01. 카프카 시작하기

Last updated - 2025년 06월 19일 Edit Source

• 📚 카프카 핵심가이드

로그 메세지, 지표 (metric), 사용자 행동, 외부와 연동되어 나가는 메세지 등 모든 애플리케이션은 데이터를 생성한다. 결국 모든 기업에서는 데이터를 기반으로 움직인다. 카프카는 링크드인이 데이터를 다루는 과정속에서 직면한 문제를 해결하기 위해 개발된 기술이다.

기업에서 데이터를 중요시하는 이유는 아래와 같다

• 데이터는 의미를 가짐
• 예를 들어, 유저가 자주 클릭하는 상품과 비슷한 상품을 추천할 수 있도록 통계를 분석할 수 있음
• 데이터의 분석은 곧, 기업의 매출 증대와 유저 상승이라는 결과를 발생시킴

이러한 일련의 작업 중 데이터를 더욱 빠르고 이동시키는 작업에 더 적은 노력을 들일수록 핵심 비즈니스 로직에 집중 가능해진다.

• 데이터 중심 기업에서 파이프라인(pipeline)이 핵심적인 요소인 이유
• 데이터 자체도 중요하지만, 데이터를 어떻게 이동시키느냐도 중요한 문제

발행(pub) / 구독(sub) 메세지 전달 패턴

• 메세지(데이터) 를 발행하는 전송자가 구독하는 수신자로 직접 보내지 않는다
• 메세지를 전달받고 중계해주는 중간 지점 역할인 브로커(broker) 가 존재

지표를 대시보드 형태로 보여주는 앱 애플리케이션 서버를 개발한다고 가정

1. 프론트엔드 서버 - 지표 서버 (직접적인 request / response)

   • 발행자와 구독자가 직접 연결된 형태

2. 여러 프론트엔드 서버, 지표 서버, 지표 UI, 데이터베이스 서버, 다른 서버 등 고도화된 형태

   • 각각의 서비스들이 직접 연결된 형태로 추적하기 어려움

3. 여러 앱 - 지푯값 발행/구독 서버 - 여러 지표 관련 서버

   • 모든 애플리케이션으로부터 지표를 받고, 필요로 하는 시스템에 제공해주는 하나의 서버

4. 지푯값 발행/구독 서버 외에도 여러 메세지 큐 시스템이 추가

   • 2번 방식보다는 좋지만, 여전히 중복 많은 상태
   • 개별적인 메세지 큐 시스템은 버그도 한계도 제각각
   • 즉, 일반화된 유형의 데이터를 발행하고 구독할 수 있는 중앙 집중화된 시스템의 필요성 대두

• 일반화된 유형의 데이터를 발행하고 구독할 수 있는 중앙 집중화된 시스템
• 분산 커밋 로그 / 분산 스트리밍 플랫폼
• 저장된 메세지(데이터)는 순서를 유지한 채 지속성 있게 보관되며, 읽을 수 있음

왜 분산 커밋 로그로 불리는가

• 파일시스템, 데이터베이스의 커밋 로그(commit log)는 모든 트랜잭션 기록을 지속성(D)있게 보존
• 시스템의 상태를 일관성(C) 있게 복구 가능
• 카프카는 위와 유사하면서도 분산된 시스템이기에 분산 커밋 로그라고도 불림

메세지 (message)

• 데이터의 기본 단위
• DB의 row나 record와 유사한 개념
• 특별한 의미 없는 단순바이트 배열
• 해당 데이터에는 특정한 형식이나 의미 ❌

키 (key)

• 메세지에 포함될 수 있는 메타데이터
• 특별한 의미 없는 단순바이트 배열
• 메세지를 저장할 파티션을 결정하기 위해 사용

키로 메세제를 저장할 파티션 결정하는 방법 예시

키값에 대한 해시값 % (토픽의 파티션 수) = 메세지가 저장될 파티션

배치 (batch)

• 같은 토픽의 파티션에 쓰여지는 메세지들의 집합
• 효율성을 위해 메세지를 배치 단위로 저장
  • 메세지 작성마다 네트워크 I/O가 발생하는 것은 막대한 오버헤드 발생시킴
  • 배치 단위로 저장하면 오버헤드 감소
  • 단, 지연(latency)과 처리량(throughput) 트레이드오프는 발생됨
  • 배치 크기 커짐 (↑) → 시간당 처리량 (↑) + 각각의 메세지 전달 지연 (↑)

• 내용을 이해하기 쉽도록 부여된 일정한 구조
• 스키마 포맷에는 Avro, Protobuf, JSON, XML 등 존재

Apache Avro (아파치 에이브로)

• 바이너리 직렬화 포맷으로 가장 많이 사용됨

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "type": "record",
  "name": "User",
  "namespace": "com.example",
  "fields": [
    {"name": "id", "type": "long"},
    {"name": "name", "type": "string"},
    {"name": "email", "type": "string"},
    {"name": "age", "type": ["null", "int"], "default": null}
  ]
}

장점

• 조밀한 직렬화 형식 제공으로 압축률 높음 → 네트워크 대역폭 절약
• 메세지 본체와 스키마가 분리되어 저장되므로 코드 생성 필요 ❌ → 공간 효율적
• 강력한 데이터 타이핑 (변수의 데이터 타입 지정하는 행위)
• 스키마 변경에 따른 상위/하위 호환성 지원

단점

• 바이너리 포맷이라 사람이 읽기 어려움
• 스키마 정의가 복잡할 수 있음
• 디버깅 시 별도 도구 필요

Protobuf (Protocol Buffers)

• Google에서 개발한 언어 중립적 직렬화 메커니즘

1
2
3
4
5
6
7
8

syntax = "proto3";

message User {
  int64 id = 1;
  string name = 2;
  string email = 3;
  optional int32 age = 4;
}

장점

• 강력한 타입 시스템과 코드 생성
• gRPC와의 자연스러운 통합
• 높은 성능과 작은 메시지 크기 (avro 보다도 작음)
• 다양한 언어 지원

단점

• 스키마 진화 규칙 엄격
  • 필드 번호는 바이너리 인코딩의 핵심이므로 한 번 할당되면 절대 변경할 수 없게 되어 변경 시 기존 데이터를 완전히 다르게 해석하게 됨
• JSON 대비 가독성이 떨어짐

JSON

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "$schema": "<http://json-schema.org/draft-07/schema#>",
  "type": "object",
  "properties": {
    "id": {"type": "integer"},
    "name": {"type": "string"},
    "email": {"type": "string", "format": "email"},
    "age": {"type": "integer", "minimum": 0}
  },
  "required": ["id", "name", "email"]
}

장점

• 사람이 읽기 쉽고 이해하기 용이
• 웹 개발자들에게 친숙함
• 디버깅이 쉬움
• 다양한 도구와 라이브러리 지원

단점

• 메시지 크기가 큼
• 바이너리 포맷 대비 성능이 떨어짐
• 스키마 진화 지원이 제한적

요약 비교표 (ChatGPT)

스키마를 통한 일관적인 데이터 형식이 중요한 이유

• 메세지 쓰기 / 읽기 작업을 분리하기 때문
• 이 작업들이 결합되어 있으면 구버전/신버전 형식을 동시에 지원할 수 있도록 업데이트 될 것
• 잘 정의된 스키마를 공유 저장소에 저장함으로써 카프카는 두 버전 형식을 지원하는 작업 없이도 메세지 처리 가능

토픽 (Topic)

• 카프카에 저장되는 메세지가 분류되는 방법
• DB의 테이블, 파일 시스템의 폴더와 비슷한 개념
• 여러 개의 파티션으로 이루어짐

파티션 (Partition)

• 커밋 로그의 관점에서, 파티션은 하나의 로그
• 메세지가 write 될 때는 append-only 형태로 작성됨
• 메세지가 read 될 때는 맨 앞에서부터 마지막까지 순서대로 읽어짐 (큐, FIFO)
• 파티션의 각 메세지는 고유한 오프셋 가짐
• 카프카가 데이터 중복과 확장성을 제공하는 방법
  • 각 파티션이 서로 다른 서버에 저장 가능 🟢
  • 하나의 토픽이 여러 개의 서버로 수평 확장(scale-out)되어 성능 향상 가능 🟢
  • 파티션은 복제 가능 🟢
  • 서로 다른 서버들이 동일한 파티션의 복제본을 저장할 수 있어서, 특정 서버에 장애가 발생한다고 해도 read, write 불가능한 상황 발생하지 않음 → SPOF 예방

토픽 > 여러 개의 파티션 > 각각의 파티션에 여러 개의 메세지

• 토픽 내부 메세지 전체에 대한 순서는 보장 ❌
• 단일 파티션 안에서 메세지 순서 보장 🟢

스트림 (Stream)

• 하나의 토픽에 저장된 데이터
• 메세지의 집합
• 프로듀서로부터 컨슈머로의 하나의 데이터 흐름
• 시간이 흐른 뒤 데이터를 한꺼번에 대량으로 처리하는 하둡(Hadoop) 같은 오프라인 프레임워크와 대비됨

카프카 클라이언트 (Kafka Client)

• 카프카 시스템의 사용자
• 프로듀서 / 컨슈머
• 고급 클라이언트
  • 카프카 커넥트(Kafka Connect) API
  • 카프카 스트림즈(Kafka Streams)
  • 고급 클라이언트들은 프로듀서/컨슈머를 기본적인 요소로 사용하며, 더 고차원적인 기능 제공

프로듀서 (Producer)

• 새로운 메세지 생성
• 발행자 (Publisher)
• 작성자 (Writer)
• 토픽에 속한 파티션들 사이에 고르게 메세지를 작성하도록 되어있음
• 특정한 파티션을 지정해서 메세지를 작성하기도 함
  • 파티셔너 (Partitioner) 를 사용하여 구현됨
    • 메세지 키, 키 값의 해시를 특정 파티션으로 대응시켜주는 행위자

컨슈머 (Consumer)

• 발행된 메세지를 읽음
• 구독자 (Subscriber)
• 독자 (Reader)
• 1개 이상의 토픽을 구독하여 각 파티션에 쓰여진 순서대로 저장된 메세지들을 읽어옴
• 메세지의 오프셋 기록하여 어디까지 읽었는지 유지

오프셋 (Offset)

• 지속적으로 증가하는 정수값
• 카프카가 메세지 저장 당시, 각각의 메세지에 부여해주는 메타데이터
• 앞의 메세지 오프셋 < 뒤의 메세지 오프셋
• 단조증가할 필요 ❌
• 오프셋 값은 대체로 카프카 자체에 저장됨
• 오프셋 덕분에 컨슈머는 읽기 작업을 정지했다가 다시 시작해도 마지막으로 읽었던 메세지의 바로 다음 메세지부터 읽기 가능 🟢

컨슈머 그룹 (Consumer Group)

• 토픽에 저장된 데이터를 읽어오기 위해 협업하는 하나 이상의 컨슈머로 구성됨
• 각 파티션이 하나의 컨슈머에 의해서만 읽히도록 함
• 컨슈머의 파티션 소유권 (Ownership) : 컨슈머 → 파티션으로 대응되는 관계
• 대량의 메세지를 갖는 토픽들을 읽기 위해 컨슈머들을 수평 확장할 수 있음 🟢
• 컨슈머 중 하나에 장애가 발생해도, 그룹 내부 다른 컨슈머들이 파티션을 재할당 받고 이어서 데이터 읽기 가능 🟢

브로커 (Broker)

• 하나의 카프카 서버
• 프로듀서로부터 메세지를 전달 받음 → 오프셋 할당 → 디스크 저장소에 쓰기 작업
• 컨슈머로부터 파티션 읽기 요청 받음 → 처리하고 발행된 메세지 보내줌
• 1s 당 수천 개의 파티션, 수백만 개의 메세지 처리 가능 🟢
• 파티션은 클러스터 안의 브로커 중 하나가 담당
  • 해당 브로커를 파티션 리더(Partition Leader) 라고 함

클러스터 (Cluster)

• 클러스터의 일부로서 카프카 브로커가 작동하도록 설계됨
• 1개의 클러스터 안에 여러 개의 브로커가 포함
  • 클러스터 컨트롤러 (Cluster Controller)
    • 클러스터에서 현재 작동 중인 브로커 중 하나가 자동으로 선정
    • 브로커에 대한 여러 관리 기능 제공
      • 파티션을 브로커에 할당
      • 장애가 발생한 브로커를 모니터링
• 카프카 클러스터는 작동 중에도 전체의 가용성(Availability)에 영향을 주지 않으면서 확장 가능 🟢

파티션 리더 (Partition Leader) / 파티션 팔로워 (Partition Follower)

• 파티션의 입장에서 봤을 때, 본인을 담당하는 브로커 → 파티션 리더
• 나머지 복제본 → 파티션 팔로워
• 복제(Replication)를 통해 리더 브로커에 장애 발생 시, 팔로워 중 하나가 리더 역할을 이어받을 수 있도록 함
• 모든 프로듀서는 리더 브로커에 메세지를 발행해야만 함
• 컨슈머는 리더나 팔로워 중 어느것으로부터 데이터를 읽어와도 상관없음

• 그림 출처 : 오늘도 개발중입니다 블로그 - Kafka(카프카) 파티션(partition) 쉽게 이해하기

카프카 클러스터의 복제 메커니즘

• 다중 클러스터 사이에서가 아닌, 하나의 클러스터 안에서만 작동되도록 설계
• 다른 클러스터로 복제할 때는 미러메이커(MirrorMaker) 같은 툴 사용

메세지 보존 (Retention)

• 일정 기간 동안 메세지를 지속성(Durability) 있게 보관하는 카프카의 핵심 기능
• 카프카 브로커는 토픽에 설정된 보존 옵션으로 특정 기간 동안 메세지를 보존 / 파티션의 크기가 특정 사이즈에 도달할 때까지 데이터를 보존 가능
  • 한도에 도달 시, 메세지는 만료되어 삭제됨
• 사용 예시
  • e.g. 사용자 활동 추적 토픽은 며칠 동안 보존
  • e.g. 애플리케이션 지표는 몇 시간만 보존

로그 압착 (Log Compaction)

• 같은 키를 갖는 메세지 중 가장 최신의 것만 보존됨
• 마지막 변경 값만이 중요한 체인지 로그(Change Log) 형태의 데이터에 사용하면 유용함

장점

• 데이터 유형별 분리
• 보안 요구사항을 충족시키기 위한 격리
• 재해 복구 (DR, Disaster Recovery) 대비한 다중 데이터센터

위에서 다중 클러스터 간 복제를 위해 미러메이커(MirrorMaker) 같은 툴을 사용한다고 했다.

• 미러메이커도 큐로 연결된 카프카 컨슈머와 프로듀서에 불과함
• 하나의 카프카 클러스터에서 메세지를 읽어옴 → 다른 클러스터에 쓰기 작업

다중 데이터센터 이중화 아키텍처에서 아래와 같은 방식 채용 가능

• Active - Active 구성
  • 서로 독립적인 카프카 클러스터를 양쪽 데이터센터에 구성하는 방식
  • MM2 (MirrorMaker2) 같은 툴을 이용해 양방향 데이터 미러링 필요
• Stretched Cluster 구성
  • 양쪽 데이터센터에 분리된 노드를 하나의 Kafka 클러스터로 묶어서 구성
  • 물리적으로 분리돼있지만, 한 개의 Kafka 클러스터라 별도 데이터 미러링 작업이 필요 없이 동기화 됨
• 자세한 내용은 토스 테크 블로그 참고
  • # 토스증권 Apache Kafka 데이터센터 이중화 구성 #1
  • # 토스증권 Apache Kafka 데이터센터 이중화 구성 #2

• 프로듀서 클라이언트가 여러 토픽을 사용하든 하나의 토픽을 사용하든 여러 프로듀서로 처리 가능
  • 프론트엔드 시스템으로부터 데이터를 수집하고 일관성을 유지하는 데 적격
  • e.g. MSA 환경에서 모든 서비스가 공통의 형식으로 쓰는 페이지 뷰용 토픽
    • 컨슈머 애플리케이션은 사이트의 모든 애플리케이션에 대한 페이지 뷰 스트림 하나만 읽어오면 됨

• 여러 컨슈머가 상호 간섭 없이 어떠한 메세지 스트림도 읽을 수 있도록 설계됨
• 하나의 메세지를 하나의 클라이언트에서만 소비할 수 있도록 되어있는 큐(queue) 시스템과의 결정적인 차이점
• 컨슈머 그룹의 일원으로 작동하는 카프카 컨슈머는 하나의 스트림을 여럿이서 나눠서 읽을 수 있음
  • 컨슈머 그룹 : 각 파티션이 하나의 컨슈머에 의해서만 읽히도록 제어
  • 스트림 : 하나의 토픽에 저장된 데이터, 메세지의 집합
  • 즉, 하나의 토픽안의 여러 파티션을 상호 간섭 없이 읽을 수 있다는 의미
  • 메세지는 전체 컨슈머 그룹에서 한 번만 처리됨을 보장

• 메세지를 지속성(Durability) 있게 저장
  • 컨슈머들이 항상 실시간으로 데이터를 읽어올 필요는 없다는 의미
• 메세지는 디스크에 쓰여진 뒤, 보유 규칙과 함께 저장됨
  • 해당 옵션은 토픽별로 설정 가능 🟢
  • 서로 다른 메세지 스트림이 컨슈머의 필요에 따라 서로 다른 기간 동안 보존 가능 🟢
  • 느린 처리 속도, 트래픽 폭주 등으로 뒤처지는 경우 데이터 유실 위험 ❌

• 유연한 확장성을 가지고 있어서, 아래의 전환이 수월함
  • e.g. 개발 환경에서는 1개의 클러스터 (3개의 브로커로 구성됨)
  • e.g. 운영 환경에서는 다중 클러스터 (수백 개의 브로커로 구성됨)
• 카프카 클러스터는 작동 중에도 전체의 가용성(Availability)에 영향을 주지 않으면서 확장 가능 🟢
  • 여러 대의 브로커로 구성된 클러스터는 개별 브로커의 장애를 처리하면서 지속적으로 클라이언트의 요청을 받아서 처리할 수 있다는 의미
  • 동시다발적인 장애를 견뎌야하는 상황 → 더 큰 복제 팩터 (RF, Replication Factor) 설정해주는 것 가능

• 발행된 메세지가 컨슈머에게 전달될 때까지 1s도 걸리지 않음
• 프로듀서/컨슈머/브로커 모두 큰 메세지 스트림을 쉽게 다룰 수 있도록 수평적 확장 🟢

• 개발자들이 자주하는 작업을 쉽게 수행할 수 있도록 해주는 기능 제공
• 카프카 커넥트(Kafka Connect)
  • 소스 데이터 시스템 → 카프카로 데이터를 가져옴
  • 카프카의 데이터 → 싱크 시스템으로 내보냄
• 카프카 스트림즈(Kafka Streams)
  • 규모 가변성, 내고장성 갖춘 스트림 처리 애플리케이션 개발 수월하게 도와줌
  • 규모 가변성 : 파티션 수를 늘려 컨슈머를 병렬처리 하는 능력
  • 내고장성 : 브로커 장애 시 다른 브로커가 리더 파티션을 인계받는 능력
    • 이 둘이 합쳐져 데이터 유실 없이 트래픽 증가 대응 가능

규모 가변성(scalability)

• 정의
  • 시스템이 부하(트래픽, 사용자 수, 데이터량 등)가 증가할 때, 성능 저하 없이 확장될 수 있는 능력
• 분류
  • 수평 확장 (Horizontal scaling, Scale Out)
  • 수직 확장 (Vertical scaling, Scale Up)
• 예시
  • Kafka : 파티션 수를 늘려 컨슈머 병렬 처리
  • MySQL : 읽기 성능 확장을 위한 read-replica 구성
  • Redis : 샤딩을 통해 데이터 분산
• 처리량 확장이 중요 !

내고장성(fault tolerance)

• 정의
  • 일부 구성 요소가 장애를 일으켜도 전체 시스템이 정상 동작을 유지할 수 있는 능력
• 방법
  • 중복(Replication): 데이터나 서비스 복제 → 마스터/슬레이브 구조
  • 헬스 체크 & Failover: 고장 감지 후 자동 전환
  • 장애 격리: 장애가 전체 시스템에 전파되지 않도록 차단
• 예시
  • Kafka: 브로커 장애 시 다른 브로커가 리더 파티션을 인계받음
  • Kubernetes: Pod 장애 시 자동 재시작
  • MySQL + MHA or ProxySQL: 마스터 장애 시 슬레이브 자동 승격
• 장애 발생은 전제이고, 그때 시스템을 멈추지 않는 설계가 핵심

• 품질, 크기, 용도가 제각각인 다양한 유형의 데이터에 대해 수행될 것
• 카프카는 이러한 데이터 생태계에 있어서 순환 시스템을 제공
  • 모든 클라이언트에 대해 일관된 인터페이스 제공
  • 다양한 인프라 요소 사이에서 메세지 전달
  • 메세지 스키마를 제공하는 시스템과 결합 → 프로듀서와 컨슈머는 밀접하게 결합되거나 연결될 필요 ❌

• 사용자가 특정 행동 시, 프론트엔드 애플리케이션에서 메세지 생성
  • e.g. 수동적인 정보 : 페이지 뷰, 클릭 추적
  • e.g. 복잡한 정보 : 사용자가 프로필 화면에 추가한 정보
• 하나 이상의 토픽으로 발행되어 백엔드 애플리케이션에 전달
  • e.g. 보고서 생성, 기계 학습 시스템에 데이터 전달, 검색 결과 업데이트 등

• 사용자에게 이메일 같은 알림을 보내야 할 때 활용
• 메세지 형식, 전송 방법 신경쓰지 않고 메세지 생성
• 애플리케이션이 전송할 메세지를 모두 읽어와서 같은 방식으로 처리 가능
  • (1) 룩앤필(Look And Feel, 사용자의 제품 체험과 겉모양, 인터페이스의 주된 기능) 사용하여 메세지를 포매팅 or 데코레이팅
  • (2) 여러 메세지를 모아서 하나의 알림 메세지로 전송
  • (3) 사용자가 원하는 메세지 수신 방식 적용
• 여러 애플리케이션에 기능을 중복해서 구현할 필요 ❌
• 메세지 누적과 같은 기능도 지원 가능 🟢

• 지푯값과 로그 같이 여러 애플리케이션이 같은 유형으로 생성한 메세지를 활용하는 대표적인 사례
• 정기적으로 지푯값을 카프카 토픽에 발행 → 모니터링, 경보를 맡고 있는 시스템이 가져다가 사용
• 하둡(Hadoop) 같이 오프라인 시스템에서 성장률 예측 같이 보다 장기적인 분석을 위해 활용 가능
• 엘라스틱서치(Elastic Search) 같은 로그 검색 전용 시스템, 보안 분석 애플리케이션에서 로그메세지 활용 가능
• e.g. 로그 저장시스템을 변경할 때, 프론트엔드 애플리케이션이나 메세지 수집 방법을 변경할 필요 ❌

• DB에 가해진 변경점들이 스트림의 형태로 카프카로 발행 가능
• 애플리케이션은 이 스트림을 구독하여 실시간 업데이트를 받아볼 수 있음
• 이러한 체인지 로그 스트림은 DB에 가해진 업데이트를 원격 시스템으로 복제 가능 🟢
• 다수의 애플리케이션에서 발생한 변경점을 하나의 DB 뷰로 통합하는데 사용 가능 🟢
• 메세지 보존 기능 → 체인지로그를 저장하는 버퍼로 사용 가능 🟢 → 컨슈머가 실패한 경우 다시 읽어오면 되니까
• 로그 압착 기능 → 로그를 더 오랫동안 보존 가능 🟢

• 카프카의 스트림 처리 → 하둡(Hadoop)의 맵리듀스(Map Reduce) 같은 기능을 수행하는 애플리케이션 가리킴
  • 하둡 : 오랜 시간에 걸쳐 누적된 데이터 처리
  • 스트림 처리 : 메세지가 생성되자마자 실시간으로 데이터를 처리
• 스트림 처리 프레임워크 사용
  • 카프카 메세지를 처리하는 작은 애플리케이션 작성
  • 각종 지푯값 계산
  • 다른 애플리케이션이 효율적으로 처리할 수 있게 메세지 파티셔닝
  • 다수의 원본으로부터 들어온 데이터를 사용하여 메세지 변환

복잡한 요청 추적 기능 : 하나의 사용자 요청이 여러 애플리케이션에 어떻게 전파되는지 보여주는 것

• 폴링 방식으로 수집되는 지표들의 수집 간격이 김
• 애플리케이션 담당자가 자신의 애플리케이션에서 수집된 지표를 관리할 수 없음
• 간단한 작업도 사람이 직접 다 만져야함
• 똑같은 측정값도 시스템이 다르면 지표 이름이 달라져 일관성 깨짐

사용자 활동 추적 시스템 : 프론트엔드에서 시스템에 주기적으로 접속해 XML 형식 메세지 배치를 쏟아넣음

• XML 형식 일관성 ❌, 파싱하는데 많은 컴퓨팅 자원 소모
• 추적되는 사용자 유형 변경 시, 프론트엔드와 오프라인 처리 시스템에 많은 추가 작업 필요
• 추적 작업이 시간 단위로 처리되어 실시간으로 활용 ❌

배치 처리가 아니면서 데이터에 실시간으로 접근 가능하면서 메세지 트래픽을 처리하기 수월하게 scale out이 가능한 시스템을 찾아떠남

• ActiveMQ를 사용해봤지만 규모 확장성 ↓
• 브로커를 정지시킬 수 있는 결함들이 많음

모니터링 시스템, 사용자 추적 시스템의 요구 조건 만족 + scale out 수월한 메세지 교환 시스템 개발

• push-pull 모델 사용하여 프로듀서와 컨슈머 분리 (decouple)
• 다수의 컨슈머가 사용할 수 있도록 메세지 교환 시스템의 데이터를 영속적으로 저장
• 높은 메세지 처리량 보이도록 최적화
• 데이터 스트림의 양이 증가 → 시스템을 scale-out 할 수 있도록
• 2020년 7월 기준 매일 7조 개의 메세지를 쓰고 5페타바이트가 넘는 데이터를 읽을 수 있는 시스템으로 성장