“kafka” 검색 결과

문제아자르 세션 기반 추천에 필요한 유저 이벤트가 서로 다른 시점에 흩어져 발생한다. 실시간 추천 품질을 유지하려면 파편화된 이벤트를 낮은 지연 + 정확히 한 번(Exactly Once) 으로 조합해야 한다.

접근Spark Streaming, Kafka Streams, Flink 를 비교한 뒤 Apache Flink 기반 스트림 조인 서비스를 구축. Event Time 기반 정밀 제어와 zero-downtime 배포까지 만족하도록 파이프라인을 설계.

결과실시간 추천을 위한 이벤트 조합을 안정적으로 제공한다. 매치 요청·대화 완료 같은 다양한 조합 시나리오를 단일 인프라로 흡수한다.

문제사용자가 보유한 쿠폰을 어떤 상품에 적용할 수 있는지 확인할 방법이 없었음.

접근Kafka 기반 이벤트 드리븐 아키텍처로 실시간 데이터 동기화. Debezium CDC 로 변경 감지, 반정규화 테이블 구축, Elasticsearch 인덱싱.

결과쿠폰 적용 가능 상품 목록 조회 기능 론칭 및 쿠폰 도메인 전반의 성능·안정성 개선.

문제Kinesis Data Stream + Firehose 기반 로그 파이프라인이 S3/GCS 중복 저장, 1~2시간 배치 지연, 스키마 변경 추적 부재로 비효율적이었다.

접근MSK(Managed Streaming for Apache Kafka) + 커스텀 Python Consumer로 전환하고 Protobuf + Buf 기반 Schema Registry로 스키마 관리를 자동화한다. GCS를 SSoT로 두고 BigQuery 외부 테이블로 적재한다.

결과데이터 신선도가 1~2시간에서 약 3분 수준으로 줄었고 수기 스키마 작업이 사라졌다. 단일 장애점이 제거되어 선택적 로그 적재가 가능해졌다.

문제카카오페이 데이터 플랫폼이 여러 admin API 와 소스의 데이터를 결합하면서 코드 품질과 확장성 유지 필요.

접근Spring Cloud Stream + Kotlin. Function 기반 패턴 + 멀티 모듈 아키텍처로 표준화된 loose-coupling 데이터 파이프라인 구성.

결과유연한 데이터 오케스트레이션, 코드 유지보수성 향상, 수평 확장 용이. 기존 spring-kafka 대비 결합도 감소.

문제7천만 라인 모놀리식 코어와 수작업 서류 검토로 보험금 청구 처리에 하루 이상 걸리는 일이 잦았다.

접근Scavenger로 데드 코드를 분석해 마이크로서비스(claim-channel/claim-core/margarine)로 분리하고, TrOCR 기반 Document AI 파이프라인(Edge Detection → Layout → OCR → Parsing)과 Strategy 패턴 기반 보험금 자동 계산기를 도입한다. AWS Lambda/S3/Spring Kafka로 비동기 처리한다.

결과1분 내 30%, 10분 내 70%의 청구가 자동 처리되고 처리 비용은 기존 대비 90% 이상 감소했다.

문제성능 테스트 환경을 준비하는 데 최대 1개월이 걸렸고 유관부서 협조가 필수였다. nGrinder의 Groovy도 개발자에게 익숙하지 않아 진입 장벽이 높았다.

접근Kubernetes 기반 샌드박스에 K6, MySQL/MongoDB/Redis/Kafka를 Pod로 묶어 셀프서비스 환경을 만든다. Testcraft 웹 UI로 배포를 관리하고 Prometheus + Grafana로 메트릭을 본다. 공용 목서버로 외부 의존성을 대체한다.

결과운영환경에 영향 없이 독립 테스트가 가능해졌고, JavaScript 기반 K6로 스크립트 작성이 쉬워졌다. 대규모 이벤트 전 허용 트래픽을 사전에 검증한다.

문제RabbitMQ 운영 중단으로 지연이체가 같이 멈출 위기였고, 단일 스케줄러로는 5분 안에 수천 건 송금을 처리할 수 없어 분당 91건이 한계였다.

접근Kafka `transfer-delay` 토픽(파티션 3개)으로 전환하고 record key에 userId를 넣어 동일 사용자의 순차 처리를 보장한다. PREPARATION 상태 + 유저락으로 중복 송금을 막고 배치 read 20건, ForkJoinPool 10 thread, Consumer 3대로 확장한다.

결과분당 처리량이 91건에서 728건으로 8배 늘었고 전체 실행 시간은 68분에서 8분으로 단축됐다.

문제게임 런칭 당일 매출/동접 지표가 1시간 이상 지연되고 국가/OS/스토어 차원이 빠져 있어 의사결정이 어려웠다.

접근Kafka 토픽을 분리하고 Spark Structured Streaming의 Stream-Stream JOIN과 watermark로 late data를 다룬다. Databricks SQL + Airflow 2분 micro batch로 집계하고 Delta Lake Medallion 구조로 저장한 뒤 Kibana 대시보드로 본다.

결과10분 이내 SLO와 5% 이내 오차를 만족하는 준실시간 지표를 만들었다. 쿠키런:모험의 탑은 출시 일주일에 200만 다운로드, 누적 매출 100억 원을 이 지표로 추적했다.

문제신용정보법에 따라 3년치 금융 데이터 수집 이력을 같은 DB에 보관하다 보니 QPS 폭증으로 Master-Slave 복제가 지연되고, 용량이 한계에 닿았으며 통계 배치는 슬로우 쿼리로 떨어졌다.

접근서비스 데이터와 이력 데이터를 분리한 뒤 모듈러 샤딩과 `AbstractRoutingDataSource`로 동적 라우팅을 구성했다. Logstash로 Kafka에서 데이터를 받아 파일 스토리지에 백업하고, 통계 쿼리는 사내 하둡 기반 Palsonic으로 이관했다.

결과QPS가 분산되고 보관 안정성이 확보됐다. Palsonic+하둡 조합으로 통계 배치 처리 시간이 크게 단축됐고 DB 부하는 사실상 사라졌다.

문제카카오페이증권이 MSA를 확장하면서 Oracle과 MongoDB 사이의 실시간 데이터 동기화가 필요해졌다. RDBMS에서 NoSQL로 가는 CDC는 참고할 사례가 적었고, 초기 적재와 변경 이벤트를 함께 다뤄야 했다.

접근Kafka Connect 위에 Debezium Source Connector와 MongoDB Sink Connector로 파이프라인을 만든다. 초기 6TB는 Talend Open Studio와 mongoimport로 분리 적재하고, 그 뒤 변경분은 Kafka 이벤트로 실시간 동기화했다.

결과6TB·130억 건의 초기 데이터를 9일 만에 적재했고, 누적된 변경분 lag도 12시간 안에 따라잡았다. 이후 안정 운영 중이다.

문제엔지니어의 업무는 매출처럼 숫자로 바로 떨어지지 않아 프로젝트 가치를 정량화하기 어렵다.

접근개발 시간 절감의 기회비용, 유사 SaaS 대비 비용, 인프라 사용량 절감이라는 세 축으로 임팩트를 계산하고 Apache Kafka 기반 Weaver 프로젝트에 적용한다.

결과SDK 통합 2.4억, CDC 실시간화 8천만, SaaS 내재화 44.6억, 인프라 절감 1천만 원 등 항목별 금액으로 프로젝트 임팩트를 환산했다.

문제네이버 플레이스 리뷰 태깅이 분석 API와 강하게 결합돼 기준 변경 때마다 재호출이 필요했고 한 리뷰의 다중 이미지가 컬렉션에 반복 업데이트돼 부하가 컸다.

접근원본을 저장하는 rawtags, 비즈니스 로직을 적용한 tags, 20분 주기로 모아 쓰는 updatabletargets 컬렉션으로 단계를 나누고 Kafka Consumer를 역할별로 분리했다.

결과이미지 태깅 업데이트가 67% 압축됐고(10,274→3,425) 한국 이미지→리뷰 전파가 47% 줄었으며 운영자 입력 보존과 ML 재학습 파이프라인까지 가능해졌다.

문제마이데이터 조회처럼 대량 트래픽이 들어오는 자산관리 서비스에서 동기 API 호출은 스레드 낭비와 높은 레이턴시를 유발한다.

접근이벤트 기반 아키텍처로 서버 간 의존성을 끊는다. 클라이언트는 SSE로 연결을 유지하고 서버 간 통신은 Kafka, 분산 환경 브로드캐스트는 Redis Pub/Sub, 비동기 상태의 동시성 제어는 Redisson 분산 락으로 처리한다.

결과동기 호출이 사라져 스레드를 효율적으로 쓰면서 더 많은 트래픽을 받는 구조가 된다. 대신 시스템 복잡도가 올라가는 트레이드오프가 있다.