기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon MSK 주요 기능 및 개념
Amazon MSK Provisioned 클러스터는 클러스터의 성능을 최적화하고 스트리밍 요구 사항을 충족하는 데 도움이 되는 다양한 기능을 제공합니다. 아래 주제에서는 이러한 기능에 대해 자세히 설명합니다.
+ [AWS Management Console](https://console.aws.amazon.com/msk)은
+ [Amazon MSK API 참조](https://docs.aws.amazon.com/msk/1.0/apireference)
+ [Amazon MSK CLI 명령 참조](https://docs.aws.amazon.com/cli/latest/reference/kafka/index.html)
**Topics**
+ [Amazon MSK 브로커 유형](broker-instance-types.md)
+ [Amazon MSK 브로커 크기](broker-instance-sizes.md)
+ [Standard 브로커의 스토리지 관리](msk-storage-management.md)
+ [Amazon MSK Provisioned 구성](msk-configuration.md)
+ [클러스터의 지능형 리밸런싱](intelligent-rebalancing.md)
+ [MSK Provisioned 클러스터에 패치 적용](patching-impact.md)
+ [브로커 오프라인 및 클라이언트 장애 조치](troubleshooting-offlinebroker-clientfailover.md)
+ [Amazon MSK의 보안](security.md)
+ [Amazon MSK 로깅](msk-logging.md)
+ [메타데이터 관리](metadata-management.md)
+ [주제 작업](msk-topic-operations-information.md)
+ [Amazon MSK 리소스](resources.md)
+ [Apache Kafka 버전](kafka-versions.md)
+ [Amazon MSK 클러스터 문제 해결](troubleshooting.md)
# Amazon MSK 브로커 유형
MSK Provisioned는 Standard와 Express라는 두 가지 브로커 유형을 제공합니다. Standard 브로커는 클러스터를 가장 유연하게 구성할 수 있는 반면, Express 브로커는 고성능 스트리밍 애플리케이션 실행을 위한 탄력성, 처리량, 복원력, 사용 편의성을 제공합니다.
각 유형에 대한 자세한 내용은 다음 토픽을 참조하세요. 다음 표에는 Standard 브로커와 Express 브로커 간의 주요 기능을 비교한 내용도 강조되어 있습니다.
| 기능 | Standard 브로커 | Express 브로커 |
| --- | --- | --- |
| [스토리지 관리](msk-storage-management.md) | 고객 관리형(특징: EBS 스토리지, 계층형 스토리지, 프로비저닝된 스토리지 처리량, 오토 스케일링, 스토리지 용량 알림) | 완전 MSK 관리형 |
| [지원되는 인스턴스](broker-instance-sizes.md) | T3, M5, M7g | M7g |
| [크기 및 규모 조정 고려 사항](bestpractices-intro.md) | 처리량, 연결, 파티션, 스토리지 | 처리량, 연결, 파티션 |
| [브로커 규모 조정](msk-update-broker-count.md) | 수직 및 수평 규모 조정 | 수직 및 수평 규모 조정 |
| [Kafka 버전](kafka-versions.md) | [Apache Kafka 버전](kafka-versions.md) 섹션을 참조하세요 | 버전 3.6에서 시작 |
| [Apache Kafka 구성](msk-configuration.md) | 추가 구성 가능 | 복원력 향상을 위해 대부분 MSK 관리형임 |
| [보안](security.md) | 암호화, 프라이빗/퍼블릭 액세스, 인증 및 권한 부여 - IAM, SASL/SCRAM, mTLS, 일반 텍스트, Kafka ACL | 암호화, 프라이빗/퍼블릭 액세스, 인증 및 권한 부여 - IAM, SASL/SCRAM, mTLS, 일반 텍스트, Kafka ACL |
| [모니터링](monitoring.md) | CloudWatch, 오픈 모니터링 | CloudWatch, 오픈 모니터링 |
**참고**
MSK API를 사용하여 브로커 유형을 전환하면 MSK 프로비저닝 클러스터를 Standard 브로커 유형에서 Express 브로커 유형으로 변경할 수 없습니다. 원하는 브로커 유형(Standard 또는 Express)으로 새 클러스터를 생성해야 합니다.
**Topics**
+ [Amazon MSK Standard 브로커](msk-broker-types-standard.md)
+ [Amazon MSK Express 브로커](msk-broker-types-express.md)
# Amazon MSK Standard 브로커
MSK 프로비저닝용 Standard 브로커는 클러스터의 성능을 구성할 수 있는 가장 유연한 기능을 제공합니다. 광범위한 클러스터 구성 중에서 선택하여 애플리케이션에 필요한 가용성, 내구성, 처리량 및 지연 시간 특성을 달성할 수 있습니다. 스토리지 용량을 프로비저닝하고 필요에 따라 늘릴 수도 있습니다. Amazon MSK는 Standard 브로커 및 연결된 스토리지 리소스의 하드웨어 유지 관리를 처리하여 발생할 수 있는 하드웨어 문제를 자동으로 복구합니다. [스토리지 관리](msk-storage-management.md), [구성](msk-configuration-standard.md) 및 [유지 관리](patching-impact.md#patching-standard-brokers)에 대한 주제를 포함하여 Standard 브로커 관련 여러 주제에 대한 자세한 내용은 이 문서에서 확인할 수 있습니다.
# Amazon MSK Express 브로커
MSK용 Express 브로커 프로비저닝을 사용하면 Apache Kafka를 더 간단하게 관리하고 더 비용 효율적으로 대규모로 실행할 수 있으며, 기대를 충족하는 짧은 지연 시간으로 더 탄력적으로 운영할 수 있습니다. 브로커에는 자동으로 확장되고 크기 조정, 프로비저닝 또는 사전 예방적 모니터링이 필요하지 않은 종량제 스토리지가 포함됩니다. 선택한 인스턴스 크기에 따라 각 브로커 노드는 표준 Apache Kafka 브로커에 비해 브로커당 최대 3배 더 많은 처리량을 제공하고, 최대 20배 더 빠르게 스케일 업하고, 90% 더 빠르게 복구할 수 있습니다. Express 브로커는 Amazon MSK의 모범 사례 기본값으로 사전 구성되어 있으며, 클라이언트 처리량 할당량을 적용하여 클라이언트와 Kafka의 백그라운드 작업 간의 리소스 경합을 최소화합니다.
다음은 Express 브로커를 사용할 때 고려해야 할 몇 가지 주요 요인과 기능입니다.
+ **스토리지 관리 없음**: Express 브로커는 [스토리지 리소스를 프로비저닝하거나 관리할 필요가 없습니다](msk-storage-management.md). 탄력적, 사실상 무제한, 종량제 및 완전관리형 스토리지를 사용할 수 있습니다. 처리량이 많은 사용 사례의 경우 컴퓨팅 인스턴스와 스토리지 볼륨 간의 상호 작용과 관련 처리량 병목 현상을 추론할 필요가 없습니다. 이러한 기능은 클러스터 관리를 간소화하고 스토리지 관리 운영 오버헤드를 제거합니다.
+ **더 빠른 조정**: Express 브로커를 사용하면 Standard 브로커보다 최대 20배 빠르게 클러스터를 조정하고 파티션을 이동할 수 있습니다. 이 기능은 예정된 로드 급증을 처리하기 위해 클러스터를 스케일 아웃하거나 비용을 줄이기 위해 클러스터를 스케일 인해야 하는 경우에 매우 중요합니다. 클러스터 규모 조정에 대한 자세한 내용은 [클러스터 확장](msk-update-broker-count.md), [브로커 제거](msk-remove-broker.md), [파티션 재할당](msk-update-broker-type.md) 및 [재분배를 위한 LinkedIn의 Cruise Control 설정](cruise-control.md)에 대한 섹션을 참조하세요.
+ **높은 처리량**: Express 브로커는 Standard 브로커보다 브로커당 최대 3배 더 많은 처리량을 제공합니다. 예를 들어 각 m7g.16xlarge 크기의 Express 브로커로 최대 500MBps의 데이터를 안전하게 쓸 수 있는 데 비해 동등한 Standard 브로커의 경우 153.8MBps입니다(두 수치 모두 복제 및 리밸런싱과 같은 백그라운드 작업에 충분한 대역폭이 할당되었다고 가정한 것임).
+ **높은 복원력을 위한 구성**: Express 브로커는 클러스터의 복원력을 개선하기 위해 다양한 모범 사례를 자동으로 제공합니다. 여기에는 중요한 Apache Kafka 구성에 대한 가드레일, 처리량 할당량, 백그라운드 운영 및 계획되지 않은 수리를 위한 용량 예약이 포함됩니다. 이러한 기능을 사용하면 대규모 Apache Kafka 애플리케이션을 더 안전하고 쉽게 실행할 수 있습니다. 자세한 내용은 [Express 브로커 구성](msk-configuration-express.md) 및 [Amazon MSK Express 브로커 할당량](limits.md#msk-express-quota) 섹션을 참조하세요.
+ **유지 관리 기간 불필요**: Express 브로커에 대한 유지 관리 기간이 불필요합니다. Amazon MSK는 클러스터 하드웨어를 지속적으로 자동으로 업데이트합니다. 자세한 내용은 [Express 브로커 패치 적용](https://docs.aws.amazon.com/msk/latest/developerguide/patching-impact.html#patching-express-brokers)을 참조하세요.
## Express 브로커에 대한 추가 정보
+ Express 브로커는 Apache Kafka API에서 작동하지만 아직 KStreams API를 완전히 지원하지 않습니다.
+ Express 브로커는 3AZ 구성에서만 사용할 수 있습니다.
+ Express 브로커는 일부 인스턴스 크기에서만 사용할 수 있습니다. 업데이트된 목록은 [Amazon MSK 요금](https://aws.amazon.com/msk/pricing/)을 참조하세요.
+ Express 브로커는 3.6, 3.8 및 3.9 버전의 Apache Kafka에서 지원됩니다.
+ Express 브로커는 Apache Kafka 버전 3.9 이상에서 KRaft 모드로 생성할 수 있습니다.
**관련 블로그 보기**
MSK Express 브로커에 대한 자세한 내용과 사용 중인 Express 브로커의 실제 예를 보려면 다음 블로그를 참조하세요.
[Kafka 클러스터에 높은 처리량과 더 빠른 크기 조정을 제공하는 Amazon MSK용 Express 브로커 소개](https://aws.amazon.com/blogs/aws/introducing-express-brokers-for-amazon-msk-to-deliver-high-throughput-and-faster-scaling-for-your-kafka-clusters/)
[Amazon MSK용 Express 브로커: 최대 20배 더 빠른 고성능 Kafka 규모 조정](https://aws.amazon.com/blogs/big-data/express-brokers-for-amazon-msk-turbo-charged-kafka-scaling-with-up-to-20-times-faster-performance/)
이 블로그는 Express 브로커가 다음을 수행하는 방법을 보여줍니다.
더 빠른 처리량, 신속한 규모 조정 및 장애로 인한 복구 시간 개선
스토리지 관리 복잡성 제거
# Amazon MSK 브로커 크기
Amazon MSK 프로비저닝된 클러스터를 생성하는 경우 클러스터에 포함할 브로커 크기를 지정합니다. [브로커 유형](broker-instance-types.md)에 따라 Amazon MSK는 다음 브로커 크기를 지원합니다.
**Standard 브로커 크기**
+ kafka.t3.small
+ kafka.m5.large, kafka.m5.xlarge, kafka.m5.2xlarge, kafka.m5.4xlarge, kafka.m5.8xlarge, kafka.m5.12xlarge, kafka.m5.16xlarge, kafka.m5.24xlarge
+ kafka.m7g.large, kafka.m7g.xlarge, kafka.m7g.2xlarge, kafka.m7g.4xlarge, kafka.m7g.8xlarge, kafka.m7g.12xlarge, kafka.m7g.16xlarge
**Express 브로커 크기**
+ express.m7g.large, express.m7g.xlarge, express.m7g.2xlarge, express.m7g.4xlarge, express.m7g.8xlarge, express.m7g.12xlarge, express.m7g.16xlarge
**참고**
일부 브로커 크기는 인증서 AWS 리전에서 사용하지 못할 수 있습니다. 리전별로 이용 가능한 인스턴스의 최신 목록은 [Amazon MSK 요금 페이지](https://aws.amazon.com/msk/pricing/)에서 업데이트된 브로커 인스턴스 요금 테이블을 참조하세요.
## 브로커 크기에 대한 기타 참고 사항
+ M7g 브로커는 AWS Graviton 프로세서(Amazon Web Services에서 구축한 사용자 지정 Arm 기반 프로세서)를 사용합니다. M7g 브로커는 비슷한 M5 인스턴스에 비해 향상된 가격 대비 성능을 제공합니다. M7g 브로커는 유사한 M5 인스턴스보다 적은 전력을 소비합니다.
+ Amazon MSK는 2.8.2 및 3.3.2 이상의 Kafka 버전을 실행하는 MSK 프로비저닝된 클러스터에서 M7g 브로커를 지원합니다.
+ M7g 및 M5 브로커는 T3 브로커보다 기본 처리량 성능이 높으며 프로덕션 워크로드에 권장됩니다. 또한 M7g 및 M5 브로커는 T3 브로커보다 브로커당 파티션 수가 더 많을 수 있습니다. 더 대규모의 프로덕션급 워크로드를 실행 중이거나 더 많은 수의 파티션이 필요한 경우 M7g 및 M5 브로커를 사용하세요. M7g 및 M5 인스턴스 크기에 대한 자세한 내용은 [Amazon EC2 범용 인스턴스](https://aws.amazon.com/ec2/instance-types/)를 참조하세요.
+ T3 브로커는 CPU 크레딧을 사용하여 성능을 일시적으로 버스트할 수 있습니다. 저비용 개발의 경우, 중소 규모의 스트리밍 워크로드를 테스트 중인 경우 또는 처리량이 일시적으로 급증하는 낮은 처리량 스트리밍 워크로드가 있는 경우 T3 브로커를 사용하십시오. T3 브로커가 프로덕션 또는 중요한 워크로드에 충분한지 확인하기 위해 개념 증명 테스트를 실행하는 것이 좋습니다. T3 브로커 크기에 대한 자세한 내용은 [Amazon EC2 T3 인스턴스](https://aws.amazon.com/ec2/instance-types/t3/)를 참조하세요.
브로커 크기를 선택하는 방법에 대한 자세한 내용은 [Standard 및 Express 브로커 모범 사례](bestpractices-intro.md) 단원을 참조하세요.
# Standard 브로커의 스토리지 관리
Amazon MSK는 MSK 클러스터의 스토리지 관리에 도움이 되는 기능을 제공합니다.
**참고**
[Express 브로커](msk-broker-types-express.md)를 사용하면 데이터에 사용되는 스토리지 리소스를 프로비저닝하거나 관리할 필요가 없습니다. 이를 통해 클러스터 관리가 간소화되고 Apache Kafka 클러스터 운영 문제의 일반적인 원인 중 하나가 제거됩니다. 또한 유휴 스토리지 용량을 프로비저닝할 필요가 없고 사용한 만큼만 비용을 지불하면 되므로 비용을 절감할 수 있습니다.
**Standard 브로커 유형**
[Standard 브로커](msk-broker-types-standard.md)를 사용하면 다양한 스토리지 옵션과 기능 중에서 선택할 수 있습니다. Amazon MSK는 MSK 클러스터의 스토리지 관리에 도움이 되는 기능을 제공합니다.
처리량 관리에 대한 자세한 내용은 [Amazon MSK 클러스터의 Standard 브로커에 대한 스토리지 처리량 프로비저닝](msk-provision-throughput.md) 섹션을 참조하세요.
**Topics**
+ [Standard 브로커를 위한 계층형 스토리지](msk-tiered-storage.md)
+ [Amazon MSK Standard 브로커 스토리지 스케일 업](msk-update-storage.md)
+ [Amazon MSK 클러스터의 Standard 브로커에 대한 스토리지 처리량 관리](msk-provision-throughput-management.md)
# Standard 브로커를 위한 계층형 스토리지
계층형 스토리지는 사실상 무제한 스토리지로 확장할 수 있어 스트리밍 데이터 애플리케이션을 비용 효율적으로 빌드할 수 있는 Amazon MSK의 저비용 스토리지 계층입니다.
성능과 비용의 균형을 맞추는 계층형 스토리지로 구성된 Amazon MSK 클러스터를 생성할 수 있습니다. Amazon MSK는 Apache Kafka 주제 보존 한도에 도달할 때까지 스트리밍 데이터를 성능에 최적화된 기본 스토리지 계층에 저장합니다. 그러면 Amazon MSK가 자동으로 데이터를 새로운 저비용 스토리지 계층으로 이동합니다.
애플리케이션이 계층형 스토리지에서 데이터를 읽기 시작하면 처음 몇 바이트 동안 읽기 지연 시간이 늘어날 수 있습니다. 저비용 계층에서 나머지 데이터를 순차적으로 읽기 시작하면 기본 스토리지 계층과 비슷한 수준의 지연 시간을 예상할 수 있습니다. 저비용 계층형 스토리지를 위해 스토리지를 프로비저닝하거나 인프라를 관리할 필요가 없습니다. 원하는 만큼만 데이터를 저장하고 사용한 만큼만 비용을 지불할 수 있습니다. 이 기능은 [KIP-405: Kafka 계층화된 스토리지](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage)에 도입된 API와 호환됩니다.
MSK 계층형 스토리지 클러스터의 규모 조정, 모니터링 및 최적화에 대한 자세한 내용은 [Amazon MSK 계층형 스토리지를 사용하여 프로덕션 워크로드를 실행하는 모범 사례](https://aws.amazon.com/blogs/big-data/best-practices-for-running-production-workloads-using-amazon-msk-tiered-storage/)를 참조하세요.
다음은 계층형 스토리지의 몇 가지 기능입니다.
+ 스토리지 규모를 거의 무제한으로 조정할 수 있습니다. Apache Kafka 인프라의 규모를 조정하는 방법을 추측할 필요가 없습니다.
+ 브로커 수를 늘리지 않고도 Apache Kafka 주제에 데이터를 더 오래 보관하거나 주제 저장 공간을 늘릴 수 있습니다.
+ 예기치 않은 처리 지연을 처리하기 위해 더 긴 기간의 안전 버퍼를 제공합니다.
+ 기존 스트림 처리 코드와 Kafka API를 사용하여 정확한 생산 순서대로 오래된 데이터를 재처리할 수 있습니다.
+ 보조 스토리지의 데이터는 브로커 디스크 간에 복제할 필요가 없으므로 파티션이 더 빠르게 재조정됩니다.
+ 브로커와 계층화된 스토리지 간의 데이터는 VPC 내에서 이동하며 인터넷을 통해 이동하지 않습니다.
+ 클라이언트 머신은 계층형 스토리지가 활성화되지 않은 클러스터에 연결할 때와 동일한 프로세스를 사용하여 계층형 스토리지가 활성화된 새 클러스터에 연결할 수 있습니다. [클라이언트 머신 생성](https://docs.aws.amazon.com/msk/latest/developerguide/create-client-machine.html)을 참조하세요.
## Amazon MSK 클러스터에 대한 계층형 스토리지 요구 사항
+ 계층형 스토리지를 사용하도록 설정한 새 주제를 생성하려면 Apache Kafka 클라이언트 버전 3.0.0 이상을 사용해야 합니다. 기존 토픽을 계층형 스토리지로 전환하려면, 3.0.0(지원되는 최소 Apache Kafka 버전은 2.8.2.tiered)보다 낮은 Kafka 클라이언트 버전을 사용하는 클라이언트 머신을 재구성하여 계층형 스토리지를 사용하도록 설정할 수 있습니다. [4단계: Amazon MSK 클러스터에서 주제 생성](create-topic.md)을(를) 참조하세요.
+ 계층형 스토리지가 활성화된 Amazon MSK 클러스터는 버전 3.6.0 이상 또는 2.8.2.tiered를 사용해야 합니다.
## Amazon MSK 클러스터에 대한 계층형 스토리지 제약 조건 및 제한 사항
계층형 스토리지에는 다음과 같은 제약과 제한 사항이 있습니다.
+ 애플리케이션이 트랜잭션 기능을 적극적으로 사용하지 않는 한 Amazon MSK의 remote\$1tier에서 읽을 때 클라이언트에서 `read_committed`에 구성되지 않았는지 확인합니다.
+ 계층형 스토리지는 AWS GovCloud(미국) 리전에서 사용할 수 없습니다.
+ 계층형 스토리지는 프로비저닝 모드 클러스터에만 적용됩니다.
+ 계층형 스토리지는 브로커 크기 t3.small을 지원하지 않습니다.
+ 저비용 스토리지의 최소 보존 기간은 3일입니다. 기본 스토리지에는 최소 보존 기간이 없습니다.
+ 계층형 스토리지는 브로커에서 다중 로그 디렉터리(JBOD 관련 기능)를 지원하지 않습니다.
+ 계층형 스토리지는 압축된 주제를 지원하지 않습니다. 계층형 스토리지가 설정된 모든 주제의 cleanup.policy가 'DELETE'로만 구성되어 있는지 확인합니다.
+ 계층형 스토리지 클러스터는 주제가 생성된 후 주제에 대한 log.cleanup.policy 정책 변경을 지원하지 않습니다.
+ 계층형 스토리지는 개별 주제에 대해 비활성화할 수 있지만 전체 클러스터에서는 비활성화할 수 없습니다. 일단 비활성화되면 주제에 대해 계층형 스토리지를 다시 활성화할 수 없습니다.
+ Amazon MSK 버전 2.8.2.tiered를 사용하는 경우 다른 계층형 스토리지를 지원하는 Apache Kafka 버전으로만 마이그레이션할 수 있습니다. 계층형 스토리지 지원 버전을 계속 사용하지 않으려면 새로운 MSK 클러스터를 생성하고 해당 클러스터로 마이그레이션하세요.
+ kafka-log-dirs 도구는 계층화된 스토리지 데이터 크기를 보고할 수 없습니다. 이 도구는 기본 스토리지에 있는 로그 세그먼트의 크기만 보고합니다.
주제 수준에서 계층형 스토리지를 구성할 때 기본 설정 및 제약 조건에 대한 자세한 내용은 [Amazon MSK 계층형 스토리지 주제 수준의 구성에 대한 지침](msk-guidelines-tiered-storage-topic-level-config.md) 섹션을 참조하세요.
# Amazon MSK 주제에 대해 로그 세그먼트를 계층형 스토리지로 복사하는 방법
새 주제 또는 기존 주제에 대해 계층형 스토리지를 활성화하면 Apache Kafka가 기본 스토리지에서 계층형 스토리지로 닫힌 로그 세그먼트를 복사합니다.
+ Apache Kafka는 닫힌 로그 세그먼트만 복사합니다. 로그 세그먼트 내의 모든 메시지를 계층화된 스토리지에 복사합니다.
+ 활성 세그먼트는 계층화 대상이 아닙니다. 로그 세그먼트 크기(segment.bytes) 또는 세그먼트 롤링 시간(segment.ms)은 세그먼트 닫기 속도를 제어하며 Apache Kafka가 세그먼트를 계층형 스토리지로 복사하는 속도도 제어합니다.
계층형 스토리지가 활성화된 주제의 보존 설정은 계층형 스토리지가 활성화되지 않은 주제의 설정과 다릅니다. 다음 규칙은 계층형 스토리지가 활성화된 주제의 메시지 보존을 제어합니다.
+ Apache Kafka에서 보존은 log.retention.ms(시간)와 log.retention.bytes(크기)의 두 가지 설정으로 정의할 수 있습니다. 이러한 설정은 Apache Kafka가 클러스터에 보관하는 데이터의 총 기간과 크기를 결정합니다. 계층형 스토리지 모드 사용 여부에 관계없이 이러한 구성은 클러스터 수준에서 설정합니다. 주제 구성으로 주제 수준에서 설정을 재정의할 수 있습니다.
+ 계층형 스토리지를 사용하도록 설정하면 기본 고성능 스토리지 계층에서 데이터를 저장하는 기간을 추가로 지정할 수 있습니다. 예를 들어 토픽의 전체 보존(log.retention.ms) 설정이 7일이고 로컬 보존(local.retention.ms)이 12시간인 경우 클러스터 기본 스토리지에는 처음 12시간 동안만 데이터를 보존합니다. 저비용 스토리지 계층은 7일 동안 데이터를 보존합니다.
+ 일반 보존 설정이 전체 로그에 적용됩니다. 여기에는 계층화된 부분과 기본 부분이 포함됩니다.
+ local.retention.ms 또는 local.retention.bytes 설정은 기본 저장소의 메시지 보존을 제어합니다. Apache Kafka는 로컬 보존 설정과 관계없이 닫힌 로그 세그먼트를 닫는 즉시 계층형 스토리지에 복사합니다(세그먼트.바이트 또는 segment.ms 기준). 세그먼트는 계층형 스토리지로 복사된 후 local.retention.ms 또는 local.retention.bytes 임계값에 도달할 때까지 기본 스토리지에 남아 있습니다. 이때 데이터는 기본 스토리지에서 삭제되지만 계층형 스토리지에서는 계속 사용할 수 있습니다. 이렇게 하면 저렴한 계층형 스토리지에서 이전 데이터를 제공하는 동안 빠른 액세스를 위해 최신 데이터를 고성능 기본 스토리지에 유지할 수 있습니다.
+ 로그 세그먼트의 메시지를 계층형 스토리지에 복사할 때 Apache Kafka는 retention.ms 또는 retention.bytes 설정에 따라 클러스터에서 메시지를 제거합니다.
## Amazon MSK 계층형 스토리지 시나리오 예제
이 시나리오는 계층화된 스토리지가 활성화될 때 기본 스토리지에 메시지가 있는 기존 주제가 어떻게 작동하는지 보여줍니다. 이 주제에서 계층형 스토리지를 사용하려면 remote.storage.enable을 `true`로 설정하면 됩니다. 이 예제에서 retention.ms는 5일로 설정되고 local.retention.ms는 2일로 설정됩니다. 다음은 세그먼트가 만료될 때 발생하는 이벤트 순서입니다.
**시간 T0 - 계층형 스토리지를 활성화하기 전.**
이 주제에 대해 계층형 스토리지를 활성화하기 전에 2개의 로그 세그먼트가 있습니다. 세그먼트 중 하나가 기존 토픽 파티션 0에 대해 활성화되어 있습니다.
![\[시간 T0 - 계층형 스토리지를 활성화하기 전입니다.\]](http://docs.aws.amazon.com/ko_kr/msk/latest/developerguide/images/tiered-storage-segments-1.png)
**시간 T1(2일 미만) - 계층형 스토리지가 활성화되었으며, 세그먼트 0이 계층형 스토리지에 복사되었습니다.**
이 주제에 대해 계층형 스토리지를 활성화하면 Apache Kafka는 닫힌 로그 세그먼트 0이 닫히는 즉시 계층형 스토리지에 복사합니다. 세그먼트는 보존 설정이 아닌 segment.bytes 또는 segment.ms 설정을 기반으로 닫힙니다. Apache Kafka는 기본 스토리지에도 사본을 보관합니다. 활성 세그먼트 1은 아직 활성 상태이고 닫히지 않았으므로 아직 계층형 스토리지로 복사할 수 없습니다. 이 타임라인에서 Amazon MSK는 세그먼트 0 및 세그먼트 1의 메시지에 대해 아직 어떤 보존 설정도 적용하지 않습니다. (local.retention.bytes/ms, retention.ms/bytes)
![\[시간 T1(2일 미만) - 계층형 스토리지가 활성화되었으며, 세그먼트 0이 계층형 스토리지에 복사되었습니다.\]](http://docs.aws.amazon.com/ko_kr/msk/latest/developerguide/images/tiered-storage-segments-2.png)
**시간 T2 - 로컬 보존이 적용됨.**
2일 후 세그먼트 0의 로컬 보존 임계값에 도달합니다. local.retention.ms를 2일로 설정하면 이것이 결정됩니다. 세그먼트 0은 이제 기본 스토리지에서 삭제되지만 계층형 스토리지에서 계속 사용할 수 있습니다. 세그먼트 0은 로컬 보존 기간이 만료된 시간 T2가 아니라 닫힌 시간 T1에 계층형 스토리지에 이미 복사되었습니다. T2 활성 세그먼트 1은 아직 활성 상태이므로 삭제하거나 계층형 스토리지로 복사할 수 없습니다.
![\[시간 T2 - 로컬 보존이 적용됨.\]](http://docs.aws.amazon.com/ko_kr/msk/latest/developerguide/images/tiered-storage-segments-3.png)
**시간 T3 - 전체 보존이 유효함.**
5일 후에는 보존 설정이 적용되고 Kafka는 계층형 스토리지에서 로그 세그먼트 0과 관련 메시지를 삭제합니다. 세그먼트 1은 아직 활성이므로 만료 대상도 아니고 계층형 스토리지로 복사할 수 있는 대상도 아닙니다. 세그먼트 1은 아직 닫히지 않았으므로 세그먼트 롤에 사용할 수 없습니다.
![\[시간 T3 - 전체 보존이 유효함.\]](http://docs.aws.amazon.com/ko_kr/msk/latest/developerguide/images/tiered-storage-segments-4.png)
# 를 사용하여 계층형 스토리지로 Amazon MSK 클러스터 생성 AWS Management Console
이 프로세스는 AWS Management Console을 사용하여 계층형 스토리지 Amazon MSK 클러스터를 생성하는 방법을 설명합니다.
1. [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/)에서 Amazon MSK 콘솔을 엽니다.
1. **클러스터 생성**을 선택합니다.
1. 계층형 스토리지에 대해 **사용자 지정 생성**을 선택합니다.
1. 클러스터의 이름을 지정합니다.
1. **클러스터 유형**에서 **프로비저닝**을 선택합니다.
1. 클러스터를 생성하는 데 사용할 Amazon MSK 계층형 스토리지를 지원하는 Amazon Kafka 버전을 선택합니다.
1. **kafka.t3.small** 이외의 브로커 크기를 지정합니다.
1. 각 가용 영역에서 Amazon MSK가 생성할 브로커 수를 선택합니다. 최소는 가용 영역당 브로커 1개, 최대는 클러스터당 브로커 30개입니다.
1. 브로커가 배포되는 영역의 수를 지정합니다.
1. 영역당 배포되는 Apache Kafka 브로커의 수를 지정합니다.
1. **스토리지 옵션**을 선택합니다. 여기에는 **계층형 스토리지 및 EBS 스토리지**가 포함되어 계층화된 스토리지 모드를 사용할 수 있습니다.
1. 클러스터 생성 마법사의 나머지 단계를 수행합니다. 완료되면 **계층형 스토리지 및 EBS 스토리지**가 **검토 및 생성** 보기에 클러스터 스토리지 모드로 나타납니다.
1. [**클러스터 생성(Create cluster)**]을 선택합니다.
# 를 사용하여 계층형 스토리지로 Amazon MSK 클러스터 생성 AWS CLI
클러스터에서 계층형 스토리지를 사용하려면 계층형 스토리지에 적합한 Apache Kafka 버전과 속성을 사용하여 클러스터를 생성하세요. 아래 코드 예시를 참조하세요. 또한 다음 섹션의 단계를 [를 사용하여 계층형 스토리지가 활성화된 Kafka 주제 생성 AWS CLI](#msk-create-topic-tiered-storage-cli)로 완료합니다.
클러스터 생성에 지원되는 전체 속성 목록은 [create-cluster](https://docs.aws.amazon.com//cli/latest/reference/kafka/create-cluster.html)를 참조하세요.
```
aws kafka create-cluster \
—cluster-name "MessagingCluster" \
—broker-node-group-info file://brokernodegroupinfo.json \
—number-of-broker-nodes 3 \
--kafka-version "3.6.0" \
--storage-mode "TIERED"
```
## 를 사용하여 계층형 스토리지가 활성화된 Kafka 주제 생성 AWS CLI
계층형 스토리지를 사용하도록 설정한 클러스터를 만들 때 시작한 프로세스를 완료하려면 이후 코드 예제에서 속성을 사용하여 계층형 스토리지를 사용하도록 설정한 주제도 생성합니다. 계층형 스토리지에 대한 구체적인 속성은 다음과 같습니다.
+ 시간 기반 보존 설정의 경우 `local.retention.ms`(예: 10분), 로그 세그먼트 크기 제한의 경우 `local.retention.bytes`입니다.
+ `remote.storage.enable`을 `true`로 설정하여 계층형 스토리지를 활성화합니다.
다음 구성에서는 local.retention.ms를 사용하지만 이 속성은 local.retention.bytes로 대체할 수 있습니다. 이 속성은 Apache Kafka가 기본 스토리지에서 계층형 스토리지로 데이터를 복사하기 전 Apache Kafka가 복사할 수 있는 바이트 수 또는 경과할 수 있는 시간을 제어합니다. 지원되는 구성 속성에 대한 자세한 내용은 [주제 수준 구성](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration)을 참조하세요.
**참고**
Apache Kafka 클라이언트 버전 3.0.0 이상을 사용해야 합니다. 이러한 버전은 해당 클라이언트 버전 `kafka-topics.sh`에서만 `remote.storage.enable`이라는 설정을 지원합니다. 이전 버전의 Apache Kafka를 사용하는 기존 주제에서 계층형 스토리지를 활성화하려면 [기존 Amazon MSK 주제에서 계층형 스토리지 활성화](msk-enable-disable-topic-tiered-storage-cli.md#msk-enable-topic-tiered-storage-cli) 섹션을 참조하세요.
```
bin/kafka-topics.sh --create --bootstrap-server $bs --replication-factor 2 --partitions 6 --topic MSKTutorialTopic --config remote.storage.enable=true --config local.retention.ms=100000 --config retention.ms=604800000 --config segment.bytes=134217728
```
# 기존 Amazon MSK 주제에서 계층형 스토리지 활성화 및 비활성화
이 섹션에서는 이미 만든 주제에서 계층형 스토리지를 활성화 및 비활성화하는 방법에 대해 설명합니다. 계층형 스토리지가 활성화된 상태에서 새 클러스터와 주제를 만들려면 [AWS Management Console을 사용하여 계층형 스토리지로 클러스터 생성](https://docs.aws.amazon.com//msk/latest/developerguide/msk-create-cluster-tiered-storage-console)을 참조하세요.
## 기존 Amazon MSK 주제에서 계층형 스토리지 활성화
기존 주제에서 계층형 스토리지를 사용 설정하려면 다음 예제의 `alter` 명령 구문을 사용합니다. 이미 존재하는 주제에서 계층형 스토리지를 활성화하는 경우 특정 Apache Kafka 클라이언트 버전으로 제한되지 않습니다.
```
bin/kafka-configs.sh --bootstrap-server $bsrv --alter --entity-type topics --entity-name msk-ts-topic --add-config 'remote.storage.enable=true, local.retention.ms=604800000, retention.ms=15550000000'
```
## 기존 Amazon MSK 주제에서 계층형 스토리지 비활성화
기존 주제에서 계층형 스토리지를 비활성화하려면 계층형 스토리지를 사용 설정할 때와 동일한 순서로 `alter` 명령 구문을 사용합니다.
```
bin/kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name MSKTutorialTopic --add-config 'remote.log.msk.disable.policy=Delete, remote.storage.enable=false'
```
**참고**
계층형 스토리지를 비활성화하면 계층형 스토리지에서 주제 데이터가 완전히 삭제됩니다. Apache Kafka는 기본 스토리지 데이터를 보존하지만 여전히 `local.retention.ms`를 기반으로 하는 기본 보존 규칙을 적용합니다. 주제에서 계층형 스토리지를 비활성화한 후에는 다시 활성화할 수 없습니다. 기존 토픽에서 계층형 스토리지를 비활성화하려는 경우 특정 Apache Kafka 클라이언트 버전으로 제한되지 않습니다.
# AWS CLI를 사용하여 기존 Amazon MSK 클러스터에서 계층형 스토리지 활성화
**참고**
계층형 스토리지에서는 압축된 주제가 지원되지 않으므로 클러스터의 log.cleanup.policy가 `delete`로 설정된 경우에만 계층형 스토리지를 활성화할 수 있습니다. 나중에 특정 주제에서 계층형 스토리지가 활성화되어 있지 않은 경우 개별 주제의 log.cleanup.policy를 `compact`로 구성할 수 있습니다. 지원되는 구성 속성에 대한 자세한 내용은 [주제 수준 구성](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration)을 참조하세요.
1. **Kafka 버전 업데이트** – 클러스터 버전은 단순한 정수가 아닙니다. 클러스터의 현재 버전을 찾으려면 `DescribeCluster` 작업 또는 `describe-cluster` AWS CLI 명령을 사용합니다. 버전의 예를 들면 `KTVPDKIKX0DER`입니다.
```
aws kafka update-cluster-kafka-version --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-kafka-version 3.6.0
```
1. 클러스터 스토리지 모드를 편집합니다. 다음 코드 예제는 [https://docs.aws.amazon.com/cli/latest/reference/kafka/update-storage.html](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-storage.html) API를 사용하여 클러스터 스토리지 모드를 `TIERED`로 편집하는 방법을 보여줍니다.
```
aws kafka update-storage --current-version Current-Cluster-Version --cluster-arn Cluster-arn --storage-mode TIERED
```
# 콘솔을 사용하여 기존 Amazon MSK 클러스터에서 계층형 스토리지 업데이트
이 프로세스는 AWS Management Console을 사용하여 계층형 스토리지 Amazon MSK 클러스터를 업데이트하는 방법을 설명합니다.
MSK 클러스터의 현재 Apache Kafka 버전이 2.8.2.tiered인지 확인합니다. MSK 클러스터를 2.8.2.tiered 버전으로 업그레이드해야 하는 경우 [Apache Kafka 버전 업데이트](https://docs.aws.amazon.com/msk/latest/developerguide/version-upgrades.html)를 참조하세요.
**참고**
계층형 스토리지에서는 압축된 주제가 지원되지 않으므로 클러스터의 log.cleanup.policy가 `delete`로 설정된 경우에만 계층형 스토리지를 활성화할 수 있습니다. 나중에 특정 주제에서 계층형 스토리지가 활성화되어 있지 않은 경우 개별 주제의 log.cleanup.policy를 `compact`로 구성할 수 있습니다. 지원되는 구성 속성에 대한 자세한 내용은 [주제 수준 구성](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration)을 참조하세요.
1. [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/)에서 Amazon MSK 콘솔을 엽니다.
1. 클러스터 요약 페이지로 이동하여 **속성**을 선택합니다.
1. **스토리지** 섹션으로 이동하여 **클러스터 스토리지 모드 편집**을 선택합니다.
1. **계층형 스토리지 및 EBS 스토리지**와 **변경 사항 저장**을 선택합니다.
# Amazon MSK Standard 브로커 스토리지 스케일 업
브로커당 EBS 스토리지의 양을 늘릴 수 있습니다. 스토리지를 줄일 수 없습니다.
스토리지 볼륨은 이 확장 작업 중에 계속 사용할 수 있습니다.
**중요**
MSK 클러스터를 위해 스토리지의 규모를 조정하면 추가 스토리지를 즉시 사용할 수 있습니다. 그러나 모든 스토리지 규모 조정 이벤트 후에 클러스터에는 휴지 기간이 필요합니다. Amazon MSK는 이 휴지 기간을 사용하여 클러스터를 다시 확장하기 전에 클러스터를 최적화합니다. 이 기간은 클러스터의 스토리지 크기, 사용률, 트래픽에 따라 최소 6시간에서 24시간 이상까지 다양합니다. 이는 Auto Scaling 이벤트와 [UpdateBrokerStorage](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes-storage.html#UpdateBrokerStorage) 작업을 사용하는 수동 규모 조정 모두에 적용됩니다. 적절한 스토리지 규모 조정에 대한 자세한 내용은 [Standard 브로커 모범 사례](bestpractices.md) 섹션을 참조하세요.
계층형 스토리지를 사용하여 브로커의 스토리지를 무제한으로 스케일 업할 수 있습니다. [Standard 브로커를 위한 계층형 스토리지](msk-tiered-storage.md) 섹션을 참조하세요.
**Topics**
+ [Amazon MSK 클러스터를 위한 자동 규모 조정](msk-autoexpand.md)
+ [Standard 브로커의 수동 규모 조정](manually-expand-storage.md)
# Amazon MSK 클러스터를 위한 자동 규모 조정
사용량 증가에 대응하여 클러스터의 스토리지를 자동으로 확장하려면 Amazon MSK에 대한 애플리케이션 Auto Scaling 정책을 구성할 수 있습니다. Auto Scaling 정책에서는 목표 디스크 사용률과 최대 규모 조정 용량을 설정합니다.
Amazon MSK의 자동 규모 조정 기능을 사용하기 전에 다음을 고려해야 합니다.
+
**중요**
스토리지 규모 조정 작업은 6시간에 한 번만 수행할 수 있습니다.
스토리지 요구 사항에 적합한 크기의 스토리지 용량으로 시작하는 것을 권장합니다. 적절한 클러스터 크기 조정에 대한 지침은 [클러스터 크기를 적절하게 조정: 클러스터당 Standard 브로커 수](bestpractices.md#brokers-per-cluster) 섹션을 참조하세요.
+ Amazon MSK는 사용량 감소에 대응하여 클러스터 스토리지를 줄이지 않습니다. Amazon MSK는 스토리지 볼륨 크기 줄이기를 지원하지 않습니다. 클러스터 스토리지의 크기를 줄여야 하는 경우 기존 클러스터를 더 작은 스토리지가 있는 클러스터로 마이그레이션해야 합니다. 클러스터 마이그레이션에 대한 자세한 내용은 [MSK 클러스터로 마이그레이션](migration.md) 섹션을 참조하세요.
+ Amazon MSK는 아시아 태평양(오사카), 아프리카(케이프타운), 아시아 태평양(말레이시아) 리전에서의 자동 규모 조정 기능을 지원하지 않습니다.
+ Auto Scaling 정책을 클러스터와 연결하면 Amazon EC2 Auto Scaling은 대상 추적을 위한 Amazon CloudWatch 경보를 자동으로 생성합니다. Auto Scaling 정책을 사용하여 클러스터를 삭제해도 이 CloudWatch 경보는 계속 유지됩니다. CloudWatch 경보를 삭제하려면 클러스터를 삭제하기 전에 클러스터에서 Auto Scaling 정책을 제거해야 합니다. 대상 추적에 대해 자세히 알아보려면 **Amazon EC2 Auto Scaling 사용 설명서에서 [Amazon EC2 Auto Scaling에 대한 대상 추적 규모 조정 정책](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html)을 참조하세요.
**Topics**
+ [Amazon MSK에 대한 오토 스케일링 정책 세부 정보](msk-autoexpand-details.md)
+ [Amazon MSK 클러스터를 위한 오토 스케일링 설정](msk-autoexpand-setup.md)
# Amazon MSK에 대한 오토 스케일링 정책 세부 정보
Auto Scaling 정책은 클러스터에 대한 다음 파라미터를 정의합니다.
+ **스토리지 사용률 목표**: Auto Scaling 작업을 트리거하는 데 사용하는 Amazon MSK의 스토리지 사용률 임계값입니다. 현재 스토리지 용량의 10%에서 80% 사이에서 사용률 목표를 설정할 수 있습니다. 스토리지 사용률 목표를 50%에서 60% 사이로 설정하는 것을 권장합니다.
+ **최대 스토리지 용량**: Amazon MSK가 브로커 스토리지에 대해 설정할 수 있는 최대 확장 한도입니다. 브로커당 최대 스토리지 용량을 최대 16TiB까지 설정할 수 있습니다. 자세한 내용은 [Amazon MSK 할당량](limits.md) 단원을 참조하십시오.
Amazon MSK는 `Maximum Disk Utilization` 지표가 `Storage Utilization Target` 설정보다 크거나 같다는 것을 감지하면 두 숫자, 즉 10GiB 또는 현재 스토리지의 10% 중 더 큰 양만큼 스토리지 용량을 늘립니다. 예를 들어 1000GiB가 있는 경우 해당 용량은 100GiB입니다. 이 서비스는 1분마다 스토리지 사용률을 확인합니다. 추가 규모 조정 작업은 두 숫자((10GiB 또는 현재 스토리지의 10%) 중 더 큰 값만큼 스토리지를 계속 늘립니다.
Auto Scaling 작업이 발생했는지 확인하려면 [ListClusterOperations](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-operations.html#ListClusterOperations) 작업을 사용합니다.
# Amazon MSK 클러스터를 위한 오토 스케일링 설정
Amazon MSK 콘솔, Amazon MSK API 또는를 사용하여 스토리지에 대한 자동 조정을 구현 CloudFormation 할 수 있습니다. [Application Auto Scaling](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html)을 통해 CloudFormation 지원을 이용할 수 있습니다.
**참고**
클러스터를 만들 때는 Auto Scaling을 구현할 수 없습니다. 먼저 클러스터를 생성한 다음 해당 클러스터에 대한 Auto Scaling 정책을 생성하고 활성화해야 합니다. 그러나 Amazon MSK 서비스가 클러스터를 생성하는 동안에도 정책을 생성할 수 있습니다.
**Topics**
+ [Amazon MSK를 사용하여 자동 조정 설정 AWS Management Console](msk-autoexpand-setup-console.md)
+ [CLI를 사용하여 자동 규모 조정 설정](msk-autoexpand-setup-cli.md)
+ [API를 사용하여 Amazon MSK에 대한 오토 스케일링 설정](msk-autoexpand-setup-api.md)
# Amazon MSK를 사용하여 자동 조정 설정 AWS Management Console
이 프로세스는 Amazon MSK 콘솔을 사용하여 스토리지에 대한 오토 스케일링을 구현하는 방법을 설명합니다.
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) Amazon MSK 콘솔을 엽니다.
1. 클러스터 목록에서 클러스터를 선택합니다. 클러스터에 대한 세부 정보가 나열된 페이지로 이동합니다.
1. **스토리지용 Auto Scaling** 섹션에서 **구성**을 선택합니다.
1. Auto Scaling 정책을 생성하고 이름을 지정합니다. 스토리지 사용률 목표, 최대 스토리지 용량, 목표 지표를 지정합니다.
1. `Save changes`을 선택합니다.
새 정책을 저장하고 활성화하면 클러스터에 대해 정책이 활성화됩니다. 그런 다음 스토리지 사용률 목표에 도달하면 Amazon MSK가 클러스터의 스토리지를 확장합니다.
# CLI를 사용하여 자동 규모 조정 설정
이 프로세스는 Amazon MSK CLI를 사용하여 스토리지에 대한 오토 스케일링을 구현하는 방법을 설명합니다.
1. [RegisterScalableTarget](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/#available-commands) 명령을 사용하여 스토리지 사용률 목표를 등록합니다.
1. [PutScalingPolicy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/#available-commands) 명령을 사용하여 자동 확장 정책을 생성합니다.
# API를 사용하여 Amazon MSK에 대한 오토 스케일링 설정
이 프로세스는 Amazon MSK API를 사용하여 스토리지에 대한 오토 스케일링을 구현하는 방법을 설명합니다.
1. [RegisterScalableTarget](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_RegisterScalableTarget.html) API를 사용하여 스토리지 사용률 목표를 등록합니다.
1. [PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html) API를 사용하여 자동 확장 정책을 생성합니다.
# Standard 브로커의 수동 규모 조정
스토리지를 늘리려면 클러스터가 `ACTIVE` 상태가 될 때까지 기다립니다. 스토리지 규모 조정에는 이벤트 사이에 최소 6시간의 휴지 기간이 있습니다. 이 작업을 통해 추가 스토리지를 즉시 사용할 수 있지만 서비스는 클러스터에서 최대 24시간 이상 소요될 수 있는 최적화를 수행합니다. 최적화 기간은 스토리지 크기에 비례합니다.
## 를 사용하여 브로커 스토리지 확장 AWS Management Console
1. [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/)에서 Amazon MSK 콘솔을 엽니다.
1. 브로커 스토리지를 업데이트할 MSK 클러스터를 선택합니다.
1. **스토리지** 섹션에서 **편집**을 선택합니다.
1. 원하는 스토리지 볼륨을 지정합니다. 스토리지 용량을 늘릴 수는 있지만 줄일 수는 없습니다.
1. **변경 사항 저장**을 선택합니다.
## 를 사용하여 브로커 스토리지 확장 AWS CLI
다음 명령을 실행하여 *ClusterArn*을 클러스터 생성 후 받은 Amazon 리소스 이름(ARN)으로 바꿉니다. 클러스터에 대한 ARN이 없는 경우, 모든 클러스터를 나열하여 찾을 수 있습니다. 자세한 내용은 [Amazon MSK 클러스터 나열](msk-list-clusters.md) 단원을 참조하십시오.
*Current-Cluster-Version*을 클러스터의 현재 버전으로 바꿉니다.
**중요**
클러스터 버전은 단순한 정수가 아닙니다. 클러스터의 현재 버전을 찾으려면 [DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster) 작업 또는 [describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html) AWS CLI 명령을 사용합니다. 버전의 예를 들면 `KTVPDKIKX0DER`입니다.
*Target-Volume-in-GiB* 파라미터는 각 브로커가 보유할 스토리지의 양을 나타냅니다. 모든 브로커의 스토리지만 업데이트할 수 있습니다. 스토리지를 업데이트할 개별 브로커를 지정할 수 없습니다. *Target-Volume-in-GiB*에 지정하는 값은 100GiB보다 큰 정수여야 합니다. 업데이트 작업 후 브로커당 스토리지는 16384GiB를 초과할 수 없습니다.
```
aws kafka update-broker-storage --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-broker-ebs-volume-info '{"KafkaBrokerNodeId": "All", "VolumeSizeGB": Target-Volume-in-GiB}'
```
## API를 사용하여 브로커 스토리지 스케일 업
API를 사용하여 브로커 스토리지를 업데이트하려면 [UpdateBrokerStorage](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-nodes-storage.html#UpdateBrokerStorage)를 참조하십시오.
# Amazon MSK 클러스터의 Standard 브로커에 대한 스토리지 처리량 관리
Amazon MSK 콘솔, CLI 및 API를 사용하여 처리량을 프로비저닝하는 방법에 대한 자세한 내용은 [Amazon MSK 클러스터의 Standard 브로커에 대한 스토리지 처리량 프로비저닝](msk-provision-throughput.md) 섹션을 참조하세요.
**Topics**
+ [Amazon MSK 브로커 처리량 병목 현상 및 최대 처리량 설정](#throughput-bottlenecks)
+ [Amazon MSK 클러스터의 스토리지 처리량 측정](#throughput-metrics)
+ [Amazon MSK 클러스터의 프로비저닝된 스토리지에 대한 구성 업데이트 값](#provisioned-throughput-config)
+ [Amazon MSK 클러스터의 Standard 브로커에 대한 스토리지 처리량 프로비저닝](msk-provision-throughput.md)
## Amazon MSK 브로커 처리량 병목 현상 및 최대 처리량 설정
브로커 처리량의 병목 현상의 원인으로는 볼륨 처리량, Amazon EC2에서 Amazon EBS로의 네트워크 처리량, Amazon EC2 송신 처리량 등이 있습니다. 프로비저닝된 스토리지 처리량을 활성화하여 볼륨 처리량을 조정할 수 있습니다. 그러나 Amazon EC2에서 Amazon EBS로의 네트워크 처리량과 Amazon EC2 송신 처리량으로 인해 브로커 처리량 제한이 발생할 수 있습니다.
Amazon EC2 송신 처리량은 소비자 그룹 및 소비자 그룹당 소비자 수에 영향을 받습니다. 또한 Amazon EC2에서 Amazon EBS로의 네트워크 처리량과 Amazon EC2 송신 처리량 모두 더 규모가 큰 브로커 크기에서 더 높습니다.
볼륨 크기가 10GiB 이상인 경우에는 초당 250MiB 이상의 스토리지 처리량을 프로비저닝할 수 있습니다. 기본값은 초당 250MiB입니다. 스토리지 처리량을 프로비저닝하려면 kafka.m5.4xlarge 이상(또는 kafka.m7g.2xlarge 이상)의 브로커 크기를 선택해야 하며 다음 표와 같이 최대 처리량을 지정할 수 있습니다.
****
| 브로커 크기 | 최대 스토리지 처리량(MiB/초) |
| --- | --- |
| kafka.m5.4xlarge | 593 |
| kafka.m5.8xlarge | 850 |
| kafka.m5.12xlarge | 1000 |
| kafka.m5.16xlarge | 1000 |
| kafka.m5.24xlarge | 1000 |
| kafka.m7g.2xlarge | 312.5 |
| kafka.m7g.4xlarge | 625 |
| kafka.m7g.8xlarge | 1000 |
| kafka.m7g.12xlarge | 1000 |
| kafka.m7g.16xlarge | 1000 |
## Amazon MSK 클러스터의 스토리지 처리량 측정
`VolumeReadBytes` 및 `VolumeWriteBytes` 지표를 사용하여 클러스터의 평균 스토리지 처리량을 측정할 수 있습니다. 이 두 지표의 합계는 평균 스토리지 처리량(바이트)을 나타냅니다. 클러스터의 평균 스토리지 처리량을 얻으려면 이 두 지표를 합계로 설정하고 기간을 1분으로 설정한 후 다음 공식을 사용합니다.
```
Average storage throughput in MiB/s = (Sum(VolumeReadBytes) + Sum(VolumeWriteBytes)) / (60 * 1024 * 1024)
```
`VolumeReadBytes` 및 `VolumeWriteBytes` 지표에 대한 자세한 내용은 [`PER_BROKER` 수준 모니터링](metrics-details.md#broker-metrics) 섹션을 참조하세요.
## Amazon MSK 클러스터의 프로비저닝된 스토리지에 대한 구성 업데이트 값
프로비저닝된 처리량을 활성화하기 전이나 활성화한 후에 Amazon MSK 구성을 업데이트할 수 있습니다. 그러나 `num.replica.fetchers` 구성 파라미터를 업데이트하고 프로비저닝된 처리량을 활성화하는 두 가지 작업을 모두 수행할 때까지는 원하는 처리량을 볼 수 없습니다.
기본 Amazon MSK 구성에서 `num.replica.fetchers` 값은 2입니다. `num.replica.fetchers`를 업데이트하기 위해 다음 표의 제안된 값을 사용할 수 있습니다. 이 값은 지침을 위한 것입니다. 사용 사례에 따라 이 값을 조정하는 것을 권장합니다.
****
| 브로커 크기 | num.replica.fetchers |
| --- | --- |
| kafka.m5.4xlarge | 4 |
| kafka.m5.8xlarge | 8 |
| kafka.m5.12xlarge | 14 |
| kafka.m5.16xlarge | 16 |
| kafka.m5.24xlarge | 16 |
업데이트된 구성은 최대 24시간 동안 적용되지 않을 수 있으며 소스 볼륨이 완전히 사용되지 않을 경우 더 오래 걸릴 수 있습니다. 그러나 마이그레이션 기간 동안 마이그레이션 볼륨 성능은 최소한 소스 스토리지 볼륨의 성능과 동일합니다. 완전히 활용되는 1TiB 볼륨을 업데이트된 구성으로 마이그레이션하는 데는 일반적으로 약 6시간이 소요됩니다.
# Amazon MSK 클러스터의 Standard 브로커에 대한 스토리지 처리량 프로비저닝
Amazon MSK 브로커는 스토리지 볼륨에 데이터를 유지합니다. 스토리지 I/O는 생산자가 클러스터에 쓸 때, 브로커 간에 데이터가 복제될 때와 소비자가 메모리에 없는 데이터를 읽을 때 소비됩니다. 볼륨 스토리지 처리량은 스토리지 볼륨에 데이터를 쓰고 읽을 수 있는 속도입니다. 프로비저닝된 스토리지 처리량은 클러스터의 브로커에 대해 해당 속도를 지정할 수 있는 기능입니다.
브로커 크기가 `kafka.m5.4xlarge` 이상이고 스토리지 볼륨이 10GiB 이상인 클러스터의 경우 프로비저닝된 처리 속도를 초당 MiB 단위로 지정할 수 있습니다. 클러스터를 생성하는 중에 프로비저닝된 처리량을 지정할 수 있습니다. 또한 `ACTIVE` 상태인 클러스터에 대해 프로비저닝된 처리량을 활성화하거나 비활성화할 수 있습니다.
처리량 관리에 대한 자세한 내용은 [Amazon MSK 클러스터의 Standard 브로커에 대한 스토리지 처리량 관리](msk-provision-throughput-management.md) 섹션을 참조하세요.
**Topics**
+ [를 사용하여 Amazon MSK 클러스터 스토리지 처리량 프로비저닝 AWS Management Console](#provisioned-throughput-console)
+ [를 사용하여 Amazon MSK 클러스터 스토리지 처리량 프로비저닝 AWS CLI](#provisioned-throughput-cli)
+ [API를 사용하여 Amazon MSK 클러스터를 생성할 때 프로비저닝 스토리지 처리량](#provisioned-throughput-api)
## 를 사용하여 Amazon MSK 클러스터 스토리지 처리량 프로비저닝 AWS Management Console
이 프로세스는 AWS Management Console 를 사용하여 프로비저닝된 처리량이 활성화된 Amazon MSK 클러스터를 생성하는 방법의 예를 보여줍니다.
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) Amazon MSK 콘솔을 엽니다.
1. **클러스터 생성**을 선택합니다.
1. **사용자 지정 생성**을 선택합니다.
1. 클러스터의 이름을 지정합니다.
1. **스토리지** 섹션에서 **활성화**를 선택합니다.
1. 브로커당 스토리지 처리량에 대한 값을 선택합니다.
1. VPC, 영역 및 서브넷, 보안 그룹을 선택합니다.
1. **다음**을 선택합니다.
1. **보안** 단계 아래에서 **다음**을 선택합니다.
1. **모니터링 및 태그** 단계 아래에서 **다음**을 선택합니다.
1. 클러스터 설정을 검토한 다음 **클러스터 생성**을 선택합니다.
## 를 사용하여 Amazon MSK 클러스터 스토리지 처리량 프로비저닝 AWS CLI
이 프로세스는 AWS CLI 를 사용하여 프로비저닝된 처리량이 활성화된 클러스터를 생성하는 방법의 예를 보여줍니다.
1. 다음 JSON을 복사하여 파일에 붙여넣습니다. 서브넷 ID 및 보안 그룹 ID 자리 표시자를 계정의 값으로 변경합니다. 파일 이름을 `cluster-creation.json`으로 지정하고 저장합니다.
```
{
"Provisioned": {
"BrokerNodeGroupInfo":{
"InstanceType":"kafka.m5.4xlarge",
"ClientSubnets":[
"Subnet-1-ID",
"Subnet-2-ID"
],
"SecurityGroups":[
"Security-Group-ID"
],
"StorageInfo": {
"EbsStorageInfo": {
"VolumeSize": 10,
"ProvisionedThroughput": {
"Enabled": true,
"VolumeThroughput": 250
}
}
}
},
"EncryptionInfo": {
"EncryptionInTransit": {
"InCluster": false,
"ClientBroker": "PLAINTEXT"
}
},
"KafkaVersion":"2.8.1",
"NumberOfBrokerNodes": 2
},
"ClusterName": "provisioned-throughput-example"
}
```
1. 이전 단계에서 JSON 파일을 저장한 디렉터리에서 다음 AWS CLI 명령을 실행합니다.
```
aws kafka create-cluster-v2 --cli-input-json file://cluster-creation.json
```
## API를 사용하여 Amazon MSK 클러스터를 생성할 때 프로비저닝 스토리지 처리량
클러스터를 생성하는 동안 프로비저닝된 스토리지 처리량을 구성하려면 [CreateClusterV2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2)를 사용합니다.
# Amazon MSK Provisioned 구성
Amazon MSK는 브로커, 주제 및 메타데이터 노드에 대한 기본 구성을 제공합니다. 또한 사용자 지정 구성을 생성하고, 이를 사용해 새 MSK 클러스터를 생성하거나 기존 클러스터를 업데이트할 수 있습니다. MSK 구성은 속성 집합과 각각에 해당하는 값으로 구성됩니다. 클러스터에서 사용하는 브로커 유형에 따라 구성 기본값 세트와 수정할 수 있는 구성 세트가 다릅니다. Standard 및 Express 브로커를 구성하는 방법에 대한 자세한 내용은 아래 섹션을 참조하세요.
**Topics**
+ [Standard 브로커 구성](msk-configuration-standard.md)
+ [Express 브로커 구성](msk-configuration-express.md)
+ [브로커 구성 작업](msk-configuration-operations.md)
# Standard 브로커 구성
이 섹션에서는 Standard 브로커의 구성 속성을 설명합니다.
**Topics**
+ [사용자 지정 Amazon MSK 구성](msk-configuration-properties.md)
+ [기본 Amazon MSK 구성](msk-default-configuration.md)
+ [Amazon MSK 계층형 스토리지 주제 수준의 구성에 대한 지침](msk-guidelines-tiered-storage-topic-level-config.md)
# 사용자 지정 Amazon MSK 구성
Amazon MSK를 사용하여 다음 Apache Kafka 구성 속성을 설정하는 사용자 지정 MSK 구성을 생성할 수 있습니다. 명시적으로 설정하지 않은 속성은 [기본 Amazon MSK 구성](msk-default-configuration.md)에 있는 값을 가져옵니다. 구성 속성에 대한 자세한 내용은 [Apache Kafka 구성](https://kafka.apache.org/documentation/#configuration)을 참조하십시오.
| 이름 | 설명 |
| --- | --- |
| allow.everyone.if.no.acl.found | 이 속성을 false로 설정하려면 먼저 클러스터에 대한 Apache Kafka ACL을 정의해야 합니다. 이 속성을 false로 설정하고 Apache Kafka ACL을 먼저 정의하지 않으면 클러스터에 대한 액세스 권한을 잃게 됩니다. 이 경우 구성을 다시 업데이트하고 이 속성을 true로 설정하여 클러스터에 다시 액세스할 수 있습니다. |
| auto.create.topics.enable | 서버의 주제 자동 생성을 활성화합니다. |
| compression.type | 주어진 주제에 대한 최종 압축 유형입니다. 이 속성을 표준 압축 코덱(gzip, snappy, lz4 및 zstd)으로 설정할 수 있습니다. 추가로 uncompressed를 허용합니다. 이 값은 압축을 하지 않은 것과 같습니다. 값을 producer로 설정하면 생산자가 설정한 원본 압축 코덱을 유지한다는 의미입니다. |
| connections.max.idle.ms | 유휴 연결 제한 시간(밀리초). 서버 소켓 프로세서 스레드는 이 속성에 설정한 값보다 더 오래 유휴 상태인 연결을 닫습니다. |
| default.replication.factor | 자동으로 생성된 주제에 대한 기본 복제 인수입니다. |
| delete.topic.enable | 주제 삭제 작업을 활성화합니다. 이 설정을 끄면 관리자 도구를 통해 주제를 삭제할 수 없습니다. |
| group.initial.rebalance.delay.ms | 그룹 코디네이터가 첫 번째 재조정을 수행하기 전에 더 많은 데이터 소비자가 새 그룹에 가입할 때까지 기다리는 시간입니다. 지연 시간이 길어지면 재조정 횟수는 줄어들 수 있지만 처리가 시작될 때까지 시간이 늘어납니다. |
| group.max.session.timeout.ms | 등록된 소비자에 대한 최대 세션 제한 시간입니다. 제한 시간이 길어지면 소비자가 하트비트 사이에 메시지를 처리할 수 있는 시간이 더 길어지지만 장애를 감지하는 데 시간이 더 오래 걸립니다. |
| group.min.session.timeout.ms | 등록된 소비자에 대한 최소 세션 제한 시간입니다. 제한 시간이 짧아지면 소비자의 하트비트가 더 자주 발생하는 대신 장애를 더 빨리 감지할 수 있습니다. 이는 브로커 리소스에 과부하를 줄 수 있습니다. |
| leader.imbalance.per.broker.percentage | 브로커당 허용되는 리더 불균형의 비율입니다. 컨트롤러는 브로커당 이 값을 초과하는 경우 리더 밸런스를 트리거합니다. 이 값은 백분율로 지정됩니다. |
| log.cleaner.delete.retention.ms | Apache Kafka가 삭제된 레코드를 유지하는 시간 길이. 최소값은 0입니다. |
| log.cleaner.min.cleanable.ratio | 이 구성 속성의 값은 0에서 1 사이일 수 있습니다. 이 값은 로그 압축기가 로그 정리를 시도하는 빈도를 결정합니다(로그 압축이 활성화된 경우). 기본적으로 Apache Kafka는 로그의 50% 이상이 압축된 경우 로그 정리를 하지 않습니다. 이 비율은 로그가 중복으로 인해 낭비하는 최대 공간을 제한합니다(50%의 경우 로그의 최대 50%가 중복일 수 있음을 의미). 비율이 높을수록 정리 횟수가 더 적고 효율적이지만 로그에서 낭비되는 공간은 더 많아집니다. |
| log.cleanup.policy | 보존 기간이 지난 세그먼트에 대한 기본 정리 정책입니다. 유효한 정책의 쉼표로 구분된 목록입니다. 유효한 정책은 delete 및 compact입니다. 계층형 스토리지를 사용하는 클러스터의 경우 유효한 정책은 delete뿐입니다. |
| log.flush.interval.messages | 메시지가 디스크로 플러시되기 전에 로그 파티션에 누적되는 메시지의 수입니다. |
| log.flush.interval.ms | 주제의 메시지가 디스크에 플러시되기 전까지 메모리에 남아 있는 최대 시간(밀리초)입니다. 이 값을 설정하지 않으면 log.flush.scheduler.interval.ms의 값이 사용됩니다. 최소값은 0입니다. |
| log.message.timestamp.difference.max.ms | 이 구성은 Kafka 3.6.0에서 더 이상 사용되지 않습니다. log.message.timestamp.before.max.ms 및 log.message.timestamp.after.max.ms라는 두 가지 구성이 추가되었습니다. 브로커가 메시지를 수신할 때의 타임스탬프와 메시지에 지정된 타임스탬프 사이의 최대 시간 차이입니다. log.message.timestamp.type=CreateTime인 경우 타임스탬프의 차이가 이 임계값을 초과하면 메시지가 거부됩니다. 이 구성은 log.message.timestamp.type=LogAppendTime인 경우 무시됩니다. |
| log.message.timestamp.type | 메시지의 타임스탬프가 메시지 생성 시간인지 로그 추가 시간인지 지정합니다. 허용 값은 CreateTime, LogAppendTime입니다. |
| log.retention.bytes | 삭제하기 전 로그의 최대 크기입니다. |
| log.retention.hours | 로그 파일을 삭제하기 전에 보관하는 시간(3차 log.retention.ms 속성)입니다. |
| log.retention.minutes | 로그 파일을 삭제하기 전에 보관하는 시간(분)(2차 log.retention.ms 속성)입니다. 이 값을 설정하지 않으면 log.retention.hours의 값이 사용됩니다. |
| log.retention.ms | 로그 파일을 삭제하기 전에 보관하는 시간(밀리초)입니다. 설정하지 않으면 log.retention.minutes 값이 사용됩니다. |
| log.roll.ms | 새 로그 세그먼트가 롤아웃되기 전 최대 시간(밀리초)입니다. 이 속성을 설정하지 않으면 log.roll.hours의 값이 사용됩니다. 이 속성의 가능한 최소값은 1입니다. |
| log.segment.bytes | 단일 로그 파일의 최대 크기입니다. |
| max.incremental.fetch.session.cache.slots | 유지되는 최대 증분 가져오기 세션 수입니다. |
| message.max.bytes | Kafka가 허용하는 최대 레코드 배치 크기입니다. 이 값을 늘리고 0.10.2보다 오래된 소비자가 있는 경우 이 정도 크기의 레코드 배치를 가져올 수 있도록 소비자의 가져오기 크기도 늘려야 합니다. 최신 메시지 형식 버전은 효율성을 위해 항상 메시지를 배치로 그룹화합니다. 이전 메시지 형식 버전에서는 압축되지 않은 레코드를 배치로 그룹화하지 않으며 이러한 경우 이 제한은 단일 레코드에만 적용됩니다. 이 값은 주제 수준 max.message.bytes 구성으로 주제별로 설정할 수 있습니다. |
| min.insync.replicas | 생산자가 ack를 `"all"`(또는 `"-1"`)로 설정하면 min.insync.replicas의 값은 쓰기가 성공한 것으로 간주되기 위해 쓰기를 승인해야 하는 최소 복제본 수를 지정합니다. 이 최소값이 충족되지 않으면 생산자가 예외를 발생시킵니다(NotEnoughReplicas 또는 NotEnoughReplicasAfterAppend). min.insync.replicas 및 acks의 값을 사용하여 내구성 보장을 강화할 수 있습니다. 예를 들어 복제 인수가 3인 주제를 생성하고, min.insync.replicas를 2로 설정하고, `"all"`의 acks를 사용하여 생산할 수 있습니다. 이렇게 하면 대부분의 복제본이 쓰기를 수신하지 못하는 경우 생산자가 예외를 발생시킵니다. |
| num.io.threads | 서버가 요청을 처리하는 데 사용하는 스레드 수로서, 디스크 I/O를 포함할 수 있습니다. |
| num.network.threads | 서버가 네트워크에서 요청을 수신하고 응답을 전송하는 데 사용하는 스레드 수입니다. |
| num.partitions | 주제별 기본 로그 파티션 수입니다. |
| num.recovery.threads.per.data.dir | 시작 시 로그를 복구하고 종료 시 로그를 플러시하는 데 사용할 데이터 디렉터리당 스레드 수입니다. |
| num.replica.fetchers | 소스 브로커의 메시지를 복제하는 데 사용하는 가져오기 스레드 수입니다. 이 값을 늘리면 팔로어 브로커의 I/O 병렬 처리 정도를 늘릴 수 있습니다. |
| offsets.retention.minutes | 소비자 그룹이 모든 소비자를 잃은 후(즉, 비어 있음) 해당 오프셋은 폐기되기 전까지 이 보존 기간 동안 유지됩니다. 독립 실행형 소비자(즉, 수동 할당을 사용하는 소비자)의 경우 오프셋은 마지막 커밋 시간에 이 보존 기간을 더한 후 만료됩니다. |
| offsets.topic.replication.factor | 오프셋 주제에 대한 복제 인수입니다. 가용성을 보장하려면 이 값을 높게 설정합니다. 클러스터 크기가 이 복제 인수 요구 사항을 충족할 때까지 내부 주제 생성에 실패합니다. |
| replica.fetch.max.bytes | 각 파티션에 대해서 가져오려고 하는 메시지 바이트 수입니다. 이 값은 절대적인 최대값이 아닙니다. 가져오기의 첫 번째 비어 있지 않은 파티션에 있는 첫 번째 레코드 배치가 이 값보다 크면 진행을 보장하기 위해 레코드 배치가 반환됩니다. message.max.bytes(브로커 구성) 또는 max.message.bytes(주제 구성)는 브로커가 허용하는 최대 레코드 배치 크기를 정의합니다. |
| replica.fetch.response.max.bytes | 전체 가져오기 응답에 대해 예상되는 최대 바이트 수입니다. 레코드는 배치로 가져오며 가져오기의 첫 번째 비어 있지 않은 파티션의 첫 번째 레코드 배치가 이 값보다 크면 진행을 보장하기 위해 배치가 반환됩니다. 이 값은 절대적인 최대값이 아닙니다. message.max.bytes(브로커 구성) 또는 max.message.bytes(주제 구성) 속성은 브로커가 허용하는 최대 레코드 배치 크기를 지정합니다. |
| replica.lag.time.max.ms | 팔로워가 가져오기 요청을 보내지 않았거나 적어도 이 시간(밀리초) 동안 리더의 로그 끝 오프셋까지 소모하지 않은 경우 리더는 ISR에서 팔로어를 제거합니다.최소값: 10000MaxValue = 30000 |
| replica.selector.class | ReplicaSelector를 구현하는 정규화된 클래스 이름입니다. 브로커는 이 값을 사용하여 선호하는 읽기 복제본을 찾습니다. Apache Kafka 버전 2.4.1 이상을 사용하며 소비자가 가장 가까운 복제본에서 가져오도록 허용하려면 이 속성을 org.apache.kafka.common.replica.RackAwareReplicaSelector로 설정하세요. 자세한 내용은 [Apache Kafka 버전 2.4.1(대신 2.4.1.1 사용)](supported-kafka-versions.md#2.4.1) 단원을 참조하십시오. |
| replica.socket.receive.buffer.bytes | 네트워크 요청에 대한 소켓 수신 버퍼입니다. |
| socket.receive.buffer.bytes | 소켓 서버 소켓의 SO\$1RCVBUF 버퍼입니다. 이 속성에 설정할 수 있는 최소값은 -1입니다. 값이 -1이면 Amazon MSK는 OS 기본값을 사용합니다. |
| socket.request.max.bytes | 소켓 요청의 최대 바이트 수입니다. |
| socket.send.buffer.bytes | 소켓 서버 소켓의 SO\$1SNDBUF 버퍼입니다. 이 속성에 설정할 수 있는 최소값은 -1입니다. 값이 -1이면 Amazon MSK는 OS 기본값을 사용합니다. |
| transaction.max.timeout.ms | 트랜잭션의 최대 제한 시간입니다. 클라이언트가 요청한 트랜잭션 시간이 이 값을 초과하면 브로커는 InitProducerIdRequest에 오류를 반환합니다. 이렇게 하면 클라이언트가 너무 긴 시간 제한을 방지합니다. 이로 인해 트랜잭션에 포함된 항목을 읽는 소비자가 중단될 수 있습니다. |
| transaction.state.log.min.isr | 트랜잭션 주제에 대한 min.insync.replicas 구성을 재정의했습니다. |
| transaction.state.log.replication.factor | 트랜잭션 주제에 대한 복제 인수입니다. 가용성을 높이려면 이 속성을 더 높은 값으로 설정합니다. 클러스터 크기가 이 복제 인수 요구 사항을 충족할 때까지 내부 주제 생성에 실패합니다. |
| transactional.id.expiration.ms | 트랜잭션 코디네이터가 트랜잭션 ID를 만료하기 전에 현재 트랜잭션에 대한 트랜잭션 상태 업데이트를 수신하기 위해 기다리는 시간(밀리초). 이 설정은 지정된 생산자 ID로 마지막으로 쓴 후 이 시간이 경과하면 생산자 ID가 만료되므로 생산자 ID 만료에도 영향을 줍니다. 주제에 대한 보존 설정으로 인해 생산자 ID의 마지막 쓰기가 삭제되면 생산자 ID가 더 빨리 만료될 수 있습니다. 이 속성의 최소값은 1밀리초입니다. |
| unclean.leader.election.enable | 데이터 손실이 발생할 수 있지만 ISR 세트에 없는 복제본을 최후의 수단으로 리더 역할을 해야 하는지 여부를 나타냅니다. |
| zookeeper.connection.timeout.ms | ZooKeeper 모드 클러스터. 클라이언트가 ZooKeeper에 대한 연결을 설정하기 위해 대기하는 최대 시간입니다. 이 값을 설정하지 않으면 zookeeper.session.timeout.ms의 값이 사용됩니다. 최소값 = 6000 최대값(포함) = 18000 클러스터 가동 중지 시간을 방지하려면 T3.small에서 이 값을 10,000으로 설정하는 것이 좋습니다. |
| zookeeper.session.timeout.ms | ZooKeeper 모드 클러스터. 밀리초 단위의 Apache ZooKeeper 세션 제한 시간입니다. 최소값 = 6000 최대값(포함) = 18000 |
사용자 지정 MSK 구성을 만들거나, 모든 구성을 나열하거나, 설명하는 방법을 알아보려면 [브로커 구성 작업](msk-configuration-operations.md) 단원을 참조하십시오. 사용자 지정 MSK 구성으로 MSK 클러스터를 만들거나 새 사용자 지정 구성으로 클러스터를 업데이트하려면 [Amazon MSK 주요 기능 및 개념](operations.md) 섹션을 참조하세요.
기존 MSK 클러스터를 사용자 지정 MSK 구성으로 업데이트할 때 Amazon MSK는 필요한 경우 롤링을 다시 시작하고 모범 사례를 사용하여 고객 가동 중지를 최소화합니다. 예를 들어 Amazon MSK는 각 브로커를 다시 시작한 후 다음 브로커로 이동하기 전에 브로커가 구성 업데이트 중에 놓쳤을 수 있는 데이터를 따라잡을 수 있도록 시도합니다.
## Amazon MSK 구성
Amazon MSK에서 제공하는 구성 속성 외에도 브로커를 다시 시작할 필요가 없는 클러스터 수준 및 브로커 수준 구성 속성을 동적으로 설정할 수 있습니다. 일부 구성 속성을 동적으로 설정할 수 있습니다. Apache Kafka 설명서의 [브로커 구성](https://kafka.apache.org/documentation/#brokerconfigs) 아래의 표에서 읽기 전용으로 표시되지 않은 속성입니다. 동적 구성과 예제 명령에 대한 자세한 내용은 Apache Kafka 설명서의 [브로커 구성 업데이트](https://kafka.apache.org/documentation/#dynamicbrokerconfigs)를 참조하세요.
**참고**
`advertised.listeners` 속성은 설정할 수 있지만 `listeners` 속성은 설정할 수 없습니다.
## 주제 수준 Amazon MSK 구성
Apache Kafka 명령을 사용하여 새 주제와 기존 주제에 대한 주제 수준 구성 속성을 설정하거나 수정할 수 있습니다. 주제 수준 구성 속성과 설정 방법 예제에 대한 자세한 내용은 Apache Kafka 설명서의 [주제 수준 구성](https://kafka.apache.org/documentation/#topicconfigs)을 참조하세요.
# 기본 Amazon MSK 구성
MSK 클러스터를 생성하고 사용자 지정 MSK 구성을 지정하지 않으면 Amazon MSK는 다음 표에 표시된 값으로 기본 구성을 생성하여 사용합니다. 이 표에 없는 속성의 경우 Amazon MSK는 사용 중인 Apache Kafka 버전과 관련된 기본값을 사용합니다. 이러한 기본값 목록은 [Apache Kafka 구성](https://kafka.apache.org/documentation/#configuration)을 참조하십시오.
| 이름 | 설명 | 비계층형 스토리지 클러스터의 기본값 | 계층형 스토리지 활성화 클러스터의 기본값 |
| --- | --- | --- | --- |
| allow.everyone.if.no.acl.found | 특정 리소스와 일치하는 리소스 패턴이 없으면 리소스에 연결된 ACL이 없는 것입니다. 이 경우 속성을 true로 설정하면 수퍼유저뿐만 아니라 모든 사용자가 리소스에 액세스할 수 있습니다. | true | true |
| auto.create.topics.enable | 서버에서 주제의 자동 생성을 활성화합니다. | false | false |
| auto.leader.rebalance.enable | 자동 리더 밸런싱을 활성화합니다. 필요한 경우 백그라운드 스레드는 정기적으로 리더 밸런스를 확인하고 시작합니다. | true | true |
| default.replication.factor | 자동으로 생성된 주제에 대한 기본 복제 인수입니다. | 가용 영역 3개에 있는 클러스터의 경우 3, 가용 영역 2개에 있는 클러스터의 경우 2입니다. | 가용 영역 3개에 있는 클러스터의 경우 3, 가용 영역 2개에 있는 클러스터의 경우 2입니다. |
| local.retention.bytes | 이전 세그먼트를 삭제하기 전 파티션에 대한 로컬 로그 세그먼트의 최대 크기입니다. 이 값을 설정하지 않으면 log.retention.bytes의 값이 사용됩니다. 유효 값은 항상 log.retention.bytes 값보다 작거나 같아야 합니다. 기본값인 -2는 로컬 보존에 제한이 없음을 나타냅니다. 이는 retention.ms/bytes 설정인 -1에 해당합니다. local.retention.ms 및 local.retention.bytes 속성은 로그 세그먼트가 로컬 스토리지에 얼마나 오래 남아 있어야 하는지 결정하는 데 사용되므로 log.retention과 유사합니다. 기존 log.retention.\$1 구성은 주제 파티션에 대한 보존 구성입니다. 여기에는 로컬 스토리지와 원격 스토리지가 모두 포함되어 있습니다. 유효한 값: [-2; \$1Inf]의 정수 | 무제한의 경우 -2 | 무제한의 경우 -2 |
| local.retention.ms | 삭제하기 전에 로컬 로그 세그먼트를 보존할 시간(밀리초)입니다. 이 값을 설정하지 않으면 Amazon MSK는 log.retention.ms의 값이 사용됩니다. 유효 값은 항상 log.retention.bytes 값보다 작거나 같아야 합니다. 기본값인 -2는 로컬 보존에 제한이 없음을 나타냅니다. 이는 retention.ms/bytes 설정인 -1에 해당합니다.local.retention.ms 및 local.retention.bytes 값은 log.retention과 유사합니다. MSK는 이 구성을 사용하여 로그 세그먼트가 로컬 스토리지에 얼마나 오래 남아 있어야 하는지 결정합니다. 기존 log.retention.\$1 구성은 주제 파티션에 대한 보존 구성입니다. 여기에는 로컬 스토리지와 원격 스토리지가 모두 포함되어 있습니다. 유효 값은 0보다 큰 정수입니다. | 무제한의 경우 -2 | 무제한의 경우 -2 |
| log.message.timestamp.difference.max.ms | 이 구성은 Kafka 3.6.0에서 더 이상 사용되지 않습니다. log.message.timestamp.before.max.ms 및 log.message.timestamp.after.max.ms라는 두 가지 구성이 추가되었습니다. 브로커가 메시지를 수신한 시점의 타임스탬프와 메시지에 지정된 타임스탬프 사이에 허용되는 최대 차이입니다. log.message.timestamp.type=CreateTime인 경우 타임스탬프의 차이가 이 임계값을 초과하면 메시지가 거부됩니다. 이 구성은 log.message.timestamp.type=LogAppendTime인 경우 무시됩니다. 허용되는 최대 타임스탬프 차이는 불필요하게 빈번한 로그 롤링을 방지하기 위해 log.retention.ms보다 크지 않아야 합니다. | 9223372036854775807 | 86400000(Kafka 2.8.2.tiered 및 Kafka 3.7.x tiered의 경우). |
| log.segment.bytes | 단일 로그 파일의 최대 크기입니다. | 1073741824 | 134217728 |
| min.insync.replicas | 생산자가 acks(생산자가 Kafka 브로커로부터 받는 승인) 값을 `"all"`(또는 `"-1"`)로 설정하는 경우 min.insync.replicas의 값은 쓰기가 성공한 것으로 간주되기 위해 쓰기를 승인해야 하는 최소 복제본 수를 지정합니다. 이 값이 이 최소값을 충족하지 못하면 생산자가 예외를 발생시킵니다(NotEnoughReplicas 또는 NotEnoughReplicasAfterAppend 중 하나). min.insync.replicas와 acks의 값을 함께 사용하면 내구성을 더욱 강력하게 보장할 수 있습니다. 예를 들어 복제 인수가 3인 주제를 생성하고, min.insync.replicas를 2로 설정하고, `"all"`의 acks를 사용하여 생산할 수 있습니다. 이렇게 하면 대부분의 복제본이 쓰기를 수신하지 못하는 경우 생산자가 예외를 발생시킵니다. | 가용 영역 3개에 있는 클러스터의 경우 2, 가용 영역 2개에 있는 클러스터의 경우 1입니다. | 가용 영역 3개에 있는 클러스터의 경우 2, 가용 영역 2개에 있는 클러스터의 경우 1입니다. |
| num.io.threads | 서버가 요청을 생성하는 데 사용하는 스레드 수로, 디스크 I/O가 포함될 수 있습니다. | 8 | max(8, vCPUs)이며 여기서 vCPU는 브로커의 인스턴스 크기에 따라 달라집니다. |
| num.network.threads | 서버가 네트워크에서 요청을 수신하고 네트워크에 응답을 전송하는 데 사용하는 스레드 수입니다. | 5 | max(5, vCPUs / 2)이며 여기서 vCPU는 브로커의 인스턴스 크기에 따라 달라집니다. |
| num.partitions | 주제별 기본 로그 파티션 수입니다. | 1 | 1 |
| num.replica.fetchers | 소스 브로커에서 메시지를 복제하는 데 사용되는 가져오기 스레드 수로, 이 값을 늘리면 팔로어 브로커의 I/O 병렬 처리 정도를 높일 수 있습니다. | 2 | max(2, vCPUs / 4)이며 여기서 vCPU는 브로커의 인스턴스 크기에 따라 달라집니다. |
| remote.log.msk.disable.policy | remote.storage.enable과 함께 사용하여 계층형 스토리지를 비활성화합니다. remote.storage.enable을 false로 설정할 때 계층형 스토리지의 데이터가 삭제됨을 나타내려면 이 정책을 삭제로 설정합니다. | 해당 사항 없음 | 없음 |
| remote.log.reader.threads | 원격 스토리지에서 데이터를 가져오는 작업을 예약하는 데 사용되는 원격 로그 리더 스레드 풀 크기입니다. | 해당 사항 없음 | max(10, vCPUs \$1 0.67)이며 여기서 vCPU는 브로커의 인스턴스 크기에 따라 달라집니다. |
| remote.storage.enable | true로 설정하면 주제에 대한 계층형 (원격) 스토리지를 활성화합니다. false로 설정되어 있고 remote.log.msk.disable.policy가 삭제로 설정되어 있는 경우 주제 수준 계층형 스토리지를 비활성화합니다. 계층형 스토리지를 비활성화하는 경우 원격 스토리지에서 데이터가 삭제됩니다. 주제에 대한 계층형 스토리지를 비활성화하면 이를 다시 활성화할 수 없습니다. | false | false |
| replica.lag.time.max.ms | 팔로워가 가져오기 요청을 보내지 않았거나 적어도 이 시간(밀리초) 동안 리더의 로그 끝 오프셋까지 소모하지 않은 경우 리더는 ISR에서 팔로어를 제거합니다. | 30000 | 30000 |
| retention.ms | 필수 필드입니다. 최소 시간은 3일입니다. 이 설정은 필수이므로 기본값이 없습니다. Amazon MSK는 retention.ms 값을 local.retention.ms와 함께 사용하여 데이터가 로컬 스토리지에서 계층형 스토리지로 이동하는 시점을 결정합니다. local.retention.ms 값은 데이터를 로컬에서 계층형 스토리지로 이동할 시기를 지정합니다. retention.ms 값은 계층형 스토리지에서 데이터를 제거(즉, 클러스터에서 제거)할 시기를 지정합니다. 유효한 값: [-1; \$1Inf]의 정수 | 최소 259,200,000밀리초(3일)이며, 무한 보존의 경우 -1입니다. | 최소 259,200,000밀리초(3일)이며, 무한 보존의 경우 -1입니다. |
| socket.receive.buffer.bytes | 소켓 서버 소켓의 SO\$1RCVBUF 버퍼입니다. 값이 -1이면 OS 기본값이 사용됩니다. | 102400 | 102400 |
| socket.request.max.bytes | 소켓 요청의 최대 바이트 수입니다. | 104857600 | 104857600 |
| socket.send.buffer.bytes | 소켓 서버 소켓의 SO\$1SNDBUF 버퍼입니다. 값이 -1이면 OS 기본값이 사용됩니다. | 102400 | 102400 |
| unclean.leader.election.enable | 데이터 손실이 발생할 수 있지만 ISR 세트에 없는 복제본을 최후의 수단으로 리더 역할을 하도록 할 것인지 여부를 나타냅니다. | true | false |
| zookeeper.session.timeout.ms | 밀리초 단위의 Apache ZooKeeper 세션 제한 시간입니다. | 18000 | 18000 |
| zookeeper.set.acl | 보안 ACL을 사용하도록 설정된 클라이언트입니다. | false | false |
사용자 지정 구성 값을 지정하는 방법에 대한 자세한 내용은 [사용자 지정 Amazon MSK 구성](msk-configuration-properties.md) 섹션을 참조하세요.
# Amazon MSK 계층형 스토리지 주제 수준의 구성에 대한 지침
다음은 주제 수준에서 계층형 스토리지를 구성할 때의 기본 설정과 제한 사항입니다.
+ Amazon MSK는 계층형 스토리지가 활성화된 주제에 대해서는 더 작은 로그 세그먼트 크기를 지원하지 않습니다. 세그먼트를 생성하려면 최소 로그 세그먼트 크기가 48MB이거나 최소 세그먼트 롤링 시간이 10분이어야 합니다. 이러한 값은 segment.bytes와 segment.ms 속성에 매핑됩니다.
+ local.retention.ms/bytes의 값은tention.ms/bytes와 같거나 초과할 수 없습니다. 이는 계층형 스토리지 보존 설정입니다.
+ local.retention.ms/bytes의 기본값은 -2입니다. 즉, retention.ms 값이 local.retention.ms/bytes에 사용됩니다. 이 경우 데이터는 로컬 스토리지와 계층형 스토리지(각각 복사본 하나씩)에 모두 남아 있으며 함께 만료됩니다. 이 옵션의 경우 로컬 데이터의 복사본이 원격 스토리지에 유지됩니다. 이 경우 소비 트래픽에서 읽은 데이터는 로컬 스토리지에서 나옵니다.
+ retention.ms의 기본값은 7일입니다. retention.bytes의 기본 크기 제한은 없습니다.
+ retention.ms/bytes의 최소값은 -1입니다. 즉, 무제한 보존을 의미합니다.
+ local.retention.ms/bytes의 최소값은 -2입니다. 즉, 로컬 스토리지에 대한 무제한 보존이 가능합니다. retention.ms/bytes 설정과 -1로 일치합니다.
+ 계층형 스토리지가 활성화된 주제의 경우 주제 수준의 구성인 retention.ms는 필수입니다. 최소 retention.ms는 3일입니다.
계층형 스토리지 제약 조건에 대한 자세한 내용은 [Amazon MSK 클러스터에 대한 계층형 스토리지 제약 조건 및 제한 사항](msk-tiered-storage.md#msk-tiered-storage-constraints) 섹션을 참조하세요.
# Express 브로커 구성
Apache Kafka에는 MSK Provisioned 클러스터의 성능을 조정하는 데 사용할 수 있는 수백 개의 브로커 구성이 있습니다. 잘못된 값이나 최적화되지 않은 값을 설정하면 클러스터 신뢰성과 성능에 영향을 미칠 수 있습니다. Express 브로커는 중요한 구성에 최적의 값을 설정하고 일반적인 잘못된 구성으로부터 보호하여 MSK Provisioned 클러스터의 가용성과 내구성을 개선합니다. 읽기 및 쓰기 액세스에 따른 구성에는 [읽기/쓰기(편집 가능)](msk-configuration-express-read-write.md), [읽기 전용](msk-configuration-express-read-only.md) 및 비읽기/쓰기 구성의 세 가지 범주가 있습니다. 일부 구성은 클러스터가 실행 중인 Apache Kafka 버전에 대한 Apache Kafka의 기본값을 계속 사용합니다. 이를 Apache Kafka 기본값으로 표시합니다.
**Topics**
+ [사용자 지정 MSK Express 브로커 구성(읽기/쓰기 액세스)](msk-configuration-express-read-write.md)
+ [Express 브로커 읽기 전용 구성](msk-configuration-express-read-only.md)
# 사용자 지정 MSK Express 브로커 구성(읽기/쓰기 액세스)
Amazon MSK의 [업데이트 구성 기능](msk-update-cluster-config.md)을 사용하거나 Apache Kafka의 AlterConfig API를 사용하여 읽기/쓰기 브로커 구성을 업데이트할 수 있습니다. Apache Kafka 브로커 구성은 정적 또는 동적입니다. 정적 구성을 적용하려면 브로커를 다시 시작해야 하지만 동적 구성을 적용하려면 브로커를 다시 시작할 필요가 없습니다. 구성 속성 및 업데이트 모드에 대한 자세한 내용은 [브로커 구성 업데이트](https://kafka.apache.org/documentation/#dynamicbrokerconfigs)를 참조하세요.
**Topics**
+ [MSK Express 브로커의 정적 구성](#msk-configuration-express-static-configuration)
+ [Express 브로커의 동적 구성](#msk-configuration-express-dynamic-configuration)
+ [Express 브로커의 주제 수준 구성](#msk-configuration-express-topic-configuration)
## MSK Express 브로커의 정적 구성
Amazon MSK를 사용하여 다음 정적 속성을 설정하는 사용자 지정 MSK 구성을 생성할 수 있습니다. Amazon MSK는 설정하지 않은 다른 모든 속성을 설정하고 관리합니다. MSK 콘솔에서 또는 [구성 명령](msk-configuration-operations-create.md)을 사용하여 정적 구성 파일을 생성하고 업데이트할 수 있습니다.
| 속성 | 설명 | 기본 값 |
| --- | --- | --- |
| allow.everyone.if.no.acl.found | 이 속성을 false로 설정하려면 먼저 클러스터에 대한 Apache Kafka ACL을 정의해야 합니다. 이 속성을 false로 설정하고 Apache Kafka ACL을 먼저 정의하지 않으면 클러스터에 대한 액세스 권한을 잃게 됩니다. 이 경우 구성을 다시 업데이트하고 이 속성을 true로 설정하여 클러스터에 다시 액세스할 수 있습니다. | true |
| auto.create.topics.enable | 서버에서 주제의 자동 생성을 활성화합니다. | false |
| compression.type | 주어진 주제에 대한 최종 압축 유형을 지정합니다. 이 구성은 표준 압축 코덱 gzip, snappy, lz4, zstd를 허용합니다. 이 구성은 압축하지 않은 유형과 동일한 `uncompressed`, 생산자가 설정한 원래 압축 코덱을 유지한다는 의미인 `producer`를 허용합니다. | Apache Kafka 기본값 |
| connections.max.idle.ms | 유휴 연결 제한 시간(밀리초). 서버 소켓 프로세서 스레드는 이 속성에 설정한 값보다 더 오래 유휴 상태인 연결을 닫습니다. | Apache Kafka 기본값 |
| delete.topic.enable | 주제 삭제 작업을 활성화합니다. 이 설정을 끄면 관리자 도구를 통해 주제를 삭제할 수 없습니다. | Apache Kafka 기본값 |
| group.initial.rebalance.delay.ms | 그룹 코디네이터가 첫 번째 재조정을 수행하기 전에 더 많은 데이터 소비자가 새 그룹에 가입할 때까지 기다리는 시간입니다. 지연 시간이 길어지면 재조정 횟수는 줄어들 수 있지만 처리가 시작될 때까지 시간이 늘어납니다. | Apache Kafka 기본값 |
| group.max.session.timeout.ms | 등록된 소비자에 대한 최대 세션 제한 시간입니다. 제한 시간이 길어지면 소비자가 하트비트 사이에 메시지를 처리할 수 있는 시간이 더 길어지지만 장애를 감지하는 데 시간이 더 오래 걸립니다. | Apache Kafka 기본값 |
| leader.imbalance.per.broker.percentage | 브로커당 허용되는 리더 불균형의 비율입니다. 컨트롤러는 브로커당 이 값을 초과하는 경우 리더 밸런스를 트리거합니다. 이 값은 백분율로 지정됩니다. | Apache Kafka 기본값 |
| log.cleanup.policy | 보존 기간이 지난 세그먼트에 대한 기본 정리 정책입니다. 유효한 정책의 쉼표로 구분된 목록입니다. 유효한 정책은 delete 및 compact입니다. 계층형 스토리지 지원 클러스터를 사용하는 경우 유효한 정책은 delete뿐입니다. | Apache Kafka 기본값 |
| log.message.timestamp.after.max.ms | 메시지 타임스탬프와 브로커의 타임스탬프 간의 허용 가능한 타임스탬프 차이입니다. 메시지 타임스탬프는 브로커의 타임스탬프보다 크거나 같을 수 있으며, 허용되는 최대 차이는 이 구성에 설정된 값에 따라 결정됩니다. `log.message.timestamp.type=CreateTime`인 경우 타임스탬프의 차이가 이 지정된 임계값을 초과하면 메시지가 거부됩니다. 이 구성은 `log.message.timestamp.type=LogAppendTime`인 경우 무시됩니다. | 86400000(24\$160\$160\$11000ms, 즉 1일) |
| log.message.timestamp.before.max.ms | 브로커의 타임스탬프와 메시지 타임스탬프 간의 허용 가능한 타임스탬프 차이입니다. 메시지 타임스탬프는 브로커의 타임스탬프보다 작거나 같을 수 있으며, 허용되는 최대 차이는 이 구성에 설정된 값에 따라 결정됩니다. `log.message.timestamp.type=CreateTime`인 경우 타임스탬프의 차이가 이 지정된 임계값을 초과하면 메시지가 거부됩니다. 이 구성은 `log.message.timestamp.type=LogAppendTime`인 경우 무시됩니다. | 86400000(24\$160\$160\$11000ms, 즉 1일) |
| log.message.timestamp.type | 메시지의 타임스탬프가 메시지 생성 시간인지 로그 추가 시간인지 지정합니다. 허용 값은 CreateTime, LogAppendTime입니다. | Apache Kafka 기본값 |
| log.retention.bytes | 삭제하기 전 로그의 최대 크기입니다. | Apache Kafka 기본값 |
| log.retention.ms | 로그 파일을 삭제하기 전에 유지할 밀리초 수입니다. | Apache Kafka 기본값 |
| max.connections.per.ip | 각 IP 주소에서 허용되는 최대 연결 수입니다. max.connections.per.ip.overrides 속성을 사용하여 재정의가 구성된 경우 이 값을 0으로 설정할 수 있습니다. 한도에 도달하면 IP 주소의 새 연결이 삭제됩니다. | Apache Kafka 기본값 |
| max.incremental.fetch.session.cache.slots | 유지되는 최대 증분 가져오기 세션 수입니다. | Apache Kafka 기본값 |
| message.max.bytes | Kafka가 허용하는 최대 레코드 배치 크기입니다. 이 값을 늘리고 0.10.2보다 오래된 소비자가 있는 경우 이 정도 크기의 레코드 배치를 가져올 수 있도록 소비자의 가져오기 크기도 늘려야 합니다. 최신 메시지 형식 버전은 효율성을 위해 항상 메시지를 배치로 그룹화합니다. 이전 메시지 형식 버전에서는 압축되지 않은 레코드를 배치로 그룹화하지 않으며 이러한 경우 이 제한은 단일 레코드에만 적용됩니다. 이 값은 주제 수준 `max.message.bytes` 구성으로 주제별로 설정할 수 있습니다. | Apache Kafka 기본값 |
| num.partitions | 주제별 기본 파티션 수입니다. | 1 |
| offsets.retention.minutes | 소비자 그룹이 모든 소비자를 잃은 후(즉, 비어 있음) 해당 오프셋은 폐기되기 전까지 이 보존 기간 동안 유지됩니다. 독립 실행형 소비자(즉, 수동 할당을 사용하는 소비자)의 경우 오프셋은 마지막 커밋 시간에 이 보존 기간을 더한 후 만료됩니다. | Apache Kafka 기본값 |
| replica.fetch.max.bytes | 각 파티션에 대해서 가져오려고 하는 메시지 바이트 수입니다. 이 값은 절대적인 최대값이 아닙니다. 가져오기의 첫 번째 비어 있지 않은 파티션에 있는 첫 번째 레코드 배치가 이 값보다 크면 진행을 보장하기 위해 레코드 배치가 반환됩니다. message.max.bytes(브로커 구성) 또는 max.message.bytes(주제 구성)는 브로커가 허용하는 최대 레코드 배치 크기를 정의합니다. | Apache Kafka 기본값 |
| replica.selector.class | ReplicaSelector를 구현하는 정규화된 클래스 이름입니다. 브로커는 이 값을 사용하여 선호하는 읽기 복제본을 찾습니다. 소비자가 가장 가까운 복제본에서 가져오도록 허용하려면 이 속성을 `org.apache.kafka.common.replica.RackAwareReplicaSelector`로 설정합니다. | Apache Kafka 기본값 |
| socket.receive.buffer.bytes | 소켓 서버 소켓의 SO\$1RCVBUF 버퍼입니다. 값이 -1이면 OS 기본값이 사용됩니다. | 102400 |
| socket.request.max.bytes | 소켓 요청의 최대 바이트 수입니다. | 104857600 |
| socket.send.buffer.bytes | 소켓 서버 소켓의 SO\$1SNDBUF 버퍼입니다. 값이 -1이면 OS 기본값이 사용됩니다. | 102400 |
| transaction.max.timeout.ms | 트랜잭션의 최대 제한 시간입니다. 클라이언트가 요청한 트랜잭션 시간이 이 값을 초과하면 브로커는 InitProducerIdRequest에 오류를 반환합니다. 이렇게 하면 클라이언트가 너무 긴 시간 제한을 방지합니다. 이로 인해 트랜잭션에 포함된 항목을 읽는 소비자가 중단될 수 있습니다. | Apache Kafka 기본값 |
| transactional.id.expiration.ms | 트랜잭션 코디네이터가 트랜잭션 ID를 만료하기 전에 현재 트랜잭션에 대한 트랜잭션 상태 업데이트를 수신하기 위해 기다리는 시간(밀리초). 이 설정은 지정된 생산자 ID로 마지막으로 쓴 후 이 시간이 경과하면 생산자 ID가 만료되므로 생산자 ID 만료에도 영향을 줍니다. 주제에 대한 보존 설정으로 인해 생산자 ID의 마지막 쓰기가 삭제되면 생산자 ID가 더 빨리 만료될 수 있습니다. 이 속성의 최소값은 1밀리초입니다. | Apache Kafka 기본값 |
## Express 브로커의 동적 구성
Apache Kafka AlterConfig API 또는 Kafka-configs.sh 도구를 사용하여 다음 동적 구성을 편집할 수 있습니다. Amazon MSK는 설정하지 않은 다른 모든 속성을 설정하고 관리합니다. 브로커를 다시 시작할 필요가 없는 클러스터 수준 및 브로커 수준 구성 속성을 동적으로 설정할 수 있습니다.
| 속성 | 설명 | 기본값 |
| --- | --- | --- |
| advertised.listeners | `listeners` 구성 속성과 다른 경우 클라이언트가 사용할 수 있도록 게시할 리스너입니다. IaaS 환경에서는 브로커가 바인딩되는 인터페이스와 이 값이 달라야 할 수 있습니다. 설정하지 않으면 리스너 값이 사용됩니다. 리스너와 달리 0.0.0.0 메타 주소를 알리는 것은 유효하지 않습니다. 또한 `listeners`와 달리 이 속성에는 중복 포트가 있을 수 있으므로 한 리스너가 다른 리스너의 주소를 알리도록 구성할 수 있습니다. 이는 외부 로드 밸런서가 사용되는 경우에 유용할 수 있습니다. 이 속성은 브로커당 수준에서 설정됩니다. | null |
| compression.type | 주어진 주제에 대한 최종 압축 유형입니다. 이 속성을 표준 압축 코덱(`gzip`, `snappy`, `lz4` 및 `zstd`)으로 설정할 수 있습니다. 추가로 `uncompressed`를 허용합니다. 이 값은 압축을 하지 않은 것과 같습니다. 값을 `producer`로 설정하면 생산자가 설정한 원본 압축 코덱을 유지한다는 의미입니다. | Apache Kafka 기본값 |
| log.cleaner.delete.retention.ms | 로그 압축 주제에 대한 삭제 톰스톤 마커를 유지하는 시간입니다. 또한 이 설정은 소비자가 오프셋 0에서 시작하는 경우 최종 단계의 유효한 스냅샷을 얻기 위해 읽기를 완료해야 하는 시간에 대한 경계를 제공합니다. 그렇지 않으면 스캔을 완료하기 전에 삭제 톰스톤이 수집될 수 있습니다. | 86400000(24 \$1 60 \$1 60 \$1 1000ms, 즉 1일), Apache Kafka 기본값 |
| log.cleaner.min.compaction.lag.ms | 로그에서 메시지가 압축되지 않은 상태로 유지되는 최소 시간입니다. 이 설정은 압축 중인 로그에만 적용됩니다. | 0, Apache Kafka 기본값 |
| log.cleaner.max.compaction.lag.ms | 메시지가 로그의 압축에 적합하지 않은 상태로 유지되는 최대 시간입니다. 이 설정은 압축 중인 로그에만 적용됩니다. 이 구성은 [7일, Long.Max] 범위로 제한됩니다. | 9223372036854775807, Apache Kafka 기본값 |
| log.cleanup.policy | 보존 기간이 지난 세그먼트에 대한 기본 정리 정책입니다. 유효한 정책의 쉼표로 구분된 목록입니다. 유효한 정책은 `delete` 및 `compact`입니다. 계층형 스토리지 지원 클러스터를 사용하는 경우 유효한 정책은 `delete`뿐입니다. | Apache Kafka 기본값 |
| log.message.timestamp.after.max.ms | 메시지 타임스탬프와 브로커의 타임스탬프 간의 허용 가능한 타임스탬프 차이입니다. 메시지 타임스탬프는 브로커의 타임스탬프보다 크거나 같을 수 있으며, 허용되는 최대 차이는 이 구성에 설정된 값에 따라 결정됩니다. `log.message.timestamp.type=CreateTime`인 경우 타임스탬프의 차이가 이 지정된 임계값을 초과하면 메시지가 거부됩니다. 이 구성은 `log.message.timestamp.type=LogAppendTime`인 경우 무시됩니다. | 86400000(24\$160\$160\$11000ms, 즉 1일) |
| log.message.timestamp.before.max.ms | 브로커의 타임스탬프와 메시지 타임스탬프 간의 허용 가능한 타임스탬프 차이입니다. 메시지 타임스탬프는 브로커의 타임스탬프보다 작거나 같을 수 있으며, 허용되는 최대 차이는 이 구성에 설정된 값에 따라 결정됩니다. `log.message.timestamp.type=CreateTime`인 경우 타임스탬프의 차이가 이 지정된 임계값을 초과하면 메시지가 거부됩니다. 이 구성은 `log.message.timestamp.type=LogAppendTime`인 경우 무시됩니다. | 86400000(24\$160\$160\$11000ms, 즉 1일) |
| log.message.timestamp.type | 메시지의 타임스탬프가 메시지 생성 시간인지 로그 추가 시간인지 지정합니다. 허용 값은 `CreateTime`, `LogAppendTime`입니다. | Apache Kafka 기본값 |
| log.retention.bytes | 삭제하기 전 로그의 최대 크기입니다. | Apache Kafka 기본값 |
| log.retention.ms | 로그 파일을 삭제하기 전에 유지할 밀리초 수입니다. | Apache Kafka 기본값 |
| max.connection.creation.rate | 언제든지 브로커에 허용되는 최대 연결 생성 속도입니다. | Apache Kafka 기본값 |
| max.connections | 언제든지 브로커에 허용되는 최대 연결 수입니다. 이 제한은 `max.connections.per.ip`를 사용하여 구성된 모든 IP당 제한에 추가로 적용됩니다. | Apache Kafka 기본값 |
| max.connections.per.ip | 각 IP 주소에서 허용되는 최대 연결 수입니다. max.connections.per.ip.overrides 속성을 사용하여 구성된 재정의가 있는경우 이 값을 `0`으로 설정할 수 있습니다. 한도에 도달하면 IP 주소의 새 연결이 삭제됩니다. | Apache Kafka 기본값 |
| max.connections.per.ip.overrides | IP 또는 호스트 이름당 쉼표로 구분된 목록은 기본 최대 연결 수로 재정의됩니다. 예시 값은 `hostName:100,127.0.0.1:200`입니다. | Apache Kafka 기본값 |
| message.max.bytes | Kafka가 허용하는 최대 레코드 배치 크기입니다. 이 값을 늘리고 0.10.2보다 오래된 소비자가 있는 경우 이 정도 크기의 레코드 배치를 가져올 수 있도록 소비자의 가져오기 크기도 늘려야 합니다. 최신 메시지 형식 버전은 효율성을 위해 항상 메시지를 배치로 그룹화합니다. 이전 메시지 형식 버전에서는 압축되지 않은 레코드를 배치로 그룹화하지 않으며 이러한 경우 이 제한은 단일 레코드에만 적용됩니다. 이 값은 주제 수준 `max.message.bytes` 구성으로 주제별로 설정할 수 있습니다. | Apache Kafka 기본값 |
| producer.id.expiration.ms | 주제 파티션 리더가 생산자 ID 만료 전에 기다리는 시간(ms)입니다. 생산자 ID는 연결된 트랜잭션이 진행 중인 동안에는 만료되지 않습니다. 주제의 보존 설정으로 인해 생산자 ID의 마지막 쓰기가 삭제되면 생산자 ID가 더 빨리 만료될 수 있습니다. 이 값을 `delivery.timeout.ms`보다 크거나 같게 설정하면 재시도 중 만료를 방지하고 메시지 중복으로부터 보호할 수 있지만 기본값은 대부분의 사용 사례에 적합해야 합니다. | Apache Kafka 기본값 |
## Express 브로커의 주제 수준 구성
Apache Kafka 명령을 사용하여 새 주제와 기존 주제에 대한 주제 수준 구성 속성을 설정하거나 수정할 수 있습니다. 주제 수준 구성을 제공할 수 없는 경우 Amazon MSK는 브로커 기본값을 사용합니다. 브로커 수준 구성과 마찬가지로 Amazon MSK는 일부 주제 수준 구성 속성이 변경되지 않도록 보호합니다. 복제 인수 `min.insync.replicas` 및 `unclean.leader.election.enable`을 예로 들 수 있습니다. `3` 이외의 복제 인수 값으로 주제를 생성하려고 시도하는 경우 Amazon MSK는 기본적으로 복제 인수가 `3`인 주제를 생성합니다. 주제 수준 구성 속성과 설정 방법 예제에 대한 자세한 내용은 Apache Kafka 설명서의 [주제 수준 구성](https://kafka.apache.org/documentation/#topicconfigs)을 참조하세요.
| 속성 | 설명 |
| --- | --- |
| cleanup.policy | 이 구성은 로그 세그먼트에 사용할 보존 정책을 지정합니다. "delete" 정책(기본값)은 보존 기간 또는 크기 제한에 도달하는 경우 이전 세그먼트를 삭제합니다. "compact" 정책은 각 키에 대한 최신 값을 유지하는 로그 압축을 활성화합니다. 쉼표로 구분된 목록에서 두 정책을 모두 지정할 수도 있습니다(예: "delete,compact"). 이 경우 보존 기간 및 크기 구성에 따라 이전 세그먼트는 삭제되고 보존된 세그먼트는 압축됩니다. Express 브로커의 압축은 파티션의 데이터가 256MB에 도달하면 트리거됩니다. |
| compression.type | 주어진 주제에 대한 최종 압축 유형을 지정합니다. 이 구성은 표준 압축 코덱(`gzip`, `snappy`, `lz4`, `zstd`)을 허용합니다. 또한 압축하지 않은 유형과 동일한 `uncompressed`, 생산자가 설정한 원래 압축 코덱을 유지한다는 의미인 `producer`를 허용합니다. |
| delete.retention.ms | 로그 압축 주제에 대한 삭제 톰스톤 마커를 유지하는 시간입니다. 또한 이 설정은 소비자가 오프셋 0에서 시작하는 경우 최종 단계의 유효한 스냅샷을 얻기 위해 읽기를 완료해야 하는 시간에 대한 경계를 제공합니다. 그렇지 않으면 스캔을 완료하기 전에 삭제 톰스톤이 수집될 수 있습니다. 이 설정의 기본값은 86400000(24 \$1 60 \$1 60 \$1 1000ms, 즉 1일), Apache Kafka 기본값입니다. |
| max.message.bytes | Kafka에서 허용하는 최대 레코드 배치 크기입니다(압축이 활성화된 경우 압축 후). 이 값이 커지고 `0.10.2`보다 오래된 소비자가 있는 경우, 소비자의 가져오기 크기도 이 크기의 레코드 배치를 가져올 수 있도록 커져야 합니다. 최신 메시지 형식 버전에서 레코드는 효율성을 위해 항상 배치로 그룹화됩니다. 이전 메시지 형식 버전에서는 압축되지 않은 레코드가 배치로 그룹화되지 않으며, 이 경우 이 제한은 단일 레코드에만 적용됩니다. 이 값은 주제 수준 `max.message.bytes config`를 통해 주제별로 설정할 수 있습니다. |
| message.timestamp.after.max.ms | 이 구성은 메시지 타임스탬프와 브로커의 타임스탬프 간에 허용되는 타임스탬프 차이를 설정합니다. 메시지 타임스탬프는 브로커의 타임스탬프보다 크거나 같을 수 있으며, 허용되는 최대 차이는 이 구성에 설정된 값에 따라 결정됩니다. `message.timestamp.type=CreateTime`인 경우 타임스탬프의 차이가 이 지정된 임계값을 초과하면 메시지가 거부됩니다. 이 구성은 `message.timestamp.type=LogAppendTime`인 경우 무시됩니다. |
| message.timestamp.before.max.ms | 이 구성은 브로커의 타임스탬프와 메시지 타임스탬프 간의 허용 가능한 타임스탬프 차이를 설정합니다. 메시지 타임스탬프는 브로커의 타임스탬프보다 작거나 같을 수 있으며, 허용되는 최대 차이는 이 구성에 설정된 값에 따라 결정됩니다. `message.timestamp.type=CreateTime`인 경우 타임스탬프의 차이가 이 지정된 임계값을 초과하면 메시지가 거부됩니다. 이 구성은 `message.timestamp.type=LogAppendTime`인 경우 무시됩니다. |
| message.timestamp.type | 메시지의 타임스탬프가 메시지 생성 시간인지 아니면 로그 추가 시간인지 정의합니다. 값은 `CreateTime` 또는 `LogAppendTime`이어야 합니다. |
| min.compaction.lag.ms | 로그에서 메시지가 압축되지 않은 상태로 유지되는 최소 시간입니다. 이 설정은 압축 중인 로그에만 적용됩니다. 이 설정의 기본값은 0, Apache Kafka 기본값입니다. |
| max.compaction.lag.ms | 메시지가 로그의 압축에 적합하지 않은 상태로 유지되는 최대 시간입니다. 이 설정은 압축 중인 로그에만 적용됩니다. 이 구성은 [7일, Long.Max] 범위로 제한됩니다. 이 설정의 기본값은 9223372036854775807, Apache Kafka 기본값입니다. |
| retention.bytes | 이 구성은 "delete" 보존 정책을 사용하는 경우 공간을 확보하기 위해 이전 로그 세그먼트를 폐기하기 전에 파티션(로그 세그먼트로 구성)이 증가할 수 있는 최대 크기를 제어합니다. 기본적으로 크기 제한은 없고 시간 제한만 있습니다. 이 제한은 파티션 수준에서 적용되므로 파티션 수에 곱하여 주제 보존을 바이트 단위로 계산합니다. 또한 `retention.bytes configuration`은 `segment.ms` 및 `segment.bytes` 구성과 독립적으로 작동합니다. `retention.bytes`가 0으로 구성된 경우에는 새 세그먼트의 롤링을 트리거합니다. |
| retention.ms | 이 구성은 "delete" 보존 정책을 사용하는 경우 공간을 확보하기 위해 이전 로그 세그먼트를 폐기하기 전에 로그를 보존할 최대 시간을 제어합니다. 이는 소비자가 데이터를 얼마나 빨리 읽어야 하는지에 대한 SLA를 나타냅니다. `-1`로 설정하면 시간 제한이 적용되지 않습니다. 또한 `retention.ms` 구성은 `segment.ms` 및 `segment.bytes` 구성과 독립적으로 작동합니다. `retention.ms` 조건이 충족되면 새 세그먼트의 롤링을 트리거합니다. |
# Express 브로커 읽기 전용 구성
Amazon MSK는 이러한 구성의 값을 설정하고 해당 값이 변경되어 클러스터의 가용성에 영향을 미치지 않도록 보호합니다. 이러한 값은 클러스터에서 실행되는 Apache Kafka 버전에 따라 변경될 수 있으므로 특정 클러스터의 값을 확인해야 합니다.
다음 표에는 Express 브로커에 대한 읽기 전용 구성이 나열되어 있습니다.
| 속성 | 설명 | Express 브로커 값 |
| --- | --- | --- |
| broker.id | 이 서버의 브로커 ID입니다. | 1,2,3... |
| broker.rack | 브로커의 랙입니다. 이는 내결함성을 위한 랙 인식 복제 할당에 사용됩니다. 예: `RACK1`, `us-east-1d` | AZ ID 또는 서브넷 ID |
| default.replication.factor | 모든 주제에 대한 기본 복제 인수입니다. | 3 |
| fetch.max.bytes | 가져오기 요청에 대해 반환할 최대 바이트 수입니다. | Apache Kafka 기본값 |
| group.max.size | 단일 소비자 그룹이 수용할 수 있는 최대 소비자 수입니다. | Apache Kafka 기본값 |
| inter.broker.listener.name | 브로커 간 통신에 사용되는 리스너의 이름입니다. | REPLICATION\$1SECURE 또는 REPLICATION |
| inter.broker.protocol.version | 브로커 간 프로토콜의 사용 버전을 지정합니다. | Apache Kafka 기본값 |
| 리스너 | 리스너 목록 - 수신할 URI와 리스너 이름을 쉼표로 구분한 목록입니다. advertised.listeners property는 설정할 수 있지만 listeners 속성은 설정할 수 없습니다. | MSK 생성 |
| log.message.format.version | 브로커가 로그에 메시지를 추가하는 데 사용할 메시지 형식 버전을 지정합니다. | Apache Kafka 기본값 |
| min.insync.replicas | 생산자가 ack를 `all`(또는 `-1`)로 설정하면 `min.insync.replicas`의 값은 쓰기가 성공한 것으로 간주되기 위해 쓰기를 승인해야 하는 최소 복제본 수를 지정합니다. 이 최소값을 충족할 수 없는 경우 생산자는 예외(`NotEnoughReplicas` 또는 `NotEnoughReplicasAfterAppend`)를 발생시킵니다. 생산자의 ack 값을 사용하여 내구성을 강화할 수 있습니다. acks를 "all"로 설정합니다. 이렇게 하면 대부분의 복제본이 쓰기를 수신하지 못하는 경우 생산자가 예외를 발생시킵니다. | 2 |
| num.io.threads | 서버가 디스크 I/O를 포함할 수 있는 요청을 생성하는 데 사용하는 스레드 수입니다. (m7g.large, 8), (m7g.xlarge, 8), (m7g.2xlarge, 16), (m7g.4xlarge, 32), (m7g.8xlarge, 64), (m7g.12xlarge, 96), (m7g.16xlarge, 128) | 인스턴스 유형에 따라 다릅니다. =Math.max(8, 2 \$1 vCPUs) |
| num.network.threads | 서버가 네트워크에서 요청을 수신하고 네트워크에 응답을 보내는 데 사용하는 스레드 수입니다. (m7g.large, 8), (m7g.xlarge, 8), (m7g.2xlarge, 8), (m7g.4xlarge, 16), (m7g.8xlarge, 32), (m7g.12xlarge, 48), (m7g.16xlarge, 64) | 인스턴스 유형에 따라 다릅니다. =Math.max(8, vCPUs) |
| replica.fetch.response.max.bytes | 전체 가져오기 응답에 대해 예상되는 최대 바이트 수입니다. 레코드는 배치로 가져오며 가져오기의 첫 번째 비어 있지 않은 파티션의 첫 번째 레코드 배치가 이 값보다 크면 진행을 보장하기 위해 배치가 반환됩니다. 이 값은 절대적인 최대값이 아닙니다. message.max.bytes(브로커 구성) 또는 max.message.bytes(주제 구성) 속성은 브로커가 허용하는 최대 레코드 배치 크기를 지정합니다. | Apache Kafka 기본값 |
| request.timeout.ms | 이 구성은 클라이언트가 요청의 응답을 기다리는 최대 시간을 제어합니다. 제한 시간이 경과하기 전에 응답이 수신되지 않으면 필요한 경우 클라이언트가 요청을 재전송하거나, 재시도가 소진되면 요청에 실패합니다. | Apache Kafka 기본값 |
| transaction.state.log.min.isr | 트랜잭션 주제에 대한 min.insync.replicas 구성을 재정의했습니다. | 2 |
| transaction.state.log.replication.factor | 트랜잭션 주제에 대한 복제 인수입니다. | Apache Kafka 기본값 |
| unclean.leader.election.enable | 데이터 손실이 발생할 수 있지만 ISR 세트에 없는 복제본이 최후의 수단으로 리더 역할을 수행할 수 있도록 허용합니다. | FALSE |
# 브로커 구성 작업
Apache Kafka 브로커 구성은 정적 또는 동적입니다. 정적 구성을 적용하려면 브로커를 다시 시작해야 합니다. 동적 구성을 업데이트하기 위해 브로커를 다시 시작할 필요는 없습니다. 구성 속성 및 업데이트 모드에 대한 자세한 내용은 Apache Kafka 구성을 참조하세요.
이 주제에서는 사용자 지정 MSK 구성을 생성하고 이러한 구성으로 작업을 수행하는 방법을 설명합니다. MSK 구성을 사용하여 클러스터를 생성하거나 업데이트하는 방법에 대한 자세한 내용은 [Amazon MSK 주요 기능 및 개념](operations.md) 단원을 참조하십시오.
**Topics**
+ [구성 생성](msk-configuration-operations-create.md)
+ [구성 업데이트](msk-configuration-operations-update.md)
+ [구성 삭제](msk-configuration-operations-delete.md)
+ [구성 메타데이터 가져오기](msk-configuration-operations-describe.md)
+ [구성 개정에 대한 세부 정보 가져오기](msk-configuration-operations-describe-revision.md)
+ [현재 리전의 계정에 있는 구성 나열](msk-configuration-operations-list.md)
+ [Amazon MSK 구성 상태](msk-configuration-states.md)
# 구성 생성
이 프로세스는 사용자 지정 Amazon MSK 구성을 생성하고 이러한 구성에 대한 작업을 수행하는 방법을 설명합니다.
1. 설정할 구성 속성과 해당 구성 속성에 할당할 값을 지정하는 파일을 만듭니다. 다음은 예제 구성 파일의 내용입니다.
```
auto.create.topics.enable = true
log.roll.ms = 604800000
```
1. 다음 AWS CLI 명령을 실행하고 *config-file-path*를 이전 단계에서 구성을 저장한 파일의 경로로 바꿉니다.
**참고**
구성에 대해 선택하는 이름은 "^[0-9A-Za-z][0-9A-Za-z-]\$10,\$1\$1"와 일치해야 합니다.
```
aws kafka create-configuration --name "ExampleConfigurationName" --description "Example configuration description." --kafka-versions "1.1.1" --server-properties fileb://config-file-path
```
다음은 이 명령을 실행한 후 성공적인 응답의 예제입니다.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"CreationTime": "2019-05-21T19:37:40.626Z",
"LatestRevision": {
"CreationTime": "2019-05-21T19:37:40.626Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "ExampleConfigurationName"
}
```
1. 이전 명령은 새로운 구성에 대해 Amazon 리소스 이름(ARN)을 반환합니다. 이 ARN을 저장하십시오. 다른 명령에서 이 구성을 참조할 때 필요합니다. 구성 ARN을 잃어버린 경우 계정에 있는 모든 구성을 나열하여 다시 찾을 수 있습니다.
# 구성 업데이트
이 프로세스는 사용자 지정 Amazon MSK 구성을 업데이트하는 방법을 설명합니다.
1. 업데이트할 구성 속성과 해당 속성에 할당할 값을 지정하는 파일을 생성합니다. 다음은 예제 구성 파일의 내용입니다.
```
auto.create.topics.enable = true
min.insync.replicas = 2
```
1. 다음 AWS CLI 명령을 실행하여 *config-file-path*를 이전 단계에서 구성을 저장한 파일의 경로로 변경합니다.
*configuration-arn*을 구성을 생성할 때 가져온 ARN으로 변경합니다. 구성을 생성할 때 ARN을 저장하지 않은 경우 `list-configurations` 명령을 사용하여 계정의 모든 구성을 나열할 수 있습니다. 목록에서 원하는 구성이 응답에 표시됩니다. 구성의 ARN도 해당 목록에 나타납니다.
```
aws kafka update-configuration --arn configuration-arn --description "Example configuration revision description." --server-properties fileb://config-file-path
```
1. 다음은 이 명령을 실행한 후 성공적인 응답의 예제입니다.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"LatestRevision": {
"CreationTime": "2020-08-27T19:37:40.626Z",
"Description": "Example configuration revision description.",
"Revision": 2
}
}
```
# 구성 삭제
다음 절차는 클러스터에 연결되지 않은 구성을 삭제하는 방법을 보여줍니다. 클러스터에 연결된 구성은 삭제할 수 없습니다.
1. 이 예제를 실행하려면 *configuration-arn*을 구성 생성 시에 가져온 ARN으로 변경합니다. 구성을 생성할 때 ARN을 저장하지 않은 경우 `list-configurations` 명령을 사용하여 계정의 모든 구성을 나열할 수 있습니다. 목록에서 원하는 구성이 응답에 표시됩니다. 구성의 ARN도 해당 목록에 나타납니다.
```
aws kafka delete-configuration --arn configuration-arn
```
1. 다음은 이 명령을 실행한 후 성공적인 응답의 예제입니다.
```
{
"arn": " arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"state": "DELETING"
}
```
# 구성 메타데이터 가져오기
다음 절차에서는 Amazon MSK 구성을 설명하여 구성에 대한 메타데이터를 가져오는 방법을 보여줍니다.
1. 다음 명령은 구성에 대한 메타데이터를 반환합니다. 구성에 대한 자세한 설명을 보려면 `describe-configuration-revision` 단원을 실행합니다.
이 예제를 실행하려면 *configuration-arn*을 구성 생성 시에 가져온 ARN으로 변경합니다. 구성을 생성할 때 ARN을 저장하지 않은 경우 `list-configurations` 명령을 사용하여 계정의 모든 구성을 나열할 수 있습니다. 목록에서 원하는 구성이 응답에 표시됩니다. 구성의 ARN도 해당 목록에 나타납니다.
```
aws kafka describe-configuration --arn configuration-arn
```
1. 다음은 이 명령을 실행한 후 성공적인 응답의 예제입니다.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "SomeTest"
}
```
# 구성 개정에 대한 세부 정보 가져오기
이 프로세스는 Amazon MSK 구성 개정에 대해 자세히 설명합니다.
`describe-configuration` 명령을 사용하여 MSK 구성을 설명하면 구성의 메타데이터를 볼 수 있습니다. 구성에 대한 설명을 보려면 `describe-configuration-revision` 명령을 사용합니다.
+ 다음 명령을 실행하여 *configuration-arn*을 구성을 생성할 때 가져온 ARN으로 변경합니다. 구성을 생성할 때 ARN을 저장하지 않은 경우 `list-configurations` 명령을 사용하여 계정의 모든 구성을 나열할 수 있습니다. 응답에 표시되는 목록에서 원하는 구성을 선택합니다. 구성의 ARN도 해당 목록에 나타납니다.
```
aws kafka describe-configuration-revision --arn configuration-arn --revision 1
```
다음은 이 명령을 실행한 후 성공적인 응답의 예제입니다.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1,
"ServerProperties": "YXV0by5jcmVhdGUudG9waWNzLmVuYWJsZSA9IHRydWUKCgp6b29rZWVwZXIuY29ubmVjdGlvbi50aW1lb3V0Lm1zID0gMTAwMAoKCmxvZy5yb2xsLm1zID0gNjA0ODAwMDAw"
}
```
`ServerProperties` 값은 base64로 인코딩됩니다. base64 디코더(예: https://www.base64decode.org/)를 사용하여 수동으로 디코딩하는 경우 사용자 지정 구성을 만드는 데 사용한 원본 구성 파일의 내용을 가져옵니다. 이 경우 다음과 같은 결과를 얻을 수 있습니다.
```
auto.create.topics.enable = true
log.roll.ms = 604800000
```
# 현재 리전의 계정에 있는 구성 나열
이 프로세스는 현재 AWS 리전의 계정에서 모든 Amazon MSK 구성을 나열하는 방법을 설명합니다.
+ 다음 명령을 실행합니다.
```
aws kafka list-configurations
```
다음은 이 명령을 실행한 후 성공적인 응답의 예제입니다.
```
{
"Configurations": [
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "SomeTest"
},
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"CreationTime": "2019-05-03T23:08:29.446Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-03T23:08:29.446Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "ExampleConfigurationName"
}
]
}
```
# Amazon MSK 구성 상태
Amazon MSK 구성은 다음 상태 중 하나에 해당될 수 있습니다. 구성에 대한 작업을 수행하려면 구성이 `ACTIVE` 또는 `DELETE_FAILED` 상태여야 합니다.
+ `ACTIVE`
+ `DELETING`
+ `DELETE_FAILED`
# 클러스터의 지능형 리밸런싱
Amazon MSK는 Express 브로커를 사용하여 모든 새 MSK 프로비저닝 클러스터에 대한 지능형 리밸런싱을 제공합니다. 이 기능은 파티션 배포 및 클러스터 조정 작업을 자동으로 관리하므로 타사 도구가 필요하지 않습니다. 지능형 리밸런싱은 클러스터를 확장하거나 축소할 때 파티션을 자동으로 리밸런싱합니다. 또한 클러스터의 상태를 지속적으로 모니터링하여 리소스 불균형 또는 오버로드가 있는지 확인하고 워크로드를 재배포합니다.
지능형 리밸런싱은 30분 이내에 완료되며 조정 중에 클러스터 가용성에 영향을 주지 않는 빠른 조정 작업을 제공합니다. 모든 새 MSK Express 기반 프로비저닝된 클러스터에 대해 기본적으로 켜져 있으며 브로커당 파티션 20,000개의 권장 최대 파티션 한도로 작동합니다. 또한이 기능은 추가 비용 없이 사용할 수 있으며 구성이 필요하지 않습니다.
2025년 11월 20일부터 Amazon MSK Express 브로커가 지원되는 모든 AWS 리전에서 Intelligent Rebalancing을 사용할 수 있습니다.
**Topics**
+ [지능형 리밸런싱 작동 방식](#how-intelligent-rebalancing-works)
+ [지능형 리밸런싱 지표 모니터링](#intelligent-rebalancing-metrics)
+ [지능형 리밸런싱 사용 시 고려 사항](#intelligent-rebalancing-considerations)
+ [단일 작업으로 Amazon MSK 클러스터 확장 및 축소](intelligent-rebalancing-scaling-clusters.md)
+ [Amazon MSK 클러스터의 정상 상태 재분배](intelligent-rebalancing-self-balancing-paritions.md)
## 지능형 리밸런싱 작동 방식
Express 브로커가 있는 모든 새 MSK 프로비저닝 클러스터에 대해 기본적으로 지능형 리밸런싱이 켜져 있습니다. 여기에는 다음 상황에 대한 지원이 포함됩니다.
+ **확장 및 축소**: 클릭 한 번으로 MSK Express 기반 클러스터에 브로커를 추가하거나 제거할 수 있습니다. 추가하거나 제거할 브로커를 지정하면 지능형 리밸런싱은 내부 AWS 모범 사례에 따라 새 클러스터 설정에서 파티션을 자동으로 재배포합니다.
+ **안정 상태 리밸런싱**:이 기능은 안정 상태에서 클러스터의 상태를 지속적으로 모니터링하고 다음과 같은 경우 파티션을 자동으로 리밸런싱합니다.
+ 리소스 사용률이 브로커 간에 왜곡됩니다.
+ 브로커가 과도하게 프로비저닝되거나 활용도가 떨어집니다.
+ 새 브로커가 추가되거나 기존 브로커가 제거됩니다.
**참고**
지능형 리밸런싱이 켜져 있으면 파티션 리밸런싱에 Cruise Control과 같은 타사 도구를 사용할 수 없습니다. 이러한 타사 도구에서 제공하는 파티션 재할당 API를 사용하려면 먼저 지능형 재분배를 일시 중지해야 합니다.
Amazon MSK 콘솔에서이 기능을 사용할 수 있습니다. AWS CLI, Amazon MSK APIs 또는 AWS SDK 및를 사용하여이 기능을 사용할 수도 있습니다 AWS CloudFormation. 자세한 내용은 [Amazon MSK 클러스터 크기 조정](intelligent-rebalancing-scaling-clusters.md) 및 [안정 상태 리밸런싱](intelligent-rebalancing-self-balancing-paritions.md) 섹션을 참조하세요.
## 지능형 리밸런싱 지표 모니터링
다음 Amazon CloudWatch 지표를 사용하여 진행 중인 과거 지능형 리밸런싱 작업의 상태를 모니터링할 수 있습니다.
+ `RebalanceInProgress`:이 지표는 리밸런싱이 진행 중인 경우 1, 그렇지 않으면 0의 값으로 1분마다 게시됩니다.
+ `UnderProvisioned`: 클러스터가 현재 프로비저닝 중이며 파티션 리밸런싱을 수행할 수 없음을 나타냅니다. 브로커를 더 추가하거나 클러스터의 인스턴스 유형을 확장해야 합니다.
MSK 프로비저닝 클러스터 모니터링에 대한 자세한 내용은 [](monitoring.md) 및 섹션을 참조하세요[](cloudwatch-metrics.md).
## 지능형 리밸런싱 사용 시 고려 사항
+ 지능형 리밸런싱 지원은 Express 브로커가 있는 새 MSK 프로비저닝 클러스터에서만 사용할 수 있습니다.
+ 자동 파티션 재할당의 경우 브로커당 최대 20,000개의 파티션에 대한 최대 지원을 사용할 수 있습니다.
+ 지능형 리밸런싱이 활성화된 경우 파티션 재할당 APIs 또는 타사 리밸런싱 도구를 사용할 수 없습니다. 이러한 APIs 또는 타사 도구를 사용하려면 먼저 MSK Express 기반 클러스터에 대한 지능형 리밸런싱을 일시 중지해야 합니다.
# 단일 작업으로 Amazon MSK 클러스터 확장 및 축소
지능형 리밸런싱을 사용하면 단일 작업으로 클러스터의 브로커 수를 편집하여 클러스터를 확장하거나 축소할 수 있습니다. Amazon MSK 콘솔에서 또는 AWS CLI Amazon MSK APIs 또는 AWS SDK 및를 사용하여이 작업을 수행할 수 있습니다 AWS CloudFormation. 브로커 수를 변경하면 Amazon MSK는 다음을 수행합니다.
+ 파티션을 새 브로커에 자동으로 배포합니다.
+ 제거 중인 브로커에서 파티션을 이동합니다.
클러스터를 확장하거나 축소할 때 클라이언트가 데이터를 생성하고 소비할 수 있는 클러스터 가용성은 영향을 받지 않습니다.
**Topics**
------
#### [ Scaling clusters using AWS Management Console ]
1. [https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)에서 Amazon MSK 콘솔을 엽니다.
1. **클러스터** 페이지에서 새로 생성된 Express 기반 클러스터를 선택합니다. 프로비저닝된 Express 기반 클러스터 생성에 대한 자세한 내용은 섹션을 참조하세요[1단계: MSK Provisioned 클러스터 생성](create-cluster.md).
1. **작업** 드롭다운 목록에서 **브로커 수 편집을** 선택합니다.
1. **영역당 브로커 수 편집** 페이지에서 다음 중 하나를 수행합니다.
+ 클러스터에 브로커를 더 추가하려면 **각 가용 영역에 브로커 추가를** 선택한 다음 추가할 브로커 수를 입력합니다.
+ 클러스터에서 브로커를 제거하려면 **각 가용 영역에서 하나의 브로커 제거를** 선택합니다.
1. **변경 사항 저장**을 선택합니다.
------
#### [ Scaling clusters using AWS CLI ]
브로커 수를 편집하여 클러스터를 확장하거나 축소할 수 있습니다. 에서이 작업을 수행하려면 다음 예제와 같이 [update-broker-count](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-broker-count.html) 명령을 AWS CLI사용합니다. 이 명령에서 `target-broker-count` 파라미터의 클러스터에 원하는 브로커 수를 지정합니다.
```
aws msk update-broker-count --cluster-arn arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1 --current-version ABCDEF1GHIJK0L --target-broker-count 6
```
------
#### [ Scaling clusters using AWS SDK ]
브로커 수를 프로그래밍 방식으로 편집하여 클러스터를 확장하거나 축소할 수 있습니다. AWS SDK를 사용하여이 작업을 수행하려면 다음 예제와 같이 [UpdateBrokerCount](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes-count.html#UpdateBrokerCount) API를 사용합니다. `TargetNumberOfBrokerNodes` 파라미터에 클러스터에서 원하는 브로커 수를 지정합니다.
```
update_broker_count_response = client.update_broker_count(
ClusterArn='arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1',
CurrentVersion='ABCDEF1GHIJK0L',
TargetNumberOfBrokerNodes=6
)
```
------
# Amazon MSK 클러스터의 정상 상태 재분배
정상 상태 리밸런싱은 Express 브로커가 있는 모든 새 MSK 프로비저닝 클러스터에 대해 기본적으로 활성화되는 지능형 리밸런싱 기능의 일부입니다. 클러스터를 확장하거나 축소하면 Amazon MSK는 파티션을 새 브로커에 배포하고 제거 예정인 브로커에서 파티션을 이동하여 파티션 관리를 자동으로 처리합니다. 브로커 간에 워크로드를 최적으로 분산하기 위해 지능형 리밸런싱은 Amazon MSK 모범 사례를 사용하여 브로커에 대한 리밸런싱을 자동으로 시작하기 위한 임계값을 결정합니다.
필요한 경우 안정 상태 재분배를 일시 중지했다가 재개할 수 있습니다. 정상 상태 리밸런싱은 클러스터를 지속적으로 모니터링하고 다음을 수행합니다.
+ 브로커 리소스 사용량(CPU, 네트워크, 스토리지)을 추적합니다.
+ 데이터 가용성에 영향을 주지 않고 파티션 배치를 자동으로 조정합니다.
+ 표준 브로커에 비해 Express 브로커에서 최대 180배 빠른 리밸런싱 작업을 완료합니다.
+ 클러스터 성능을 유지합니다.
**Topics**
------
#### [ Pause and resume steady state rebalancing in AWS Management Console ]
1. [https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)에서 Amazon MSK 콘솔을 엽니다.
1. **클러스터** 페이지에서 Express 기반 클러스터를 선택합니다. 프로비저닝된 Express 기반 클러스터 생성에 대한 자세한 내용은 섹션을 참조하세요[1단계: MSK Provisioned 클러스터 생성](create-cluster.md).
1. 클러스터 세부 정보 페이지에서 **지능형 리밸런싱** 상태가 **활성**인지 확인합니다. 지능형 리밸런싱을 사용할 수 없거나 상태가 **일시 중지됨**인 경우 새 Express 기반 클러스터를 생성합니다.
1. **작업** 드롭다운 목록에서 **지능형 재분배 편집**을 선택합니다.
1. **지능형 리밸런싱 편집** 페이지에서 다음을 수행합니다.
1. **일시 중지됨을** 선택합니다.
1. **변경 사항 저장**을 선택합니다.
------
#### [ Pause and resume steady state rebalancing using AWS CLI ]
를 **ACTIVE** 사용하여 클러스터의 리밸런싱 상태를 로 설정하려면 다음 예제와 같이 [update-rebalancing](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-rebalancing.html) 명령을 AWS CLI사용합니다. 이 명령에서 `rebalancing` 파라미터를 사용하여 상태를 지정합니다.
```
aws msk update-rebalancing --cluster-arn arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1 --current-version ABCDEF1GHIJK0L --rebalancing "{\"Rebalancing\":{\"Status\":\"ACTIVE\"}}"
```
------
#### [ Pause and resume steady state rebalancing using AWS SDK ]
[UpdateRebalancingRequest](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-rebalancing.html#UpdateRebalancing) API를 사용하여 클러스터의 리밸런싱 상태를 설정하여 브로커 수를 프로그래밍 방식으로 수정할 수도 있습니다. 다음 예제에서는 리밸런싱 상태를 **ACTIVE** 및 로 설정하는 방법을 보여줍니다**PAUSED**.
```
final UpdateRebalancingRequest updateRebalancingRequest = new UpdateRebalancingRequest()
.withClusterArn(arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1)
.withCurrentVersion(ABCDEF1GHIJK0L)
.withRebalancing(new Rebalancing().withStatus("ACTIVE"));
```
```
final UpdateRebalancingRequest updateRebalancingRequest = new UpdateRebalancingRequest()
.withClusterArn(arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1)
.withCurrentVersion(ABCDEF1GHIJK0L)
.withRebalancing(new Rebalancing().withStatus("PAUSED"));
```
------
# MSK Provisioned 클러스터에 패치 적용
Amazon MSK는 주기적으로 클러스터 브로커의 소프트웨어를 업데이트합니다. 유지 관리에는 계획된 업데이트 또는 계획되지 않은 수리가 포함됩니다. 계획된 유지 관리에는 클러스터의 상태, 보안 및 성능을 유지하는 데 필요한 운영 체제 업데이트, 보안 업데이트 및 기타 소프트웨어 업데이트가 포함됩니다. 갑작스러운 인프라 성능 저하를 해결하기 위해 계획되지 않은 유지 관리를 수행합니다. Standard 브로커와 Express 브로커에 대한 유지 관리를 수행하지만 환경은 다릅니다.
## Standard 브로커에 대한 패치 적용
Standard 브로커에 대한 업데이트는 [모범 사례](bestpractices.md)를 따르는 경우 애플리케이션의 쓰기 및 읽기에 영향을 주지 않습니다.
Amazon MSK는 소프트웨어에 대한 롤링 업데이트를 사용하여 클러스터의 고가용성을 유지합니다. 이 프로세스 중에 브로커는 한 번에 하나씩 재부팅되고 Kafka는 리더십을 다른 온라인 브로커로 자동으로 이동합니다. 에서 AWS Management Console 또는 `DescribeClusterOperation` 및 `ListClusterOperations` APIs를 통해 클러스터 작업을 볼 때 이러한 유지 관리 작업은 작업 유형이 인 상태로 표시됩니다`SECURITY_PATCHING`. Kafka 클라이언트에는 파티션의 리더십 변화를 자동으로 감지하고 MSK 클러스터에 데이터를 계속 쓰고 읽을 수 있는 메커니즘이 내장되어 있습니다. 패치 적용 중을 포함하여 클러스터를 항상 원활하게 작동하려면 [Apache Kafka 클라이언트의 모범 사례](bestpractices-kafka-client.md) 섹션을 따르세요.
브로커가 오프라인 상태가 된 후 클라이언트에서 일시적인 연결 해제 오류가 표시되는 것은 정상입니다. 또한 짧은 기간(최대 2분이며 일반적으로 더 짧음) 동안 p99 읽기 및 쓰기 지연 시간(일반적으로 높은 밀리초, 최대 약 2초)의 어느 정도 급증도 관찰할 수 있습니다. 이러한 스파이크는 예상되며 클라이언트가 새 리더 브로커에 다시 연결해도 발생합니다. 이는 생산 또는 소비에 영향을 미치지 않으며 재연결 후 이 문제는 해결됩니다. 자세한 내용은 [오프라인 및 클라이언트 장애 조치 브로커](https://docs.aws.amazon.com/msk/latest/developerguide/troubleshooting-offlinebroker-clientfailover.html)를 참조하세요.
또한 종료된 브로커의 파티션은 더 이상 데이터를 복제하지 않으므로 예상되는 `UnderReplicatedPartitions` 지표가 증가하는 것을 확인할 수 있습니다. 이는 다른 브로커에서 호스팅되는 이러한 파티션에 대한 복제본이 이제 요청을 처리하고 있으므로 애플리케이션의 쓰기 및 읽기에 영향을 주지 않습니다.
소프트웨어 업데이트 후 브로커가 다시 온라인 상태가 되면 오프라인 상태일 때 생성된 메시지를 '확인'해야 합니다. 확인 중에 볼륨 처리량 및 CPU 사용량이 증가하는 것을 관찰할 수도 있습니다. 이러한 증가는 브로커에 충분한 CPU, 메모리, 네트워크 및 볼륨 리소스가 있는 경우 클러스터에 대한 쓰기 및 읽기에는 영향을 미치지 않습니다.
## Express 브로커에 대한 패치 적용
Express 브로커에는 유지 관리 기간이 없습니다. Amazon MSK는 시간 분산 방식으로 클러스터를 지속적으로 자동 업데이트합니다. 즉, 한 달 동안 간헐적이고 단수적인 브로커 재부팅을 예상할 수 있습니다. 이렇게 하면 클러스터 전체의 일회성 유지 관리 기간에 계획이나 조정을 할 필요가 없습니다. 항상 그렇듯이 브로커 재부팅 중에는 리더십이 요청을 계속 처리하는 다른 브로커로 변경되기 때문에 트래픽이 중단되지 않습니다. 에서 AWS Management Console 또는 `DescribeClusterOperation` 및 `ListClusterOperations` APIs를 통해 클러스터 작업을 볼 때 이러한 유지 관리 작업은 작업 유형이 인 상태로 표시됩니다`BROKER_UPDATE`.
Express 브로커는 유지 관리 중에 발생할 수 있는 로드 변경에 대해 클러스터를 복원할 수 있도록 모범 사례 설정 및 가드레일로 구성되어 제공됩니다. Amazon MSK는 클러스터 오버로드로 인해 브로커 재시작 중에 발생할 수 있는 문제를 완화하기 위해 Express 브로커에 처리량 할당량을 설정합니다. 이러한 개선으로 인해 Express 브로커를 사용할 때 사전 알림, 계획 및 유지 관리 기간이 필요하지 않습니다.
Express 브로커는 항상 세 가지 방법으로 데이터를 복제하므로 재부팅 중에 클라이언트가 자동으로 장애 조치를 수행합니다. 복제 인수가 1 또는 2로 설정되어 있기 때문에 주제를 사용할 수 없게 되는 문제에 대해 걱정할 필요가 없습니다. 또한 다시 시작된 Express 브로커를 따라잡는 것이 표준 브로커보다 빠릅니다. Express 브로커의 패치 적용 속도가 빨라지면 클러스터에 대해 예약한 컨트롤 플레인 활동에 대한 계획 중단이 최소화됩니다.
모든 Apache Kafka 애플리케이션과 마찬가지로 Express 브로커에 연결하는 클라이언트에 대한 공유 클라이언트-서버 계약이 여전히 있습니다. 브로커 간의 리더십 장애 조치를 처리하도록 클라이언트를 구성하는 것은 여전히 중요합니다. 패치 적용 중을 포함하여 클러스터를 항상 원활하게 작동하려면 [Apache Kafka 클라이언트의 모범 사례](bestpractices-kafka-client.md) 섹션을 따르세요. 브로커가 다시 시작된 후 [클라이언트에서 일시적인 연결 해제 오류](troubleshooting-offlinebroker-clientfailover.md)가 표시되는 것은 정상입니다. 팔로워 브로커가 파티션 리더십을 맡게 되므로 이는 생산 및 소비에 영향을 주지 않습니다. Apache Kafka 클라이언트는 자동으로 장애 조치를 수행하고 새 리더 브로커에 요청을 보내기 시작합니다.
# 브로커 오프라인 및 클라이언트 장애 조치
Kafka는 오프라인 브로커를 허용합니다. 모범 사례에 따라 정상적이고 균형 잡힌 클러스터의 단일 오프라인 브로커는 영향을 주거나 생산 또는 소비 실패를 초래하지 않습니다. 다른 브로커가 파티션 리더십을 인수하고 Kafka 클라이언트 lib가 자동으로 장애 조치를 취하고 새 리더 브로커에게 요청을 보내기 시작하기 때문입니다.
**클라이언트 서버 계약**
따라서 클라이언트 라이브러리와 서버 측 동작 간의 공유 계약이 발생합니다. 서버는 하나 이상의 새 리더를 성공적으로 할당해야 하며 클라이언트는 적시에 새로운 리더에게 요청을 보내도록 브로커를 변경해야 합니다.
Kafka는 예외를 사용하여 이 흐름을 제어합니다.
**예제 절차**
1. 브로커 A가 오프라인 상태가 됩니다.
1. Kafka 클라이언트에서 예외(일반적으로 네트워크 연결 해제 또는 not\$1leader\$1for\$1partition)를 수신합니다.
1. 이러한 예외는 Kafka 클라이언트에서 메타데이터를 업데이트하여 최신 리더에 대해 인식할 수 있도록 합니다.
1. Kafka 클라이언트는 다른 브로커의 새로운 파티션 리더에게 요청을 다시 보냅니다.
이 프로세스는 일반적으로 판매된 Java 클라이언트 및 기본 구성에서 2초 미만이 걸립니다. 클라이언트 측 오류는 상세화되고 반복적이지만 ‘WARN’ 레벨로 표시된 정도의 우려의 대상이 아닙니다.
**예제: 예외 1**
`10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Got error produce response with correlation id 864845 on topic-partition msk-test-topic-1-0, retrying (2147483646 attempts left). Error: NETWORK_EXCEPTION. Error Message: Disconnected from node 2`
**예제: 예외 2**
`10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Received invalid metadata error in produce request on partition msk-test-topic-1-41 due to org.apache.kafka.common.errors.NotLeaderOrFollowerException: For requests intended only for the leader, this error indicates that the broker is not the current leader. For requests intended for any replica, this error indicates that the broker is not a replica of the topic partition.. Going to request metadata update now"`
Kafka 클라이언트는 일반적으로 1초\$13초 이내에 이러한 오류를 자동으로 해결합니다. 이는 클라이언트 측 지표에서 p99의 생산/소비 지연 시간(일반적으로 100초대의 높은 밀리초)으로 표시됩니다. 이 시간보다 길면 일반적으로 클라이언트 구성 또는 서버 측 컨트롤러 로드에 문제가 있음을 나타냅니다. 문제 해결 섹션을 참조하세요.
성공적인 장애 조치는 트래픽 및 리더십이 예상대로 이동했음을 입증하는 다른 브로커에 대한 `BytesInPerSec` 및 `LeaderCount` 지표 증가를 확인하여 알아볼 수 있습니다. 또한 복제본이 종료 브로커에서 오프라인 상태일 때 예상되는 `UnderReplicatedPartitions` 지표 증가도 볼 수 있습니다.
**문제 해결**
클라이언트-서버 계약을 위반하면 위 흐름이 중단될 수 있습니다. 가장 일반적인 문제의 이유는 다음과 같습니다.
+ Kafka 클라이언트 lib의 잘못된 구성 또는 잘못된 사용
+ 타사 클라이언트 lib를 사용하는 예기치 않은 기본 동작 및 버그
+ 오버로드된 컨트롤러로 인해 파티션 리더 할당 속도 감소
+ 새로운 컨트롤러가 선택되어 파티션 리더 할당 속도 감소
리더십 장애 조치를 처리하기 위한 올바른 동작을 보장하려면 다음을 수행하는 것이 좋습니다.
+ 느린 리더십 할당을 방지하기 위해 컨트롤러 브로커를 적절하게 조정하려면 서버 측 [모범 사례](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html)를 따라야 합니다.
+ 클라이언트가 장애 조치를 처리하도록 하려면 클라이언트 라이브러리에서 재시도가 활성화되어 있어야 합니다.
+ 연결/요청 급증을 방지하려면 클라이언트 라이브러리에 retry.backoff.ms 구성(기본값 100)이 있어야 합니다.
+ 클라이언트 라이브러리에서 request.timeout.ms 및 delivery.timeout.ms 애플리케이션의 SLA와 일치하는 값으로 설정해야 합니다. 값이 높을수록 특정 장애 유형에 대한 장애 조치가 느려집니다.
+ 클라이언트 라이브러리에서 초기 검색에 대한 가용성 영향을 방지하기 위해 boottrap.servers에 최소 3개의 무작위 브로커가 포함되어 있는지 확인해야 합니다.
+ 일부 클라이언트 라이브러리는 다른 클라이언트 라이브러리보다 수준이 낮으며 애플리케이션 개발자가 재시도 로직 및 예외 처리 자체를 구현할 것으로 기대합니다. 사용 예제는 클라이언트 lib 관련 설명서를 참조하고 올바른 재연결/재시도 로직을 따라야 합니다.
+ 생성, 성공한 요청 수 및 재시도할 수 없는 오류 수에 대한 클라이언트 측 지연 시간을 모니터링하는 것이 좋습니다.
+ 이전 타사 Golang 및 Ruby 라이브러리는 생산 및 소비 요청이 영향을 받지 않음에도 불구하고 전체 브로커 오프라인 기간 동안 계속 상세화되는 것으로 관찰되었습니다. 로그에 실제 영향과 노이즈가 있는지 확인하려면 요청 지표 외에 성공 및 오류에 대한 비즈니스 수준 지표를 항상 모니터링하는 것이 좋습니다.
+ network/not\$1leader에 대한 일시적 예외는 일반적이고 영향을 미치지 않으며 kafka 프로토콜의 일부로 예상되므로 고객은 이 예외에 대해 불안해 하지 않아도 됩니다.
+ UnderReplicatedPartitions는 일반적이고 영향을 미치지 않으며 단일 오프라인 브로커 중에 예상되므로 고객은 이에 대해 불안해 하지 않아도 됩니다.
# Amazon MSK의 보안
의 클라우드 보안 AWS 이 최우선 순위입니다. AWS 고객은 보안에 가장 민감한 조직의 요구 사항을 충족하도록 구축된 데이터 센터 및 네트워크 아키텍처의 이점을 누릴 수 있습니다.
보안은 AWS 와 사용자 간의 공동 책임입니다. [공동 책임 모델](https://aws.amazon.com/compliance/shared-responsibility-model/)은 이 사항을 클라우드*의* 보안 및 클라우드 *내* 보안으로 설명합니다.
+ **클라우드 보안 **- AWS 는 AWS 클라우드에서 AWS 서비스를 실행하는 인프라를 보호할 책임이 있습니다. AWS 또한는 안전하게 사용할 수 있는 서비스를 제공합니다. 타사 감사자는 [AWS 규정 준수 프로그램](https://aws.amazon.com/compliance/programs/) 일환으로 보안의 효과를 정기적으로 테스트하고 확인합니다. Amazon Managed Streaming for Apache Kafka에 적용되는 규정 준수 프로그램에 대해 알아보려면 [규정 준수 프로그램별 범위 내 Amazon Web Services](https://aws.amazon.com/compliance/services-in-scope/)를 참조하세요.
+ **클라우드의 보안** - 사용자의 책임은 사용하는 AWS 서비스에 따라 결정됩니다. 또한 귀하는 데이터의 민감도, 회사 요구 사항, 관련 법률 및 규정을 비롯한 기타 요소에 대해서도 책임이 있습니다.
이 설명서는 Amazon MSK를 사용할 때 공동 책임 모델을 적용하는 방법을 이해하는 데 도움이 됩니다. 다음 주제에서는 보안 및 규정 준수 목표를 충족하도록 Amazon MSK를 구성하는 방법을 설명합니다. 또한 Amazon MSK 리소스를 모니터링하고 보호하는 데 도움이 되는 다른 Amazon Web Services를 사용하는 방법도 알아봅니다.
**Topics**
+ [Amazon Managed Streaming for Apache Kafka의 데이터 보호](data-protection.md)
+ [Amazon MSK API에 대한 인증 및 권한 부여](security-iam.md)
+ [Apache Kafka API에 대한 인증 및 권한 부여](kafka_apis_iam.md)
+ [Amazon MSK 클러스터의 보안 그룹 변경](change-security-group.md)
+ [Amazon MSK 클러스터의 Apache ZooKeeper 노드에 대한 액세스 제어](zookeeper-security.md)
+ [Amazon Managed Streaming for Apache Kafka에 대한 규정 준수 검증](MSK-compliance.md)
+ [Amazon Managed Streaming for Apache Kafka의 복원력](disaster-recovery-resiliency.md)
+ [Amazon Managed Streaming for Apache Kafka의 인프라 보안](infrastructure-security.md)
# Amazon Managed Streaming for Apache Kafka의 데이터 보호
AWS [공동 책임 모델](https://aws.amazon.com/compliance/shared-responsibility-model/) Amazon Managed Streaming for Apache Kafka의 데이터 보호에 적용됩니다. 이 모델에 설명된 대로 AWS 는 모든를 실행하는 글로벌 인프라를 보호할 책임이 있습니다 AWS 클라우드. 사용자는 이 인프라에 호스팅되는 콘텐츠에 대한 통제 권한을 유지할 책임이 있습니다. 사용하는 AWS 서비스 의 보안 구성과 관리 태스크에 대한 책임도 사용자에게 있습니다. 데이터 프라이버시에 관한 자세한 내용은 [데이터 프라이버시 FAQ](https://aws.amazon.com/compliance/data-privacy-faq/)를 참조하세요. 유럽의 데이터 보호에 대한 자세한 내용은 *AWS 보안 블로그*의 [AWS 공동 책임 모델 및 GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) 블로그 게시물을 참조하세요.
데이터 보호를 위해 자격 증명을 보호하고 AWS 계정 AWS IAM Identity Center 또는 AWS Identity and Access Management (IAM)를 사용하여 개별 사용자를 설정하는 것이 좋습니다. 이렇게 하면 개별 사용자에게 자신의 직무를 충실히 이행하는 데 필요한 권한만 부여됩니다. 또한 다음과 같은 방법으로 데이터를 보호하는 것이 좋습니다.
+ 각 계정에 다중 인증(MFA)을 사용합니다.
+ SSL/TLS를 사용하여 AWS 리소스와 통신합니다. TLS 1.2는 필수이며 TLS 1.3을 권장합니다.
+ 를 사용하여 API 및 사용자 활동 로깅을 설정합니다 AWS CloudTrail. CloudTrail 추적을 사용하여 AWS 활동을 캡처하는 방법에 대한 자세한 내용은 *AWS CloudTrail 사용 설명서*의 [ CloudTrail 추적 작업을](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) 참조하세요.
+ 내의 모든 기본 보안 제어와 함께 AWS 암호화 솔루션을 사용합니다 AWS 서비스.
+ Amazon S3에 저장된 민감한 데이터를 검색하고 보호하는 데 도움이 되는 Amazon Macie와 같은 고급 관리형 보안 서비스를 사용합니다.
+ 명령줄 인터페이스 또는 API를 AWS 통해에 액세스할 때 FIPS 140-3 검증 암호화 모듈이 필요한 경우 FIPS 엔드포인트를 사용합니다. 사용 가능한 FIPS 엔드포인트에 대한 자세한 내용은 [연방 정보 처리 표준(FIPS) 140-3](https://aws.amazon.com/compliance/fips/)을 참조하세요.
고객의 이메일 주소와 같은 기밀 정보나 중요한 정보는 태그나 **이름** 필드와 같은 자유 형식 텍스트 필드에 입력하지 않는 것이 좋습니다. 여기에는 Amazon MSK 또는 기타 AWS 서비스 에서 콘솔 AWS CLI, API 또는 AWS SDKs를 사용하여 작업하는 경우가 포함됩니다. 이름에 사용되는 태그 또는 자유 형식 텍스트 필드에 입력하는 모든 데이터는 청구 또는 진단 로그에 사용될 수 있습니다. 외부 서버에 URL을 제공할 때 해당 서버에 대한 요청을 검증하기 위해 자격 증명을 URL에 포함해서는 안 됩니다.
**Topics**
+ [Amazon MSK 암호화](msk-encryption.md)
+ [Amazon MSK 암호화 시작하기](msk-working-with-encryption.md)
+ [인터페이스 VPC 엔드포인트와 함께 Amazon MSK API 사용](privatelink-vpc-endpoints.md)
# Amazon MSK 암호화
Amazon MSK는 엄격한 데이터 관리 요구 사항을 충족하는 데 사용할 수 있는 데이터 암호화 옵션을 제공합니다. Amazon MSK가 암호화에 사용하는 인증서는 13개월마다 갱신해야 합니다. Amazon MSK는 모든 클러스터에 대해 해당 인증서를 자동으로 갱신합니다. Amazon MSK가 인증서 업데이트 작업을 시작할 때 Express 브로커 클러스터는 `ACTIVE` 상태를 유지합니다. Standard 브로커 클러스터의 경우 Amazon MSK는 인증서 업데이트 작업을 시작할 때 클러스터의 상태를 `MAINTENANCE`로 설정합니다. 업데이트가 완료되면 MSK는 클러스터의 상태를 다시 `ACTIVE`로 설정합니다. 클러스터가 인증서 업데이트 작업을 진행하는 동안 계속해서 데이터를 생성하고 사용할 수 있지만 해당 클러스터에 대한 업데이트 작업은 수행할 수 없습니다.
## 저장 시 Amazon MSK 암호화
Amazon MSK는 [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/)(KMS)와 통합되어 투명한 서버 측 암호화 기능을 제공합니다. Amazon MSK는 항상 저장 데이터를 암호화합니다. MSK 클러스터를 생성하는 경우 Amazon MSK가 저장 데이터를 암호화하는 데 사용할 AWS KMS key 를 지정할 수 있습니다. KMS 키를 지정하지 않으면 Amazon MSK에서 [AWS 관리형 키](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk)를 생성하고 사용자를 대신하여 사용합니다. KMS 키에 대한 자세한 내용은 *AWS Key Management Service 개발자 가이드*의 [AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys) 섹션을 참조하십시오.
## 전송 중 Amazon MSK 암호화
Amazon MSK는 TLS 1.2를 사용합니다. 기본적으로 MSK 클러스터의 브로커 간에 전송 중인 데이터를 암호화합니다. 클러스터를 생성할 때 이 기본값을 재정의할 수 있습니다.
클라이언트와 브로커 간 통신의 경우 다음 세 가지 설정 중 하나를 지정해야 합니다.
+ TLS 암호화 데이터만 허용합니다. 기본 설정입니다.
+ 일반 텍스트와 TLS 암호화 데이터를 모두 허용합니다.
+ 일반 텍스트 데이터만 허용합니다.
Amazon MSK 브로커는 퍼블릭 AWS Certificate Manager 인증서를 사용합니다. 따라서 Amazon Trust Services를 신뢰하는 모든 트러스트 스토어는 Amazon MSK 브로커의 인증서도 신뢰합니다.
전송 중 암호화를 활성화하는 것이 좋지만 이 경우 CPU 오버헤드와 몇 밀리초의 지연 시간이 추가될 수 있습니다. 그러나 대부분의 사용 사례는 이러한 차이에 민감하지 않으며, 클러스터, 클라이언트, 사용 프로필 구성에 따라 영향을 미치는 정도는 달라집니다.
# Amazon MSK 암호화 시작하기
MSK 클러스터를 생성할 때 JSON 형식으로 암호화 설정을 지정할 수 있습니다. 다음은 예입니다.
```
{
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "arn:aws:kms:us-east-1:123456789012:key/abcdabcd-1234-abcd-1234-abcd123e8e8e"
},
"EncryptionInTransit": {
"InCluster": true,
"ClientBroker": "TLS"
}
}
```
`DataVolumeKMSKeyId`의 경우 [고객 관리형 키](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)를 지정하거나 계정의 MSK용 AWS 관리형 키 (`alias/aws/kafka`)를 지정할 수 있습니다. 를 지정하지 않으면 `EncryptionAtRest`Amazon MSK는 여전히에서 저장 데이터를 암호화합니다 AWS 관리형 키. 클러스터에서 사용 중인 키를 확인하려면 `GET` 요청을 보내거나 `DescribeCluster` API 작업을 호출합니다.
`EncryptionInTransit`의 경우 `InCluster`의 기본값은 true입니다. 그러나 브로커 간에 데이터가 전달될 때 Amazon MSK가 암호화하지 않도록 하려면 이를 false로 설정할 수 있습니다.
클라이언트와 브로커 사이에 전송되는 데이터에 암호화 모드를 지정하려면 `ClientBroker`를 `TLS`, `TLS_PLAINTEXT` 또는 `PLAINTEXT`의 세 가지 값 중 하나로 설정합니다.
**Topics**
+ [Amazon MSK 클러스터를 생성할 때 암호화 설정 지정](msk-working-with-encryption-cluster-create.md)
+ [Amazon MSK TLS 암호화 테스트](msk-working-with-encryption-test-tls.md)
# Amazon MSK 클러스터를 생성할 때 암호화 설정 지정
이 프로세스는 Amazon MSK 클러스터를 생성할 때 암호화 설정을 지정하는 방법을 설명합니다.
**클러스터를 생성할 때 암호화 설정 지정**
1. 이전 예제의 내용을 파일에 저장하고 파일에 원하는 이름을 지정합니다. 예를 들어, `encryption-settings.json`이라고 지정합니다.
1. `create-cluster` 명령을 실행하고 `encryption-info` 옵션을 사용하여 구성 JSON을 저장한 파일을 가리킵니다. 다음은 예입니다. *\$1YOUR MSK VERSION\$1*을 Apache Kafka 클라이언트 버전과 일치하는 버전으로 변경합니다. MSK 클러스터 버전을 찾는 방법에 대한 자세한 내용은 [MSK 클러스터 버전 확인](create-topic.md#find-msk-cluster-version) 섹션을 참조하세요. MSK 클러스터 버전과 다른 Apache Kafka 클라이언트 버전을 사용하면 Apache Kafka 데이터 손상, 손실, 가동 중지가 발생할 수 있습니다.
```
aws kafka create-cluster --cluster-name "ExampleClusterName" --broker-node-group-info file://brokernodegroupinfo.json --encryption-info file://encryptioninfo.json --kafka-version "{YOUR MSK VERSION}" --number-of-broker-nodes 3
```
다음은 이 명령을 실행한 후 성공적인 응답의 예입니다.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:123456789012:cluster/SecondTLSTest/abcdabcd-1234-abcd-1234-abcd123e8e8e",
"ClusterName": "ExampleClusterName",
"State": "CREATING"
}
```
# Amazon MSK TLS 암호화 테스트
이 프로세스는 Amazon MSK에서 TLS 암호화를 테스트하는 방법을 설명합니다.
**TLS 암호화를 테스트하려면**
1. [3단계: 클라이언트 머신 생성](create-client-machine.md)의 지침에 따라 클라이언트 머신을 만듭니다.
1. 클라이언트 머신에 Apache Kafka를 설치합니다.
1. 이 예제에서는 JVM 트러스트스토어를 사용하여 MSK 클러스터와 통신합니다. 이렇게 하려면 먼저 클라이언트 머신에 `/tmp`라는 폴더를 만듭니다. 그런 다음 Apache Kafka 설치 폴더인 `bin`으로 이동하여 다음 명령을 실행하십시오. (JVM 경로는 다를 수 있습니다.)
```
cp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64/jre/lib/security/cacerts /tmp/kafka.client.truststore.jks
```
1. 클라이언트 머신의 Apache Kafka 설치 폴더인 `bin`에 있는 동안 다음 내용으로 `client.properties`라는 텍스트 파일을 만듭니다.
```
security.protocol=SSL
ssl.truststore.location=/tmp/kafka.client.truststore.jks
```
1. 가 AWS CLI 설치된 시스템에서 다음 명령을 실행하여 *clusterARN*을 클러스터의 ARN으로 바꿉니다.
```
aws kafka get-bootstrap-brokers --cluster-arn clusterARN
```
성공적인 결과는 다음과 같습니다. 다음 단계에 필요하므로 이 결과를 저장하십시오.
```
{
"BootstrapBrokerStringTls": "a-1.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123,a-3.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123,a-2.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123"
}
```
1. 다음 명령을 실행하여 *BootstrapBrokerStringTls*를 이전 단계에서 얻은 브로커 엔드포인트 중 하나로 변경합니다.
```
/bin/kafka-console-producer.sh --broker-list BootstrapBrokerStringTls --producer.config client.properties --topic TLSTestTopic
```
1. 새 명령 창을 열고 동일한 클라이언트 머신에 연결합니다. 그러면 다음 명령을 실행하여 콘솔 소비자를 생성합니다.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringTls --consumer.config client.properties --topic TLSTestTopic
```
1. 생산자 창에서 문자 메시지와 반환을 입력하고 소비자 창에서 동일한 메시지를 찾습니다. Amazon MSK는 이 메시지를 전송하는 동안 암호화했습니다.
암호화된 데이터로 작업하도록 Apache Kafka 클라이언트를 구성하는 방법에 대한 자세한 내용은 [Kafka 클라이언트 구성](https://kafka.apache.org/documentation/#security_configclients)을 참조하십시오.
# 인터페이스 VPC 엔드포인트와 함께 Amazon MSK API 사용
AWS PrivateLink로 구동되는 인터페이스 VPC 엔드포인트를 사용하여 Amazon VPC와 Amazon MSK APIs이 Amazon 네트워크를 벗어나지 않도록 할 수 있습니다. 인터페이스 VPC 엔드포인트에는 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 AWS Direct Connect 연결이 필요하지 않습니다. [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)는 Amazon VPC의 프라이빗 IPs와 함께 탄력적 네트워크 인터페이스를 사용하여 AWS 서비스 간에 프라이빗 통신을 가능하게 하는 AWS 기술입니다. 자세한 내용은 [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 및 [인터페이스 VPC 엔드포인트(AWS PrivateLink)를 참조하세요](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint).
애플리케이션은 AWS PrivateLink를 사용하여 Amazon MSK Provisioned 및 MSK Connect APIs에 연결할 수 있습니다. 시작하려면 Amazon VPC 리소스의 트래픽이 인터페이스 VPC 엔드포인트를 통해 흐름을 시작하도록 Amazon MSK API에 대한 인터페이스 VPC 엔드포인트를 생성합니다. FIPS 지원 인터페이스 VPC 엔드포인트는 미국 리전에서 사용할 수 있습니다. 자세한 내용은 [인터페이스 엔드포인트 생성](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint)을 참조하세요.
이 기능을 사용하면 Apache Kafka 클라이언트가 인터넷을 순회하여 연결 문자열을 검색하지 않고도 연결 문자열을 동적으로 가져와 MSK Provisioned 또는 MSK Connect 리소스와 연결할 수 있습니다.
인터페이스 VPC 엔드포인트를 생성할 때 다음 서비스 이름 엔드포인트 중 하나를 선택합니다.
**MSK Provisioned의 경우:**
+ 다음 서비스 이름 엔드포인트는 새 연결에 더 이상 지원되지 않습니다.
+ com.amazonaws.region.kafka
+ com.amazonaws.region.kafka-fips(FIPS 지원)
+ IPv4 및 IPv6 트래픽을 모두 지원하는 듀얼 스택 엔드포인트 서비스는 다음과 같습니다.
+ aws.api.region.kafka-api
+ aws.api.region.kafka-api-fips(FIPS 지원)
듀얼 스택 엔드포인트를 설정하려면 [듀얼 스택 및 FIPS 엔드포인트](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html) 지침을 따라야 합니다.
여기서 region은 리전 이름입니다. MSK Provisioned 호환 API를 사용하려면 이 서비스 이름을 선택합니다. 자세한 내용은 *https://docs.aws.amazon.com/msk/1.0/apireference/*의 [작업](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html)을 참조하세요.
**MSK Connect의 경우:**
+ com.amazonaws.region.kafkaconnect
여기서 region은 리전 이름입니다. MSK Connect 호환 API를 사용하려면 이 서비스 이름을 선택합니다. 자세한 내용은 *Amazon Connect API 참조*의 [작업](https://docs.aws.amazon.com/MSKC/latest/mskc/API_Operations.html)을 참조하세요.
인터페이스 VPC 엔드포인트를 생성하는 단계별 지침을 비롯한 자세한 내용은 *AWS PrivateLink 설명서*의 [인터페이스 엔드포인트 생성](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint)을 참조하세요.
## Amazon MSK Provisioned 또는 MSK Connect API의 VPC 엔드포인트에 대한 액세스 제어
VPC 엔드포인트 정책을 사용하면 정책을 VPC 엔드포인트에 연결하거나 IAM 사용자, 그룹 또는 역할에 연결된 정책의 추가 필드를 사용하여 액세스를 제어할 수 있습니다. 이를 통해 지정된 VPC 엔드포인트를 통해서만 발생하도록 액세스를 제한할 수 있습니다. 적절한 예제 정책을 사용하여 MSK Provisioned 또는 MSK Connect 서비스에 대한 액세스 권한을 정의합니다.
엔드포인트를 생성할 때 정책을 연결하지 않으면 Amazon VPC는 서비스에 대한 전체 액세스를 허용하는 기본 정책을 자동으로 연결합니다. 엔드포인트 정책은 IAM ID 기반 정책 또는 서비스별 정책을 재정의하거나 대체하지 않습니다. 이는 엔드포인트에서 지정된 서비스로의 액세스를 제어하기 위한 별도의 정책입니다.
자세한 내용은 *AWS PrivateLink 설명서*의 [VPC 엔드포인트를 통해 서비스에 대한 액세스 제어](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)를 참조하세요.
------
#### [ MSK Provisioned — VPC policy example ]
**읽기 전용 액세스**
이 샘플 정책은 VPC 엔드포인트에 연결할 수 있습니다. 자세한 내용은 Amazon VPC 리소스에 대한 액세스 제어를 참조하십시오. 연결된 VPC 엔드포인트를 통해서만 작업을 나열하고 설명할 수 있도록 작업을 제한합니다.
```
{
"Statement": [
{
"Sid": "MSKReadOnly",
"Principal": "*",
"Action": [
"kafka:List*",
"kafka:Describe*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
**MSK Provisioned - VPC 엔드포인트 정책 예제**
특정 MSK 클러스터에 대한 액세스 제한
이 샘플 정책은 VPC 엔드포인트에 연결할 수 있습니다. 연결된 VPC 엔드포인트를 통한 특정 Kafka 클러스터에 대한 액세스를 제한합니다.
```
{
"Statement": [
{
"Sid": "AccessToSpecificCluster",
"Principal": "*",
"Action": "kafka:*",
"Effect": "Allow",
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster"
}
]
}
```
------
#### [ MSK Connect — VPC endpoint policy example ]
**커넥터 나열 및 새 커넥터 생성**
다음은 MSK Connect에 대한 엔드포인트 정책의 예입니다. 이 정책은 지정된 역할이 커넥터를 나열하고 새 커넥터를 생성하도록 허용합니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "MSKConnectPermissions",
"Effect": "Allow",
"Action": [
"kafkaconnect:ListConnectors",
"kafkaconnect:CreateConnector"
],
"Resource": "*",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/MyMSKConnectExecutionRole"
]
}
}
]
}
```
**MSK Connect — VPC 엔드포인트 정책 예제**
지정된 VPC에 있는 특정 IP 주소의 요청만 허용
다음 예제는 지정된 VPC의 지정된 IP 주소에서 들어오는 요청만 성공하도록 허용하는 정책을 보여 줍니다. 다른 IP 주소에서 들어오는 요청은 실패합니다.
```
{
"Statement": [
{
"Action": "kafkaconnect:*",
"Effect": "Allow",
"Principal": "*",
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:VpcSourceIp": "192.0.2.123"
},
"StringEquals": {
"aws:SourceVpc": "vpc-555555555555"
}
}
}
]
}
```
------
# Amazon MSK API에 대한 인증 및 권한 부여
AWS Identity and Access Management (IAM)는 관리자가 AWS 리소스에 대한 액세스를 안전하게 제어하는 데 도움이 AWS 서비스 되는 입니다. IAM 관리자는 Amazon MSK 리소스를 사용할 수 있도록 *인증*(로그인)하고 *권한을 부여*(권한 보유)할 수 있는 사용자를 제어합니다. IAM은 추가 비용 없이 사용할 수 AWS 서비스 있는 입니다.
**Topics**
+ [Amazon MSK와 IAM의 작동 방식](security_iam_service-with-iam.md)
+ [Amazon MSK ID 기반 정책 예제](security_iam_id-based-policy-examples.md)
+ [Amazon MSK의 서비스 연결 역할](using-service-linked-roles.md)
+ [AWS Amazon MSK에 대한 관리형 정책](security-iam-awsmanpol.md)
+ [Amazon MSK 자격 증명 및 액세스 문제 해결](security_iam_troubleshoot.md)
# Amazon MSK와 IAM의 작동 방식
IAM을 사용하여 Amazon MSK에 대한 액세스를 관리하기 전에 Amazon MSK에서 사용할 수 있는 IAM 기능을 이해해야 합니다. Amazon MSK 및 기타 AWS 서비스에서 IAM을 사용하는 방법을 전체적으로 알아보려면 *IAM 사용 설명서*의 [AWS IAM으로 작업하는 서비스를](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) 참조하세요.
**Topics**
+ [Amazon MSK ID 기반 정책](security_iam_service-with-iam-id-based-policies.md)
+ [Amazon MSK 리소스 기반 정책](security_iam_service-with-iam-resource-based-policies.md)
+ [Amazon MSK 태그 기반 권한 부여](security_iam_service-with-iam-tags.md)
+ [Amazon MSK IAM 역할](security_iam_service-with-iam-roles.md)
# Amazon MSK ID 기반 정책
IAM ID 기반 정책을 사용하면 허용되거나 거부되는 작업과 리소스뿐 아니라 작업이 허용되거나 거부되는 조건을 지정할 수 있습니다. Amazon MSK는 특정 작업, 리소스, 조건 키를 지원합니다. JSON 정책에서 사용하는 모든 요소에 대해 알고 싶다면 *IAM 사용 설명서*의 [IAM JSON 정책 요소 참조](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)를 참조하세요.
## Amazon MSK 자격 증명 기반 정책에 대한 작업
관리자는 AWS JSON 정책을 사용하여 누가 무엇에 액세스할 수 있는지 지정할 수 있습니다. 즉, 어떤 **보안 주체**가 어떤 **리소스**와 어떤 **조건**에서 **작업**을 수행할 수 있는지를 지정할 수 있습니다.
JSON 정책의 `Action`요소는 정책에서 액세스를 허용하거나 거부하는 데 사용할 수 있는 작업을 설명합니다. 연결된 작업을 수행할 수 있는 권한을 부여하기 위한 정책에 작업을 포함하세요.
Amazon MSK의 정책 작업은 작업 앞에 `kafka:` 접두사를 사용합니다. 예를 들어 누군가에게 Amazon MSK `DescribeCluster` API 작업으로 MSK 클러스터를 설명할 수 있는 권한을 부여하려면 정책에 `kafka:DescribeCluster` 작업을 포함하면 됩니다. 정책 문에는 `Action` 또는 `NotAction` 요소가 포함되어야 합니다. Amazon MSK는 이 서비스로 수행할 수 있는 태스크를 설명하는 자체 작업 세트를 정의합니다.
MSK 주제 APIs에 대한 정책 작업은 작업 앞에 `kafka-cluster` 접두사를 사용합니다. 단원을 참조하십시오[IAM 권한 부여 정책 작업 및 리소스의 의미](kafka-actions.md).
명령문 하나에 여러 태스크를 지정하려면 다음과 같이 쉼표로 구분합니다.
```
"Action": ["kafka:action1", "kafka:action2"]
```
와일드카드(\$1)를 사용하여 여러 작업을 지정할 수 있습니다. 예를 들어, `Describe`라는 단어로 시작하는 모든 작업을 지정하려면 다음 작업을 포함합니다.
```
"Action": "kafka:Describe*"
```
Amazon MSK 작업 목록을 보려면 *IAM 사용 설명서*에서 [Amazon Managed Streaming for Apache Kafka를 위한 작업, 리소스, 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonmanagedstreamingforapachekafka.html)를 참조하세요.
## Amazon MSK 자격 증명 기반 정책에 대한 리소스
관리자는 AWS JSON 정책을 사용하여 누가 무엇에 액세스할 수 있는지 지정할 수 있습니다. 즉, 어떤 **보안 주체**가 어떤 **리소스**와 어떤 **조건**에서 **작업**을 수행할 수 있는지를 지정할 수 있습니다.
`Resource` JSON 정책 요소는 작업이 적용되는 하나 이상의 객체를 지정합니다. 모범 사례에 따라 [Amazon 리소스 이름(ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)을 사용하여 리소스를 지정합니다. 리소스 수준 권한을 지원하지 않는 작업의 경우, 와일드카드(\$1)를 사용하여 해당 문이 모든 리소스에 적용됨을 나타냅니다.
```
"Resource": "*"
```
Amazon MSK 인스턴스 리소스의 ARN은 다음과 같습니다.
```
arn:${Partition}:kafka:${Region}:${Account}:cluster/${ClusterName}/${UUID}
```
ARN 형식에 대한 자세한 내용은 [Amazon 리소스 이름(ARNs) 및 AWS 서비스 네임스페이스를 참조하세요](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
예를 들어 문에서 `CustomerMessages` 인스턴스를 지정하려면 다음 ARN을 사용합니다.
```
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/CustomerMessages/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2"
```
특정 계정에 속하는 모든 인스턴스를 지정하려면 와일드카드(\$1)를 사용합니다.
```
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/*"
```
리소스 생성 태스크와 같은 일부 Amazon MSK 태스크는 특정 리소스에서 수행할 수 없습니다. 이러한 경우, 와일드카드(\$1)를 사용해야 합니다.
```
"Resource": "*"
```
단일 문에서 여러 리소스를 지정하려면 ARN을 쉼표로 구분합니다.
```
"Resource": ["resource1", "resource2"]
```
Amazon MSK 리소스 유형과 해당 ARN의 목록을 보려면 *IAM 사용 설명서*에서 [Amazon Managed Streaming for Apache Kafka로 정의된 리소스](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-resources-for-iam-policies)를 참조하세요. 각 리소스의 ARN을 지정할 수 있는 작업을 알아보려면 [Amazon Managed Streaming for Apache Kafka에서 정의한 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-actions-as-permissions)을 참조하세요.
## Amazon MSK 자격 증명 기반 정책의 조건 키
관리자는 AWS JSON 정책을 사용하여 누가 무엇에 액세스할 수 있는지 지정할 수 있습니다. 즉, 어떤 **보안 주체**가 어떤 **리소스**와 어떤 **조건**에서 **작업**을 수행할 수 있는지를 지정할 수 있습니다.
`Condition` 요소는 정의된 기준에 따라 문이 실행되는 시기를 지정합니다. 같음(equals) 또는 미만(less than)과 같은 [조건 연산자](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)를 사용하여 정책의 조건을 요청의 값과 일치시키는 조건식을 생성할 수 있습니다. 모든 AWS 전역 조건 키를 보려면 *IAM 사용 설명서*의 [AWS 전역 조건 컨텍스트 키를](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) 참조하세요.
Amazon MSK는 자체 조건 키 세트를 정의하며 일부 전역 조건 키 사용도 지원합니다. 모든 AWS 전역 조건 키를 보려면 *IAM 사용 설명서*의 [AWS 전역 조건 컨텍스트 키를 참조하세요](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html).
Amazon MSK 조건 키 목록을 보려면 *IAM 사용 설명서*에서 [Amazon Managed Streaming for Apache Kafka를 위한 조건 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-policy-keys)를 참조하세요. 조건 키를 사용할 수 있는 작업과 리소스를 알아보려면 [Amazon Managed Streaming for Apache Kafka에서 정의한 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-actions-as-permissions)을 참조하세요.
## Amazon MSK 자격 증명 기반 정책의 예제
Amazon MSK ID 기반 정책 예제를 보려면 [Amazon MSK ID 기반 정책 예제](security_iam_id-based-policy-examples.md) 섹션을 참조하세요.
# Amazon MSK 리소스 기반 정책
Amazon MSK는 Amazon MSK 클러스터와 함께 사용할 수 있는 클러스터 정책(리소스 기반 정책이라고도 함)을 지원합니다. 클러스터 정책을 사용하여 Amazon MSK 클러스터에 대한 프라이빗 연결을 설정할 수 있는 크로스 계정 권한이 있는 IAM 주체를 정의할 수 있습니다. IAM 클라이언트 인증과 함께 사용하는 경우, 클러스터 정책을 사용하여 연결 클라이언트에 대한 Kafka 데이터 영역 권한을 세분화하여 정의할 수도 있습니다.
클러스터 정책에 지원되는 최대 크기는 20KB입니다.
클러스터 정책을 구성하는 방법의 예를 보려면 [2단계: MSK 클러스터에 클러스터 정책 연결](mvpc-cluster-owner-action-policy.md) 섹션을 참조하세요.
# Amazon MSK 태그 기반 권한 부여
Amazon MSK 클러스터에 태그를 연결할 수 있습니다. 태그에 근거하여 액세스를 제어하려면 `kafka:ResourceTag/key-name`, `aws:RequestTag/key-name`또는 `aws:TagKeys`조건 키를 사용하여 정책의 [조건 요소](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)에 태그 정보를 제공합니다. Amazon MSK 리소스 태그 지정에 대한 자세한 내용은 [Amazon MSK 클러스터에 태그 지정](msk-tagging.md) 섹션을 참조하세요.
태그를 통해서만 클러스터 액세스를 제어할 수 있습니다. 주제 및 소비자 그룹에 태그를 지정하려면 태그 없이 정책에 별도의 문을 추가해야 합니다.
클러스터에서 태그 기반으로 해당 클러스터에 대한 액세스를 제한하는 ID 기반 정책의 예를 보려면 [태그를 기반으로 Amazon MSK 클러스터에 액세스](security_iam_id-based-policy-examples-view-widget-tags.md) 섹션을 참조하세요.
ID 기반 정책의 조건을 사용하여 태그를 기반으로 Amazon MSK 리소스에 대한 액세스를 제어할 수 있습니다. 다음 예에서는 사용자가 클러스터를 설명하고, 부트스트랩 브로커를 가져오고, 브로커 노드를 나열, 업데이트, 삭제할 수 있도록 허용하는 정책을 보여줍니다. 그러나 이 정책은 클러스터 태그 `Owner`에 해당 사용자의 `username` 값이 있는 경우에만 권한을 부여합니다. 다음 정책의 두 번째 문은 클러스터의 주제에 대한 액세스를 허용합니다. 이 정책의 첫 번째 문은 주제 액세스를 승인하지 않습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessClusterIfOwner",
"Effect": "Allow",
"Action": [
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*",
"kafka:Delete*"
],
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/*"
]
}
]
}
```
------
# Amazon MSK IAM 역할
[IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)은 특정 권한이 있는 Amazon Web Services 계정 내의 엔터티입니다.
## Amazon MSK에서 임시 자격 증명 사용
임시 보안 인증을 사용하여 페더레이션을 통해 로그인하거나, IAM 역할을 맡거나, 교차 계정 역할을 맡을 수 있습니다. [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) 또는 [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)과 같은 AWS STS API 작업을 호출하여 임시 보안 자격 증명을 얻습니다.
Amazon MSK는 임시 보안 인증 정보 사용을 지원합니다.
## 서비스 연결 역할
[서비스 연결 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)을 사용하면 Amazon Web Services가 다른 서비스의 리소스에 액세스하여 사용자 대신 작업을 완료할 수 있습니다. 서비스 연결 역할은 IAM 계정에 나타나고 서비스가 소유합니다. 관리자는 서비스 연결 역할의 권한을 볼 수 있지만 편집할 수는 없습니다.
Amazon MSK는 서비스 연결 역할을 지원합니다. Amazon MSK 서비스 연결 역할 생성 또는 관리에 대한 자세한 내용은 [Amazon MSK의 서비스 연결 역할](using-service-linked-roles.md) 섹션을 참조하세요.
# Amazon MSK ID 기반 정책 예제
기본적으로 IAM 사용자 및 역할에는 Amazon MSK API 작업을 실행할 수 있는 권한이 없습니다. 관리자는 지정된 리소스에서 특정 API 태스크를 수행할 수 있는 권한을 사용자와 역할에게 부여하는 IAM 정책을 생성해야 합니다. 그런 다음 관리자는 해당 권한이 필요한 IAM 사용자 또는 그룹에 이러한 정책을 연결해야 합니다.
이러한 예제 JSON 정책 문서를 사용하여 IAM ID 기반 정책을 생성하는 방법을 알아보려면 *IAM 사용 설명서*의 [JSON 탭에서 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor)을 참조하세요.
**Topics**
+ [정책 모범 사례](security_iam_service-with-iam-policy-best-practices.md)
+ [사용자가 자신의 고유한 권한을 볼 수 있도록 허용](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [하나의 Amazon MSK 클러스터 액세스](security_iam_id-based-policy-examples-access-one-cluster.md)
+ [태그를 기반으로 Amazon MSK 클러스터에 액세스](security_iam_id-based-policy-examples-view-widget-tags.md)
# 정책 모범 사례
ID 기반 정책에 따라 계정에서 사용자가 Amazon MSK 리소스를 생성, 액세스 또는 삭제할 수 있는지 여부가 결정됩니다. 이 작업으로 인해 AWS 계정에 비용이 발생할 수 있습니다. ID 기반 정책을 생성하거나 편집할 때는 다음 지침과 권장 사항을 따르세요.
+ ** AWS 관리형 정책을 시작하고 최소 권한으로 전환 -** 사용자 및 워크로드에 권한 부여를 시작하려면 많은 일반적인 사용 사례에 대한 권한을 부여하는 *AWS 관리형 정책을* 사용합니다. 에서 사용할 수 있습니다 AWS 계정. 사용 사례에 맞는 AWS 고객 관리형 정책을 정의하여 권한을 추가로 줄이는 것이 좋습니다. 자세한 내용은 *IAM 사용 설명서*의 [AWS 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) 또는 [AWS 직무에 대한 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)을 참조하세요.
+ **최소 권한 적용** – IAM 정책을 사용하여 권한을 설정하는 경우, 작업을 수행하는 데 필요한 권한만 부여합니다. 이렇게 하려면 *최소 권한*으로 알려진 특정 조건에서 특정 리소스에 대해 수행할 수 있는 작업을 정의합니다. IAM을 사용하여 권한을 적용하는 방법에 대한 자세한 정보는 *IAM 사용 설명서*에 있는 [IAM의 정책 및 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)을 참조하세요.
+ **IAM 정책의 조건을 사용하여 액세스 추가 제한** – 정책에 조건을 추가하여 작업 및 리소스에 대한 액세스를 제한할 수 있습니다. 예를 들어, SSL을 사용하여 모든 요청을 전송해야 한다고 지정하는 정책 조건을 작성할 수 있습니다. AWS 서비스와 같은 특정를 통해 사용되는 경우 조건을 사용하여 서비스 작업에 대한 액세스 권한을 부여할 수도 있습니다 CloudFormation. 자세한 내용은 *IAM 사용 설명서*의 [IAM JSON 정책 요소: 조건](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)을 참조하세요.
+ **IAM Access Analyzer를 통해 IAM 정책을 확인하여 안전하고 기능적인 권한 보장** - IAM Access Analyzer에서는 IAM 정책 언어(JSON)와 모범 사례가 정책에서 준수되도록 새로운 및 기존 정책을 확인합니다. IAM Access Analyzer는 100개 이상의 정책 확인 항목과 실행 가능한 추천을 제공하여 안전하고 기능적인 정책을 작성하도록 돕습니다. 자세한 내용은 *IAM 사용 설명서*의 [IAM Access Analyzer에서 정책 검증](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)을 참조하세요.
+ **다중 인증(MFA) 필요 -**에서 IAM 사용자 또는 루트 사용자가 필요한 시나리오가 있는 경우 추가 보안을 위해 MFA를 AWS 계정켭니다. API 작업을 직접적으로 호출할 때 MFA가 필요하면 정책에 MFA 조건을 추가합니다. 자세한 내용은 *IAM 사용 설명서*의 [MFA를 통한 보안 API 액세스](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)를 참조하세요.
IAM의 모범 사례에 대한 자세한 내용은 *IAM 사용 설명서*의 [IAM의 보안 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)를 참조하세요.
# 사용자가 자신의 고유한 권한을 볼 수 있도록 허용
이 예제는 IAM 사용자가 자신의 사용자 ID에 연결된 인라인 및 관리형 정책을 볼 수 있도록 허용하는 정책을 생성하는 방법을 보여줍니다. 이 정책에는 콘솔에서 또는 AWS CLI 또는 AWS API를 사용하여 프로그래밍 방식으로이 작업을 완료할 수 있는 권한이 포함됩니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# 하나의 Amazon MSK 클러스터 액세스
이 예에서는 Amazon Web Services 계정의 IAM 사용자에게 클러스터 중 하나인 `purchaseQueriesCluster`에 대한 액세스 권한을 부여하려고 합니다. 이 정책은 사용자가 클러스터를 설명하고, 부트스트랩 브로커를 가져오고, 브로커 노드를 나열하고 업데이트할 수 있도록 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"UpdateCluster",
"Effect":"Allow",
"Action":[
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*"
],
"Resource":"arn:aws:kafka:us-east-1:012345678012:cluster/purchaseQueriesCluster/abcdefab-1234-abcd-5678-cdef0123ab01-2"
}
]
}
```
------
# 태그를 기반으로 Amazon MSK 클러스터에 액세스
ID 기반 정책의 조건을 사용하여 태그를 기반으로 Amazon MSK 리소스에 대한 액세스를 제어할 수 있습니다. 이 예에서는 사용자가 클러스터를 설명하고, 부트스트랩 브로커를 가져오고, 브로커 노드를 나열, 업데이트, 삭제할 수 있도록 허용하는 정책 생성 방법을 보여줍니다. 하지만 클러스터 태그 `Owner`가 해당 사용자의 사용자 이름 값을 가지고 있는 경우에만 권한이 부여됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessClusterIfOwner",
"Effect": "Allow",
"Action": [
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*",
"kafka:Delete*"
],
"Resource": "arn:aws:kafka:us-east-1:012345678012:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
}
]
}
```
------
이 정책을 계정의 IAM 사용자에게 연결할 수 있습니다. `richard-roe`라는 사용자가 MSK 클러스터를 업데이트하려고 시도하는 경우 클러스터에 `Owner=richard-roe` 또는 `owner=richard-roe` 태그를 지정해야 합니다. 그렇지 않으면 액세스가 거부됩니다. 조건 키 이름은 대소문자를 구분하지 않기 때문에 조건 태그 키 `Owner`는 `Owner` 및 `owner` 모두와 일치합니다. 자세한 정보는 *IAM 사용 설명서*의 [IAM JSON 정책 요소: 조건](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)을 참조하세요.
# Amazon MSK의 서비스 연결 역할
Amazon MSK는 AWS Identity and Access Management (IAM) [ 서비스 연결 역할을](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) 사용합니다. 서비스 연결 역할은 Amazon MSK에 직접 연결되는 고유한 유형의 IAM 역할입니다. 서비스 연결 역할은 Amazon MSK에서 사전 정의하며 서비스가 사용자를 대신하여 다른 AWS 서비스를 호출하는 데 필요한 모든 권한을 포함합니다.
서비스 연결 역할을 사용하면 필요한 권한을 수동으로 추가할 필요가 없으므로 Amazon MSK를 더 간편하게 설정할 수 있습니다. Amazon MSK는 서비스 연결 역할의 권한을 정의합니다. 달리 정의되지 않는 한, Amazon MSK만이 해당 역할을 맡을 수 있습니다. 정의된 권한에는 신뢰 정책과 권한 정책이 포함되며 이 권한 정책은 다른 IAM 엔터티에 연결할 수 없습니다.
서비스 연결 역할을 지원하는 다른 서비스에 대한 자세한 내용은 [IAM과 함께 작동하는 Amazon Web Services](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)를 참조하고 **서비스 연결 역할** 열에서 **예**로 표시된 서비스를 찾아보세요. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 **예(Yes)** 링크를 선택합니다.
**Topics**
+ [서비스 연결 역할 권한](slr-permissions.md)
+ [서비스 연결 역할 생성](create-slr.md)
+ [서비스 연결 역할 편집](edit-slr.md)
+ [서비스 연결 역할이 지원되는 리전](slr-regions.md)
# Amazon MSK에 대한 서비스 연결 역할 권한
Amazon MSK는 **AWSServiceRoleForKafka**라는 서비스 연결 역할을 사용합니다. Amazon MSK는 해당 역할을 사용하여 리소스에 액세스하고 다음과 같은 작업을 수행합니다.
+ `*NetworkInterface` – 고객 계정에서 네트워크 인터페이스를 생성하고 관리하여 고객 VPC의 클라이언트가 클러스터 브로커에 액세스할 수 있도록 합니다.
+ `*VpcEndpoints` -를 사용하여 고객 VPC의 클라이언트가 클러스터 브로커에 액세스할 수 있도록 하는 고객 계정의 VPC 엔드포인트를 관리합니다 AWS PrivateLink. Amazon MSK는 `DescribeVpcEndpoints`, `ModifyVpcEndpoint`, `DeleteVpcEndpoints`에 대한 권한을 사용합니다.
+ `secretsmanager` -를 사용하여 클라이언트 자격 증명을 관리합니다 AWS Secrets Manager.
+ `GetCertificateAuthorityCertificate` - 프라이빗 인증 기관의 인증서를 검색합니다.
+ `*Ipv6Addresses` - 고객 계정의 네트워크 인터페이스에 IPv6 주소를 할당 및 할당 해제하여 MSK 클러스터에 대한 IPv6 연결을 활성화합니다.
+ `ModifyNetworkInterfaceAttribute` - MSK 클러스터 연결을 위한 IPv6 설정을 구성하도록 고객 계정의 네트워크 인터페이스 속성을 수정합니다.
이 서비스 연결 역할은 관리형 정책 `KafkaServiceRolePolicy`에 연결됩니다. 이 정책에 대한 업데이트는 [KafkaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/KafkaServiceRolePolicy.html)를 참조하세요.
AWSServiceRoleForKafka 서비스 연결 역할은 역할을 수임하기 위해 다음 서비스를 신뢰합니다.
+ `kafka.amazonaws.com`
역할 권한 정책을 통해 Amazon MSK는 리소스에 대해 다음 작업을 완료할 수 있습니다.
IAM 엔터티(사용자, 그룹, 역할 등)가 서비스 연결 역할을 생성하고 편집하거나 삭제할 수 있도록 권한을 구성할 수 있습니다. 자세한 내용은 IAM 사용 설명서**의 [서비스 연결 역할 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) 섹션을 참조하세요.
# Amazon MSK에 대한 서비스 연결 역할 생성
서비스 연결 역할은 수동으로 생성할 필요가 없습니다. AWS CLI, 또는 AWS API에서 Amazon MSK 클러스터 AWS Management Console를 생성하면 Amazon MSK가 서비스 연결 역할을 생성합니다.
이 서비스 연결 역할을 삭제했다가 다시 생성해야 하는 경우 동일한 프로세스를 사용하여 계정에서 역할을 다시 생성할 수 있습니다. Amazon MSK 클러스터를 생성하는 경우 Amazon MSK에서 서비스 연결 역할을 다시 생성합니다.
# Amazon MSK에 대한 서비스 연결 역할 편집
Amazon MSK에서는 AWSServiceRoleForKafka 서비스 연결 역할을 편집하도록 허용하지 않습니다. 서비스 연결 역할을 생성한 후에는 다양한 개체가 역할을 참조할 수 있기 때문에 역할 이름을 변경할 수 없습니다. 하지만 IAM을 사용하여 역할의 설명을 편집할 수 있습니다. 자세한 내용은 IAM 사용 설명서**의 [서비스 연결 역할 편집](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)을 참조하세요.
# Amazon MSK 서비스 연결 역할에 대해 지원되는 리전
Amazon MSK는 서비스가 제공되는 모든 리전에서 서비스 연결 역할 사용을 지원합니다. 자세한 설명은 [AWS 리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html)를 참조하세요.
# AWS Amazon MSK에 대한 관리형 정책
AWS 관리형 정책은에서 생성하고 관리하는 독립 실행형 정책입니다 AWS. AWS 관리형 정책은 사용자, 그룹 및 역할에 권한 할당을 시작할 수 있도록 많은 일반적인 사용 사례에 대한 권한을 제공하도록 설계되었습니다.
AWS 관리형 정책은 모든 AWS 고객이 사용할 수 있으므로 특정 사용 사례에 대해 최소 권한을 부여하지 않을 수 있습니다. 사용 사례에 고유한 [고객 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)을 정의하여 권한을 줄이는 것이 좋습니다.
AWS 관리형 정책에 정의된 권한은 변경할 수 없습니다. 가 관리형 정책에 정의된 권한을 AWS 업데이트하는 AWS 경우 업데이트는 정책이 연결된 모든 보안 주체 자격 증명(사용자, 그룹 및 역할)에 영향을 줍니다. AWS AWS 서비스 는 새가 시작되거나 기존 서비스에 새 API 작업을 사용할 수 있게 될 때 AWS 관리형 정책을 업데이트할 가능성이 높습니다.
자세한 내용은 *IAM 사용자 가이드*의 [AWS 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)을 참조하세요.
# AWS 관리형 정책: AmazonMSKFullAccess
이 정책은 모든 Amazon MSK 작업에 대한 전체 액세스 권한을 허용하는 관리 권한을 보안 주체에게 부여합니다. 해당 정책의 권한은 다음과 같이 그룹화됩니다.
+ Amazon MSK 권한은 모든 Amazon MSK 작업을 허용합니다.
+ **`Amazon EC2` 권한** - 이 정책에서 이 권한은 API 요청에서 전달된 리소스를 검증하는 데 필요합니다. 이는 Amazon MSK가 클러스터에서 리소스를 성공적으로 사용할 수 있도록 하기 위한 것입니다. 이 정책의 나머지 Amazon EC2 권한은 Amazon MSK가 클러스터에 연결하는 데 필요한 AWS 리소스를 생성하도록 허용합니다.
+ **`AWS KMS` 권한** - 이 정책에서 이 권한은 API 호출 중에 요청에서 전달된 리소스를 검증하는 데 사용됩니다. Amazon MSK가 전달된 키를 Amazon MSK 클러스터에서 사용할 수 있도록 하기 위해 필요합니다.
+ **`CloudWatch Logs, Amazon S3, and Amazon Data Firehose` 권한** - 이 권한은 Amazon MSK가 로그 전송 대상에 도달할 수 있는지와 브로커 로그 사용에 유효한지 확인하는 데 필요합니다.
+ **`IAM` 권한** – 이 권한은 계정에서 서비스 연결 역할을 생성하고 서비스 실행 역할을 Amazon MSK에 전달할 수 있도록 하는 데 필요합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"kafka:*",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeSecurityGroups",
"ec2:DescribeRouteTables",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcAttribute",
"kms:DescribeKey",
"kms:CreateGrant",
"logs:CreateLogDelivery",
"logs:GetLogDelivery",
"logs:UpdateLogDelivery",
"logs:DeleteLogDelivery",
"logs:ListLogDeliveries",
"logs:PutResourcePolicy",
"logs:DescribeResourcePolicies",
"logs:DescribeLogGroups",
"S3:GetBucketPolicy",
"firehose:TagDeliveryStream"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:*:ec2:*:*:vpc/*",
"arn:*:ec2:*:*:subnet/*",
"arn:*:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:*:ec2:*:*:vpc-endpoint/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/AWSMSKManaged": "true"
},
"StringLike": {
"aws:RequestTag/ClusterArn": "*"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:*:ec2:*:*:vpc-endpoint/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateVpcEndpoint"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteVpcEndpoints"
],
"Resource": "arn:*:ec2:*:*:vpc-endpoint/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AWSMSKManaged": "true"
},
"StringLike": {
"ec2:ResourceTag/ClusterArn": "*"
}
}
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "kafka.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/kafka.amazonaws.com/AWSServiceRoleForKafka*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "kafka.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/kafka.amazonaws.com/AWSServiceRoleForKafka*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/delivery.logs.amazonaws.com/AWSServiceRoleForLogDelivery*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "delivery.logs.amazonaws.com"
}
}
}
]
}
```
------
# AWS 관리형 정책: AmazonMSKReadOnlyAccess
이 정책은 Amazon MSK의 정보를 볼 수 있는 읽기 전용 권한을 사용자에게 부여합니다. 이 정책이 첨부된 보안 주체는 기존 리소스를 업데이트하거나 삭제할 수 없으며 새 Amazon MSK 리소스를 생성할 수도 없습니다. 예를 들어 이러한 권한이 있는 주체는 자신의 계정과 연결된 클러스터 및 구성 목록을 볼 수 있지만 클러스터의 구성이나 설정을 변경할 수는 없습니다. 해당 정책의 권한은 다음과 같이 그룹화됩니다.
+ **`Amazon MSK` 권한** – 이 권한을 통해 Amazon MSK 리소스를 나열하고, 리소스를 설명하고, 리소스에 대한 정보를 얻을 수 있습니다.
+ **`Amazon EC2` 권한** – 이 권한은 클러스터와 연결된 Amazon VPC, 서브넷, 보안 그룹, ENI를 설명하는 데 사용됩니다.
+ **`AWS KMS` 권한** – 이 권한은 클러스터와 연결된 키를 설명하는 데 사용됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"kafka:Describe*",
"kafka:List*",
"kafka:Get*",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"kms:DescribeKey"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
# AWS 관리형 정책: KafkaServiceRolePolicy
IAM 엔터티에 KafkaServiceRolePolicy를 연결할 수 없습니다. 이 정책은 서비스 연결 역할에 첨부되어 Amazon MSK가 MSK 클러스터에서 VPC 엔드포인트(커넥터) 관리, 네트워크 인터페이스 관리, AWS Secrets Manager로 클러스터 보안 인증 정보 관리와 같은 작업을 수행할 수 있도록 합니다. 자세한 내용은 [Amazon MSK의 서비스 연결 역할](using-service-linked-roles.md) 단원을 참조하십시오.
다음 표에서는 Amazon MSK가 변경 사항 추적을 시작한 이후 KafkaServiceRolePolicy 관리형 정책의 업데이트에 대해 설명합니다.
| 변경 | 설명 | Date |
| --- | --- | --- |
| [KafkaServiceRolePolicy에 IPv6 연결 지원 추가](#security-iam-awsmanpol-KafkaServiceRolePolicy) - 기존 정책 업데이트 | Amazon MSK는 MSK 클러스터에 대한 IPv6 연결을 활성화하기 위해 KafkaServiceRolePolicy에 권한을 추가했습니다. 이러한 권한을 통해 Amazon MSK는 네트워크 인터페이스에 IPv6 주소를 할당 및 할당 해제하고 고객 계정의 네트워크 인터페이스 속성을 수정할 수 있습니다. | 2025년 11월 17일 |
| [KafkaServiceRolePolicy](#security-iam-awsmanpol-KafkaServiceRolePolicy) — 기존 정책에 대한 업데이트 | Amazon MSK가 다중 VPC 프라이빗 연결을 지원하기 위한 권한을 추가했습니다. | 2023년 3월 8일 |
| Amazon MSK에서 변경 사항 추적 시작 | Amazon MSK가 KafkaServiceRolePolicy 관리형 정책에 대한 변경 사항 추적을 시작했습니다. | 2023년 3월 8일 |
# AWS 관리형 정책: AWSMSKReplicatorExecutionRole
이 `AWSMSKReplicatorExecutionRole` 정책은 MSK 클러스터 간에 데이터를 복제할 수 있는 권한을 Amazon MSK Replicator에 부여합니다. 해당 정책의 권한은 다음과 같이 그룹화됩니다.
+ **`cluster`** – IAM 인증을 사용하여 클러스터에 연결할 수 있는 Amazon MSK Replicator 권한을 부여합니다. 또한 클러스터를 설명하고 변경할 수 있는 권한을 부여합니다.
+ **`topic`** - 주제를 설명, 생성 및 변경하고 주제의 동적 구성을 변경할 수 있는 권한을 Amazon MSK Replicator에 부여합니다.
+ **`consumer group`** - 소비자 그룹을 설명 및 변경하고, MSK 클러스터에서 날짜를 읽고 쓰고, Replicator에서 생성한 내부 주제를 삭제할 수 있는 권한을 Amazon MSK Replicator에 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ClusterPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:DescribeCluster",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeTopic",
"kafka-cluster:CreateTopic",
"kafka-cluster:AlterTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData",
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup",
"kafka-cluster:DescribeTopicDynamicConfiguration",
"kafka-cluster:AlterTopicDynamicConfiguration",
"kafka-cluster:WriteDataIdempotently"
],
"Resource": [
"arn:aws:kafka:*:*:cluster/*"
]
},
{
"Sid": "TopicPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:DescribeTopic",
"kafka-cluster:CreateTopic",
"kafka-cluster:AlterTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData",
"kafka-cluster:DescribeTopicDynamicConfiguration",
"kafka-cluster:AlterTopicDynamicConfiguration",
"kafka-cluster:AlterCluster"
],
"Resource": [
"arn:aws:kafka:*:*:topic/*/*"
]
},
{
"Sid": "GroupPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup"
],
"Resource": [
"arn:aws:kafka:*:*:group/*/*"
]
}
]
}
```
------
# AWS 관리형 정책에 대한 Amazon MSK 업데이트
이 서비스가 이러한 변경 사항을 추적하기 시작한 이후부터 Amazon MSK의 AWS 관리형 정책 업데이트에 대한 세부 정보를 봅니다.
| 변경 | 설명 | Date |
| --- | --- | --- |
| [WriteDataIdempotently 권한이 AWSMSKReplicatorExecutionRole에 추가됨](security-iam-awsmanpol-AWSMSKReplicatorExecutionRole.md) - 기존 정책의 업데이트 | Amazon MSK에서 MSK 클러스터 간의 데이터 복제를 지원하기 위해 AWSMSKReplicatorExecutionRole 정책에 WriteDataIdempotently 권한을 추가했습니다. | 2024년 3월 12일 |
| [AWSMSKReplicatorExecutionRole](security-iam-awsmanpol-AWSMSKReplicatorExecutionRole.md) - 새로운 정책 | Amazon MSK에서 Amazon MSK Replicator를 지원하기 위해 AWSMSKReplicatorExecutionRole 정책을 추가했습니다. | 2023년 12월 4일 |
| [AmazonMSKFullAccess](security-iam-awsmanpol-AmazonMSKFullAccess.md) - 기존 정책에 대한 업데이트 | Amazon MSK가 Amazon MSK Replicator를 지원하기 위한 권한을 추가했습니다. | 2023년 9월 28일 |
| [KafkaServiceRolePolicy](security-iam-awsmanpol-KafkaServiceRolePolicy.md) — 기존 정책에 대한 업데이트 | Amazon MSK가 다중 VPC 프라이빗 연결을 지원하기 위한 권한을 추가했습니다. | 2023년 3월 8일 |
| [AmazonMSKFullAccess](security-iam-awsmanpol-AmazonMSKFullAccess.md) - 기존 정책에 대한 업데이트 | Amazon MSK가 클러스터에 연결할 수 있도록 새로운 Amazon EC2 권한을 추가했습니다. | 2021년 11월 30일 |
| [AmazonMSKFullAccess](security-iam-awsmanpol-AmazonMSKFullAccess.md) - 기존 정책에 대한 업데이트 | Amazon MSK가 Amazon EC2 라우팅 테이블을 설명할 수 있는 새로운 권한을 추가했습니다. | 2021년 11월 19일 |
| Amazon MSK에서 변경 사항 추적 시작 | Amazon MSK는 AWS 관리형 정책에 대한 변경 사항 추적을 시작했습니다. | 2021년 11월 19일 |
# Amazon MSK 자격 증명 및 액세스 문제 해결
다음 정보를 사용하여 Amazon MSK 및 IAM으로 작업할 때 발생할 수 있는 일반적인 문제를 진단하고 수정할 수 있습니다.
**Topics**
+ [Amazon MSK에서 작업을 수행할 권한이 없음](#security_iam_troubleshoot-no-permissions)
## Amazon MSK에서 작업을 수행할 권한이 없음
에서 작업을 수행할 권한이 없다는 AWS Management Console 메시지가 표시되면 관리자에게 문의하여 도움을 받아야 합니다. 관리자는 로그인 보안 인증 정보를 제공한 사람입니다.
다음 예제 오류는 `mateojackson` IAM 사용자가 콘솔을 사용하여 클러스터를 삭제하려고 하지만 `kafka:DeleteCluster` 권한이 없는 경우 발생합니다.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: kafka:DeleteCluster on resource: purchaseQueriesCluster
```
이 경우, Mateo는 `purchaseQueriesCluster` 작업을 사용하여 `kafka:DeleteCluster` 리소스에 액세스하도록 허용하는 정책을 업데이트하라고 관리자에게 요청합니다.
# Apache Kafka API에 대한 인증 및 권한 부여
IAM을 사용하여 클라이언트를 인증하고 Apache Kafka 작업을 허용하거나 거부할 수 있습니다. 또는 TLS나 SASL/SCRAM을 사용하여 클라이언트를 인증하고 Apache Kafka ACL을 사용하여 작업을 허용하거나 거부할 수 있습니다.
클러스터에서 [Amazon MSK 작업](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html)을 수행할 수 있는 사용자를 제어하는 방법에 대한 자세한 내용은 [Amazon MSK API에 대한 인증 및 권한 부여](security-iam.md) 섹션을 참조하세요.
**Topics**
+ [IAM 액세스 제어](iam-access-control.md)
+ [Amazon MSK에 대한 상호 TLS 클라이언트 인증](msk-authentication.md)
+ [AWS Secrets Manager를 사용한 로그인 보안 인증](msk-password.md)
+ [Apache Kafka ACL](msk-acls.md)
# IAM 액세스 제어
Amazon MSK를 위한 IAM 액세스 제어를 사용하면 MSK 클러스터에 대한 인증과 권한 부여를 모두 처리할 수 있습니다. 이렇게 하면 인증에 한 메커니즘을 사용하고 권한 부여에 다른 메커니즘을 사용할 필요가 없습니다. 예를 들어 클라이언트가 클러스터에 쓰기를 시도할 때 Amazon MSK는 IAM을 사용하여 해당 클라이언트가 인증된 자격 증명인지 여부와 클러스터에 생성할 수 있는 권한이 있는지 여부를 확인합니다.
IAM 액세스 제어는 Python, Go, JavaScript 및 .NET으로 작성된 Kafka 클라이언트를 포함하여 Java 및 비 Java 클라이언트에서 작동합니다. Java가 아닌 클라이언트에 대한 IAM 액세스 제어는 Kafka 버전 2.7.1 이상의 MSK 클러스터에서 사용할 수 있습니다.
IAM 액세스 제어를 가능하게 하기 위해 Amazon MSK는 Apache Kafka 소스 코드를 약간 수정합니다. 이러한 수정 사항으로 인해 Apache Kafka 환경이 눈에 띄게 달라지지는 않습니다. Amazon MSK는 액세스 이벤트를 기록하므로 이를 감사할 수 있습니다.
IAM 액세스 제어를 사용하는 MSK 클러스터에 대해 Apache Kafka ACL API를 호출할 수 있습니다. 그러나 Apache Kafka ACL은 IAM ID에 대한 권한 부여에 영향을 미치지 않습니다. IAM 정책을 사용하여 IAM ID에 대한 액세스를 제어해야 합니다.
**중요 고려 사항**
MSK 클러스터에서 IAM 액세스 제어를 사용하는 경우 다음 중요 고려 사항에 유의하세요.
IAM 액세스 제어는 Apache ZooKeeper 노드에는 적용되지 않습니다. 이러한 노드에 대한 액세스를 제어하는 방법에 대한 자세한 내용은 [Amazon MSK 클러스터의 Apache ZooKeeper 노드에 대한 액세스 제어](zookeeper-security.md) 섹션을 참조하세요.
클러스터에서 IAM 액세스 제어를 사용하는 경우 `allow.everyone.if.no.acl.found` Apache Kafka 설정은 적용되지 않습니다.
IAM 액세스 제어를 사용하는 MSK 클러스터에 대해 Apache Kafka ACL API를 호출할 수 있습니다. 그러나 Apache Kafka ACL은 IAM ID에 대한 권한 부여에 영향을 미치지 않습니다. IAM 정책을 사용하여 IAM ID에 대한 액세스를 제어해야 합니다.
# Amazon MSK의 IAM 액세스 제어 작동 방식
Amazon MSK에 대한 IAM 액세스 제어를 사용하려면 다음 단계를 수행하세요. 이러한 단계는 이 섹션의 나머지 부분에서 자세히 설명합니다.
+ [IAM 액세스 제어를 사용하는 Amazon MSK 클러스터 생성](create-iam-access-control-cluster-in-console.md)
+ [IAM 액세스 제어를 위한 클라이언트 구성](configure-clients-for-iam-access-control.md)
+ [IAM 역할에 대한 권한 부여 정책 생성](create-iam-access-control-policies.md)
+ [IAM 액세스 제어를 위한 부트스트랩 브로커 가져오기](get-bootstrap-brokers-for-iam.md)
# IAM 액세스 제어를 사용하는 Amazon MSK 클러스터 생성
이 섹션에서는 AWS Management Console, API 또는를 사용하여 IAM 액세스 제어를 사용하는 Amazon MSK 클러스터를 AWS CLI 생성하는 방법을 설명합니다. 기존 클러스터에 대한 IAM 액세스 제어를 사용 설정하는 방법에 대한 자세한 내용은 [Amazon MSK 클러스터의 보안 설정 업데이트](msk-update-security.md) 섹션을 참조하세요.
**AWS Management Console 를 사용하여 IAM 액세스 제어를 사용하는 클러스터 생성**
1. [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/)에서 Amazon MSK 콘솔을 엽니다.
1. **클러스터 생성**을 선택합니다.
1. **사용자 지정 설정으로 클러스터 생성**을 선택합니다.
1. **인증** 섹션에서 **IAM 액세스 제어**를 선택합니다.
1. 클러스터 생성을 위한 나머지 워크플로를 완료합니다.
**API 또는 AWS CLI 를 사용하여 IAM 액세스 제어를 사용하는 클러스터 생성**
+ IAM 액세스 제어를 사용하도록 설정한 클러스터를 생성하려면 [CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster) API 또는 [create-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/create-cluster.html) CLI 명령을 사용하고 `ClientAuthentication` 파라미터에 대해 다음 JSON(`"ClientAuthentication": { "Sasl": { "Iam": { "Enabled": true } }`)을 전달합니다.
# IAM 액세스 제어를 위한 클라이언트 구성
클라이언트가 IAM 액세스 제어를 사용하는 MSK 클러스터와 통신할 수 있도록 하려면 다음 메커니즘 중 하나를 사용할 수 있습니다.
+ SASL\$1OAUTHBEARER 메커니즘을 사용하여 비 Java 클라이언트 구성
+ SASL\$1OAUTHBEARER 메커니즘 또는 AWS\$1MSK\$1IAM 메커니즘을 사용하여 Java 클라이언트 구성
## SASL\$1OAUTHBEARER 메커니즘을 사용하여 IAM 구성
1. 다음 Python Kafka 클라이언트 예제를 사용하여 client.properties 구성 파일을 편집합니다. 구성 변경은 다른 언어에서도 비슷합니다.
```
from kafka import KafkaProducer
from kafka.errors import KafkaError
from kafka.sasl.oauth import AbstractTokenProvider
import socket
import time
from aws_msk_iam_sasl_signer import MSKAuthTokenProvider
class MSKTokenProvider():
def token(self):
token, _ = MSKAuthTokenProvider.generate_auth_token('')
return token
tp = MSKTokenProvider()
producer = KafkaProducer(
bootstrap_servers='',
security_protocol='SASL_SSL',
sasl_mechanism='OAUTHBEARER',
sasl_oauth_token_provider=tp,
client_id=socket.gethostname(),
)
topic = ""
while True:
try:
inp=input(">")
producer.send(topic, inp.encode())
producer.flush()
print("Produced!")
except Exception:
print("Failed to send message:", e)
producer.close()
```
1. 선택한 구성 언어의 헬퍼 라이브러리를 다운로드하고 해당 언어 라이브러리 홈페이지의 *시작하기* 섹션에 있는 지침을 따르세요.
+ JavaScript: [https://github.com/aws/aws-msk-iam-sasl-signer-js\$1getting-started](https://github.com/aws/aws-msk-iam-sasl-signer-js#getting-started)
+ Python: [https://github.com/aws/aws-msk-iam-sasl-signer-python\$1get-started](https://github.com/aws/aws-msk-iam-sasl-signer-python#get-started)
+ Go: [https://github.com/aws/aws-msk-iam-sasl-signer-go\$1getting-started](https://github.com/aws/aws-msk-iam-sasl-signer-go#getting-started)
+ .NET: [https://github.com/aws/aws-msk-iam-sasl-signer-net\$1getting-started](https://github.com/aws/aws-msk-iam-sasl-signer-net#getting-started)
+ JAVA: Java용 SASL\$1OAUTHBEARER 지원은 [https://github.com/aws/aws-msk-iam-auth/releases](https://github.com/aws/aws-msk-iam-auth/releases) jar 파일을 통해 사용 가능
## MSK 사용자 지정 AWS\$1MSK\$1IAM 메커니즘을 사용하여 IAM을 구성
1. `client.properties` 파일에 다음을 추가합니다. **을 클라이언트의 트러스트 스토어 파일에 대한 정규화된 경로로 변경합니다.
**참고**
특정 인증서를 사용하지 않으려면 `client.properties` 파일에서 `ssl.truststore.location=`을 제거하면 됩니다. `ssl.truststore.location`의 값을 지정하지 않으면 Java 프로세스에서 기본 인증서를 사용합니다.
```
ssl.truststore.location=
security.protocol=SASL_SSL
sasl.mechanism=AWS_MSK_IAM
sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required;
sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler
```
자격 AWS 증명에 대해 생성한 명명된 프로필을 사용하려면 클라이언트 구성 파일에 `awsProfileName="your profile name";`를 포함합니다. 명명된 프로필에 대한 자세한 내용은 AWS CLI 설명서의 [명명된 프로필을](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html) 참조하세요.
1. 안정적인 최신 [aws-msk-iam-auth](https://github.com/aws/aws-msk-iam-auth/releases) JAR 파일을 다운로드하여 클래스 경로에 배치합니다. Maven을 사용하는 경우 필요에 따라 버전 번호를 조정하여 다음 종속성을 추가합니다.
```
software.amazon.msk
aws-msk-iam-auth
1.0.0
```
Amazon MSK 클라이언트 플러그인은 Apache 2.0 라이선스에 따라 오픈 소스로 제공됩니다.
# IAM 역할에 대한 권한 부여 정책 생성
권한 부여 정책을 클라이언트에 해당하는 IAM 역할에 연결합니다. 권한 부여 정책에서 역할에 대해 허용하거나 거부할 작업을 지정합니다. 클라이언트가 Amazon EC2 인스턴스를 사용하는 경우 권한 부여 정책을 해당 Amazon EC2 인스턴스의 IAM 역할에 연결합니다. 또는 명명된 프로필을 사용하도록 클라이언트를 구성한 다음 권한 부여 정책을 해당 명명된 프로필의 역할과 연결할 수 있습니다. [IAM 액세스 제어를 위한 클라이언트 구성](configure-clients-for-iam-access-control.md)에서는 명명된 프로필을 사용하도록 클라이언트를 구성하는 방법에 대해 설명합니다.
IAM 정책을 만드는 방법에 대한 자세한 내용은 [IAM 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)을 참조하세요.
다음은 MyTestCluster라는 클러스터에 대한 권한 부여 정책의 예제입니다. `Action` 및 `Resource` 요소의 의미를 이해하려면 [IAM 권한 부여 정책 작업 및 리소스의 의미](kafka-actions.md)를 참조하세요.
**중요**
IAM 정책에 대한 변경 사항은 IAM API 및 AWS CLI 에 즉시 반영됩니다. 그러나 정책 변경이 적용되려면 상당한 시간이 소요될 수 있습니다. 대부분 정책 변경은 1분 이내에 적용됩니다. 네트워크 상태에 따라 지연 시간이 늘어날 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeCluster"
],
"Resource": [
"arn:aws:kafka:us-east-1:111122223333:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/*"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:group/MyTestCluster/*"
]
}
]
}
```
------
데이터 생산 및 소비와 같은 일반적인 Apache Kafka 사용 사례에 해당하는 조치 요소가 포함된 정책을 생성하는 방법을 알아보려면 [클라이언트 권한 부여 정책의 일반적인 사용 사례](iam-access-control-use-cases.md)를 참조하세요.
Kafka 버전 2.8.0 이상에서는 **WriteDataIdempotently** 권한이 더 이상 사용되지 않습니다([KIP-679](https://cwiki.apache.org/confluence/display/KAFKA/KIP-679%3A+Producer+will+enable+the+strongest+delivery+guarantee+by+default)). 기본적으로 `enable.idempotence = true`가 설정되어 있습니다. 따라서 Kafka 버전 2.8.0 이상의 경우 IAM은 Kafka ACL과 동일한 기능을 제공하지 않습니다. 해당 주제에 대한 `WriteData` 액세스 권한만 제공해서는 주제에 `WriteDataIdempotently`를 수행할 수 없습니다. 이는 **모든** 주제에 `WriteData`가 제공되는 경우에는 영향을 미치지 않습니다. 이 경우 `WriteDataIdempotently`가 허용됩니다. 이는 IAM 로직의 구현 방식과 Kafka ACL의 구현 방식에 차이가 있기 때문입니다. 또한 주제에 멱등적으로 쓰려면 `transactional-ids`에 대한 액세스 권한도 필요합니다.
이 문제를 해결하려면 다음 정책과 유사한 정책을 사용하는 것을 권장합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeCluster",
"kafka-cluster:WriteDataIdempotently"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/TestTopic",
"arn:aws:kafka:us-east-1:123456789012:transactional-id/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*"
]
}
]
}
```
------
이 경우 `WriteData`는 `TestTopic`에 대한 쓰기를 허용하고 `WriteDataIdempotently`은 클러스터에 대한 멱등성 쓰기를 허용합니다. 또한 이 정책은 필요한 `transactional-id` 리소스에 대한 액세스 권한을 추가합니다.
`WriteDataIdempotently`는 클러스터 수준 권한이므로 주제 수준에서 사용할 수 없습니다. `WriteDataIdempotently`가 주제 수준으로 제한되어 있으면 해당 정책이 작동하지 않습니다.
# IAM 액세스 제어를 위한 부트스트랩 브로커 가져오기
[Amazon MSK 클러스터를 위한 부트스트랩 브로커 가져오기](msk-get-bootstrap-brokers.md)을(를) 참조하세요.
# IAM 권한 부여 정책 작업 및 리소스의 의미
**참고**
Apache Kafka 버전 3.8 이상을 실행하는 클러스터의 경우 IAM 액세스 제어는 트랜잭션을 종료하기 위한 WriteTxnMarkers API를 지원합니다. 3.8 이전 버전의 Kafka를 실행하는 클러스터의 경우 IAM 액세스 제어는 WriteTxnMarkers를 포함한 내부 클러스터 작업을 지원하지 않습니다. 이러한 이전 버전의 경우 트랜잭션을 종료하려면 IAM 인증 대신 적절한 ACLs을 사용하여 SCRAM 또는 mTLS 인증을 사용합니다.
이 섹션에서는 IAM 권한 부여 정책에서 사용할 수 있는 작업 및 리소스 요소의 의미에 대해 설명합니다. 정책 예제는 [IAM 역할에 대한 권한 부여 정책 생성](create-iam-access-control-policies.md)을 참조하세요.
## 권한 부여 정책 작업
다음 표에는 Amazon MSK를 위한 IAM 액세스 제어를 사용할 때 권한 부여 정책에 포함할 수 있는 작업이 나열되어 있습니다. 권한 부여 정책에 표의 *작업* 열에 있는 작업을 포함할 때는 *필수 작업* 열에 있는 해당 작업도 포함해야 합니다.
| 작업 | 설명 | 필수 작업 | 필수 리소스 | 서버리스 클러스터에 적용 가능 |
| --- | --- | --- | --- | --- |
| kafka-cluster:Connect | 클러스터에 연결하고 인증할 수 있는 권한을 부여합니다. | 없음 | 클러스터 | 예 |
| kafka-cluster:DescribeCluster | 클러스터의 다양한 측면을 설명할 수 있는 권한을 부여하며, 이는 Apache Kafka의 DESCRIBE CLUSTER ACL과 동일합니다. | `kafka-cluster:Connect` | 클러스터 | 예 |
| kafka-cluster:AlterCluster | 클러스터의 다양한 측면을 변경할 수 있는 권한을 부여하며, 이는 Apache Kafka의 ALTER CLUSTER ACL과 동일합니다. | `kafka-cluster:Connect` `kafka-cluster:DescribeCluster` | 클러스터 | 아니요 |
| kafka-cluster:DescribeClusterDynamicConfiguration | 클러스터의 동적 구성을 설명할 수 있는 권한을 부여하며, 이는 Apache Kafka의 DESCRIBE\$1CONFIGS CLUSTER ACL과 동일합니다. | `kafka-cluster:Connect` | 클러스터 | 아니요 |
| kafka-cluster:AlterClusterDynamicConfiguration | 클러스터의 동적 구성을 변경할 수 있는 권한을 부여하며, 이는 Apache Kafka의 ALTER\$1CONFIGS CLUSTER ACL과 동일합니다. | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` | 클러스터 | 아니요 |
| kafka-cluster:WriteDataIdempotently | 클러스터에서 데이터를 멱등적으로 쓸 수 있는 권한을 부여하며, 이는 Apache Kafka의 IDEMPOTENT\$1WRITE CLUSTER ACL과 동일합니다. | `kafka-cluster:Connect` `kafka-cluster:WriteData` | 클러스터 | 예 |
| kafka-cluster:CreateTopic | 클러스터에 주제를 생성할 수 있는 권한을 부여하며, 이는 Apache Kafka의 CREATE CLUSTER/TOPIC ACL과 동일합니다. | `kafka-cluster:Connect` | 주제 | 예 |
| kafka-cluster:DescribeTopic | 클러스터의 주제를 설명할 수 있는 권한을 부여하며, 이는 Apache Kafka의 DESCRIBE TOPIC ACL과 동일합니다. | `kafka-cluster:Connect` | 주제 | 예 |
| kafka-cluster:AlterTopic | 클러스터의 주제를 변경할 수 있는 권한을 부여하며, 이는 Apache Kafka의 ALTER TOPIC ACL과 동일합니다. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | 주제 | 예 |
| kafka-cluster:DeleteTopic | 클러스터에서 주제를 삭제할 수 있는 권한을 부여하며, 이는 Apache Kafka의 DELETE TOPIC ACL과 동일합니다. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | 주제 | 예 |
| kafka-cluster:DescribeTopicDynamicConfiguration | 클러스터에서 주제의 동적 구성을 설명할 수 있는 권한을 부여하며, 이는 Apache Kafka의 DESCRIBE\$1CONFIGS TOPIC ACL과 동일합니다. | `kafka-cluster:Connect` | 주제 | 예 |
| kafka-cluster:AlterTopicDynamicConfiguration | 클러스터에서 주제의 동적 구성을 변경할 수 있는 권한을 부여하며, 이는 Apache Kafka의 ALTER\$1CONFIGS TOPIC ACL과 동일합니다. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` | 주제 | 예 |
| kafka-cluster:ReadData | 클러스터의 토픽에서 데이터를 읽을 수 있는 권한을 부여하며, 이는 Apache Kafka의 READ TOPIC ACL과 동일합니다. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterGroup` | 주제 | 예 |
| kafka-cluster:WriteData | Apache Kafka의 WRITE TOPIC ACL에 해당하는 클러스터에서 주제에 데이터를 쓸 수 있는 권한을 부여합니다. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | 주제 | 예 |
| kafka-cluster:DescribeGroup | 클러스터에서 그룹을 설명할 수 있는 권한을 부여하며, 이는 Apache Kafka의 DESCRIBE GROUP ACL과 동일합니다. | `kafka-cluster:Connect` | 그룹 | 예 |
| kafka-cluster:AlterGroup | 클러스터의 그룹에 참여할 수 있는 권한을 부여하며, 이는 Apache Kafka의 READ GROUP ACL과 동일합니다. | `kafka-cluster:Connect` `kafka-cluster:DescribeGroup` | 그룹 | 예 |
| kafka-cluster:DeleteGroup | 클러스터에서 그룹을 삭제할 수 있는 권한을 부여하며, 이는 Apache Kafka의 DELETE GROUP ACL과 동일합니다. | `kafka-cluster:Connect` `kafka-cluster:DescribeGroup` | 그룹 | 예 |
| kafka-cluster:DescribeTransactionalId | 클러스터에서 트랜잭션 ID를 설명할 수 있는 권한을 부여하며, 이는 Apache Kafka의 DESCRIBE TRANSACTIONAL\$1ID ACL과 동일합니다. | `kafka-cluster:Connect` | transactional-id | 예 |
| kafka-cluster:AlterTransactionalId | 클러스터의 트랜잭션 ID를 변경할 수 있는 권한을 부여하며, 이는 Apache Kafka의 WRITE TRANSACTIONAL\$1ID ACL과 동일합니다. | `kafka-cluster:Connect` `kafka-cluster:DescribeTransactionalId` `kafka-cluster:WriteData` | transactional-id | 예 |
콜론 뒤에 오는 작업에서 별표(\$1) 와일드카드를 여러 번 사용할 수 있습니다. 예를 들면 다음과 같습니다.
+ `kafka-cluster:*Topic`은 `kafka-cluster:CreateTopic`, `kafka-cluster:DescribeTopic`, `kafka-cluster:AlterTopic`, `kafka-cluster:DeleteTopic`을 나타냅니다. `kafka-cluster:DescribeTopicDynamicConfiguration` 또는 `kafka-cluster:AlterTopicDynamicConfiguration`은 포함되지 않습니다.
+ `kafka-cluster:*`는 모든 권한을 나타냅니다.
## 권한 부여 정책 리소스
다음 표에는 Amazon MSK를 위한 IAM 액세스 제어를 사용할 때 권한 부여 정책에 사용할 수 있는 4가지 유형의 리소스를 보여줍니다. 또는 [DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster) API AWS Management Console 또는 [describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html) AWS CLI 명령을 사용하여 클러스터 Amazon 리소스 이름(ARN)을 가져올 수 있습니다. 그런 다음 클러스터 ARN을 사용하여 주제, 그룹, 트랜잭션 ID ARN을 구성할 수 있습니다. 권한 부여 정책에서 리소스를 지정하려면 해당 리소스의 ARN을 사용합니다.
| Resource | ARN 형식 |
| --- | --- |
| Cluster | arn:aws:kafka:region:account-id:cluster/cluster-name/cluster-uuid |
| Topic | arn:aws:kafka:region:account-id:topic/cluster-name/cluster-uuid/topic-name |
| Group | arn:aws:kafka:region:account-id:group/cluster-name/cluster-uuid/group-name |
| 트랜잭션 ID | arn:aws:kafka:region:account-id:transactional-id/cluster-name/cluster-uuid/transactional-id |
별표(\$1) 와일드카드는 ARN의 `:cluster/`, `:topic/`, `:group/`, `:transactional-id/` 뒤에 오는 부분 어디에서나 여러 번 사용할 수 있습니다. 다음은 별표(\$1) 와일드카드를 사용하여 여러 리소스를 참조하는 방법에 대한 몇 가지 예입니다.
+ `arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/*`: 클러스터의 UUID에 관계없이 MyTestCluster라는 이름의 모든 클러스터에 있는 모든 주제입니다.
+ `arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*_test`: 이름이 MyTestCluster이고 UUID가 abcd1234-0123-abcd-5678-1234abcd-1인 클러스터에서 이름이 “\$1test”로 끝나는 모든 주제입니다.
+ `arn:aws:kafka:us-east-1:0123456789012:transactional-id/MyTestCluster/*/5555abcd-1111-abcd-1234-abcd1234-1`: 계정에 있는 MyTestCluster라는 클러스터의 모든 구현에서 트랜잭션 ID가 5555abcd-1111-abcd-1234-abcd1234-1인 모든 트랜잭션입니다. 즉, MyTestCluster라는 이름의 클러스터를 생성한 다음 삭제한 다음 같은 이름의 다른 클러스터를 생성하는 경우 이 리소스 ARN을 사용하여 두 클러스터에서 동일한 트랜잭션 ID를 나타낼 수 있습니다. 그러나 삭제된 클러스터는 액세스할 수 없습니다.
# 클라이언트 권한 부여 정책의 일반적인 사용 사례
다음 표의 첫 번째 열에는 몇 가지 일반적인 사용 사례가 나와 있습니다. 클라이언트가 특정 사용 사례를 수행하도록 권한을 부여하려면 클라이언트의 권한 부여 정책에 해당 사용 사례에 필요한 작업을 포함하고 `Effect`를 `Allow`로 설정합니다.
Amazon MSK에 대한 IAM 액세스 제어의 일부인 모든 작업에 대한 자세한 내용은 [IAM 권한 부여 정책 작업 및 리소스의 의미](kafka-actions.md) 섹션을 참조하세요.
**참고**
기본적으로 작업이 거부됩니다. 클라이언트가 수행할 수 있도록 권한을 부여하려는 모든 작업을 명시적으로 허용해야 합니다.
****
| 사용 사례: | 필수 작업 |
| --- | --- |
| 관리자 | `kafka-cluster:*` |
| 주제 생성 | `kafka-cluster:Connect` `kafka-cluster:CreateTopic` |
| 데이터 생산 | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` |
| 데이터 소비 | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeGroup` `kafka-cluster:AlterGroup` `kafka-cluster:ReadData` |
| 멱등적으로 데이터 생산 | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` `kafka-cluster:WriteDataIdempotently` |
| 트랜잭션 방식으로 데이터 생산 | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` `kafka-cluster:DescribeTransactionalId` `kafka-cluster:AlterTransactionalId` |
| 클러스터 구성 설명 | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` |
| 클러스터의 구성 업데이트 | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` `kafka-cluster:AlterClusterDynamicConfiguration` |
| 주제 구성 설명 | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` |
| 주제의 구성 업데이트 | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` `kafka-cluster:AlterTopicDynamicConfiguration` |
| 주제 변경 | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterTopic` |
# Amazon MSK에 대한 상호 TLS 클라이언트 인증
애플리케이션에서 Amazon MSK 브로커로의 연결을 위해 TLS를 사용하여 클라이언트 인증을 활성화할 수 있습니다. 클라이언트 인증을 사용하려면 AWS Private CA가 필요합니다. 는 클러스터 AWS 계정 와 동일한 또는 다른 계정에 있을 AWS Private CA 수 있습니다. AWS Private CA에 대한 자세한 내용은 [생성 및 관리를 AWS Private CA](https://docs.aws.amazon.com/acm-pca/latest/userguide/create-CA.html) 참조하세요.
Amazon MSK는 인증서 해지 목록(CRL)을 지원하지 않습니다. 클러스터 주제에 대한 액세스를 제어하거나 손상된 인증서를 차단하려면 Apache Kafka ACLs 및 AWS 보안 그룹을 사용합니다. Apache Kafka ACL 사용에 대한 자세한 내용은 [Apache Kafka ACL](msk-acls.md) 섹션을 참조하세요.
**Topics**
+ [클라이언트 인증을 지원하는 Amazon MSK 클러스터 생성](msk-authentication-cluster.md)
+ [인증을 사용하도록 클라이언트 설정](msk-authentication-client.md)
+ [인증을 사용하여 메시지 생성 및 사용](msk-authentication-messages.md)
# 클라이언트 인증을 지원하는 Amazon MSK 클러스터 생성
이 절차에서는를 사용하여 클라이언트 인증을 활성화하는 방법을 보여줍니다 AWS Private CA.
**참고**
상호 TLS를 사용하여 액세스를 제어할 때는 각 MSK 클러스터 AWS Private CA 에 대해 독립적인를 사용하는 것이 좋습니다. 이렇게 하면 PCA가 서명한 TLS 인증서는 단일 MSK 클러스터에서만 인증됩니다.
1. 다음 콘텐츠를 가진 `clientauthinfo.json`이라는 파일을 생성합니다: *Private-CA-ARN*을 PCA의 ARN으로 바꿉니다.
```
{
"Tls": {
"CertificateAuthorityArnList": ["Private-CA-ARN"]
}
}
```
1. [를 사용하여 프로비저닝된 Amazon MSK 클러스터 생성 AWS CLI](create-cluster-cli.md)에 설명된 대로 `brokernodegroupinfo.json` 파일을 생성합니다.
1. 클라이언트 인증을 사용하려면 클라이언트와 브로커 간 전송 중 암호화를 활성화해야 합니다. 다음 콘텐츠를 가진 `encryptioninfo.json`이라는 파일을 생성합니다: *KMS-Key-ARN*을 KMS 키의 ARN으로 바꿉니다. `ClientBroker`를 `TLS` 또는 `TLS_PLAINTEXT`로 설정할 수 있습니다.
```
{
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "KMS-Key-ARN"
},
"EncryptionInTransit": {
"InCluster": true,
"ClientBroker": "TLS"
}
}
```
암호화에 대한 자세한 내용은 [Amazon MSK 암호화](msk-encryption.md) 섹션을 참조하세요.
1. 가 AWS CLI 설치된 시스템에서 다음 명령을 실행하여 인증 및 전송 중 암호화가 활성화된 클러스터를 생성합니다. 응답에 제공된 클러스터 ARN을 저장합니다.
```
aws kafka create-cluster --cluster-name "AuthenticationTest" --broker-node-group-info file://brokernodegroupinfo.json --encryption-info file://encryptioninfo.json --client-authentication file://clientauthinfo.json --kafka-version "{YOUR KAFKA VERSION}" --number-of-broker-nodes 3
```
# 인증을 사용하도록 클라이언트 설정
이 프로세스는 인증을 사용할 클라이언트로 사용하도록 Amazon EC2 인스턴스를 설정하는 방법을 설명합니다.
이 프로세스는 클라이언트 머신을 생성하고, 주제를 생성하고, 필요한 보안 설정을 구성하여 인증을 사용해서 메시지를 생성하고 소비하는 방법을 설명합니다.
1. 클라이언트 머신으로 사용할 Amazon EC2 인스턴스를 생성합니다. 간단히 하기 위해 클러스터에 사용한 것과 동일한 VPC에 이 인스턴스를 생성합니다. 이러한 클라이언트 머신을 생성하는 방법에 대한 예제는 [3단계: 클라이언트 머신 생성](create-client-machine.md) 단원을 참조하십시오.
1. 주제를 생성합니다. 예를 들어, [4단계: Amazon MSK 클러스터에서 주제 생성](create-topic.md) 단원의 지침을 참조하십시오.
1. 가 AWS CLI 설치된 시스템에서 다음 명령을 실행하여 클러스터의 부트스트랩 브로커를 가져옵니다. *Cluster-ARN*을 클러스터의 ARN으로 바꿉니다.
```
aws kafka get-bootstrap-brokers --cluster-arn Cluster-ARN
```
응답에서 `BootstrapBrokerStringTls`에 연결된 문자열을 저장합니다.
1. 클라이언트 머신에서 다음 명령을 실행하여 JVM 트러스트 스토어를 사용하여 클라이언트 트러스트 스토어를 만듭니다. JVM 경로가 다른 경우 그에 따라 명령을 조정하십시오.
```
cp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64/jre/lib/security/cacerts kafka.client.truststore.jks
```
1. 클라이언트 머신에서 다음 명령을 실행하여 클라이언트에 대한 프라이빗 키를 만듭니다. *Distinguished-Name*, *Example-Alias*, *Your-Store-Pass*, *Your-Key-Pass*를 원하는 문자열로 바꿉니다.
```
keytool -genkey -keystore kafka.client.keystore.jks -validity 300 -storepass Your-Store-Pass -keypass Your-Key-Pass -dname "CN=Distinguished-Name" -alias Example-Alias -storetype pkcs12 -keyalg rsa
```
1. 클라이언트 머신에서 다음 명령을 실행하여 이전 단계에서 만든 프라이빗 키로 인증서 요청을 만듭니다.
```
keytool -keystore kafka.client.keystore.jks -certreq -file client-cert-sign-request -alias Example-Alias -storepass Your-Store-Pass -keypass Your-Key-Pass
```
1. `client-cert-sign-request` 파일을 열고, `-----BEGIN CERTIFICATE REQUEST-----`로 시작해 `-----END CERTIFICATE REQUEST-----`로 끝나는지 확인합니다. `-----BEGIN NEW CERTIFICATE REQUEST-----`로 시작하는 경우, 파일의 시작 부분과 끝 부분에서 단어 `NEW` 및 그 뒤의 단일 공백을 삭제합니다.
1. 가 AWS CLI 설치된 시스템에서 다음 명령을 실행하여 인증서 요청에 서명합니다. *Private-CA-ARN*을 PCA의 ARN으로 바꿉니다. 원하는 경우 유효성 값을 변경할 수 있습니다. 여기에서는 300을 사용합니다.
```
aws acm-pca issue-certificate --certificate-authority-arn Private-CA-ARN --csr fileb://client-cert-sign-request --signing-algorithm "SHA256WITHRSA" --validity Value=300,Type="DAYS"
```
응답에 제공된 인증서 ARN을 저장합니다.
**참고**
클라이언트 인증서를 검색하려면 `acm-pca get-certificate` 명령을 사용하고 사용자 인증서 ARN을 지정합니다. 자세한 내용은 *AWS CLI 명령 참조*에서 [get-certificate](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm-pca/get-certificate.html)를 참조하세요.
1. 다음 명령을 실행하여가 자동으로 AWS Private CA 서명한 인증서를 가져옵니다. *Certificate-ARN*을 이전 명령에 대한 응답에서 얻은 ARN으로 바꿉니다.
```
aws acm-pca get-certificate --certificate-authority-arn Private-CA-ARN --certificate-arn Certificate-ARN
```
1. 이전 명령을 실행한 JSON 결과에서 `Certificate` 및 `CertificateChain`에 연결된 문자열을 복사합니다. 이 두 문자열을 signed-certificate-from-acm이라는 새 파일에 붙여 넣습니다. 우선 `Certificate`에 연결된 문자열을 붙여 넣은 다음, `CertificateChain`와 연결된 문자열을 붙여 넣습니다. `\n` 문자를 새 줄로 바꿉니다. 다음은 인증서 및 인증서 체인을 붙여 넣은 이후의 파일 구조입니다.
```
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
```
1. 클라이언트 머신에서 다음 명령을 실행하여 MSK 브로커와 통신할 때 제공할 수 있도록 키 스토어에 이 인증서를 추가합니다.
```
keytool -keystore kafka.client.keystore.jks -import -file signed-certificate-from-acm -alias Example-Alias -storepass Your-Store-Pass -keypass Your-Key-Pass
```
1. 다음 콘텐츠를 가진 `client.properties`이라는 파일을 생성합니다: 트러스트 스토어 및 키 스토어 위치를 `kafka.client.truststore.jks`를 저장한 경로로 조정합니다. *\$1YOUR KAFKA VERSION\$1* 자리 표시자를 Kafka 클라이언트 버전으로 대체합니다.
```
security.protocol=SSL
ssl.truststore.location=/tmp/kafka_2.12-{YOUR KAFKA VERSION}/kafka.client.truststore.jks
ssl.keystore.location=/tmp/kafka_2.12-{YOUR KAFKA VERSION}/kafka.client.keystore.jks
ssl.keystore.password=Your-Store-Pass
ssl.key.password=Your-Key-Pass
```
# 인증을 사용하여 메시지 생성 및 사용
이 프로세스는 인증을 사용하여 메시지를 생성하고 사용하는 방법을 설명합니다.
1. 다음 명령을 실행해 주제를 생성합니다. `client.properties`라는 파일은 이전 절차에서 생성한 파일입니다.
```
/bin/kafka-topics.sh --create --bootstrap-server BootstrapBroker-String --replication-factor 3 --partitions 1 --topic ExampleTopic --command-config client.properties
```
1. 콘솔 생산자를 시작하려면 다음 명령을 실행합니다. `client.properties`라는 파일은 이전 절차에서 생성한 파일입니다.
```
/bin/kafka-console-producer.sh --bootstrap-server BootstrapBroker-String --topic ExampleTopic --producer.config client.properties
```
1. 클라이언트 머신의 새 명령 창에서 다음 명령을 실행하여 콘솔 소비자를 시작합니다.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBroker-String --topic ExampleTopic --consumer.config client.properties
```
1. 생산자 창에 메시지를 입력하고 소비자 창에 표시되는지 확인합니다.
# AWS Secrets Manager를 사용한 로그인 보안 인증
AWS Secrets Manager를 사용하여 저장되고 보호되는 로그인 자격 증명을 사용하여 Amazon MSK 클러스터에 대한 액세스를 제어할 수 있습니다. Secrets Manager에 사용자 보안 인증 정보를 저장하면 보안 인증 정보 감사, 업데이트, 교체와 같은 클러스터 인증의 오버헤드가 줄어듭니다. 또한 Secrets Manager를 사용하면 클러스터 간에 사용자 보안 인증 정보를 공유할 수 있습니다.
보안 암호를 MSK 클러스터와 연결하면 MSK는 자격 증명 데이터를 주기적으로 동기화합니다.
**Topics**
+ [로그인 자격 증명 인증의 작동 방식](msk-password-howitworks.md)
+ [Amazon MSK 클러스터를 위해 SASL/SCRAM 인증 설정](msk-password-tutorial.md)
+ [사용자 작업](msk-password-users.md)
+ [SCRAM 비밀 사용 시 제한 사항](msk-password-limitations.md)
# 로그인 자격 증명 인증의 작동 방식
Amazon MSK의 로그인 보안 인증 정보 인증은 SASL/SCRAM(Simple Authentication and Security Layer/Salted Challenge Response Mechanism) 인증을 사용합니다. 클러스터에 대한 로그인 보안 인증 정보 인증을 설정하려면 [AWS Secrets Manager](https://docs.aws.amazon.com//secretsmanager/?id=docs_gateway)에서 보안 암호 리소스를 생성하고 로그인 보안 인증 정보를 해당 보안 암호에 연결합니다.
SASL/SCRAM은 [RFC 5802](https://tools.ietf.org/html/rfc5802)에 정의되어 있습니다. SCRAM은 보안 해싱 알고리즘을 사용하며 클라이언트와 서버 간에 일반 텍스트 로그인 보안 인증 정보를 전송하지 않습니다.
**참고**
클러스터에 대해 SASL/SCRAM 인증을 설정하면 Amazon MSK는 클라이언트와 브로커 간의 모든 트래픽에 대해 TLS 암호화를 설정합니다.
# Amazon MSK 클러스터를 위해 SASL/SCRAM 인증 설정
AWS Secrets Manager에서 보안 암호를 설정하려면 [AWS Secrets Manager 사용 설명서](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)의 [보안 암호 생성 및 검색](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) 자습서를 따르세요.
Amazon MSK 클러스터에 대한 보안 암호를 생성하는 경우에는 다음 요구 사항에 유의하세요.
+ 암호 유형으로 **다른 유형의 보안 암호(예: API 키)**를 선택합니다.
+ 보안 암호 이름은 접두사 **AmazonMSK\$1**로 시작해야 합니다.
+ 기존 사용자 지정 AWS KMS 키를 사용하거나 보안 암호에 대한 새 사용자 지정 AWS KMS 키를 생성해야 합니다. Secrets Manager는 기본적으로 보안 암호에 기본 AWS KMS 키를 사용합니다.
**중요**
기본 AWS KMS 키로 생성된 보안 암호는 Amazon MSK 클러스터에서 사용할 수 없습니다.
+ **일반 텍스트** 옵션을 사용하여 키-값 페어를 입력하려면 로그인 보안 인증 정보 데이터가 다음 형식이어야 합니다.
```
{
"username": "alice",
"password": "alice-secret"
}
```
+ 보안 암호에 대한 Amazon 리소스 이름(ARN) 값
+
**중요**
[클러스터 크기를 적절하게 조정: Standard 브로커당 파티션 수](bestpractices.md#partitions-per-broker)에 설명된 제한을 초과하는 클러스터에는 Secrets Manager 보안 암호를 연결할 수 없습니다.
+ AWS CLI 를 사용하여 보안 암호를 생성하는 경우 `kms-key-id` 파라미터의 키 ID 또는 ARN을 지정합니다. 별칭을 지정하지 마세요.
+ 보안 암호를 클러스터에 연결하려면 Amazon MSK 콘솔 또는 [BatchAssociateScramSecret](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html#BatchAssociateScramSecret) 작업을 사용합니다.
**중요**
암호를 클러스터와 연결하면 Amazon MSK는 클러스터가 정의한 보안 암호 값에 액세스하고 읽을 수 있도록 허용하는 리소스 정책을 암호에 연결합니다. 이 리소스 정책을 수정해서는 안 됩니다. 이렇게 하면 클러스터가 보안 암호에 액세스하는 것을 방지할 수 있습니다. 보안 암호 리소스 정책 및/또는 보안 암호 암호화에 사용되는 KMS 키를 변경하는 경우 보안 암호를 MSK 클러스터에 다시 연결해야 합니다. 이를 통해 클러스터가 보안 암호에 계속 액세스할 수 있습니다.
다음 `BatchAssociateScramSecret` 작업의 예제 JSON 입력은 보안 암호를 클러스터와 연결합니다.
```
{
"clusterArn" : "arn:aws:kafka:us-west-2:0123456789019:cluster/SalesCluster/abcd1234-abcd-cafe-abab-9876543210ab-4",
"secretArnList": [
"arn:aws:secretsmanager:us-west-2:0123456789019:secret:AmazonMSK_MyClusterSecret"
]
}
```
# 로그인 보안 인증 정보를 사용하여 클러스터에 연결
보안 암호를 생성하고 클러스터에 연결하면 클라이언트를 클러스터에 연결할 수 있습니다. 다음 절차에서는 SASL/SCRAM 인증을 사용하는 클러스터에 클라이언트를 연결하는 방법을 보여줍니다. 또한 예제 주제에서 이를 생성하고 소비하는 방법을 보여줍니다.
**Topics**
+ [SASL/SCRAM 인증을 사용하여 클러스터에 클라이언트 연결](#w2aab9c13c29c17c13c11b9b7)
+ [연결 문제 해결](#msk-password-tutorial-connect-troubleshooting)
## SASL/SCRAM 인증을 사용하여 클러스터에 클라이언트 연결
1. 가 AWS CLI 설치된 시스템에서 다음 명령을 실행합니다. *clusterARN*을 클러스터의 ARN으로 바꿉니다.
```
aws kafka get-bootstrap-brokers --cluster-arn clusterARN
```
이 명령의 JSON 결과에서 `BootstrapBrokerStringSaslScram`이라는 문자열과 연관된 값을 저장합니다. 이후 단계에서 이 값을 사용합니다.
1. 클라이언트 머신에서 암호에 저장된 사용자 보안 인증 정보가 포함된 JAAS 구성 파일을 생성합니다. 예를 들어 사용자 **alice**에 대해 다음과 같은 내용으로 `users_jaas.conf`라는 파일을 생성합니다.
```
KafkaClient {
org.apache.kafka.common.security.scram.ScramLoginModule required
username="alice"
password="alice-secret";
};
```
1. 다음 명령을 사용하여 JAAS 구성 파일을 `KAFKA_OPTS` 환경 파라미터로 내보냅니다.
```
export KAFKA_OPTS=-Djava.security.auth.login.config=/users_jaas.conf
```
1. `/tmp` 디렉터리에 `kafka.client.truststore.jks`라는 파일을 생성합니다.
1. (선택 사항) 다음 명령을 사용하여 JVM `cacerts` 폴더에 이전 단계에서 생성한 `kafka.client.truststore.jks` 파일로 JDK 키 저장소 파일을 복사합니다. *JDKFolder*를 인스턴스의 JDK 폴더 이름으로 변경합니다. 예를 들어 JDK 폴더의 이름은 `java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64`일 수 있습니다.
```
cp /usr/lib/jvm/JDKFolder/lib/security/cacerts /tmp/kafka.client.truststore.jks
```
1. Apache Kafka 설치의 `bin` 디렉터리에 다음 내용으로 `client_sasl.properties`라는 클라이언트 속성 파일을 생성합니다. 이 파일은 SASL 메커니즘과 프로토콜을 정의합니다.
```
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
```
1. 예제 주제를 생성하려면 다음 명령을 실행합니다. *BootstrapBrokerStringSaslScram*을 이 주제의 1단계에서 얻은 부트스트랩 브로커 문자열로 바꿉니다.
```
/bin/kafka-topics.sh --create --bootstrap-server BootstrapBrokerStringSaslScram --command-config /client_sasl.properties --replication-factor 3 --partitions 1 --topic ExampleTopicName
```
1. 생성한 예제 주제로 생성하려면 클라이언트 머신에서 다음 명령을 실행합니다. *BootstrapBrokerStringSaslScram*을 이 주제의 1단계에서 검색한 부트스트랩 브로커 문자열로 바꿉니다.
```
/bin/kafka-console-producer.sh --broker-list BootstrapBrokerStringSaslScram --topic ExampleTopicName --producer.config client_sasl.properties
```
1. 생성한 주제에서 사용하려면 클라이언트 머신에서 다음 명령을 실행합니다. *BootstrapBrokerStringSaslScram*을 이 주제의 1단계에서 얻은 부트스트랩 브로커 문자열로 바꿉니다.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringSaslScram --topic ExampleTopicName --from-beginning --consumer.config client_sasl.properties
```
## 연결 문제 해결
Kafka 클라이언트 명령을 실행하는 경우, 특히 대규모 주제 또는 데이터세트로 작업할 때 Java 힙 메모리 오류가 발생할 수 있습니다. 이러한 오류는 Kafka 도구가 워크로드에 충분하지 않을 수 있는 기본 메모리 설정이 있는 Java 애플리케이션으로 실행되기 때문에 발생합니다.
`Out of Memory Java Heap` 오류를 해결하려면 메모리 설정을 포함하도록 `KAFKA_OPTS` 환경 변수를 수정하여 Java 힙 크기를 늘릴 수 있습니다.
다음 예제에서는 최대 힙 크기를 1GB(`-Xmx1G`)로 설정합니다. 사용 가능한 시스템 메모리 및 요구 사항에 따라 이 값을 조정할 수 있습니다.
```
export KAFKA_OPTS="-Djava.security.auth.login.config=/users_jaas.conf -Xmx1G"
```
대규모 주제를 사용하는 경우 메모리 사용량을 제한하는 `--from-beginning` 대신 시간 기반 또는 오프셋 기반 파라미터를 사용하는 것이 좋습니다.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringSaslScram --topic ExampleTopicName --max-messages 1000 --consumer.config client_sasl.properties
```
# 사용자 작업
**사용자 생성**: 보안 암호에 키-값 페어로 사용자를 생성합니다. Secrets Manager 콘솔에서 **일반 텍스트** 옵션을 사용하는 경우 로그인 보안 인증 정보 데이터를 다음 형식으로 지정해야 합니다.
```
{
"username": "alice",
"password": "alice-secret"
}
```
**사용자 액세스 취소:** 클러스터에 액세스하기 위한 사용자의 보안 인증 정보를 취소하려면 먼저 클러스터에서 ACL을 제거하거나 적용한 다음 보안 암호 연결을 해제하는 것을 권장합니다. 이는 다음과 같은 이유 때문입니다.
+ 사용자를 제거해도 기존 연결은 닫히지 않습니다.
+ 보안 암호에 대한 변경 사항이 전파되는 데에는 최대 10분이 소요됩니다.
Amazon MSK에서 ACL을 사용하는 방법에 대한 자세한 내용은 [Apache Kafka ACL](msk-acls.md) 섹션을 참조하세요.
ZooKeeper 모드를 사용하는 클러스터의 경우 사용자가 ACL을 수정하지 못하도록 ZooKeeper 노드에 대한 액세스를 제한하는 것이 좋습니다. 자세한 내용은 [Amazon MSK 클러스터의 Apache ZooKeeper 노드에 대한 액세스 제어](zookeeper-security.md) 단원을 참조하십시오.
# SCRAM 비밀 사용 시 제한 사항
SCRAM 보안 암호를 사용할 때는 다음 제한 사항에 유의하세요.
+ Amazon MSK는 SCRAM-SHA-512 인증만 지원합니다.
+ Amazon MSK 클러스터는 최대 1,000명의 사용자를 보유할 수 있습니다.
+ 보안 암호와 AWS KMS key 함께를 사용해야 합니다. 기본 시크릿 관리자 암호화 키를 사용하는 보안 암호는 Amazon MSK와 함께 사용할 수 없습니다. KMS 키 생성에 대한 자세한 내용은 [대칭 암호화 KMS 키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk)을 참조하세요.
+ Secrets Manager에서는 비대칭 KMS 키를 사용할 수 없습니다.
+ [BatchAssociateScramSecret](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html#BatchAssociateScramSecret) 작업을 사용하여 한 번에 최대 10개의 보안 암호를 클러스터에 연결할 수 있습니다.
+ Amazon MSK 클러스터와 연결된 보안 암호의 이름에는 접두사 **AmazonMSK\$1**가 있어야 합니다.
+ Amazon MSK 클러스터와 연결된 보안 암호는 클러스터와 동일한 Amazon Web Services 계정 및 AWS 리전에 있어야 합니다.
# Apache Kafka ACL
Apache Kafka에는 플러그형 권한 부여자가 있으며, 기본 제공 권한 부여자 구현이 함께 제공됩니다. Amazon MSK는 브로커의 `server.properties` 파일에서 이 권한 부여자를 활성화합니다.
Apache Kafka ACL의 형식은 "Principal P is [Allowed/Denied] Operation O From Host H on any Resource R matching ResourcePattern RP"입니다. RP가 특정 리소스 R과 일치하지 않으면 R에 연결된 ACL이 없으므로 수퍼유저 이외의 누구도 R에 액세스할 수 없습니다. 이 Apache Kafka 동작을 변경하려면 속성 `allow.everyone.if.no.acl.found`를 true로 설정합니다. Amazon MSK는 이 속성을 기본적으로 true로 설정합니다. 즉, Amazon MSK 클러스터를 사용할 때 리소스에 ACL을 명시적으로 설정하지 않으면 모든 보안 주체가 이 리소스에 액세스할 수 있습니다. 리소스에 대해 ACL을 활성화하면 권한이 부여된 보안 주체만 ACL에 액세스할 수 있습니다. TLS 상호 인증을 사용하여 주제에 대한 액세스를 제한하고 클라이언트에 권한을 부여하려면 Apache Kafka 권한 부여자 CLI를 사용하여 ACL을 추가합니다. ACL 추가, 제거 및 나열 방법에 대한 자세한 내용은 [Kafka 인증 명령줄 인터페이스](https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Authorization+Command+Line+Interface)를 참조하십시오.
Amazon MSK는 브로커를 슈퍼 사용자로 구성하므로 모든 주제에 액세스할 수 있습니다. 이를 통해 브로커가 클러스터 구성에 `allow.everyone.if.no.acl.found` 속성이 정의되어 있는지 여부에 관계없이 기본 파티션에서 메시지를 복제할 수 있습니다.
**주제에 대한 읽기 및 쓰기 액세스 권한을 추가하거나 제거하려면**
1. 브로커가 ACL이 있는 모든 주제에서 읽을 수 있도록 ACL 테이블에 브로커를 추가합니다. 브로커에게 주제에 대한 읽기 액세스 권한을 부여하려면 MSK 클러스터와 통신할 수 있는 클라이언트 머신에서 다음 명령을 실행합니다.
*Distinguished-Name*을 해당 클러스터의 부트스트랩 브로커의 DNS로 바꾼 다음 이 고유 이름의 첫 번째 마침표 앞에 있는 문자열을 별표(`*`)로 바꿉니다. 예를 들어, 클러스터의 부트스트랩 브로커 중 하나에 DNS `b-6.mytestcluster.67281x.c4.kafka.us-east-1.amazonaws.com`이 있는 경우 다음 명령의 *Distinguished-Name*을 `*.mytestcluster.67281x.c4.kafka.us-east-1.amazonaws.com`으로 바꿉니다. 부트스트랩 브로커를 가져오는 방법에 대한 자세한 내용은 [Amazon MSK 클러스터를 위한 부트스트랩 브로커 가져오기](msk-get-bootstrap-brokers.md) 단원을 참조하십시오.
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Read --group=* --topic Topic-Name
```
1. 주제에 대한 클라이언트 애플리케이션 읽기 액세스 권한을 부여하려면 클라이언트 머신에서 다음 명령을 실행합니다. 상호 TLS 인증을 사용하는 경우 프라이빗 키를 생성할 때 사용한 것과 동일한 *Distinguished-Name*을 사용합니다.
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Read --group=* --topic Topic-Name
```
읽기 액세스 권한을 제거하려면 `--add`를 `--remove`로 바꾸어 같은 명령을 실행하면 됩니다.
1. 주제에 대한 쓰기 액세스 권한을 부여하려면 클라이언트 머신에서 다음 명령을 실행합니다. 상호 TLS 인증을 사용하는 경우 프라이빗 키를 생성할 때 사용한 것과 동일한 *Distinguished-Name*을 사용합니다.
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Write --topic Topic-Name
```
쓰기 액세스 권한을 제거하려면 `--add`를 `--remove`로 바꾸어 같은 명령을 실행하면 됩니다.
# Amazon MSK 클러스터의 보안 그룹 변경
이 페이지에서는 기존 MSK 클러스터의 보안 그룹을 변경하는 방법을 설명합니다. 특정 사용자 세트에 액세스 권한을 제공하거나 클러스터에 대한 액세스를 제한하기 위해 클러스터의 보안 그룹을 변경해야 할 수도 있습니다. 보안 그룹에 대한 자세한 내용은 Amazon VPC 사용 설명서에서 [VPC의 보안 그룹](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)을 참조하세요.
1. [ListNodes](https://docs.amazonaws.cn/en_us/msk/1.0/apireference/clusters-clusterarn-nodes.html#ListNodes) API 또는의 [list-nodes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/list-nodes.html) 명령을 사용하여 클러스터의 브로커 목록을 AWS CLI 가져옵니다. 이 작업의 결과에는 브로커와 연결된 탄력적 네트워크 인터페이스(ENI)의 ID가 포함됩니다.
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) Amazon EC2 콘솔을 엽니다.
1. 화면 오른쪽 상단에 있는 드롭다운 목록을 사용하여 클러스터가 배포될 리전을 선택합니다.
1. 왼쪽 창의 **네트워크 및 보안**에서 **네트워크 인터페이스**를 선택합니다.
1. 첫 번째 단계에서 가져온 첫 번째 ENI를 선택합니다. 화면 상단의 **작업** 메뉴를 선택한 다음 **보안 그룹 변경**을 선택합니다. 해당 ENI에 새 보안 그룹을 할당합니다. 첫 번째 단계에서 가져온 각 ENI에 대해 이 단계를 반복합니다.
**참고**
Amazon EC2 콘솔을 사용하여 클러스터의 보안 그룹에 대한 변경 사항은 **네트워크 설정**의 MSK 콘솔에 반영되지 않습니다.
1. 새 보안 그룹의 규칙을 구성하여 고객이 브로커에 액세스할 수 있도록 합니다. 보안 그룹 규칙 설정에 대한 자세한 내용은 Amazon VPC 사용 설명서에서 [규칙 추가, 제거, 업데이트](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#AddRemoveRules)를 참조하세요.
**중요**
클러스터의 브로커와 연결된 보안 그룹을 변경한 다음 해당 클러스터에 새 브로커를 추가하면 Amazon MSK는 새 브로커를 클러스터가 생성될 때 클러스터와 연결된 원래 보안 그룹에 연결합니다. 그러나 클러스터가 올바르게 작동하려면 모든 브로커가 동일한 보안 그룹에 연결되어 있어야 합니다. 따라서 보안 그룹을 변경한 후 새 브로커를 추가하는 경우 이전 절차를 다시 수행하여 새 브로커의 ENI를 업데이트해야 합니다.
# Amazon MSK 클러스터의 Apache ZooKeeper 노드에 대한 액세스 제어
보안상의 이유로 Amazon MSK 클러스터의 일부인 Apache ZooKeeper 노드에 대한 액세스를 제한할 수 있습니다. 노드에 대한 액세스를 제한하기 위해 별도의 보안 그룹을 할당할 수 있습니다. 그런 다음 해당 보안 그룹에 대한 액세스 권한을 결정할 수 있습니다.
**중요**
이 섹션은 KRaft 모드에서 실행되는 클러스터에는 적용되지 않습니다. [KRaft 모드](metadata-management.md#kraft-intro)을(를) 참조하세요.
**Topics**
+ [Apache ZooKeeper 노드를 별도의 보안 그룹에 배치하려면](zookeeper-security-group.md)
+ [Apache ZooKeeper에서 TLS 보안 사용](zookeeper-security-tls.md)
# Apache ZooKeeper 노드를 별도의 보안 그룹에 배치하려면
Apache ZooKeeper 노드에 대한 액세스를 제한하기 위해 별도의 보안 그룹을 할당할 수 있습니다. 보안 그룹 규칙을 설정하여 이 새 보안 그룹에 액세스할 수 있는 사용자를 선택할 수 있습니다.
1. 클러스터에 대한 Apache ZooKeeper 연결 문자열을 가져옵니다. 자세한 방법은 [ZooKeeper 모드](metadata-management.md#msk-get-connection-string)을 참조하세요. 이 연결 문자열은 Apache ZooKeeper 노드의 DNS 이름을 포함합니다.
1. `host` 또는 `ping` 같은 도구를 사용하여 이전 단계에서 얻은 DNS 이름을 IP 주소로 변환합니다. 이 절차의 뒷부분에 필요하므로 이 IP 주소를 저장하십시오.
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) Amazon EC2 콘솔을 엽니다.
1. 탐색 창의 **NETWORK & SECURITY(네트워크 및 보안)** 아래에서 **Network Interfaces(네트워크 인터페이스)**를 선택합니다.
1. 네트워크 인터페이스 테이블 위의 검색 필드에 클러스터 이름을 입력한 다음 return을 입력합니다. 이렇게 하면 테이블에 표시되는 네트워크 인터페이스 수가 클러스터와 연결된 인터페이스로 제한됩니다.
1. 목록의 첫 번째 네트워크 인터페이스에 해당하는 행의 시작 부분에 있는 확인란을 선택합니다.
1. 페이지 하단의 세부 정보 창에서 **주 프라이빗 IPv4 IP**를 찾습니다. 이 IP 주소가 이 절차의 첫 번째 단계에서 얻은 IP 주소 중 하나와 일치하면 이 네트워크 인터페이스가 클러스터의 일부인 Apache ZooKeeper 노드에 할당된다는 뜻입니다. 그렇지 않으면 이 네트워크 인터페이스 옆의 확인란 선택을 취소하고, 목록에서 다음 네트워크 인터페이스를 선택합니다. 네트워크 인터페이스를 선택하는 순서는 중요하지 않습니다. 다음 단계에는 Apache ZooKeeper 노드에 할당된 모든 네트워크 인터페이스에서 일일이 동일한 작업을 수행합니다.
1. Apache ZooKeeper 노드에 해당하는 네트워크 인터페이스를 선택하는 경우 페이지 상단의 **작업** 메뉴를 선택한 다음, **보안 그룹 변경**을 선택합니다. 이 네트워크 인터페이스에 새 보안 그룹을 할당합니다. 보안 그룹 생성에 대한 자세한 내용은 Amazon VPC 설명서에서 [보안 그룹 생성](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#CreatingSecurityGroups)을 참조하세요.
1. 이전 단계를 반복하여 클러스터의 Apache ZooKeeper 노드와 연결된 모든 네트워크 인터페이스에 동일한 새 보안 그룹을 할당합니다.
1. 이제 이 새 보안 그룹에 액세스할 수 있는 사용자를 선택할 수 있습니다. 보안 그룹 규칙 설정에 대한 자세한 내용은 Amazon VPC 설명서에서 [규칙 추가, 제거, 업데이트](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#AddRemoveRules)를 참조하세요.
# Apache ZooKeeper에서 TLS 보안 사용
클라이언트와 Apache ZooKeeper 노드 간의 전송 시 암호화에 TLS 보안을 사용할 수 있습니다. Apache ZooKeeper 노드로 TLS 보안을 구현하려면 다음을 수행합니다.
+ Apache ZooKeeper에서 TLS 보안을 사용하려면 클러스터는 Apache Kafka 버전 2.5.1 이상을 사용해야 합니다.
+ 클러스터를 생성하거나 구성할 때 TLS 보안을 활성화합니다. TLS가 활성화된 Apache Kafka 버전 2.5.1 이상에서 생성된 클러스터는 Apache ZooKeeper 엔드포인트에서 자동으로 TLS 보안을 사용합니다. TLS 보안 설정에 대한 자세한 내용은 [Amazon MSK 암호화 시작하기](msk-working-with-encryption.md) 섹션을 참조하세요.
+ [DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster) 작업을 사용하여 TLS Apache ZooKeeper 엔드포인트를 검색합니다.
+ `kafka-configs.sh` 및 [https://kafka.apache.org/documentation/#security_authz_cli](https://kafka.apache.org/documentation/#security_authz_cli) 도구 또는 ZooKeeper 셸과 함께 사용할 Apache ZooKeeper 구성 파일을 생성합니다. 각 도구에서 `--zk-tls-config-file` 파라미터를 사용하여 Apache ZooKeeper 구성을 지정합니다.
다음 예제는 일반적인 Apache ZooKeeper 구성 파일을 보여줍니다.
```
zookeeper.ssl.client.enable=true
zookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
zookeeper.ssl.keystore.location=kafka.jks
zookeeper.ssl.keystore.password=test1234
zookeeper.ssl.truststore.location=truststore.jks
zookeeper.ssl.truststore.password=test1234
```
+ 다른 명령(예: `kafka-topics`)의 경우 `KAFKA_OPTS` 환경 변수를 사용하여 Apache ZooKeeper 파라미터를 구성해야 합니다. 다음 예제는 Apache ZooKeeper 파라미터를 다른 명령에 전달하도록 `KAFKA_OPTS` 환경 변수를 구성하는 방법을 보여줍니다.
```
export KAFKA_OPTS="
-Dzookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
-Dzookeeper.client.secure=true
-Dzookeeper.ssl.trustStore.location=/home/ec2-user/kafka.client.truststore.jks
-Dzookeeper.ssl.trustStore.password=changeit"
```
`KAFKA_OPTS` 환경 변수를 구성한 후에는 CLI 명령을 정상적으로 사용할 수 있습니다. 다음 예제는 `KAFKA_OPTS` 환경 변수의 Apache ZooKeeper 구성을 사용하여 Apache Kafka 주제를 생성합니다.
```
/bin/kafka-topics.sh --create --zookeeper ZooKeeperTLSConnectString --replication-factor 3 --partitions 1 --topic AWSKafkaTutorialTopic
```
**참고**
Apache ZooKeeper 구성 파일에서 사용하는 파라미터 `KAFKA_OPTS`의 이름과 환경 변수에서 사용하는 파라미터의 이름이 일치하지 않습니다. 구성 파일 및 `KAFKA_OPTS` 환경 변수에서 어떤 이름을 어떤 파라미터와 함께 사용하는지에 대해 주의하세요.
TLS로 Apache ZooKeeper 노드에 액세스하는 방법에 대한 자세한 내용은 [KIP-515: ZK 클라이언트에서 새로운 TLS 지원 인증 활성화](https://cwiki.apache.org/confluence/display/KAFKA/KIP-515%3A+Enable+ZK+client+to+use+the+new+TLS+supported+authentication)를 참조하세요.
# Amazon Managed Streaming for Apache Kafka에 대한 규정 준수 검증
타사 감사자는 AWS 규정 준수 프로그램의 일환으로 Amazon Managed Streaming for Apache Kafka의 보안 및 규정 준수 여부를 평가합니다. 여기에는 PCI 및 HIPAA BAA가 포함됩니다.
특정 규정 준수 프로그램의 범위에 속하는 AWS 서비스 목록은 규정 준수 프로그램 [제공 범위 내 Amazon 서비스규정 준수 프로그램 제공](https://aws.amazon.com/compliance/services-in-scope/) . 일반 정보는 [AWS 규정 준수 프로그램](https://aws.amazon.com/compliance/programs/).
를 사용하여 타사 감사 보고서를 다운로드할 수 있습니다 AWS Artifact. 자세한 내용은 [Downloading Reports inDownloading AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)을 참조하세요.
Amazon MSK 사용 시 규정 준수 책임은 데이터의 민감도, 회사의 규정 준수 목표 및 관련 법률과 규정에 따라 결정됩니다.는 규정 준수를 지원하기 위해 다음 리소스를 AWS 제공합니다.
+ [보안 및 규정 준수 빠른 시작 안내서](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance): 이 배포 안내서에서는 아키텍처 고려 사항에 관해 설명하고 AWS에서 보안 및 규정 준수에 중점을 둔 기본 환경을 배포하기 위한 단계를 제공합니다.
+ [HIPAA 보안 및 규정 준수를 위한 설계 백서 ](https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.html)-이 백서에서는 기업이 AWS 를 사용하여 HIPAA 준수 애플리케이션을 생성하는 방법을 설명합니다.
+ [AWS 규정 준수 리소스](https://aws.amazon.com/compliance/resources/) -이 워크북 및 가이드 모음은 산업 및 위치에 적용될 수 있습니다.
+ *AWS Config 개발자 안내서*의 [규칙을 사용하여 리소스 평가](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) -이 AWS Config 서비스는 리소스 구성이 내부 관행, 업계 지침 및 규정을 얼마나 잘 준수하는지 평가합니다.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) -이 AWS 서비스는 보안 업계 표준 및 모범 사례 준수 여부를 확인하는 데 도움이 AWS 되는 내 보안 상태에 대한 포괄적인 보기를 제공합니다.
# Amazon Managed Streaming for Apache Kafka의 복원력
AWS 글로벌 인프라는 AWS 리전 및 가용 영역을 중심으로 구축됩니다. AWS 리전은 물리적으로 분리되고 격리된 여러 가용 영역을 제공하며,이 가용 영역은 지연 시간이 짧고 처리량이 높으며 중복성이 높은 네트워킹과 연결됩니다. 가용 영역을 사용하면 중단 없이 영역 간에 자동으로 장애 극복 조치가 이루어지는 애플리케이션 및 데이터베이스를 설계하고 운영할 수 있습니다. 가용 영역은 기존의 단일 또는 다중 데이터 센터 인프라보다 가용성, 내결함성, 확장성이 뛰어납니다.
AWS 리전 및 가용 영역에 대한 자세한 내용은 [AWS 글로벌 인프라를](https://aws.amazon.com/about-aws/global-infrastructure/) 참조하세요.
# Amazon Managed Streaming for Apache Kafka의 인프라 보안
관리형 서비스인 Amazon Managed Streaming for Apache Kafka는 [Amazon Web Services: 보안 프로세스 개요](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf) 백서에 설명된 AWS 글로벌 네트워크 보안 절차로 보호됩니다.
AWS 에서 게시한 API 호출을 사용하여 네트워크를 통해 Amazon MSK에 액세스합니다. 클라이언트가 전송 계층 보안(TLS) 1.0 이상을 지원해야 합니다. TLS 1.2 이상을 권장합니다. 클라이언트는 Ephemeral Diffie-Hellman(DHE) 또는 Elliptic Curve Ephemeral Diffie-Hellman(ECDHE)과 같은 PFS(전달 완전 보안, Perfect Forward Secrecy)가 포함된 암호 제품군도 지원해야 합니다. Java 7 이상의 최신 시스템은 대부분 이러한 모드를 지원합니다.
또한 요청은 액세스 키 ID 및 IAM 위탁자와 관련된 시크릿 액세스 키를 사용하여 서명해야 합니다. 또는 [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html)(AWS STS)를 사용하여 임시 보안 자격 증명을 생성하여 요청에 서명할 수 있습니다.
# Amazon MSK 로깅
Apache Kafka 브로커 로그를 Amazon CloudWatch Logs, Amazon S3, Amazon Data Firehose 등의 대상 유형 중 하나 이상에 전달할 수 있습니다. 를 사용하여 Amazon MSK API 호출을 로깅할 수도 있습니다 AWS CloudTrail.
**참고**
브로커 로그는 MSK Standard 브로커와 Express 브로커 모두에서 사용할 수 있습니다.
## 브로커 로그
브로커 로그를 통해 Apache Kafka 애플리케이션의 문제를 해결하고 MSK 클러스터와의 통신을 분석할 수 있습니다. INFO 수준 브로커 로그를 CloudWatch 로그 그룹, S3 버킷, Firehose 전송 스트림 등의 대상 리소스 유형 중 하나 이상에 전송하도록 신규 또는 기존 MSK 클러스터를 구성할 수 있습니다. 그런 다음 Firehose를 통해 전송 스트림의 로그 데이터를 OpenSearch Service로 전송할 수 있습니다.
클러스터에 브로커 로그를 전달하도록 클러스터를 구성하기 전에 대상 리소스를 생성해야 합니다. Amazon MSK는 이러한 대상 리소스가 아직 존재하지 않는 경우 이를 생성하지 않습니다. 이러한 세 가지 유형의 대상 리소스와 이를 생성하는 방법에 대한 자세한 내용은 다음 설명서를 참조하십시오.
+ [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html)
+ [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)
### 필수 권한
Amazon MSK 브로커 로그의 대상을 구성하려면 Amazon MSK 작업에 사용하는 IAM ID에 [AWS 관리형 정책: AmazonMSKFullAccess](security-iam-awsmanpol-AmazonMSKFullAccess.md) 정책에 설명된 권한이 있어야 합니다.
브로커 로그를 S3 버킷으로 스트리밍하려면 `s3:PutBucketPolicy` 권한도 필요합니다. S3 버킷 정책에 대한 자세한 내용은 Amazon S3 사용 설명서에서 [S3 버킷 정책을 추가하려면 어떻게 해야 하나요?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/add-bucket-policy.html)를 참조하세요. IAM 정책 전반에 대한 자세한 내용은 IAM 사용 설명서의 [액세스 관리](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html)를 참조하세요.
### SSE-KMS 버킷과 함께 사용하기 위한 필수 KMS 키 정책
고객 관리형 키와 함께 AWS KMS관리형 키(SSE-KMS)를 사용하여 S3 버킷에 대한 서버 측 암호화를 활성화한 경우 Amazon MSK가 버킷에 브로커 파일을 쓸 수 있도록 KMS 키의 키 정책에 다음을 추가합니다.
```
{
"Sid": "Allow Amazon MSK to use the key.",
"Effect": "Allow",
"Principal": {
"Service": [
"delivery.logs.amazonaws.com"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
}
```
### 를 사용하여 브로커 로그 구성 AWS Management Console
새 클러스터를 생성하는 경우 **모니터링** 섹션에서 **브로커 로그 전달** 제목을 찾습니다. Amazon MSK에서 브로커 로그를 전달할 대상을 지정할 수 있습니다.
기존 클러스터의 경우 클러스터 목록에서 클러스터를 선택한 다음 **속성** 탭을 선택합니다. **모니터링** 섹션까지 아래로 스크롤한 다음 **편집** 버튼을 선택합니다. Amazon MSK에서 브로커 로그를 전달할 대상을 지정할 수 있습니다.
### 를 사용하여 브로커 로그 구성 AWS CLI
`create-cluster` 또는 `update-monitoring` 명령을 사용하면 선택적으로 `logging-info` 파라미터를 지정하고 다음 예제와 같이 JSON 구조를 전달할 수 있습니다. 이 JSON에서 세 가지 대상 유형은 모두 선택 사항입니다.
**참고**
로그 전송을 설정하려면 Firehose 스트림에서 `LogDeliveryEnabled` 태그를 `true`로 설정해야 합니다. CloudWatch 로그에 대해가 AWS 생성하는 서비스 연결 역할은이 태그를 사용하여 모든 Firehose 전송 스트림에 대한 권한을 부여합니다. 이 태그를 제거하면 서비스 연결 역할이 Firehose 스트림에 로그를 전송할 수 없습니다. 서비스 연결 역할에 포함된 권한을 보여주는 IAM 정책의 예를 보려면 *Amazon CloudWatch 사용 설명서*의 [리소스 권한에 사용되는 IAM 역할](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-Firehose.html)을 참조하세요.
```
{
"BrokerLogs": {
"S3": {
"Bucket": "amzn-s3-demo-bucket",
"Prefix": "ExamplePrefix",
"Enabled": true
},
"Firehose": {
"DeliveryStream": "ExampleDeliveryStreamName",
"Enabled": true
},
"CloudWatchLogs": {
"Enabled": true,
"LogGroup": "ExampleLogGroupName"
}
}
}
```
### API를 사용하여 브로커 로그 구성
[CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster) 또는 [UpdateMonitoring](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-monitoring.html#UpdateMonitoring) 작업에 전달하는 JSON에 선택적 `loggingInfo` 구조를 지정할 수 있습니다.
**참고**
기본적으로 브로커 로깅을 활성화하면 Amazon MSK는 `INFO` 수준 로그를 지정된 대상에 기록합니다. 그러나 표준 브로커의 경우 Apache Kafka 2.4.X 이상의 사용자는 브로커 로그 수준을 [모든 log4j 로그 수준으로](https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html) 동적으로 설정할 수 있습니다. 브로커 로그 수준을 동적으로 설정하는 방법에 대한 자세한 내용은 [KIP-412: 동적 애플리케이션 로그 수준을 지원하도록 관리자 API 확장](https://cwiki.apache.org/confluence/display/KAFKA/KIP-412%3A+Extend+Admin+API+to+support+dynamic+application+log+levels)을 참조하세요. 로그 수준을 `DEBUG` 또는 `TRACE`로 동적으로 설정하는 경우 Amazon S3 또는 Firehose를 로그 대상으로 사용하는 것이 좋습니다. CloudWatch Logs를 로그 대상으로 사용하고 `DEBUG` 또는 `TRACE` 수준 로깅을 동적으로 활성화하는 경우 Amazon MSK는 로그 샘플을 지속적으로 전달할 수 있습니다. 이는 브로커 성능에 상당한 영향을 미칠 수 있으므로 `INFO` 로그 수준이 문제의 근본 원인을 파악하기에 충분히 상세하지 않은 경우에만 사용해야 합니다.
# 를 사용하여 API 호출 로깅 AWS CloudTrail
**참고**
AWS CloudTrail 로그는를 사용하는 경우에만 Amazon MSK에 사용할 수 있습니다[IAM 액세스 제어](iam-access-control.md).
Amazon MSK는 Amazon MSK에서 사용자 AWS CloudTrail, 역할 또는 서비스가 수행한 작업에 대한 레코드를 제공하는 AWS 서비스와 통합됩니다. CloudTrail은 에 대한 API 직접 호출을 이벤트로 캡처합니다. 캡처된 호출에는 Amazon MSK 콘솔에서의 호출과 Amazon MSK API 작업에 대한 코드 호출이 포함되어 있습니다. 또한 주제 및 그룹 생성 및 변경과 같은 Apache Kafka 작업을 캡처합니다.
트레일을 만들면 Amazon MSK용 이벤트를 포함한 CloudTrail 이벤트를 Amazon S3 버킷에 지속적으로 전달할 수 있습니다. 추적을 구성하지 않은 경우에도 **이벤트 기록**에서 CloudTrail 콘솔의 최신 이벤트를 볼 수 있습니다. CloudTrail에서 수집한 정보를 사용하여 Amazon MSK 또는 Apache Kafka 작업으로 이루어진 요청, 요청이 이루어진 IP 주소, 요청을 한 사람, 요청이 이루어진 시기, 추가 세부 정보를 확인할 수 있습니다.
구성 및 활성화 방법을 포함하여 CloudTrail에 대한 자세한 내용은 [AWS CloudTrail 사용자 안내서](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)를 참조하세요.
## CloudTrail의 Amazon MSK 정보
CloudTrail은 계정 생성 시 Amazon Web Services 계정에서 활성화됩니다. 지원되는 이벤트 활동이 MSK 클러스터에서 발생하면 해당 활동은 **이벤트 기록**의 다른 AWS 서비스 이벤트와 함께 CloudTrail 이벤트에 기록됩니다. Amazon Web Services 계정에서 최신 이벤트를 확인, 검색 및 다운로드할 수 있습니다. 자세한 설명은 [CloudTrail 이벤트 기록으로 이벤트 보기](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)를 참조하세요.
Amazon MSK에 대한 이벤트를 포함하여 Amazon Web Services 계정의 이벤트에 대한 지속적인 레코드를 보려면 추적을 생성합니다. CloudTrail은 *추적*을 사용하여 Amazon S3 버킷으로 로그 파일을 전송할 수 있습니다. 콘솔에서 추적을 생성하면 기본적으로 모든 Region에 추적이 적용됩니다. 추적은 AWS 파티션에 있는 모든 리전의 이벤트를 로깅하고 지정된 Amazon S3 버킷으로 로그 파일을 전송합니다. 또는 CloudTrail 로그에서 수집된 이벤트 데이터를 추가 분석하고 처리하도록 다른 Amazon 서비스를 구성할 수도 있습니다. 자세한 내용은 다음 자료를 참조하세요.
+ [추적 생성 개요](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail 지원 서비스 및 통합](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [CloudTrail에서 Amazon SNS 알림 구성](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [여러 리전으로부터 CloudTrail 로그 파일 받기](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) 및 [여러 계정으로부터 CloudTrail 로그 파일 받기](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
Amazon MSK는 모든 [Amazon MSK 작업](https://docs.aws.amazon.com/MSK/2.0/APIReference/operations.html)을 CloudTrail 로그 파일에 이벤트로 기록합니다. 또한 다음과 같은 Apache Kafka 작업을 기록합니다.
+ kafka-cluster:DescribeClusterDynamicConfiguration
+ kafka-cluster:AlterClusterDynamicConfiguration
+ kafka-cluster:CreateTopic
+ kafka-cluster:DescribeTopicDynamicConfiguration
+ kafka-cluster:AlterTopic
+ kafka-cluster:AlterTopicDynamicConfiguration
+ kafka-cluster:DeleteTopic
모든 이벤트 또는 로그 항목에는 요청을 생성했던 사용자에 관한 정보가 포함됩니다. ID 정보를 이용하면 다음을 쉽게 판단할 수 있습니다.
+ 요청이 루트 사용자 또는 AWS Identity and Access Management (IAM) 사용자 자격 증명으로 이루어졌는지 여부입니다.
+ 역할 또는 페더레이션 사용자의 임시 자격 증명을 사용하여 요청이 생성되었는지 여부.
+ 요청이 다른 AWS 서비스에서 이루어졌는지 여부입니다.
자세한 설명은 [CloudTrail userIdentity 요소](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html)를 참조하세요.
## 예제: Amazon MSK 로그 파일 항목
트레일이란 지정한 S3 버킷에 이벤트를 로그 파일로 입력할 수 있게 하는 구성입니다. CloudTrail 로그 파일에는 하나 이상의 로그 항목이 포함될 수 있습니다. 이벤트는 모든 소스로부터의 단일 요청을 나타내며 요청 작업, 작업 날짜와 시간, 요청 파라미터 등에 대한 정보가 들어 있습니다. CloudTrail 로그 파일은 퍼블릭 API 호출과 Apache Kafka 작업의 스택 기록이 정렬되어 있지 않으므로 특정 순서로 표시되지 않습니다.
다음 예제는 `DescribeCluster` 및 `DeleteCluster` Amazon MSK 작업을 보여주는 CloudTrail 로그 항목을 보여줍니다.
```
{
"Records": [
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEF0123456789ABCDE",
"arn": "arn:aws:iam::012345678901:user/Joe",
"accountId": "012345678901",
"accessKeyId": "AIDACKCEVSQ6C2EXAMPLE",
"userName": "Joe"
},
"eventTime": "2018-12-12T02:29:24Z",
"eventSource": "kafka.amazonaws.com",
"eventName": "DescribeCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.0",
"userAgent": "aws-cli/1.14.67 Python/3.6.0 Windows/10 botocore/1.9.20",
"requestParameters": {
"clusterArn": "arn%3Aaws%3Akafka%3Aus-east-1%3A012345678901%3Acluster%2Fexamplecluster%2F01234567-abcd-0123-abcd-abcd0123efa-2"
},
"responseElements": null,
"requestID": "bd83f636-fdb5-abcd-0123-157e2fbf2bde",
"eventID": "60052aba-0123-4511-bcde-3e18dbd42aa4",
"readOnly": true,
"eventType": "AwsApiCall",
"recipientAccountId": "012345678901"
},
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEF0123456789ABCDE",
"arn": "arn:aws:iam::012345678901:user/Joe",
"accountId": "012345678901",
"accessKeyId": "AIDACKCEVSQ6C2EXAMPLE",
"userName": "Joe"
},
"eventTime": "2018-12-12T02:29:40Z",
"eventSource": "kafka.amazonaws.com",
"eventName": "DeleteCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.0",
"userAgent": "aws-cli/1.14.67 Python/3.6.0 Windows/10 botocore/1.9.20",
"requestParameters": {
"clusterArn": "arn%3Aaws%3Akafka%3Aus-east-1%3A012345678901%3Acluster%2Fexamplecluster%2F01234567-abcd-0123-abcd-abcd0123efa-2"
},
"responseElements": {
"clusterArn": "arn:aws:kafka:us-east-1:012345678901:cluster/examplecluster/01234567-abcd-0123-abcd-abcd0123efa-2",
"state": "DELETING"
},
"requestID": "c6bfb3f7-abcd-0123-afa5-293519897703",
"eventID": "8a7f1fcf-0123-abcd-9bdb-1ebf0663a75c",
"readOnly": false,
"eventType": "AwsApiCall",
"recipientAccountId": "012345678901"
}
]
}
```
다음은 `kafka-cluster:CreateTopic` 작업을 설명하는 CloudTrail 로그 항목을 보여 주는 예시입니다.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEFGH1IJKLMN2P34Q5",
"arn": "arn:aws:iam::111122223333:user/Admin",
"accountId": "111122223333",
"accessKeyId": "CDEFAB1C2UUUUU3AB4TT",
"userName": "Admin"
},
"eventTime": "2021-03-01T12:51:19Z",
"eventSource": "kafka-cluster.amazonaws.com",
"eventName": "CreateTopic",
"awsRegion": "us-east-1",
"sourceIPAddress": "198.51.100.0/24",
"userAgent": "aws-msk-iam-auth/unknown-version/aws-internal/3 aws-sdk-java/1.11.970 Linux/4.14.214-160.339.amzn2.x86_64 OpenJDK_64-Bit_Server_VM/25.272-b10 java/1.8.0_272 scala/2.12.8 vendor/Red_Hat,_Inc.",
"requestParameters": {
"kafkaAPI": "CreateTopics",
"resourceARN": "arn:aws:kafka:us-east-1:111122223333:topic/IamAuthCluster/3ebafd8e-dae9-440d-85db-4ef52679674d-1/Topic9"
},
"responseElements": null,
"requestID": "e7c5e49f-6aac-4c9a-a1d1-c2c46599f5e4",
"eventID": "be1f93fd-4f14-4634-ab02-b5a79cb833d2",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "111122223333"
}
```
# 메타데이터 관리
Amazon MSK는 Apache ZooKeeper 또는 KRaft 메타데이터 관리 모드를 지원합니다.
Amazon MSK의 Apache Kafka 버전 3.7.x에서 ZooKeeper 모드 대신 KRaft 모드를 사용하는 클러스터를 생성할 수 있습니다. KRaft 기반 클러스터는 Kafka 내의 컨트롤러를 사용하여 메타데이터를 관리합니다.
**Topics**
+ [ZooKeeper 모드](#msk-get-connection-string)
+ [KRaft 모드](#kraft-intro)
## ZooKeeper 모드
[Apache ZooKeeper](https://zookeeper.apache.org/)는 구성 정보 유지, 명명, 분산 동기화 제공 및 그룹 서비스 제공을 위한 중앙화된 서비스입니다. 이러한 모든 종류의 서비스는 Apache Kafka를 비롯한 분산 애플리케이션에서 몇몇 또는 다른 형태로 사용됩니다.
클러스터에서 ZooKeeper 모드를 사용하는 경우 아래 단계를 사용하여 Apache ZooKeeper 연결 문자열을 가져올 수 있습니다. 하지만 Kafka 2.5에서는 `--zookeeper` 플래그가 더 이상 사용되지 않고 Kafka 3.0에서는 제거되므로 `BootstrapServerString`을 사용하여 클러스터에 연결하고 관리자 작업을 수행하는 것이 좋습니다.
### 를 사용하여 Apache ZooKeeper 연결 문자열 가져오기 AWS Management Console
1. [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/)에서 Amazon MSK 콘솔을 엽니다.
1. 표에 이 계정에 속한 현재 리전의 모든 클러스터가 나열됩니다. 설명을 보려면 클러스터의 이름을 선택합니다.
1. **클러스터 요약** 페이지에서 **클라이언트 정보 보기**를 선택합니다. 여기에는 부트스트랩 브로커와 Apache ZooKeeper 연결 문자열이 표시됩니다.
### 를 사용하여 Apache ZooKeeper 연결 문자열 가져오기 AWS CLI
1. 클러스터의 Amazon 리소스 이름(ARN)을 모르는 경우, 계정의 모든 클러스터를 나열하여 찾을 수 있습니다. 자세한 내용은 [Amazon MSK 클러스터 나열](msk-list-clusters.md) 단원을 참조하십시오.
1. 클러스터에 대한 다른 정보와 함께 Apache ZooKeeper 연결 문자열을 가져오려면 *ClusterArn*을 클러스터의 ARN으로 바꾸어 다음 명령을 실행합니다.
```
aws kafka describe-cluster --cluster-arn ClusterArn
```
이 `describe-cluster` 명령의 출력은 다음 JSON 예제와 같습니다.
```
{
"ClusterInfo": {
"BrokerNodeGroupInfo": {
"BrokerAZDistribution": "DEFAULT",
"ClientSubnets": [
"subnet-0123456789abcdef0",
"subnet-2468013579abcdef1",
"subnet-1357902468abcdef2"
],
"InstanceType": "kafka.m5.large",
"StorageInfo": {
"EbsStorageInfo": {
"VolumeSize": 1000
}
}
},
"ClusterArn": "arn:aws:kafka:us-east-1:111122223333:cluster/testcluster/12345678-abcd-4567-2345-abcdef123456-2",
"ClusterName": "testcluster",
"CreationTime": "2018-12-02T17:38:36.75Z",
"CurrentBrokerSoftwareInfo": {
"KafkaVersion": "2.2.1"
},
"CurrentVersion": "K13V1IB3VIYZZH",
"EncryptionInfo": {
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "arn:aws:kms:us-east-1:555555555555:key/12345678-abcd-2345-ef01-abcdef123456"
}
},
"EnhancedMonitoring": "DEFAULT",
"NumberOfBrokerNodes": 3,
"State": "ACTIVE",
"ZookeeperConnectString": "10.0.1.101:2018,10.0.2.101:2018,10.0.3.101:2018"
}
}
```
이전 JSON 예제는 `describe-cluster` 명령 출력에 있는 `ZookeeperConnectString` 키를 보여줍니다. 이 키에 해당하는 값을 복사하고, 클러스터에서 주제를 생성해야 할 때를 대비해 저장하십시오.
**중요**
Apache ZooKeeper 연결 문자열을 가져오려면 Amazon MSK 클러스터가 `ACTIVE` 상태여야 합니다. 클러스터가 여전히 `CREATING` 상태에 있으면 `describe-cluster` 명령의 출력에 `ZookeeperConnectString`이 포함되지 않습니다 이 경우, 몇 분 정도 기다린 다음 클러스터가 `ACTIVE` 상태에 도달한 후 `describe-cluster`를 다시 실행합니다.
### API를 사용하여 Apache ZooKeeper 연결 문자열 가져오기
API를 사용하여 Apache ZooKeeper 연결 문자열을 가져오려면 [DescribeCluster](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)를 참조하십시오.
## KRaft 모드
Amazon MSK는 Kafka 버전 3.7.x에서 KRaft(Apache Kafka Raft)에 대한 지원을 도입했습니다. Apache Kafka 커뮤니티는 Apache Kafka 클러스터의 메타데이터 관리를 위해 [Apache ZooKeeper](#msk-get-connection-string)를 대체하도록 KRaft를 개발했습니다. KRaft 모드에서 클러스터 메타데이터는 ZooKeeper 노드 대신 Kafka 클러스터의 일부인 Kafka 컨트롤러 그룹 내에서 전파됩니다. KRaft 컨트롤러는 추가 비용 없이 포함되어 있으므로 추가 설정이나 관리가 필요하지 않습니다. KRaft에 대한 자세한 내용은 [KIP-500](https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum)을 참조하세요.
다음은 MSK의 KRaft 모드에 대해 유의해야 할 몇 가지 사항입니다.
+ KRaft 모드는 새로운 클러스터에만 사용할 수 있습니다. 클러스터가 생성된 후에는 메타데이터 모드를 전환할 수 없습니다.
+ MSK 콘솔에서 Kafka 버전 3.7.x를 선택하고 클러스터 생성 창에서 KRaft 확인란을 선택하여 Kraft 기반 클러스터를 생성할 수 있습니다.
+ MSK API [https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster) 또는 [https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2) 작업을 사용하여 KRaft 모드에서 클러스터를 생성하려면 `3.7.x.kraft`를 버전으로 사용해야 합니다. `3.7.x`를 버전으로 사용하여 ZooKeeper 모드에서 클러스터를 생성합니다.
+ 브로커당 파티션 수는 KRaft 및 ZooKeeper 기반 클러스터에서 동일합니다. 하지만 KRaft를 사용하면 [클러스터에 더 많은 브로커](https://docs.aws.amazon.com/msk/latest/developerguide/limits.html)를 프로비저닝하여 클러스터당 더 많은 파티션을 호스팅할 수 있습니다.
+ Amazon MSK에서 KRaft 모드를 사용하기 위해 API를 변경할 필요는 없습니다. 그러나 클라이언트에서 지금도 여전히 `--zookeeper` 연결 문자열을 사용하는 경우 `--bootstrap-server` 연결 문자열을 사용하여 클러스터에 연결하도록 클라이언트를 업데이트해야 합니다. `--zookeeper` 플래그는 Apache Kafka 버전 2.5에서 더 이상 사용되지 않으며 Kafka 버전 3.0부터 제거된다는 점에 유의하세요. 따라서 클러스터에 대한 모든 연결에는 최신 Apache Kafka 클라이언트 버전과 `--bootstrap-server` 연결 문자열을 사용하는 것이 좋습니다.
+ ZooKeeper 모드는 Apache Kafka에서 ZooKeeper도 지원하는 모든 릴리스 버전에서 계속 사용할 수 있습니다. Apache Kafka 버전 및 향후 업데이트에 대한 지원 종료에 대한 자세한 내용은 [지원되는 Apache Kafka 버전](supported-kafka-versions.md) 단원을 참조하세요.
+ 사용하는 모든 도구에서 ZooKeeper 연결 없이 Kafka Admin API를 사용할 수 있는지 확인해야 합니다. 클러스터를 Cruise Control에 연결하는 업데이트된 단계는 [Amazon MSK에서 Apache Kafka용 LinkedIn의 Cruise Control 사용](cruise-control.md) 단원을 참조하세요. Cruise Control에는 [ ZooKeeper 없이 Cruise Control을 실행](https://github.com/linkedin/cruise-control/wiki/Run-without-ZooKeeper)하는 방법도 있습니다.
+ 관리 작업을 위해 클러스터의 KRaft 컨트롤러에 직접 액세스할 필요는 없습니다. 그러나 오픈 모니터링을 사용하여 지표를 수집하는 경우 클러스터에 대한 일부 비컨트롤러 관련 지표를 수집하려면 컨트롤러의 DNS 엔드포인트도 필요합니다. MSK 콘솔에서 또는 [ListNodes](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes.html#ListNodes) API 작업을 사용하여 이러한 DNS 엔드포인트를 가져올 수 있습니다. KRaft 기반 클러스터에 대한 오픈 모니터링 설정을 위한 업데이트된 단계는 [Prometheus를 사용하여 MSK 프로비저닝 클러스터 모니터링](open-monitoring.md) 단원을 참조하세요.
+ ZooKeeper 모드 클러스터를 통해 KRaft 모드 클러스터를 모니터링하는 데 필요한 추가 [CloudWatch 지표](https://docs.aws.amazon.com/msk/latest/developerguide/metrics-details.html)는 없습니다. MSK는 클러스터에 사용되는 KRaft 컨트롤러를 관리합니다.
+ `--bootstrap-server` 연결 문자열을 사용하여 KRaft 모드 클러스터에서 ACL을 계속 관리할 수 있습니다. `--zookeeper` 연결 문자열을 사용하여 ACL을 관리해서는 안 됩니다. [Apache Kafka ACL](msk-acls.md)을(를) 참조하세요.
+ KRaft 모드에서 클러스터의 메타데이터는 외부 ZooKeeper 노드가 아닌 Kafka 내의 KRaft 컨트롤러에 저장됩니다. 따라서 [ZooKeeper 노드와 마찬가지로](https://docs.aws.amazon.com/msk/latest/developerguide/zookeeper-security.html) 컨트롤러 노드에 대한 액세스를 별도로 제어할 필요는 없습니다.
# 주제 작업
Amazon MSK APIs 사용하면 Kafka 관리자 클라이언트를 설정하고 유지 관리할 필요 없이 MSK 프로비저닝 클러스터의 주제를 관리할 수 있습니다. 이러한 APIs 사용하면 보존 및 정리 정책과 같은 구성 설정과 함께 복제 인수 및 파티션 수와 같은 주제 속성을 정의하거나 읽을 수 있습니다. AWS CLI, AWS SDKs 및 AWS CloudFormation을 비롯한 친숙한 인터페이스를 사용하여 Kafka 주제를 프로그래밍 방식으로 관리할 수 있습니다. 이러한 APIs는 Amazon MSK 콘솔에도 통합되어 모든 주제 작업을 한 곳에서 수행할 수 있습니다. 이제 안내 기본값을 사용하여 몇 번의 클릭만으로 주제를 생성하거나 업데이트할 수 있으며 주제 구성, 파티션 수준 정보 및 지표에 대한 포괄적인 가시성을 얻을 수 있습니다.
**중요**
이러한 주제 API 응답은 약 1분마다 업데이트되는 데이터를 반영합니다. 변경 후 최신 주제 상태의 경우 쿼리하기 전에 약 1분 정도 기다려야 합니다.
## 주제 APIs 사용 요구 사항
+ 클러스터는 MSK 프로비저닝 클러스터여야 합니다. MSK Serverless 클러스터에는 이러한 APIs를 사용할 수 없습니다.
+ 클러스터가 Apache Kafka 버전 3.6.0 이상을 실행 중이어야 합니다. 지원되는 버전에 대한 자세한 내용은 섹션을 참조하세요[지원되는 Apache Kafka 버전](supported-kafka-versions.md).
+ 클러스터가 `ACTIVE` 상태여야 합니다. 클러스터 상태에 대한 자세한 내용은 [MSK 프로비저닝된 클러스터의 상태 이해](msk-cluster-states.md) 섹션을 참조하세요.
+ 적절한 IAM 권한이 있어야 합니다. 자세한 내용은 [주제 작업 APIs에 대한 IAM 권한](#topic-operations-permissions) 단원을 참조하십시오.
## 주제 작업 APIs에 대한 IAM 권한
이러한 APIs 호출하려면 적절한 IAM 권한이 있어야 합니다. 다음 표에는 각 API에 필요한 권한이 나열되어 있습니다.
**주제 작업 APIs에 필요한 권한**
| API | 필수 권한 | Resource |
| --- | --- | --- |
| ListTopics | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | 클러스터 ARN, 주제 ARN |
| DescribeTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeTopicDynamicConfiguration` | 클러스터 ARN, 주제 ARN |
| DescribeTopicPartitions | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeTopicDynamicConfiguration` | 클러스터 ARN, 주제 ARN |
| CreateTopic | `kafka-cluster:Connect` `kafka-cluster:CreateTopic` | 클러스터 ARN, 주제 ARN |
| DeleteTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DeleteTopic` | 클러스터 ARN, 주제 ARN |
| UpdateTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterTopic` `kafka-cluster:AlterTopicDynamicConfiguration` | 클러스터 ARN, 주제 ARN |
**참고**
의 경우 IAM 정책에서 클러스터 ARN을 `kafka-cluster:Connect`지정합니다. 다른 모든 작업의 경우 IAM 정책에서 주제 ARN을 지정합니다.
**참고**
의 경우 와일드카드(\$1)를 사용하여 클러스터의 모든 주제를 일치시킬 `ListTopics`수 있습니다. 예를 들어 `arn:aws:kafka:us-east-1:123456789012:topic/my-cluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/*`입니다.
Amazon MSK의 IAM 액세스 제어에 대한 자세한 내용은 섹션을 참조하세요[IAM 액세스 제어](iam-access-control.md).
**Topics**
+ [주제 APIs 사용 요구 사항](#topic-operations-requirements)
+ [주제 작업 APIs에 대한 IAM 권한](#topic-operations-permissions)
+ [Amazon MSK 클러스터의 주제 나열](msk-list-topics.md)
+ [주제에 대한 자세한 정보 가져오기](msk-describe-topic.md)
+ [주제에 대한 파티션 정보 보기](msk-describe-topic-partitions.md)
+ [Amazon MSK 클러스터에서 주제 생성](msk-create-topic.md)
+ [Amazon MSK 클러스터에서 주제 업데이트](msk-update-topic.md)
+ [Amazon MSK 클러스터에서 주제 삭제](msk-delete-topic.md)
# Amazon MSK 클러스터의 주제 나열
MSK 프로비저닝 클러스터의 모든 주제를 나열하여 파티션 수 및 복제 인자와 같은 기본 메타데이터를 볼 수 있습니다. 이는 클러스터의 주제를 모니터링하거나, 인벤토리 검사를 수행하거나, 추가 조사를 위한 주제를 식별하는 데 유용합니다.
**참고**
`ListTopics` API는 기본 주제 메타데이터를 제공합니다. 현재 상태 및 구성을 포함하여 특정 주제에 대한 자세한 정보를 가져오려면 `DescribeTopic` API를 사용합니다. 자세한 내용은 [주제에 대한 자세한 정보 가져오기](msk-describe-topic.md) 단원을 참조하십시오.
**참고**
이 API 응답은 약 1분마다 업데이트되는 데이터를 반영합니다. 변경 후 최신 주제 상태의 경우 쿼리하기 전에 약 1분 정도 기다려야 합니다.
**Topics**
+ [를 사용하여 주제 나열 AWS Management Console](list-topics-console.md)
+ [를 사용하여 주제 나열 AWS CLI](list-topics-cli.md)
+ [API를 사용하여 주제 나열](list-topics-api.md)
# 를 사용하여 주제 나열 AWS Management Console
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) Amazon MSK 콘솔을 엽니다.
1. 클러스터 목록에서 주제를 나열할 클러스터의 이름을 선택합니다.
1. 클러스터 세부 정보 페이지에서 **주제** 탭을 선택합니다.
1. 이 표에는 주제 이름, 파티션 수, 복제 인수, out-of-sync 복제본 수를 포함하여 클러스터의 모든 주제가 표시됩니다.
# 를 사용하여 주제 나열 AWS CLI
다음 명령을 실행하여 *ClusterArn*을 클러스터의 Amazon 리소스 이름(ARN)으로 바꿉니다. 클러스터에 대한 ARN이 없는 경우, 모든 클러스터를 나열하여 찾을 수 있습니다. 자세한 내용은 [Amazon MSK 클러스터 나열](msk-list-clusters.md) 단원을 참조하십시오.
```
aws kafka list-topics --cluster-arn ClusterArn
```
이 명령의 출력은 다음 JSON 예제와 같습니다.
```
{
"topics": [
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"partitionCount": 3,
"replicationFactor": 3,
"outOfSyncReplicaCount": 0
},
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/AnotherTopic",
"topicName": "AnotherTopic",
"partitionCount": 6,
"replicationFactor": 3,
"outOfSyncReplicaCount": 1
}
]
}
```
## 결과 페이지 매김
클러스터에 주제가 많은 경우 페이지 매김을 사용하여 더 작은 배치로 결과를 검색할 수 있습니다. `--max-results` 파라미터를 사용하여 반환할 최대 주제 수를 지정하고 `--next-token` 파라미터를 사용하여 결과의 다음 페이지를 검색합니다.
```
aws kafka list-topics --cluster-arn ClusterArn --max-results 10
```
사용 가능한 결과가 더 있는 경우 응답에 `nextToken` 값이 포함됩니다. 이 토큰을 사용하여 결과의 다음 페이지를 검색합니다.
```
aws kafka list-topics --cluster-arn ClusterArn --max-results 10 --next-token NextToken
```
## 이름을 기준으로 주제 필터링
`--topic-name-filter` 파라미터를 사용하여 접두사를 지정하여 주제 목록을 필터링할 수 있습니다. 그러면 이름이 지정된 접두사로 시작하는 주제만 반환됩니다.
```
aws kafka list-topics --cluster-arn ClusterArn --topic-name-filter "prod-"
```
이 명령은 `prod-orders` 또는 `prod-`와 같이 이름이 로 시작하는 주제만 반환합니다`prod-inventory`.
# API를 사용하여 주제 나열
API를 사용하여 주제를 나열하려면 [ListTopics](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics.html#ListTopics)를 참조하세요.
# 주제에 대한 자세한 정보 가져오기
현재 상태, 파티션 수, 복제 인수 및 구성을 포함하여 MSK 프로비저닝 클러스터의 특정 주제에 대한 자세한 정보를 검색할 수 있습니다. 이는 문제 해결, 주제 설정 검증 또는 작업 중 주제 상태 모니터링에 유용합니다.
**참고**
이 API 응답은 약 1분마다 업데이트되는 데이터를 반영합니다. 변경 후 최신 주제 상태의 경우 쿼리하기 전에 약 1분 정도 기다려야 합니다.
**Topics**
+ [를 사용하여 주제 설명 AWS Management Console](describe-topic-console.md)
+ [를 사용하여 주제 설명 AWS CLI](describe-topic-cli.md)
+ [API를 사용하여 주제 설명](describe-topic-api.md)
# 를 사용하여 주제 설명 AWS Management Console
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) Amazon MSK 콘솔을 엽니다.
1. 클러스터 목록에서 설명할 주제가 포함된 클러스터의 이름을 선택합니다.
1. 클러스터 세부 정보 페이지에서 **주제** 탭을 선택합니다.
1. 주제 목록에서 보려는 주제의 이름을 선택합니다.
1. 주제 세부 정보 페이지에는 상태, 파티션 수, 복제 인수, 구성 설정 등 주제에 대한 정보가 표시됩니다.
# 를 사용하여 주제 설명 AWS CLI
다음 명령을 실행하여 *ClusterArn*을 클러스터의 Amazon 리소스 이름(ARN)으로 바꾸고 *TopicName*을 설명하려는 주제의 이름으로 바꿉니다.
```
aws kafka describe-topic --cluster-arn ClusterArn --topic-name TopicName
```
이 명령의 출력은 다음 JSON 예제와 같습니다.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"partitionCount": 3,
"replicationFactor": 3,
"configs": "Y29tcHJlc3Npb24udHlwZT1wcm9kdWNlcgpyZXRlbnRpb24ubXM9NjA0ODAwMDAw",
"status": "ACTIVE"
}
```
## 주제 상태 이해
`status` 필드는 주제의 현재 상태를 나타냅니다. 다음 표에서는 가능한 상태 값을 설명합니다.
**주제 상태 값**
| Status | 설명 |
| --- | --- |
| 생성 | 주제가 생성 중입니다. |
| ACTIVE | 주제가 활성 상태이고 사용할 준비가 되었습니다. |
| 업데이트 중 | 주제 구성이 업데이트되고 있습니다. |
| DELETING | 주제가 삭제되고 있습니다. |
## 주제 구성 이해
`configs` 필드에는 Base64 형식으로 인코딩된 주제의 Kafka 구성 속성이 포함되어 있습니다. 읽기 가능한 형식으로 구성을 보려면 Base64 문자열을 디코딩해야 합니다.
다음 예제에서는 Linux 또는 macOS에서 `base64` 명령을 사용하여 구성을 디코딩하는 방법을 보여줍니다.
```
echo "Y29tcHJlc3Npb24udHlwZT1wcm9kdWNlcgpyZXRlbnRpb24ubXM9NjA0ODAwMDAw" | base64 --decode
```
디코딩된 출력에는 주제 구성 속성이 키-값 형식으로 표시됩니다.
```
compression.type=producer
retention.ms=604800000
```
주제 수준 구성 속성에 대한 자세한 내용은 섹션을 참조하세요[주제 수준 Amazon MSK 구성](msk-configuration-properties.md#msk-topic-confinguration).
# API를 사용하여 주제 설명
API를 사용하여 주제를 설명하려면 [DescribeTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#DescribeTopic)을 참조하세요.
# 주제에 대한 파티션 정보 보기
MSK 프로비저닝 클러스터에서 특정 주제의 파티션에 대한 자세한 정보를 검색할 수 있습니다. 이 정보에는 파티션 번호, 리더 브로커, 복제본 브로커 및 동기화 내 복제본(ISR)이 포함됩니다. 이는 파티션 배포를 모니터링하거나, 덜 복제된 파티션을 식별하거나, 복제 문제를 해결하는 데 유용합니다.
**참고**
이 API 응답은 약 1분마다 업데이트되는 데이터를 반영합니다. 변경 후 최신 주제 상태를 보려면 쿼리하기 전에 약 1분 정도 기다려야 합니다.
**Topics**
+ [를 사용하여 파티션 정보 보기 AWS Management Console](describe-topic-partitions-console.md)
+ [를 사용하여 파티션 정보 보기 AWS CLI](describe-topic-partitions-cli.md)
+ [API를 사용하여 파티션 정보 보기](describe-topic-partitions-api.md)
# 를 사용하여 파티션 정보 보기 AWS Management Console
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) Amazon MSK 콘솔을 엽니다.
1. 클러스터 목록에서 주제가 포함된 클러스터의 이름을 선택합니다.
1. 클러스터 세부 정보 페이지에서 **주제** 탭을 선택합니다.
1. 주제 목록에서 파티션 정보를 보려는 주제의 이름을 선택합니다.
1. 주제 세부 정보 페이지에 파티션 정보가 표시되며 각 파티션의 파티션 번호, 리더 브로커, 복제본 및 동기화된 복제본이 표시됩니다.
# 를 사용하여 파티션 정보 보기 AWS CLI
다음 명령을 실행하여 *ClusterArn*을 클러스터의 Amazon 리소스 이름(ARN)으로 바꾸고 *TopicName*을 주제 이름으로 바꿉니다.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName
```
이 명령의 출력은 다음 JSON 예제와 같습니다.
```
{
"partitions": [
{
"partition": 0,
"leader": 1,
"replicas": [1, 2, 3],
"isr": [1, 2, 3]
},
{
"partition": 1,
"leader": 2,
"replicas": [2, 3, 1],
"isr": [2, 3, 1]
},
{
"partition": 2,
"leader": 3,
"replicas": [3, 1, 2],
"isr": [3, 1]
}
]
}
```
## 파티션 정보 이해
응답에는 각 파티션에 대한 다음 정보가 포함됩니다.
+ **파티션** - 파티션 번호입니다. 파티션은 0부터 번호가 매겨집니다.
+ **leader** -이 파티션에 대한 리더의 브로커 ID입니다. 리더는 파티션에 대한 모든 읽기 및 쓰기 요청을 처리합니다.
+ **복제본 **-이 파티션의 복제본이 있는 브로커 IDs 목록입니다. 여기에는 동기화 내 복제본과 out-of-sync 복제본이 모두 포함됩니다.
+ **isr** - 동기화된 복제본인 브로커 IDs 목록입니다. 이러한 복제본은 리더와 완전히 연결되며 필요한 경우 리더 역할을 맡을 수 있습니다.
위 예제에서 파티션 2에는 out-of-sync 복제본이 있습니다. `replicas` 목록에는 브로커 2가 포함되지만 `isr` 목록에는 포함되지 않습니다. 이는 브로커 2가이 파티션의 리더와 완전히 연결되지 않았음을 나타냅니다.
## 결과 페이지 매김
주제에 파티션이 많은 경우 페이지 매김을 사용하여 더 작은 배치로 결과를 검색할 수 있습니다. `--max-results` 파라미터를 사용하여 반환할 최대 파티션 수를 지정하고 `--next-token` 파라미터를 사용하여 결과의 다음 페이지를 검색합니다.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName --max-results 10
```
사용 가능한 결과가 더 있는 경우 응답에 `nextToken` 값이 포함됩니다. 이 토큰을 사용하여 결과의 다음 페이지를 검색합니다.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName --max-results 10 --next-token NextToken
```
## 일반 사용 사례
파티션 정보 보기는 여러 시나리오에 유용합니다.
+ **과소 복제된 파티션 식별** - `replicas` 및 `isr` 목록을 비교하여 일부 복제본이 동기화되지 않은 파티션을 식별합니다. 이는 성능 문제 또는 브로커 문제를 나타낼 수 있습니다.
+ **파티션 배포 모니터링** - 파티션 리더가 브로커에 고르게 분산되어 있는지 확인하여 로드가 균형 잡힌지 확인합니다.
+ **복제 문제 해결 **- ISR 목록을 검사하여 복제를 따라잡는 데 문제가 있는 브로커를 식별합니다.
+ **파티션 리밸런싱 계획** - 리밸런싱 작업을 수행하기 전에이 정보를 사용하여 현재 파티션 레이아웃을 이해합니다.
# API를 사용하여 파티션 정보 보기
API를 사용하여 파티션 정보를 보려면 [DescribeTopicPartitions](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname-partitions.html#DescribeTopicPartitions)를 참조하세요.
# Amazon MSK 클러스터에서 주제 생성
사용자 지정 Kafka AdminClient를 설정하지 않고도이 API를 직접 사용하여 MSK 프로비저닝된 클러스터에서 주제를 생성할 수 있습니다. 주제를 생성할 때 주제 이름, 파티션 수, 복제 인수 및 선택적으로 주제 구성을 지정합니다.
**Topics**
+ [를 사용하여 주제 생성 AWS Management Console](create-topic-console.md)
+ [를 사용하여 주제 생성 AWS CLI](create-topic-cli.md)
+ [API를 사용하여 주제 생성](create-topic-api.md)
# 를 사용하여 주제 생성 AWS Management Console
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) Amazon MSK 콘솔을 엽니다.
1. 클러스터 목록에서 주제를 생성할 클러스터의 이름을 선택합니다.
1. 클러스터 세부 정보 페이지에서 **주제** 탭을 선택합니다.
1. **주제 생성**을 선택합니다.
1. 주제 이름, 파티션 수 및 복제 인수를 입력합니다. 선택적으로 구성을 추가합니다. 한 번에 여러 주제를 생성할 수 있습니다.
1. **주제 생성**을 선택합니다.
# 를 사용하여 주제 생성 AWS CLI
다음 명령을 실행하여 *ClusterArn*을 클러스터의 Amazon 리소스 이름(ARN)으로 바꿉니다. 클러스터에 대한 ARN이 없는 경우, 모든 클러스터를 나열하여 찾을 수 있습니다. 자세한 내용은 [Amazon MSK 클러스터 나열](msk-list-clusters.md) 단원을 참조하십시오.
```
aws kafka create-topic --cluster-arn ClusterArn --topic-name MyTopic --partition-count 3 --replication-factor 3
```
이 명령의 출력은 다음 JSON 예제와 같습니다.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "CREATING"
}
```
# API를 사용하여 주제 생성
API를 사용하여 주제를 생성하려면 [CreateTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics.html#CreateTopic)을 참조하세요.
# Amazon MSK 클러스터에서 주제 업데이트
기존 주제에 대한 파티션 수 또는 주제 수준 구성을 업데이트합니다. 이 작업은 재생성 없이 주제를 수정합니다.
**참고**
단일 API 호출에서 파티션 수 또는 주제 구성을 업데이트할 수 있지만 둘 다 동시에 업데이트할 수는 없습니다. 둘 다 업데이트하려면 별도의 API 직접 호출을 수행합니다.
**Topics**
+ [를 사용하여 주제 업데이트 AWS Management Console](update-topic-console.md)
+ [를 사용하여 주제 업데이트 AWS CLI](update-topic-cli.md)
+ [API를 사용하여 주제 업데이트](update-topic-api.md)
# 를 사용하여 주제 업데이트 AWS Management Console
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) Amazon MSK 콘솔을 엽니다.
1. 클러스터 목록에서 업데이트하려는 주제가 포함된 클러스터의 이름을 선택합니다.
1. 클러스터 세부 정보 페이지에서 **주제** 탭을 선택합니다.
1. 업데이트할 주제를 선택한 다음 **작업**에서 **파티션 설정 편집** 또는 **구성 편집**을 선택합니다.
1. 필요에 따라 파티션 수 또는 구성을 업데이트합니다.
1. **저장**을 선택합니다.
# 를 사용하여 주제 업데이트 AWS CLI
다음 명령을 실행하여 *ClusterArn*을 클러스터의 Amazon 리소스 이름(ARN)으로 바꾸고 *TopicName*을 업데이트하려는 주제의 이름으로 바꿉니다.
```
aws kafka update-topic --cluster-arn ClusterArn --topic-name TopicName --partition-count 6
```
이 명령의 출력은 다음 JSON 예제와 같습니다.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "UPDATING"
}
```
# API를 사용하여 주제 업데이트
API를 사용하여 주제를 업데이트하려면 [UpdateTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#UpdateTopic)을 참조하세요.
# Amazon MSK 클러스터에서 주제 삭제
주제를 삭제하면 모든 데이터, 메타데이터 및 파티션 정보가 영구적으로 제거됩니다. 이 작업은 실행 취소할 수 없습니다.
**Topics**
+ [를 사용하여 주제 삭제 AWS Management Console](delete-topic-console.md)
+ [를 사용하여 주제 삭제 AWS CLI](delete-topic-cli.md)
+ [API를 사용하여 주제 삭제](delete-topic-api.md)
# 를 사용하여 주제 삭제 AWS Management Console
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) Amazon MSK 콘솔을 엽니다.
1. 클러스터 목록에서 삭제하려는 주제가 포함된 클러스터의 이름을 선택합니다.
1. 클러스터 세부 정보 페이지에서 **주제** 탭을 선택합니다.
1. 삭제할 주제를 선택한 다음 **작업**에서 **삭제**를 선택합니다.
1. 삭제를 확인한 다음 **삭제**를 선택합니다.
# 를 사용하여 주제 삭제 AWS CLI
다음 명령을 실행하여 *ClusterArn*을 클러스터의 Amazon 리소스 이름(ARN)으로 바꾸고 *TopicName*을 삭제하려는 주제의 이름으로 바꿉니다.
```
aws kafka delete-topic --cluster-arn ClusterArn --topic-name TopicName
```
이 명령의 출력은 다음 JSON 예제와 같습니다.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "DELETING"
}
```
# API를 사용하여 주제 삭제
API를 사용하여 주제를 삭제하려면 [DeleteTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#DeleteTopic)을 참조하세요.
# Amazon MSK 리소스
Amazon MSK에서는 상황에 따라 *리소스*라는 용어에 두 가지 의미가 있습니다. API의 컨텍스트에서 리소스는 작업을 간접적으로 호출할 수 있는 구조입니다. 이러한 리소스의 목록과 해당 리소스에 대해 호출할 수 있는 작업은 Amazon MSK API 참조의 [리소스](https://docs.aws.amazon.com/msk/1.0/apireference/resources.html)를 참조하세요. [IAM 액세스 제어](iam-access-control.md)의 컨텍스트에서 리소스는 [권한 부여 정책 리소스](kafka-actions.md#msk-iam-resources) 섹션에 정의된 대로 액세스를 허용하거나 거부할 수 있는 엔터티입니다.
# Apache Kafka 버전
Amazon MSK 클러스터를 생성하는 경우 클러스터에 설치할 Apache Kafka 버전을 지정합니다. 또한 기존 클러스터의 Apache Kafka 버전을 업데이트할 수 있습니다. 이 장의 주제는 Kafka 버전 지원의 타임라인과 모범 사례에 대한 제안을 이해하는 데 도움이 됩니다.
**Topics**
+ [지원되는 Apache Kafka 버전](supported-kafka-versions.md)
+ [Amazon MSK 버전 지원](version-support.md)
# 지원되는 Apache Kafka 버전
Amazon Managed Streaming for Apache Kafka(Amazon MSK)는 다음 Apache Kafka 및 Amazon MSK 버전을 지원합니다. Apache Kafka 커뮤니티는 릴리스 날짜 이후 버전에 대해 약 12개월 동안 지원합니다. 자세한 내용은 [Apache Kafka 수명 종료(EOL) 정책](https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan#TimeBasedReleasePlan-WhatIsOurEOLPolicy?)을 참조하세요.
다음 표에는 Amazon MSK가 지원하는 Apache Kafka 버전이 나열되어 있습니다.
| Apache Kafka 버전 | MSK 릴리스 날짜 | 지원 종료일 |
| --- | --- | --- |
| [1.1.1](https://archive.apache.org/dist/kafka/1.1.1/RELEASE_NOTES.html) | -- | 2024-06-05 |
| [2.1.0](https://archive.apache.org/dist/kafka/2.1.0/RELEASE_NOTES.html) | -- | 2024-06-05 |
| [2.2.1](https://archive.apache.org/dist/kafka/2.2.1/RELEASE_NOTES.html) | 2019년 7월 31일 | 2024-06-08 |
| [2.3.1](https://archive.apache.org/dist/kafka/2.3.1/RELEASE_NOTES.html) | 2019년 12월 19일 | 2024-06-08 |
| [2.4.1](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) | 2020년 4월 2일 | 2024-06-08 |
| [2.4.1.1](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) | 2020-09-09 | 2024-06-08 |
| [2.5.1](https://archive.apache.org/dist/kafka/2.5.1/RELEASE_NOTES.html) | 2020-09-30 | 2024-06-08 |
| [2.6.0](https://archive.apache.org/dist/kafka/2.6.0/RELEASE_NOTES.html) | 2020-10-21 | 2024-09-11 |
| [2.6.1](https://archive.apache.org/dist/kafka/2.6.1/RELEASE_NOTES.html) | 2021-01-19 | 2024-09-11 |
| [2.6.2](https://archive.apache.org/dist/kafka/2.6.2/RELEASE_NOTES.html) | 2021-04-29 | 2024-09-11 |
| [2.6.3](https://archive.apache.org/dist/kafka/2.6.3/RELEASE_NOTES.html) | 2021-12-21 | 2024-09-11 |
| [2.7.0](https://archive.apache.org/dist/kafka/2.7.0/RELEASE_NOTES.html) | 2020-12-29 | 2024-09-11 |
| [2.7.1](https://archive.apache.org/dist/kafka/2.7.1/RELEASE_NOTES.html) | 2021-05-25 | 2024-09-11 |
| [2.7.2](https://archive.apache.org/dist/kafka/2.7.2/RELEASE_NOTES.html) | 2021-12-21 | 2024-09-11 |
| [2.8.0](https://archive.apache.org/dist/kafka/2.8.0/RELEASE_NOTES.html) | 2021-05-19 | 2024-09-11 |
| [2.8.1](https://archive.apache.org/dist/kafka/2.8.1/RELEASE_NOTES.html) | 2022-10-28 | 2024-09-11 |
| [2.8.2-tiered](https://archive.apache.org/dist/kafka/2.8.2/RELEASE_NOTES.html) | 2022-10-28 | 2025-01-14 |
| [3.1.1](https://archive.apache.org/dist/kafka/3.1.1/RELEASE_NOTES.html) | 2022-06-22 | 2024-09-11 |
| [3.2.0](https://archive.apache.org/dist/kafka/3.2.0/RELEASE_NOTES.html) | 2022-06-22 | 2024-09-11 |
| [3.3.1](https://archive.apache.org/dist/kafka/3.3.1/RELEASE_NOTES.html) | 2022-10-26 | 2024-09-11 |
| [3.3.2](https://archive.apache.org/dist/kafka/3.3.2/RELEASE_NOTES.html) | 2023-03-02 | 2024-09-11 |
| [3.4.0](https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html) | 2023-05-04 | 2025-08-04 |
| [3.5.1](https://archive.apache.org/dist/kafka/3.5.1/RELEASE_NOTES.html) | 2023-09-26 | 2025-10-23 |
| [3.6.0](https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html) | 2023-11-16 | 2026-06-01 |
| [3.7.x](https://archive.apache.org/dist/kafka/3.7.0/RELEASE_NOTES.html) | 2024-05-29 | -- |
| [3.8.x](https://downloads.apache.org/kafka/3.8.0/RELEASE_NOTES.html) | 2025-02-20 | -- |
| [3.9.x](https://downloads.apache.org/kafka/3.9.0/RELEASE_NOTES.html)(권장) | 2025-04-21 | -- |
| [4.0.x](https://downloads.apache.org/kafka/4.0.0/RELEASE_NOTES.html) | 2025-05-16 | -- |
| [4.1.x](https://downloads.apache.org/kafka/4.1.0/RELEASE_NOTES.html) | 2025-10-15 | -- |
Amazon MSK 버전 지원 정책에 대한 자세한 내용은 [Amazon MSK 버전 지원 정책](version-support.md#version-support-policy) 섹션을 참조하세요.
## Amazon MSK 버전 4.1.x
Amazon Managed Streaming for Apache Kafka(Amazon MSK)는 이제 미리 보기 기능으로 대기열, 조기 액세스의 새로운 스트림 리밸런싱 프로토콜, 적격 리더 복제본(ELR)을 도입하는 Apache Kafka 버전 4.1을 지원합니다. 이러한 기능과 함께 Apache Kafka 버전 4.1에는 다양한 버그 수정 및 개선 사항이 포함되어 있습니다.
Kafka 4.1의 주요 하이라이트는 미리 보기 기능으로 대기열을 도입하는 것입니다. 여러 컨슈머를 사용하여 동일한 토픽 파티션의 메시지를 처리하여 포인트 투 포인트 메시지 전송이 필요한 워크로드의 병렬 처리 및 처리량을 개선할 수 있습니다. 새로운 스트림 리밸런싱 프로토콜은 Kafka 4.0의 컨슈머 리밸런싱 프로토콜을 기반으로 하며 최적화된 작업 할당 및 리밸런싱을 위해 브로커 규모 조정 기능을 Kafka Streams로 확장합니다. 또한 이제 가용성을 강화하기 위해 ELR이 기본적으로 활성화됩니다.
자세한 사항 및 전체 개선 사항, 버그 수정 목록은 [Apache Kafka 버전 4.1에 대한 릴리스 정보](https://downloads.apache.org/kafka/4.1.0/RELEASE_NOTES.html)를 참조하세요.
Amazon MSK에서 Apache Kafka 4.1 사용을 시작하려면 AWS Management Console AWS CLI또는 AWS SDKs를 통해 새 클러스터를 생성할 때 버전 4.1.x를 선택합니다. 인플레이스 롤링 업데이트를 사용하여 기존 MSK 프로비저닝 클러스터를 업그레이드할 수도 있습니다. Amazon MSK는 브로커를 다시 시작하여 가용성을 유지하고 업그레이드 중에 데이터를 보호합니다. Kafka 버전 4.1 지원은 Amazon MSK가 제공되는 모든 AWS 리전 에서 사용할 수 있습니다.
## Amazon MSK 버전 4.0.x
Amazon Managed Streaming for Apache Kafka(Amazon MSK)는 이제 Apache Kafka 버전 4.0을 지원합니다. 이 버전은 클러스터 관리 및 성능의 최신 발전을 MSK Provisioned에 제공합니다. Kafka 4.0은 이제 일반적으로 사용할 수 있는 새로운 컨슈머 리밸런싱 프로토콜을 도입하여 더 원활하고 빠른 그룹 리밸런싱을 보장합니다. 또한 Kafka 4.0은 Java 17을 사용하기 위해 브로커와 도구가 필요하며, 향상된 보안 및 성능을 제공하고, 다양한 버그 수정 및 개선 사항을 포함하고, Apache ZooKeeper를 통한 메타데이터 관리를 중단합니다.
자세한 사항 및 전체 개선 사항, 버그 수정 목록은 [Apache Kafka 버전 4.0에 대한 릴리스 정보](https://downloads.apache.org/kafka/4.0.0/RELEASE_NOTES.html)를 참조하세요.
## Amazon MSK 버전 3.9.x(권장)
Amazon Managed Streaming for Apache Kafka(Amazon MSK)는 이제 Apache Kafka 버전 3.9을 지원합니다. 이 버전은 토픽 수준에서 계층형 스토리지를 비활성화할 때 계층형 데이터를 유지할 수 있도록 하여 계층형 스토리지 기능을 개선합니다. 컨슈머 애플리케이션은 로컬 및 원격 스토리지에서 연속 로그 오프셋을 유지하면서 원격 로그 시작 오프셋(Rx)에서 기록 데이터를 읽을 수 있습니다.
버전 3.9는 ZooKeeper 및 KRaft 메타데이터 관리 시스템을 모두 지원하는 마지막 버전입니다. Amazon MSK는 릴리스 날짜로부터 최소 2년 동안 버전 3.9에 대한 추가 지원을 제공합니다.
자세한 사항 및 전체 개선 사항, 버그 수정 목록은 [Apache Kafka 버전 3.9.x에 대한 릴리스 정보](https://downloads.apache.org/kafka/3.9.0/RELEASE_NOTES.html)를 참조하세요.
## Amazon MSK 버전 3.8.x
Amazon Managed Streaming for Apache Kafka(Amazon MSK)는 이제 Apache Kafka 버전 3.8을 지원합니다. 이제 메타데이터 관리를 위해 KRAFT 또는 ZooKeeper 모드와 함께 버전 3.8을 사용하여 새 클러스터를 생성하거나 버전 3.8을 사용하도록 기존 ZooKeeper 기반 클러스터를 업그레이드할 수 있습니다. Apache Kafka 버전 3.8에는 성능을 개선하는 몇 가지 버그 수정 사항과 새로운 기능이 포함되어 있습니다. 새로운 주요 기능에는 압축 수준 구성에 대한 지원이 포함됩니다. 이렇게 하면 기본 압축 수준을 변경할 수 있으므로 lz4, zstd 및 gzip과 같은 압축 유형을 사용할 때 성능을 더욱 최적화할 수 있습니다.
자세한 사항 및 전체 개선 사항, 버그 수정 목록은 [Apache Kafka 버전 3.8.x에 대한 릴리스 정보](https://downloads.apache.org/kafka/3.8.0/RELEASE_NOTES.html)를 참조하세요.
## Apache Kafka 버전 3.7.x(프로덕션 환경 사용 가능 계층형 스토리지 포함)
MSK의 Apache Kafka 버전 3.7.x에는 Apache Kafka 버전 3.7.0에 대한 지원이 포함되어 있습니다. 새로운 3.7.x 버전을 사용하도록 클러스터를 생성하거나 기존 클러스터를 업그레이드할 수 있습니다. 버전 이름이 변경되면 Apache Kafka 커뮤니티에서 릴리스할 때 3.7.1과 같은 최신 패치 수정 버전을 더 이상 채택할 필요가 없습니다. Amazon MSK는 향후 패치 버전이 출시되면 해당 버전을 지원하도록 3.7.x를 자동으로 업데이트합니다. 자동 업데이트 덕분에 버전 업그레이드를 트리거하지 않고도 패치 수정 버전을 통해 사용할 수 있는 보안 및 버그 수정의 이점을 누릴 수 있습니다. Apache Kafka에서 릴리스한 이러한 패치 수정 버전은 버전 호환성을 저하시키지 않으며 클라이언트 애플리케이션의 읽기 또는 쓰기 오류에 대한 걱정 없이 새로운 패치 수정 버전의 이점을 누릴 수 있습니다. CloudFormation과 같은 인프라 자동화 도구가 버전 이름 변경 사항을 반영하도록 업데이트되었는지 확인하세요.
Amazon MSK는 이제 Apache Kafka 버전 3.7.x에서 KRaft 모드(Apache Kafka Raft)를 지원합니다. Amazon MSK에서는 ZooKeeper 노드와 마찬가지로 KRaft 컨트롤러가 추가 비용 없이 포함되어 있으므로 추가 설정이나 관리가 필요하지 않습니다. 이제 Apache Kafka 버전 3.7.x의 KRaft 모드 또는 ZooKeeper 모드에서 클러스터를 생성할 수 있습니다. Kraft 모드에서는 Zookeeper 기반 클러스터의 30개 브로커 할당량에 비해 제한 증가를 요청하지 않고 클러스터당 더 많은 파티션을 호스팅할 수 있도록 최대 60개의 브로커를 추가할 수 있습니다. MSK의 KRaft에 대한 자세한 내용은 [KRaft 모드](metadata-management.md#kraft-intro)를 참조하세요.
Apache Kafka 버전 3.7.x에는 성능을 개선하는 몇 가지 버그 수정 사항과 새로운 기능도 포함되어 있습니다. 주요 개선 사항으로는 클라이언트를 위한 리더 검색 최적화와 로그 세그먼트 플러시 최적화 옵션이 있습니다. 전체 개선 사항 및 버그 수정 목록은 [3.7.0](https://archive.apache.org/dist/kafka/3.7.0/RELEASE_NOTES.html)에 대한 Apache Kafka 릴리스 정보를 참조하세요.
## Apache Kafka 버전 3.6.0(프로덕션 환경 사용 가능 계층형 스토리지 포함)
Apache Kafka 버전 3.6.0(프로덕션 환경 사용 가능 계층형 스토리지 포함)에 대한 자세한 내용은 Apache Kafka 다운로드 사이트의 [릴리스 정보](https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html)를 참조하세요.
Amazon MSK에서는 안정성을 위해 이번 릴리스에서도 쿼럼 관리용으로 ZooKeeper를 계속 사용하고 관리할 예정입니다.
## Amazon MSK 버전 3.5.1
Amazon Managed Streaming for Apache Kafka(Amazon MSK)는 이제 새로운 클러스터와 기존 클러스터에 대해 Apache Kafka 버전 3.5.1을 지원합니다. Apache Kafka 3.5.1에는 성능을 개선하는 몇 가지 버그 수정 사항과 새로운 기능이 포함되어 있습니다. 주요 기능으로는 소비자를 위한 새로운 랙 인식 파티션 할당 도입이 포함됩니다. Amazon MSK는 이번 릴리스에서도 쿼럼 관리용으로 ZooKeeper를 계속 사용하고 관리할 예정입니다. 전체 개선 사항 및 버그 수정 목록은 3.5.1에 대한 Apache Kafka 릴리스 정보를 참조하세요.
Apache Kafka 버전 3.5.1에 대한 자세한 내용은 Apache Kafka 다운로드 사이트의 [릴리스 정보](https://archive.apache.org/dist/kafka/3.5.1/RELEASE_NOTES.html)를 참조하세요.
## Amazon MSK 버전 3.4.0
Amazon Managed Streaming for Apache Kafka(Amazon MSK)는 이제 새로운 클러스터와 기존 클러스터에 대해 Apache Kafka 버전 3.4.0을 지원합니다. Apache Kafka 3.4.0에는 성능을 개선하는 몇 가지 버그 수정 사항과 새로운 기능이 포함되어 있습니다. 주요 기능으로는 가장 가까운 복제본에서 가져올 수 있도록 안정성을 개선하는 수정 사항이 있습니다. Amazon MSK는 이번 릴리스에서도 쿼럼 관리용으로 ZooKeeper를 계속 사용하고 관리할 예정입니다. 전체 개선 사항 및 버그 수정 목록은 3.4.0에 대한 Apache Kafka 릴리스 정보를 참조하세요.
Apache Kafka 버전 3.4.0에 대한 자세한 내용은 Apache Kafka 다운로드 사이트의 [릴리스 정보](https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html)를 참조하세요.
## Amazon MSK 버전 3.3.2
Amazon Managed Streaming for Apache Kafka(Amazon MSK)는 이제 새로운 클러스터와 기존 클러스터에 대해 Apache Kafka 버전 3.3.2를 지원합니다. Apache Kafka 3.3.2에는 성능을 개선하는 몇 가지 버그 수정 사항과 새로운 기능이 포함되어 있습니다. 주요 기능으로는 가장 가까운 복제본에서 가져올 수 있도록 안정성을 개선하는 수정 사항이 있습니다. Amazon MSK는 이번 릴리스에서도 쿼럼 관리용으로 ZooKeeper를 계속 사용하고 관리할 예정입니다. 전체 개선 사항 및 버그 수정 목록은 3.3.2에 대한 Apache Kafka 릴리스 정보를 참조하세요.
Apache Kafka 버전 3.3.2에 대한 자세한 내용은 Apache Kafka 다운로드 사이트의 [릴리스 정보](https://archive.apache.org/dist/kafka/3.3.2/RELEASE_NOTES.html)를 참조하세요.
## Amazon MSK 버전 3.3.1
Amazon Managed Streaming for Apache Kafka(Amazon MSK)는 이제 새로운 클러스터와 기존 클러스터에 대해 Apache Kafka 버전 3.3.1을 지원합니다. Apache Kafka 3.3.1에는 성능을 개선하는 몇 가지 버그 수정 사항과 새로운 기능이 포함되어 있습니다. 일부 주요 기능으로는 지표 및 파티셔너에 대한 개선 사항이 있습니다. Amazon MSK에서는 안정성을 위해 이번 릴리스에서도 쿼럼 관리용으로 ZooKeeper를 계속 사용하고 관리할 예정입니다. 전체 개선 사항 및 버그 수정 목록은 3.3.1에 대한 Apache Kafka 릴리스 정보를 참조하세요.
Apache Kafka 버전 3.3.1에 대한 자세한 내용은 Apache Kafka 다운로드 사이트의 [릴리스 정보](https://archive.apache.org/dist/kafka/3.3.1/RELEASE_NOTES.html)를 참조하세요.
## Amazon MSK 버전 3.1.1
Amazon Managed Streaming for Apache Kafka(Amazon MSK)는 이제 새로운 클러스터와 기존 클러스터에 대해 Apache Kafka 버전 3.1.1 및 3.2.0을 지원합니다. Apache Kafka 3.1.1 및 Apache Kafka 3.2.0에는 성능을 개선하는 몇 가지 버그 수정 사항과 새로운 기능이 포함되어 있습니다. 일부 주요 기능으로는 지표 개선 사항과 주제 ID 사용이 있습니다. MSK에서는 안정성을 위해 이번 릴리스에서도 쿼럼 관리용으로 ZooKeeper를 계속 사용하고 관리할 예정입니다. 전체 개선 사항 및 버그 수정 목록은 3.1.1 및 3.2.0에 대한 Apache Kafka 릴리스 정보를 참조하세요.
Apache Kafka 버전 3.1.1 및 3.2.0에 대한 자세한 내용은 Apache Kafka 다운로드 사이트의 [3.2.0 릴리스 정보](https://archive.apache.org/dist/kafka/3.2.0/RELEASE_NOTES.html) 및 [3.1.1 릴리스 정보](https://archive.apache.org/dist/kafka/3.1.1/RELEASE_NOTES.html)를 참조하세요.
## Amazon MSK 계층형 스토리지 버전 2.8.2.tiered
이번 릴리즈는 Apache Kafka 버전 2.8.2의 Amazon MSK 전용 버전이며, 오픈 소스 Apache Kafka 클라이언트와 호환됩니다.
2.8.2.tiered 릴리즈에는 [Apache Kafka용 KIP-405](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage)에 도입된 API와 호환되는 계층형 스토리지 기능이 포함되어 있습니다. Amazon MSK 계층형 스토리지 기능에 대한 자세한 내용은 [Standard 브로커를 위한 계층형 스토리지](msk-tiered-storage.md) 섹션을 참조하세요.
## Apache Kafka 버전 2.5.1
Apache Kafka 버전 2.5.1에는 몇 가지 버그 수정과 새로운 기능이 포함되어 있으며, 여기에는 Apache ZooKeeper 및 관리 클라이언트를 위한 전송 중 암호화가 포함됩니다. Amazon MSK는 [DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster) 작업으로 쿼리할 수 있는 TLS ZooKeeper 엔드포인트를 제공합니다.
[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster) 작업의 출력에는 TLS ZooKeeper 엔드포인트를 나열하는 `ZookeeperConnectStringTls` 노드가 포함되어 있습니다.
다음 예제는 `DescribeCluster` 작업에 대한 응답의 `ZookeeperConnectStringTls` 노드를 보여줍니다.
```
"ZookeeperConnectStringTls": "z-3.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182,z-2.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182,z-1.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182"
```
Zookeeper를 사용한 TLS 암호화 사용에 대한 자세한 내용은 [Apache ZooKeeper에서 TLS 보안 사용](zookeeper-security-tls.md) 섹션을 참조하세요.
Apache Kafka 버전 2.5.1에 대한 자세한 내용은 Apache Kafka 다운로드 사이트의 [릴리스 정보](https://archive.apache.org/dist/kafka/2.5.1/RELEASE_NOTES.html)를 참조하세요.
## Amazon MSK 버그 수정 버전 2.4.1.1
이 릴리스는 Apache Kafka 버전 2.4.1의 Amazon MSK 전용 버그 수정 버전입니다. 이 버그 수정 릴리스에는 소비자 그룹이 지속적으로 재조정되어 `PreparingRebalance` 상태를 유지하는 드문 문제인 [KAFKA-9752](https://issues.apache.org/jira/browse/KAFKA-9752) 관련 수정 사항이 포함되어 있습니다. 이 문제는 Apache Kafka 버전 2.3.1 및 2.4.1을 실행하는 클러스터에 영향을 미칩니다. 이 릴리스에는 Apache Kafka 버전 2.5.0에서 사용 가능한 커뮤니티 제작 수정 사항이 포함되어 있습니다.
**참고**
버전 2.4.1.1을 실행하는 Amazon MSK 클러스터는 Apache Kafka 버전 2.4.1과 호환되는 모든 Apache Kafka 클라이언트와 호환됩니다.
Apache Kafka 2.4.1을 사용하시려면 새로운 Amazon MSK 클러스터에 MSK 버그 수정 버전 2.4.1.1을 사용하는 것을 권장합니다. 이 수정 사항을 적용하려면 Apache Kafka 버전 2.4.1을 실행하는 기존 클러스터를 이 버전으로 업데이트하면 됩니다. 기존 클러스터 업그레이드에 대한 자세한 내용은 [Apache Kafka 버전 업그레이드](version-upgrades.md) 섹션을 참조하세요.
클러스터를 버전 2.4.1.1로 업그레이드하지 않고 이 문제를 해결하려면 [Amazon MSK 클러스터 문제 해결](troubleshooting.md) 설명서의 [`PreparingRebalance` 상태에 멈춘 소비자 그룹](troubleshooting.md#consumer-group-rebalance) 섹션을 참조하세요.
## Apache Kafka 버전 2.4.1(대신 2.4.1.1 사용)
**참고**
Apache Kafka 버전 2.4.1에서는 더 이상 MSK 클러스터를 생성할 수 없습니다. 대신 Apache Kafka 버전 2.4.1과 호환되는 클라이언트에서 [Amazon MSK 버그 수정 버전 2.4.1.1](#2.4.1.1)을 사용할 수 있습니다. 또한 이미 Apache Kafka 버전 2.4.1이 설치된 MSK 클러스터가 있는 경우 대신 Apache Kafka 버전 2.4.1.1을 사용하도록 업데이트하는 것을 권장합니다.
KIP-392는 Apache Kafka 2.4.1 릴리스에 포함된 주요 Kafka 개선 제안 중 하나입니다. 이러한 개선 사항을 통해 소비자는 가장 가까운 복제본에서 가져올 수 있게 되었습니다. 이 기능을 사용하려면 소비자 속성의 `client.rack`을 소비자의 가용 영역 ID로 설정합니다. AZ ID의 예는 `use1-az1`입니다. Amazon MSK는 `broker.rack`을 브로커의 가용 영역 ID로 설정합니다. 또한 `replica.selector.class` 구성 속성을 Apache Kafka에서 제공하는 랙 인식의 구현인 `org.apache.kafka.common.replica.RackAwareReplicaSelector`로 설정해야 합니다.
이 버전의 Apache Kafka를 사용하면 `PER_TOPIC_PER_BROKER` 모니터링 수준의 지표는 해당 값이 처음으로 0이 아닌 값이 된 후에만 나타납니다. 자세한 내용은 [`PER_TOPIC_PER_BROKER` 수준 모니터링](metrics-details.md#broker-topic-metrics) 단원을 참조하십시오.
가용 영역 IDs를 찾는 방법에 대한 자세한 내용은 AWS Resource Access Manager 사용 설명서의 [리소스의 AZ IDs](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html)를 참조하세요.
구성 속성 설정에 대한 자세한 내용은 [Amazon MSK Provisioned 구성](msk-configuration.md) 단원을 참조하십시오.
KIP-392에 대한 자세한 내용은 Confluence 페이지의 [Allow Consumers to Fetch from Closest Replica](https://cwiki.apache.org/confluence/display/KAFKA/KIP-392:+Allow+consumers+to+fetch+from+closest+replica)를 참조하십시오.
Apache Kafka 버전 2.4.1에 대한 자세한 내용은 Apache Kafka 다운로드 사이트의 [릴리스 정보](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html)를 참조하십시오.
# Amazon MSK 버전 지원
이 주제에서는 [Amazon MSK 버전 지원 정책](#version-support-policy) 및 [Apache Kafka 버전 업그레이드](version-upgrades.md)에 대한 절차를 설명합니다. Kafka 버전을 업그레이드하는 경우 [버전 업그레이드의 모범 사례](version-upgrades-best-practices.md)에 설명된 모범 사례를 따르세요.
**Topics**
+ [Amazon MSK 버전 지원 정책](#version-support-policy)
+ [Apache Kafka 버전 업그레이드](version-upgrades.md)
+ [버전 업그레이드의 모범 사례](version-upgrades-best-practices.md)
## Amazon MSK 버전 지원 정책
이 섹션에서는 Amazon MSK 지원 Kafka 버전에 대한 지원 정책을 설명합니다.
+ 모든 Kafka 버전은 지원 종료일에 도달할 때까지 지원됩니다. 지원 종료일에 대한 자세한 내용은 [지원되는 Apache Kafka 버전](supported-kafka-versions.md) 단원을 참조하세요. MSK 클러스터를 지원 종료일 전에 권장 Kafka 버전 이상으로 업그레이드합니다. Apache Kafka 버전 업그레이드에 대한 자세한 내용은 [Apache Kafka 버전 업그레이드](version-upgrades.md) 섹션을 참조하세요. 지원 종료일 후 Kafka 버전을 사용하는 클러스터는 권장 Kafka 버전으로 자동 업그레이드됩니다. 자동 업그레이드는 지원 종료 날짜 이후 언제든지 발생할 수 있습니다. 업그레이드 전에는 알림이 제공되지 않습니다.
+ MSK는 새로 생성된 클러스터에서 지원 종료일이 공개된 Kafka 버전을 사용하는 경우 이러한 클러스터에 대한 지원을 단계적으로 중단합니다.
# Apache Kafka 버전 업그레이드
기존 MSK 클러스터를 최신 버전의 Apache Kafka로 업그레이드할 수 있습니다. 클러스터의 Kafka 버전을 업그레이드하기 전에 클라이언트 측 소프트웨어 버전이 새 Kafka 버전의 기능을 지원하는지 확인합니다.
업그레이드 중에 클러스터를 고가용성으로 만드는 방법에 대한 자세한 내용은 [고가용성 클러스터 빌드](bestpractices.md#ensure-high-availability) 섹션을 참조하세요.
**를 사용하여 Apache Kafka 버전 업그레이드 AWS Management Console**
1. [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/)에서 Amazon MSK 콘솔을 엽니다.
1. 탐색 모음에서 MSK 클러스터를 생성한 리전을 선택합니다.
1. 업그레이드하려는 MSK 클러스터를 선택합니다.
1. **속성** 탭의 **Apache Kafka 버전** 섹션에서 **업그레이드**를 선택합니다.
1. **Apache Kafka 버전** 섹션에서 다음을 수행합니다.
1. *Apache Kafka 버전 선택* 드롭다운 목록에서 업그레이드할 대상 버전을 선택합니다. 예를 들어 **3.9.x**를 선택합니다.
1. (선택 사항) **버전 호환성 보기**를 선택하여 클러스터의 현재 버전과 사용 가능한 업그레이드 버전 간의 호환성을 확인합니다. 그런 다음 **선택**을 선택하여 계속 진행합니다.
**참고**
Amazon MSK는 대부분의 Apache Kafka 버전으로의 현재 위치 업그레이드를 지원합니다. 그러나 ZooKeeper 기반 Kafka 버전에서 KRaft 기반 버전으로 업그레이드할 때는 새 클러스터를 생성해야 합니다. 그런 다음 데이터를 새 클러스터에 복사하고 클라이언트를 새 클러스터로 전환합니다.
1. (선택 사항) **클러스터 구성 업데이트** 확인란을 선택하여 새 버전과 호환되는 구성 업데이트를 적용합니다. 이렇게 하면 새 버전의 기능과 개선 사항이 활성화됩니다.
기존 사용자 지정 구성을 유지 관리해야 하는 경우 이 단계를 건너뛸 수 있습니다.
**참고**
서버 측 업그레이드는 클라이언트 애플리케이션을 자동으로 업데이트하지 않습니다.
클러스터 안정성을 유지하기 위해 버전 다운그레이드는 지원되지 않습니다.
1. **업그레이드**를 선택하여 프로세스를 시작합니다.
**를 사용하여 Apache Kafka 버전 업그레이드 AWS CLI**
1. 다음 명령을 실행하여 *ClusterArn*을 클러스터 생성 후 받은 Amazon 리소스 이름(ARN)으로 바꿉니다. 클러스터에 대한 ARN이 없는 경우, 모든 클러스터를 나열하여 찾을 수 있습니다. 자세한 내용은 [Amazon MSK 클러스터 나열](msk-list-clusters.md) 단원을 참조하십시오.
```
aws kafka get-compatible-kafka-versions --cluster-arn ClusterArn
```
이 명령의 출력에는 클러스터를 업그레이드할 수 있는 Apache Kafka 버전 목록이 포함되어 있습니다. 다음 예제와 같습니다.
```
{
"CompatibleKafkaVersions": [
{
"SourceVersion": "2.2.1",
"TargetVersions": [
"2.3.1",
"2.4.1",
"2.4.1.1",
"2.5.1"
]
}
]
}
```
1. 다음 명령을 실행하여 *ClusterArn*을 클러스터 생성 후 받은 Amazon 리소스 이름(ARN)으로 바꿉니다. 클러스터에 대한 ARN이 없는 경우, 모든 클러스터를 나열하여 찾을 수 있습니다. 자세한 내용은 [Amazon MSK 클러스터 나열](msk-list-clusters.md) 단원을 참조하십시오.
*Current-Cluster-Version*을 클러스터의 현재 버전으로 바꿉니다. *TargetVersion*의 경우 이전 명령의 출력에서 대상 버전을 지정할 수 있습니다.
**중요**
클러스터 버전은 단순한 정수가 아닙니다. 클러스터의 현재 버전을 찾으려면 [DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster) 작업 또는 [describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html) AWS CLI 명령을 사용합니다. 버전의 예를 들면 `KTVPDKIKX0DER`입니다.
```
aws kafka update-cluster-kafka-version --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-kafka-version TargetVersion
```
이전 명령의 출력은 다음 JSON과 같습니다.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"ClusterOperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef"
}
```
1. `update-cluster-kafka-version` 작업 결과를 가져오려면 다음 명령을 실행하여 *ClusterOperationArn*을 `update-cluster-kafka-version` 명령의 출력에서 가져온 ARN으로 바꿉니다.
```
aws kafka describe-cluster-operation --cluster-operation-arn ClusterOperationArn
```
이 `describe-cluster-operation` 명령의 출력은 다음 JSON 예제와 같습니다.
```
{
"ClusterOperationInfo": {
"ClientRequestId": "62cd41d2-1206-4ebf-85a8-dbb2ba0fe259",
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"CreationTime": "2021-03-11T20:34:59.648000+00:00",
"OperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef",
"OperationState": "UPDATE_IN_PROGRESS",
"OperationSteps": [
{
"StepInfo": {
"StepStatus": "IN_PROGRESS"
},
"StepName": "INITIALIZE_UPDATE"
},
{
"StepInfo": {
"StepStatus": "PENDING"
},
"StepName": "UPDATE_APACHE_KAFKA_BINARIES"
},
{
"StepInfo": {
"StepStatus": "PENDING"
},
"StepName": "FINALIZE_UPDATE"
}
],
"OperationType": "UPDATE_CLUSTER_KAFKA_VERSION",
"SourceClusterInfo": {
"KafkaVersion": "2.4.1"
},
"TargetClusterInfo": {
"KafkaVersion": "2.6.1"
}
}
}
```
`OperationState` 값이 `UPDATE_IN_PROGRESS`인 경우, 잠시 기다린 다음 `describe-cluster-operation` 명령을 다시 실행합니다. 작업이 완료되면 `OperationState`의 값이 `UPDATE_COMPLETE`가 됩니다. Amazon MSK가 작업을 완료하는 데 걸리는 시간은 다양하므로 작업이 완료될 때까지 반복해서 확인해야 할 수 있습니다.
**API를 사용하여 Apache Kafka 버전 업그레이드**
1. 클러스터를 업그레이드할 수 있는 Apache Kafka 버전 목록을 가져오려면 [GetCompatibleKafkaVersions](https://docs.aws.amazon.com//msk/1.0/apireference/compatible-kafka-versions.html#GetCompatibleKafkaVersions) 작업을 호출합니다.
1. 호환되는 Apache Kafka 버전 중 하나에 클러스터를 업그레이드하려면 [UpdateClusterKafkaVersion](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-version.html#UpdateClusterKafkaVersion) 작업을 호출합니다.
# 버전 업그레이드의 모범 사례
Kafka 버전 업그레이드 프로세스의 일부로 수행되는 롤링 업데이트 중에 클라이언트 연속성을 보장하려면 다음과 같은 클라이언트 및 Apache Kafka 주제의 구성을 검토합니다.
+ 주제 복제 계수(RF)를 2개의 AZ 클러스터의 경우 `2`의 최소값으로 설정하고 3개의 AZ 클러스터의 경우 `3`의 최소값으로 설정합니다. `2`의 RF 값은 패치 적용 중에 오프라인 파티션으로 이어질 수 있습니다.
+ 최소 동기화 내 복제본(minISR)을 `miniISR = (RF) - 1`인 Replication Factor(RF)보다 1 작은 최대값으로 설정합니다. 이렇게 하면 파티션 복제본 세트가 한 복제본이 오프라인 또는 과소 복제되는 것을 허용할 수 있습니다.
+ 여러 브로커 연결 문자열을 사용하도록 클라이언트를 구성합니다. 클라이언트의 연결 문자열에 여러 브로커가 있으면 클라이언트 I/O를 지원하는 특정 브로커가 패치되기 시작하는 경우 장애 조치가 가능합니다. 여러 브로커가 있는 연결 문자열을 가져오는 방법에 대한 자세한 내용은 [Amazon MSK 클러스터의 부트스트랩 브로커 가져오기](https://docs.aws.amazon.com//msk/latest/developerguide/msk-get-bootstrap-brokers.html)를 참조하세요.
+ 새로운 버전에서 사용 가능한 기능을 활용하려면 연결 클라이언트를 권장 버전 이상으로 업그레이드하는 것이 좋습니다. 클라이언트 업그레이드는 MSK 클러스터 Kafka 버전의 수명 종료(EOL) 날짜의 적용을 받지 않으며 EOL 날짜까지 완료할 필요가 없습니다. Apache Kafka는 이전 클라이언트가 최신 클러스터에서 작업할 수 있도록 허용하는 [양방향 클라이언트 호환성 정책](https://kafka.apache.org/protocol#protocol_compatibility)을 제공하며 그 반대의 경우도 마찬가지입니다.
+ 버전 3.x.x를 사용하는 Kafka 클라이언트에는 `acks=all` 및 `enable.idempotence=true` 기본값이 적용될 수 있습니다. `acks=all`은 `acks=1`의 이전 기본값과 다르며 모든 동기화 내 복제본이 생산 요청을 승인하도록 하여 더 강화된 내구성을 제공합니다. 마찬가지로 `enable.idempotence`의 기본값은 이전에 `false`였습니다. `enable.idempotence=true`를 기본값으로 변경하면 중복 메시지의 가능성이 낮아집니다. 이러한 변경 사항은 모범 사례 설정으로 간주되며 정상 성능 파라미터 내에 약간의 추가 지연 시간이 발생할 수 있습니다.
+ 새로운 MSK 클러스터를 생성할 때는 권장 Kafka 버전을 사용합니다. 권장 Kafka 버전을 사용하면 최신 Kafka 및 MSK 기능을 활용할 수 있습니다.
# Amazon MSK 클러스터 문제 해결
다음 정보는 Amazon MSK 클러스터에서 발생할 수 있는 문제를 해결하는 데 도움이 될 수 있습니다. 또한 [AWS re:Post](https://repost.aws/)에 문제를 게시할 수 있습니다. Amazon MSK Replicator 문제 해결은 [MSK Replicator 문제 해결](msk-replicator-troubleshooting.md) 단원을 참조하세요.
**Topics**
+ [볼륨 교체 때문에 복제 과부하로 인해 디스크 포화 발생](#replication-overload-disk-saturation)
+ [`PreparingRebalance` 상태에 멈춘 소비자 그룹](#consumer-group-rebalance)
+ [브로커 로그를 Amazon CloudWatch Logs에 전달하는 중 오류 발생](#cw-broker-logs-error)
+ [기본 보안 그룹 없음](#troubleshooting-shared-vpc)
+ [클러스터가 CREATING 상태에 정체된 것으로 표시됨](#troubleshooting-cluster-stuck)
+ [클러스터 상태가 CREATING에서 FAILED로 바뀜](#troubleshooting-cluster-failed)
+ [클러스터가 ACTIVE 상태에 있지만 생산자가 데이터를 보낼 수 없거나 소비자가 데이터를 받을 수 없음](#troubleshooting-nodata)
+ [AWS CLI 가 Amazon MSK를 인식하지 못함](#troubleshooting-nocli)
+ [파티션이 오프라인으로 전환되거나 복제본이 동기화되지 않음](#troubleshooting-offlinepartition-outofsyncreplicas)
+ [디스크 공간이 부족함](#troubleshooting-lowdiskspace)
+ [메모리 부족](#troubleshooting-lowmemory)
+ [생산자가 NotLeaderForPartitionException을 받음](#troubleshooting-NotLeaderForPartitionException)
+ [복제되지 않은 파티션(URP)이 0보다 큼](#troubleshooting-urp)
+ [클러스터에는 \$1\$1amazon\$1msk\$1canary와 \$1\$1amazon\$1msk\$1canary\$1state라는 주제가 있습니다.](#amazon_msk_canary)
+ [파티션 복제 실패](#partition_replication_fails)
+ [퍼블릭 액세스가 활성화된 클러스터에 액세스할 수 없음](#public-access-issues)
+ [IPv6 부트스트랩을 통해 클러스터에 액세스할 수 없음](#dualstack-issues)
+ [내에서 클러스터에 액세스할 수 없음 AWS: 네트워킹 문제](#networking-trouble)
+ [인증 실패: 연결 횟수가 너무 많음](#troubleshoot-too-many-connects)
+ [인증 실패: 세션이 너무 짧음](#troubleshoot-session-too-short)
+ [MSK 서버리스: 클러스터 생성 실패](#troubleshoot-serverless-create-cluster-failure)
+ [MSK 구성에서 KafkaVersionsList를 업데이트할 수 없음](#troubleshoot-kafkaversionslist-cfn-update-failure)
## 볼륨 교체 때문에 복제 과부하로 인해 디스크 포화 발생
예기치 않은 볼륨 하드웨어 장애 발생 시 Amazon MSK에서 볼륨을 새 인스턴스로 교체할 수 있습니다. Kafka는 클러스터의 다른 브로커에서 파티션을 복제하여 새로운 볼륨을 다시 채웁니다. 파티션이 복제되고 인식되면 리더십 및 비동기 복제본(ISR) 멤버가 될 수 있습니다.
**문제**
볼륨 교체에서 복구하는 브로커의 경우 크기가 다양한 일부 파티션이 다른 파티션보다 먼저 온라인 상태로 다시 전환될 수 있습니다. 이러한 파티션은 여전히 다른 파티션을 추적하고 있는(복제하고 있는) 동일한 브로커의 트래픽을 제공할 수 있으므로 문제가 될 수 있습니다. 이 복제 트래픽은 경우에 따라 기본 볼륨 처리량 한도를 포화시킬 수 있습니다. 기본 사례에서는 초당 250MiB입니다. 이 포화가 발생하면 이미 인식된 모든 파티션이 영향을 받아 ISR을 해당 파티션과 공유하는 모든 브로커(원격 승인 `acks=all`으로 인한 리더 파티션뿐만 아니라)의 클러스터 전체에서 지연 시간이 발생합니다. 이 문제는 다양한 크기의 파티션 수가 많은 더 큰 클러스터에서 더 일반적입니다.
**권장 사항**
+ 복제 I/O 상태를 개선하려면 [모범 사례 스레드 설정](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html#optimize-broker-threads)이 마련되어 있어야 합니다.
+ 기본 볼륨 포화 가능성을 줄이려면 처리량이 더 높은 프로비저닝된 스토리지를 활성화합니다. 처리량이 많은 복제 사례의 경우 최소 처리량 값 500MiB/s가 권장되지만 필요한 실제 값은 처리량 및 사용 사례에 따라 달라집니다. [Amazon MSK 클러스터의 Standard 브로커에 대한 스토리지 처리량 프로비저닝](msk-provision-throughput.md)
+ 복제 압력을 최소화하려면 `num.replica.fetchers`를 기본값인 `2`로 낮춥니다.
## `PreparingRebalance` 상태에 멈춘 소비자 그룹
하나 이상의 소비자 그룹이 영구 재조정 상태에 머무는 경우, Apache Kafka 버전 2.3.1 및 2.4.1에 영향을 주는 Apache Kafka 문제 [KAFKA-9752](https://issues.apache.org/jira/browse/KAFKA-9752)가 원인일 수 있습니다.
문제를 해결하려면 문제에 대한 수정 사항이 포함된 [Amazon MSK 버그 수정 버전 2.4.1.1](supported-kafka-versions.md#2.4.1.1)로 클러스터를 업그레이드하는 것을 권장합니다. 기존 클러스터를 Amazon MSK 버그 수정 버전 2.4.1.1로 업데이트하는 방법에 대한 자세한 내용은 [Apache Kafka 버전 업그레이드](version-upgrades.md) 섹션을 참조하세요.
클러스터를 Amazon MSK 버그 수정 버전 2.4.1.1로 업그레이드하지 않고 이 문제를 해결하기 위한 해결 방법은 Kafka 클라이언트가 [고정 멤버십 프로토콜](#consumer-group-rebalance-static)을 사용하도록 설정하거나 멈춘 소비자 그룹의 조정 브로커 노드에 [식별 및 재부팅](#consumer-group-rebalance-reboot) 작업을 수행하는 것입니다.
### 정적 멤버십 프로토콜 구현
클라이언트에서 정적 멤버십 프로토콜을 구현하려면 다음을 수행합니다.
1. [Kafka Consumers](https://kafka.apache.org/26/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaConsumer.html) 구성의 `group.instance.id` 속성을 그룹 내 소비자를 식별하는 정적 문자열로 설정합니다.
1. 구성의 다른 인스턴스가 정적 문자열을 사용하도록 업데이트되었는지 확인합니다.
1. 변경 사항을 Kafka 소비자에게 배포합니다.
클라이언트 구성에서 세션 시간 제한을 소비자 그룹 재조정을 조기에 트리거하지 않고 소비자가 복구할 수 있는 기간으로 설정하는 경우 정적 멤버십 프로토콜을 사용하는 것이 더 효과적입니다. 예를 들어 소비자 애플리케이션이 5분 동안의 사용 불가 상태를 견딜 수 있는 경우 세션 시간 제한의 합리적인 값은 기본값인 10초가 아닌 4분이 될 수 있습니다.
**참고**
정적 멤버십 프로토콜을 사용하면 해당 문제가 발생할 확률이 줄어듭니다. 정적 멤버십 프로토콜을 사용하는 경우에도 이 문제가 발생할 수 있습니다.
### 조정 브로커 노드 재부팅
조정 브로커 노드를 재부팅하려면 다음을 수행합니다.
1. `kafka-consumer-groups.sh` 명령을 사용하여 그룹 코디네이터를 식별합니다.
1. [RebootBroker API](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-reboot-broker.html#RebootBroker) 작업을 사용하여 중단된 소비자 그룹의 그룹 코디네이터를 다시 시작합니다.
## 브로커 로그를 Amazon CloudWatch Logs에 전달하는 중 오류 발생
브로커 로그를 Amazon CloudWatch Logs로 전송하도록 클러스터를 설정하려고 할 때 두 가지 예외 중 하나가 발생할 수 있습니다.
`InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded` 예외가 발생하는 경우 다시 시도하되 `/aws/vendedlogs/`로 시작하는 로그 그룹을 사용하십시오. 자세한 내용은 [특정 Amazon Web Services에서 로깅 활성화](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html)를 참조하세요.
`InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded` 예외가 발생하면 계정에서 기존 Amazon CloudWatch Logs 정책을 선택하고 다음 JSON을 추가합니다.
```
{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}
```
위의 JSON을 기존 정책에 추가하려고 하는데 선택한 정책의 최대 길이에 도달했다는 오류가 표시되는 경우 다른 Amazon CloudWatch Logs 정책 중 하나에 JSON을 추가해 보세요. 기존 정책에 JSON을 추가한 후 다시 한번 브로커 로그 전달을 Amazon CloudWatch Logs로 설정합니다.
## 기본 보안 그룹 없음
클러스터를 생성하려고 하는데 기본 보안 그룹이 없다는 오류가 표시되는 경우, 본인의 공유 VPC를 사용하고 있기 때문일 수 있습니다. 관리자에게 이 VPC의 보안 그룹을 설명할 수 있는 권한을 요청하고 다시 시도하십시오. 이 작업을 허용하는 정책의 예는 [Amazon EC2: 특정 VPC와 연결된 EC2 보안 그룹을 콘솔에서 프로그래밍 방식으로 관리할 수 있도록 허용](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html)을 참조하십시오.
## 클러스터가 CREATING 상태에 정체된 것으로 표시됨
간혹 클러스터 생성에 최대 30분이 소요될 수 있습니다. 30분 동안 기다렸다가 클러스터의 상태를 다시 확인하십시오.
## 클러스터 상태가 CREATING에서 FAILED로 바뀜
클러스터를 다시 생성해 보십시오.
## 클러스터가 ACTIVE 상태에 있지만 생산자가 데이터를 보낼 수 없거나 소비자가 데이터를 받을 수 없음
+ 클러스터 생성에 성공했지만(클러스터 상태는 `ACTIVE`) 데이터를 보내거나 받을 수 없는 경우, 생산자 및 소비자 애플리케이션이 클러스터에 액세스할 수 있는지 확인합니다. 자세한 내용은 [3단계: 클라이언트 머신 생성](create-client-machine.md)의 지침을 참조하십시오.
+ 생산자와 소비자가 클러스터에 액세스할 수 있지만 데이터 생산과 소비에 계속 문제가 발생하는 경우 가능한 원인은 [KAFKA-7697](https://issues.apache.org/jira/browse/KAFKA-7697)로, 이 경우 Apache Kafka 버전 2.1.0에 영향을 미치고 이로 인해 하나 이상의 브로커가 교착 상태에 빠질 수 있습니다. 이 버그의 영향을 받지 않는 Apache Kafka 2.2.1로 마이그레이션하는 것을 고려하십시오. 마이그레이션 방법에 대한 자세한 내용은 [Kafka 워크로드를 Amazon MSK 클러스터로 마이그레이션](migration.md) 단원을 참조하십시오.
## AWS CLI 가 Amazon MSK를 인식하지 못함
가 AWS CLI 설치되어 있지만 Amazon MSK 명령을 인식하지 못하는 경우 AWS CLI 를 최신 버전으로 업그레이드합니다. 업그레이드 방법에 대한 자세한 지침은 설치를 AWS CLI참조하세요. [AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) 를 사용하여 Amazon MSK 명령을 실행하는 방법에 대한 자세한 내용은 섹션을 참조 AWS CLI 하세요[Amazon MSK 주요 기능 및 개념](operations.md).
## 파티션이 오프라인으로 전환되거나 복제본이 동기화되지 않음
디스크 공간 부족 증상일 수 있습니다. [디스크 공간이 부족함](#troubleshooting-lowdiskspace)을(를) 참조하세요.
## 디스크 공간이 부족함
디스크 공간 관리의 모범 사례인 [디스크 공간 모니터링](bestpractices.md#bestpractices-monitor-disk-space) 및 [데이터 보존 파라미터 조정](bestpractices.md#bestpractices-retention-period) 단원을 참조하십시오.
## 메모리 부족
`MemoryUsed` 지표가 높거나 `MemoryFree`가 낮다고 해서 문제가 있다는 뜻은 아닙니다. Apache Kafka는 최대한 많은 메모리를 사용하도록 설계되었으며 최적으로 관리합니다.
## 생산자가 NotLeaderForPartitionException을 받음
종종 발생하는 일시적인 오류입니다. 생산자의 `retries` 구성 파라미터를 현재 값보다 큰 값으로 설정합니다.
## 복제되지 않은 파티션(URP)이 0보다 큼
`UnderReplicatedPartitions` 지표는 모니터링해야 하는 중요한 지표입니다. 정상 MSK 클러스터에서 이 지표의 값은 0입니다. 0보다 크면 다음 이유 중 하나 때문일 수 있습니다.
+ `UnderReplicatedPartitions`가 급증하는 경우, 클러스터가 수신 트래픽과 발신 트래픽을 처리하기에 적합한 크기로 프로비저닝되지 않았기 때문일 수 있습니다. [Standard 브로커 모범 사례](bestpractices.md)을(를) 참조하세요.
+ 트래픽이 낮은 기간에도 `UnderReplicatedPartitions` 값이 0보다 큰 증상이 지속된다면, 주제에 브로커 액세스 권한을 부여하지 않는 제한적인 ACL을 설정했기 때문일 수 있습니다. 파티션을 복제하려면 브로커가 READ 및 DESCRIBE 주제 모두에 대한 권한이 있어야 합니다. DESCRIBE는 READ 권한과 함께 기본적으로 부여됩니다. ACL 설정에 대한 자세한 내용은 Apache Kafka 설명서의 [권한 부여 및 ACL](https://kafka.apache.org/documentation/#security_authz)을 참조하십시오.
## 클러스터에는 \$1\$1amazon\$1msk\$1canary와 \$1\$1amazon\$1msk\$1canary\$1state라는 주제가 있습니다.
MSK 클러스터에 `__amazon_msk_canary`라는 이름의 주제와 `__amazon_msk_canary_state`라는 이름의 주제가 있는 것을 볼 수 있습니다. 이는 Amazon MSK가 클러스터 상태 및 진단 지표에 대해 생성하고 사용하는 내부 주제입니다. 이러한 주제는 크기가 무시할 수 있을 정도로 작으며 삭제할 수 없습니다.
## 파티션 복제 실패
CLUSTER\$1ACTIONS에 ACL을 설정하지 않았는지 확인합니다.
## 퍼블릭 액세스가 활성화된 클러스터에 액세스할 수 없음
클러스터에 공용 액세스가 활성화되어 있지만 여전히 인터넷에서 클러스터에 액세스할 수 없는 경우 다음 단계를 수행합니다.
1. 클러스터의 보안 그룹 인바운드 규칙이 IP 주소와 클러스터의 포트를 허용하는지 확인합니다. 클러스터 포트 번호 목록은 [포트 정보](port-info.md) 섹션을 참조하세요. 또한 보안 그룹의 아웃바운드 규칙이 아웃바운드 통신을 허용하는지 확인합니다. 보안 그룹 및 해당 인바운드 및 아웃바운드 규칙에 대한 자세한 내용은 Amazon VPC 사용 설명서에서 [VPC의 보안 그룹](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)을 참조하세요.
1. IP 주소와 클러스터 포트가 클러스터 VPC 네트워크 ACL의 인바운드 규칙에 허용되는지 확인합니다. 보안 그룹과 달리 네트워크 ACL은 상태 비저장입니다. 즉, 인바운드 및 아웃바운드 규칙을 모두 구성해야 합니다. 아웃바운드 규칙에서 모든 트래픽(포트 범위: 0\$165535)을 사용자 IP 주소로 허용합니다. 자세한 내용은 Amazon VPC 사용 설명서의 [규칙 추가 및 삭제](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#Rules)를 참조하세요.
1. 퍼블릭 액세스 부트스트랩 브로커 문자열을 사용하여 클러스터에 액세스하고 있는지 확인합니다. 퍼블릭 액세스가 활성화된 MSK 클러스터에는 두 개의 서로 다른 부트스트랩 브로커 문자열이 있는데, 하나는 퍼블릭 액세스를 위한 것이고 다른 하나는 AWS내에서 액세스하기 위한 것입니다. 자세한 내용은 [를 사용하여 부트스트랩 브로커 가져오기 AWS Management Console](get-bootstrap-console.md) 단원을 참조하십시오.
## IPv6 부트스트랩을 통해 클러스터에 액세스할 수 없음
제공된 IPv6 부트스트랩 문자열을 사용하여 클러스터에 연결하는 데 문제가 있는 경우 다음 단계를 따르세요.
1. 클라이언트에 IPv4 및 IPv6 주소가 모두 할당되어 있는지 확인합니다. 클라이언트 애플리케이션은 IPv4 및 IPv6 주소 지정이 모두 활성화되고 올바르게 구성된 서브넷에서 실행 중이어야 합니다. VPC에 IPv4 CIDR 블록과 연결된 IPv6 CIDR 블록이 모두 있는지 확인하고, 서브넷에 IPv4 및 IPv6 주소가 모두 활성화되어 있는지 확인하고, EC2 인스턴스 또는 클라이언트 환경에 IPv4 및 IPv6 주소가 모두 할당되어 있는지 확인합니다. 자세한 내용은 Amazon [ VPCs 사용 설명서의 VPC 및 서브넷의 IP 주소 지정](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html)을 참조하세요.
1. 보안 그룹 인바운드 및 아웃바운드 규칙에 관련 IPv6 포트가 있는지 확인합니다. IPv6 주소에서 클러스터 포트의 트래픽을 허용하는 인바운드 규칙을 추가하고 IPv6 트래픽을 허용하도록 아웃바운드 규칙을 구성합니다. 특정 포트 번호는 MSK 설명서의 [포트 정보를](https://docs.aws.amazon.com/msk/latest/developerguide/port-info.html) 참조하세요. 듀얼 스택 모드에서 실행되는 경우 IPv4 및 IPv6 규칙을 모두 업데이트해야 합니다. 보안 그룹 및 해당 인바운드 및 아웃바운드 규칙에 대한 자세한 내용은 Amazon VPC 사용 설명서에서 [VPC의 보안 그룹](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html)을 참조하세요.
1. IPv6 지원을 위해 JVM 속성 구성이 올바른지 확인합니다. 클라이언트 애플리케이션에서를 `java.net.preferIPv6Addresses` 로 설정하고를 `true``java.net.preferIPv4Stack`로 설정합니다`false`. 이러한 설정은 시스템 속성 또는 JVM 인수로 구성할 수 있습니다. 이러한 변경 사항을 적용한 후 애플리케이션을 다시 시작합니다.
## 내에서 클러스터에 액세스할 수 없음 AWS: 네트워킹 문제
MSK 클러스터와 성공적으로 통신할 수 없는 Apache Kafka 애플리케이션이 있는 경우 다음 연결 테스트를 수행하여 시작합니다.
1. [Amazon MSK 클러스터를 위한 부트스트랩 브로커 가져오기](msk-get-bootstrap-brokers.md)에 설명된 방법 중 하나를 사용하여 부트스트랩 브로커의 주소를 가져옵니다.
1. 다음 명령에서 *bootstrap-broker*를 이전 단계에서 얻은 브로커 주소 중 하나로 바꿉니다. 클러스터가 TLS 인증을 사용하도록 설정된 경우 *port-number*를 9094로 바꿉니다. 클러스터에서 TLS 인증을 사용하지 않는 경우 *port-number*를 9092로 바꿉니다. 클라이언트 시스템에서 명령을 실행합니다.
```
telnet bootstrap-broker port-number
```
포트 번호는 다음과 같습니다.
+ 클러스터가 TLS 인증을 사용하도록 설정된 경우 9094
+ 클러스터에서 TLS 인증을 사용하지 않는 경우 9092
+ 퍼블릭 액세스가 활성화된 경우에는 다른 포트 번호가 필요
클라이언트 시스템에서 명령을 실행합니다.
1. 모든 부트스트랩 브로커에 대해 이전 명령을 반복합니다.
클라이언트 머신이 브로커에 액세스할 수 있는 경우 이는 연결 문제가 없음을 의미합니다. 이 경우 다음 명령을 실행하여 Apache Kafka 클라이언트가 올바르게 설정되어 있는지 확인합니다. *bootstrap-brokers*를 가져오려면 [Amazon MSK 클러스터를 위한 부트스트랩 브로커 가져오기](msk-get-bootstrap-brokers.md)에 설명된 방법 중 하나를 사용합니다. *topic*을 해당 주제의 이름으로 바꿉니다.
```
/bin/kafka-console-producer.sh --broker-list bootstrap-brokers --producer.config client.properties --topic topic
```
이전 명령이 성공하면 클라이언트가 올바르게 설정되었음을 의미합니다. 여전히 애플리케이션에서 생성 및 소비할 수 없는 경우 애플리케이션 수준에서 문제를 디버그하십시오.
클라이언트 머신이 브로커에 액세스할 수 없는 경우 클라이언트 시스템 설정에 따른 지침은 다음 하위 섹션을 참조하세요.
### 동일한 VPC의 Amazon EC2 클라이언트와 MSK 클러스터
클라이언트 머신이 MSK 클러스터와 동일한 VPC에 있는 경우 클러스터의 보안 그룹에 클라이언트 머신의 보안 그룹으로부터의 트래픽을 허용하는 인바운드 규칙이 있는지 확인합니다. 이러한 규칙 설정에 대한 자세한 내용은 [보안 그룹 규칙](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules)을 참조하십시오. 클러스터와 동일한 VPC에 있는 Amazon EC2 인스턴스에서 클러스터에 액세스하는 방법의 예제는 [Amazon MSK 사용 시작하기](getting-started.md) 섹션을 참조하세요.
### 서로 다른 VPC의 Amazon EC2 클라이언트와 MSK 클러스터
클라이언트 시스템과 클러스터가 서로 다른 두 VPC에 있는 경우 다음을 확인합니다.
+ 두 VPC가 피어링되어 있습니다.
+ 피어링 연결의 상태가 활성 상태입니다.
+ 두 VPC의 라우팅 테이블이 올바르게 설정되어 있습니다.
VPC 피어링에 대한 자세한 내용은 [VPC 피어링 연결 작업](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html)을 참조하십시오.
### 온프레미스 클라이언트
를 사용하여 MSK 클러스터에 연결하도록 설정된 온프레미스 클라이언트의 경우 다음을 Site-to-Site VPN확인합니다.
+ VPN 연결 상태가 `UP`입니다. VPN 연결 상태를 확인하는 방법에 대한 자세한 내용은 [VPN 터널의 현재 상태를 확인하려면 어떻게 합니까?](https://aws.amazon.com/premiumsupport/knowledge-center/check-vpn-tunnel-status/)를 참조하십시오.
+ 클러스터 VPC의 라우팅 테이블에는 대상의 형식이 `Virtual private gateway(vgw-xxxxxxxx)`인 온프레미스 CIDR에 대한 라우팅이 포함되어 있습니다.
+ MSK 클러스터의 보안 그룹은 포트 2181, 포트 9092(클러스터가 일반 텍스트 트래픽을 허용하는 경우), 포트 9094(클러스터가 TLS 암호화 트래픽을 허용하는 경우)의 트래픽을 허용합니다.
자세한 Site-to-Site VPN 문제 해결 지침은 [Client VPN 문제 해결을 참조하세요](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/troubleshooting.html).
### Direct Connect
클라이언트가를 사용하는 경우 문제 해결을 Direct Connect참조하세요. [Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Troubleshooting.html)
이전 문제 해결 지침으로 문제가 해결되지 않으면 네트워크 트래픽을 차단하는 방화벽이 없는지 확인하십시오. 추가 디버깅을 위해 `tcpdump` 및 `Wireshark`와 같은 도구를 사용하여 트래픽을 분석하고 트래픽이 MSK 클러스터에 도달하고 있는지 확인합니다.
## 인증 실패: 연결 횟수가 너무 많음
`Failed authentication ... Too many connects` 오류는 하나 이상의 IAM 클라이언트가 공격적인 속도로 연결을 시도하므로 브로커가 스스로를 보호하고 있음을 나타냅니다. 브로커가 더 높은 속도의 새 IAM 연결을 수락하도록 하려면 [https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms](https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms) 구성 파라미터를 늘릴 수 있습니다.
브로커별 새 연결 속도 제한에 대한 자세한 내용은 [Amazon MSK 할당량](limits.md) 페이지를 참조하세요.
## 인증 실패: 세션이 너무 짧음
이 `Failed authentication ... Session too short` 오류는 클라이언트가 곧 만료될 IAM 자격 증명을 사용하여 클러스터에 연결을 시도하는 경우 발생합니다. IAM 자격 증명이 새로 고쳐지는 방식을 확인해야 합니다. 대부분의 경우 자격 증명이 세션 만료에 너무 가깝게 교체되어 서버 측에 문제가 발생하고 인증에 실패할 수 있습니다.
## MSK 서버리스: 클러스터 생성 실패
MSK 서버리스 클러스터를 생성하려고 하는데 워크플로우가 실패하는 경우 VPC 엔드포인트를 생성할 수 있는 권한이 없는 것일 수 있습니다. 관리자가 `ec2:CreateVpcEndpoint` 작업을 허용하여 VPC 엔드포인트를 만들 수 있는 권한을 부여했는지 확인합니다.
모든 Amazon MSK 작업을 수행하는 데 필요한 전체 권한 목록은 [AWS 관리형 정책: AmazonMSKFullAccess](security-iam-awsmanpol-AmazonMSKFullAccess.md) 섹션을 참조하세요.
## MSK 구성에서 KafkaVersionsList를 업데이트할 수 없음
[AWS::MSK::Configuration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html) 리소스에서 [KafkaVersionsList](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-kafkaversionslist) 속성을 업데이트하면 다음 오류와 함께 업데이트가 실패합니다.
```
Resource of type 'AWS::MSK::Configuration' with identifier '' already exists.
```
`KafkaVersionsList` 속성을 업데이트하면는 이전 구성을 삭제하기 전에 업데이트된 속성으로 새 구성을 AWS CloudFormation 다시 생성합니다. 새 구성이 기존 구성과 동일한 이름을 사용하기 때문에 CloudFormation 스택 업데이트가 실패합니다. 이러한 업데이트에는 [리소스 교체](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-update-behaviors.html#update-replacement)가 필요합니다. `KafkaVersionsList`를 성공적으로 업데이트하려면 동일한 작업에서 [이름](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-name) 속성도 업데이트해야 합니다.
또한 AWS Management Console 또는를 사용하여 생성된 클러스터에 구성이 연결된 경우 AWS CLI구성 리소스에 다음을 추가하여 [실패한 리소스 삭제 시도](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted)를 방지합니다.
```
UpdateReplacePolicy: Retain
```
업데이트가 성공하면 Amazon MSK 콘솔로 이동하여 이전 구성을 삭제합니다. MSK 구성에 대한 자세한 내용은 [Amazon MSK Provisioned 구성](msk-configuration.md) 단원을 참조하십시오.