# REL 4  분산 시스템에서 장애 방지를 위한 상호 작용은 어떻게 설계합니까? 분산 시스템에서 구성 요소(예: 서버 또는 서비스)는 통신 네트워크를 사용하여 상호 연결됩니다. 워크로드는 이러한 네트워크에서 데이터 손실 또는 지연 시간이 발생하더라도 안정적으로 작동해야 합니다. 분산 시스템의 구성 요소는 다른 구성 요소나 워크로드에 부정적인 영향을 미치지 않는 방식으로 작동해야 합니다. 여기에 나온 모범 사례는 장애를 방지하고 MTBF(평균 장애 간격)를 개선합니다. **Topics** + [REL04-BP01 필요한 분산 시스템의 종류 식별](rel_prevent_interaction_failure_identify.md) + [REL04-BP02 느슨하게 결합된 종속성 구현](rel_prevent_interaction_failure_loosely_coupled_system.md) + [REL04-BP03 일정한 작업 수행](rel_prevent_interaction_failure_constant_work.md) + [REL04-BP04 모든 응답의 멱등성 유지](rel_prevent_interaction_failure_idempotent.md) # REL04-BP01 필요한 분산 시스템의 종류 식별 하드 실시간 분산 시스템에서는 응답을 동기식으로 신속하게 제공해야 하지만, 소프트 실시간 시스템에서는 응답하기 위한 몇 분 이상의 여유가 주어집니다. 오프라인 시스템은 배치 또는 비동기식 처리를 통해 응답을 처리합니다. 하드 실시간 분산 시스템은 안정성 요구 사항이 가장 엄격합니다. 요청/응답 서비스로 알려진 높은 수준의 실시간 분산 시스템과 관련된 문제가 [분산 시스템의 가장 어려운 문제라고](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) 할 수 있습니다. 이 문제가 어려운 이유는 언제 도착할지 예상할 수 없는 요청에 대해 신속하게 응답을 제공해야 하기 때문입니다(예: 응답이 올 때까지 앞에서 대기하는 고객). 예를 들어 프런트엔드 웹 서버, 주문 파이프라인, 신용 카드 거래, 모든 AWS API 및 전화 통신이 여기에 포함됩니다. **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음 ## 구현 가이드 + 필요한 분산 시스템의 종류를 식별합니다. 분산 시스템에는 지연 시간, 확장 및 축소, 네트워킹 API에 대한 이해, 데이터 마샬링 및 마샬링 취소와 알고리즘(예: Paxos)의 복잡성과 같은 당면 과제가 있었습니다. 시스템이 커지고 분산화가 확대되자, 이론적으로는 극단적 사례에 해당했던 문제들이 주기적으로 발생하기 시작했습니다. + [Amazon Builders' Library: 분산 시스템의 도전 과제](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) + 하드 실시간 분산 시스템에서는 응답이 동기식으로 신속하게 제공되어야 합니다. + 소프트 실시간 시스템은 상대적으로 응답 시간의 여유가 있어 분 단위 이상의 응답 시간이 허용됩니다. + 오프라인 시스템은 배치 또는 비동기식 처리를 통해 응답을 처리합니다. + 하드 실시간 분산 시스템은 안정성 요구 사항이 가장 엄격합니다. ## 리소스 **관련 문서:** + [Amazon EC2: Ensuring Idempotency(멱등성 보장)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) + [Amazon Builders' Library: 분산 시스템의 도전 과제](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) + [Amazon Builders' Library: (안정성, 지속적인 작업 및 맛 좋은 한 잔의 커피)](https://aws.amazon.com/builders-library/reliability-and-constant-work/) + [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [Amazon Simple Queue Service란 무엇입니까?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) **관련 동영상:** + [AWS New York Summit 2019: Intro to Event-driven Architectures(이벤트 중심 아카텍처 및 Amazon EventBridge 소개) 및 Amazon EventBridge(MAD205)](https://youtu.be/tvELVa9D9qU) + [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small(루프 닫기 및 마음 열기: 규모에 상관없이 시스템을 제어하는 방법) ARC337(느슨한 결합, 일정한 작업, 정적 안정성 포함)](https://youtu.be/O8xLxNje30M) + [AWS re:Invent 2019: Moving to event-driven architectures(이벤트 중심 아키텍처로 전환)(SVS308)](https://youtu.be/h46IquqjF3E) # REL04-BP02 느슨하게 결합된 종속성 구현 대기열 처리 시스템, 스트리밍 시스템, 워크플로 및 로드 밸런서와 같은 종속성은 약결합됩니다. 느슨한 결합은 한 구성 요소의 동작을 다른 종속 구성 요소에서 분리하여 복원력 및 민첩성을 높이는 데 도움이 됩니다. 한 구성 요소에 대한 변경이 다른 종속 구성 요소의 변경을 강제하는 경우 이러한 구성 요소는 *강하게* 결합된 것입니다. *느슨한* 결합에서는 이 종속성이 분리되므로 종속 구성 요소에서는 버전이 지정되고 게시된 인터페이스만 알면 됩니다. 종속성 간에 느스한 결합을 구현하면 한 구성 요소의 장애가 다른 구성 요소에 영향을 미치지 않도록 분리됩니다. 느슨한 결합을 사용하면 종속 구성 요소에 미치는 위험을 최소화하면서 추가 코드 또는 기능을 추가할 수 있습니다. 또한 종속성의 기본 구현을 스케일 아웃하거나 변경할 수 있으므로 확장성이 개선됩니다. 느슨한 결합을 통해 복원력을 추가로 개선하려면 가능한 경우 구성 요소가 비동기식으로 상호 작용하도록 합니다. 이 모델은 즉각적인 응답이 필요하지 않고 요청이 등록되었다는 확인으로 충분한 상호 작용에 적합합니다. 이러한 상호 작용에는 이벤트를 생성하는 구성 요소와 이벤트를 사용하는 구성 요소가 포함됩니다. 두 구성 요소는 직접적인 지점 간 상호 작용을 통해 통합되지 않으며 일반적으로 내구성이 있는 중간 스토리지 계층(예: SQS 대기열 또는 Amazon Kinesis 또는 AWS Step Functions와 같은 스트리밍 데이터 플랫폼)을 통해 통합됩니다. ![\[대기열 처리 시스템 및 로드 밸런서와 같은 종속성이 느슨하게 결합된 것을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/loosely-coupled-dependencies.png) Amazon SQS 대기열과 Elastic Load Balancer는 느슨한 결합을 위한 중간 계층을 추가할 수 있는 두 가지 방법의 예입니다. AWS 클라우드에서는 Amazon EventBridge를 사용하여 이벤트 기반 아키텍처를 구축할 수도 있습니다. Amazon EventBridge는 클라이언트(이벤트 소비자)가 사용하는 서비스에서 클라이언트(이벤트 생산자)를 추상화할 수 있습니다. Amazon Simple Notification Service(Amazon SNS)는 높은 처리량의 푸시 기반 다대다 메시징이 필요할 때 효과적인 솔루션입니다. Amazon SNS 주제를 사용하면 게시자 시스템에서 다수의 구독자 엔드포인트로 메시지를 팬아웃하여 병렬 처리를 수행할 수 있습니다. 대기열은 다수의 장점을 제공하지만 대부분의 강성 실시간 시스템에서 임계 시간(주로 초 단위)을 초과한 요청은 무효한 요청(클라이언트가 포기하여 더 이상 응답을 기다리지 않는 요청)으로 간주되어 처리되지 않습니다. 이렇게 하면 오래된 요청 대신 여전히 유효한 요청일 가능성이 큰 최근 요청을 처리할 수 있습니다. **일반적인 안티 패턴:** + 워크로드의 일부로 싱글톤 배포 + 장애 조치 또는 비동기식 요청 처리 기능 없이 워크로드 티어 간에 API를 직접 호출 **이 모범 사례 수립의 이점:** 느슨한 결합은 한 구성 요소의 동작을 다른 종속 구성 요소에서 분리하여 복원력 및 민첩성을 높이는 데 도움이 됩니다. 한 구성 요소에서 발생한 장애는 다른 구성 요소로부터 격리됩니다. **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 ## 구현 가이드 + 느슨하게 결합된 종속성을 구현합니다. 대기열 처리 시스템, 스트리밍 시스템, 워크플로 및 로드 밸런서와 같은 종속성은 약결합됩니다. 느슨한 결합은 한 구성 요소의 동작을 다른 종속 구성 요소에서 분리하여 복원력 및 민첩성을 높이는 데 도움이 됩니다. + [AWS re:Invent 2019: Moving to event-driven architectures(이벤트 중심 아키텍처로 전환)(SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [Amazon Simple Queue Service란 무엇입니까?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) + Amazon EventBridge를 사용하면 느슨하게 결합되고 분산된 이벤트 중심의 아키텍처를 구축할 수 있습니다. + [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge(이벤트 중심 아카텍처 및 Amazon EventBridge 소개)(MAD205)](https://youtu.be/tvELVa9D9qU) + 한 구성 요소에 대한 변경이 다른 종속 구성 요소의 변경을 강제하는 경우 이러한 구성 요소는 강하게 결합된 것입니다. 느슨한 결합에서는 이 종속성이 분리되므로 종속 구성 요소에서는 버전이 지정되고 게시된 인터페이스만 알면 됩니다. + 가능한 경우 구성 요소 상호 작용을 비동기식으로 만듭니다. 이 모델은 즉각적인 응답이 필요하지 않고 요청이 등록되었다는 확인으로 충분한 상호 작용에 적합합니다. + [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda(Amazon SQS 및 Lambda를 사용하는 확장 가능한 서버리스 이벤트 중심 애플리케이션)(API304)](https://youtu.be/2rikdPIFc_Q) ## 리소스 **관련 문서:** + [AWS re:Invent 2019: Moving to event-driven architectures(이벤트 중심 아키텍처로 전환)(SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [Amazon EC2: Ensuring Idempotency(멱등성 보장)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) + [Amazon Builders' Library: 분산 시스템의 도전 과제](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) + [Amazon Builders' Library: Reliability, constant work, and a good cup of coffee(안정성, 지속적인 작업 및 맛 좋은 한 잔의 커피)](https://aws.amazon.com/builders-library/reliability-and-constant-work/) + [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) + [Amazon Simple Queue Service란 무엇입니까?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) **관련 동영상:** + [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge(이벤트 중심 아카텍처 및 Amazon EventBridge 소개)(MAD205)](https://youtu.be/tvELVa9D9qU) + [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small(루프 닫기 및 마음 열기: 규모에 상관없이 시스템을 제어하는 방법) ARC337(느슨한 결합, 일정한 작업, 정적 안정성 포함)](https://youtu.be/O8xLxNje30M) + [AWS re:Invent 2019: Moving to event-driven architectures(이벤트 중심 아키텍처로 전환)(SVS308)](https://youtu.be/h46IquqjF3E) + [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda(Amazon SQS 및 Lambda를 사용하는 확장 가능한 서버리스 이벤트 중심 애플리케이션)(API304)](https://youtu.be/2rikdPIFc_Q) # REL04-BP03 일정한 작업 수행 대규모 로드가 급속도로 변경되면 시스템에서 장애가 발생할 수 있습니다. 예를 들어 서버 수천 대의 상태를 모니터링하는 상태 확인을 수행하는 워크로드의 경우 매번 동일한 크기의 페이로드(현재 상태의 전체 스냅샷)를 전송해야 합니다. 장애가 전혀 발생하지 않는 경우나, 또는 모든 서버에서 발생하는 경우와 무관하게 상태 확인 시스템은 대규모의 급속한 변경 없이 일정한 작업을 처리합니다. 예를 들어 상태 확인 시스템이 100,000개의 서버를 모니터링하는 경우 서버 장애율이 정상적으로 낮을 때는 서버에 가해지는 로드가 작습니다. 그러나 중대한 이벤트로 인해 이러한 서버의 절반이 비정상 상태가 될 때 상태 확인 시스템에서 알림 시스템을 업데이트하고 클라이언트로 상태를 전달하려면 상태 확인 시스템이 과부하가 될 수 있습니다. 그렇기 때문에 상태 확인 시스템에서는 매번 현재 상태의 전체 스냅샷을 전송하는 것이 낫습니다. 100,000개의 서버 상태(각각 비트로 표시됨)는 12.5KB 페이로드에 불과합니다. 장애가 발생한 서버가 없든 모든 서버에서 장애가 발생하든 상태 확인 시스템은 일정한 작업을 처리하므로 대규모의 급속한 변경이 시스템 안정성에 위협이 되지 않습니다. 이 방법으로 Amazon Route 53이 엔드포인트(예: IP 주소)에 대한 상태 확인을 수행하여 최종 사용자가 어떻게 엔드포인트에 라우팅되는지 판단합니다. **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 낮음 ## 구현 가이드 + 로드에 대규모의 급격한 변화가 있을 때 시스템에서 장애가 발생하지 않도록 일정하게 작업을 수행합니다. + 느슨한 결합 종속성을 구현합니다. 대기열 처리 시스템, 스트리밍 시스템, 워크플로 및 로드 밸런서와 같은 종속성은 약결합됩니다. 느슨한 결합은 한 구성 요소의 동작을 다른 종속 구성 요소에서 분리하여 복원력 및 민첩성을 높이는 데 도움이 됩니다. + [Amazon Builders' Library: (안정성, 지속적인 작업 및 맛 좋은 한 잔의 커피)](https://aws.amazon.com/builders-library/reliability-and-constant-work/) + [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small(루프 닫기 및 마음 열기: 규모에 상관없이 시스템을 제어하는 방법) ARC337(일정한 작업 포함) ](https://youtu.be/O8xLxNje30M?t=2482) + 10만 개의 서버를 모니터링하는 상태 확인 시스템의 예에서 성공 또는 실패 횟수와 관계없이 페이로드 크기가 일정하게 유지되도록 워크로드를 엔지니어링합니다. ## 리소스 **관련 문서:** + [Amazon EC2: Ensuring Idempotency(멱등성 보장)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) + [Amazon Builders' Library: 분산 시스템의 도전 과제](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) + [Amazon Builders' Library: (안정성, 지속적인 작업 및 맛 좋은 한 잔의 커피)](https://aws.amazon.com/builders-library/reliability-and-constant-work/) **관련 동영상:** + [AWS New York Summit 2019: Intro to Event-driven Architectures(이벤트 중심 아카텍처 및 Amazon EventBridge 소개) 및 Amazon EventBridge(MAD205)](https://youtu.be/tvELVa9D9qU) + [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small(루프 닫기 및 마음 열기: 규모에 상관없이 시스템을 제어하는 방법) ARC337(일정한 작업 포함) ](https://youtu.be/O8xLxNje30M?t=2482) + [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small(루프 닫기 및 마음 열기: 규모에 상관없이 시스템을 제어하는 방법) ARC337(느슨한 결합, 일정한 작업, 정적 안정성 포함)](https://youtu.be/O8xLxNje30M) + [AWS re:Invent 2019: Moving to event-driven architectures(이벤트 중심 아키텍처로 전환)(SVS308)](https://youtu.be/h46IquqjF3E) # REL04-BP04 모든 응답의 멱등성 유지 멱등성이 있는 서비스는 각 요청이 정확히 한 번만 완료되도록 합니다. 이렇게 하면 다수의 동일한 요청에서 단일 요청과 동일한 결과가 나옵니다. 멱등성이 있는 서비스를 사용하면 클라이언트가 요청이 오류로 여러 번 처리될 것이라는 염려 없이 재시도를 시행할 수 있습니다. 이를 위해 클라이언트는 멱등성 토큰을 사용하여 API 요청을 실행할 수 있으며 요청이 반복될 때마다 동일한 토큰이 사용됩니다. 멱등성이 있는 서비스 API는 토큰을 사용하여 요청이 처음 완료되었을 때 반환된 응답과 동일한 응답을 반환합니다. 분산 시스템에서 작업을 최대 한 번(클라이언트가 한 번만 요청) 또는 최소 한 번(클라이언트가 성공 확인을 수신할 때까지 계속 요청) 수행하기는 쉽습니다. 그러나 작업의 멱등성을 보장하기는 어렵습니다. 즉 작업을 *정확히* 한 번 수행하여 다수의 동일한 요청에서 단일 요청과 동일한 결과를 얻기는 어렵습니다. API에서 멱등성 토큰을 사용하면 서비스가 중복 레코드를 생성하지 않고 부작용 없이 변경 요청을 한 번 이상 수신할 수 있습니다. **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 ## 구현 가이드 + 모든 응답의 멱등성을 유지합니다. 멱등성이 있는 서비스는 각 요청이 정확히 한 번만 완료되도록 합니다. 이렇게 하면 다수의 동일한 요청에서 단일 요청과 동일한 결과가 나옵니다. + 클라이언트는 멱등성 토큰을 사용하여 API 요청을 실행할 수 있으며 요청이 반복될 때마다 동일한 토큰이 사용됩니다. 멱등성이 있는 서비스 API는 토큰을 사용하여 요청이 처음 완료되었을 때 반환된 응답과 동일한 응답을 반환합니다. + [Amazon EC2: Ensuring Idempotency(멱등성 보장)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) ## 리소스 **관련 문서:** + [Amazon EC2: Ensuring Idempotency(멱등성 보장)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html) + [Amazon Builders' Library: 분산 시스템의 도전 과제](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) + [Amazon Builders' Library: Reliability, constant work, and a good cup of coffee(안정성, 지속적인 작업 및 맛 좋은 한 잔의 커피)](https://aws.amazon.com/builders-library/reliability-and-constant-work/) **관련 동영상:** + [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge(이벤트 중심 아카텍처 및 Amazon EventBridge 소개)(MAD205)](https://youtu.be/tvELVa9D9qU) + [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small(루프 닫기 및 마음 열기: 규모에 상관없이 시스템을 제어하는 방법) ARC337(느슨한 결합, 일정한 작업, 정적 안정성 포함)](https://youtu.be/O8xLxNje30M) + [AWS re:Invent 2019: Moving to event-driven architectures(이벤트 중심 아키텍처로 전환)(SVS308)](https://youtu.be/h46IquqjF3E)