if kakao 2022 : 카카오톡 메시징 시스템 재건축 이야기 끄적끄적

카카오 메시지는 일 평균 500k /tps 트래픽, 40M 의 평균 연결 세션 수, 6.5M /tps 의 최고 트래픽을 가지고 있다.

 

 

2011년 겁나 빠른 황소 프로젝트를 통해 패킷 경량화 및 통신 최적화, 푸시 시스템 구조 최적화, 백엔드 시스템 성능 개선을 함

11년 동안 잘 사용했음

 

client와 연결되는 곳은 c++로 하고 비즈니스 로직은 java로 했음

c++ 백엔드는 epoll기반 비동기 입출력, 쓰레드 별로 미리 할당한 메모리 버퍼 사용, 대당 500K이상 세션 관리

 

과연 이게 앞으로도 잘 돌아갈까?

 

커스텀은 진짜 하나 하나 다 성능을 끄집어냈지만 시간이 지날수록 유지보수가 힘들어진다.

양산은 어느정도 성능 저하는 있겠지만 유지보수가 짱좋음

 

현재 앞단에 있는 서버는 직접 개발한 코드로 인해 고성능 서비스를 제공했지만 기능 개선/개발 등에 치명적임

코드가독성도 떨어지고 라이브러리 내재화로 외부 라이브러리 사용이 제약적임

메모리 효율이 줄어듬

무엇보다 11년이 지난 지금 메모리 버그가 생길때마다 원인 파악이 어려워지고 문제 해결 시간이 점점 길어짐

 

어려운 유지보수

- 적은 단위 테스트, 너무 복잡한 통합 테스트

- 오래된 배포 시스템 : shell script / python

- 파트내 인적 리소스 불균형: c++/java

과연 10년 후에도 문제 없이 유지보수가 가능할까?????

 

비즈니스서버

- java

- spring 

- netty with epoll

- jenkins

- bdd with cucumber

- junit

 

재건축 1차

- 트래픽이 비교적 적고 장애 영향도가 낮은 서비스 부터 각 모듈을 1:1로 교체

private api server : As-Is

사내 서비스를 위한 api 서버

호출시 자체 메시징 프로토콜 지원 필욧

문서 빈약

 

To-Be

Http호출 지원

AsciiDoc을 이용한 문서화

k8s를 이용한 유연한 배포 및 확장성 증대

 

session info repository : As-Is

- 세션 정보 저장 서버

- In-memory저장

- 확장 및 기능추가의 어려움

To-Be

- 저장소 분리 : Redis(cluster)

- 고도화된 세션 정보 저장 가능(e.g. 읽지 않은 메시지 개수 등)

- k8s를 통한 유연한 배포 및 확장 

 

Redis

- 적용 중 레디스 피크 트래픽 산정 실패

- 각 레디스 버킷당 100K tps 이상 넘지 않도록 설정

- Redis client 변경 : Jedis --> Lettuce

 

 

Relay & session manager

- 500k sessions

- 15 ~ 30k tps, max 100k tps

 

고민점

- GC로 인한 stw 영향 최소화 : ZGC

- 빠르고 편한 개발 : Kotlin

- 비동기 릴레이 : Thread pool executor, 추후 coroutine

- Full-mesh 에서 한 대씩 신규 서버 적용: 장애 위험성 고려

-- 클라이언트 / 타 서버에서는 블랙박스

- 기존 서버 대비 성능 이슈

-- 잦은 메모리 할당으로 인한 성능저하가 있을까??

부하테스트에서 kotlin에서 큰 성능 저하는 없었음

gc는 stw이슈 때문에 반드시 zgc가 좋음

 

g1gc 와 zgc의 비교에서 zgc가 프로토콜 처리 안정성이 더 좋다.

 

최적화 작업

- 멀티 디바이스를 위한 세션 구조 개편

- 동시성 영향 받는 데이터들의 Lock 구조 개선

- GC 설정 튜닝

- 비동기 릴레이 : thread pool, 이후 coroutine

 

개선 사항

- 간결해진 코드 : 절반 이상 감소한 코드라인

- 접근성이 높아진 배포 및 운영 : 터미널 -> 웹

- 가용 인력 3배 증가

- 실수를 줄여주는 직관적인 통합 테스트

 - 계층 분리를 통해 유연해진 디자인