표준 브로커 모범 사례 - Amazon Managed Streaming for Apache Kafka
클라이언트 측 고려 사항서버 측 고려 사항

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

표준 브로커 모범 사례

이 주제에서는 Amazon를 사용할 때 따라야 할 몇 가지 모범 사례를 간략하게 설명합니다MSK. Amazon MSK Replicator 모범 사례에 대한 자세한 내용은 섹션을 참조하세요MSK Replicator 사용 모범 사례.

클라이언트 측 고려 사항

애플리케이션의 가용성 및 성능은 서버 측 설정뿐만 아니라 클라이언트 설정에도 따라 달라집니다.

  • 고가용성을 위해 클라이언트를 구성합니다. Apache Kafka와 같은 분산 시스템에서는 고가용성을 보장하는 것이 신뢰할 수 있고 내결함성 있는 메시징 인프라를 유지하는 데 매우 중요합니다. 브로커는 업그레이드, 패치 적용, 하드웨어 장애 및 네트워크 문제와 같이 계획된 이벤트와 계획되지 않은 이벤트 모두에 대해 오프라인 상태가 됩니다. Kafka 클러스터는 오프라인 브로커 오류를 처리할 수 있으므로 Kafka 클라이언트도 브로커 장애 조치를 정상적으로 처리해야 합니다. 에 대한 전체 세부 정보를 참조하세요Apache Kafka 클라이언트 모범 사례.

  • 클라이언트 연결 문자열에 각 가용 영역의 브로커가 하나 이상 포함되어 있는지 확인합니다. 클라이언트의 연결 문자열에 여러 브로커가 있으면 특정 브로커가 업데이트를 위해 오프라인 상태일 때 장애 조치를 수행할 수 있습니다. 여러 브로커를 통해 연결 문자열을 가져오는 방법에 대한 자세한 내용은 Amazon MSK 클러스터의 부트스트랩 브로커 가져오기 단원을 참조하십시오.

  • 성능 테스트를 실행하여 클라이언트 구성이 성능 목표를 충족하도록 허용하는지 확인합니다.

서버 측 고려 사항

클러스터 크기 조정: 표준 브로커당 파티션 수

다음 표에는 표준 브로커당 권장되는 파티션 수(리더 및 팔로워 복제본 포함)가 나와 있습니다. 권장 파티션 수는 적용되지 않으며 프로비저닝된 모든 주제 파티션에서 트래픽을 전송하는 시나리오에 대한 모범 사례입니다.

브로커 크기 브로커당 권장 파티션 수(리더 및 팔로어 복제본 포함) 업데이트 작업을 지원하는 최대 파티션 수
kafka.t3.small 300 300
kafka.m5.large 또는 kafka.m5.xlarge 1000 1500
kafka.m5.2xlarge 2000 3000
kafka.m5.4xlarge, kafka.m5.8xlarge, kafka.m5.12xlarge, kafka.m5.16xlarge 또는 kafka.m5.24xlarge 4000 6000
kafka.m7g.large 또는 kafka.m7g.xlarge 1000 1500
kafka.m7g.2xlarge 2000 3000
kafka.m7g.4xlarge, kafka.m7g.8xlarge, kafka.m7g.12xlarge 또는 kafka.m7g.16xlarge 4000 6000

파티션 수가 높고 처리량이 낮은 사용 사례가 있지만 모든 파티션에서 트래픽을 전송하지 않는 경우, 클러스터가 파티션 수가 높을수록 정상 상태를 유지하는지 확인하기 위해 충분한 테스트 및 성능 테스트를 수행한 경우 브로커당 더 많은 파티션을 패키징할 수 있습니다. 브로커당 파티션 수가 최대 허용 값을 초과하고 클러스터에 과부하가 걸리면 다음 작업을 수행할 수 없습니다.

  • 클러스터 구성 업데이트

  • 더 작은 브로커 크기로 클러스터 업데이트

  • AWS Secrets Manager 보안 암호를 SASL/SCRAM 인증이 있는 클러스터와 연결

파티션 수가 많으면 Prometheus 스크레이핑 CloudWatch 에서 Kafka 지표가 누락될 수도 있습니다.

파티션 수를 선택하는 방법에 대한 지침은 Apache Kafka는 클러스터당 200K 파티션 지원을 참조하십시오. 또한 직접 테스트를 수행하여 자신에게 적합한 브로커 크기를 결정하는 것을 권장합니다. 다양한 브로커 크기에 대한 자세한 내용은 Amazon MSK브로커 유형 단원을 참조하세요.

클러스터의 적절한 크기: 클러스터당 표준 브로커 수

MSK 프로비저닝된 클러스터에 적합한 수의 표준 브로커를 결정하고 비용을 이해하려면 MSK 크기 조정 및 요금 스프레드시트를 참조하세요. 이 스프레드시트는 유사한 자체 관리형 EC2Apache Kafka 클러스터와 MSK 비교하여 MSK 프로비저닝된 클러스터의 크기와 Amazon의 관련 비용을 추정합니다. 스프레드시트의 입력 파라미터에 대한 자세한 내용을 보려면 파라미터 설명 위에 커서를 대십시오. 이 시트에서 제공하는 추정치는 보수적이며 새 MSK 프로비저닝된 클러스터의 시작점을 제공합니다. 클러스터 성능, 크기, 비용은 사용 사례에 따라 다르므로 실제 테스트를 통해 확인하는 것이 좋습니다.

기본 인프라가 Apache Kafka 성능에 미치는 영향을 이해하려면 AWS 빅 데이터 블로그에서 Apache Kafka 클러스터의 크기를 올바르게 조정하여 성능 및 비용을 최적화하는 모범 사례를 참조하세요. 이 블로그 게시물에서는 처리량, 가용성, 지연 시간 요구 사항을 충족하기 위해 클러스터 크기를 조정하는 방법에 대해 설명합니다. 또한 스케일 업과 스케일 아웃이 필요한 시기와 같은 질문에 대한 답변과 프로덕션 클러스터의 크기를 지속적으로 확인하는 방법에 대한 지침을 제공합니다.

m5.4xl, m7g.4xl 또는 더 큰 인스턴스에 대한 클러스터 처리량 최적화

m5.4xl, m7g.4xl 또는 더 큰 인스턴스를 사용하는 경우 num.io.threads 및 num.network.threads 구성을 조정하여 MSK 프로비저닝된 클러스터 처리량을 최적화할 수 있습니다.

Num.io.threads는 Standard 브로커가 요청을 처리하는 데 사용하는 스레드 수입니다. 인스턴스 크기에 지원되는 CPU 코어 수까지 스레드를 더 추가하면 클러스터 처리량을 개선하는 데 도움이 될 수 있습니다.

Num.network.threads는 Standard 브로커가 모든 수신 요청을 수신하고 응답을 반환하는 데 사용하는 스레드 수입니다. 네트워크 스레드는 들어오는 요청을 요청 대기열에 배치하여 io.threads에서 처리합니다. num.network.threads를 인스턴스 크기에 지원되는 CPU 코어 수의 절반으로 설정하면 새 인스턴스 크기를 완전히 사용할 수 있습니다.

중요

대기열 포화로 인한 혼잡이 발생할 수 있으므로 num.io.threads를 늘리기 전에 num.network.threads를 늘리지 마세요.

권장 설정
인스턴스 크기 num.io.threads의 권장값 num.network.threads의 권장값

m5.4xl

16

8

m5.8xl

32

16

m5.12xl

48

24

m5.16xl

64

32

m5.24xl

96

48

m7g.4xlarge

16

8

m7g.8xlarge

32

16

m7g.12xlarge

48

24

m7g.16xlarge

64

32

최신 Kafka AdminClient 를 사용하여 주제 ID 불일치 문제 방지

Kafka AdminClient 버전 2.8.0 이상을 사용하여 MSK 프로비저닝된 클러스터의 주제 파티션을 늘리거나 재할당--zookeeper하기 위해 플래그가 2.8.0보다 낮은 Kafka 버전을 사용하면 주제의 ID가 손실됩니다(오류:가 파티션의 주제 ID와 일치하지 않음). --zookeeper 플래그는 Kafka 2.5에서 더 이상 사용되지 않으며 Kafka 3.0부터 제거된다는 점에 유의하세요. 0.8.x~2.4.x 버전에서 2.5.0으로 업그레이드를 참조하세요.

주제 ID 불일치를 방지하려면 Kafka 관리자 작업에 Kafka 클라이언트 버전 2.8.0 이상을 사용하세요. 또는 클라이언트 2.5 이상에서는 --zookeeper 플래그 대신 --bootstrap-servers 플래그를 사용할 수 있습니다.

고가용성 클러스터 빌드

다음 권장 사항을 사용하면 업데이트 중에(예: 브로커 크기 또는 Apache Kafka 버전을 업데이트할 때) 또는 AmazonMSK이 브로커를 교체할 때 MSK 프로비저닝된 클러스터를 쉽게 사용할 수 있습니다.

  • 3개의 AZ 클러스터를 설정합니다.

  • 복제 인수(RF)가 3 이상인지 확인합니다. RF가 1이면 롤링 업데이트 중에 오프라인 파티션이 발생할 수 있고 RF가 2이면 데이터 손실이 발생할 수 있다는 점에 유의하세요.

  • 최소 동기화 내 복제본(분ISR)을 최대 RF - 1로 설정합니다. RF와 같은 최소값ISR은 롤링 업데이트 중에 클러스터에가 생성되지 않도록 할 수 있습니다. 최소ISR 2를 사용하면 복제본 하나가 오프라인 상태일 때 3방향 복제 주제를 사용할 수 있습니다.

CPU 사용량 모니터링

Amazon은 브로커(로 정의CPU User + CPU System)의 총 CPU 사용률을 60% 미만으로 유지할 것을 MSK 강력히 권장합니다. 클러스터 총 사용 CPU 가능한 비율이 40% 이상인 경우 Apache Kafka는 필요한 경우 클러스터의 브로커 간에 CPU 로드를 재배포할 수 있습니다. 이 작업이 필요한 경우의 한 가지 예는 Amazon이 브로커 오류를 MSK 감지하고 복구하는 경우입니다.이 경우 Amazon은 패치 적용과 같은 자동 유지 관리를 MSK 수행합니다. 또 다른 예는 사용자가 브로커 크기 변경 또는 버전 업그레이드를 요청하는 경우입니다.이 두 경우 Amazon은 한 번에 하나의 브로커를 오프라인으로 전환하는 롤링 워크플로를 MSK 배포합니다. 리드 파티션이 있는 브로커가 오프라인 상태가 되면 Apache Kafka는 파티션 책임자를 재할당하여 클러스터 내 다른 브로커에게 작업을 재분배합니다. 이 모범 사례를 따르면 클러스터에 이러한 운영 이벤트를 견딜 수 있는 충분한 CPU 헤드룸이 있는지 확인할 수 있습니다.

Amazon CloudWatch 지표 수학을 사용하여 인 복합 지표를 생성할 수 있습니다CPU User + CPU System. 복합 지표가 평균 CPU 사용률 60%에 도달하면 트리거되는 경보를 설정합니다. 이 경보가 트리거되면 다음 옵션 중 하나를 사용하여 클러스터를 확장합니다.

  • 옵션 1(권장): 다음으로 큰 크기로 브로커 크기를 업데이트합니다. 예를 들어 현재 크기가 kafka.m5.large인 경우 kafka.m5.xlarge를 사용하도록 클러스터를 업데이트합니다. 클러스터에서 브로커 크기를 업데이트할 때 AmazonMSK은 브로커를 롤링 방식으로 오프라인으로 전환하고 파티션 리더십을 다른 브로커에 일시적으로 재할당한다는 점에 유의하세요. 크기 업데이트는 일반적으로 브로커당 10~15분 정도 소요됩니다.

  • 옵션 2: 생산자로부터 수집된 모든 메시지가 라운드 로빈 쓰기를 사용하는 주제가 있는 경우(즉, 메시지에 키가 지정되지 않고 순서가 소비자에게 중요하지 않은 경우) 브로커를 추가하여 클러스터를 확장합니다. 또한 처리량이 가장 많은 기존 주제에 파티션을 추가할 수도 있습니다. 그런 다음 kafka-topics.sh --describe를 사용하여 새로 추가된 파티션이 새 브로커에 할당되었는지 확인합니다. 이전 옵션에 비해 이 옵션의 가장 큰 이점은 리소스와 비용을 더 세부적으로 관리할 수 있다는 점입니다. 또한 CPU 부하가 60%를 크게 초과하는 경우이 옵션을 사용할 수 있습니다. 이러한 형태의 조정으로 인해 일반적으로 기존 브로커에 대한 부하가 증가하지 않기 때문입니다.

  • 옵션 3: 브로커를 추가하여 MSK 프로비저닝된 클러스터를 확장한 다음 라는 파티션 재할당 도구를 사용하여 기존 파티션을 재할당합니다kafka-reassign-partitions.sh. 그러나 이 옵션을 사용하면 파티션이 재할당된 후 클러스터가 브로커 간에 데이터를 복제하는 데 리소스를 사용해야 합니다. 이전 두 옵션에 비해 처음에는 클러스터의 부하가 크게 증가할 수 있습니다. 따라서 복제로 인해 추가 CPU 로드 및 네트워크 트래픽이 발생하므로 CPU 사용률이 70%를 초과할 때는이 옵션을 사용하지 MSK 않는 것이 좋습니다. Amazon은 이전 두 옵션을 사용할 수 없는 경우에만이 옵션을 사용하는 것이 MSK 좋습니다.

기타 권장 사항:

  • 로드 배포를 위한 프록시로서 브로커당 총 CPU 사용률을 모니터링합니다. 브로커의 CPU 사용률이 지속적으로 고르지 않은 경우 로드가 클러스터 내에 균등하게 분산되지 않는다는 신호일 수 있습니다. 파티션 할당을 통해 로드 분산을 지속적으로 관리하려면 Cruise Control을 사용하는 것이 좋습니다.

  • 생산 및 소비 지연을 모니터링합니다. 생산 및 소비 지연 시간은 CPU 사용률에 따라 선형적으로 증가할 수 있습니다.

  • JMX 스크레이프 간격: Prometheus 기능을 사용하여 공개 모니터링을 활성화하는 경우 Prometheus 호스트 구성(prometheus.yml)에 60초 이상의 스크레이프 간격(scrape_interval: 60초)을 사용하는 것이 좋습니다. 스크레이프 간격을 줄이면 클러스터의 CPU 사용량이 높아질 수 있습니다.

디스크 공간 모니터링

메시지의 디스크 공간이 부족하지 않도록 KafkaDataLogsDiskUsed 지표를 감시하는 CloudWatch 경보를 생성합니다. 이 지표의 값이 85% 이상에 도달하면 다음 작업 중 하나 이상을 수행합니다.

경보를 설정하고 사용하는 방법에 대한 자세한 내용은 Amazon CloudWatch 경보 사용을 참조하세요. Amazon MSK 지표의 전체 목록은 섹션을 참조하세요Amazon MSK 프로비저닝 클러스터 모니터링.

데이터 보존 파라미터 조정

메시지를 소비해도 로그에서 제거되지 않습니다. 정기적으로 디스크 공간을 확보하려면 메시지가 로그에 유지되는 기간인 보존 기간을 명시적으로 지정하면 됩니다. 보존 로그 크기를 지정할 수도 있습니다. 보존 기간 또는 보존 로그 크기에 도달하면 Apache Kafka는 로그에서 비활성 세그먼트를 제거하기 시작합니다.

클러스터 수준에서 보존 정책을 지정하려면, log.retention.hours, log.retention.minutes, log.retention.ms 또는 log.retention.bytes 파라미터 중 하나 이상을 설정합니다. 자세한 내용은 사용자 지정 Amazon MSK 구성 단원을 참조하십시오.

주제 수준에서 보존 파라미터를 지정할 수도 있습니다.

  • 주제별로 보존 기간을 지정하려면 다음 명령을 사용합니다.

    kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name TopicName --add-config retention.ms=DesiredRetentionTimePeriod

  • 주제별로 보존 로그 크기를 지정하려면 다음 명령을 사용합니다.

    kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name TopicName --add-config retention.bytes=DesiredRetentionLogSize

주제 수준에서 지정하는 보존 파라미터는 클러스터 수준 파라미터보다 우선합니다.

비정상 종료 후 로그 복구 속도 향상

비정상 종료 후 브로커는 로그 복구를 수행하므로 다시 시작하는 데 시간이 걸릴 수 있습니다. 기본적으로 Kafka는 로그 디렉터리당 단일 스레드만 사용하여 해당 복구를 수행합니다. 예를 들어 수천 개의 파티션이 있는 경우 로그 복구를 완료하는 데 몇 시간이 소요될 수 있습니다. 로그 복구 속도를 높이려면 구성 속성 num.recovery.threads.per.data.dir을 사용하여 스레드 수를 늘리는 것을 권장합니다. CPU 코어 수로 설정할 수 있습니다.

Apache Kafka 메모리 모니터링

Apache Kafka가 사용하는 메모리를 모니터링하는 것을 권장합니다. 그렇지 않으면 클러스터를 사용할 수 없게 될 수 있습니다.

Apache Kafka가 사용하는 메모리 양을 확인하려면 HeapMemoryAfterGC 지표를 모니터링하면 됩니다. HeapMemoryAfterGC는 가비지 수집 후 사용 중인 전체 힙 메모리의 백분율입니다. 가 60%를 HeapMemoryAfterGC 초과할 때 조치를 취하는 CloudWatch 경보를 생성하는 것이 좋습니다.

메모리 사용량을 줄이기 위해 취할 수 있는 조치는 다양합니다. Apache Kafka를 구성하는 방식에 따라 달라집니다. 예를 들어 트랜잭션 메시지 전송을 사용하는 경우 Apache Kafka 구성에서 transactional.id.expiration.ms 값을 604800000밀리초에서 86400000밀리초(7일에서 1일로)로 줄일 수 있습니다. 이를 통해 각 트랜잭션의 메모리 사용량이 줄어듭니다.

브로커가 아닌MSK 브로커를 추가하지 마세요.

ZooKeeper기반 MSK 프로비저닝된 클러스터의 경우 Apache ZooKeeper 명령을 사용하여 브로커를 추가하는 경우 이러한 브로커는 MSK 프로비저닝된 클러스터에 추가되지 않으며 Apache ZooKeeper 에 클러스터에 대한 잘못된 정보가 포함됩니다. 이로 인해 데이터가 손실될 수 있습니다. 지원되는 MSK 프로비저닝된 클러스터 작업은 섹션을 참조하세요Amazon MSK 주요 기능 및 개념.

전송 중 암호화 활성화

전송 중 암호화와 활성화하는 방법에 대한 자세한 내용은 전송 중인 Amazon MSK 암호화 단원을 참조하십시오.

파티션 재할당

파티션을 동일한 MSK 프로비저닝된 클러스터의 다른 브로커로 이동하려면 라는 파티션 재할당 도구를 사용할 수 있습니다kafka-reassign-partitions.sh. 예를 들어, 클러스터를 확장하거나 브로커를 제거하기 위해 파티션을 이동하도록 새로운 브로커를 추가한 후에는 새로운 브로커에 파티션을 다시 할당하여 해당 클러스터를 재분배할 수 있습니다. MSK 프로비저닝된 클러스터에 브로커를 추가하는 방법에 대한 자세한 내용은 섹션을 참조하세요Amazon MSK 클러스터의 브로커 수 확장. MSK 프로비저닝된 클러스터에서 브로커를 제거하는 방법에 대한 자세한 내용은 섹션을 참조하세요Amazon MSK 클러스터에서 브로커 제거. 파티션 재할당 도구에 대한 자세한 내용은 Apache Kafka 설명서의 클러스터 확장을 참조하십시오.