if(kakaoAI)2024 의 9개의 세션들이 ‘Data’를 주제로 진행됩니다. 카카오가 다루는 대용량 데이터를 처리하는 기술들과 데이터베이스를 다루며 발생했던 고민과 도전 등을 다룹니다. AI 기반 광고 추천, MongoDB 자동 업그레이드, 카프카 운영, 대용량 데이터 동기화 및 캐싱 전략 등 다양한 주제가 준비되어 있습니다.• AI 기반 광고 추천 파이프라인에서 스파크 스트리밍의 배포 및 모니터링 전략 (최원영) AI 기반 광고 추천 시스템에서 스파크 스트리밍을 활용한 실시간 데이터 처리 파이프라인 아키텍처와 효과적인 모니터링 방법을 소개합니다.• DBA is free! MongoDB 자동 업그레이드 시스템 개발기 (최소영) 사내 수많은 데이터베이스를 업그레이드하는 과정은 지난한 커뮤니케이션과 반복적인 작업으로 고통스러운 과정입니다. 카카오의 분산데이터베이스 조직에서는 MongoDB 자동업그레이드 플랫폼 MUA를 구축하여 사내 대규모 MongoDB 를 편리하게 업그레이드하고 운영비용을 크게 절감한 사례를 공유합니다.• 카프카, Kraft를 만나다 : 주키퍼 없이 운영하는 카프카의 실전 운영 (심현준) 카프카는 ‘주키퍼 기반의 코디네이션’ 대신 ‘Kafka Raft(Kraft)’를 지원하게 되면서 한 단계 진화하게 되었습니다. Kraft Mode의 장점과 구축 단계에서 습득한 노하우에 대해 공유합니다.• 대용량 데이터베이스 동기화를 위한 최적의 CDC 시스템 구축기 (최여명, 이승민) ‘싱크버스’ 프로젝트를 통해 데이터베이스 간 실시간 동기화 시스템을 구현한 사례를 소개합니다. 수십억 건의 데이터를 MySQL에서 Iceberg까지 연동하는 과정에서 맞닥뜨린 어려움과 그 해결 방안을 공유합니다.• ActionBase : 실시간 유저 활동 데이터 서빙 시스템 소개 (김민석) 유저의 클릭, 좋아요 등의 활동 데이터를 실시간으로 저장하고 서빙하는 시스템을 소개합니다. 선물하기 위시 기능 전환 시 발생한 문제와 해결 방안, 대용량 데이터의 읽기/쓰기 성능 및 응답 시간 최적화 기술, 다양한 비즈니스 로직을 효율적으로 처리하기 위한 쿼리 엔진, 그리고 선물하기, 쇼핑하기, 프로모션 등 실제 비즈니스에 적용된 사례를 공유합니다.• 카카오 빌링 MySQL DB 샤딩 적용 (권세원) ‘동맥경화 비만 빌링 시스템 눈물의 다이어트기 (MySQL 빌링 DB 샤딩)’ 사례를 통해 빌링 시스템의 MySQL DB 샤딩 적용 과정을 소개합니다. 증가하는 결제 건수와 성능 문제를 해결하기 위해 PK 기반 샤딩을 도입하고, 용량 문제와 퍼포먼스 문제를 해결한 과정을 공유합니다.• 대용량 트래픽 아니면 안 보셔도 됩니다! 선물하기 서비스 캐싱 전략 (이희관, 이세희) 선물하기 서비스에서 대량 트래픽을 견디기 위해 고안한 다양한 캐싱 전략을 소개합니다. Hybrid Cache, Auto Cache Warm Up, 초 단위 Cache Warm Up을 통해 대규모 트래픽에도 빠르고 안정적인 응답을 제공한 과정과, 각 전략을 구현하며 직면했던 문제와 해결 방안을 공유하는

안녕하세요 저는 VI Engineering 팀 김윤제입니다.Gmarket Mobile Web Vip(View Item Page = 상품 상세)를 담당하고 있는 Backend Engineer 입니다.이번 블로그에서는 개인적으로 상품 상세 페이지에 넣고 싶었던현재 이 상품 몇 명이 보고 있어요 기능을 혼자 공부하며 개발해보는데 있어서어떻게 설계를 해야 최적의 성능을 낼 수 있을지 고민하였고 그 과정을 설명드리려고 합니다.자세한 내용은 아래에서 살펴보도록 하겠습니다.동작 과정요구사항은 다음과 같았습니다.상품 별로 중복되지 않은 사용자가 몇 명이 보고 있는지 실시간으로 집계하여 보여준다.현재 이 상품 몇 명이 보고 있어요 기능의 동작 과정은 다음과 같습니다.사용자가 웹 또는 앱을 통하여 상품 상세 페이지에 접속한다.상품 상세 서버에서는 상품 번호와 사용자 인식 정보를 데이터베이스에 저장한다.상품 상세 서버에서는 데이터베이스에서 해당 상품번호에 몇 명의 사용자가 있는지 검색한다.데이터베이스에서 검색한 사용자 수를 현재 사용자에게 반환한다.접속 중인 사용자 (웹 또는 앱)는 주기적으로 상품 상세 서버에 현재 몇명이 이 상품을 보고 있는지 요청한다.사용자가 이탈 (상품을 벗어남)하면 데이터베이스에서 해당 상품번호에 저장된 해당 사용자 인식 정보를 제거합니다.5번에서 주기적으로 상품 상세 서버에 요청을 해야 하는데 웹 / 앱이 동일한 방법을 써야 관리하기가 쉬울 것 같다는 점에서웹소켓 / 소켓이 아닌 API 요청을 받는 게 좋다고 생각했습니다.실시간으로 쏟아지는 트래픽 속에서 집계를 해야 하는 상황이라 RDB로는 성능이 안 나올 것 같아 NoSql 데이터베이스를 선택했습니다. 이제 Nosql 데이터베이스 중 Redis와 MongoDb 사이에서 선택해야 했는데요.아래에서 각 데이터베이스 별로 장단점을 알아보도록 하겠습니다.RedisRedis란?Redis는 Remote Dictionary Server의 약자로 키(Key) - 값(Value) 쌍의 해시 맵과 같은 구조를 가진 비관계형(NoSQL) 데이터베이스 관리 시스템(DBMS)입니다.Redis는 오픈 소스 기반으로인-메모리(In-memory) 데이터 구조 저장소로 메모리에 데이터를 저장합니다.따라서 별도의 쿼리문이 필요로 하지 않고, 인-메모리에 저장되기 때문에 상당히 빠른 속도로 처리할 수 있습니다. Redis의 특징 및 장단점1. 성능모든 Redis 데이터는 메모리에 저장되어 대기 시간을 낮추고 처리량을 높입니다.평균적으로 읽기 및 쓰기의 작업 속도가 1ms로 디스크 기반 데이터베이스보다 빠릅니다.2. 유연한 데이터 구조Redis의 데이터는 String, List, Set, Hash, Sorted Set, Bitmap, JSON 등다양한 데이터 타입을 지원합니다.따라서, 애플리케이션의 요구 사항에 알맞은 다양한 데이터 타입을 활용할 수 있습니다.3. 개발 용이성Redis는 쿼리문이 필요로 하지 않으며, 단순한 명령 구조로 데이터의 저장, 조회 등이 가능합니다.또한, Java, Python, C, C

안녕하세요. 토스증권 실시간 데이터 팀 리더 강병수입니다.이전 아티클에서는 토스증권의 ksqlDB 활용사례를 소개했는데요. 오늘은 ksqlDB의 강력한 Join 기능을 활용해서 토스증권의 다양한 로그를 실시간으로 조합하여 중요한 비즈니스 문제를 해결한 사례를 소개하려고 합니다.토스증권은 MAB(Multi-Armed Bandits) 알고리즘을 이용해서 수많은 국내/해외 뉴스 중 유저가 흥미를 느낄만한 아티클을 찾고 제공하고 있습니다. 이 글은 ML이나 추천 과정을 자세히 기술하는 글은 아닙니다. 뉴스 추천이라는 멋진 요리를 만들기 위해서는 신선한 재료가 중요한데요. 신선한 재료를 어떻게 제공하는지에 관한 이야기입니다.정확하고 최신성을 유지하는 뉴스 추천 MAB 알고리즘을 위해서는 실시간으로 발생하는 유저의 뉴스 탭 방문과 뉴스 클릭 로그가 필요한데요. 유저의 실시간 뉴스탭 활동 로그를 score 갱신하는 피드백으로 사용하고 있기 때문이에요. Score를 계속 갱신해서 유저들이 흥미를 갖는 뉴스를 더 많이 노출하거나, 기존에 노출되는 뉴스보다 더 재밌는 뉴스를 찾습니다. 이 시스템의 핵심 재료는 ‘실시간으로 발생하는 뉴스탭 활동 로그’입니다.MAB의 score 계산에는 CTR(Click-Through-Rate)을 핵심으로 사용하는데요. CTR을 계산하기 위해 두 가지 로그가 필요합니다. 뉴스 탭 impression 로그와, 뉴스 click 로그인데요. 실시간으로 발생하는 뉴스탭 활동 로그에서 ksqlDB를 이용해 CTR 계산에 필요한 로그만 필터링해서 제공하면 이제 MAB 뉴스 추천을 만들 수 있게 됩니다.이를 생성하는 ksqlDB 쿼리 (이하 KSQL)을 살펴보면 아래와 같이 간단하게 만들 수 있습니다.신선한 재료를 실시간으로 제공한 결과 MAB를 이용한 추천을 통해 아래 사진과 같이 유저가 흥미를 느낄 만한 뉴스를 찾아서 제공하게 됩니다.MAB에 개인화를 더하다하지만 MAB 뉴스 추천은 여기서 끝이 아닙니다. 토스증권 ML 엔지니어 분들이 추천 알고리즘 성능을 개선하기 위해서 비슷한 성향을 가진 유저들을 구분하는 유저 클러스터링 모델을 만들었습니다. 이 유저 클러스터링 모델을 MAB 추천에 적용한다면 뉴스 클릭률을 더 높이는 것을 실험을 통해 밝혀냈고, 유저 클러스터링 결과를 MAB 추천에 적용하기로 했습니다.ksqlDB이 해야 할 일은 이제 한 가지 더 늘어났습니다. 위에서 뽑아낸 뉴스 탭 impression 로그, 뉴스 click 로그에 각각 유저가 속한 클러스터 번호를 붙여주는 일입니다. 같은 클러스터 번호를 가진 유저들이 흥미를 갖는 뉴스 추천을 받게 되면서 더 재밌고 클릭률이 높은 뉴스탭으로 발전하게 됩니다.토스증권의 유저 클러스터링 결과는 매일 갱신돼서 MongoDB에 저장됩니다. 실시간으로 발생되는 뉴스탭 활동 로그에 MongoDB에 있는 클러스터 번호를 꺼내서 붙여주려면 어떻게 해야 할까요? 이때부터 실시간 Join에 대한 니즈가 시작됩니다.먼저 가장 간단하게 구현해볼 수 있는 것은 뉴스탭 활동로그를 실시간으로 소비한 다음

안녕하세요. LINE Plus에서 Global E-Commerce Platform 개발을 맡고 있는 장효택입니다.LINE Brand Catalog와 통합 커머스 검색 서비스(이하 통합 커머스 검색으로 통칭)에는 다양한 위치에 수많은 이미지가 사용되고 있습니다. 가장 흔하게 접할 수 있는 상품, 카탈로그 이미지부터 브랜드와 카테고리 영역 등에서도 이미지가 사용됩니다.통합 커머스 검색에서는 외부 상점의 상품 이미지를 OBS라는 사내 미디어 플랫폼에 저장해서 사용자에게 보여줍니다. 이 과정에서 불필요한 이미지 중복 저장 방지와 성인 이미지 검출, 이미지 사용처 확인 등 다양한 기능을 최적화해 사용하기 위해 이미지의 고유 ID와 크기, 색상 정보, 성인 이미지 점수 등 여러 정보를 MySQL에 저장해 관리하고 있습니다.현재 통합 커머스 검색에 존재하는 상품 수는 10억 개를 상회하고 각 상품은 여러 장의 이미지를 사용할 수 있기 때문에 결과적으로 26억 개가 넘는 이미지가 저장 및 관리되고 있는데요. 통합 커머스 검색 서비스의 규모가 계속 커지면서 DB 마이그레이션을 진행할 수밖에 없었습니다.저희 팀은 DB 마이그레이션을 진행하면서 독특하게 Kafka 생태계와 ETL 데이터를 적극 활용하는 방법을 사용해서 MySQL에서 MongoDB로의 마이그레이션을 성공적으로 완료할 수 있었습니다. 이번 글에서는 마이그레이션을 결정한 순간부터 마이그레이션 성공 후 MongoDB로 운영하는 현재에 이르기까지의 경험을 공유하겠습니다.마이그레이션이 필요하다는 신호통합 커머스 검색에 새로운 상점이 입점하고 등록되는 상품이 계속 증가하면서 자연스레 저장하고 관리하는 이미지가 더욱 많아졌습니다. 새로 추가되는 이미지의 개수를 살펴보면 한 달에 적게는 4,000만 건에서 많게는 2억 건이 넘는 이미지가 새로 추가되고 있습니다.신규 이미지가 증가하면서 이미지의 정보를 저장하는 테이블(이하 이미지 테이블)과 이미지 사용처의 정보를 저장하는 테이블(이하 참조 테이블)이 빠르게 커졌습니다.이와 같이 두 테이블의 크기가 빠르게 증가하면서 다음 두 가지 문제에 대한 우려가 커졌습니다.MySQL 디스크가 가득찰 것으로 예상MySQL에서는 이미지 관련 테이블뿐 아니라 통합 커머스 검색 서비스 운영에 필요한 다른 여러 테이블도 함께 존재하는데요. 이미지 관련 테이블이 빠르게 커지면서 MySQL의 디스크 사용량이 90%를 초과했고, 그중 이미지 관련 테이블의 비율이 70%을 초과했습니다. 한 달에 약 1%씩 크기가 증가하고 있었고, 이 추세라면 일 년 내에 이미지 테이블은 물론 다른 테이블에도 영향을 미칠 수 있는 상황이었습니다. 타 테이블들은 서로 연관성이 깊고, 안정성을 확보하기 위한 트랜잭션 작업과 스키마 정의가 필수라서 마이그레이션하기가 어려웠습니다.데이터가 너무 많아 스키마 변경 어려움서비스를 운영하다 보면 필드를 변경하거나 새로 추가해야 하는 일이 발생하는데요. 이미지 테이블의 경우 데이터가 워낙 많다 보니 스키마를 변경하면 시스템이 느려지거나 멈추는 현상(hang up)이 발