티스토리 뷰
카카오에서 기술 컨퍼런스가 열려서 구경갔다. 온라인이고 발표자료와 영상까지 무료로 공유해주는게 역시 대기업 답다.
온라인 컨퍼런스를 관람하면서 신기했던 것과 유익했던 것 몇 가지를 정리, 공유하고자 한다.
if(kakao)dev2022
함께 나아가는 더 나은 세상
if.kakao.com
지난 발표영상은 유튜브에서 볼 수 있다.
https://www.youtube.com/@kakaotech
kakao tech
더 나은 세상을 만드는 카카오 테크
www.youtube.com
# 10.15 카카오 데이터센터 화재 - 장애
이번년도 핫한 IT 이슈 중 하나였을 카카오 대규모 서비스 장애에 대해 원인을 분석하고, 기술적으로 재발방지를 위해 어떻게 개선했는지 설명한다.
https://www.youtube.com/watch?v=v4hRiooY7Dw&list=PLwe9WEhzDhwG1BfKSLBhNd6wrpnWRC9Dg&index=4
장애 복구가 늦어진 이유
1. 데이터센터 간의 이중화 미흡
- 판교 데이터센터 내부는 이중화가 잘 되어있었지만, 그렇지 않은 서비스들은 이중화가 미흡했다.
2. 운영관리, 모니터링 도구의 이중화 미흡
- 화재 여파로 컨테이너 관리 도구를 사용할 수 없자, 복구에 시간이 더 소요되게 됨
3. 이중화 전환후 가용 자원 부족
- 판교 데이터센터에 오는 트래픽 전체를 가담할 자원이 부족해서, 결국 판교 데이터센터가 다시 재가동되어야만 했다
4. 위기대응 인력, 자원 부족
- 위기대응을 할 인력적 자원(경력자)가 부족했다.
5. 커뮤니케이션 혼선
- 카카오 내부적으로 커뮤티케이션 툴로 카카오톡 카카오워크를 사용하는데, 이를 못 씀
요약하자면 이중화가 되어있긴 했는데, 미흡했고 이런 대규모 장애를 대응할 인적/물적 자원이 부족했다고 한다.
중앙화된 서비스가 먹통이 되자, 그 여파가 상당했는데 이번 기회로 블록체인의 탈중앙화에 대해서 뭔가 다시 한 번 생각해보는 계기가 되었다.
# Day 2 - Docker Swarm 기반 Redis Saas 플랫폼 구축 사례
https://www.youtube.com/watch?v=-GsWFaQg6Q0&list=PLwe9WEhzDhwH5tt1WKAR4sXQHag02lvG3&index=13
카카오 사내에서 사용하는 Redis Saas 플랫폼 구축 사례에 대해서 설명해주신다.
대기업은 이런 인프라 팀이 있는게 좋은 것 같다. Redis Saas 플랫폼은 쉽게 말해서 카카오 사내 개발자들이 Redis를 사용하기 쉽게 하기위해서 Redis를 만들어주고, 관리해주고, 할당해주고 하는 또 하나의 작은(?) Redis 서비스를 만든 것이다.
이를 통해 Redis 세팅을 모르는 개발자라도 웹 인터페이스를 통해 안전하고 효율적으로 Redis를 사용할 수 있다.
AWS EC2의 Redis, 카카오 사내 버전이라고 생각하면 될 거 같다.
이를 관리하기위해 Redismon이라는 모니터링 툴도 자체 개발했다고 한다. (역시 카카오)
오케스트레이션 도구로 Docker Swarm과 k8s를 고민했다고 하셨는데,
세팅이 쉽고 러닝커브가 적은 Docker Swarm을 채택 했다고 한다. 나중에 도입하게 될 경우가 생기면 참고해야겠다.
개인적으로 Redis Saas를 AWS 처럼 온디멘드 형식으로 외부에도 공개하면 좋겠다라는... 생각을 하면서 관람했다.
(나도 카카오가 관리해주는 Redis 쓰고 싶어!!)
# Day 2 - 카카오톡 메시징 시스템 재건축 이야기: C++ 서버를 Java및 Kotlin으로
https://www.youtube.com/watch?v=_Of8e0o6u3U&list=PLwe9WEhzDhwH5tt1WKAR4sXQHag02lvG3&index=14
카카오톡 메시징 시스템을 점차 Kotlin으로 컨버팅해가는 과정을 설명한 세션이다.
카카오톡 메시징 서버 시스템은 초기에 Ruby로 작성되어 있었다고 한다.
그러다가 2011년, 겁나 빠른 황소 프로젝트 (이름이... 참 웃기다...)를 통해 C++, Java로 변경했다고 한다.
C++를 도입하면서 성능이 대폭 향상되었지만, 이를 유지보수할 개발자를 시장에서 찾기 어려워서 Java로 변경해 가는 추세였는데, Java보단 Kotlin이 더 생산성이 좋아서 Kotlin으로 컨버팅을 진행하고 있다고 한다.
트래픽이 낮은 서버들 부터 변경을 진행했다고 한다. 카카오톡 그 작은 앱 뒤에는 정말 어마무시한 서버 시스템이 자리잡고 있다.
메시지 시스템이다 보니 C++를 채택할 만큼 성능이 중요한데, JVM GC에 관한 성능저하가 역시 걸림돌이었나 보다.
그래서 zgc라는걸 사용하고 개선하다 보니 위 표처럼 C++ 서버처럼 성능이 굉장히 비슷해졌다고 한다.
Java도 JIT 컴파일러 덕분에 "Java는 느리다!"라는 프레임을 어느정도 벗어날 수 있게 됐듯이, Kotlin도 JVM언어라 해서 성능이 컴파일 로우레벨 언어보다 막 엄청 떨어지진 않는 듯 하다.
Kotlin을 도입하므로써 기존 코드를 절반(!!!)가량 줄일 수 있었다고 한다.
역시 Kotlin이 한국 스프링 시장의 미래라는 걸 다시 한 번 체감했다.
# Day 3 - WebRTC 기반 게임 리모트 플레이: 실시간 커뮤니케이션 서비스를 위한 WebRTC
https://www.youtube.com/watch?v=8jryUH6xmjU&list=PLwe9WEhzDhwHb4uC0WGHw0cU4gRDUt71X&index=43
WebRTC라는 기술을 사용해서 게임 리모트 플레이를 구현하는 과정을 설명하는 세션이다.
게임 리모트 플레이란? 쉽게 말해 저사양 컴퓨터에서 고사양 게임을 돌릴 수 있게 해주는 기술이다.
요즘 소켓 관련 기술에 관심이 있어서 봐봤는데, 역시 좀 어렵다.
WebRTC처럼 뭔가 네트워크와 관련된 기술에 요즘 흥미가 가는 것 같다.
게임 관련 기술의 난이도는 최상이라는 것을 이번에 또 한번 느낄 수 있었다.
여담이지만 하이퍼커넥트의 아자르가 이 WebRTC로 구현되어 있다고 한다.
# Day 3 - JVM warm up
https://www.youtube.com/watch?v=CQi3SS2YspY&list=PLwe9WEhzDhwHb4uC0WGHw0cU4gRDUt71X&index=44
JIT 컴파일러의 역할
바이트코드를 기계어로 번역하는 과정에서 이미 한 번 번역된 바이트코드를 캐싱하여 다시 번역할 필요 없이 가져다 써서 성능을 향상시키는 컴파일러 (DP와 비슷하다.)
JIT 컴파일러를 활용해서 성능 향상을 보려면, 기계어가 캐싱되어야 하는데 어플리케이션 시작후에는 캐싱된 데이터가 없어서 느리다고 한다.
이를 해결하기 위해 어플리케이션 시작 후 의도적으로 로직을 수행하여 성능이 나오도록 하는 warm up 과정에 대해 설명하는 세션이다.
해당 발표자분은 카카오모빌리티 계정 서비스 서버 백엔드 개발자이신데, 서비스 배포시 초기 응답 레이턴시가 낮게 나오는 현상을 해결하기 위해서 JIT 컴파일러와 warm up을 도입했다고 했다.
역시 개발자에게 안 되는 건 없는 것 같다. (그리고 극한의 성능 향상을 좋아하는 것 같다.)
# 그 외에
한국어를 SQL로 번역하는 ML 모델을 개발중이라고 한다.
모델이름은 RYANSQL이다. 딥러닝이 정말 IT 최첨단 기술의 최외각인 것 같아서 너무 멋있고 신기했다.
이 밖에도 엄청 유익한 세션들이 많았으니 시간 투자해서 직접 보는 것도 좋을 것 같다!