Event Streams 가용성을 위한 서비스 레벨 계약(SLA)

Standard 플랜

Event Streams 표준 플랜에서는 다중 구역 지역 배치를 통해 고가용성 아키텍처를 제공합니다. 다중 구역 위치에서 Event Streams 서비스는 세 개의 가용성 영역에 분산되어 있습니다. 즉, 클러스터가 단일 구역 또는 해당 영역 내의 구성요소의 실패에 대해 복원력이 있음을 의미합니다.

Event Streams 는 스탠다드 플랜에서 99.99 %의 가용성을 제공합니다. IBM Cloud®에서 고가용성 서비스의 SLA에 대한 자세한 정보는 다음을 참조하십시오. IBM Cloud(퍼블릭 클라우드)에 대한 SLA(Service Level Agreement).

Enterprise 플랜

Event Streams 엔터프라이즈 플랜에서는 다중 구역 지역 배치를 통해 고가용성 아키텍처를 제공합니다. 다중 구역 위치에서 Event Streams 서비스는 세 개의 가용성 구역에 분산됩니다. 즉, 단일 구역이나 해당 구역에 있는 구성요소가 실패하는 경우 클러스터가 복원될 수 있습니다.

다중 구역 지역 배포의 경우, 엔터프라이즈 플랜에서 가용성 99.99 %로 Event Streams 서비스가 제공됩니다. IBM Cloud의 고가용성 서비스에 대한 SLA에 대한 자세한 정보는 IBM Cloud(퍼블릭 클라우드)에 대한 서비스 레벨 계약을 참조하십시오.

Event Streams 가 단일 구역 위치 와 같이 가용성이 높지 않은 구성에서 실행될 경우, 가용성은 99.9 %입니다. IBM Cloud에서 고가용성이 아닌 서비스의 SLA에 대한 자세한 정보는 IBM Cloud(퍼블릭 클라우드)의 서비스 레벨 계약을 참조하십시오.

어떻게 측정합니까?

서비스 인스턴스는 성능, 오류율 및 통합 오퍼레이션에 대한 응답을 지속적으로 모니터링합니다. 가동 중단이 기록됩니다. 자세한 정보는 Event Streams를 참조하십시오.

가용성은 Kafka 항목에서 메시지를 생성하고 사용할 수 있는 애플리케이션의 기능을 말합니다.

이러한 가용성을 달성하기 위해 고려해야 할 사항은 무엇입니까?

애플리케이션 관점에서 높은 수준의 가용성을 달성하려면 연결성, 처리량 및 메시지 일관성 및 지속성을 고려해야 합니다. 사용자는 비즈니스에 이 세 가지 요소를 최적화하기 위해 애플리케이션을 설계할 책임이 있습니다.

연결

클라우드의 동적 특성으로 인해 애플리케이션은 연결 중단을 예상해야 합니다. 연결 중단은 서비스 장애로 간주되지 않습니다.

재시도

Kafka 클라이언트는 재연결 논리를 제공하지만, 명시적으로 생성자에 대한 재연결을 사용으로 설정해야 합니다. 자세한 내용은 retries 속성을 참조하십시오. 60초 이내에 다시 연결됩니다.

중복

재시도를 사용하면 중복 메시지가 발생할 수 있습니다. 연결 중단 시점에 따라 작성자는 서버에서 메시지가 성공적으로 처리되었는지 확인하지 못할 수 있으므로 다시 연결했을 때 메시지를 다시 전송해야 합니다. 중복 메시지를 예상하도록 애플리케이션을 설계하십시오.

중복을 허용할 수 없으면 idempotent 생성자 기능(Kafka 1.1부터)을 사용하여 재시도 중 중복을 방지하십시오. 자세한 내용은 enable.idempotence 속성을 참조하십시오.

처리량

처리량은 클러스터에서 보내고 받을 수 있는 초당 바이트 수로 표시됩니다.

표준 플랜에 대한 특정 안내

처리량 안내 정보는 한계 및 할당량 - 표준을 참조하십시오.

엔터프라이즈 플랜에 대한 특정 안내

처리량 지침 정보는 한계 및 할당량 - 엔터프라이즈를 참조하십시오.

수치

애플리케이션이 수행되는 방법을 인식하도록 애플리케이션을 인스트루먼트합니다. 예를 들어, 보내고 받은 메시지 수, 메시지 크기 및 리턴 코드 등이 있습니다. 애플리케이션의 사용량을 이해하면 해당 애플리케이션의 리소스를 적절하게 구성하는 데 도움이 됩니다(예: 항목에 대한 메시지 보존 시간).

포화

클러스터에 생성될 수 있는 트래픽의 한계에 도달하면 생성자가 제한되기 시작하고, 대기 시간이 증가하며, 궁극적으로 제한시간 초과 오류와 같은 오류가 발생합니다. 구성에 따라 메시지 일관성 및 지속성에도 영향을 줄 수 있습니다. 자세한 정보는 메시지의 일관성 및 지속성을 참조하십시오.

메시지의 일관성 및 지속성

Kafka에서는 실패 시 사용할 수 있는 클러스터의 다른 노드에서 수신한 메시지를 복제하여 가용성과 내구성을 확보합니다. Event Streams에서는 세 개의 복제본(default.replication.factor = 3)을 사용합니다. 즉, 노드에서 수신한 각 메시지가 다른 가용성 구역의 다른 두 노드로 복제됩니다. 이렇게 하면 데이터나 기능의 손실 없이 노드 또는 가용성 영역의 손실을 허용할 수 있습니다.

생성자 acks 모드

모든 메시지가 복제되지만, 애플리케이션은 프로듀서의 acks 모드 속성을 사용하여 프로듀서가 생성한 메시지가 서비스로 얼마나 강력하게 전송되는지를 제어할 수 있습니다. 이 특성은 속도와 메시지 손실 위험 사이에서 선택할 수 있게 합니다. Kafka 3.0에서 기본 클라이언트 설정은 acks=all (이 버전 이전에는 acks=1 였음) 입니다. acks=all 설정은 연결된 브로커와 클러스터에 있는 하나 이상의 추가 브로커가 메시지 수신을 수신확인하는 즉시 생성자가 성공을 리턴함을 의미합니다. acks=all 사용의 장점은 최상위 레벨의 지속성을 제공하여 메시지 데이터 손실을 방지한다는 점입니다.

동기화 복제본

Event Streams 가 사용하는 구성에서 Kafka 는 각 파티션 복제본의 리더가 될 하나의 브로커와 팔로워가 될 두 개의 다른 브로커를 선택합니다. 클라이언트의 메시지 데이터가 파티션의 리더 (leader) 로 전송되고 팔로워 (follower) 로 복제됩니다. 팔로워가 리더와 보조를 맞추는 경우 "동기화" 복제본으로 간주됩니다. 정의에 따라 리더는 항상 동기화된 것으로 간주됩니다.

브로커에 적용되는 유지보수로 인해 파티션의 리더를 사용할 수 없게 되면 Kafka 는 자동으로 다른 동기화 복제본 중 하나를 새 리더가 되도록 선택합니다. 이 프로세스는 신속하게 발생하며 Kafka 클라이언트에 의해 자동으로 처리됩니다.

불결한 지도자 선거

Event Streams 는 비정리 리더 선택을 사용 안함으로 설정합니다. 이 설정은 변경할 수 없습니다.

정리되지 않은 리더 선출 이라는 용어는 파티션에 대한 모든 동기화 복제본이 사용 불가능하게 되는 상황에서 Kafka 가 응답하는 방법을 설명합니다. 정리되지 않은 리더 선택이 사용으로 설정되면 Kafka 는 동기화되었는지 여부에 관계없이 첫 번째 복제본을 파티션의 리더로 사용할 수 있게 하여 복구합니다. 이로 인해 리더로 선택된 복제본이 이전 리더의 모든 메시지 데이터를 복제하지 않은 경우 메시지 데이터가 유실될 수 있습니다. Event Streams의 경우와 같이 정리되지 않은 리더 선택이 사용 안함으로 설정되면 Kafka 는 동기화된 복제본이 사용 가능하게 될 때까지 대기하고 파티션의 새 리더가 되도록 선택합니다. 이렇게 하면 정리되지 않은 리더 선택을 사용할 때 발생할 수 있는 메시지 데이터 손실 가능성을 방지할 수 있습니다. Kafka 는 클라이언트가 메시지 데이터를 생성하고 이용하기 위해 파티션을 사용하기 전에 특정 브로커가 다시 온라인이 되기를 기다려야 할 수 있기 때문에 복구가 더 오래 걸릴 수 있습니다.

단일 구역 위치 배치

가용성을 최대화하려면 다중 구역 위치에 빌드된 고가용성 공용 환경을 사용하는 것이 좋습니다. 다중 구역 위치에서 Kafka 클러스터는 3개의 가용성 구간에 분산되어 있습니다. 즉, 단일 구역이 실패하거나 해당 구역의 컴포넌트가 실패하는 경우 클러스터를 복원할 수 있습니다. 일부 고객은 지리적 위치를 필요로 하므로 지리적으로 로컬이지만 단일 구역 위치에 Event Streams 클러스터를 프로비저닝하려고 합니다. Event Streams 는 이 배포 모델을 지원하지만, 다음과 같은 가용성 트레이드오프를 염두에 두어야 합니다

  • 단일 구역 위치에서 단일 실패로 인해 일정 기간 동안 클러스터가 오프라인이 되는 카테고리가 있습니다. 예를 들어, 전체 데이터 센터나 업데이트가 실패하거나 기본 하이퍼바이저, SAN 또는 네트워크와 같은 공유 컴포넌트가 실패할 수 있습니다. 이 실패는 단일 구역 위치의 SLA 감소로 나타납니다.

  • Kafka 를 여러 구역에 분산시키는 것의 장점은 전체 클러스터를 무너뜨릴 수 있는 실패의 가능성을 최소화하는 것입니다. 반면에, 하나의 장애가 한 구역 내의 전체 클러스터를 무너뜨릴 가능성이 작습니다. 최악의 경우 데이터도 유실될 수 있습니다. 예를 들어, 생성자가 acks=all을(를) 사용하더라도 모든 Kafka 노드가 동시에 작동 중지되면 브로커가 수신을 확인했지만 기본 파일 시스템에서 디스크로 비우기를 완료하지 않았다는 메시지가 표시될 수 있습니다. 플러시되지 않은 메시지는 잠재적으로 손실될 수 있습니다.

자세한 정보는 메시지 수신확인을 참조하십시오. 대부분의 유스 케이스에서 이점은 문제가 되지 않습니다. 그러나 모든 환경에서 메시지 유실이 발생하지 않아야 하는 경우 다중 가용성 구역 클러스터, 교차 영역 복제 또는 생성자 측 메시지 체크포인트와 같은 다른 전략을 사용하십시오.

자세한 정보는 단일 구역 클러스터 및 다중 구역 클러스터를 참조하십시오.