본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://fastcampus.info/4n8ztzq
안녕하세요 :)
오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 " 챌린지에 도전하는 서른 세번째 날입니다.
서른 두번째 날에는 커넥션 서비스를 분리하는 이유에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.
오늘 학습할 내용의 제목은,
Part 5. 모놀리틱 서비스 분해 > Ch 3. 책임 분리로 진행하는 모놀리틱 서비스 분해와 양방향 카프카 연동 >
02. 양방향 카프카 연동을 위한 구조 설명
입니다.
🔄 모놀리틱 분해: 양방향 카프카 연동 구조 설계
- 이번 챕터의 두 번째 주제는 양방향 카프카 연동 구조입니다.
- 이전 글에서 커넥션 서버와 메시지 서버를 분리해야 하는 이유를 살펴봤다면, 이번에는 이 둘을 카프카를 통해 어떻게 안정적이고 순서 보장 가능하게 연결할지 이야기하겠습니다.
📌 카프카 파티션과 순서 보장
- 카프카의 토픽은 여러 개의 파티션으로 구성될 수 있습니다.
- 단일 파티션: 메시지가 FIFO 순서로 들어오고 처리 순서도 보장됩니다.
- 멀티 파티션: 성능은 확장되지만, 메시지 처리 순서가 뒤섞일 수 있습니다.
- 채팅 서비스에서 중요한 것은 동일 사용자가 보낸 메시지의 순서입니다.
- 다른 사용자의 동시 메시지 전송 순서는 중요하지 않지만, 한 사용자가 1 → 2 → 3 순서로 전송한 메시지가 2 → 1 → 3으로 도착해서는 안 됩니다.
- 이를 해결하기 위해 파티션 키를 사용합니다.
- 파티션 키를 (채널 ID, 유저 ID)로 설정
- 동일 사용자가 동일 채널에 보낸 메시지는 항상 같은 파티션으로 라우팅
- 해당 파티션 내에서는 FIFO 순서가 유지되므로, 최소한 사용자 단위의 순서 보장은 가능합니다.
🔄 양방향 카프카의 개념
- 카프카는 본질적으로 단방향 스트리밍입니다.
- 한 토픽을 통해 커넥션 서버 → 메시지 서버 방향으로 메시지를 보낼 수 있습니다.
- 반대 방향(메시지 서버 → 커넥션 서버) 통신을 위해서는 또 다른 토픽이 필요합니다.
- 즉, 단방향 토픽 2개를 구성하면 논리적으로 양방향 통신이 가능해집니다.
- 토픽 A: 커넥션 서버 → 메시지 서버
- 토픽 B: 메시지 서버 → 커넥션 서버
- 이렇게 하면 양쪽 모두 스케일 아웃이 가능하며, 각 방향이 독립적으로 동작합니다.
⚠️ 문제: 커넥션 서버 스케일 아웃 시 세션 식별
- 커넥션 서버는 웹소켓 연결을 직접 관리합니다.
- 스케일 아웃된 상태에서 메시지 서버가 응답을 전송할 때, 해당 사용자가 어느 커넥션 서버에 연결되어 있는지 알아야 정확히 전달할 수 있습니다.
- 일반적인 브로드캐스트 구조에서는 이 매핑이 불분명해져서 잘못된 서버로 응답이 가는 문제가 생깁니다.
💡 해결책: 커넥션 서버 전용 토픽
- 각 커넥션 서버가 자신만 소비하는 전용 토픽을 가집니다.
예시:- 커넥션 서버 1 → B1 토픽
- 커넥션 서버 2 → B2 토픽
- 사용자가 커넥션 서버에 연결되면, 해당 서버는 (유저 ID → 토픽명) 매핑 정보를 Redis에 저장합니다.
- 메시지 서버가 특정 사용자에게 응답해야 할 때, Redis를 조회해 해당 사용자가 속한 토픽을 확인합니다.
- 해당 토픽으로 프로듀싱하면, 오직 그 토픽을 소비하는 커넥션 서버가 메시지를 가져와 연결된 웹소켓 세션에 전달합니다.
- 이 구조의 장점은 풀메쉬 연결 없이도 확장 가능하다는 점입니다.
- 커넥션 서버를 추가해도 단순히 전용 토픽을 하나 더 만들면 되고, 기존 서버는 영향을 받지 않습니다.
🛠 운영 환경 고려
- 카프카 토픽은 런타임에 동적으로 생성할 수 있지만, 운영 환경에서는 보안 및 정책에 따라 사전 생성이 필요할 수 있습니다.
- 개발 환경: 카프카 어드민 API를 통해 동적 생성
- 운영 환경: 배포 전에 토픽 미리 생성 후 사용
- 우리의 구현에서는 개발 편의를 위해 동적 생성을 활용할 계획입니다.
- 이번 구조 설계에서 가장 핵심적인 부분은 세션 위치를 정확히 식별하는 방법이었습니다.
- 단순히 카프카로 메시지를 전달한다고 해서 원하는 서버에 도착하는 것이 아니기 때문에, 전용 토픽 + Redis 매핑 구조는 매우 합리적인 선택이라고 생각합니다.
- 또한, 이 구조는 채팅 외의 다른 실시간 서비스(게임 매치메이킹, 실시간 알림, IoT 기기 제어 등)에도 응용할 수 있습니다. 특히 "토픽 설계" 가 잘 되어 있어야 이후 운영·확장 과정에서 병목 없이 안정적인 서비스가 가능하다는 점을 다시 한번 느꼈습니다.
