요구사항 정리와 범위 자르기

기능과 비기능으로 나누고 범위 밖을 먼저 자릅니다.

그다음 각 숫자가 어떤 설계를 강제하는지 말합니다. 동시 접속 20만 은 연결 계층을 분리하게 만들고, 채널 최대 5만 명 은 팬아웃 설계를 요구합니다.

흔한 실수: 비기능을 "실시간, 고가용성, 확장성" 처럼 형용사로 나열하는 것. 숫자와 그 숫자가 강제하는 결론이 없으면 아무 설계도 정해지지 않습니다. 그리고 범위 밖을 말하지 않으면 통화와 검색까지 얘기가 번져 무엇도 깊게 다루지 못합니다.

채널 안에서만 보장합니다. 전역 순서는 포기합니다.

전역 순서를 보장하려면 모든 메시지가 한 곳을 지나야 하고, 그러면 그곳이 처리량 상한이 됩니다. 채널 단위로만 보장하면 채널을 기준으로 나눠 처리할 수 있습니다.

채널 A 의 메시지끼리는 순서가 맞아야 한다
채널 A 와 채널 B 의 메시지가 서로 뒤바뀌어도 사용자는 알 수 없다

사용자는 한 대화방을 보고 있으므로 그 안에서만 맞으면 됩니다. 필요 없는 보장을 찾아 버리는 것이 확장 경로를 여는 방법입니다.

흔한 실수: 순서를 타임스탬프로 맞추겠다고 답하는 것. 서버 시계가 조금씩 다르고 같은 밀리초에 두 메시지가 들어올 수 있습니다. 순서가 중요하면 채널마다 증가하는 번호를 서버가 붙이는 편이 확실합니다.

연결 유지입니다. 메시지 처리량보다 먼저 걸립니다.

하루 2억 건 을 초로 나누면 약 2,300건
피크를 5배로 잡아도 초당 1만건 남짓
반면 동시 접속은 20만 이 계속 열려 있다

초당 1만 건 쓰기는 파티션을 나누면 처리됩니다. 그런데 20만 개의 연결은 아무 메시지가 오가지 않아도 메모리와 파일 디스크립터를 계속 점유합니다.

그래서 연결을 받는 계층과 메시지를 처리하는 계층을 나눕니다. 자원 성격이 다르면 따로 늘려야 합니다.

흔한 실수: 초당 메시지 수만 계산하고 끝내는 것. 채팅은 연결이 오래 살아 있는 종류라 요청 수로 환산한 숫자만 보면 병목을 반대로 짚습니다.

아닙니다. 평균이 12명 이므로 대부분의 채널에는 과설계입니다.

큰 채널용 팬아웃 설계는 공짜가 아닙니다. 전달을 큐로 넘기고, 진행 상태를 추적하고, 실패한 전달을 다시 시도하는 구조가 붙습니다.

그래서 설계는 두 갈래가 됩니다. 인원 수를 보고 경로를 고릅니다.

흔한 실수: 최대값만 보고 하나의 경로로 통일하는 것. 요구사항에 평균이 함께 적혀 있는 이유가 이것입니다. 최대는 무엇이 가능해야 하는지를 정하고, 평균은 무엇이 흔한지를 정합니다. 흔한 경우를 무겁게 만들면 전체가 느려집니다.