카카오의 카프카 적용 사례 RUBICS 출처: https://kakao.github.io/2016/04/27/rubics/ 루빅스는 카카오의 추천 시스템이다. 2015년에 뉴스 기사를 추천하는 서비스에서 사용이되었으며 현재는 카카오 채널 등 다양한 콘텐츠에서 루빅스의 추천시스템을 사용하고 있다. 뉴스 서비스는 다른 콘텐츠에 비해서 생명주기가 짧기 때문에 사용자의 반응을 최대한 빠르게 수집 및 처리하여 추천 랭킹에 반영해야 한다. 실시간 데이터 처리 메시지큐: 카카오에서는 카프카가 데이터 손실을 방지해 줄 수 있으며 안정적이기 때문에 메시지큐로 사용했다. 데이터 스트림 처리기: 추천 랭킹을 위한 기계 학습에서 사용되며 Apache Spark Streaming을 사용하고 있다. 개발팀 내에 스칼라 언어에 익..

개요 카프카를 활용한 인프라를 설계해보기 위해 찾아보다가 Confluent 공동 창립자 중 한명인 네하 나크헤데의 프레젠테이션을 보게 되었다. 이번에는 그 내용을 정리해보려고 한다. 프레젠테이션 내용 지난 10년간 데이터 시스템은 많이 바뀌었다. 여러 DB에서 데이터 웨어하우스로 ETL하여 데이터를 넣는 방식이었다. 최근 몇가지 데이터 추세는 ETL 아키텍처의 극적인 변화를 주도하고 있다. Single Server Database는 전사적 규모로 분산 데이터 플랫폼으로 바뀌고 있다. 그리고 일반적인 데이터가 아닌 logs, sensors, metrics 등으로 데이터 타입이 많아지고 있으며 스트림 데이터는 점점 보편화(increasingly ubiquitous)되고 있다. 그래서 그 결과는 아주 복잡한 ..

개요 카프카에서는 토픽을 많이 생성해서 사용하는데 Naming Convention 없이 사용하게 된다면 나중에 복잡해질수도 있기 때문에 알아보려고 한다. Convention 카프카에서 토픽을 생성할 때 유효한 문자는 [영문, 숫자, '.', '_', '-']만 사용할 수 있다. 그리고 유의할 점은 마침표(.)와 밑줄(_)은 충돌할 수 있기 때문에 둘 중 하나만 사용하는 것이 좋다. 선택할 수 있는 예시들은 다음과 같다. .. -- ... .. .. ... .. .. 이 게시물을 작성한 사람은 이 데이터 타입으로 성공했다고 한다. 이 방식으로 사용하면 인프라가 어느정도 커져도 커버할 수 있을 것으로 예상된다. message type logging queuing tracking etl/db streaming..

개요 데이터를 수집하고 가공하고 제공을 하기 위해서 보통 아주 많은 양의 데이터들을 다루게 된다. 파일을 저장할 때 압축을 하지 않는다면 파일의 크기가 커지는 동시에 비용도 증가하게 된다. 이것을 줄이기 위해서 보통은 압축을 해서 저장을 하게 된다. 저장하는 방식에는 여러가지가 있는데 이번에는 각 압축 방식마다 어떤 특징이 있는지 알아보려고 한다. 압축 방식들 gzip GNU zip의 줄임말이며 초기 유닉스 시스템에 쓰이던 압축 프로그램을 대체하기 위해 만들어졌다. 1992년 10월 31일에 처음 공개되었다. 무손실 압축 데이터 알고리즘(DEFLATE)을 사용한다. 파일 형식 중에 하나인 타르(tar)와 함께 .tar.gz 형식으로 자주 사용된다. 이 경우 다른 파일끼리 중복되는 부분을 압축시킬 수 있다..

개요 카프카로 데이터를 이동시킬 때 Kafka Connect를 사용하면 쉽고 편하게 이동시키는데에 도움이 된다. 예를 들면 MySQL에서 Kafka를 거쳐 S3에 넣고 싶을 때 JDBC Source Connector를 사용하여 MySQL에서 Kafka에 넣고, Kafka에서 S3 Sink Connector를 사용하여 S3에 넣을 수 있다. 여기에서 source connector는 데이터 소스에서 카프카로 데이터를 넣는 커넥터이고, sink connector는 데이터를 카프카에서 목적지로 데이터를 이동하는 커넥터이다. 이번에는 S3 Sink Connector를 사용하여 Kafka Connect가 어떻게 동작하는지 이해해보려고 한다. 시작하기 환경 Docker ubuntu:20.04 kafka 2.8.0 K..

키가 존재하면 업데이트하고, 존재하지 않으면 삽입하는 동작이 필요했다. 하지만 대용량의 요청을 보내면서 무리를 덜 줄 방법을 생각하다가 스택오버플로우에 물어봤는데 금방 답변을 해주었다. 질문했던 내용을 자세히 보려면 이 링크를 참조하면 된다. 기존의 방식 1. 1번 키에 prop_a, prop_b에 데이터 삽입 INSERT INTO example_table (id, prop_a, prop_b) VALUES (1,1,7) ON DUPLICATE KEY UPDATE prop_a=1,prop_b=7; ------------------------------------------------------------- id(primary key), prop_a, prop_b, prop_c 1 1 7 0 --------..