if(kakaoAI) 2024 참여 후기

Overview

• 참여 날짜: 2024년 10월 24일 목 (day 3)
• 장소: Kakao AI Campus

패널톡 1부

각 계열사 CTO 들이 나와서 이야기하고 질의응답

AI Finance

카카오뱅크

AI Ecosystem

• 카카오뱅크는 다양한 AI 기술을 사용하여 성과를 내고 국제적인 인정을 받고 있음
  • 고객 상담의 1/3 이상을 AI 를 사용하여 처리 중
• 더욱 높은 수준의 AI 서비스를 구현하기 위해 뭘 해야할까
  • 전문적인 조직의 필요성 대두
  • = AI Ecosystem
• 1. AI infra
• 2. AI Division = ai 사업 & 기술총괄, ai 경영시스템 국제표준 취득,
• 3. AI Product = AI hub, 개인맞춤형 agent, gen ai 가드레일/레드팀 도입으로품질 검증
• qna 핵심 키워드 1. GenAI 가드레일
  • 부적절한 내용이 학습되지 않도록 구성된 일종의 시스템
  • 구체적으로는 유해컨텐츠 필터링, 프롬프트 인젝션 방지 등등 적용
  • GenAI 가드레일과 비슷한 국내 레퍼런스가 있는지?
    • 일부 빅테크는 자체적으로 있는 것으로 알고 있음
    • 작년부터 솔루션 업체들이 서비스를 내놓고 있음
• qna 핵심 키워드 2. XAI (설명 가능한 AI)
  • 과거에는 잘 안됐는데?
    • 인공지능 분야가 복잡하다보니 설명이 어려웠음
    • 최근 설명하고자하는 니즈 증가
    • 은행이다보니 신뢰성을 위해 AI 에 대한 설명이 굉장히 중요해지고 있음
  • 어느 정도 구체적으로 설명이 가능할지
    • 정확도를 높이면 속도가 떨어지고, 속도를 높이면 정확도가 떨어지고
    • 자체적으로는 커널샵이라는 알고리즘을 사용하여 가속화 (다른 날짜에 관련 내용을 소개했었음)
  • FDS 시스템에 적용
  • OpenAI 등의 LLM 사용이 내부에서 가능한지? 금융이라 규제가 많을텐데
    • 8월에 금융당국에서 망분리 개선 로드맵을 발표하고 난 이후, 승인 받은 회사는 사용이 가능. 현재 심사 중으로 승인 이후 사용이 가능해질 예정

카카오페이

• 17년 설립 이후 42억건의 연간 거래 달성, 거래금액 40조원 달성
• 안정성과 신뢰성이 매우 중요한 가치
• AI 를 통해 신뢰할 수 있는 전문가를 양성하고자 함
• FDS/ADS = 이상거래 탐지 시스템 구현 노력
• 머신러닝 적극 활용 중
• 실시간 모델 학습 아키텍처 구현
• 금융비서를 통해 지식의 불균형을 해소하고자 함
• Mixture of Experts = 개인화
• 카카오페이를 모든 금융 플랫폼의 중심 플랫폼으로 만들고 모든 금융 요구를 충족하는게 궁극적인 목표
• FDS, ADS 와 Adaptive ML 내용으로 패널톡 진행
  • Adaptive ML 이란?
    • 모델 업데이트는 배치, 피처 업데이트는 실시간
  • 비슷한 사례가 있는지?
  • 마이크로배치를 하고 있으며, 리얼타임은 힘들다
• 금융비서와 MoE
  • LLM 들은 굉장히 일반적인 분야를 다룬다
  • 신뢰성과 최적화를 위해 금융 중심인 모델을 설계하게 된 것
  • 평가는 어떻게 하는지?
    • 국내 용어사전을 만들고 전문가 검증을 거친 시나리오를 생성, 파라미터 튜닝을 통해 독립적으로 평가하고 실험할 수 있는 구성 구현

카카오엔터프라이즈

• 클라우드업계에서는 후발주자
• 후발주자로써 아직 덜 알려졌기에 장점을 어필해보려고 함
• 타사 대비 성능 이점이 있음
  • AMD 와 협업하여 고집적 서버 개발
  • 네트워크 가속화 기술
  • 칩을 직접 들어서 보여주는 연출 = 젠슨 황?
• Multi AZ
  • 간단하게 구성 가능
• 보안
  • 다양한 안정성 평가들을 완료 및 준수
• TOP500 상위 10%내 Rank
  • GPU 클러스터의 효율성이 매우 높음
  • AI 엔지니어링 경쟁력을 어필
• 고성능 VM
  • CPU L3 cache 경합문제를 어떻게 풀 수 있는지?
    • CPU pinning 이라는 기술을 통해 CPU 격리를 구현
    • 베어메탈에 준하는 수준의 성능 (95%)
  • 네트워크 Xilise
    • I/O 가 문제
    • 하이퍼바이저 안에서 사용하게 되면 CPU 를 60~70% 까지 점유
    • 공동 연구개발을 통해 전용 카드 개발
• Sovereign Cloud
  • 데이터 주권의 중요성이 부각
  • 그럼에도 해외 업체와 경쟁할 수 있을 정도의 서비스 개발 목표

패널별 한 마디

• AI 시대로 넘어오면서 설계와 아키텍트가 더 중요해지는 시대. 설계와 디자인들에 더 집중하자.
• 금융 도메인에 있어서 AI 기술 도입은 아직 초기 단계. 카카오뱅크는 AI 기술을 활용해서 고객들에게 그동안 경험하지 못했던 혁신적인 서비스를 만들려고 준비 중.

패널톡 2부

AI Life

카카오엔터테인먼트

• 유저들에게 어떤 즐거움을 줄 수 있을지 고민
• Helix 라는 AI 모델을 활용하여 인간의 개입 없이 유저에게 추천 시스템을 제공 중
• Helix Shorts 에 대한 소개
  • 기존 쇼츠는 제작기간 총 3주
  • Helix Shorts 는 제작기간 3시간 편당 5만원
  • (개인소감: 화면 전환과 자막 퀼리티가 인상적이지만, 보기 좋은 쇼츠 퀼리티는 아니다)
• 아티스트들의 IP 를 AI 에 활용하기 위해 연구 중
• Helix Shorts
  • 하이엔드 퀼리티는 사람이 할 수 밖에 없음
  • 간단한 소개 정도는 AI 에게 맡길 수 있음
  • LLM 을 개발하기 보다는 활용에 집중하는 선택을 했음
  • 메트릭 컨텐츠에서 감정을 어떻게 꺼낼 수 있는지?
    • vision AI 기술을 활용해서 캐릭터의 감정을 AI 가 직접 읽고 판단
    • 지식 그래프를 함께 만들어서 활용하는 등의 노력
    • 캐릭터의 미세한 표정을 분석
  • 사람이 만든 쇼츠와 AI 가 만든 쇼츠가 얼마나 퀼리티 차이가 나는지?
    • 컨텐츠마다 다르지만, 우열을 가리기 어려움
    • 어떤 컨텐츠는 AI 가 더 생성을 잘하기도 함
• 캐릭터 페르소나
  • 구현이 굉장히 어려움
  • 팬덤을 생성할 수 있을 정도의 퀼리티가 쉽지 않음
  • 말을 할 때 미세한 근육의 표현 등이 어렵기 때문
  • 현재 기술로는 제한이 많다
  • 그렇다면 언제쯤 가능할까?
    • LLM 이 빠르게 발전한 것처럼, AI 페르소나도 빠르게 발전할 수 있지 않을까?

카카오모빌리티

• 일상 속 AI 디바이스 을 소개
• 자율주행, 서비스 로봇
• 사람이 더 가치 있는 일에 집중할 수 있도록 하려 함
• 태스크 관리, 디지털맵, 최적화 가 중요
• 자율 주행
  • 글로벌 최적화된 정보는 제한적
  • 디지털 트윈 관제
  • 자체 관제 시스템을 통해서 수요 예측, 공사장 등 선제적 진입 제한
  • 경쟁의 핵심을 데이터
  • 합성 데이터 기반 성능 개선
  • 직접 데이터를 생성해서 실험
  • 강남 지역에서 굉장히 많은 시민 분들이 사용 중
  • 심야시간 운행 중
  • 일부 시간대에는 수요가 공급을 초과
  • 재탑승률 매우 높음
  • 기술이 완성되었다고 하긴 어렵겠지만 기반이 마련되었다고 평가 중
  • 아직까지 사고는 없다
  • 차량에 세이프티 드라이버 탑승 중. 내년에는 세이프티 드라이버도 탑승하지 않을 예정
  • 자율주행으로까지 서비스를 확장하게 된 계기가 있는지?
    • 택시 서비스로 얻게된 대용량의 데이터와 노하우들
    • 무인 자율주행차량에도 반드시 필요한 것들
    • 이걸 자율주행으로 활용할 수 있도록
  • 자율주행 기술 수준이 어느 정도인지?
    • 직접 차량 제작을 하려고 준비 중
    • AI 데이터 선순환 구조를 만들려고 함
    • 파트너사 차량에서 얻어지는 데이터들을 전처리하고 트레이닝하고 배포하는 일련의 프로세스 개발 중
    • 자율주행 기술에 대한 이해도가 매우 중요
    • 쓰면 쓸수록 더욱 개선될 예정
  • 우버, 웨이모 등의 경쟁사에 대비 어느 정도?
    • 아직 비교하기엔 어렵
    • 로컬 데이터는 많음
    • 로컬에 집중하려고 함
    • 해외 업체들이 국내에서 서비스하려고 할 때 카카오모빌리티의 플랫폼을 사용할 수 있도록 할 예정이라 협업관계라고 생각하고 있음

• 서비스 로봇
  • BRING 이라는 로봇 서비스 제공 중
  • 실내 POI 데이터 수집
  • 건물 내 배송에 집중
  • 건물 내는 자율주행 차량과는 달리 센서 제한이 많음
  • 장애물들도 매우 많음
  • 로봇이 모든 것을 해결하기는 어렵기 때문에 건물의 인프라와 연결되는 것을 주력으로 하려고 함
  • 다른 업체의 로봇은 환경 자체를 로봇 친화적으로 설계하는데 브링도 그런지?
    • 지금은 그런걸 필요로하지는 않음
    • 최대한 사람 친화적으로 움직이도록 하려고 함
    • 주어진 건물 환경에서 운용할 수 있도록 방향성을 설정
  • 건물 내 데이터도 확보하면 자율주행에도 좋은 것 같은데?
    • 굉장히 중요한 데이터가 될 수 있다
    • 실내 POI 정보를 취득할 수 있기 때문에 카카오맵 등의 서비스를 개선할 수 있다
    • 내부적으로 개발 중
    • 앞으로 진일보된 맵 서비스를 이용해보실 수 있도록 노력 중
  • 이것 외에 확장을 계획하고 있는 부분?
    • 실외 배송 로봇 준비 중
    • 레미안 아파트 외에도 적용되도록
    • 종국에는 자율주행, 실내외 로봇이 모두 유기적으로 통합될 수 있도록 하려고 함

카카오헬스케어

모두를 건강하게

• 당뇨에 집중하기로 함
• 혈당 측정기술을 사용한 pasta 라는 서비스 런칭
• Life Recipe
• 잔소리를 나이스하게 하는 느낌
• AI 챗봇을 활용해서 운동 기록을 남길 수 있음
  • 파스타 AI 챗봇
• Seamless 한 경험 제공에 집중
• 계열사 중 특이하게 하드웨어(당뇨 관련)를 만들고 있는데 어떤 계기로 하게 되었는지?
  • 다른 업체와 협업을 통해 개발 중
  • 덱스콤 이라는 업체
• 협업을 통해 얻게 된 강점
  • 사용자 입장에서는 덱스콤 앱 필요없이 pasta 앱으로 연동
• 사용자 입장에서 어떻게 사용되고 있는지?
  • 개인에게 어떤 식단이 맞는지에 대한 인사이트를 제공해줄 수 있음
  • 스트레스가 혈당에 어떤 영향을 주는지
• 사람마다 다른 것들을 파스타 앱에 어떻게 응용할 수 있을까?
  • 개인화 AI 를 사용하려고 계획 중
• 음식 말고도 혈당을 올리는 요소들이 있는데, 확장을 위한 편의성 계획이 있는지?
  • 입력 외에도 준비 중이며 다양한 서비스들은 이미 연동되어 있음
  • 외부업체 AI 연동
  • 인바디 연동
  • 체혈을 통한 혈당 모니터링
  • 인슐린 주사를 맞아야 하는 분들을 위한 인슐린 양 측정기 연동
• 의료 자문과 단순 질문의 차이를 어떻게 AI 챗봇이 구분하는지
  • 자세한 내용은 의사와 상의하라는 권고문구가 나올 듯
  • 챗봇은 국내 의료법을 준수하기 위해 노력 중
• 챗봇의 신뢰성은?
  • 내부적으로 신뢰도를 확보한 데이터를 RAG 에 사용하고 있음

패널별 한마디

• 이제는 AI 와 함께 개발하는 시대. 적극적으로 노력해서 AI 와 개발하는 경험을 가져야 한다. 학습에 시간과 돈을 아끼지 말자.
• 지금은 AI 를 통한 새로운 물결. 2~3년 안에 삶을 바꿔놓을 것. AI 는 선택이 아니라 필수이며 관심을 갖고 공부해야 한다.

MMORPG 실시간 알림 서비스 개발기 feat. Kafka Streams

• 알림 서비스 소개
• 개발 이유 과정
• 출시 이후 기대 효과
• 알림 서비스가 왜 필요한가?
  • 왜 MMORPG에?
  • 모바일 MMORPG 는 자동전투를 지원
  • PC 클라이언트의 제공
    • 모바일 게임을 피씨에서 제공하기 위해
  • 스트리밍 서비스 (RINK)
  • 알림서비스가 없다면?
    • 캐릭터가 사망하게 된다면 방치되게 됨
  • 알림 서비스가 있다면 캐릭터가 사망하기 전 위험 알림을 받을 수 있다
  • 다양한 이벤트에 대한 알림
  • 수시로 게임을 확인할 필요가 없음
• 기존 알림 서비스의 한계
  • 알림 서비스 구조
  • 기존엔 이벤트 감지는 게임사에 개발, 알림 발송은 카카오게임즈에서 개발
  • 알림 서비스가 파편화됨
  • 신규 게임이 추가될 때마다 게임마다 다른 형태의 알림 서비스가 됨
  • 하나의 서비스를 양쪽에서 개발
    • 기능이 추가될 때마다 양쪽에서 협의가 필요
• 알림 서비스 플랫폼화
  • 게임 로그를 사용
  • 이벤트가 발생하면 하나의 통합 Kafka 에 적재
• 실시간과 정확성이 중요
  • 캐릭터가 사망하기 전 받아야 한다
  • 중요한 알림을 놓치면 안된다
• 신규 알림 서비스 조건
  • 게임별로 생성되는 분당 8만건의 로그를 처리할 수 있는 시스템
  • 모든 로그가 정확히 한 번만 처리
  • 게임이 늘어날 때마다 확장할 수 있는 시스템
• Kafka Streams 도입을 결정
  • Kafka 토픽 간에 스트림 프로세싱을 제공해주는 라이브러리
  • 높은 확장성과 내결함성 지원
  • 카프카의 exactly-once 메시지 전송 전략 지원
• 왜 Kafka Streams 인가
  • Apache Flink 는 너무 복잡해
  • logstash 는 exactly-once 를 지원하지 않아
  • 카프카 스트림즈는 가볍고 정확성을 보장
• 카프카 스트림즈는 단순한 라이브러리
  • 스프링에서 임포트하면 즉시 사용 가능
• Kafka Streams 의 필터링 기능
• Streams Application 성능 검증
  • 485만건의 로그를 필터링
  • 1만5천건의 대상 로그
  • 정확성 100%
  • 99.97% 의 로그가 1초 이내에 처리됨
  • 평균 처리 속도 0.3초
• 알림 발송 컴포넌트
  • 푸시 메시지와 알림함 분리
  • 초기엔 Spring Batch 의 Job 을 사용
    • 너무 느리다는 문제
    • 메타데이터 저장과정때문에 실시간성을 보장하기 힘들었음
  • ThreadPoolTaskExecutor 를 사용하도록 개선
    • 푸시 담당 pool, 알림함 저장 pool
    • 앞에는 queue 를 별도로 둠
• 대규모 트래픽
  • async 와 decoupling
  • 알림 요청과 알림 처리를 개별 모듈로 분리
  • 트래픽이 늘어났을 때 요청과 처리가 분리되어 있으면 시스템 전체 처리량이 늘어남
• 결과적으로 파편화 개선
  • 게임 개발사가 로그 토픽에만 로그를 쌓아준다면 알림 서비스를 모두 이용할 수 있음
• 카카오톡을 이용하지 않는 해외를 위해 카카오게임즈커넥트라는 앱을 사용하여 알림 서비스를 이용할 수 있도록 함
• 출시 후
  • 5일간 4억건 이상의 로그 발생
  • 총 200만건의 알림 발송 전체 로그의 0.4%
  • qna. 알람을 못받았다는 CS 는 들어오지 않음

리뷰

• 이미 잘 알려진 해결법이라 크게 신선하지는 않았음
• 스토리텔링은 나쁘지 않았음. 선택의 근거에 어느 정도 공감할 수 있었다.
• 성능 테스트 진행 및 결과가 인상적
• 사이드로 Kafka Streams 를 사용해봐야겠다고 생각이 드는 유익한 발표

통계를 이용해 이탈을 방지할 수 있을까?

SMART STATS 개발기

• Intro
  • 이탈
  • 왜 이탈을 할까
    • 흥미를 잃어서
    • 너무 어렵거나, 너무 쉽거나
    • 같은 허들이어도 체감 난이도가 다르다
    • 이 체감 난이도는 국가 별로 더 다르다
    • 모두를 만족하는 난이도는 존재하지 않는다
    • 어려움으로 인한 이탈은 매우 빠르게 진행
  • 직접적인 도움을 준다면?
    • 실질적으로 큰 도움은 되지 않음
    • 반응률이 좋지 않음
      • 지원해줘도 크게 관심이 없음
    • 형평성의 문제가 발생
      • 누구는 주고 누구는 안주나요
  • 근본적인 해결책은 게임에 몰입하기 위해 도움을 주는 것
  • 몰입
  • 통계
    • 대중의 픽
    • 통계를 제공하는 서비스를 만들어보자 = SMART STATS
    • 본인의 현재 가치를 객관적으로 판단할 수 있게 도움을 줌
• Data
  • 언제 어떤 데이터를 어떻게 가져올 것인가?
    • 언제 - 메인 퀘스트 클리어
    • 언제 - 던전 클리어
    • 어떤 - 나와 비슷한 사람
  • 확장성과 유연성
  • 이벤트 기반 발생 로그를 다양한 목적에 맞게 가공
  • 원하는 시점에 필요한 데이터를 활용 가능
  • 이상적인 최적의 발송 타이밍 = 좌절하기 직전
• SMART STATS
  • 1차 프로젝트는 데이터를 최대한 쌓아보자
• Conclusion
  • 아직 프로젝트가 진행 중
  • 그래서 효과가 있었나?
  • A/B 테스트 결과 실험군의 잔존율이 더 높게 집계
    • 주요 타겟이었던 D그룹의 잔존율은 대조군 대비 약 1.8배 더 높은 수준
    • 잔존한 D 그룹의 레벨 분포도 실험군이 더 우세
  • 무과금 유저들이 PU 로 전환된 확률도 증가

리뷰

확실히 통계는 숫자로써 유저의 현재 상태에 대해 객관적으로 알려주거나, 가이드로서의 역할을 기대할 수 있다.

다만 유저 입장에서 게임 플레이에 영향을 주는 요인 중 하나는 공략의 유무이다. 게임의 오픈 초기는 공략법이 정립되지 않아서 특정 선택지로 쏠리지 않을 수 있고, 어느 정도 시간이 흐르면 정석적인 방법이 등장하여 통계가 편향될 것 같다.

따라서 통계를 냈기 때문에 유저 잔존율이 높아진게 아니라, 그저 유저입장에서는 하나의 도파민 요소가 늘었기 때문에 이탈하지 않은 것 아닐까 하는 의문이 들었다. 사실상 결과물도 없었고, 주장에 대한 근거가 다소 빈약하다고 느껴진 점은 좀 아쉽다.

모두를 위한 게임 데이터 검색

• 게임 데이터의 특징
  • 유저 플레이에 따라 다양한 로그 데이터 발생
  • 특정 게임의 경우 오픈 초기 매출 비중이 크기 때문에, 초반에 빠른 결제 분석 필요
  • 빠른 어뷰징 대응으로 게임 피해 최소화 필요
• 빠른 분석을 위해 빠른 데이터 추출 필요
• 누구나 필요한 시점에 쉽고 빠르게 데이터 접근성을 높일 필요가 있었음
• 게임 데이터 접근성을 높이는 검색 시스템
  • 데이터 개방 프로젝트
  • 사내에서 DB 와 SQL 에 대한 교육을 진행 했으나 대중성 확보 어려웠음
    • 비엔지니어 직군에게는 SQL 과 데이터 구조에 대한 생소함이 존재
• 자연어로 데이터를 확인할 수 있게 하자 -> 자연어 기반 게임 데이터 검색 시스템
  • 데이터 추출 대응이 우선적으로 필요
  • TEXT-to-SQL
    • 할루시네이션 문제
    • 토큰 제한 문제
    • 쿼리가 복잡하면 성능이 낮음
    • 정확도를 신뢰하기 어려움
  • 정확도를 위해 템플릿 사용
    • 사용자가 템플릿을 사용하여 구성 후, LLM 이 리뷰
  • 만약 필요한 템플릿이 존재하지 않는다면 쿼리 빌더 사용
    • 템플릿 방식보다 조금 더 유연함
  • 100% 대응은 현실적으로 어려움
  • 기능을 고도화할 예정
• 데이터 탐색
  • 정답 미정, SQL 비효율적, 추상적, 인간 중심적인 질문은 템플릿 & 빌더 방식으로 해결하기 어려움
  • 추상적인 질문을 구체적인 질문으로 정형화하는 것이 일반적
• 질문 해결을 위한 발상의 전환
  • 데이터를 쌓을 때부터 질문에 적합하게 쌓자
• 정답이 없는 추상적인 질문에 어떻게 대답할까?
  • 게임 데이터는 모두 유저가 발생시키는 것
  • 질문도 대부분 유저와 관련되어 있는 질문
  • 질문의 대상이 되는 유저를 먼저 추출한다면 측정값은 비교적 쉽게 구할 수 있음
• 유저 특성 정보를 확인할 수 있는 체계인 유저 프로필을 고안
  • 어떤 것을 특성으로 정의할 것인가?
  • 최신 정보는 어떻게 업데이트할 것인가?
    • 최근 pvp 승률 = 지수 이동 평균
    • 적합한 수학식 선택
• 유저 프로필 데이터는 벡터 DB 에 저장 후 관리
• 유저 탐색 기능 흐름
  • 예시 유저군과 비슷한 유저 구하기
  • 입력된 유저의 특성을 찾고 유사한 특성을 보유한 유저들을 리스트업

리뷰

대부분의 기능은 결국 벡터DB 의 유사도 검색에 의지했다. 보편적인 방법이고 확실히 효과적이지만, 기대만큼 신선하지는 않은 느낌이라 좀 아쉽다.

최근 대부분의 Storage(Redis, PostgreSQL, MongoDB 등) 는 벡터를 지원하고 있는만큼, 점점 더 벡터 검색에 대해 공부해볼 필요성이 증가하고 있다고 느껴지는 발표였다.

멀티플랫폼 게임의 어뷰저 차단하기

• 어뷰저는 게임의 룰을 악용하고 서비스 제공 업체에 금전적인 손해를 입힐 수 있으며 게임 생태계를 망칠 수 있는 존재
• 인증 차단
  • 플랫폼 서버에서의 차단
    • 클라이언트 정보 기반 차단
    • 시스템 IP 대역 임시 차단
• 국가 데이터 조합으로 판단한 데이터 불일치
• 작업장 경향성
  • 수십대의 기기를 동시에 사용하는 패턴
• 연관 데이터의 정합성 불일치
• 그럼에도 불구하고 게임에 접속한 계정이 있다면
  • 인게임에서 어뷰저 차단 조치 진행
  • 세션 종료
  • 차단 조치 및 블랙리스트 등록
  • 그러나 클라이언트 정보는 조작이 가능하여 실효성이 적었음
  • ASN 대역을 활용하여 차단을 구성
    • 자율 시스템에서 관리되는 특정 의심 IP 대역 차단
    • 해당 데이터를 이용해서 의심 IP 대역 임시 차단
• 클라우드를 활용한 어뷰징 시도
  • 업체의 특정 아이피 대역 추가 차단
• IP 대역 데이터 관리
  • 접속 차단 관리 툴을 통해 아이피를 등록하고 배치를 통해 클라우드에서 대역 관련 정보를 가져옴
  • ASN 데이터를 가공하고 디비에 등록
  • 클라이언트가 접근을 시도할 때 등록한 대역에 속하는지 확인 후 접속을 차단
• 결제 어뷰징
  • 우회 결제
    • 환율차익을 보기 위해 다른 국가에서 구매하는 것
    • 유저는 이득 회사는 손실
    • 유저는 이미 지불했기 때문에 마땅히 유저를 제재할 근거가 없음
    • 결제 국가를 제한해버리면 되지만 이러한 서비스를 지원하지 않는 스토어도 많음
    • 등록되지 않은 화폐를 사용한 결제를 제한
  • 클라이언트 변조
    • 우회 결제와는 달리 엄연한 불법의 영역
    • 가짜 앱을 등록해두고 게임 서버를 속이는 방법
    • 클라이언트 값은 언제든지 변조가 가능하기 때문에 검증은 서버에서 하는걸 권장
• 어뷰저의 진입을 최대한 방해하여 건강한 생태계를 유지하도록 하는 것

리뷰

분야가 좀 달라서 잘 이해하기 어려웠지만, 어떤 고민을 하고 있는지 엿볼 수 있어서 흥미로웠다.

ActionBase 실시간 유저활동 데이터 서빙 시스템

실시간 유저 활동 데이터 서빙 시스템 소개

• ActionBase 소개
  • 카카오가 직접 개발 중
  • 대규모 실시간 유저 활동 데이터 서빙 시스템
  • 저지연처리 -> 실시간 서비스 처리
  • 높은 처리량
  • 큰 저장공간
  • 다양한 대규모 활동 데이터를 효율적으로 처리
  • Apche HBase 기반으로 강한 일관성 제공
  • 그래프 기반
• 주요 적용 사례
  • 선물하기 위시
  • 쇼핑하기 찜
  • 쇼핑탭 쇼핑 히스토리
  • 다양한 프로모션

• 유저 활동 데이터 저장 및 쿼리
  • Actor 가 Target 을 Action 했다 로 표현
  • 범용성
  • 확장성
  • 쿼리 효율성

• 데이터 쓰기 흐름

• ActionBase 쿼리
  • 다단계 쿼리
  • 처리 및 응답

• 기술적 특징
  • BASE 와 ACID
    • ActionBase 는 BASE 모델 사용
  • 비관적, 낙관적 동시성 수행 제어
    • ActionBase 는 비관적 동시성 수행 제어 사용
    • 엣지 및 인덱스와 카운터 동시 저장 구현 용이
  • 최종 일관성과 즉시 일관성
    • ActoinBase 는 이를 모두 지원
  • 멱등성
• 데이터 파이프라인(스트리밍, 배치)
  • WAL 및 CDC

• 스냅샷 및 마이그레이션
  • 데이터 구조를 직접 복사하는 것으로 매우 빠른 마이그레이션이 가능

• 시나리오 테스트
  • json 으로 시나리오가 정의되어 있음
  • 최대한의 테스트 커버리지를 확보하기 위해 노력 중
• 쉐도우 테스트
  • 실제와 동일 트래픽을 미러링
  • 배포 전 잠재적 위험 요소 확인 가능
  • ingress 로 트래픽을 미러링해서 바라보는 애플리케이션 파드를 변경하는 방법
• 마무리 및 향후 계획
  • ActionBase 는 대규모 실시간 유저활동 데이터 서빙 시스템
  • 개발 초기인만큼, 기능을 더욱 확장해나갈 계획

리뷰

• HBase 기반이긴 하지만 그래프 DB 를 직접 구현하여 사용한다는 점이 매우 인상적
• 스트리밍 + 배치 시스템에 대해 운영 및 테스트 노하우를 엿볼 수 있었다
• 개인적으로는 오늘 발표 중 가장 유익했다.

카카오 빌링 MySQL 샤딩 적용

Kakao A.I. (Auto Increment)

• 합병이 반복되며 단일 DB 구조였던 빌링 시스템에 데이터가 매우 많이 증가함
• 21년 11월 11일 빼빼로데이에 큰 장애를 겪은 이후 빠르게 샤딩을 적용할 필요성이 제기
• CTO 의 전폭적인 지원 아래 DB 스펙은 돈으로 해결
  • 1대 -> 12대
• 운영 중인 서비스를 중단하지 않고 어떻게 샤딩을 적용해야할까 에 대한 고민
• 여기저기 문의해본 결과 Apache ShardingSphere 를 사용하기로 함
• 결제 정보에 마땅한 샤딩키가 없어서 Auto Increment(A.I) PK 값을 샤딩 키로 사용
  • 10500000000001 -> 5번 샤드
  • 10400000000001 -> 4번 샤드
  • 10300000000001 -> 3번 샤드
  • 10200000000001 -> 2번 샤드
• 굉장히 큰 숫자를 PK 로 사용하여, 논리적으로는 키 중복이 발생할 수 있지만 물리적으로는 발생하지 않는다 (그 전에 disk full 이 발생하기 때문에)
• 불필요한 조인은 모두 제거했음
• 장애가 나지 않았다면 장애가 다가오고 있다는 뜻 이라는 다소 자조 섞인 마지막 멘트가 명언

리뷰

연사 분의 꾸미지 않은 솔직한 발표가 재밌었습니다. AI 가 주제인 컨퍼런스인만큼 회사로부터 어떻게든 AI 이야기하라는 압박이 있었다면서 준비한게 AI(Auto increment)라고 하시는 부분에서 재치가 느껴졌습니다. 마치 아무것도 아닌 것처럼 발표하셨지만, 사실 그렇게 쉽지만은 않은 내용이였고 '우리 회사 이만큼 대단한 기술 씁니다' 느낌인 다른 발표보다 훨씬 실무에 도움이 될 실용적인 발표였습니다.

Conclusion

완전히 주관적인 의견이지만, 몇몇 세션을 제외하면 깊이가 다소 부족한 느낌이 있었습니다. 세션 자체는 좋았으나, 내용에서 특별한 기술적 인사이트를 얻기는 어려웠습니다. 아무래도 다양한 사람이 참여하는만큼 '깊이보다는 전달력에 초점을 맞춘걸까' 싶은 생각이 들었습니다. 반대로 특정 세션은 굉장히 인상적이였고, 정말 대단한 일을 하고 있다는게 전해졌습니다.

전체적으로 상당히 공을 많이 들였다는게 느껴지는 컨퍼런스였습니다. 장소가 다소 외진 곳에 있었는데도 불구하고, 이동이 전혀 불편하지 않았고 전체 진행이 매끄러웠습니다. 무려 3일이나 진행하는 대형 컨퍼런스를 '이 정도로 열심히 잘 준비할 수 있구나' 싶은 생각이 들었네요.

내년에는 어떤 퍼포먼스를 보여줄지 기대되는 컨퍼런스였습니다.