MSK 클러스터의 고가용성 모범사례 충족 여부 확인 및 설정 변경하는 방법
3 minutos de lectura
Nivel de contenido: Intermedio
0
해당 기사에서는 MSK 클러스터의 고가용성 모범 사례를 준수하는지 확인하는 방법 및 설정과 관련하여 설명합니다.
MSK는 버전 업그레이드 혹은 보안 패치 수행 시 Rolling Restart 프로세스를 수행하므로 업데이트/패치가 진행되는 동안 MSK 클러스터를 사용 가능하도록 합니다. [1] 해당 이벤트가 수행되는 동안 MSK 클러스터의 다운타임이 발생하지는 않지만, Rolling Restart를 진행하며 브로커 노드를 차례대로 재부팅하는 동안 해당 브로커를 사용할 수 없기 때문에 MSK 클러스터에 고가용성 모범사례를 확인하여 고가용성을 유지하도록 설정하는것이 필요합니다. 아래는 고가용성을 유지하기 위한 모범사례입니다.
[+] 모범 사례 - 고가용성 클러스터 빌드
https://docs.aws.amazon.com/ko_kr/msk/latest/developerguide/bestpractices.html#ensure-high-availability
1. 3개의 AZ 클러스터를 설정합니다.
2. 토픽 별 Replication Factor(RF) 가 3개 이상인지 확인합니다. 참고로 RF가 1인 경우 패치 작업 중에 오프라인 파티션이 발생할 수 있으며 RF 가 2 이면 데이터가 손실될 수 있습니다.
3. 최소 동기화 복제본 (MiniSR, min.insync.replicas[2]) 을 최대 RF-1로 설정하여 파티션 복제 세트가 하나의 복제본이 오프라인 상태이거나 복제 부족을 견딜 수 있도록 합니다.
4. 컨슈머/프로듀서에 설정된 브로커 Endpoint 에 각 가용 영역의 브로커가 하나 이상 포함되어 있는지 확인합니다. 여러 브로커가 있으면 클라이언트 I/O를 지원하는 특정 브로커가 패치가 적용되기 시작할 때 failover 가 가능합니다.
MSK 클러스터의 AZ의 개수를 확인하는 방법
- AWS 콘솔 접속> [MSK 클러스터] 클릭 > 속성
- [브로커],[브로커 세부 정보]에서 브로커의 가용영역 및 브로커의 개수를 확인할수있습니다.
Broker엔드포인트 확인
- cli 환경 또는 Producer/ Consumer 환경에서 아래와 같이 여러개의 브로커 엔드포인트를 사용하고있는지 확인합니다.
예시 : [b-3.test.xxxxxxxx.kafka.us-east-1.amazonaws.com:9092](http://b-3.test.xxxxxxxx.kafka.us-east-1.amazonaws.com:9092) ,[b-2.test.xxxxxxxxkafka.us-east-1.amazonaws.com:9092](http://b-2.test.xxxxxxxxkafka.us-east-1.amazonaws.com:9092) ,[b-1.test.xxxxxxxx.kafka.us-east-1.amazonaws.com:9092](http://b-1.test.xxxxxxxx.kafka.us-east-1.amazonaws.com:9092)
- 해당 브로커 엔드포인트는 [MSK 클러스터], [클라이언트 정보 보기] 에서 부트스트랩 서버를 통해 확인 가능합니다.
Replication Factor 및 최소 동기화 복제본(ISR) 확인하는 방법
- 아래의 명령어를 통해 kafka 토픽과 관련된 설정을 확인합니다.
Command
./kafka-topics.sh --bootstrap-server <$brokers> --command-config client.properties --describe --topic <TestTopic>
Output:
Topic: <TestTopic> TopicId: FETy9.... PartitionCount: 1 ReplicationFactor: 2 Configs: min.insync.replicas=1,message.format.version=3.0-IV1,unclean.leader.election.enable=true
Topic: <TestTopic> Partition: 0 Leader: 1 Replicas: 1,2 Isr: 1,2
- 위에 나와있는대로 ReplicationFactor 는 2로 min.insync.replicas 1임을 확인할 수 있습니다.
ReplicationFactor 변경하는 방법
- 아래의 방법을 통해 토픽의 Replication Factor를 2개에서 3개로 변경합니다.
- change-replication-factor.json 파일을 아래와 같이 생성합니다.
{
"version":1,
"partitions":[
{
"topic":"<TestTopic>",
"partition":0,
"replicas":[1,2,3]
}
]
}
- ./kafka-reassign-partitions.sh를 통해 Replication Factor를 변경합니다. [2]
./kafka-reassign-partitions.sh --bootstrap-server <$brokers> --reassignment-json-file change-replication-factor.json --execute --command-config client.properties
MiniSR 변경하기
- 아래의 명령을 통해 기존 토픽에 설정되어있는 MiniSR를 2로 변경할 수 있습니다. [3]
./kafka-configs.sh --bootstrap-server <$brokers> --alter --entity-type topics --entity-name <TestTopic> --command-config client.properties --add-config min.insync.replicas=2
Replication Factor , MiniSR 설정의 변경 확인
- 아래와 같이 Replication Factor는 3으로 min.insync.replicas는 2로 정상적으로 변경된것을 확인할수있습니다.
Command
./kafka-topics.sh --bootstrap-server <$brokers> --command-config client.properties --describe --topic <TestTopic>
Output
Topic: <TestTopic> TopicId: FETy9.... PartitionCount: 1 ReplicationFactor: 3 Configs: min.insync.replicas=2,message.format.version=3.0-IV1,unclean.leader.election.enable=true
Topic: <TestTopic> Partition: 0 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
참고
[1] 보안 패치로 인해 클라이언트 I/O가 중단되지 않도록 하려면 어떻게 해야 하나요?
https://repost.aws/ko/knowledge-center/msk-avoid-disruption-during-patching
[2] Re-assign partitions after changing cluster size
[3] Kafka Topic Configuration: Minimum In-Sync Replicas - Overriding Topic Configuration Defaults
https://www.conduktor.io/kafka/kafka-topic-configuration-min-insync-replicas/
Sin comentarios
Contenido relevante
- OFICIAL DE AWSActualizada hace un año
- OFICIAL DE AWSActualizada hace 2 años
- OFICIAL DE AWSActualizada hace 2 años
- OFICIAL DE AWSActualizada hace 2 años