Amazon MSK에서 올바른 클러스터 유형을 선택하는 방법

이 글은 AWS Big Data Blog에 게시된 How to choose the right Amazon MSK cluster type for you by Ali Alemi을 한국어로 번역 및 편집하였습니다.

Amazon Managed Streaming for Apache Kafka (Amazon MSK)는 Apache Kafka의 인프라 및 운영을 관리하는 AWS 스트리밍 데이터 서비스로, 개발자와 DevOps 관리자가 AWS에서 Apache Kafka 애플리케이션 및 커넥터를 쉽게 실행할 수 있도록 해줍니다. Amazon MSK는 Apache Kafka 클러스터를 운영, 유지, 확장하고, 엔터프라이즈 레벨의 보안 기능을 기본 제공하며, 스트리밍 데이터 애플리케이션의 개발을 가속화 할 수 있는 통합 기능을 갖추고 있습니다. 몇 번의 클릭만으로 AWS 관리 콘솔을 사용하여 MSK 클러스터를 생성하고 쉽게 시작할 수 있습니다.

클러스터를 새로 생성할 때 프로비저닝 또는 서버리스 중에서 클러스터 유형을 선택하도록 되어있습니다. 각 워크로드에 가장 적합한 클러스터 유형을 선택하는 것은 워크로드 유형과 DevOps 선호도에 따라 달라집니다. 프로비저닝된 Amazon MSK방식은 클러스터를 확장, 구성 및 최적화하는 방법에 대해 보다 많은 유연성을 제공합니다. 반면에 Amazon MSK 서버리스는 클러스터의 확장, 부하 관리, 운영을 더 쉽게 해줍니다. MSK 서버리스를 사용하면 인프라를 구성, 관리하거나 클러스터를 최적화할 필요 없이 애플리케이션을 실행할 수 있으며, 스트리밍하고 보관하는 데이터 볼륨에 대한 비용만 지불하면 됩니다. MSK 서버리스는 오토밸런싱 기능을 통해 브로커 간의 파티션 분배를 균일하게 할 수 있을 뿐 아니라, 모니터링을 포함한 완전 관리형 파티션 관리를 지원합니다.

이번 게시글에서는 가상의 회사인 AnyCompany가 두 개의 서로 다른 애플리케이션에서 Amazon MSK를 활용하는 사례를 설명합니다. 애플리케이션별로 프로비저닝 또는 서버리스 클러스터 중 하나를 선택하는데, 어떤 프로세스가 활용되는지에 대해 알 수 있습니다. 조직 구조와 애플리케이션 요구사항이 최적의 제품을 찾는데 어떤 관련이 있는 지와 함께 애플리케이션의 요구사항에서 반대로 확인하는 방법도 함께 알아봅니다. 마지막으로 요구사항과 Amazon MSK 기능과의 관계를 살펴봅니다.

활용 사례

AnyCompany는 두 개의 Kafka 애플리케이션을 Amazon MSK로 이전하려는 엔터프라이즈 기업입니다.

첫 번째는 대규모 이커머스 플랫폼으로, 현재 데이터 센터에서 자체적으로 관리되는 Apache Kafka 클러스터를 사용하는 레거시 애플리케이션입니다. AnyCompany는 해당 애플리케이션을 AWS 클라우드로 마이그레이션하고 Amazon MSK를 사용하여 관리 및 운영 오버헤드를 줄이려고 합니다. AnyCompany에는 수년간 데이터 센터에서 Kafka 클러스터를 운영해 온 DataOps 팀이 있습니다. AnyCompany는 개발팀이 아닌 DataOps 팀에서 MSK 클러스터를 계속 운영하기를 원합니다. 코드 변경에 대한 유연성은 거의 없습니다. 예를 들어, 애플리케이션의 몇 가지 모듈은 MSK 클러스터와 함께 제공되는 Apache ZooKeeper에 대한 일반 텍스트 통신과 액세스가 필요합니다. 일반적으로 애플리케이션으로 유입되는 트래픽 처리량은 변동성이 적으나, 특별 판매 이벤트 기간에는 사용자가 급증합니다. DataOps 팀은 이 애플리케이션의 트래픽 패턴을 잘 이해하고 있으며, 몇 가지 사용자 지정 브로커 수준의 설정을 통해 MSK 클러스터를 최적화할 수 있다고 생각 합니다.

두 번째는 현재 개발 중인 새로운 클라우드 네이티브 게임 애플리케이션입니다. AnyCompany는 이 게임 애플리케이션을 곧 출시하고 마케팅 캠페인을 진행할 예정입니다. 아직 오픈 전이기 때문에 이 애플리케이션에 필요한 처리량은 알 수 없으나, 초기에 트래픽이 많다가 사용자 활동이 점차 감소할 것으로 예상하고 있습니다. 이 애플리케이션은 미국에서 먼저 출시될 예정이므로 낮의 트래픽이 밤보다 높을 것으로 예상됩니다. 이 애플리케이션은 Kafka 클라이언트 버전, 전송 중 암호화, 인증 측면에서 다양한 유연성을 제공합니다. 클라우드 네이티브 애플리케이션이기 때문에 AnyCompany는 개발팀에서 인프라에 대한 오너십을 갖는 것을  원하고 있습니다.

솔루션 개요

AnyCompany가 두 가지 Amazon MSK 서비스 중에서 어떤 것을 사용할지 결정하는 프로세스를 살펴 보겠습니다. 다음 다이어그램은 이 프로세스를 하이 레벨로 보여줍니다.

다음 섹션에서는 각 단계와 결정을 내리기 전에 AnyCompany가 수집해야 하는 관련 정보에 대해 자세히 설명합니다.

아파치 카프카의 역량

AWS는 프로비저닝된 방식의 Amazon MSK를 사용할 때 따라야 할 모범 사례를 제공합니다. 프로비저닝된 방식의 Amazon MSK는 더 많은 유연성을 제공하기 때문에 워크로드에 따라 적합한 확장 결정을 할 수 있습니다. 예를 들어 워크로드 그룹을 단일 클러스터로 통합하여 비용을 절감하거나, 브로커에 사용자 지정 구성을 적용하여 클러스터를 모니터링하고 최적화하는 데 중요한 메트릭을 결정할 수도 있습니다. 지원되는 여러 버전 중에서 어떤 Apache Kafka 버전을 선택하고 새 버전으로 업그레이드할 시기를 결정할 수 있습니다. 설정 적용과 각 브로커의 업그레이드는 롤링 방식으로 처리됩니다.

유연성이 높아지면 책임도 커집니다. 항상 클러스터가 적절한 크기인지 확인해야 합니다. 클러스터 및 브로커, 토픽 레벨의 메트릭을 모니터링 함으로써 트래픽 처리에 필요한 충분한 리소스를 가지고 있는지 알 수 있습니다. 또한 각 브로커에 할당된 파티션 수가 Amazon MSK에서 권고하는 수치를 초과하지 않는지 확인해야 합니다. 파티션이 불균형한 경우 모든 브로커에서 파티션을 균등하게 분배해야 합니다. 파티션이 권고되는 것보다 많은 경우 브로커를 더 큰 사이즈로 업그레이드하거나 클러스터의 브로커 수를 늘려야 합니다. 또한 AWS IAM 인증을 사용할 때 TCP 커넥션 수에 대한 모범 사례도 있습니다.

MSK 서버리스 클러스터는 클러스터 크기를 적절히 조정하고 브로커 간 파티션의 균형을 맞추는 복잡한 작업을 없애 줍니다. 따라서 개발자는 애플리케이션 코드 작성에 집중할 수 있습니다.

AnyCompany는 프로비저닝된 MSK클러스터 유형에 대한 확장 및 모범 사례에 익숙한 숙련된 DataOps 팀이 있습니다. AnyCompany는 이커머스 애플리케이션 팀을 대신하여 자동화 및 따라 하기 쉬운 표준 절차를 구축하기 위해 DataOps 팀의 Kafka 전문 지식을 활용할 수 있습니다. 게임 개발팀은 인프라에 대한 오너십을 가져야 하기 때문에 해당되지 않습니다.

다음 섹션에서는 각 애플리케이션에 적합한 클러스터 유형을 결정하기 전에 프로세스의 다른 단계에 대해 설명합니다.

사용자 정의 구성

특정 사용 환경에서는 MSK 클러스터를 기본 설정과 다르게 구성해야 하는 경우가 있습니다. 이는 애플리케이션 요구 사항 때문일 수 있습니다. 예를 들어 AnyCompany의 이커머스 플랫폼에서는 모든 토픽의 기본 보존 기간이 72시간이 되도록 브로커를 설정해야 합니다. 또한 토픽은 요청을 받거나 존재하지 않을 때 자동으로 만들어져야 합니다.

프로비저닝된 Amazon MSK서비스는 브로커, 토픽 및 Apache ZooKeeper 노드에 대한 기본 구성을 제공합니다. 또한 사용자 정의 구성을 만들고 이를 이용하여 새로운 MSK 클러스터를 만들거나 기존 클러스터를 업데이트할 수도 있습니다. MSK 클러스터의 구성은 속성 집합과 이에 대한 설정 값으로 구성됩니다.

MSK 서버리스에서는 브로커 수준 구성을 적용할 수 없습니다. 이는 백엔드 노드의 구성과 관리를 AWS가 대신하기 때문입니다. 따라서 브로커 노드를 구성하는 번거로움이 사라지고, 사용자는 애플리케이션의 토픽만 관리하면 됩니다. 자세한 내용은 MSK 서버리스에서 변경할 수 있는 토픽 수준 구성 목록을 참조하세요.

이커머스 플랫폼과 달리 AnyCompany의 게임 애플리케이션은 브로커 수준의 사용자 지정 구성이 필요하지 않습니다. 개발자는 각 토픽에 대한 retention.ms 및 max.message.bytes 값만 설정하면 됩니다.

애플리케이션 요구사항

Apache Kafka 애플리케이션은 보안, 데이터 연결, 쓰기 또는 읽기 방식, 데이터 보존 기간, 확장 패턴 등 다양한 부분에서 차이가 있습니다. 예를 들어, 어떤 애플리케이션은 수직으로만 확장할 수 있는 반면, 어떤 애플리케이션은 수평으로만 확장할 수 있습니다. 유연한 애플리케이션은 전송 중 암호화를 사용할 수 있지만, 레거시 애플리케이션은 일반 텍스트 형식으로만 통신하기도 합니다.

클러스터 레벨 쿼터

Amazon MSK는 모든 고객에게 서비스의 성능, 안정성 및 가용성을 보장하기 위해 일부 값에 대한 쿼터를 적용하고 있습니다. 이러한 쿼터는 변경될 수 있기 때문에 최신 값을 알고 싶으시면 Amazon MSK 쿼터를 참조 하세요. 일부 쿼터는 소프트 제한으로 서포트 티켓을 통해 늘릴 수 있습니다.

Amazon MSK에서 클러스터 유형을 선택할 때는 애플리케이션 요구 사항을 이해하고 각각의 제공 값과 관련된 쿼터와 비교하는 것이 중요합니다. 이를 통해 사용자의 목표와 애플리케이션의 요구 사항을 충족하는 최적의 클러스터 유형을 선택할 수 있습니다. 필요한 처리량을 계산하는 방법과 함께 Amazon MSK 쿼터와 비교해야 하는 주요 항목들을 살펴보겠습니다:

• 계정당 클러스터 수 – Amazon MSK에는 단일 AWS 계정에서 생성할 수 있는 클러스터 수에 대한 쿼터가 있을 수 있습니다. 이로 인해 더 많은 클러스터를 만들 수 없을 경우, 여러 AWS 계정에서 클러스터를 만들고 보안 연결 패턴을 사용하여 애플리케이션에 대한 액세스를 제공할 수 있습니다.
• 메시지 크기 – 프로듀서가 단일 메시지에 대해 작성하는 최대 메시지 크기가 MSK 클러스터에 구성된 크기보다 작은 지 확인해야 합니다. 프로비저닝된 MSK클러스터에서는 사용자 지정 구성을 통해 기본값을 변경할 수 있습니다. MSK 서버리스를 선택하는 경우 Amazon MSK 쿼터에서 이 값을 확인하세요. 평균 메시지 크기는 클러스터의 총 수신 또는 송신 처리량을 계산할 때 유용하며, 이 글의 뒷부분에서 설명합니다.
• 초당 메시지 전송률 – 클러스터의 총 수신 및 송신 처리량과 직접 관련이 있습니다. 총 수신 처리량은 초당 메시지 전송률에 메시지 크기를 곱한 값입니다. batch.size 및 linger.ms 속성을 조정하여 프로듀서가 최적의 처리량에 맞게 구성되었는지 확인해야 합니다. MSK 서버리스를 선택하는 경우, 요청 속도 할당량보다 낮은 속도로 최적의 배치를 구성하도록 프로듀서를 구성해야 합니다.
• 컨슈머 그룹 수 – 클러스터의 총 송신 처리량에 직접적인 영향을 줍니다. 총 송신 처리량은 수신 처리량에 컨슈머 그룹 수를 곱한 값입니다. MSK 서버리스를 선택하는 경우 애플리케이션이 이러한 쿼터로 작동할 수 있는지 확인해야 합니다.
• 최대 파티션 수 – 프로비저닝된 Amazon MSK 는 브로커당 특정 한도를 초과하지 않도록 권고합니다(브로커 크기에 따라 다름). 브로커당 파티션 수가 이전 표에 지정된 최대값을 초과하면 특정 업그레이드 또는 업데이트 작업을 수행할 수 없습니다. 또한 MSK 서버리스에는 클러스터당 최대 파티션 수에 대한 할당량이 있습니다. 서포트 케이스를 통해 할당량 증가를 요청할 수 있습니다.

파티션 레벨 쿼터

Apache Kafka는 토픽이라는 구조로 데이터를 생성합니다. 각 토픽은 하나 또는 여러 개의 파티션으로 구성됩니다. 파티션은 Apache Kafka에서 병렬 처리 수준을 의미합니다. 데이터는 데이터 파티셔닝 기술을 사용하여 브로커 간에 분산됩니다. 주요한 Amazon MSK 요구 조건을 살펴보고 애플리케이션에 어떤 클러스터 유형이 더 적합한지 확인하는 방법을 알아보겠습니다:

• 파티션당 최대 처리량 – MSK 서버리스는 백엔드 노드 간에 토픽의 파티션을 자동으로 균형 있게 조정합니다. 수신 처리량이 증가하면 즉시 확장됩니다. 그러나 각 파티션에는 수용하는 데이터의 양에 대한 할당량이 있습니다. 이는 데이터가 모든 파티션과 백엔드 노드에 고르게 분산되도록 하기 위한 것입니다. MSK 서버리스 클러스터에서는 집계된 처리량이 애플리케이션에 필요한 최대 처리량과 같도록 충분한 파티션으로 토픽을 만들어야 합니다. 또한 소비자가 파티션당 최대 송신 처리량 할당량보다 낮은 속도로 데이터를 읽도록 해야 합니다. 프로비저닝된 Amazon MSK를 사용하는 경우 쓰기 및 읽기 작업에 대한 파티션 수준 할당량이 없습니다. 그러나 AWS는 핫 파티션을 모니터링 및 감지하고 브로커 노드 간에 파티션의 균형을 맞추는 방법을 제어할 것을 권고합니다.
• 데이터 스토리지 – 각 메시지가 특정 토픽에 보관되는 시간은 클러스터에 필요한 총 스토리지 양에 직접적인 영향을 미칩니다. Amazon MSK를 사용하면 토픽 레벨에서 보존 기간을 관리할 수 있습니다. 프로비저닝된 MSK 클러스터에서는 브로커 레벨 구성으로 기본 데이터 보존 기간을 설정할 수 있습니다. MSK 서버리스 클러스터는 데이터 보존을 무제한으로 허용하지만 각 파티션에 저장할 수 있는 최대 데이터에 대한 별도의 쿼터가 있습니다.

보안

Amazon MSK는 다음과 같은 방법으로 데이터를 보호할 것을 권고합니다. 보안 기능의 사용 가능 여부는 클러스터 유형에 따라 다릅니다. 클러스터 유형을 선택하기 전에 해당 클러스터 유형에서 선호하는 보안 옵션이 지원되는지 확인하세요.

• 저장 중 암호화 – Amazon MSK는 AWS Key Management Service (AWS KMS)와 통합하여 투명한 서버측 암호화를 제공합니다. Amazon MSK는 항상 저장 중인 데이터를 암호화합니다. MSK 클러스터를 생성할 때 데이터를 암호화하는 데 사용할 KMS 키를 지정할 수 있습니다.
• 전송 중 암호화 – Amazon MSK는 TLS 1.2를 사용합니다. 기본적으로 MSK 클러스터의 브로커 간에 전송 중인 데이터를 암호화합니다. 클러스터를 만들 때 이 기본값을 재정의할 수 있습니다. 클라이언트와 브로커 간의 통신을 위해서는 다음 설정 중 하나를 지정해야 합니다:
  • TLS 암호화된 데이터만 허용합니다. (기본 설정)
  • 일반 텍스트 및 TLS 암호화된 데이터를 모두 허용합니다.
  • 일반 텍스트 데이터만 허용합니다.
• 인증 및 권한 – IAM을 사용하여 클라이언트를 인증하고 Apache Kafka 작업을 허용하거나 거부합니다. IAM 대신 TLS 또는 SASL/SCRAM을 사용하여 클라이언트를 인증하고 Apache Kafka ACL을 사용하여 작업을 허용하거나 거부할 수 있습니다.

오너십 비용

Amazon MSK는 Apache Kafka 클러스터를 관리하는 데 시간과 리소스를 낭비하지 않도록 도와 줍니다. Amazon MSK 콘솔에서 몇 번의 클릭만으로 모범 사례 기반의 고가용성을 가진 Apache Kafka 클러스터를 생성할 수 있습니다. Amazon MSK는 Apache Kafka 클러스터를 자동으로 프로비저닝하고 실행할 뿐 아니라 클러스터 상태를 지속적으로 모니터링하고 애플리케이션 다운타임 없이 이상이 있는 노드를 자동으로 교체합니다. 또한, Amazon MSK는 미사용 및 전송 중인 데이터를 암호화하여 Apache Kafka 클러스터를 보호합니다. 이러한 기능은 총 소유 비용(TCO)을 크게 절감할 수 있습니다.

프로비저닝된MSK클러스터를 사용하면 필요에 따라 클러스터 용량을 지정 후 확장할 수 있습니다. MSK 서버리스 클러스터를 사용하면 클러스터 용량을 지정하거나 확장할 필요가 없습니다. MSK 서버리스는 처리량에 따라 클러스터 용량을 자동으로 확장하며, 클러스터의 토픽에서 대해 생산자와 소비자가 쓰고 읽는 데이터의 GB당 요금만 지불하면 됩니다. 또한 서버리스 클러스터에 대한 시간당 요금과 생성하는 각 파티션에 대한 시간당 요금을 지불합니다. MSK 서버리스 클러스터 유형은 일반적으로 모니터링, 용량 계획 및 MSK 클러스터 확장에 필요한 엔지니어링 리소스 비용을 제거하여 소유 비용을 낮춥니다. 그러나 조직에 Kafka 역량을 갖춘 DataOps 팀이 있는 경우, 이를 이용하여 최적화된 프로비저닝된 MSK 클러스터를 운영할 수도 있습니다. 이를 통해 여러 개의 Kafka 애플리케이션을 단일 클러스터로 통합하여 Amazon MSK 비용을 절감할 수 있습니다. 여러 MSK 클러스터 간의 워크로드를 분할에 대한 시기와 방법을 결정할 때 고려해야 할 몇 가지 중요한 사항이 있습니다.

Apache ZooKeeper

Apache ZooKeeper는 클러스터를 생성할 때 Amazon MSK에 포함된 서비스입니다. 이 서비스는 Apache Kafka 메타데이터를 관리하고 리더 선출을 위한 쿼럼 컨트롤러 역할을 합니다. ZooKeeper와 상호 작용하는 것이 권장되는 패턴은 아니지만, 일부 Kafka 애플리케이션은 ZooKeeper에 직접 연결해야 할 수도 있습니다. Amazon MSK로 마이그레이션하는 동안 이러한 애플리케이션 몇 가지를 발견할 수도 있습니다. 이전 버전의 Kafka 클라이언트 라이브러리를 사용하거나 그 밖의 다른 이유 때문일 수도 있습니다. 예를 들어, Cruise Control과 같이 Apache Kafka 관리 작업이나 가시성을 지원하는 애플리케이션은 일반적으로 이러한 직접 접근이 필요합니다.

클러스터 유형을 선택하기 전에 먼저 ZooKeeper 클러스터에 대한 직접 접근을 제공하는 서비스를 확인해야 합니다. 이 게시글을 작성하는 시점에서는, 프로비저닝된 Amazon MSK만이 ZooKeeper에 대한 직접 액세스를 제공합니다.

AnyCompany가 클러스터 유형을 선택하는 방법

AnyCompany는 먼저 각 애플리케이션에 대한 몇 가지 중요한 요구 사항을 수집해야 합니다. 다음 표에는 이러한 요구 사항이 나와 있습니다. 별표(*)로 표시된 행은 이전 행의 값을 기준으로 계산된 값입니다.

게임 애플리케이션의 경우 AnyCompany는 프로비저닝된 MSK클러스터를 지원하는데 내부 Kafka기술 역량을 활용하고 싶어하지 않습니다. 또한 게임 애플리케이션은 사용자 정의 설정이 필요하지 않으며 요구되는 처리량이 MSK 서버리스 클러스터 유형에서 설정한 쿼터보다 낮습니다. 따라서 이 시나리오에서는 MSK 서버리스 클러스터가 더 적합합니다.

이커머스 플랫폼의 경우 AnyCompany는 Kafka 기술 역량을 사용하고자 합니다. 또한 요구되는 처리량이 MSK 서버리스 할당량을 초과하고 애플리케이션에 일부 브로커 레벨의 사용자 정의 설정이 필요합니다. 또한 이커머스 플랫폼은 여러 클러스터로 분할할 수 없습니다. 이러한 이유로 AnyCompany는 이 시나리오에서 프로비저닝된 MSK 클러스터 유형을 선택합니다. 또한 AnyCompany는 프로비저닝된 Amazon MSK에 대한 요금 모델을 통해 비용을 더 많이 절약할 수 있습니다. 처리량은 대부분 일정하며 AnyCompany는 DataOps 팀을 사용하여 프로비저닝된 MSK 클러스터를 최적화하고 자체 전문 지식을 기반으로 확장에 대한 의사 결정을 내리고자 합니다.

결론

애플리케이션에 가장 적합한 클러스터 유형을 선택하는 것은 처음에는 복잡해 보일 수 있습니다. 이 게시글에서는 애플리케이션의 요구 사항과 사용 가능한 리소스를 반대로 살펴보는 데 도움이 되는 프로세스를 보여드렸습니다. 프로비저닝된 MSK클러스터는 클러스터를 확장, 구성 및 최적화하는 방식에 있어 더 많은 유연성을 제공합니다. 반면에 MSK 서버리스는 컴퓨팅 및 스토리지 용량을 관리할 필요 없이 Apache Kafka 클러스터를 더 쉽게 실행할 수 있는 클러스터 유형입니다. 일반적으로 애플리케이션에 브로커 수준의 사용자 정의 구성이 필요하지 않고 애플리케이션 트래픽 처리 요구 사항이 MSK 서버리스 클러스터 유형의 쿼터를 초과하지 않는 경우 MSK 서버리스로 시작하는 것이 좋습니다. 워크로드를 여러 개의 MSK 서버리스 클러스터로 분할하는 것이 가장 좋은 경우도 있지만, 이것이 불가능하다면 프로비저닝된 MSK클러스터를 고려해야 할 수도 있습니다. 프로비저닝된 MSK 클러스터를 최적화해서 운영하려면 조직 내에 Kafka에 대한 기술 역량이 있어야 합니다.

Amazon MSK에 대해서 더 많은 내용을 알고 싶으시면 공식 제품 페이지를 참고하시기 바랍니다.