Apache Kafka용 관리형 서비스는 안전하고 확장 가능한 오픈소스 Apache Kafka 클러스터를 실행하는 데 도움이 되는 Google Cloud 서비스입니다. 이 페이지에서는 서비스에서 자동화하고 간소화하는 작업을 간략하게 설명합니다. Apache Kafka에 대한 자세한 내용은 Apache Kafka 웹사이트를 참고하세요.
간단한 크기 조정 및 확장
Apache Kafka용 관리형 서비스 클러스터의 크기를 조정하거나 확장하려면 클러스터의 총 vCPU 수와 RAM 크기만 설정하면 됩니다. 스토리지를 비롯한 브로커 관리가 완전히 자동화됩니다. 클라이언트의 요구사항을 충족하기 위해 vCPU 및 기타 리소스 사용량을 모니터링하고 이를 상향 또는 하향 조정할 수 있습니다.
vCPU 수와 RAM 크기를 설정하면 서비스에서 브로커 크기 조절 및 프로비저닝을 자동화합니다. 클러스터 크기를 늘리는 데 새 브로커가 필요한 경우 서비스는 브로커 간에 파티션을 자동으로 재분산할 수 있습니다.
브로커 프로비저닝
클러스터의 총 vCPU 및 RAM 크기를 구성하면 서비스에서 새 브로커를 프로비저닝하고 기존 브로커를 확장합니다. 일반적인 클러스터 구성의 경우 총 vCPU 및 RAM 크기가 모든 브로커에 균등하게 분할됩니다. 즉, 브로커당 vCPU 수가 소수점 이하로 허용되지만 브로커당 최소 vCPU 1개가 필요합니다. 모든 클러스터는 3개 영역에 분산됩니다. 즉, 클러스터당 최소 3개의 vCPU와 3GiB의 RAM이 필요합니다.
클러스터 크기를 늘리면 브로커가 브로커당 최대 15개의 vCPU로 수직 확장됩니다. 이 한도에 도달하면 서비스에서 새 브로커를 만듭니다. 클러스터 크기를 줄이면 기존 브로커가 단일 vCPU로 축소되지만 삭제되지는 않습니다.
최대 브로커 크기는 언제든지 변경될 수 있습니다. 이 한도는 vCPU 수에 따라 브로커 처리량의 선형 확장을 유지하기 위해 선택되었습니다.
확장 알고리즘
브로커 수는 클러스터의 총 vCPU 또는 메모리 용량에 따라 결정됩니다. 확장 비율은 vCPU 15개당 브로커 1개 또는 리소스 120기비바이트(GiB)당 브로커 1개 중 브로커 수가 더 많은 쪽입니다. vCPU 대 메모리 비율 (vCPU:GiB)은 1:1~1:8 사이여야 합니다. 브로커는 3개 영역에 균등하게 분산되며 최대 차이는 1입니다.
예를 들어 vCPU 70개와 RAM 130GiB로 클러스터를 구성하고 복제 요소를 3으로 설정하면 다음 계산에 따라 브로커 수가 결정됩니다.
vCPU를 고려하여 필요한 브로커 수를 계산합니다.
ceiling(70 vCPUs / 15 vCPUs)= 5개 브로커메모리를 고려하는 데 필요한 브로커 수를 계산합니다.
ceiling(130 GiB / 120 GiB)= 브로커 2개
이 시나리오에서는 브로커 수가 vCPU 수에 따라 결정되므로 클러스터에 브로커가 5개 있습니다. 3개 영역 중 2개 영역에는 각각 브로커 2개가 할당되어 있고 마지막 영역에는 브로커 1개가 할당되어 있습니다.
스토리지 관리
스토리지 관리가 자동화됩니다. 대부분의 경우 비용을 관리하거나 데이터 보관 정책을 충족하기 위해 개별 주제의 보관 기간을 설정해야 합니다. 영구 디스크를 프로비저닝하고 관리할 필요가 없습니다.
이 서비스는 등급형 스토리지(KIP-405)를 사용합니다. 계층화된 스토리지는 브로커에 연결된 사전 프로비저닝된 영구 디스크 볼륨과 사실상 무제한의 객체 스토리지를 결합합니다.
이 서비스는 성능, 가용성, 비용의 균형을 맞추기 위해 각 vCPU에 SSD 영구 디스크를 100GiB 이상 할당합니다. 브로커당 실제 디스크 크기가 이 값을 초과할 수 있지만 vCPU당 100GiB에 대해 청구됩니다. 클러스터가 축소되더라도 브로커당 디스크 크기는 줄어들지 않습니다.
각 파티션 리더는 이러한 영구 디스크의 세그먼트 파일에 메시지를 버퍼링합니다. 세그먼트가 롤링되면 리전별 Cloud Storage로 지원되는 영구 객체 스토리지로 이동합니다. 이러한 세그먼트 파일의 크기는 log.roll.ms 및 log.segment.bytes 설정에 따라 설정됩니다.
이러한 세부정보는 이해하는 데 유용하지만 스토리지는 서비스에서 관리합니다. vCPU당 영구 디스크 용량과 같은 구체적인 구성은 변경될 수 있는 구현 세부정보입니다. 영구 스토리지에 사용되는 Cloud Storage 버킷에 직접 액세스할 수 없습니다.
재조정
새로 프로비저닝된 브로커가 성능을 유지하는 데 유용하려면 기존 브로커의 일부 트래픽을 이러한 새 머신으로 이동해야 합니다. 이를 더 쉽게 하려면 자동 리밸런싱을 사용 설정하면 됩니다.
자동 재분산이 사용 설정된 경우 새 브로커가 프로비저닝되면 서비스가 기존 브로커의 파티션을 자동으로 재분산합니다. 계층화된 스토리지 모델은 상대적으로 적은 양의 데이터를 새 브로커에 복사해야 하므로 리밸런싱 속도가 빨라집니다.
리밸런싱 알고리즘은 파티션 수를 기반으로 합니다. 각 파티션에서 제공하는 실제 트래픽은 고려되지 않습니다.
유연한 네트워킹
이 서비스는 모든 VPC에서 클러스터에 안전하게 액세스할 수 있도록 합니다. 여기에는 여러 VPC, 프로젝트, 리전에서의 액세스가 포함됩니다.
클러스터의 네트워킹을 구성하려면 클러스터에 액세스할 수 있는 서브넷 집합을 제공합니다. 서비스는 각 서브넷에서 부트스트랩 서버와 브로커를 위한 비공개 IP 주소를 프로비저닝합니다. 또한 각 IP 주소의 URL을 사용하여 비공개 Cloud DNS를 설정합니다. 부트스트랩 서버에는 부하 분산기가 있으므로 클러스터당 부트스트랩 URL이 하나 있습니다. URL은 모든 VPC에서 동일하므로 환경 전반에서 클라이언트 구성을 일관되게 유지할 수 있습니다.
이러한 유연성은 Private Service Connect (PSC) 덕분에 가능합니다. 클러스터에 할당된 각 IP 주소에는 PSC 엔드포인트가 필요합니다. 엔드포인트는 자동으로 프로비저닝됩니다.
클러스터 보호
이 서비스는 클러스터 보안을 위해 인증, 승인, 암호화, 패치, 리소스 격리와 같은 기능을 제공합니다. 또한 인증되지 않고 암호화되지 않은 연결 및 스토리지는 허용되지 않습니다.
인증
이 서비스는 SASL (Simple Authentication and Security Layer)과 mTLS (mutual TLS)라는 두 가지 인증 방법을 지원합니다. mTLS 인증은 2025년 6월 24일 이후에 생성된 클러스터에서 사용할 수 있습니다. 관리 클러스터에 대한 모든 연결은 SASL을 사용하는 IAM ID 또는 mTLS를 사용하는 클라이언트 인증서인 주체로 인증합니다. SASL을 사용할 때는 사람, 서비스, 제휴 계정이 주 구성원으로 지원됩니다.
이 서비스는 SASL/GSSAPI, SASL/SCRAM-SHA-256, SASL/SCRAM-SHA-512를 비롯한 다른 프로토콜을 지원하지 않습니다. 또한 서비스는 인증되지 않은 연결을 허용하지 않습니다.
승인
서비스는 승인에 계층화된 접근 방식을 사용합니다. IAM은 리소스 생성, 업데이트, 삭제와 같은 클러스터 관리 작업을 제어합니다. 인증된 주 구성원의 승인은 사용된 방법에 따라 달라집니다.
SASL: IAM을 사용하는 주 구성원은Google Cloud IAM 역할 바인딩을 통해 또는 클러스터의 Kafka ACL을 사용하여 승인됩니다. 자세한 내용은 SASL 인증 구성을 참고하세요.
mTLS: mTLS로 인증하는 주체는 Kafka ACL을 통해 승인됩니다. 자세한 내용은 mTLS 인증 구성을 참고하세요.
Google Cloud 도구 또는 서드 파티 Kafka 도구를 사용하여 Kafka ACL을 관리할 수 있습니다. IAM 및 Kafka ACL 구성에 대한 자세한 내용은 IAM 및 Kafka ACL로 액세스 제어를 참고하세요.
암호화
암호화가 필요합니다. 클러스터에 대한 모든 연결은 TLS를 사용해야 합니다. 브로커가 제공하는 TLS 인증서는 공개 인증 기관에서 서명합니다. 저장된 데이터는 항상 암호화됩니다. 저장 데이터 암호화에 Google 관리 암호화 키 또는 고객 관리 암호화 키 (CMEK)를 사용할지 선택합니다.
패치
서비스팀은 오픈소스 코드에서 발견된 보안 취약점을 추적합니다. 서비스에서 취약점을 발견하면 클러스터에 자동으로 패치를 적용합니다.
리소스 격리
서비스의 또 다른 보안 기능은 리소스 격리입니다. 관리 서비스는 공개 IP 주소를 통해 액세스할 수 없는 비공개 VPC의 테넌트 프로젝트에 클러스터를 배포합니다. 각 프로젝트에는 전용 서비스 에이전트 계정이 있는 전용 테넌트 프로젝트가 있습니다. 이렇게 하면 서비스에 부여된 액세스 범위를 제한할 수 있습니다.
스키마 레지스트리
생산자와 소비자 간의 조정을 간소화하기 위해 Managed Service for Apache Kafka에는 스키마 레지스트리 API가 포함되어 있습니다. 서비스에서 제공하는 레지스트리는 애플리케이션 간에 공유되는 스키마의 저장소 역할을 합니다.
이 서비스는 기존 Kafka 애플리케이션과의 통합을 지원하는 Confluent 스키마 레지스트리 REST API를 구현합니다. Apache Avro 및 프로토콜 버퍼 (Protobuf) 스키마 형식이 지원됩니다. JSON은 지원되지 않습니다.
Apache Kafka용 관리형 서비스는 스키마 레지스트리와 스키마를 관리하기 위한 관리 API 및 도구 모음도 제공합니다. 툴셋에는Google Cloud 콘솔, gcloud CLI, 클라이언트 라이브러리가 포함됩니다.
스키마 레지스트리에 대한 자세한 내용은 스키마 레지스트리 개요를 참고하세요.
Kafka Connect와 데이터 통합
Managed Service for Apache Kafka는 Kafka Connect를 통해 데이터 통합을 간소화합니다. Kafka Connect는 Connect 클러스터에서 호스팅되는 여러 기본 제공 커넥터 플러그인을 제공합니다. 이러한 커넥터는 마이그레이션, 백업, 재해 복구, 고가용성, 데이터 통합에 사용됩니다. 이러한 커넥터를 사용하면 Apache Kafka용 관리형 서비스 클러스터를 다른 Kafka 배포 및 BigQuery, Cloud Storage, Pub/Sub과 같은 Google Cloud 서비스를 비롯한 다양한 시스템에 연결할 수 있습니다. Kafka Connect는 운영 오버헤드가 낮고 모니터링 및 로깅이 통합된 확장 가능하고 안정적인 데이터 통합을 제공합니다.
Kafka Connect에 대해 자세히 알아보려면 Kafka Connect 개요를 참고하세요.
고가용성 클러스터
이 서비스의 목표는 미션 크리티컬 애플리케이션에 리전 클러스터를 제공하는 것입니다. 특히 이 서비스는 개별 영역 또는 브로커의 장애로부터 사용자를 보호합니다.
이를 위해 모든 클러스터는 랙 인식 3개 영역 구성으로 프로비저닝됩니다. 기본 주제 구성에는 복제본이 3개 이상 필요합니다. 랙 인식 기능을 사용하면 복제본이 서로 다른 영역에 생성됩니다. 동기화된 복제본의 기본 최소 수는 2입니다. 즉, 클러스터가 영역 또는 브로커의 완전한 손실을 허용할 수 있습니다.
소프트웨어, 하드웨어 또는 네트워킹 오류로 인해 브로커에 장애가 발생하면 자동으로 대체됩니다. 서비스에서 브로커 오류를 감지하면 필요한 경우 다른 머신에서 자동으로 다시 시작합니다. 브로커를 사용할 수 있게 되면 Apache Kafka가 브로커를 클러스터에 통합합니다. 영역이 완전히 실패하면 새 브로커를 만들 수 없을 수 있습니다. 하지만 다른 두 영역이 계속 사용 가능한 상태로 유지되는 한 클러스터는 계속 작동합니다.
이러한 특정 기능 외에도 증가하는 내부 도구 및 프로세스 목록을 통해 서비스, Apache Kafka 코드, 업데이트의 상태를 사전 예방적으로 유지합니다. 데이터 및 메타데이터 백업은 여러 수준에서 유지되므로 서비스가 많은 인적 오류와 소프트웨어 장애로부터 복구할 수 있습니다.
이 서비스는 리전 또는 이중 영역 장애로부터 보호를 제공하지 않습니다. 이 수준의 보호가 필요한 애플리케이션의 경우 별도의 리전 클러스터 두 개를 실행하는 것이 좋습니다. Kafka Connect의 MirrorMaker 2.0과 같은 도구를 사용하여 두 클러스터 간에 데이터를 동기화할 수 있습니다.
관리 스타일에 맞는 도구
이 서비스는 클러스터 관리 및 문제 해결 스타일에 맞는 완전한 도구 세트를 제공하는 것을 목표로 합니다. 여기에는 관리, 모니터링, 로깅을 위한 도구가 포함됩니다.
Apache Kafka용 관리형 서비스는 Google Cloud API로 노출됩니다. 즉, REST 및 gRPC API를 사용하여 클러스터와 클러스터 리소스를 관리할 수 있습니다. 다음과 같은 여러 클라이언트와 인터페이스가 이러한 API에 제공됩니다.
- 코드형 인프라 접근 방식을 선호하는 경우 Terraform 제공자
- 브라우저에서 대화형 작업을 위한 Google Cloud 콘솔의 UI
- 셸에서 대화형 작업을 위한 gcloud CLI
- 맞춤 개발 및 스크립팅을 위한 Java, Python, Go 등의 언어로 된 클라이언트 라이브러리
모니터링 및 문제 해결을 위해 서비스는 측정항목을 Cloud Monitoring으로 내보냅니다. 일부 측정항목은 서비스 UI에서 확인할 수 있습니다. 대화형 작업, 알림 구성, 다른 시스템으로 내보내기를 위해 Cloud Monitoring에서 전체 세트를 사용할 수 있습니다.
서비스는 브로커 로그를 Cloud Logging으로 내보내기도 합니다. 이러한 로그는 검색 가능하며 로그 기반 측정항목 및 알림을 만드는 데 사용할 수 있습니다.
업그레이드 및 패치
Apache Kafka용 관리형 서비스 클러스터는 Apache Kafka 버전 3.7.1에서 실행됩니다. 서비스는 중요한 보안 취약점에 자동으로 패치를 적용합니다.
운영체제 및 오케스트레이션 레이어를 비롯한 기본 인프라 업데이트는 지속적이고 자동입니다. 브로커는 순차적 다시 시작으로 업데이트되며 클러스터의 다운타임은 없습니다.
이 서비스는 브로커에서 실행되는 Apache Kafka 코드를 새 부 버전으로 자동 업그레이드하지 않습니다.
투명한 비용
Apache Kafka용 관리형 서비스의 가격 책정 모델은 Compute Engine에서 직접 Apache Kafka를 실행할 때 표시되는 요금과 유사합니다. 프로비저닝하는 리소스(vCPU, RAM, 로컬 스토리지)와 사용하는 리소스(영구 스토리지, 데이터 전송)에 대해 요금을 지불합니다. Managed Service for Apache Kafka를 사용하면 유사한 시스템을 직접 설정하는 것보다 영구 스토리지 및 vCPU 비용이 더 많이 듭니다. 반면 데이터 전송 및 로컬 스토리지 가격은 Managed Service for Apache Kafka와 자체 관리형 Kafka 간에 유사합니다. 가격 책정에 대한 자세한 내용은 Apache Kafka용 관리형 서비스 가격 책정을 참고하세요.
Apache Kafka를 실행하므로 호환 가능
마지막으로 Apache Kafka용 관리형 서비스는 환경에서 이미 실행 중일 수 있는 동일한 오픈소스 소프트웨어를 실행합니다. 서비스로 이전하기 위해 애플리케이션 코드를 변경할 필요는 없습니다.
제한사항
Managed Service for Apache Kafka에는 다음과 같은 제한사항이 있습니다.
각 클러스터에는 세 영역 각각에 동일한 리소스가 있어야 합니다. 단일 영역 또는 2개 영역 Apache Kafka용 관리형 서비스 클러스터는 지원되지 않습니다.
클러스터를 만들 때 영역을 선택할 수 없습니다.
클러스터에서 로컬 스토리지의 볼륨을 구성할 수 없습니다.
Managed Service for Apache Kafka는 KRaft 모드로 실행됩니다. Zookeeper 모드는 지원되지 않습니다.
측정항목용 JMX API는 지원되지 않습니다.
zstd을 사용한 주제 압축은 지원되지 않습니다.compression.type에 지원되는 값은lz4,gzip,snappy,uncompressed입니다.언제든지
read-only업데이트 모드로 브로커 구성을 변경할 수 있지만 이러한 변경사항은 브로커가 다시 시작될 때만 적용됩니다. 다시 시작은 Google의 유지보수 및 업그레이드 프로세스의 일환으로 주기적으로 발생하지만, 정해진 일정이나 수동으로 트리거하는 방법은 없습니다. 따라서 이러한 변경사항이 적용되는 시기를 관리할 수 없습니다.read-only구성의 예로는auto.create.topics.enable및background.threads가 있습니다.message.max.bytes과 같은cluster-wide업데이트 모드를 사용하여 구성을 업데이트하면 다시 시작할 필요가 없으며 즉시 적용됩니다.일부 브로커 구성 매개변수는 서비스에서 관리하며 업데이트할 수 없습니다. 여기에는
broker.id및remote.log.storage.system.enable와 같은 저장소 관련 설정이 포함됩니다.
다음 단계
- Apache Kafka용 관리형 서비스 클러스터 만들기
- Apache Kafka용 관리형 서비스 클러스터를 사용하여 메시지 보내기 및 받기
- Apache Kafka용 관리형 서비스 제한사항을 검토합니다.
- Apache Kafka용 관리형 서비스 가격 책정에 대해 알아봅니다.