- 현대 사회에 필수불가결한 메신저 어플의 대용량 데이터 발생과 이로 인한 부하를 견뎌내기 위해 필요한 대책을 직접 리서치 및 적용
- 매번 업그레이드 한 버전 별로 테스트를 진행하고 결과를 수치화, 시각화하여 개선 과정 신뢰도 향상
- 채팅 메세지 전송/수신 max 1000ms
- 채팅 메세지 영구 저장
- 실시간 서버 모니터링
- 스케일 아웃 가능한 서버
- 단계별로 아래의 테스트 조건들을 상향시키면서 에러율과 최대지연시간의 결과와 원인을 분석하며 성능 개선
- 동시간대 접속 유저 : 100~5000명
- 초당 보내는 채팅 수 : 100~5000개
- 분당 보내는 총 채팅 수 : 6000~300,000개
- 응답 시간 제한 : 1000ms, 2000ms
- 분당 최대 300000건의 데이터들을 수용하기 위한 DB 성능 개선
- 경제적이고 효율적인 DB선정을 위한 데이터베이스 시스템 분석
- MySQL
- MongoDB
- Cassandra
- 검색 성능 개선
채팅방 추가 | 채팅 기능 |
---|---|
- 부하 테스트 시연 영상
1. 도커 스웜을 통한 클러스터 환경 구축 | 2. JMeter를 통한 부하 테스트 시작 |
---|---|
3. 도커 컨테이너 리소스 사용률 및 서버 로그 확인 | 4. 그라파나를 통한 서버 모니터링 |
5. db 모니터링 | 6. 테스트를 통해 나온 지표 확인 및 분석 |
요구사항 | 선택지 | 기술 선택 이유 |
---|---|---|
🛢️ 데이터 베이스 | ver1. MySQL, ver2. MongoDB, ver3. Cassandra |
버전 별 성능테스트 결과와 IOPS와 Billing 측면에서 우위를 가진 MongoDB 최종 선택 |
📈 부하 테스트 | Jmeter, Ngrinder | 소켓 통신 테스트를 위한 시나리오 작성 가능 |
📊 모니터링 | Grafana, Prometheus, kibana | - Grafana : 시스템 관점에서 CPU 메모리, 디스크 IO 사용율과 같은 지표를 시각화 하는데 특화 - Kibana : 엘라스틱 위에서 쿼리 로그 분석에 특화 → 채팅 시스템에서 트래픽 지표를 분석하기 위해 Grafana 선택 |
🛠️ 데이터 파이프라인 | Kafka, Redis | - Redis : 휘발성 - kafka : 트랜잭션을 줄이고 비동기적으로 데이터베이스에 저장할 수 있고 정합성을 보장 → 휘발성이 있는 Redis는 신뢰도가 중요한 채팅 서비스와 적합하지 않다고 판단, kafka 선택 |
🗂️ 클러스터링 | Docker Swarm, Kubernetes | 컨테이너 클러스터링, 로드밸런싱 기능에 집중 - 중소 규모의 클러스터에서 컨테이너 기반 애플리케이션 구동을 제어하기에 충분한 기능을 제공 - 도커 엔진이 설치된 환경이라면 별도의 구축 비용 없이 컨테이너 오케스트레이션 환경 구축 가능 - Kubernetes의 경우 master node의 최소 요구 사양이 CPU 2, RAM 2GB, 현 프로젝트에 오버 스펙이라고 판단 → Docker Swarm 선택 |
🔍 검색 성능 개선 | Elasticsearch, MongoDB Index, QueryDSL |
대용량의 데이터 속에서 채팅 메시지를 찾아야 함에 집중 - 역 인덱스를 이용해 데이터를 관리하기 때문에 모든 데이터를 탐색하지 않고도 결과를 찾을 수 있음 - 데이터의 규모가 커질수록 찾고자 하는 메시지의 데이터 위치를 알고 있는 것은 성능 최적화를 가능케 함 |
⚙️ CI/CD | Github Action, Jenkins | Jenkins: 별도의 서버를 구축해야하며, 계정과 트리거에 기반하고 있으며 GitHub 이벤트를 처리할 수없다. Git Action: 클라우드에서 동작하므로 어떤 설치도 필요 없다. 모든 GitHub 이벤트에 대해 GitHub Actions를 제공하고 있다. GitHub에 push, PR 이벤트가 발생할 때 자동 테스트, 배포가 쉽게 이루어지기 때문에 개발에 몰두할 수 있음 -> Github Action 선택 |
🚀 소켓 통신 | Web socket | - 서버가 클라이언트에게 비동기 메시지를 보낼 때 가장 널리 사용하는 기술 - 양방향 메시지 전송까지 가능 |