if(kakakoAI) 2024

if(kakao AI) 2024

AI Finance Tech (정규돈, 김동용, 신재홍, 이어형)

• 카카오 정규돈, 카카오뱅크 신재홍, 카카오페이 김동용, 카카오엔터프라이즈 이어형

카카오뱅크의 AI Ecosystem - CTO 신재홍

• 카카오뱅크의 AI 혁신 적용
  • 신분증 OCR, 영상통화 안면인식 등 AI 적용
  • FDS 속도 최대 10배 향상
    • FDS XAI 가속화 알고리즘 적용
  • 무자각 인증, 안면 위변조탐지기술 적용
  • 금융특화 언어모델 개발 > 고객센터 챗봇 적용
• AI infra
  • GPU 와 같은 고성능 시스템 인프라 구축
  • MLOps 구축하여 AI 모델의 생애주기 관리
• AI Division
  • AI 사업 & 기술 총괄 부서 창설
  • 자체 AI 서비스 개발
  • AI 경영시스템 국제 표준 & 건버넌스 관리
• AI Product
  • AI Hub 를 통해 임직원 역량 강화
  • AI 품질 자체 검증
• AI 통해서 고객의 우수한 경험과 안정성을 보장하고자 한다.

카카오페이의 AI, 신뢰할 수 있는 금융 파트너 - CTO 김동용

• 카카오페이는 거래수와 거래액 지속적인 성장
• AI 를 통해 고객의 자산 보호, 신뢰성 제공
• FDS / ADS 를 통해서 고객 서비스 안정성 제공
  • 높은 성능의 탐지 기능이 필요한 FDS 서비스르 AI 를 활용하여 자체 서비스 개발하는 듯
• 금융 비서를 통해서 금융 데이터를 수집하고 정보 제공
  • MoE : Mixture of Experts
  • 사용자가 필요로 하는 전문가는 선택하여 서비스 제공
• 보험 진단 서비스
  • 보험진단AI 를 통해서 고객 정보를 수집하여 필요한 보험 추천 / 서비스 제공
• 카카오페이를 모든 금융 서비스의 중심으로 만들고, AI 기술을 통해 안정성을 보장하고자 한다.

카카오엔터프라이즈, Beyond the Cloud - CTO 이어형

• 카카오클라우드 소개
  • 후발주자이지만, 기존 서비스의 단점을 보완
• 카카오클라우드의 성능은 해외 클라우드 서비스랑 비슷하고, 국내 서비스보다는 높은 성능 자랑
• AMD 고집적 서버 개발을 통해 고성능 VM 안정적인 서비스 제공
• Xilinx 네트워크 가속화 하드를 통해 높은 성능의 VM 서비스 제공
• Multi AZ 구성을 통해 안정적인 서비스 제공
  • 다른 클라우드와도 손쉽게 연동 가능: 고성능 네트워크 기반이기에 가능한 듯
• 금융기관의 private cloud 나 on-premise 환경과도 높은 네트워크 성능 보장
• ISO, CASP, ISMS 안정성 평가 완료

패널톡 Q&A

• 카카오페이 - FDS, ADS와 Adaptive ML
  • 모든 사람을 타켓팅하여 검사하는 것이 아니라 정밀도를 높여서 정확한 타켓을 선정하고 검사하도록 Role 과 ML 를 적절하게 섞어서 탐지 서비스 구축
  • 금융 서비스 특성상 실시간으로 데이터가 변화하기 때문에, Batch 의 실행 주기가 거의 realtime 수준으로 짧은 주기가 될 수 있다.
• 카카오페이 - 금융비서와 MoE
  • 전문 분야의 AI를 별도로 구성하여 LLM 관리
  • 금융 전문가의 데이터를 전체적으로 정리하고 LLM 학습
• 카카오뱅크 - GenAI 가드레일
  • GenAI 를 보호하는 기술적인 장치
  • 부적절한 컨텐츠가 LLM 에 인입되는 것을 방어
  • LLM 의 잘못된 답변 필터링
  • 여러가지 자체 컴포넌트를 통해서 기술적으로 LLM 가드레일 개발
• 카카오뱅크 - XAI
  • 금융 서비스 특성상 XAI 의 필요성 높아지고 있다.
• 카카오뱅크 - LLM
  • 금융혁신기술 통해서 LLM 적용 가능
• 카카오엔터프라이즈 - 고성능 VM
  • VM 생성 시 발생할 수 있는 CPU 경합 문제로 성능에 대한 고민 끝에 AMD 협업을 통해 고성능 VM 제공
  • 해외 클라우드 서비스와의 경쟁력을 위해 하드웨어 연구 개발에 더 집중
• 카카오엔터프라이즈 - Sovereign Cloud
  • 다양한 서비스를 벤치마킹하여 경쟁력을 키우고 있다.

마무리

• 카카오페이 - AI가 나오므로 개발자로서는 코딩보다는 시스템 아키텍처로서의 역할이 커질 것 같다.
• 카카오뱅크 - 금융 도메인에서 AI 기술을 초기 단계이지만, 카카오뱅크는 혁신적이 서비스 개발 예정이다.
• 카카오엔터프라이즈 - 카카오클라우드 기억해주세요.

---

AI Life Tech (정규돈, 김기범, 장성욱, 유창국)

카카오엔터테이먼트 - CTO 김기범

• Persona 페르소나를 아티스트들에게 어떤 영향을 줄 수 있을지 함께 고민
• 멜론 : 생성형 AI를 통해 고객을 이해하고, 노래 추천할 수 있도록 개발 진행
• 웹툰 : AI 를 통해 Shorts, 번역 등 다양한 서비스를 개발 진행

카카오모빌리티, 일상 속 AI Device - 미래이동연구소장 장성욱

• AI 기반의 자율주행, 로보틱스 서비스 소개
• 자율주행 서비스
  • 태스트 관리, 디지털맵, 관제시스템 및 운영 노하우, 데이터와 알고리즘 4가지 기준으로 AI 서비스 접목하여 개발 집중
  • Edge case 데이터 취득 및 활용
    • 수많은 데이터를 수집하고, 사진 합성을 통해 다양한 케이스를 활용하여 AI 학습 진행
    • 차량 인프라 > 데이터 처리 > AI 학습 > OTA 차량 적용
• 서비스 로봇
  • 한개의 로봇으로 다양한 배달 서비스를 제공

카카오헬스케어, 모두를 건강하게 - CTO 유창국

• 많은 경험의 문제를 해결하자. 고객의 경험을 드라마틱하게 바꿔보자.
• Pasta 서비스
  • 라이프 레시피를 제공하는 서비스
  • 생활 습관을 바꾸기 위한 라이프 레시피를 추천
  • “귀찮음을 편리함으로” 바꿔서 잔소리를 나이스하게 하는 헬스케어앱으로 발전
  • 사진을 촬영하면 AI 를 통해서 자동으로 식단 기록
  • 음성을 통해서 자동 생활 기록
  • 챗봇을 통해서 질의 답변 처리
• AI 를 통해서 헬스케어앱의 접근성을 높이도록 노력하였다.

패널톡 Q&A

• 카카오엔터테인먼트 - 카카오엔터테인먼트 IP
  • 카카오엔터테인먼트의 수많은 아티스트들의 IP에 대해서는 저작권 규제로 인한 시기 상조
• 카카오엔터테인먼트 - Helix Shorts
  • 3주 > 3시간 작업으로 단축하여 사람의 일하는 방식과 삶의 변화에 큰 영향
  • 하이엔드 작업은 사람이 하지만, 간단한 제공 서비스를 AI 작업으로 전환
  • LLM 발전을 가정하고, LLM 활용을 잘하는 방법에 집중
• 카카오엔터테인먼트 - 캐릭터 페르소나
  • 버츄얼 아이돌이 노래도 하고, 팬들과 소통도 하는 캐릭터를 AI 로 개발
• 카카오모빌리티 - 자율주행
  • 서울에서 상용 중인 자율주행 택시에 대한 이용률과 재이용률 향상
  • 세이프티 드라이버가 동반 탑승
  • 자율주행 기술에 대한 이해도와 함께 AI 적용으로 개발 발전 예정
  • 해외 업체와는 경쟁사보다는 협력사로 발전 예정
• 카카오모빌리티 - 서비스로봇 브링
  • 현재는 실내 위주로 서비스하지만, 실외도 준비중
• 카카오헬스케어 - Seamless한 경험 제공
  • 파트너사 협업을 통해 혈당 데이터 수집을 통해 물리적인 디바이스를 통해 헬스케어앱으로 바로 데이터 수집 가능
• 카카오헬스케어 - 파스타 인사이트

---

대용량 트래픽 아니면 안보셔도 됩니다! 선물하기 서비스 캐싱 전략 (카카오 - 이희관, 이세희)

• 개선 배경
  • 평시 기준 10배, 이벤트 기간 기준 3배의 트래픽으로 서비스 장애 발생
  • 조회 성능을 위해 캐시를 적용
  • 캐시 데이터 만료되는 경우, 그대로 트래픽이 다른 서비스로 흘러가는 현상 발생 > Cache Stampede
  • Cache Stampede 방지 전략
    • TTL 증가
      • 상품 정보인 경우 캐시 TTL 길다면, 사용자 경험 저하
    • 만료 캐시 갱신 처리 로직 분산락 사용
      • 하나의 캐시 갱신 처리만 처리될 수 있도록 분산락 사용
      • 하지만, 다른 요청은 응답 지연 발생
    • 캐시 WarmUp
      • 별도의 Batch 를 통해서 캐시가 만료되기 전에 캐시를 미리 갱신
      • 1분 주기의 Batch 를 통해서 상품정보를 자동 갱신
      • 캐시 서버 IO 로 인한 지연 발생
      • 캐시 웜업 서버 목록 누락으로 Cache Stampede 발생
• Hybrid Cache
  • 개인화 데이터가 아니고, 업데이트 빈도가 낮고, 데이터 크기가 작고, 조회 키 범위가 낮은 캐시 정보는 로컬 캐싱 처리
  • 로컬 캐시인 경우, 자주 사용하는 데이터를 캐싱 처리
  • 글로벌 캐시인 경우, 최신 상태 데이터 저장, 캐시 데이터 중앙 관리 형태로 사용
  • 로컬 캐시에 데이터가 있는 경우, 글로벌 캐시 조회 하지 않음
  • 하이브리드 캐시는 네트워크 비용 감소 효과
  • 데이터의 일관성 보장 문제 해결
    • Zookeeper 활용
      • 서버 간의 동기화를 위한 분산 오케스트레이션(?)
      • Watch 기능을 이용해 서버 변경 이벤트 감지
      • 변경된 timestamp 를 key 로 Zookeeper 노드 관리
• Auto Cache WarmUp
  • 캐시 데이터 변경 누락을 방지하기 위한 전략
  • PER 알고리즘 : 일정 시간이 지나면 캐시가 스스로 갱신하는 알고리즘
    • 캐시 갱신 여부가 캐시 만료되기 전 요청에 대한 의존성 문제
      • 요청되지 않는거나, 중복 요청인 경우 캐시 갱신 비용으로 지연 발생
    • 캐시 갱신 시간이 유동적인 문제
  • 캐시 웜업 자동화 방식
    • HOT 프로모션 상품의 페이지를 자동 캐시 웜업 적용
    • HOT Promotion Collector: 회원이 자주 요청하는 페이지 조회 요청의 ID 값을 이용하여 HOT 프로모션 상품을 타켓팅
    • 원격 저장소, 인메모리 저장소, 자원 리소스 => 레디스 선택 사유
    • SortedSet 사용하여 HOT 프로모션 페이지 랭킹 저장
    • Key Swap 방지를 위해 시간대 별로 페이지 ID 별 호출 건수 Hash 캐시 저장
    • 가중치를 계산하여 HOT 프로모션 상품 자동 캐시 웜업 우선순위 결정
    • 레디스 부하 분산을 위해 로컬캐시 활용
      • 로컬 캐시에 임시 데이터 저장
      • 임시 데이터틀 HOT 프로모션 콜렉터로 전달
      • HOT 프로모션 컬렉터에서 레디스로 캐싱 처리
• 초 단위 Cache WarmUp
  • 캐시 웜업 1분 단위에서 초 단위로 변경 전략
  • 초 단위 트리거를 RabbitMQ 활용
    • RabbitMQ 메시지 처리가 강력한 브로커로, Dead-Letter Queue 활용하여 초 단위 트리거 전략
    • 발행된 메시지를 1초 뒤에 만료되게 하여 DL Queue 로 전달하면 DL 컨슈머에서 메시지 처리 전략

No Silver Bullet!

• 정답은 없지만, 문제 해결을 위한 고민과 노력으로 정답을 찾는 것이 중요하다

---

카프카, KRaft를 만나다: 주키퍼 없이 운영하는 카프카의 실전 운영 노하우 (카카오 - 심현준)

• 개선 배경
  • KRaft 버전 3.3.1 > 3.8.0
  • KRaft 모델 클러스터 준비 계획
• 주키퍼 없는 카프카
  • Zookeeper Ensemble & Kafka Cluster 를 별도 인프라 구성하여 관리
  • 주키퍼의 한계
    • 카프카 내부 네트워크 이슈로 데이터 적합성 꺠지는 현상 발생
    • 주키퍼와 카프카 연결 네트워크 이슈 발생
  • KRaft Mode
    • Raft 알고리즘으로 분산 오케스트레이션 가능한 Kafka 관리 모드
    • 카프카 클러스터 안에서 분산 처리 가능
      • 네트워크 이슈 해결 가능
    • 신속한 컨트롤러 장애 조치 가능
      • 주키퍼 대비 월등한 복구 속도 제공
• 구성 과정
  • Dev 1년 정도 실험 거쳐 CBT 테스트 후 PRD 배포
  • 주키퍼 기반 설정 > KRaft 기반 설정 변경
  • kafka-ui, kminion 관리 도구 변경
    • 관리 도구 네트워크 지연 감소
  • kafka 내부 버그 이슈로 1년 정도 Dev 에서만 사용
• 발전 과정
  • 벤치마크 & 워크로드 도구 : trogdor
  • 카프카 모니터링 : jmx-?
  • 안정성 테스트
    • Trogdor 로 극심한 부하 유발
    • 파워플러그 & 네트워크 단절 복구 케이스별 성능 테스트 진행
  • 벤치마크 테스트

---

안정성과 유연성을 겸비한 카카오뱅크의 On-Premise Kubernates 구축 여정기 (카카오뱅크 - 김동현)

• 카카오뱅크의 쿠버네티스
  • 2023년 온프레미스 쿠버네티스 환경 구축 > k17s
  • 경영(비금융) 지원망 / 금융 운영망
    • 네트워크 구간별 분리된 많은 클러스터 존재
  • Helm을 이용한 IaC
    • Infra as 쿠버네티스 관리 시작
    • Helm 차트를 만들어서 쿠버네티스 관리
  • 프로비저닝 도구
    • hele 차트를 통해 새로운 클러스터를 생성하고 설정 파일은 yaml 파일로 관리
    • 아르고 도구를 통해서 클러스터 모니터링
    • ClusterAPI
      • 클러스터 프로비저닝 도구 활용
      • 클러스터 노드 증설 등 관리 API 제공
    • Multiple Machine Provider
    • Helm 차크를 표준 환경에 맞춘 표준 패키지로 구성
  • GitLab + Argo CD + k8s 기반 CI/CD 환경 구축
  • 네트워크 장치 또한 쿠버네티스 기반으로 설정 조작하도록 환경 구성
• 금융 컴플라이언스와 보안
  • 전자금융감독규정 컴플라이언스 준수 운영 필요
  • Kyverno 기반 Admission Controller
    • kubectl 요청 시, kube-apiserver 에서 인증/검증 단계를 통해 webhook 을 통해 명령어를 검사
  • Cilium 기반 Network Security
    • 쿠버네티스 네트워크 정책보다 Ciliumn 네트워크 정책 넓음 범위 제공
  • Packer, Ansible 기반 쿠버네티스 클러스터 관리
    • 클러스터 파이프라인을 통해 노드 취약점 등 컴플라이언스 취약점 조치
    • 신속한 쿠버네티스 클러스터를 생성 가능
  • Hikube 기반 접근 제어
    • 클러스터 접근 권한 제어
• 앞으로의 계획

---

지연이체 서비스 개발기: 은행 점검 시간 끝나면 송금해 드릴게요! (카카오페이 - 박소현)

• 레거시 시스템 > 신규 아키텍처 시스템 적용 경험 공유
• 카카오페이 지연이체 서비스
  • 은행 점검 시간 이후 송금하도록 지연 이체 서비스 제공
  • 메시지 큐 인프라 변경 RabbitMQ > Kafka (전사적인 메시지 브로커를 카프카로만 사용하겠다고 공지!!)
• New 아키텍처 찾아서
  • 지연이체 서비스 유지된 채 새로운 아키텍처 적용
  • 각기 다른 은행 점검 시간에 맞춰서 지연 이체 처리 필요
  • 은행 점검 시간 기준으로 5분마다 Batch 수행으로 송금 실행 예상 시간에 이체 처리
  • 한번에 5천건이 넘는 이체 처리 필요
  • 스케쥴러 갯수를 늘리면 데이터 중복 발생하고, 백단 서비스 서버 부하 발생
  • 카프카 적용으로 문제 해결!
    • 스케쥴러에서 카프카로 지연이체 요청 발행
    • 메시지 수신하여 지연 이체 처리
    • 하지만,
      • 처리 지연으로 카프카로 같은 데이터가 메시지로 발행 문제 발생
      • 같은 데이터가 중복 발행된 메시지가 다른 컨슈머에서 처리 가능 문제 발생
    • 같은 데이터의 중복 메시지 문제 해결을 위해 레디스 기반 글로벌 분산락 사용하여 문제 해결!
      • 하지만, 분산락으로 발생하는 송금 실패 다수 발견
    • 같은 고객의 데이터의 중복 메시지는 같은 컨슈머에서 처리하도록 설계
      • 스케쥴러에서 카프카로 발행 전 레코드 값에 고객 정보를 추가하여 동일한 파티션으로 메시지 분류되어 컨슘 처리
• 릴리즈 해프닝과 빠른 롤백
  • 지연 이체 시스템 배포 후 20분 예상 시간 > 70분으로 증가하는 이슈 발생
    • 기존 시스템 > Zuul Proxy > 신규 시스템 으로 가도록 하는 아키텍처를 통해서 빠른 롤백 처리 가능
  • 컨슈머 단일 데이터 처리로 인한 처리 성능 지연 발생 원인!
    • 파티션 또는 컨슈머 갯수 조정하는 것은 무의미
    • 컨슈머의 동시 처리 기능을 추가한다고 하더라도 파티션 갯수 때문에 무의미
    • 컨슈머에서 비동기 처리 기능을 추가하기 하더라도 단건 메시지 처리 방식 때문에 무의미
• 실행 속도 부스트업하기
  • 컨슈머 대수를 2대 > 3대 증설
  • 컨슈머에서 Batch Size 만큼 다건 메시지 처리하도록 개선
  • 다건 메시지 수신하여 멀티-스레딩 병렬 처리
  • 처리량 800% 증가, 실행 속도 8배 향상
• 아키텍처 설계 시
  • 중복 데이터 발생
  • 동시 처리 발생
  • 롤백 전략
  • 성능 최적화

---

카카오페이는 어떻게 수천만 결제를 처리할까? 우아한 결제 분산락 노하우 (카카포페이 - 양세열)

• 매년 10억 넘는 결제 트랜잭션 처리
• 피할 수 없는 동시성 이슈
  • 공유되는 자원을 접근하고 처리 시스템을 고질적인 이슈: 동시성
  • Lost Update 이슈 발생
• 동시성 이슈 해결사! 분산락
  • DB 락으로만 해결하기 위해서는 무리가 있으며, 분산락 적용 추천
  • 분산 락: 분산된 여러 시스템이 하나의 공유 자원을 안전하게 접근할 수 있도록 락 처리
  • 먼저 락을 획득한 시스템 외 다른 시스템의 요청은 락 대기 상태 후 락 획득하고 서비스 기능 처리
  • 동시 들어오는 요청을 순차적으로 처리하면서 Lost Update 이슈 해결 가능
• 카카오페이의 분산락 적용
  • 하나의 서비스 로직 처리에도 여러 개의 분산락을 정의하여 관리
• 일반적인 분산락
  • 스프링 AOP 활용한 분산락 처리
    • 마킹 애노테이션 + 분산락 Aspect + 적용 메서드
  • AOP 분산락의 불편한 점
    • 적용 여부 확인
      • 컴파일 타임 체크 안되기 때문에 런타임 시 에러 발견
      • private 함수에는 분산락 적용 불가
    • Key 파라미터 적용
      • SpringEL 이기 떄문에 key 파라미터 설정 파악이 어려움
    • 락 장시간 점유 성능 저하
      • 메서드 전체에 락이 필요 없는 경우, 전체 메서드 락 적용으로 성능 저하 가능
    • 기능 수정 및 리팩토링 어려움
      • 파라미터 순서가 달라지거나 하면 장애 발생 가능
• 우아한 분산락 노하우
  • 함수형 프로그래밍을 활용한 우아한 분산락 전략
  • 분산락 데코레이션 함수를 활용!
    • redissonClient 를 사용하여 락할 수 있는 별도 함수를 정의
    • 분산락이 필요한 기능별 데코레이션 함수 개발 필요
  • 애노테이션으로 함수 전체 락 설정이 아니기 때문에 함수 내 락이 필요한 영역만 락 가능!
• 우아한 분산락 개발을 통해 성능과 유지보수성을 모두 잡을 수 있었던 좋은 경험이었다.

---

카카오 빌링 MySQL DB 샤딩 적용 (카카오 - 권세원)

• 카카오빌링 소개
  • 빌링: 마트의 계산대의 역할
    • PG 연동하는 시스템
  • 외부 시스템 연동 인터페이스 많다.
  • 금융 관련 민감 정보가 많다.
  • 규제/감사 많다.
  • 강성 클레임이 많다.
  • 2024년 망분리/대통합 시기
  • 2013년 부터 성장하는 시스템과 빌링DB 방대한 데이터 축적
• 해결 해야 할 문제
  • DB 용량 문제
  • 장애발생/전파 문제
  • 2021 빼빼로데이 전까지 페이와 커머스에서만 발생하던 장애가 … 어느 순간 발전해서 빌링만 장애 발생 ㅠㅠ
• 삽질스토리
  • DB 용량 문제를 위해 샤딩 처리로 해결 계획
  • DB 서버 1대 > 12대 증설
  • 서비스군 별로 DB 서버 분배 처리
  • MySQL DB 샤딩
    • 고급 솔루션 사용?
      • 운용 경험 없고, 다른 장애 발생 가능, 기존 시스템 변경 규모 예측 불가, 장기간 테스트 필요
    • 애플리케이션 레벨 샤딩 구현?
      • 샤드키 필요, 샤딩 전 데이터 마이그레이션 이슈, 샤딩 후 데이터 재배치 이슈
    • 빌링DB 는 A.I. (Auto Increment) 기반 PK 를 사용
    • DB 에서 생성된 PK 값을 사용하여 샤딩 처리 계획!
      • PK 기반 샤드키를 생성하여 중복되지 않은 방식 채택
      • 샤드키 자릿수를 최대한 늘려서 키 구간별 샤딩 처리
    • 단건 조회는 샤드키 구간 별로 샤드 DB 접근하여 조회
    • 다건 조회는 Apache ShardingSphere-Proxy 활용
      • Shard-Proxy 를 통해 admin 서비스에서 접근 조회 처리
  • DB 샤딩 이관 작업
    • 샤딩할 테이블 분류
    • 분류할 테이블 복제 이동
  • 동적 샤딩
    • 프로퍼티 설정을 통해 배포없이 동적 샤딩 처리
    • 장애 발생 시 복제 샤드DB 조회할 수 있도록 분산 처리
• 결과
  • 눈에 띄는 성능 개선
  • 전체 삽질 기간: 104일

장애가 안나고 있다는 건, 장애가 가까워지고 있다는 것!

---