오늘은 if(kakao)dev2022에서 시청한 카카오 메세징 재건축 이야기를 보고, 해당 영상에서 개발자들이 고려했던 점들을 짚어보고 이해해보려고 한다.
1. 발표 내용
해당 발표에서는 노후화된 카카오 메세징 시스템의 개선에 대한 내용을 다룬다. 본 목차에서는 개발자들이 왜 이런 선택을 했는가를 생각해보고 이에 대해 작성해보도록 하겠다.
1.1 커스텀과 양산형
발표에서 처음을 여는 주제이다. 커스텀은 각 요소들을 최적화하여 성능을 끌어올린 상태를 의미하고, 양산형은 각종 외부 라이브러리를 사용하여 개발한 제품을 의미한다고 볼 수 있다.
물론 최적화가 된 커스텀이 성능이 더 좋겠지만, 해당 발표에서는 커스텀의 결과물에 대한 다른 시각에 대해서 이야기한다.
- 내부 라이브러리 사용 혹은 내재화를 통한 서비스 종속성
- 복잡하거나 세부적인 로직이 생기면서, 가용 인원이 부족해짐
- 담당자 부재 시, 개발 및 유지보수가 어려움
커스텀에 대한 부정적 시각은 꽤 공감이 되는 내용들이었다.
이해하기 쉽게 커스텀은 수제, 양산형은 공장품과 같다고 볼 수 있을 것 같다. 수제의 경우 더 정교한 품질을 가질 수 있지만 장인들을 필요로 하고, (이 또한 시계나 가방 같은 경우가 해당된다) 양산품은 많은 양을 생성할 수 있고 인력을 공급하기 쉽다는 장점이 있다.
분명 수제가 더 좋은 품질을 가지는 섹션에서도 양산품에 대한 수요와 공급은 존재하므로, 개발에서 커스텀만을 고집하는 것도 아집일 수 있겠다라는 생각이 들었다. 이는 오픈소스의 시대 도래와도 맞아 떨어지는 시각이라고 생각한다.
1.2 다른 아키텍쳐를 가지는 프로세스들
발표 화자는 위와 같이 커스텀에 대한 이야기를 하면서, 발송 도메인의 프로세스들이 C++와 JAVA로 부분적 구현이 되어있고 C++로 구현된 프로세스들이 커스텀의 성격을 띈다고 공개하였다. 공개된 구조는 그림 1과 같다.
그림 1. 카카오 메세징 백엔드 서버 구조
그림 1의 붉은 색 절취선을 기준으로 왼쪽은 C++로 구현되었고, 서버들은 JAVA로 구성된 구조를 가지고 있었다.
여기서 C++의 기존 프로세스들을 언어를 변경하는 것에는 다음과 같은 이유들이 있었다고 한다.
- 회사 내 부족한 C++ 인력 자원
- 기존 C++로 개발되어 각 프로세스들이 독자적인 프로토콜을 가짐
- 진행하기 어려운 단위테스트
- 어플리케이션 간 강결합
결국 위와 같은 이유들로 인해 C++로 구성하여 가지고 있던 "커스텀"의 장점을 버리고 대중적으로 학습된 언어인 JAVA를 선택한 것이다.
위의 경우는 내가 다니고 있는 회사에서 이루어지는 JAVA 전환과도 상당히 유사한 사례인데,
1. 기존 성능에 민감한 프로세스들이 C로 개발이 되어있으며
2. 작은 단위의 프로세스들로 파편화 된 상태에서 강결합 되어있고
3. TCP를 기반으로 둔 독자적 프로토콜로 구성되어 있었다. 때문에 위의 사유들은 꽤나 공감이 가는 내용들이었다. 유입되는 개발자들은 상당수가 JAVA개발자들이며, 외부 프로세스들에서 비교적 통신하기 어려운 TCP로 구성되어있고, 특정 프로세스에 의존성을 가지는 파편화된 어플리케이션으로 구성되어 유지보수가 힘든 상태였다.
1.3 JAVA로의 전환
앞서 1.2 다른 아키텍쳐를 가지는 프로세스들의 JAVA전환 이유가 공감이 가는 내용이었기 때문에, 어떤 방식으로 전환을 진행했는지가 꽤나 기대 되는 상태에서 세미나를 시청했다.
1.3.1 영향도가 낮은 서비스부터
그들이 선택한 제 1전략은 "트래픽이 비교적 적고, 장애 영향도가 낮은 서비스부터" 였다.
해당 전략은 상당히 공감이 갔다. 전환시 부담이 적은 프로세스를 우선시하여 전환한다는 이야기로, 운영을 하는 입장에서는 상당히 합리적인 결정이라고 생각되었다. 또한 장애 영향도가 낮다는 것은 프로세스 중요성 외에도, 타 프로세스와의 결합도가 낮은 프로세스를 의미할 수 있겠다는 생각도 들었다.
이후에는 전환과 함께 어떤 부분들을 수정했는지에 대해 공유를 했는데,
- Asciidoc을 이용한 문서화
- inMemory -> redis를 통한 확장성 증대
- 독자적 프로토콜 -> HTTP 사용
등의 특이사항이 있었다. 이 때 jedis에서 무분별하게 세션을 형성하여 Lettuce로 라이브러리를 변경했다는 내용이 있었다.
1.3.2 발송 릴레이서버 개선
개인적으로는 해당 개선의 내용이 발표자료에서 가장 재미있었는데, 현재 업무상태에서 고려할 수 있는 부분들이 많아서 그랬던 것 같다.
그림2. 발송 릴레이 서버 개선 고민점
그림2의 내용중에서도, 가장 흥미로웠던 것은 코틀린을 도입하면서 쉽고 가독성이 높은 개발을 진행할 수 있었다는 경험이었다.
회사에서 업무를 진행하며 어려운 부분이 맡고 있는 프로세스가 해당 목차의 발송 릴레이서버와 같은 고성능을 요하는 프로세스이다보니 서비스 백엔드/프론트엔드 개발자들이 쉽게 접근하기가 어려웠다. (ex- TCP구성, MultiThreading) 프로세스의 특성상 구현이 어려워 가용 인적 자원이 많지 않다는 것이다.
이런 생각을 하다보니 발표에서 언급한 코틀린의 특성이 이러한 문제를 조금 상쇄시켜줄 수 있지 않을까?? 라는 생각이 들었다.
발표에서는 중요하게 다루지 않았지만, 그림2에 있는 coroutine의 적용 역시 어플리케이션 개발 난이도를 낮출 수 있다고 보여졌기 때문이다.
그렇다면 코틀린으로 개발했을 때 성능은 어떨까? 라는 의구심이 들 수 있는데, 카카오에서는 자세한 실험 파라미터는 공개하지 않았지만 그림 3과 같이 대략적인 벤치마크를 공개해주었다.
그림 3. 카카오 메세징 시스템의 C++, kotlin(g1gc), kotlin(zgc)의 성능 벤치마크
2. 느낀점
발표를 듣고 나서 느낀점들이 꽤나 많았다.
먼저 가장 흥미로웠던 부분은 이전부터 고민해왔던 특정 프로젝트의 개발난이도를 언어를 변경하므로서 개선할 수도 있겠다라는 생각을 하게 되었다는 점이고, (언어의 러닝커브도 있겠지만, 이점이 많다면 학습할 수 있다고 생각되었다) 성능뿐만이 아닌 인적 자원을 기준으로 둔 개발도 필요하다라는 관점을 얻게 되었다.
또한 JAVA의 Garbage Collector에 따른 성능차이는 크게 신경쓰지 않았는데, 이를 계기로 한번 확인해보면 좋을 것 같다는 생각을 하게되었다.
앞으로의 개선에 이 발표가 큰 도움이 될 것이라고 생각하며, 발표자에게 감사의 인사를 전하고 싶다. 👍
