[고찰] 카카오톡 대규모 트래픽 대응 방법 정리 및 생각

서론

최근 채팅에 대한 [고찰] 글을 조금씩 작성하고 있다.

내가 채팅에 관심을 가지는 이유는 아래와 같다.

1️⃣ 채팅만큼 (1)수많은 요청을, (2)단시간에 처리하는 도메인은 없다고 생각한다. 실시간으로 많은 사람과 대화하고 통신하는 도메인이 채팅말고 또 있을까?
2️⃣ API 서버를 구축하는 것은 어느정도의 한계가 존재한다. 물론 필자 또한 아무것도 모르는 개발자 지망생이지만, API 서버가 가지는 기술 난이도와 복잡성은 소켓 서버에 비해 낮다고 생각한다.(소켓스트림, 유저의 접속여부에 따른 푸시알림 및 채팅 처리, 상황에 따른 비즈니스 서비스 고려, 아키텍쳐 설계 등)

 

위와 같은 이유로 다양한 테크블로그 및 유튜브를 정리해보고 있다.

그리고 어느정도의 지식이 쌓인다 판단되면, 나만의 유연한 채팅 아키텍쳐 서버를 구축하는 것이 2025년도 올해의 최종목표이다.

비록 학업, 단체 프로젝트 등 매우 바쁘지만... 꼭 시간을 짜내서라도 완성했으면 좋겠다...! 

 

 

이번에는 '카카오톡 대규모 트래픽, 폭증하는 트래픽에 대처하는 방법' 에 대해 정리한다.

 

본론

카카오톡의 메세지 전송

백그라운드 로그인이란?

 

사용자의 편의성을 극대화하기 위한 기능이다. 우리가 카카오톡에 접속하지마자 로그인과정을 수행하지 않고, 바로 메세지를 볼 수 있는 이유이기도 하다.

1. 🙍 사용자1이 👩‍🔧사용자2에게 메세지를 보낸다.
2. 👩‍🔧는 바쁘기 때문에 카카오톡을 보지 못한다. 이때, 푸시알림을 받는다.
3. 푸시알림을 받은 모바일앱은 카카오톡이 켜진 뒤, 바로 로그인 요청을 보낸다. -> tcp 스트림 연결(socket)
4. 스트림을 통해서 사용자가 카카오톡을 다시 켜면, 곧바로 메세지를 보고 전송할 수 있다.

 

2016년 경주 지진으로 인한 카카오톡 장애

위 백그라운드 로그인이 원인이었다.

재난안내문자를 받은 모바일이 깨어나게 되면서, 모든 기기가 백그라운드 로그인 요청을 수행했다...!

이에 로그인 및 tcp 연결요청을 처리하려는 트래픽처리에 모든 쓰레드가 사용되었기에, 메세지 요청에 대한 처리에서 장애가 발생한다.

기존 접속하던 사용자도 연결 실패가 수행되면서 로그인만 처리하게 되었다....

-> 자동구축 시스템 구축 원인

 

자동구축 시스템을 어떻게?

트래픽 증가 문제에 자동으로 대처하기 위해서는 시스템의 부하를 인지해야한다. -> 활성화 쓰레드의 비율을 측정해서 트래픽 폭증을 인지하도록 한다. 평소 트래픽의 활성화가 6.25%인데, 트래픽 증가에 따라 부하레벨을 책정하여 조치할 수 있도록 한다.

부하레벨을 기준으로, 쓰레드를 독점하는 일을 제거했다. 즉, 백그라운드 로그인과 같이 빠르게 실패처리를 하더라도 당장 처리할 필요없는 요청을 막고 중요한 트래픽을 신속하게 처리할 수 있도록 했다.

부하에 따라 로그인 처리 트래픽이 증가하더라도, 일정 비율을 유지하도록 했다. 그외에는 필요한 요청(ex: 메세지 요청)에 대해서 처리할 수 있도록 구축했다. 포항 지진때 위 자동 대응 시스템을 확인할 수 있었다. 똑같이 재난문자가 발송되었다.

지표를 확인해본 결과, 지진이 발생했을 때 백그라운드 로그인지표가 매우 활성화되게 되었다. 이때, 자동으로 백그라운드 로그인을 차단하면서 로그인 TPS가 낮아지게 되었다. 

완벽하게 대용량 트래픽이 한순간에 몰려오는 것을 빠르게 대응하고 처리한 모습이다.
특히 똑같은 상황에서 다른 결과를 증명한 것이 감탄이 나온다.

📌📌📌📌
대용량 트래픽에 따른 부하레벨 구축 및 특정 요청 처리를 제한한다. 특정 요청을 서버에서 어떻게 인지하도록 했을까?
특정 요청에 대한 차단 혹은 쓰레드 일정수 분배하는 시스템 구축을 고려해보자.

 

교통 관리 시스템 구축하기

2020 1월 1일 신년 장애

 

2019년 이미 신년에 대비해 구축해두었던 시스템이 있었다. 이후 새로운 시스템을 도입하다보니, 이 시스템의 응답시간이 10ms에서 600ms까지 증가하는 문제가 발생했다. 전체 서버에서도 장애가 발생한다. 결국 client요청이 timeout이 발생하고 연결이 끊어졌다.

 

이때 새해에 요청하는 트래픽은 백그라운드 로그인이 아닌, 기본적인 앱의 동작과정이었기에 구축된 시스템이 없었다.

-> 이전 자동 트래픽 관리 시스템으로는 조절 불가했고, 이때 또한 로그인 트래픽이 급증하게 되었다.

-> 결국 위 자동 대응 시스템만으로는 해결불가...⚠️⚠️⚠️⚠️

 

요청별 전용 도로

상대적으로 무거운 로그인 요청이 너무나도 많아지면 문제가 발생한다. 신년에 끊어졌던 로그인은 사용자가 직접 요청하는 로그인이었다.

-> 로그인(각 요청마다의)에 관련된 전용별 도로를 만들면 되지 않을까?

 

로그인을 처리가 오래걸리기에, 로그인의 쓰레드를 한정짓도록 한다!😊 로그인이 쓰레드를 독점하지 않도록 한다.

다른 요청에 대한 처리를 모두 원활하게 수행하자!

교통관리 시스템: 매니저 객체가 다양한 요청에 대해서 할당될 쓰레드 수를 정의한다. 각 요청에 대한 쓰레드 수가 임계점에 도달하면 overflow를 통해 실패시킨다! -> 보면 로그인의 쓰레드 수가, 늘 가장 많다..!

이또한 똑같은 상황에서 위 교통 관리 시스템이 효과를 보였다. 22년 월드컵 조규성의 가나전 골.

이전, 18년도 월드컵에서 300만 에러가 발생했지만, 22년도에는 에러가 없었고 초당 42만건을 받아도 장애가 없었다...

로그인이 카카오톡에서 가장 많다는 점이 놀랍다.
트래픽의 중요도는 메세지 전송이 가장 중요하지만, 무조건 채팅 시스템의 처리가 중요한 것이라 생각했다. 신기하구만...

📌📌📌📌
교통관리 시스템에서 매니저가 쓰레드 수를 관리하고 있고, 쓰레드가 임계점(t1)에 도달하면 overflow를 수행한다고 했다.
이는 어느 1가지 요청이 쓰레드를 점유하여, 다른 요청을 처리하지 못하는 상황에서 유효하다.
그렇지만, 과연 단순히 1가지 요청의 쓰레드가 많은 상황이어도 꼭 이렇게 처리해야할까? 이런 상황에서는 놀고있는 쓰레드를 분배할수는 없을까?
-> 최저 임계점 t2을 설정한다. t2 > {현재 활성화 쓰레드 수} 일 경우, dynamic thread allocation을 통해서 실시간 쓰레드 풀을 조정하는건?

 

---

내 생각 정리

각 상황에 따른 장애에 빠르게 대응했고, 동일한 상황에서 다른 결과를 보여낸 모습은 왜 카카오가 국내 최고의 IT기업 중 하나인지 보여주는 결과라고 생각한다.

 

핵심 2가지 정리

1. 특정 요청(백그라운드 로그인)에 대한 부하레벨 측정 및 트래픽 차단을 통한 다른 요청의 원활한 트래픽 통신.

2. 요청에 따른 쓰레드 수를 조절할 수 있는 시스템 구축.

 

실시간 쓰레드 풀 재할당은 안정성이 떨어지고, 복잡성이 증가하는 대신, 속도가 빠르다. 과연 그런가?

채팅 서버 만들면서 나중에 실험해보자!