폭증하는 카카오톡 트래픽에 대처하는 방법
카카오톡 메인 화면에서 가장 중요한 탭은 1탭과 2탭.
- 1탭: 친구 목록, 2탭: 채팅방
톡메세징파트는 채팅서비스에서 크게 두 가지를 담당하고 있다.
- 카카오 클라이언트의 로그인 관련 기능
- 카카오 클라이언트에서 채팅방 진입, 메시지 동기화, 메시지 전송 등
처리하는 메시지의 양
- 평상시 낮 최고 트래픽은 초당 62만 건 정도
- 메시지 전송만 보면 초당 4만 5천 건.
트래픽 폭증 예시
- 지진과 같은 자연재해
- 대형 이벤트 - 신년 / 월드컵과 같은 큰 이벤트
대응 실패하면 장애 발생. 카카오톡에서 장애 대응 시스템을 어떻게 만들어왔는지, 실제 서비스 장애가 있었던 사례와 함께 소개하고자 함.
자동 대응 시스템
2016년 9월 경주 지진으로 인한 장애를 설명하려면, 백그라운드 로그인 기능을 설명해야 함.
백그라운드 로그인: 사용자 편의성을 위한 기능
- 누군가 메시지를 카톡방에 보내면, 서버는 메시지를 카톡 클라이언트에 전달하려고 시도함.
- 사용자가 카톡 안보고 있고 접속도 안하고 있으면
- iOS의 APNS나 안드로이드 FCM 사용해서 사용자에게 Push를 보냄.
- push 받은 모바일은 카톡이 켜짐, 클라이언트가 서버에 로그인 절차를 수행.
- 사용자가 따로 로그인하지 않고도 메시지 볼 수 있도록 하는 것.
경주 지진 때 카카오톡이 2시간 가까이 장애가 있었던 이유: 백그라운드 로그인.
- 재난안내문자가 전국민에게 발송 -> 모바일 wake up, 카톡 클라이언트가 백그라운드 로그인 수행
- 평상시에는 일부 사용자가 수동으로 로그인 / 메시지가 도착했을 때에만 백그라운드 로그인 시도
- 재난 발생시 전국민의 디바이스가 한번에 로그인 시도하는 상황이 됨
- 무거운 로그인 로직을 우선하기 위해 모든 리소스 사용 -> 메시지 로직이 실패함.
- 메시지 로직에 실패가 반복되자 재로그인하는 디바이스 등장
장애 터지고 트래픽이 폭증하다가, 백그라운드 로그인 요청이 우선되면서 메시지 전송 TPS가 바닥을 찍는다.
- 1시간 반 가까이 장애가 지속됨.
신년이나 월드컵처럼 예측 가능한 이벤트 말고, 재난상황처럼 예측 불가능한 이벤트는 자동으로 인지하고 대응할 수 있어야 한다.
- 대응방법: 활성 쓰레드 개수에 따른 구분
- 활성 쓰레드 비율을 토대로 '부하 레벨'을 구분한다.
- 트래픽 폭증 상태를 서버가 인지하면, 상황에 맞게 대응할 수 있도록 한다.
- 부하 레벨이 높아지면, 백그라운드 로그인 비중을 낮추고 메시지 전송 재시도 횟수도 조절한다.
즉 사용자 편의기능인 백그라운드 로그인 기능은 긴급상황일 때 비활성화. 메시지 전송을 우선한다.
효과: 2017년 포항 지진
- 지진 발생했을 때 백그라운드 로그인 트래픽 증가. -> 활성화된 쓰레드 개수 상승 -> 백그라운드 로그인 기능 차단
- 메시지 TPS는 큰 문제 없이 처리됨.
교통관리 시스템 구축
새로 도입한 시스템에서 장애 발생. 응답시간이 10ms -> 600ms까지 상승.
- timeout이 발생하면서 일부 클라이언트 연결이 끊김. = 재로그인이 필요
- 백그라운드 로그인이 아니라 '사용자가 직접 요청하는 로그인' 요청이 증가. -> 백그라운드 로그인 대응 시스템이 동작하지 않음
- 장애의 최초 발원지 해결은 5분, 장애가 전파되어 발생한 시스템 성능 하락을 복구하기까지는 1시간 40여 분.
로그인은 상대적으로 무거운 요청. 처리 시간이 꽤 걸린다.
- 들어오는 요청별로 할당 가능한 쓰레드를 구분 / 한정하면 되지 않을까?
요청이 들어왔을 때, 요청 종류에 따라 할당할 수 있는 쓰레드 개수를 지정한다.
- 할당한 쓰레드 개수가 임계점을 넘을 경우 실패를 응답한다.
이 조치의 효과는 2022년 카타르 월드컵에서 나타났다.
카카오톡에서 가장 높은 트래픽이 발생한 시점: 카타르월드컵 가나전 조규성의 동점골. (2018년 독일전 손흥민 골 시점의 트래픽 갱신)
- 초당 TPS가 42만.
- '메시지 전송'에 할당된 쓰레드 개수를 제한.
- 2018년 독일전의 경우 평소보다 에러 지표가 크게 높음
- 2022년 가나전의 경우 평상시와 비슷한 수준의 에러 지표. (y축 노란색이 독일전, 주황색이 가나전.)
메시지 전송은 일부 실패하더라도, 서비스 장애로 전파되지 않도록 조치.
- 트래픽 우선순위 산정하기.
- 특정 요청이 모든 자원을 점유하지 않도록
https://www.youtube.com/watch?v=U905BeDQ_BA
'학습일지 > architecture' 카테고리의 다른 글
우아콘 2023 - Kafka를 활용한 이벤트 기반 아키텍처 구축 (0) | 2024.05.08 |
---|---|
Designing Event-Driven MicroServices: Patterns (0) | 2024.01.21 |
KubeCon 2022 NA - How to build a Distributed System (0) | 2022.12.11 |
WoowaCon 2022 - 회원 시스템 이벤트 아키텍처로 구축하기 (0) | 2022.10.27 |
Complete Jenkins Pipeline Tutorial | Jenkinsfile explained 정리 (0) | 2022.04.10 |