Day 4 - Amazon MSK(Kafka): 토픽, 파티션, 언제 무엇

Kafka의 구조: 토픽과 파티션

스트리밍 수집 도구의 마지막 조각은 Amazon MSK(Managed Streaming for Apache Kafka) 다. Kinesis가 AWS 고유의 스트리밍 서비스라면, Kafka는 업계 표준 오픈소스 스트리밍 플랫폼이고 MSK는 그 Kafka를 AWS가 관리형으로 제공하는 서비스다.

핵심 질문은 어제와 같다: "Kinesis가 있는데 왜 MSK인가? 언제 무엇을 쓰나?" 오늘은 Kafka의 기본 개념(토픽·파티션·컨슈머 그룹)을 잡고, Kinesis와 정확히 어디서 갈리는지를 본다. DEA-C01에서 이 비교는 거의 반드시 나온다.

Kafka에서 데이터는 토픽(topic) 단위로 분류된다. 토픽은 "주제별 로그"라고 보면 된다(예: orders, clicks, sensor-data). 각 토픽은 다시 여러 파티션(partition) 으로 쪼개진다. 파티션이 Kafka의 병렬성·처리량 단위다.

토픽: orders
 ├─ 파티션 0:  [msg0][msg1][msg2] ...   ← append-only 로그, 순서 보장
 ├─ 파티션 1:  [msg0][msg1] ...
 └─ 파티션 2:  [msg0][msg1][msg2][msg3] ...

눈치챘겠지만 구조가 KDS와 거의 같다. 토픽 ≈ 스트림, 파티션 ≈ 샤드다. 프로듀서가 메시지를 보낼 때 키를 지정하면 그 키로 어느 파티션에 갈지 결정되고, 한 파티션 안에서는 순서가 보장된다. KDS의 파티션 키 개념과 동일하다.

from kafka import KafkaProducer
producer = KafkaProducer(bootstrap_servers="b-1.msk.amazonaws.com:9092")
 
# 키(user-8821)가 파티션을 결정 → 같은 사용자 메시지는 같은 파티션, 순서 보장
producer.send("orders", key=b"user-8821", value=b'{"item":"book","qty":2}')
producer.flush()

💡 관련 이론: Kafka와 Kinesis는 둘 다 "분산 append-only 로그" 모델을 공유한다. 메시지를 소비해도 사라지지 않고(retention 동안 보관), 여러 컨슈머 그룹이 각자의 오프셋(offset)에서 독립적으로 읽는다. 이 점에서 둘 다 SQS 같은 전통 큐와 근본적으로 다르다. 그래서 Kafka 경험자는 Kinesis를 빠르게 이해하고, 반대도 마찬가지다. 시험은 이 "개념적 1:1 대응"을 알고 있는지 확인한다.

컨슈머 그룹과 오프셋

컨슈머들은 컨슈머 그룹(consumer group) 으로 묶인다. 한 그룹 안에서는 파티션이 컨슈머들에게 분배되어, 각 파티션은 그룹 내 한 컨슈머만 읽는다(병렬 처리). 서로 다른 그룹은 같은 토픽을 독립적으로 전부 읽는다(팬아웃).

각 컨슈머 그룹은 자신이 어디까지 읽었는지를 오프셋(offset) 으로 기록한다. KDS의 체크포인트(KCL이 DynamoDB에 저장)와 같은 개념이다.

토픽 orders (파티션 3개)
 ├─ consumer-group-A (실시간 결제처리)  : 파티션0→C1, 파티션1→C2, 파티션2→C3
 └─ consumer-group-B (데이터레이크 적재) : 동일 토픽을 독립 오프셋으로 별도 소비

💡 관련 이론: 컨슈머 수가 파티션 수를 넘으면 초과 컨슈머는 놀게 된다(한 파티션은 그룹 내 한 컨슈머만 읽으므로). 따라서 처리량을 늘리려면 컨슈머만 늘리는 게 아니라 파티션 수를 충분히 잡아야 한다. 이는 KDS에서 컨슈머를 늘려도 샤드가 부족하면 병렬성이 제한되는 것과 같은 원리다. "병렬성의 상한 = 파티션(샤드) 수"라는 공식이 양쪽에 공통으로 적용된다.

MSK: 관리형이지만 Kafka는 Kafka다

MSK는 Kafka 브로커·주키퍼(또는 KRaft)의 프로비저닝·패치·장애 복구를 AWS가 대신해준다. 하지만 여전히 클러스터·브로커·파티션을 사용자가 인식하고 설계해야 한다. 완전 서버리스가 필요하면 MSK Serverless가 용량을 자동 관리한다.

- MSK (Provisioned): 브로커 인스턴스 타입·수를 지정, 세밀한 제어
- MSK Serverless    : 용량 자동, 사용량 과금, 운영 부담 최소
- MSK Connect       : 관리형 Kafka Connect (소스/싱크 커넥터로 시스템 연동)

Kinesis vs MSK: 언제 무엇을

이게 오늘의 핵심이다.

핵심 판단 기준은 단순하다.

• 이미 Kafka를 쓰고 있다(코드·커넥터·팀 역량) → MSK. 기존 Kafka 애플리케이션을 코드 변경 거의 없이 그대로 옮길 수 있다(리프트 앤 시프트).
• AWS에서 새로 시작하고 운영 부담을 최소화하고 싶다 → Kinesis. 특히 단순 적재면 Firehose.
• 온프레미스/멀티클라우드 이식성이 중요하다 → Kafka(MSK). Kinesis는 AWS에 종속된다.

시험에서 결정적 키워드는 "기존 Apache Kafka 워크로드/애플리케이션"이다. 이 표현이 나오면 MSK가 정답일 가능성이 크다. Kafka 생태계(Kafka Connect, Kafka Streams, 기존 토픽 설계, 컨슈머 코드)를 재사용해야 하기 때문이다. 반대로 "최소 운영 부담", "서버리스", "AWS 네이티브 신규 구축", "단순 S3/Redshift 적재" 같은 표현이면 Kinesis 쪽이다. 두 서비스는 기능이 겹치므로, 정답은 기술적 우열이 아니라 "기존 자산과 운영 모델"로 갈린다.

데이터 적재로 잇기

MSK에 들어온 데이터를 분석 스택으로 보내는 방법은 다음과 같다. MSK Connect의 싱크 커넥터(예: S3 Sink)로 토픽 데이터를 S3에 적재하거나, Kafka를 소비하는 Lambda·Flink(Amazon Managed Service for Apache Flink)로 실시간 처리 후 다운스트림에 보낸다. KDS와 마찬가지로 "수집 → 처리 → 적재"의 흐름은 동일하다.

복제와 내구성: Kafka 가 데이터를 지키는 방식

Kinesis 는 복제를 서비스가 알아서 처리해 사용자가 만질 값이 없다. Kafka 는 내구성을 설정으로 조립한다. MSK 가 관리형이어도 이 설정의 책임은 사용자에게 남는다.

토픽 orders, 파티션 0, 복제 계수(replication factor) 3
  브로커 1 (AZ-a) : 리더      ← 프로듀서·컨슈머가 붙는 곳
  브로커 2 (AZ-b) : 팔로워    ← 리더를 따라 복제
  브로커 3 (AZ-c) : 팔로워
  ISR(in-sync replicas) = 리더를 제때 따라잡고 있는 복제본 집합

• 유실 없는 구성의 표준은 복제 계수 3 + min.insync.replicas=2 + 프로듀서 acks=all 이다. 브로커 하나가 죽어도 쓰기가 계속되고, 확인된 메시지는 최소 두 곳에 있다.
• MSK 의 기본 클러스터 구성은 3개 AZ 클러스터에서 기본 복제 계수 3, min.insync.replicas 2 다(2개 AZ 클러스터는 각각 2와 1). 토픽 자동 생성(auto.create.topics.enable)은 기본으로 꺼져 있고 기본 파티션 수는 1 이다.
• acks=1 로 보내면 리더가 받고 복제 전에 죽었을 때 메시지가 사라진다. "브로커 장애 뒤 일부 메시지가 없다"는 지문의 원인이 대개 이것이다.
• 브로커 장애가 나면 MSK 가 감지해 교체하고, 가능하면 기존 스토리지를 재사용해 다시 복제할 양을 줄인다. 복구 뒤에도 브로커 주소는 유지된다.

Kafka 는 클러스터 메타데이터를 과거에는 Apache ZooKeeper 에 두었고, 최근 버전은 Kafka 내부 컨트롤러 그룹이 직접 관리하는 KRaft 모드로 옮겨 가고 있다. MSK 는 두 방식을 모두 제공하고, ZooKeeper 노드든 KRaft 컨트롤러든 추가 비용 없이 MSK 가 운영한다. 시험에서는 "ZooKeeper 를 직접 운영해야 하나"가 아니라 "MSK 가 대신 운영한다"는 사실만 알면 된다.

클러스터 유형 세 가지

"MSK"라고 해서 다 같은 운영 부담이 아니다.

• "Kafka 호환 + 운영 부담 최소"가 함께 나오면 MSK Serverless 다. 다만 SASL/SCRAM 이나 상호 TLS 로 인증하는 기존 클라이언트를 그대로 붙여야 한다는 조건이 있으면 Serverless 는 맞지 않는다.
• Serverless 의 파티션당 유입 한도는 고정이라, 한 키에 트래픽이 몰리는 워크로드는 프로비저닝이 낫다.

인증·권한·네트워크

Kinesis 는 리전 엔드포인트에 IAM 으로 호출하면 끝이다. MSK 는 VPC 안의 브로커에 접속하는 구조라 네트워크와 인증을 따로 설계한다.

• IAM 액세스 제어는 인증과 권한을 IAM 정책 하나로 처리한다. 다른 AWS 서비스(Lambda, Firehose, Glue)에서 붙을 때 가장 단순하다.
• 기존 Kafka 클라이언트가 SASL/SCRAM 을 쓰고 있었다면 자격 증명을 Secrets Manager 에 넣고 클러스터에 연결한다.
• 브로커는 사용자 VPC 의 서브넷에 놓인다. 컨슈머가 다른 VPC·계정에 있으면 VPC 피어링, Transit Gateway, 다중 VPC 프라이빗 연결 중 하나가 필요하다. "Lambda 가 MSK 에 연결하지 못한다"의 원인은 대개 서브넷·보안 그룹이다.
• Glue 의 Kafka 연결은 TLS 엔드포인트만 지원한다. 본문 예시의 9092(평문)는 학습용이고, 운영에서는 전송 구간 암호화를 켠 포트를 쓴다.

파티션 수는 한 번 정하면 되돌리기 어렵다

• 그래서 Kafka 는 처음부터 파티션을 넉넉히 잡는 것이 관례다. 다만 파티션이 많을수록 브로커 메모리·파일 핸들·리더 선출 시간이 늘어나므로, 브로커 크기별 권장 파티션 수 안에서 잡는다.
• 파티션 수는 "목표 처리량 ÷ 파티션당 처리량"과 "필요한 컨슈머 병렬도" 중 큰 쪽으로 정한다. 컨슈머 10개를 병렬로 돌리려면 파티션이 최소 10개다.
• 키가 있는 메시지는 키 해시로, 키가 없는 메시지는 프로듀서가 파티션에 고르게 흩뿌린다. 순서가 필요 없으면 키를 비워 두는 것이 분산에 유리하다.

보존: 시간 기준과 로그 컴팩션

• Kafka 의 기본 보존은 시간 기준 삭제다. 기본값은 7일이고 토픽별로 바꾼다(retention.ms). 크기 기준(retention.bytes)도 함께 걸 수 있다.
• 로그 컴팩션(cleanup.policy=compact)은 Kinesis 에 없는 기능이다. 같은 키의 옛 값을 지우고 키마다 최신 값 하나만 남긴다. "고객별 현재 상태"를 토픽에 영구히 들고 있으면서 새 컨슈머가 처음부터 읽어 상태를 복원하는 용도다.
• 장기 보존이 필요하면 Standard 브로커의 계층형 스토리지로 오래된 세그먼트를 저비용 계층에 내리거나, 처음부터 S3 로 적재해 두고 재처리는 S3 에서 한다.
• Kinesis 는 기본 24시간, 최대 365일이다. 보존을 늘릴수록 요금이 붙는다는 점은 양쪽이 같다.

MSK 를 분석 스택에 잇는 길

• MSK Connect 는 MSK 클러스터뿐 아니라 VPC 에서 닿는 자체 운영 Kafka 에도 붙을 수 있다. 커넥터 워커를 자동 확장하거나 고정 용량으로 둘 수 있다.
• "온프레미스 Kafka Connect 클러스터를 운영 부담 없이 옮긴다"는 MSK Connect, "커넥터를 모른다, 그냥 S3 에 쌓고 싶다"는 Firehose 다.

Kinesis vs MSK: 숫자와 동작으로 다시 보기

• 메시지 크기가 크거나, 토픽이 수백 개이거나, 컨슈머 그룹이 수십 개인 경우는 Kafka 모델이 자연스럽다. 스트림 몇 개에 컨슈머 몇 개인 단순한 구조는 Kinesis 가 운영이 가볍다.

지문 단서 → 정답 판별표

내일은 이번 주에 배운 배치 4종과 스트리밍 3종을 하나의 의사결정 지도로 묶어 복습한다.

📖 용어

• 브로커 : Kafka 클러스터를 이루는 서버 한 대. 파티션 데이터를 저장하고 프로듀서·컨슈머의 요청을 받는다.
• 토픽 / 파티션 : 메시지를 주제별로 나눈 로그와, 그 로그를 병렬 처리하려고 쪼갠 단위.
• 오프셋 : 파티션 안에서 메시지의 순번. 컨슈머 그룹이 어디까지 읽었는지 이 번호로 기록한다.
• 컨슈머 그룹 : 같은 일을 나눠 맡는 컨슈머 묶음. 그룹 안에서는 파티션을 나눠 읽고, 그룹끼리는 서로 독립이다.
• 복제 계수 : 파티션 하나를 몇 개의 브로커에 복사해 둘지 정한 수.
• ISR(in-sync replicas) : 리더를 제때 따라잡고 있는 복제본 집합. 쓰기 성공 판정의 기준이 된다.
• acks : 프로듀서가 "보냈다"고 인정받기 위해 몇 개의 복제본 확인을 기다릴지 정하는 설정.
• 로그 컴팩션 : 같은 키의 옛 메시지를 지우고 키마다 최신 값만 남기는 보존 방식.
• Kafka Connect : Kafka 와 외부 시스템(DB, S3 등)을 코드 없이 잇는 커넥터 프레임워크. MSK Connect 가 이를 관리형으로 제공한다.
• 리프트 앤 시프트 : 애플리케이션을 거의 고치지 않고 그대로 옮기는 마이그레이션 방식.