<div id="readability-page-1" class="page"><div>
 <a href="/m/category/%EB%AD%94%EA%B0%80%EB%A5%BC%20%EB%B4%A4%EA%B1%B0%EB%82%98%20%ED%96%88%EB%8B%A4%EB%A9%B4%20%EC%98%AC%EB%A6%AC%EB%8A%94%20%EC%B9%B4%ED%85%8C%EA%B3%A0%EB%A6%AC">뭔가를 봤거나 했다면 올리는 카테고리</a><h3>if kakao 2022 : 카카오톡 메시징 시스템 재건축 이야기 끄적끄적</h3>
 </div><cite>Berno</cite>
 2022. 12. 18. 19:12
 <div>
 카카오 메시지는 일 평균 500k /tps 트래픽, 40M 의 평균 연결 세션 수, 6.5M /tps 의 최고 트래픽을 가지고 있다.


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

client와 연결되는 곳은 c++로 하고 비즈니스 로직은 java로 했음
c++ 백엔드는 epoll기반 비동기 입출력, 쓰레드 별로 미리 할당한 메모리 버퍼 사용, 대당 500K이상 세션 관리

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

커스텀은 진짜 하나 하나 다 성능을 끄집어냈지만 시간이 지날수록 유지보수가 힘들어진다.
양산은 어느정도 성능 저하는 있겠지만 유지보수가 짱좋음

현재 앞단에 있는 서버는 직접 개발한 코드로 인해 고성능 서비스를 제공했지만 기능 개선/개발 등에 치명적임
코드가독성도 떨어지고 라이브러리 내재화로 외부 라이브러리 사용이 제약적임
메모리 효율이 줄어듬
무엇보다 11년이 지난 지금 메모리 버그가 생길때마다 원인 파악이 어려워지고 문제 해결 시간이 점점 길어짐

어려운 유지보수
- 적은 단위 테스트, 너무 복잡한 통합 테스트
- 오래된 배포 시스템 : shell script / python
- 파트내 인적 리소스 불균형: c++/java
과연 10년 후에도 문제 없이 유지보수가 가능할까?????

비즈니스서버
- java
- spring&nbsp;
- 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를 통한 유연한 배포 및 확장&nbsp;

Redis
- 적용 중 레디스 피크 트래픽 산정 실패
- 각 레디스 버킷당 100K tps 이상 넘지 않도록 설정
- Redis client 변경 : Jedis --&gt; Lettuce


Relay &amp; 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

개선 사항
- 간결해진 코드 : 절반 이상 감소한 코드라인
- 접근성이 높아진 배포 및 운영 : 터미널 -&gt; 웹
- 가용 인력 3배 증가
- 실수를 줄여주는 직관적인 통합 테스트
&nbsp;- 계층 분리를 통해 유연해진 디자인
 
 
 </div></div>

흔한 컴공출신 개발자

bernoyoun

카카오 메시지는 일 평균 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배 증가
- 실수를 줄여주는 직관적인 통합 테스트
 - 계층 분리를 통해 유연해진 디자인

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

댓글