요구사항 정리와 범위 자르기
채팅 설계도 요구사항을 기능과 비기능으로 나누고 범위 밖을 먼저 자르는 것에서 시작합니다. 이 토픽은 아래 하나의 요구사항을 끝까지 풉니다.
| 항목 | 값 |
|---|---|
| 서비스 | 팀 메신저 |
| 동시 접속 | 20만 |
| 채널 크기 | 평균 12명, 최대 5만 명 |
| 메시지 | 하루 2억 건 |
| 전달 지연 | 300ms 안에 상대 화면까지 |
| 순서 | 채널 안에서만 보장한다. 전역 순서는 포기 |
기능 요구사항과 범위 밖
| 구분 | 내용 |
|---|---|
| 이번에 만든다 | 채널에 메시지 보내기, 실시간 수신, 지난 메시지 조회, 읽음 표시, 접속하지 않은 사람에게 알림, 접속 상태와 입력 중 표시 |
| 범위 밖 | 음성과 영상 통화, 파일 미리보기, 메시지 검색, 종단간 암호화 |
범위 밖을 말하는 것이 실력입니다. 검색을 빼면 저장 구조가 단순해지고, 종단간 암호화를 빼면 서버가 내용을 볼 수 있어 알림 문구를 만들 수 있습니다. 뺀 것이 남은 설계를 바꿉니다.
비기능 요구사항이 설계를 정한다
| 숫자 | 강제하는 것 | 왜 |
|---|---|---|
| 동시 접속 20만 | 연결 계층 분리 | 연결을 유지하는 일과 메시지를 처리하는 일은 자원 성격이 다르다 |
| 채널 최대 5만 명 | 팬아웃 설계 | 한 번 보낸 메시지가 5만 개의 전달로 늘어난다 |
| 지연 300ms | 서버가 밀어주기 | 폴링은 간격만큼 지연이 쌓인다 |
| 채널 내 순서만 | 채널 단위 파티션 | 전역 순서를 포기하면 채널별로 나눠 처리할 수 있다 |
순서를 어디까지 보장할지가 확장을 정한다
전역 순서를 보장하려면 모든 메시지가 한 곳을 지나야 합니다. 그러면 그곳이 상한이 됩니다.
채널 안에서만 보장하기로 정하면 채널을 기준으로 나눠 처리할 수 있습니다. 다른 채널의 메시지가 서로 뒤바뀌어도 사용자는 알 수 없습니다. 한 대화방 안에서만 순서가 맞으면 됩니다.
이것이 요구사항을 읽는 방법입니다. 무엇을 포기해도 되는지 찾으면 확장 경로가 열립니다.
평균값은 반대로 읽는다
평균 12명 이라는 숫자는 과설계를 막는 쪽으로 씁니다. 최대가 5만 명 이라 팬아웃 설계가 필요하지만, 실제 채널 대부분은 12명이라 보낼 때 바로 전달해도 됩니다.
그래서 설계는 하나가 아니라 두 갈래가 됩니다. 작은 채널은 즉시 전달, 큰 채널만 다른 경로로 보냅니다. 최대값만 보고 모든 채널을 무겁게 처리하면 흔한 경우가 느려집니다.
- Q.채팅 서비스의 요구사항을 어떻게 정리하시겠습니까
- Q.메시지 순서를 어디까지 보장해야 하나요
- Q.이 요구사항에서 가장 먼저 한계에 닿는 곳은 어디인가요