[ACC Ewha] 대규모 채팅 시스템 설계 프로젝트 - (1) 주제 선정, 유저 시나리오 작성, 아키텍처 초안 작성

ACC Ewha 사이드 프로젝트로 대규모 시스템 아키텍처를 설계해보게 되었다!

"가상 면접 사례로 배우는 대규모 시스템 설계 기초" 책을 기반으로 주제가 결정되었는데, 우리 팀 주제는 '채팅 시스템'이다.

 

주제 요구 조건

• 일대일 채팅 또는 그룹 채팅 기능을 구현한다.
• 키-값 저장소에 채팅 이력을 보관한다.

인프라 요구 조건

• 평균적으로 약 1000명의 유저가 해당 서비스를 사용 (최대 동시 접속 사용자 수 500명 예상)
• 초당 약 50건의 메시지 전송 처리 필요
• 최대 6개월간 메시지 내역 보관 필요
• 메시지 전송 지연 시간은 2초 이내

심화 조건

• 그룹 채팅 지원: 최대 100명까지 참여 가능한 그룹 채팅방 제공
• 첨부 파일: 채팅에서 최대 10MB 크기의 파일 첨부 기능 지원
• 오프라인 메시지 처리: 사용자가 오프라인 상태일 때 메시지 저장 및 재접속 시 동기화
• 멀티 디바이스 지원: 동일 계정으로 최대 3개 기기 동시 접속 지원 (동일 계정 접속 수 제한)

채팅 시스템 아키텍처 구축 사례를 찾아보니, 과거 컨퍼런스에서 진행된 발표들을 찾을 수 있었고 이를 바탕으로 어떤 기술을 사용해야 하는지 감을 잡을 수 있었다.

 

천만 사용자를 위한 카카오의 AWS Native 글로벌 채팅 서비스 - 김영욱 SA, AWS / Walter Kim 실장, Kakao :: AWS Summit Seoul 2023

https://www.youtube.com/watch?v=BG7U3zXJ39M&embeds_referring_euri=https%3A%2F%2Fwww.notion.so%2F&source_ve_path=MjM4NTE

 

2200만 사용자를 위한 채팅 시스템 아키텍처 - 서호석 솔루션즈 아키텍트, AWS / 변규현 SW 엔지니어, 당근마켓 :: AWS Summit Korea 2022
https://www.youtube.com/watch?app=desktop&v=lCxgddyxDyg

 

2024 당근 테크밋업 

https://www.youtube.com/watch?v=_F6k0tg8ODo

 

 

WebSocket: 양방향 실시간 통신에서 필수!

과거 SSE 기능 구현을 하다가 알게 되었던 웹소켓을 사용해볼 때가 드디어~

과거라면 WebSocket을 Spring Boot에서 구현하는 것만 생각했을 것 같은데, 구축 사례를 열심히 찾아보니 AWS 서비스로 채팅시스템 구축이 가능했다.

아래의 이미지를 참고해 아키텍처를 구상하게 되었다.

API Gateway, AWS Lambda, DynamoDB 부분이 핵심적이다.

 

https://www.youtube.com/watch?v=XnEYjgoPUfw

---

 

채팅 시스템 기능 구체화를 위해, 어떤 채팅 시스템들이 있는지 레퍼런스를 수집했다.

그 과정에서, 팬과 아티스트가 대화하는 '버블' SNS의 채팅 방식이 인상적이었다. 일반인들도 아티스트 관점에서 채팅을 남길 수 있는 일대다 서비스가 있으면 재밌겠다는 생각이 들었다.

따라서 버블 패러디 SNS를 제안해보게 되었는데, 다들 흥미로워해서 주제로 결정되었다!

excalidraw로 유저 시나리오를 그렸다.

 

구현할 기능 목록은 다음과 같다.

1. 채팅방 생성
   1. 아티스트 이름, 비밀번호 입력 (회원가입 절차 필요 x)
   2. 채팅방 링크가 생성되며, 링크 공유 가능
2. 채팅방 입장
   1. 링크를 통해 접속할 수 있다.
   2. 입장 시 이름과 비밀번호(선택)을 입력한다. (웬투밋과 비슷)
   3. 아티스트는 생성시 입력한 정보를 바탕으로 로그인 할 수 있다.
3. 채팅방에서 채팅 조회
   1. 아티스트에게는 전체 채팅이 보인다.
   2. 팬에게는 아티스트의 채팅과 자신의 채팅이 보인다.
4. 채팅방에서 채팅 전송
5. 아티스트 계정 로그인 - 프로필 사진 업로드

---

각 기능의 구현을 위한 아키텍처 초안은 다음과 같이 구상했다.

1. 채팅: WebSocket API Gateway + Lambda(2개)
2. 채팅 메시지 저장: AWS DynamoDB
3. 유저 데이터, 채팅방 데이터 저장: AWS RDS (MySQL)
4. 메시지 큐: AWS ElasticCache (Redis Pub/Sub)
5. API 서버(백엔드): AWS EC2, AWS VPC
6. ALB 로드밸런서
7. AWS SQS
   +EventBridge, CloudWatch Event 등도 사용 계획

아직 ElasticCache와 SQS의 활용이 적절한지 잘 모르겠는데, 추가적인 공부를 진행해야 할 것 같다.

CloudCraft로 제작했는데 편집이 어려웠다. 2D 아키텍처 그림이 더 효율적인 것 같다.