10. 운영

온프렘 Kafka 운영의 90%는 세 숫자를 보는 일이다 — 랙, URP, 디스크

이 장에서 처음 나오는 말5개

URPUnder-Replicated Partitions: 복제본이 ISR에서 빠져 "정해진 만큼 복제되지 못한" 파티션 수. 0이 정상 — 0이 아니면 클러스터 어딘가가 아프다.
SASL/SCRAMSimple Authentication and Security Layer / Salted Challenge Response Authentication Mechanism: Kafka에서 흔히 쓰는 사용자명 · 비밀번호 기반 인증 방식. 비밀번호를 평문으로 보내지 않는다.
mTLSmutual TLS: 서버뿐 아니라 클라이언트도 인증서로 신원을 증명하는 TLS. Strimzi가 인증서 발급을 자동화해 준다.
ACLAccess Control List: "이 계정은 이 토픽에 읽기만" 식의 권한 목록. Kafka 인가(authorization)의 기본 수단이다.
Cruise Control: 파티션 배치를 분석해 브로커 간 부하를 자동 재배치하는 컴포넌트. Strimzi에 내장 옵션으로 있다.

모니터링 — 세 지표부터

Prometheus + Grafana 조합이 표준이다. Strimzi가 브로커 JMX 지표의 Prometheus 노출을 설정으로 지원하고, 컨슈머 랙은 kafka-exporter(Strimzi 내장 옵션)가 뽑아 준다. 공식 예제 대시보드가 있어 첫 구성은 그대로 가져다 쓰면 된다.

지표	무엇을 말하나	알람 기준
컨슈머 랙	소비가 생산을 따라가는가 (5장)	단조 증가가 지속되면 — 절대값보다 추세다
URP	복제가 온전한가	0이 아니면 — 브로커 다운 · 디스크 · 네트워크 어딘가의 신호
디스크 사용률	보존 계산이 현실과 맞는가	70%에서 경고 — 만석은 최악 장애다(11장)

이 셋이 잡히면 그다음이 active controller 수(항상 1), 요청 지연, 리더 선출 빈도다 — 하지만 셋 없이 그다음은 없다.

보안 — 기본값은 전부 열려 있다

Kafka의 기본 상태는 평문 통신 · 무인증 · 무인가다. 사내망이라도 “아무 파드나 붙어서 아무 토픽이나 읽고 쓸 수 있는” 상태로 두는 것은, 개인정보·주문 데이터가 흐르기 시작하는 순간 감사 지적 사항이 된다. 세 층을 각각 잠근다 —

층	수단	Strimzi에서
암호화	리스너 TLS	`listeners[].tls: true` — 인증서는 오퍼레이터가 발급·갱신
인증	mTLS 또는 SASL/SCRAM	`KafkaUser` CRD가 인증서/비밀번호를 Secret으로 만들어 준다
인가	ACL	`KafkaUser`의 `authorization` 절 — 계정별 · 토픽별 read/write

원칙은 서비스마다 계정 하나 + 최소 권한 — 알림 서비스 계정은 자기가 읽는 토픽의 read와 자기 그룹의 read만 갖는다. “공용 계정 하나로 전부”는 사고 조사도 회수도 못 한다
OIDC(Keycloak)로 Kafka 인증을 붙이는 OAuth 리스너도 있다 — 사내 IdP를 이미 운영한다면 검토 대상. 구조는 Keycloak 덱의 그림 그대로다

일상 운영 — 루틴이 되는 일들

토픽 생성 · 설정 변경 — KafkaTopic CRD를 Git에 커밋 → 리뷰 → 반영. auto.create.topics.enable(토픽 자동 생성)은 꺼 둔다 — 오타 토픽 · 기본 설정(RF1) 토픽이 몰래 생기는 구멍이다
브로커 설정 변경 · 업그레이드 — Kafka CRD를 고치면 오퍼레이터가 ISR을 봐 가며 한 대씩 롤링한다. Kafka 업그레이드는 Strimzi 버전 → Kafka 버전 → (KRaft) 메타데이터 버전 순서로, 릴리스 노트의 지원 매트릭스를 따라간다
브로커 증설 · 재배치 — 노드풀 replicas를 늘려도 기존 파티션은 저절로 안 옮겨 간다. 새 브로커는 새 토픽/파티션만 받는다 — 기존 부하를 나누려면 파티션 재배치가 필요하고, 손 재배치(kafka-reassign-partitions.sh) 대신 Cruise Control(Strimzi KafkaRebalance CRD)에 맡기는 것이 안전하다
백업 — Kafka는 스냅숏 백업이 어색한 시스템이다(항상 흐르는 로그라). 기본 태도는 “복제가 곧 내구성 + 원본은 상류 시스템에 있다”이고, Kafka가 데이터의 원본이 되는 토픽(컴팩션 상태 토픽 등)만 S3/MinIO 싱크나 MirrorMaker 2로 따로 내려 둔다

매일 — 대시보드에서 세 지표 확인 (알람이 대신하게 되면 생략)
매주 — 랙 추세와 디스크 증가 속도를 보며 용량 계산(7장) 재검증
분기 — Strimzi·Kafka 버전 확인 및 업그레이드 계획 (Strimzi는 두 버전 이상 건너뛰는 업그레이드를 지원하지 않는 경우가 많다)

10장 요약

지표는 랙(추세) · URP(0이어야) · 디스크(70%) 세 개부터 — Strimzi + Prometheus로 첫날 구성
보안 세 층: TLS · 인증(mTLS/SCRAM — KafkaUser로 자동화) · ACL(서비스당 계정 + 최소 권한)
토픽·계정은 Git의 YAML로, 자동 생성은 끈다 — 롤링·업그레이드·재배치는 오퍼레이터와 Cruise Control에
브로커 증설은 재배치까지 해야 부하가 나뉜다
백업의 기본 태도는 “원본은 상류에” — Kafka가 원본인 토픽만 따로 내린다

11. 트러블슈팅증상에서 원인으로 — 어느 층부터 볼지의 진단 순서와 대표 증상 카탈로그.