Small Asteroid Blog

Kafka를 메시지 큐로만 보면 소비한 데이터를 왜 보관하고 다시 읽는지 이해하기 어렵다. Jay Kreps의 「The Log」에서 설명하는 로그, 복제, 테이블, 데이터 통합, 데이터베이스 기능 분리를 정리했다.1. 로그는 변경 이력을 순서대로 저장한다로그는 레코드를 끝에 추가하고, 기록된 순서대로 읽는 저장 구조다.Append-only: 새로운 레코드를 로그 끝에 추가한다.순서: 로그에 기록된 순서가 기준이다. 이벤트의 실제 발생 시각과 반드시 같지는 않다.Kafka: 각 파티션이 하나의 로그이며, 오프셋이 레코드의 위치를 나타낸다.보장 범위: 순서는 파티션 내부에서 보장된다. 서로 다른 파티션 사이의 전체 순서는 보장하지 않는다.여기서 말하는 로그는 log4j·syslog의 에러 메시지와는 구분된다..

논문: https://arxiv.org/html/2302.02579제목: Recommender Systems: A Primer (추천 시스템: 입문서)저자: Pablo Castells (스페인 마드리드 자치대학), Dietmar Jannach (오스트리아 클라겐푸르트 대학)출판 시기: 2023년 2월 (ACM Press 출판 예정 서적 "Advanced Topics for Information Retrieval"의 챕터 프리프린트)논문의 목적주요 내용 구성2. 고전적 알고리즘 패러다임 아이템 검색 및 랭킹을 위한 대표적인 알고리즘들을 정리합니다.협업 필터링(Collaborative Filtering): 비슷한 취향을 가진 사용자들의 행동을 기반으로 추천콘텐츠 기반 필터링(Content-based Filt..

💡 이 글에서 다루는 내용 1부에서 개념을, 2부에서 설계·분석을 다뤘습니다. 마지막으로 실무 함정들과 추천 시스템 밖 활용 사례를 정리합니다.1. 함정 4가지🕸️ 네트워크 효과 (Interference)A/B 테스트의 전제는 "각 유저의 결과가 서로 독립적"이라는 것. 하지만 소셜/커머스 플랫폼에선 이 전제가 자주 깨집니다.재고 한정 인기 상품을 B 그룹에 더 많이 추천 → 먼저 품절 → A 그룹은 볼 기회 자체가 사라짐 → 차이의 원인이 "추천 로직"이 아니라 "재고 경쟁"일 수 있음대안: 클러스터 단위 무작위 배정, 스위치백 테스트(시간 단위 A/B 전환)🌱 콜드스타트 (Cold Start)행동 데이터가 거의 없는 신규 유저·아이템은 추천 모델이 힘을 못 씀. 실험군/대조군에 고르지 않게 분포..

설계 기본기와 결과 분석💡 이 글에서 다루는 내용 1부에서 개념을 다뤘다면, 이번엔 실험을 어떻게 설계하고 결과를 어떻게 해석하는지 다룹니다. 1. 좋은 실험은 가설에서 시작한다"일단 돌려보자"는 실험은 나중에 해석할 기준이 없습니다. 좋은 A/B 테스트는 항상 명확한 가설에서 출발해야 합니다.가설 템플릿 "[무엇을] 바꾸면, [어떤 지표]가 [어느 방향으로] 변할 것이다. 왜냐하면 [이유] 때문이다."예시추천 리스트의 개인화 강도를 높이면, 클릭률이 상승할 것이다. 왜냐하면 유저의 현재 관심사와 더 밀접한 아이템이 노출되기 때문이다.⚠️ 가설 없이 실험하면, 여러 지표 중 우연히 좋아 보이는 것만 골라 "성공"이라 주장하는 오류(HARKing, p-hacking)에 빠지기 쉽습니다. 2. 지표는 두..

💡 이 글에서 다루는 내용 A/B 테스트가 정확히 뭔지, 왜 굳이 해야 하는지를 개발자 관점에서 정리합니다. 1. A/B 테스트, 한 문장으로떡볶이 가게를 상상해봅시다.사장님이 새로운 소스 레시피(B)를 개발했는데, 기존 레시피(A)보다 더 잘 팔릴지 확신이 없습니다. 무작정 전체 메뉴를 B로 바꾸는 건 위험합니다. 손님들이 싫어하면 매출이 뚝 떨어지니까요.그래서 이렇게 합니다.홀수 번째 손님 → 기존 소스(A)짝수 번째 손님 → 새 소스(B)일주일간 각각 몇 그릇 팔렸는지, 재방문했는지 기록B가 확실히 더 잘 팔리면 → 그때 전체를 B로 교체A/B 테스트 = 바꾸기 전에, 일부에게만 먼저 보여주고 숫자로 확인하는 것 IT 서비스에서는 이 "레시피"가 추천 알고리즘, 버튼 디자인, 가격 정책 등으로 바..

prd에 있는 prd.msk.ingestion.* 토픽들이 전부 RF=1이었다. MSK 버전을 올리려면 브로커가 한 대씩 롤링 재시작되는데, RF=1이면 그동안 파티션이 통째로 오프라인 된다. 브로커가 2대라 RF를 브로커 수만큼, 즉 2로 올려서 업그레이드 중에도 다른 브로커로 리더십이 넘어가게 만들었다. 작업하면서 새로 알게 된 것들, 헷갈렸던 것들을 정리해둔다.업그레이드 전에 뭘 봐야 하나msk 버전 업그레이드 하기 전 사전 점검이 클러스터에 붙은 앱/컨슈머 그룹 목록 파악각 앱이 쓰는 토픽의 RF/minISR 점검 (제일 중요)모든 클라이언트 멀티 브로커 부트스트랩 + retry 설정 확인위 "취약 앱" 리스트 추려두기RF랑 minISR, 헷갈리지 말자RF(Replication Factor)는 파..