Kafka 클라우드 전환 전략: 오브젝트 스토리지 시대의 보안과 안정성

Apache Kafka의 “디스크리스(Diskless)” 또는 “직접 S3(오브젝트 스토리지) 적용” 설계 방향의 기술 배경 및 고려할 점입니다.

개요 및 배경

• 최근 Kafka 커뮤니티에서는 여러 KIP (Kafka Improvement Proposal) 가 동시다발적으로 제안되었고, 그 중심 주제는 바로 클라우드 가용영역(AZ) 간 복제 비용 및 오브젝트 스토리지 활용입니다.
• 단순히 기술적 선택지로만 다루는 것이 아니라, Kafka가 앞으로 “어떤 시스템이 될 것인가?”라는 방향성 차원에서 접근하고 있습니다.
• 요약하자면
  • 전통적으로 Kafka는 디스크 기반 로그 세그먼트를 이용해, 리더-팔로워 복제 모델로 데이터를 보관하고 높은 처리량/낮은 지연(latency)을 확보해 왔습니다.
  • 그러나 클라우드·멀티 AZ 환경에서는 복제 비용, 네트워크 트래픽, 스토리지 비용 등이 부담이 되면서 오브젝트 스토리지(S3 등)를 내구성과 저장소로 활용하고, 브로커는 상태(state)를 최소화하는(disaggregated) 설계에 대한 요구가 커졌습니다.
• 따라서 “디스크리스(diskless)” 혹은 “오브젝트 스토리지 직접사용(direct-to-S3)”이라는 개념이 떠오르고 있으며, Kafka 커뮤니티는 이 방향 가운데 두 갈래 길(fork)에 서 있다는 것입니다.

용어 정리 – ‘디스크리스’ vs ‘오브젝트 스토리지 직접사용’

• 완전히 디스크가 사라지는 구조가 아니며, 사용자 입장에서 디스크를 신경쓰지 않아도 되는 구조로 보는 것이 맞습니다.
• 왜 차이가 중요하냐면
  • 단순히 “디스크 대신 S3를 쓴다” → 기존 브로커 아키텍처나 복제 모델 대부분을 유지하면서 오브젝트 스토리지만 바꾸는 변화
  • 근본적으로 “브로커는 상태를 거의 갖지 않고, 저장은 오브젝트 스토리지에 위임한다” → 더 큰 아키텍처 변화가 따라야 하는 변화
• 따라서 Kafka가 앞으로 클라우드·엘라스틱(Elastic)·무상태(Stateless) 컴퓨트 모델로 진화할 것인가, 아니면 기존 디스크 기반 리더-팔로워 구조를 유지하면서 변화폭을 최소화할 것인가의 선택입니다.

공통 설계 요소

Kafka가 오브젝트 스토리지를 활용하는 설계로 나아갈 때, 여러 제안(KIP)에서 반복적으로 등장하는 핵심 설계 패턴들이 있습니다. 이를 먼저 정리해 보면 다음과 같습니다.

1. 통합 객체 업로드 (Combined Objects)

• 여러 토픽(Topic) 및 파티션(Partition)의 데이터를 한꺼번에 배치 집계해서 오브젝트 스토리지에 업로드하는 방식이 공통적으로 제안됩니다.
• 그 이유는 두 가지입니다.
  1. 작은 파일(많은 수의 작은 업로드)을 방지하기 위해서 — 오브젝트 스토리지 서비스는 다수의 작은 요청을 처리할 때 비용이나 성능 상 불리할 수 있습니다.
  2. 다른 AZ 또는 브로커에 데이터를 흩뿌리면 네트워크·IO 비용이 커지므로, 버퍼링하여 한 번에 업로드하는 것이 효율적입니다.

2. 시퀀싱(Sequencing) 및 메타데이터 저장

• 기존 Kafka 리더-복제 모델에서는 리더가 순서를 결정하고, 각 배치(batch)에 오프셋(offset)을 할당합니다. 오브젝트 스토리지를 활용하는 설계에서는 이 순서를 재정립해야 합니다.
• 즉, 생산자(producer)가 데이터를 쓰는 브로커는 단순히 오브젝트 스토리지에 배치를 올리고, 그 후 분산된 조정자(coordinator) 혹은 메타데이터 저장소가 각 배치의 오프셋, 바이트범위(byte-range) 등의 정보를 저장하고 소비자(consumer)가 읽을 수 있게 해야 합니다.

3. 리전/가용영역 정렬(zone-alignment)

• 클라우드 환경에서는 AZ 간 데이터 복제나 브로커 통신이 비용과 레이턴시 측면에서 중요한 이슈입니다. 따라서 프로듀서와 컨슈머가 가급적 자기 AZ 내(zone-local) 자원에 붙도록 설계하는 것이 효율적입니다.
• 예컨대: 생산자가 쓰는 브로커를 자기 AZ 내에 두거나, 컨슈머가 읽을 때 AZ 내 캐시(cache)를 활용하는 등 설계가 제안됩니다.

4. 오브젝트 압축(Object Compaction)

• 여러 토픽·파티션이 섞인 오브젝트에 대한 효율적 읽기/정리를 위해 오브젝트 내부를 다시 파티션별로 나누거나, 압축된 형태(compaction) 로 정리하는 디자인이 등장합니다.
• 이는 읽기 지연(latency)이나 비용을 줄이기 위한 전략입니다.

설계 방향의 갈림길: 두 가지 경로

크게 두 가지 설계 방향(“혁명적(Revolutionary)” vs “진화적(Evolutionary)”)을 제시하며, 각각의 장단점을 비교합니다.

1. 혁명적 경로 (Revolutionary)

• 이 경로는 오브젝트 스토리지 기반 설계를 본격적으로 도입하여 브로커를 최대한 상태없음(stateless)으로 만들고, 저장소를 분리(disaggregated)하는 방향입니다.
• 특징
  • 브로커는 단지 프로듀서·컨슈머 요청을 처리하고 데이터는 오브젝트 스토리지에 저장.
  • 메타데이터, 시퀀싱, 오프셋 할당 등은 별도의 조정자(coordinator)/메타스토리지(metadata store)가 담당.
  • 브로커 규모가 가변적(elastic)이며, 노드를 추가/삭제하기 쉬움.
• 예시
  • WarpStream: 순수하게 디스크리스, 모든 브로커가 상태 없음, 중앙 메타데이터 서비스가 시퀀싱 담당.
  • Aiven Inkless: Kafka fork 형태로 direct-to-S3 설계를 구현한 사례.
• 장점
  • 클라우드 네이티브 아키텍처에 적합: 유연한 확장성, 오브젝트 스토리지 비용·운영 이점
  • AZ 간 복제 비용 절감 가능성
• 단점
  • 기존 Kafka 복제·트랜잭션·아이도미던시(idempotency) 논리 등을 두 번 구현해야 할 가능성 → 코드 복잡성 증가 가능성.
  • 큰 구조 리팩토링 필요: 기존 리더-팔로워 모델과 다소 다른 패러다임
  • 운영 시 메타데이터 서비스라는 또 다른 장애물/관리포인트가 생김

2. 진화적 경로 (Evolutionary)

• 이 경로는 기존 Kafka 아키텍처(리더-팔로워, 브로커 상태 유지)를 가급적 유지하면서, 오브젝트 스토리지를 보완적으로 도입하는 방식입니다.
• 특징
  • 리더 기반 토픽 파티션 구조 유지.
  • 복제 대신 각 브로커가 S3 기반 Write-Ahead-Log(WAL)를 관리하며, 장기 저장(tiering) 과정을 오브젝트 스토리지로 전환.
  • 코드 변경을 최소화하려는 접근
• 예시
  • KIP‑1176 (제안): 리더 기반 구조 유지, 브로커마다 S3 WAL, 기존 티어드 저장소(tiered storage) 재활용.
• 장점
  • 기존 Kafka 사용자 및 운영팀에게 친숙함
  • 리팩토링이나 대규모 코드 재작성 부담이 상대적으로 적음
• 단점
  • 오브젝트 스토리지 중심 설계의 장점을 완전히 살리지 못할 수 있음
  • Retro-fitting(기존 구조에 새 기능 억지로 맞춤) 시 코드 복잡성이 오히려 증가할 수 있음.

실제 제안안(KIP) 비교

대표적인 KIP들 사례로 어느 경로에 속하는지, 설계 특징·우려사항 주요 항목을 요약합니다.

1. KIP‑1150

• Revision 1: 리더리스(leaderless) 브로커, 모든 브로커가 어떤 토픽·파티션에도 쓰고 읽을 수 있는 구조. 배치 배치를 오브젝트로 S3에 저장하고, 별도의 Batch Coordinator가 메타데이터와 시퀀싱을 담당.
• 장점: 혁명적 설계에 가깝고 오브젝트 스토리지 설계 이점을 많이 취함.
• 우려사항: Batch Coordinator 자체가 새로운 복잡성 포인트이며, 트랜잭션·아이도미던시 등을 위한 구현이 남아있음.
• Revision 2: 기존 티어드 저장소(tiered storage)와의 통합을 꾀하며, 일부 ‘디스크’를 다시 활용하는 하이브리드 형태.
• Revision 3: Batch Coordinator를 없애고 기존 토픽 복제 메커니즘을 활용해 메타데이터 저장을 분산화하려는 제안.

2. KIP-1176

• 설계는 리더 기반 구조 유지 + 브로커별 S3 WAL + 기존 복제 대신 오브젝트 스토리지 활용 + 기존 티어드 저장소 재사용.
• 비교적 낮은 리스크 접근. 다만 “정합성(consistency), 고가용성(availability)” 측면에서 아직 설계상 질문이 남아 있음.

3. 기타 하이브리드 설계

• 위 두 축 사이에 중간 영역(hybrid)이 존재함. 예컨대 KIP-1150 rev2처럼 오브젝트 스토리지를 기본으로 하되, 로컬 디스크(브로커 상태)를 일부 유지하는 방식 등이 있습니다.

300x250

운영 및 보안 고려 사항

Kafka의 이러한 아키텍처 변화가 미치는 영향과 내부 사용자에게 제시해야 할 점검포인트를 중심으로 정리합니다.

1. 데이터 보관 및 내구성(durability) 보증

• 오브젝트 스토리지를 내구성 저장소로 활용할 경우, 오브젝트가 손상되거나 삭제될 경우 복구 절차가 기존 디스크 기반 구조와 달라질 수 있습니다.
  • 오브젝트 버전 관리(Versioning), 삭제 방지(Object Lock) 기능 여부 확인
  • 오브젝트 스토리지와 브로커 간의 전송 경로 암호화(예: TLS) 및 인증/권한 제어 강화
• 메타데이터 스토리지(예: Batch Coordinator, Postgres 등)를 도입하는 설계에서는 해당 메타데이터 서비스에 대한 가용성, 백업, 복구 전략을 반드시 검토해야 합니다.

2. 접근 제어 및 격리(Isolation)

• 브로커가 오브젝트 스토리지에 로그를 업로드하는 형태가 많아짐에 따라, 브로커→스토리지 간 인증 토큰, 권한 범위(least privilege) 설정이 중요해집니다.
• 멀티 AZ 혹은 멀티 리전 구성에서는 각 AZ 브로커 및 오브젝트 스토리지 접근이 적절히 네트워크 격리돼야 하고, AZ 간 교차 접근 등이 비용·보안 리스크가 될 수 있습니다.
• 소비자(fetch) 요청 경로가 복잡해지면 브로커 내부 캐시(cache)나 지역 캐시(zone-local) 사용에 따른 권한 설정도 고려해야 합니다.

3. 네트워크 및 비용 측면 보안

• 오브젝트 스토리지로의 대량 업로드 혹은 다운로드가 발생하면 네트워크 비용뿐 아니라 네트워크 보안 리스크도 증가할 수 있습니다.
  • 예컨대 브로커가 S3 버킷에서 오브젝트를 가져올 때, 퍼블릭 인터넷망 대신 VPC 엔드포인트, 프라이빗 링크(Private Link) 등 보호된 경로 사용 여부 확인
• AZ 간 복제 비용을 줄이고자 하는 설계가 오히려 네트워크 아웃바운드 트래픽이나 S3 요청 수 증가로 보안 노출면을 확대할 수 있습니다.

4. 장애 대응 및 복구 전략

• 오브젝트 스토리지 활용 설계에서는 읽기(fetch) 시 오브젝트 다운로드 → 오프셋 주입(inject) 등 새로운 경로가 추가됩니다. 이 경로에서 지연(latency)이나 실패(failure) 가능성이 운영 장애로 이어질 수 있으므로, 장애 시나리오 및 복구 절차를 마련해야 합니다.
  • 예컨대 Batch Coordinator가 다운되면 오프셋 할당이 중단될 수 있는가?
  • 브로커-오브젝트 스토리지 간 연결 끊김 시 어떻게 fallback할 것인가?
• 버전별 설계(Revsion 2/3 등)에서는 로컬 디스크를 다시 사용하거나 복제 모델을 유지함으로써 장애 위험을 줄이는 하이브리드 방식도 고려됩니다.

5. 운영 복잡성 및 코드 유지관리

• 설계 변경이 클수록 내부 새로운 기능(예: Batch Coordinator, S3 업로드/다운로드, 오브젝트 압축 등) 이해하고 운영해야 하는 부담이 커집니다.
• 코드 복제(duplicate logic)나 리팩토링 부재로 인한 기술 부채(technical debt)가 누적될 수 있으므로, 설계 선택 시 향후 유지관리 비용까지 고려되어야 합니다.

6. 내부 사용자 가이드 및 점검포인트

• 안내할 사항
  • 프로듀서·컨슈머 지연 변화 가능성: S3 업로드 대기, 오프셋 주입 등의 영향
  • 로컬 브로커 파티션 할당 변화: 설계에 따라 브로커가 더 많은 파티션을 수용하거나, “모든 브로커가 어떤 파티션도” 쓰는 구조로 바뀔 수 있음
  • 소비자 그룹 할당이 AZ 정렬(zone-local) 방식으로 바뀔 수 있으므로 컨슈머 애플리케이션 설정 변경 가능성
• 점검포인트
  • S3 버킷 정책(버전관리, 암호화, 접근제어) 검토
  • 브로커 역할(role) 정의 및 리소스 영향: 상태가 적은 브로커 vs 상태가 많은 브로커 구분 운영 가능성
  • 메타데이터 서비스(예: Batch Coordinator, Postgres 등) 장애 대응 전략 및 모니터링 체계 마련
  • 비용·성능 분석: AZ 간 복제 비용 감소가 설계 변경 비용·운영 리스크보다 더 큰가?
  • 보안 감사 및 로그: 오브젝트 스토리지 접근 로그, 브로커-스토리지 통신 로그 확보 여부

고려해야 할 적용 방향

위 논의를 바탕으로 내부 적용을 위한 고려사항 및 논의 프레임을 제안드립니다.

1. 현재 환경 및 요구사항 분석

• 우리 회사가 현재 운영하는 Kafka 기반 서비스의 특성 파악
  • 지연(latency) 민감성 있는 실시간 처리인가? 아니면 분석 기반, 로그 수집 기반 등 느슨한 지연 요건인가?
  • 멀티 AZ 또는 멀티 리전 구성 중인가? AZ 간 트래픽 및 복제 비용이 현재 유의미한가?
  • 브로커 및 스토리지(디스크) 운영비용, 복제 비용, 스토리지 용량증가 추세 등을 분석
• 보안 및 규제 요인
  • 저장되는 메시지 내용이 민감정보인가? 암호화·지속성·접근제한 요건이 어떤가?
  • 오브젝트 스토리지 사용 시 기존 로그 저장소나 아카이브 저장소와의 통합 필요 여부

2. 설계 방향 선택 고려

• 만약 지연이 매우 중요하고 디스크 기반 구조가 현재 잘 작동 중이라면 → 진화적(Evolutionary) 경로가 현실적 선택일 수 있습니다.
• 반면, 클라우드 AZ 간 복제 비용이 급격히 증가하고 있고 엘라스틱한 처리량 증감이 잦으며 스토리지 운영 복잡성이 커진다면 → 혁명적(Revolutionary) 경로가 장기적으로 유리할 수 있습니다.
• 두 경로를 모두 고려한 하이브리드 전략도 현실적입니다.
  • 예컨대, 비지연 민감한 토픽은 기존 방식 유지하고, 느슨한 지연을 허용하는 분석/로그 토픽은 오브젝트 스토리지 설계로 전환
  • 점진적 마이그레이션: 초기에는 브로커 특정 파티션만 오브젝트 스토리지 활용 → 이후 전면 전환

3. 보안·운영 준비 및 점검 리스트

• 오브젝트 스토리지 버킷 설정: 암호화(E-S3 SSE), 접근 정책, 버전관리, 삭제보호(Object Lock)
• 브로커 권한 및 인증: IAM 역할, 최소 권한, 네트워크 접근 제어(VPC 엔드포인트 등)
• 메타데이터 컴포넌트(예: Batch Coordinator) 장애/가용성 설계: 다중 AZ, 백업/복구, 로그 모니터링
• 로깅 및 감사: 오브젝트 업로드/다운로드 로그, 브로커-스토리지 통신 로그, 권한 변경 추적
• 비용 및 성능 모니터링: S3 요청 수, 다운로드 바이트, AZ 간 데이터 전송량, 브로커 CPU/메모리/디스크 사용량
• 개발/운영 문서화: 새 아키텍처에서는 브로커 역할 변화, 컨슈머 그룹 설정 변경 가능성, 운영 절차 변경 등이 생기므로 문서화 필요
• 보안 테스트/침해 대응 플랜: 오브젝트 스토리지 내 데이터 누출 사고 발생 시 영향 범위, 복구 절차, 내부 통보 프로세스

결론 및 제언

• Kafka가 현재 마주한 변화의 기점(fork)은 단순히 복제 비용을 줄이기 위한 기술 변경이 아니라, Kafka가 앞으로 어떤 플랫폼이 될 것인가라는 근본적 질문입니다.
• 혁명적 경로는 미래 클라우드 네이티브 구조에 더 잘 적합하나 초기 도입·운영·유지보수 리스크가 큽니다.
• 진화적 경로는 기존 운영환경과 친숙하지만 장기적 구조 변화에서 얻을 수 있는 이점을 놓칠 위험이 있습니다.
• 우리 조직에서는 다음과 같은 제언을 드립니다.
  1. 현황 분석을 통해 지연 요구, 복제 비용, 스토리지 비용, 운영 복잡성 등을 객관적으로 파악
  2. 파일럿/PoC(Proof of Concept) 형태로 비핵심 토픽에 오브젝트 스토리지 기반 구조를 적용해보고 성능·운영·보안 영향을 측정
  3. 보안·운영 측면 체크리스트 및 가이드라인을 준비: 스토리지 권한, 네트워크 경로, 감사 로깅, 장애 대응 등
  4. 팀 내부 개발/운영 역량을 고려하여 단계적 마이그레이션 전략 수립: 예컨대 “로그 토픽 → 분석 토픽 → 핵심 실시간 토픽” 순으로 변화
  5. 커뮤니티 및 Kafka 프로젝트 변화 동향을 지속적으로 모니터링: KIP 논의가 어떻게 마무리되는지, Kafka 버전에서 어떤 방식이 공식 채택되는지 등