2024 카카오 컨퍼런스 3일차 참석 간단한 내용 정리

참여한 세션

• 10 : 00 ~ 12 : 00
  AI financial Tech
  AI Life Tech
• 13 : 00 ~ 14 : 00
  카카오 서비스들은 어떻게 CI/CD 를 하는가?
• 14 : 00 ~ 15 : 00
  모두를 위한 게임 데이터 검색 시스템
• 15 : 00 ~ 16 : 00
  GraalVM 도입으로 JVM 백엔드 애플리케이션의 구동 초기 성능 문제 해결하기
• 16 : 00 ~ 17: 00
  카카오페이는 어떻게 수천만 결제를 처리할까? 우아한 결제 분산락 노하우
• 17 : 00 ~ 18 : 00
  카카오 빌링 MySQL DB 샤딩 적용

필수 참여

1) AI financial Tech
패널톡 : 카카오뱅크, 카카오클라우드, 카카오페이
  카카오 뱅크 : 보험 분석 관련 인공지능 발전 상황 공유
  카카오 클라우드 : 카카오 클라우드의 소개, 인공지능 오피스 플랫폼 Koworker(2025년 공개예정)
  카카오 페이 : AI를 활용한 비정상 거래 단속, 개선 상황 공유

 

2) AI Life Tech
패널톡 : 카카오헬스케어, 카카오모빌리티, 카카오페이지
  카카오 헬스케어 : 인공지능 혈당관리 솔루션 파스타
  카카오 모빌리티 : 자율주행 택시 현황, 브링(Bring) : 커뮤니티 내부 배달 로봇
  카카오 페이지 : 사람 제작 웹툰 소개 쇼츠 vs AI 제작 비교, 장점 소개

 

→ 각 회사의 현재 기술 성과를 공유하고 Q&A, 추후 성과 공개

개인적으로 참여한 세션

1. 카카오 서비스들은 어떻게 CI/CD 를 하는가?

→ 다양한 쿠버네티스 환경, 각 서비스 별로 배포 절차가 다르고 사용하는 플랫폼이 달라 문제 발생

 

문제점 :

 - 배포 시 학습 곡선 등 비용이 발생
 - 서버 리소스 낭비

 

대안

Kargo, 카카오 자체 CI/CD 솔루션

 

Kargo의 4가지 설계 원칙

 

1)중앙화 :
공통 kubeconfig 설정 및 해당 키를 서비스에 공유한 후 배포 절차 수행

→ 통일된 CICD 절차 구축을 통한 리소스 최소화

 

2) 깃 옵스 : 파이프라인 자동화를 통해 배포 부담 감소

 

3) 무설치 : K8s Job을 통한 상태, 히스토리 관리

 

4) MSA : 컴포넌트를 최대한 분리해 안정성 확보

2. 모두를 위한 게임 데이터 검색 시스템 :
로그 데이터 검색 시 보다 효율적이고 빠른 검색을 위한 검색 시스템 도입기

시행착오
- 쿼리 빌더를 사용한 SQL 쿼리 작성 후 검색
→ 사용할 수 있는 쿼리가 제한적이고, 사용자(마케팅 팀 등)이 SQL을 알아야됨

 

- 쿼리 템플릿 : 사용자가 기존에 생성된 SQL 쿼리 선택 후 검색
→ 질문 정형화로 인한 효율 감소

 

도입 : LLM 자연어 검색 시스템

 

도입 간 발생한 문제
할루시네이션 : AI의 엉뚱한 대답
→ 로그 데이터를 특성별로 분해

ex) 게임을 “3개월째” 접속하지 “않은” 회원

 

→ 분해한 데이터를 벡터 DB에 저장하여 할루시네이션 개선

3. GraalVM 도입으로 JVM 백엔드 애플리케이션의 구동 초기 성능 문제 해결하기

자바 애플리케이션 구동 시 핫스팟 VM과 GraalVM 비교
다양한 측면에서 비교했지만, GraalVM이 항상 우수하지 않다

 

결론 :

초기 가동시에는 속도가 빠르지만, 구동 이후 일정 시점부터 핫스팟VM보다 느리거나 비슷한 속도를 보인다

4.카카오페이는 어떻게 수천만 결제를 처리할까? 우아한 결제 분산락 노하우

사용자 - 계좌 - 은행 구조로 된 결제 구조에서, 사용자와 은행이 동시에 계좌와 통신하는 경우
→ 동시성 통신을 하면 계좌 잔액이 꼬이게 된다.

→ 락의 필요성 대두 : 어느 한 쪽의 거래가 진행되는 동안, 다른 쪽의 거래는 락을 걸어 막는다.

 

다만, 속도가 매우 느려지게 된다

 

분산락 구현
Redis를 사용한 분산락 구현 : Redission ~ 레디스 분산락
Spring AOP를 이용해 구현 ~ 코드는 추후 공개되는 영상에 첨부됨
Spring AOP를 통하면 불필요한 락이 약 1초가 더 발생하지만, 거래가 천만건이면 그만큼 더 느려진다

 

함수형 프로그래밍을 사용한 구현
cf) 주로 코드를 보여준 세션이어서 추후 세션에서 보다 자세한 내용이 확인 가능합니다.

5. 카카오 빌링 MySQL DB 샤딩 적용

카카오 빌링 서비스는 PG사의 앞단에서. 서비스와 ERP 사이 데이터를 처리하는 일을 한다

 

→ 외부 인터페이스가 많고, 민감정보 취급, 규제 및 감사가 많다 ~ 작업의 난이도가 높다

 

결제 건수가 증가하는 가운데 모든 데이터를 빌링DB 하나에서만 처리했던 기존 구조

 

→ 2021년 빼뺴로 데이에 DB 다운

 

용량 부족
하나의 서비스에서 장애 발생 시, 다른 서비스도 같은 빌링 DB를 사용하므로 장애 전파

 

대안 : 샤딩

→ 해시 기반 샤딩, 범위 기반 샤딩을 애플리케이션 레벨에서 구현

 

문제점 :

샤딩 후 데이터 재배치

 

대응:

기존 Auto Increment PK값을 기반으로 샤딩 진행

PK 특정 자리 수 까지 샤딩 구분에 필요한 값 설정

 

아파치 샤딩 스피어 프록시를 활용해 어드민 변경 최소화
동적 샤딩 : 특정 이벤트(장애, 서비스 간 트래픽 차이 발생 등) 발생 시
샤드를 할당