모범 사례

이 주제에서는 Amazon MSK를 사용할 때 따라야 할 몇 가지 모범 사례를 간략하게 설명합니다.

클러스터 크기를 적절하게 조정: 브로커당 파티션 수

다음 표는 브로커당 권장되는 파티션 수(리더 및 팔로어 복제본 포함)를 보여줍니다.

브로커 크기	브로커당 권장 파티션 수(리더 및 팔로어 복제본 포함)
kafka.t3.small	300
kafka.m5.large 또는 kafka.m5.xlarge	1000
kafka.m5.2xlarge	2000
kafka.m5.4xlarge, kafka.m5.8xlarge, kafka.m5.12xlarge, kafka.m5.16xlarge 또는 kafka.m5.24xlarge	4000
kafka.m7g.large 또는 kafka.m7g.xlarge	1000
kafka.m7g.2xlarge	2000
kafka.m7g.4xlargekafka.m7g.8xlarge,kafka.m7g.12xlarge, 또는 kafka.m7g.16xlarge	4000

브로커당 파티션 수가 권장값을 초과하여 클러스터에 과부하가 주어지면 다음 작업을 수행하지 못할 수 있습니다.

• 클러스터 구성 업데이트

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

• SASL/SCRAM 인증을 사용하는 클러스터에 AWS Secrets Manager 시크릿을 연결합니다.

파티션 수가 많으면 Prometheus 스크래핑에서 Kafka 메트릭이 누락될 수도 있습니다. CloudWatch

파티션 수를 선택하는 방법에 대한 지침은 Apache Kafka는 클러스터당 200K 파티션 지원을 참조하십시오. 또한 자체 테스트를 수행하여 브로커에 적합한 크기를 결정하는 것이 좋습니다. 다양한 브로커 규모에 대한 자세한 내용은 을 참조하십시오브로커 크기.

클러스터 크기를 적절하게 조정: 클러스터당 브로커 수

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

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

m5.4xl, m7g.4xl 이상 인스턴스의 클러스터 처리량을 최적화합니다.

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

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

Num.network.threads는 브로커가 들어오는 모든 요청을 수신하고 응답을 반환하는 데 사용하는 스레드 수입니다. 네트워크 스레드는 들어오는 요청을 요청 대기열에 배치하여 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

주제 ID 불일치 문제를 방지하려면 최신 Kafka를 AdminClient 사용하십시오.

Kafka 버전 2.8.0 이상을 사용하는 클러스터의 주제 파티션을 늘리거나 --zookeeper 재할당하기 위해 플래그가 있는 2.8.0 미만의 Kafka AdminClient 버전을 사용하면 주제 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 버전을 업데이트할 때) 또는 Amazon MSK가 브로커를 교체할 때 MSK 클러스터의 가용성을 높일 수 있습니다.

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

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

• 최소 동기화 복제본(minISR)을 최대 RF - 1로 설정합니다. RF와 동일한 minISR은 롤링 업데이트 중에 클러스터 생성을 방해할 수 있습니다. 2개의 minISR을 사용하면 하나의 복제본이 오프라인 상태일 때 3방향 복제된 항목이 가능합니다.

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

CPU 사용량 모니터링

Amazon MSK는 브로커의 총 CPU 사용률(CPU User + CPU System으로 정의됨)을 60% 미만으로 유지할 것을 강력하게 권장합니다. 클러스터 총 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. 클러스터에서 브로커 크기를 업데이트하면 Amazon MSK가 순차적으로 브로커를 오프라인 상태로 전환하고 파티션 리더십을 일시적으로 다른 브로커에 재할당한다는 점을 기억하십시오. 크기 업데이트는 일반적으로 브로커당 10~15분 정도 소요됩니다.

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

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

기타 권장 사항:

• 부하 분산을 위한 프록시로 브로커당 총 CPU 사용률을 모니터링합니다. 브로커의 CPU 사용률이 지속적으로 고르지 않다면 클러스터 내에서 부하가 고르게 분산되지 않았다는 신호일 수 있습니다. Amazon MSK는 Cruise Control을 사용하여 파티션 할당을 통한 부하 분산을 지속적으로 관리할 것을 권장합니다.

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

• JMX 스크레입 간격: Prometheus 기능으로 개방형 모니터링을 사용하도록 설정하는 경우 Prometheus 호스트 구성(prometheus.yml)에 60초 이상의 스크레입 간격(scrape_interval: 60초)을 사용하는 것을 권장합니다. 스크랩 간격을 줄이면 클러스터의 CPU 사용량이 늘어날 수 있습니다.

디스크 공간 모니터링

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

• 자동 크기 조정를 사용합니다. 수동 조정에 설명된 대로 브로커 스토리지를 수동으로 늘릴 수도 있습니다.

• 메시지 보존 기간 또는 로그 크기를 줄입니다. 이렇게 하는 방법에 대한 정보는 데이터 보존 파라미터 조정 단원을 참조하십시오.

• 사용되지 않는 항목을 삭제합니다.

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

데이터 보존 파라미터 조정

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

클러스터 수준에서 보존 정책을 지정하려면, log.retention.hours, log.retention.minutes, log.retention.ms 또는 log.retention.bytes 파라미터 중 하나 이상을 설정합니다. 자세한 정보는 사용자 지정 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는 가비지 수집 후 사용 중인 전체 힙 메모리의 백분율입니다. HeapMemoryAfterGC증가율이 60% 를 넘으면 조치를 취하는 CloudWatch 경보를 생성하는 것이 좋습니다.

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

MSK 이외의 브로커 추가 금지

ZooKeeper기반 클러스터의 경우 Apache ZooKeeper 명령을 사용하여 브로커를 추가하면 이러한 브로커가 MSK 클러스터에 추가되지 않으며 ZooKeeper Apache에 클러스터에 대한 잘못된 정보가 포함됩니다. 이로 인해 데이터가 손실될 수 있습니다. 지원되는 클러스터 작업은 Amazon MSK: 작동 방식 단원을 참조하십시오.

전송 중 암호화 활성화

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

파티션 재할당

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