기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
MSK 프로비저닝 클러스터에 패치 적용
Amazon MSK는 주기적으로 클러스터의 브로커에 소프트웨어를 업데이트합니다. 유지 관리에는 계획된 업데이트 또는 계획되지 않은 수리가 포함됩니다. 계획된 유지 관리에는 클러스터의 상태, 보안 및 성능을 유지하는 데 필요한 운영 체제 업데이트, 보안 업데이트, 인증서 갱신 및 기타 소프트웨어 업데이트가 포함됩니다. 갑작스러운 인프라 성능 저하를 해결하기 위해 계획되지 않은 유지 관리를 수행합니다. Standard 및 Express 브로커에 대한 유지 관리를 수행하지만 경험은 다릅니다.
표준 브로커에 대한 패치 적용
모범 사례를 따르는 경우 표준 브로커를 업데이트해도 애플리케이션의 쓰기 및 읽기에는 영향을 미치지 않습니다.
Amazon MSK는 소프트웨어에 대한 롤링 업데이트를 사용하여 클러스터의 고가용성을 유지합니다. 이 프로세스 중에 브로커는 한 번에 하나씩 재부팅되고 Kafka는 리더십을 다른 온라인 브로커로 자동으로 이동합니다. Kafka 클라이언트에는 파티션의 리더십 변화를 자동으로 감지하고 MSK 클러스터에 데이터를 계속 쓰고 읽을 수 있는 메커니즘이 내장되어 있습니다. 패치 적용 중을 포함하여 클러스터를 항상 원활하게 작동Apache Kafka 클라이언트 모범 사례하려면를 따르세요.
브로커가 오프라인 상태가 된 후 클라이언트에서 일시적인 연결 해제 오류가 표시되는 것은 정상입니다. 또한 짧은 기간(최대 2분이며 일반적으로 더 짧음) 동안 p99 읽기 및 쓰기 지연 시간(일반적으로 높은 밀리초, 최대 약 2초)의 어느 정도 급증도 관찰할 수 있습니다. 이러한 스파이크는 예상되며 클라이언트가 새 리더 브로커에 다시 연결해도 발생합니다. 이는 생산 또는 소비에 영향을 미치지 않으며 재연결 후 이 문제는 해결됩니다. 자세한 내용은 오프라인 및 클라이언트 장애 조치 브로커를 참조하세요.
또한 종료된 브로커의 파티션UnderReplicatedPartitions이 더 이상 데이터를 복제하지 않으므로 예상되는 지표가 증가하는 것을 확인할 수 있습니다. 이는 다른 브로커에서 호스팅되는 이러한 파티션에 대한 복제본이 이제 요청을 처리하고 있으므로 애플리케이션의 쓰기 및 읽기에 영향을 주지 않습니다.
소프트웨어 업데이트 후 브로커가 다시 온라인 상태가 되면 오프라인 상태일 때 생성된 메시지를 '확인'해야 합니다. 확인 중에 볼륨 처리량 및 CPU 사용량이 증가하는 것을 관찰할 수도 있습니다. 이러한 증가는 브로커에 충분한 CPU, 메모리, 네트워크 및 볼륨 리소스가 있는 경우 클러스터에 대한 쓰기 및 읽기에는 영향을 미치지 않습니다.
Express 브로커에 대한 패치 적용
Express 브로커에는 유지 관리 기간이 없습니다. Amazon MSK는 시간 분산 방식으로 클러스터를 지속적으로 자동으로 업데이트합니다. 즉, 한 달 동안 가끔씩 단일 브로커가 재부팅될 수 있습니다. 이렇게 하면 클러스터 전체의 일회성 유지 관리 기간에 대한 계획이나 조정을 할 필요가 없습니다. 항상 그렇듯이 브로커 재부팅 중에는 트래픽이 중단되지 않습니다. 리더십이 요청을 계속 처리하는 다른 브로커로 변경되기 때문입니다.
Express 브로커는 유지 관리 중에 발생할 수 있는 로드 변경에 대해 클러스터를 복원할 수 있도록 모범 사례 설정 및 가드레일로 구성됩니다. Amazon MSK는 Express 브로커에 대한 처리량 할당량을 설정하여 클러스터 오버로드로 인한 영향을 완화하여 브로커 재시작 중에 문제를 일으킬 수 있습니다. 이러한 개선 사항을 통해 Express 브로커를 사용할 때 사전 알림, 계획 및 유지 관리 기간이 필요하지 않습니다.
Express 브로커는 항상 세 가지 방법으로 데이터를 복제하므로 재부팅 중에 클라이언트가 자동으로 장애 조치를 수행합니다. 복제 인수가 1 또는 2로 설정되어 있기 때문에 주제를 사용할 수 없게 되는 것에 대해 걱정할 필요가 없습니다. 또한 다시 시작된 Express 브로커를 따라잡는 것이 표준 브로커보다 빠릅니다. Express 브로커의 패치 속도가 빨라지면 클러스터에 대해 예약한 컨트롤 플레인 활동에 대한 계획 중단을 최소화할 수 있습니다.
모든 Apache Kafka 애플리케이션과 마찬가지로 Express 브로커에 연결하는 클라이언트에 대한 공유 클라이언트-서버 계약은 여전히 존재합니다. 브로커 간의 리더십 장애 조치를 처리하도록 클라이언트를 구성하는 것은 여전히 중요합니다. 패치 적용 중을 포함하여 클러스터를 항상 원활하게 작동Apache Kafka 클라이언트 모범 사례하려면를 따르세요. 브로커 재시작 후 클라이언트에서 일시적인 연결 해제 오류가 표시되는 것은 정상입니다. 팔로워 브로커가 파티션 리더십을 맡게 되므로 이는 생산 및 소비에 영향을 주지 않습니다. Apache Kafka 클라이언트는 자동으로 장애 조치를 수행하고 새 리더 브로커에 요청을 보내기 시작합니다.
