REL 4: 분산 시스템에서 장애 방지를 위한 상호 작용은 어떻게 설계합니까?
분산 시스템에서 구성 요소(예: 서버 또는 서비스)는 통신 네트워크를 사용하여 상호 연결됩니다. 워크로드는 이러한 네트워크에서 데이터 손실 또는 지연 시간이 발생하더라도 안정적으로 작동해야 합니다. 분산 시스템의 구성 요소는 다른 구성 요소나 워크로드에 부정적인 영향을 미치지 않는 방식으로 작동해야 합니다. 여기에 나온 모범 사례는 장애를 방지하고 MTBF(평균 장애 간격)를 개선합니다.
리소스
AWS re:Invent 2019: Moving to event-driven architectures (SVS308)
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems,
Big and Small ARC337 (includes loose coupling, constant work, static stability)
AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge
(MAD205)
What Is Amazon EventBridge?
What Is Amazon Simple Queue Service?
Amazon EC2: Ensuring Idempotency
The Amazon Builders' Library: Challenges with distributed systems
모범 사례:
-
필요한 분산 시스템의 종류 식별: 하드 실시간 분산 시스템은 응답을 동기식으로 신속하게 제공해야 하며, 소프트 실시간 시스템은 몇 분 이상의 보다 관대한 기간에 응답을 제공할 수 있습니다. 오프라인 시스템은 배치 또는 비동기식 처리를 통해 응답을 처리합니다. 하드 실시간 분산 시스템은 안정성 요구 사항이 가장 엄격합니다.
-
약결합 종속성 구현:: 대기열 처리 시스템, 스트리밍 시스템, 워크플로 및 로드 밸런서와 같은 종속성은 약결합됩니다. 약한 결합은 한 구성 요소의 동작을 다른 종속 구성 요소에서 분리하여 복원력 및 민첩성을 높이는 데 도움이 됩니다.
-
모든 응답의 멱등성 유지: 멱등성이 있는 서비스는 각 요청이 정확히 한 번만 완료되도록 합니다. 이렇게 하면 다수의 동일한 요청에서 단일 요청과 동일한 결과가 나옵니다. 멱등성이 있는 서비스를 사용하면 클라이언트가 요청이 오류로 여러 번 처리될 것이라는 염려 없이 재시도를 시행할 수 있습니다. 이를 위해 클라이언트는 멱등성 토큰을 사용하여 API 요청을 실행할 수 있으며 요청이 반복될 때마다 동일한 토큰이 사용됩니다. 멱등성이 있는 서비스 API는 토큰을 사용하여 요청이 처음 완료되었을 때 반환된 응답과 동일한 응답을 반환합니다.
-
일정한 작업 처리: 대규모 로드가 급속도로 변경되면 시스템에서 장애가 발생할 수 있습니다. 예를 들어 서버 수천 대의 상태를 모니터링하는 상태 확인 시스템은 매번 동일한 크기의 페이로드(현재 상태의 전체 스냅샷)를 전송해야 합니다. 장애가 발생한 서버가 없든 모든 서버에서 장애가 발생하든, 상태 확인 시스템은 대규모의 급속한 변경이 없는 일정한 작업을 처리합니다.
개선 계획
필요한 분산 시스템의 종류 식별
The Amazon Builders' Library: Challenges with distributed systems
- 하드 실시간 분산 시스템에서는 응답이 동기식으로 신속하게 제공되어야 합니다.
- 소프트 실시간 시스템은 상대적으로 응답 시간의 여유가 있어 분 단위 이상의 응답 시간이 허용됩니다.
- 오프라인 시스템은 배치 또는 비동기식 처리를 통해 응답을 처리합니다.
- 하드 실시간 분산 시스템은 안정성 요구 사항이 가장 엄격합니다.
약결합 종속성 구현:
AWS re:Invent 2019: Moving to event-driven architectures (SVS308)
What Is Amazon EventBridge?
What Is Amazon Simple Queue Service?
- Amazon EventBridge를 사용하면 약결합되고 분산된 이벤트 중심의 아키텍처를 구축할 수 있습니다.
AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205) - 한 구성 요소에 대한 변경이 다른 종속 구성 요소의 변경을 강제하는 경우 이러한 구성 요소는 강하게 결합된 것입니다. 약한 결합에서는 이 종속성이 분리되므로 종속 구성 요소에서는 버전이 지정되고 게시된 인터페이스만 알면 됩니다.
- 가능한 경우 구성 요소 상호 작용을 비동기식으로 만듭니다. 이 모델은 즉각적인 응답이 필요하지 않고 요청이 등록되었다는 확인으로 충분한 상호 작용에
적합합니다.
AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)
모든 응답의 멱등성 유지
- 클라이언트는 멱등성 토큰을 사용하여 API 요청을 실행할 수 있으며 요청이 반복될 때마다 동일한 토큰이 사용됩니다. 멱등성이 있는 서비스 API는
토큰을 사용하여 요청이 처음 완료되었을 때 반환된 응답과 동일한 응답을 반환합니다.
Amazon EC2: Ensuring Idempotency
일정한 작업 처리
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work)
- 성공 또는 실패 횟수와 관계없이 페이로드 크기가 일정하게 유지되도록 워크로드를 엔지니어링합니다.
- 예를 들어 상태 확인 시스템이 100,000개의 서버를 모니터링하는 경우 서버 장애율이 정상적으로 낮을 때는 서버에 가해지는 로드가 작습니다. 그러나 중대한 이벤트로 인해 이러한 서버의 절반이 비정상 상태가 될 때 상태 확인 시스템에서 알림 시스템을 업데이트하고 클라이언트로 상태를 전달하려면 상태 확인 시스템이 과부하가 될 수 있습니다. 상태 확인 시스템에서는 매번 현재 상태의 전체 스냅샷을 전송하는 것이 낫습니다. 100,000개의 서버 상태(각각 비트로 표시됨)는 12.5KB 페이로드에 불과합니다. 장애가 발생한 서버가 없든 모든 서버에서 장애가 발생하든 상태 확인 시스템은 일정한 작업을 처리하므로 대규모의 급속한 변경이 시스템 안정성에 위협이 되지 않습니다. 실제로 Amazon Route 53 상태 확인의 제어 영역은 이 방식으로 설계되었습니다.