<div id="readability-page-1" class="page"><div data-popover="" id="popover-animation" role="tooltip"><p><h3>Meta info of this page</h3></p><ul><li></li><li><div><p><span>Plublished on March 17 2024</span></p></div></li><li></li><li></li><li></li><li></li></ul></div><div id="single-content"><h2 id="pocket-pick">Pocket Pick<a data-title-of-head="" href="#pocket-pick"></a></h2><h3 id="리디에서-kafka를-사용하는-법-내부-api-활용에서-kafka-기반으로httpsridicorpcomstoryhow-to-use-kafka-in-ridi"><a href="https://ridicorp.com/story/how-to-use-kafka-in-ridi" target="_blank">리디에서 Kafka를 사용하는 법 (내부 API 활용에서 Kafka 기반으로)</a>
<a data-title-of-head="" href="#%eb%a6%ac%eb%94%94%ec%97%90%ec%84%9c-kafka%eb%a5%bc-%ec%82%ac%ec%9a%a9%ed%95%98%eb%8a%94-%eb%b2%95-%eb%82%b4%eb%b6%80-api-%ed%99%9c%ec%9a%a9%ec%97%90%ec%84%9c-kafka-%ea%b8%b0%eb%b0%98%ec%9c%bc%eb%a1%9chttpsridicorpcomstoryhow-to-use-kafka-in-ridi"></a></h3><ul><li>실시간 랭킹을 집계하기 위해 API 호출 방식을 사용했었는데 Kafka를 통한 이벤트 수집 방식으로 변경</li><li>Kafka Topic에 수집된 감상 데이터(이벤트)는 다른 서비스에서도 활용할 수 있게 됨</li><li>통계, 메시지큐, 다양한 이벤트(프로모션)의 실시간 처리 등에 활용하고 있음</li><li>Kafka 메시지 포맷으로
<a href="https://cloudevents.io/" target="_blank">CloudEvents</a>
<sup id="fnref:1"><a href="#fn:1" role="doc-noteref">1</a></sup>를 사용하고 있음</li></ul><h3 id="광고-정산-시스템에-kafka-streams-도입하기httpswwwbucketplacecompost2022-05-20-eab491eab3a0-eca095ec82b0-ec8b9cec8aa4ed859cec9790-kafka-streams-eb8f84ec9e85ed9598eab8b0"><a href="https://www.bucketplace.com/post/2022-05-20-%EA%B4%91%EA%B3%A0-%EC%A0%95%EC%82%B0-%EC%8B%9C%EC%8A%A4%ED%85%9C%EC%97%90-kafka-streams-%EB%8F%84%EC%9E%85%ED%95%98%EA%B8%B0" target="_blank">광고 정산 시스템에 Kafka Streams 도입하기</a>
<a data-title-of-head="" href="#%ea%b4%91%ea%b3%a0-%ec%a0%95%ec%82%b0-%ec%8b%9c%ec%8a%a4%ed%85%9c%ec%97%90-kafka-streams-%eb%8f%84%ec%9e%85%ed%95%98%ea%b8%b0httpswwwbucketplacecompost2022-05-20-eab491eab3a0-eca095ec82b0-ec8b9cec8aa4ed859cec9790-kafka-streams-eb8f84ec9e85ed9598eab8b0"></a></h3><ul><li>‘오늘의집’이 CPC 광고 시스템을 도입하면서 예산 충전과 클릭당 차감을 실시간으로 처리하고, 중복 처리를 방지하기 위해 Kafka Streams를 도입하게 된 사례</li><li>문제점: 모든 클릭 요청은 Kafka Topic의 메시지로 들어오게 된다. Kafka와 RDB만으로 설계했을 경우, 정산 처리 단계 중 클릭에 따른 예산 차감이 실패하게 되었을 때 Topic offset이 commit되지 않았다면, 재시도 로직에서 예산 차감이 중복될 수 있다.</li><li>개선 방향1: RDB 테이블에 예산 차감 히스토리 목적으로 Topic offset을 저장해서 Consumer가 처리할 현재 Offset보다 높은 경우, 처리하지 않고 Offset을 Commit하는 방법<ul><li>단점1: 정산 처리 비즈니스 로직과 중복 처리 방지 로직이 함께 구현되어 복잡성 증가</li><li>단점2: 모든 클릭 로그를 저장해야 하기 때문에 RDB 부하가 발생할 수 있다.</li></ul></li><li>개선 방향2: Kafka Streams (클라이언트 라이브러리)로 exactly-once 처리하기<ul><li>제약 사항: RDB 같은 외부 연동이 포함된 경우, exactly-once를 보장하지 못 한다.</li><li>해결: in-memory DB(state store) 활용<ul><li>정산처리 애플리케이션 안에 Kafka Streams 구현과 in-memory DB를 포함하고 있게 된다.</li><li>애플리케이션이 재시작될 경우 in-memory DB의 데이터가 사라지는 것을 복구하기 위해 in-memory DB에 저장되는 모든 데이터를 Kafka topic으로 전송. 애플리케이션이 재시작될 때 이 Topic에서 메시지를 읽어와 마지막 데이터 상태를 유지</li><li>in-memory DB에 저장될 데이터를 Topic에 전송하는 것과 클릭 로그 Topic offset을 commit하는 작업이 Atomic함을 보장하기 위해 Kafka Transaction을 활용</li></ul></li><li>예산 차감 처리 내역을 별도 Topic에 저장하고, 이 메시지를 Kafka Connect를 통해 S3로 저장. Apache Spark으로 일별 통계 계산 후 RDB 저장</li></ul></li><li>결론<ul><li>장점<ul><li>Kafka Streams의 exactly-once 기능 덕분에 비즈니스 로직에만 집중할 수 있다.</li><li>in-memory DB를 활용하기 때문에 빠르다. (예: 예산 조회)</li><li>처리량 부하에 따라 스케일 아웃이 용이하다.</li></ul></li><li>단점<ul><li>새로운 것에 대한 거부감?<ul><li>(내 생각) Kafka Streams가 어려워서?</li></ul></li></ul></li></ul></li></ul><hr><h2 id="tech-video">Tech Video<a data-title-of-head="" href="#tech-video"></a></h2><h3 id="infcon-2023---eks-비용-절감-전략-회사에서-실현한-사이드-프로젝트의-아이디어">INFCON 2023 - EKS 비용 절감 전략 (회사에서 실현한 사이드 프로젝트의 아이디어)<a data-title-of-head="" href="#infcon-2023---eks-%eb%b9%84%ec%9a%a9-%ec%a0%88%ea%b0%90-%ec%a0%84%eb%9e%b5-%ed%9a%8c%ec%82%ac%ec%97%90%ec%84%9c-%ec%8b%a4%ed%98%84%ed%95%9c-%ec%82%ac%ec%9d%b4%eb%93%9c-%ed%94%84%eb%a1%9c%ec%a0%9d%ed%8a%b8%ec%9d%98-%ec%95%84%ec%9d%b4%eb%94%94%ec%96%b4"></a></h3><p><iframe src="https://www.youtube.com/embed/UGT0HHx4Hl4" allowfullscreen="" title="YouTube Video"></iframe></p><ul><li>핵심 아이디어<ul><li>스팟 인스턴스 사용 + 적절한 노드 선택</li><li>적절한 컨테이너 리소스 할당</li><li>필요한 시간에만 클러스터 운영</li><li>의도하지 않은 실수를 차단할 수 있는 시스템</li></ul></li><li>스팟 인스턴스 사용 + 적절한 노드 선택<ul><li>Karpenter<ul><li>클러스터 오토스케일링 도구</li><li>파드의 정의된 리소스에 따라 노드 선택 가능</li><li>스팟 / 온디맨드 타입 지정해서 프로비저닝 가능</li><li>특정 노드의 모든 파드가 다른 노드로 이동할 수 있다면 특정 노드를 종료</li><li>노드 사용량 볼때 좋은 도구<ul><li><a href="https://github.com/awslabs/eks-node-viewer" target="_blank">https://github.com/awslabs/eks-node-viewer</a></li></ul></li></ul></li></ul></li><li>적절한 컨테이너 리소스 설정<ul><li>Kubecost<ul><li>적절한 리소스 설정 - kubecost rightsize recommend 사용</li><li>비용 예측 방법 - kubecost cost predict 사용</li></ul></li></ul></li><li>필요한 시간에만 클러스터 운영<ul><li>Cronjob</li><li>Botkube - 클러스터 이벤트를 실시간 모니터링 및 알림 전송?<ul><li>Slack 메시지로 kubectl 명령어를 전송하고, 결과(stdout)을 메시지 창에 표시해줌</li></ul></li></ul></li><li>의도하지 않은 실수를 차단할 수 있는 시스템 - OPA (Open Policy Agent) Gatekeeper<ul><li>PaC (Policy as a Code) : 정책을 코드로 만든다.<ul><li>예: Replica 개수 제한, POD 리소스 제한, StorageClass를 gp3로 제한</li></ul></li></ul></li><li>그밖에<ul><li>짧은 시간동안 많은 트래픽이 예상되는 경우, 미리 노드를 프로비저닝<ul><li>Kapenter는 비용, 리소스 최적화 컨셉에는 맞지만, 오버 프로비저닝이 필요한 상황에서는 대응하기 어렵다.</li><li>KEDA(Kubernetes Event Driven Autoscaler)</li></ul></li></ul></li></ul><h3 id="토스-slash23---kafka-이중화로-다양한-장애-상황-완벽-대처하기">토스 SLASH23 - Kafka 이중화로 다양한 장애 상황 완벽 대처하기<a data-title-of-head="" href="#%ed%86%a0%ec%8a%a4-slash23---kafka-%ec%9d%b4%ec%a4%91%ed%99%94%eb%a1%9c-%eb%8b%a4%ec%96%91%ed%95%9c-%ec%9e%a5%ec%95%a0-%ec%83%81%ed%99%a9-%ec%99%84%eb%b2%bd-%eb%8c%80%ec%b2%98%ed%95%98%ea%b8%b0"></a></h3><p><iframe src="https://www.youtube.com/embed/Pzkioe7Dvo4" allowfullscreen="" title="YouTube Video"></iframe></p><ul><li>Producer –&gt; Cluster –&gt; Consumer<ul><li>Produce<ul><li>한국/미국 체결가, 호가, 거래소 정보</li><li>토스 코어, 토스 뱅크</li><li>한국, 미국 언론사 뉴스 수신</li><li>Client, Server, System Log</li><li>DB CDC</li></ul></li><li>Broker<ul><li>–&gt; ksqlDB 적극 활용 중 (오…)</li></ul></li><li>Consumer<ul><li>Service Server</li><li>MySQL</li><li>Hadoop</li><li>ES</li><li>KUDU??</li><li>Redis</li><li>토스 코어, 토스 뱅크</li></ul></li></ul></li><li>장애 상황의 구분<ul><li>카프카 클러스터 일부 노드 장애<ul><li>분산 형태라 운영에 심각한 문제가 발생하지 않을 수 있음</li></ul></li><li>IDC 전면 장애<ul><li>심각한 상황</li><li>다른 IDC에 Disaster Recovery(DR) 시스템을 구축해야 한다.<ul><li>보통 Active - Standby 구성을 하며, Standby는 잘 관리가 안 되면 실제 장애 상황에서 기대한 것처럼 Active가 안 될 수도 있다.</li><li>Active - Active 구성을 지향!!</li></ul></li></ul></li></ul></li><li>위 두가지 상황을 이겨내기 위해 이중화를 해야 한다!<ul><li>Kafka는 Stateful한 시스템은 이중화 구성이 어렵다.</li><li>IDC 두 곳을 유저 트래픽의 50%씩 나눠서 Active-Active 구성을 유지한다.</li><li>두 IDC로 반반씩 나눠진 메시지는 Kafka Connect를 사용해서 실시간 미러링</li><li>Offset Sync라는 데몬으로 Consumer Group Offset을 싱크<ul><li>단, Consumer 그룹은 한 쪽 IDC의 Broker로만 연결하여 중복처리를 방지한다.</li><li>Offset은 클러스터가 다르면 번호체계가 달라지기 때문에 중간에 상대쪽 IDC에 맞는 번호로 변경해야 한다는 점이 중요</li></ul></li></ul></li><li>이중화 클러스터 관리하기<ul><li>클러스터의 모든 메트릭을 Prometheus로 수집하여, Thanos Ruler를 이용해서 정의한 조건이 충족되면 알림</li><li>클러스터의 모든 로그는 ElasticSearch로 실시간 수집, ElasticAlert로 알림</li><li>시계열 데이터의 이상 징후 탐지하는 ML 모델도 개발 중</li></ul></li></ul><hr><h2 id="starred-github-repo">Starred Github Repo<a data-title-of-head="" href="#starred-github-repo"></a></h2><ul><li><a href="https://github.com/charmbracelet/gum" target="_blank">gum</a><ul><li>반복적이고 패턴화된 터미널 작업을 하나의 Shell Script로 만들어서 사용할 때 일반적으로 위치/키워드 파라미터 등으로 동작을 분기하게 되는데 Gum을 사용하면 TUI 상에서 Interactive 하게 만들 수 있다.</li><li>블로그의 새 글을 등록할 때 <code>hugo new ...</code>부터 시작하여 여러 메타데이터를 수동으로 바꾸는 일이 많은데 gum으로 하나 만들어두면 좋을 것 같다.<br><img src="https://camo.githubusercontent.com/43b2c2e06b97b0ead420caecf4cc2eabb4c586063fabf96435b060919bce6186/68747470733a2f2f73747566662e636861726d2e73682f67756d2f64656d6f2e676966" alt="" loading="lazy"></li></ul></li><li><a href="https://github.com/jdx/mise" target="_blank">mise</a><ul><li><a href="https://github.com/asdf-vm/asdf" target="_blank">asdf</a>
비슷한 개발 도구(예: Python, Node.js)의 버전 관리할 수 있다.</li><li><code>make</code> 또는 <code>npm script</code> 같은 Task runner로도 기능도 제공한다.</li><li>asdf를 몇 년째 잘 쓰고 있는데 딱히 넘어갈 만한 이유는 없을 것 같다.</li></ul></li></ul></div></div>

조은우 개발 블로그

Eunwoo Cho

Pocket Pick 리디에서 Kafka를 사용하는 법 (내부 API 활용에서 Kafka 기반으로) 실시간 랭킹을 집계하기 위해 API 호출 방식을 사용했었는데 Kafka를 통한 이벤트 수집 방식

2024 Weekly #11 Log

댓글