RESOURCES

Amazon MSK(Amazon Managed Streaming for Apache Kafka)는 Apache Kafka 인프라 및 작업을 관리하는 AWS 스트리밍 데이터 서비스로, 개발자와 DevOps 관리자가 전문가가 아니어도 AWS에서 Apache Kafka 애플리케이션 및 Kafka Connect 커넥터를 쉽게 실행할 수 있습니다.

Amazon MSK는 Apache Kafka 클러스터를 운영, 유지 관리 및 확장하고, 즉시 사용 가능한 엔터프라이즈급 보안 기능을 제공하며 스트리밍 데이터 애플리케이션의 개발을 가속화하는 AWS 통합 기능을 내장하고 있습니다. 클릭 몇 번으로 AWS Management Console을 사용하여 MSK 클러스터를 생성하여 쉽게 시작할 수 있습니다.

 

클러스터를 생성할 때 프로비저닝 또는 서버리스의 두 가지 옵션 중에서 클러스터 유형을 선택해야 합니다. 각 워크로드에 가장 적합한 클러스터 유형을 선택하는 것은 워크로드 유형과 DevOps 기본 설정에 따라 다릅니다. 

Amazon MSK 프로비저닝된 클러스터는 클러스터를 확장, 구성 및 최적화하는 방법에 더 많은 유연성을 제공합니다. 반면에 Amazon MSK Serverless는 확장, 로드 관리 및 클러스터 운영을 더 쉽게 해줍니다. MSK Serverless를 사용하면 인프라를 구성, 관리하거나 클러스터를 최적화할 필요 없이 애플리케이션을 실행할 수 있으며 스트리밍 및 유지하는 데이터 볼륨에 대해서만 비용을 지불합니다. MSK Serverless는 모니터링을 포함하여 파티션을 완벽하게 관리하고 클러스터의 브로커 전체에 균등한 파티션 분배를 보장합니다(자동 균형 조정).

 

오늘 포스팅에서는 Amazon MSK를 두 가지 애플리케이션에 사용할 계획인 가상 회사 AnyCompany의 사용 사례를 살펴볼 예정입니다. 프로비저닝된 클러스터 유형과 서버리스 클러스터 유형 중에서 결정해야 하는데요, 이를 조직 구조 및 애플리케이션 요구 사항이 최상의 제안을 찾는데 어떻게 관련되는지를 포함하여 애플리케이션 요구 사항에서 역으로 작업하여 워크로드에 가장 적합한 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가 결정을 내리기 전에 수집해야 하는 관련 정보와 각 단계를 자세히 설명합니다.

 

 

Apache Kafka의 역량

 

 

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

 

유연성이 높을수록 더 많은 책임이 있는데요, 언제든지 클러스터의 크기가 적절한지 확인해야 합니다. 처리량에 필요한 리소스가 충분한지 확인하기 위해 클러스터 수준, 브로커 수준 및 주제 수준 지표 집합을 모니터링하여 이를 달성할 수 있습니다. 또한 각 브로커에 할당된 파티션 수가 Amazon MSK에서 제안한 수를 초과하지 않는지 확인해야 합니다. 파티션의 균형이 맞지 않으면 모든 브로커에 균등하게 로드해야 합니다. 권장보다 많은 파티션이 있는 경우 브로커를 더 큰 크기로 업그레이드하거나 클러스터의 브로커 수를 늘려야 합니다. AWS Identity and Access Management (IAM) 인증을 사용할 때 TCP 연결 수에 대한 모범 사례도 있습니다.

 

MSK 서버리스 클러스터는 클러스터의 적정 크기 조정과 브로커 간 파티션 균형의 복잡성을 제거합니다. 이를 통해 개발자는 애플리케이션 코드 작성에 쉽게 집중할 수 있습니다.

AnyCompany에는 MSK 프로비저닝 클러스터 유형에 대한 확장 작업 및 모범 사례에 익숙한 숙련된 DataOps 팀이 있습니다. AnyCompany는 DataOps 팀의 Kafka 전문 지식을 사용하여 전자 상거래 애플리케이션 팀을 대신하여 자동화 및 따르기 쉬운 표준 절차를 구축할 수 있습니다. 게임 개발팀은 인프라의 완전한 소유권을 가질 것으로 예상되기 때문에 예외입니다.

 

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

 

 

맞춤 구성

 

 

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

 

Amazon MSK 프로비저닝 오퍼링은 브로커, 주제 및 Apache ZooKeeper 노드에 대한 기본 구성을 제공합니다. 또한 사용자 정의 구성을 생성하고 이를 사용하여 새 MSK 클러스터를 생성하거나 기존 클러스터를 업데이트할 수 있습니다. MSK 클러스터 구성은 일련의 속성과 해당 값으로 구성됩니다.

 

MSK Serverless는 브로커 수준 구성 적용을 허용하지 않습니다. 이는 AWS가 백엔드 노드 구성 및 관리를 담당하기 때문입니다. 브로커 노드 구성의 부담을 덜어주기 때문에 애플리케이션의 주제만 관리하면 됩니다. 자세히 알아보려면 MSK 서버리스에서 변경할 수 있는 항목 수준 구성 목록을 참조하십시오.

 

전자 상거래 플랫폼과 달리 AnyCompany의 게임 애플리케이션은 브로커 수준의 사용자 지정 구성이 필요하지 않습니다. 개발자는 각 주제별로만 max.message.bytes과retention.ms를설정하려고 합니다.

 

신청 요건

 

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 Serverless에는 클러스터당 최대 파티션 수의 할당량도 있습니다. 지원 사례를 생성하여 할당량 증가를 요청할 수 있습니다.

 

파티션 수준 할당량

 

Apache Kafka는 주제라는 구조로 데이터를 구성합니다. 각 주제는 하나 또는 여러 파티션으로 구성됩니다. 파티션은 Apache Kafka의 병렬 처리 정도입니다. 데이터는 데이터 파티셔닝을 사용하여 브로커에 분산됩니다. 몇 가지 중요한 Amazon MSK 요구 사항과 애플리케이션에 더 적합한 클러스터 유형을 확인하는 방법을 살펴보겠습니다.

 

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

 

보안

 

Amazon MSK는 다음과 같은 방법으로 데이터를 보호할 것을 권장합니다. 보안 기능의 가용성은 클러스터 유형에 따라 다릅니다. 클러스터 유형에 대한 결정을 내리기 전에 선택한 클러스터 유형에서 선호하는 보안 옵션이 지원되는지 확인하십시오.

 

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

 

소유 비용

 

Amazon MSK를 사용하면 Apache Kafka 클러스터를 관리하는 데 막대한 시간과 상당한 리소스를 소비하지 않아도 되므로 비즈니스에 거의 또는 전혀 가치를 추가할 수 없습니다. Amazon MSK 콘솔에서 클릭 몇 번으로 Apache Kafka의 배포 모범 사례를 기반으로 한 설정 및 구성으로 고가용성 Apache Kafka 클러스터를 생성할 수 있습니다. Amazon MSK는 Apache Kafka 클러스터를 자동으로 프로비저닝하고 실행합니다. 

 

Amazon MSK는 클러스터 상태를 지속적으로 모니터링하고 애플리케이션 가동 중지 시간 없이 비정상 노드를 자동으로 교체합니다. 또한 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 클라이언트 라이브러리를 사용하거나 다른 이유 때문일 수 있습니다. 예를 들어 Apache Kafka 관리 작업 또는 Cruise Control 과 같은 가시성을 지원하는 애플리케이션에는 일반적으로 이러한 종류의 액세스가 필요합니다.

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

 

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

 

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

 

 

 

게임 애플리케이션의 경우 AnyCompany는 사내 Kafka 역량을 사용하여 MSK 프로비저닝 클러스터를 지원하기를 원하지 않습니다. 또한 게임 애플리케이션에는 사용자 지정 구성이 필요하지 않으며 해당 처리량 요구 사항은 MSK 서버리스 클러스터 유형에서 설정한 할당량 미만입니다. 이 시나리오에서는 MSK 서버리스 클러스터가 더 적합합니다.

 

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

 

결론

 

애플리케이션에 가장 적합한 클러스터 유형을 선택하는 것이 처음에는 복잡해 보일 수 있습니다. 이 게시물에서는 애플리케이션의 요구 사항과 사용 가능한 리소스에서 거꾸로 작업하는 데 도움이 되는 프로세스를 보여 주었습니다. MSK 프로비저닝 클러스터는 클러스터를 확장, 구성 및 최적화하는 방법에 더 많은 유연성을 제공합니다. 

 

반면 MSK 서버리스는 컴퓨팅 및 스토리지 용량을 관리할 필요 없이 Apache Kafka 클러스터를 더 쉽게 실행할 수 있는 클러스터 유형입니다. 일반적으로 애플리케이션에 브로커 수준 사용자 지정 구성이 필요하지 않고 애플리케이션 처리량이 MSK 서버리스 클러스터 유형의 할당량을 초과하지 않는 경우 MSK 서버리스로 시작하는 것이 좋습니다. 경우에 따라 여러 MSK Serverless 클러스터 간에 워크로드를 분할하는 것이 가장 좋지만 이것이 가능하지 않은 경우에는 MSK 프로비저닝 클러스터를 고려해야 할 수도 있습니다. 최적화된 MSK 프로비저닝 클러스터를 운영하려면 조직 내에서 Kafka 역량이 있어야 합니다.

 

Amazon MSK에 대한 자세한 내용은 공식 제품 페이지를 참조하십시오.

 

 

원문URL: https://aws.amazon.com/ko/blogs/big-data/how-to-choose-the-right-amazon-msk-cluster-type-for-you/

 

메가존클라우드 TechBlog는 AWS BLOG 영문 게재 글이나 관련 기사 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.