대규모 채팅 시스템 설계하기 1: 실시간 통신 방식

ACC에서 사이드 프로젝트를 시작했다. 

주제는 총 4개가 있었는데, 그 중 우리 팀은 대규모 채팅 시스템을 만들기로 했다.

📌 채팅 시스템 요구 사항

• 일대일 채팅 및 그룹 채팅 지원
• 채팅 이력을 키-값 저장소에 보관
• 평균 1,000명 동시 사용자
• 초당 약 50건의 메시지 처리
• 최대 6개월간 메시지 보관
• 메시지 전송 지연 시간 2초 이내

이 외에도 다음과 같은 심화 조건이 있었다:

• 그룹 채팅: 최대 100명까지 참여 가능
• 첨부 파일 전송: 최대 10MB
• 오프라인 메시지 처리: 재접속 시 동기화 지원
• 멀티 디바이스: 동일 계정으로 최대 3대까지 동시 접속 허용

우리는 먼저 기본 조건부터 완성하기로 했다.

---

💬 채팅 시스템의 핵심: 실시간 통신

일반적인 웹 서비스에서는 HTTP 요청/응답 방식으로 통신하지만, 채팅 서비스처럼 빠른 상호작용이 필요한 경우에는 실시간 통신이 필수다.

실시간 통신 방식은 여러 가지가 있으며, 이번 프로젝트에 적용할 수 있는 대표적인 방식들을 정리해보았다.

1. Polling (짧은 주기 폴링)

클라이언트가 일정 주기마다 서버에 "새 메시지 있나요?"라고 요청을 보내는 방식이다.

• 구현은 간단하지만,
• 메시지가 없어도 계속 요청이 발생하므로 서버 리소스 낭비가 크다.
• 주기가 짧을수록 실시간성은 올라가지만 비용도 증가한다.

2. Long Polling

Polling의 단점을 보완한 방식이다.

• 클라이언트가 요청을 보내면, 서버는 응답을 보류하고 새 메시지가 생겼을 때 응답을 보낸다.
• 메시지를 받은 클라이언트는 즉시 다음 요청을 다시 보내며 연결을 유지한다.

다만, 메시지 발생이 잦은 경우에는 결국 Polling처럼 짧은 간격의 재요청이 반복되며,
여러 채팅 서버를 운영할 때 로드밸런서의 라운드로빈 방식 때문에 송신자와 수신자가 다른 서버에 연결되면 메시지 전달에 어려움이 생길 수 있다.

3. Streaming

한 번 연결을 맺고, 서버가 지속적으로 데이터를 푸시하는 방식이다.

• HTTP 기반이지만 응답이 끊기지 않고 데이터 흐름이 계속 유지된다.
• 단방향(서버 → 클라이언트) 통신이라는 제한이 있어, 클라이언트가 서버로 메시지를 보내는 데는 적합하지 않다.

4. WebSocket

실시간 통신 기술 중 가장 널리 사용되는 방식이다.

• 클라이언트가 서버와 지속적인 양방향 연결을 유지한다.
• 연결 후에는 별도의 요청 없이도 서버와 클라이언트가 자유롭게 메시지를 주고받을 수 있다.
• 채팅, 실시간 알림, 게임 등에서 가장 보편적으로 사용됨

WebSocket은 HTTP 또는 HTTPS 포트를 사용하므로, 방화벽이 있는 환경에서도 잘 작동한다.
다만, 연결을 계속 유지해야 하므로 서버에서 연결 수 관리 및 스케일링 전략이 중요하다

 

 

채팅 시스템은 클라이언트와 서버가 양방향 연결을 해야하기 때문에, 웹소켓을 사용하기로 결정했다.

그리고 주제 구체화를 진행했다.

주제: 아티스트가 되어보세요 - 페이크버블

• 방장: 아티스트 라벨을 달고 연예인처럼 화려한 디자인 하에서 채팅을 남김
  • 방을 만드려면 비밀번호를 입력 → 비밀번호로만 방장 로그인 가능 (필수)
  • 웬투밋처럼 하면 로그인 구현 간단!!
  • 회원 정보 만들 필요 X, 각 채팅방만 고유 O
  • 프로필 사진 업로드 용으로 S3 사용
• 익명: 익명으로 채팅을 남김 (로그인 필요 x)
• 방장과 익명유저 각자의 시점에서 채팅 UI는 서로 반대로 렌더링 (본인이 쓰는 쪽이 우측)
• 각 채팅방의 URL은 고유함 (링크가 UUID)

이게 우리 팀이 정한 주제이다.

 

⚙️ 기술 스택 및 인프라 설계

우리 팀은 AWS를 활용한 인프라 구조를 구성했다.
고가용성과 확장성을 고려해 다음과 같이 구성했다:

💬 채팅

• WebSocket + API Gateway + Lambda (메시지 입출력용 Lambda 2개)

🗃 메시지 저장

• DynamoDB: 채팅 메시지 저장 (6개월 TTL)

👤 유저/채팅방 정보

• RDS (MySQL): 방 정보, 유저 메타데이터 관리

🚀 메시지 브로드캐스트

• Redis Pub/Sub (ElasticCache): 서버 간 메시지 동기화

🔧 API 서버

• EC2 + VPC 기반 API 서버 구성

📈 부하 테스트 및 확장

• ALB + Lambda Auto Scaling
• CloudWatch Events / EventBridge로 시간대 기반 스케일링 조정

📜 기타

• S3: 프로필 이미지 업로드
• 로그 관리: 추후 CloudWatch + S3 연동 예정

 

하지만 아직 Redis, SQS를 쓰는 것이 적합한건지 모르겠다.

2주차까지 공부를 더 해봐야할 것 같다...