# REL 5 분산 시스템에서 장애 완화 또는 극복을 위한 상호 작용은 어떻게 설계합니까?
분산 시스템에서 구성 요소(예: 서버 또는 서비스)는 통신 네트워크를 사용하여 상호 연결됩니다. 워크로드는 이러한 네트워크에서 데이터 손실 또는 지연 시간이 발생하더라도 안정적으로 작동해야 합니다. 분산 시스템의 구성 요소는 다른 구성 요소나 워크로드에 부정적인 영향을 미치지 않는 방식으로 작동해야 합니다. 이러한 모범 사례를 준수하면 워크로드가 스트레스 또는 장애를 견디고, 더 빠르게 이를 복구하며, 이러한 장애의 영향을 완화할 수 있습니다. 그러면 결과적으로 MTTR(평균 복구 시간)이 개선됩니다.
**Topics**
+ [REL05-BP01 관련 하드 종속성을 소프트 종속성으로 변환하는 정상적인 성능 저하 구현](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 요청 제한](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 재시도 호출 제어 및 제한](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 빠른 실패 및 대기열 제한](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 클라이언트 시간 제한 설정](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 가능한 경우 서비스를 스테이트리스로 설계](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 비상 레버 구현](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 관련 하드 종속성을 소프트 종속성으로 변환하는 정상적인 성능 저하 구현
구성 요소의 종속성이 비정상 상태인 경우에도 구성 요소 자체가 성능이 저하된 방식으로 작동할 수 있습니다. 예를 들어 종속성 호출이 실패하면 미리 결정된 정적 응답으로 장애 조치됩니다.
서비스 A가 서비스 B를 호출하고 서비스 B는 서비스 C를 호출하는 경우
![\[서비스 B가 서비스 C를 호출할 때 서비스 C가 실패하는 것을 보여주는 다이어그램. 서비스 B는 성능이 저하된 응답을 서비스 A에 반환함\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/graceful-degradation.png)
서비스 B가 서비스 C를 호출할 때 서비스 B는 서비스 C로부터 오류 또는 시간 초과를 수신합니다. 서비스 B는 서비스 C(및 여기에 포함된 데이터)의 응답이 없는 대신 가능한 것을 반환합니다. 이 값은 마지막으로 캐시된 정상 값이 될 수 있습니다. 또는 서비스 B는 서비스 C에서 수신했을 수 있는 것에 대해 미리 결정된 정적 응답을 대체할 수 있습니다. 그런 다음 호출자인 서비스 A에 성능이 저하된 응답을 반환할 수 있습니다. 이 정적 응답이 없다면 서비스 C의 장애가 서비스 B를 통해 서비스 A로 계단식으로 전달되어 가용성이 손실됩니다.
강한 종속성에 대한 가용성 방정식의 승인자( [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122)참조)에 따라 C의 가용성 손실은 B의 유효 가용성에 심각한 영향을 미칩니다. 서비스 B는 정적 응답을 반환함으로써 C의 장애를 완화하고 성능이 저하되기는 하지만 서비스 C의 가용성을 100%처럼 보이게 만듭니다(오류 조건에서 정적 응답을 성공적으로 반환한다는 가정하에). 정적 응답은 오류를 반환하는 것에 대한 단순한 대안이며 다른 수단을 사용하여 응답을 다시 계산하려는 시도가 아닙니다. 완전히 다른 메커니즘에서 동일한 결과를 얻기 위한 이러한 시도를 폴백 동작이라고 하는데 이는 피해야 할 안티패턴입니다.
단계적 성능 저하의 또 다른 예는 *회로 차단기 패턴입니다.*. 장애가 일시적인 경우에는 재시도 전략을 사용해야 합니다. 일시적이지 않고 작업이 실패할 가능성이 있는 경우 회로 차단기 패턴은 실패할 가능성이 있는 요청을 수행하지 못하도록 클라이언트를 차단합니다. 요청이 정상적으로 처리될 때는 회로 차단기가 닫히고 요청이 전송됩니다. 원격 시스템에서 오류를 반환하기 시작하거나 지연 시간이 길어지면 회로 차단기가 열리고 종속성이 무시되거나 덜 포괄적이지만 간단하게 얻을 수 있는 응답(단순한 응답 캐시일 수 있음)으로 결과가 대체됩니다. 시스템은 주기적으로 종속성 호출을 시도해 복구 여부를 확인합니다. 종속성이 복구된 경우에는 회로 차단기가 닫힙니다.
![\[회로 차단기가 열리고 닫힌 상태를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/circuit-breaker.png)
다이어그램에 표시된 닫힌 상태와 열린 상태 외에, 열린 상태에서 구성 가능한 기간이 지나면 회로 차단기가 반개방 상태로 전환될 수 있습니다. 이 상태에서는 평소보다 훨씬 낮은 속도로 주기적으로 서비스 호출이 시도됩니다. 이 탐색기는 서비스의 상태를 확인하는 데 사용됩니다. 반개방 상태에서 여러 번 성공하면 회로 차단기가 닫힌 상태로 전환되고 정상 요청이 재개됩니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 관련 하드 종속성을 소프트 종속성으로 변환하는 정상적인 성능 저하를 구현합니다. 구성 요소의 종속성이 비정상 상태인 경우에도 구성 요소 자체가 성능이 저하된 방식으로 작동할 수 있습니다. 예를 들어 종속성 호출이 실패하면 미리 결정된 정적 응답으로 장애 조치됩니다.
+ 정적 응답을 반환함으로써 워크로드는 종속성에서 발생하는 장애를 완화합니다.
+ [Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability(Well-Architected 실습: 레벨 300: 상태 확인 구현 및 종속성 관리를 통한 안정성 개선)](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
+ 재시도 작업이 실패할 가능성이 있는 경우 이를 감지하고 회로 차단기 패턴을 이용해 클라이언트가 실패한 호출을 실행하지 못하도록 합니다.
+ [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html)
## 리소스
**관련 문서:**
+ [Amazon API Gateway: 처리량 향상을 위해 API 요청 제한](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker('Release It\$1' 도서의 회로 차단기 요약)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [AWS의 오류 재시도 및 지수 백오프](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard 'Release It\$1 Design and Deploy Production-Ready Software(Release It\$1 프로덕션 지원 소프트웨어 설계 및 배포)'](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [Amazon Builders' Library: 분산 시스템의 폴백 방지](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: 심각한 수준의 대기열 백로그 방지](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: 캐싱 관련 당면 과제 및 전략](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Amazon Builders' Library: 시간 제한, 재시도 및 지터를 사용한 백오프](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**관련 동영상:**
+ [재시도, 백오프 및 지터: AWS re:Invent 2019: Introducing The Amazon Builders’ Library(Amazon Builders’ Library 소개)(DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**관련 예시:**
+ [Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability(Well-Architected 실습: 레벨 300: 상태 확인 구현 및 종속성 관리를 통한 안정성 개선)](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL05-BP02 요청 제한
요청 제한은 예기치 않은 수요 증가에 대응하기 위한 완화 패턴입니다. 일부 요청은 처리되지만 정의된 제한을 초과하는 요청은 거부되고 병목 현상이 발생했음을 나타내는 메시지를 반환합니다. 클라이언트는 요청을 다시 중단하고 중단하거나 더 느린 속도로 다시 시도할 것이라는 기대입니다.
각 노드나 셀이 처리할 수 있는 확인된 요청 용량을 처리하도록 서비스를 설계해야 합니다. 이 용량은 로드 테스트를 통해 설정할 수 있습니다. 그런 다음 요청 도착 속도를 추적해야 하며, 임시 도착 속도가 이 한도를 초과하는 경우의 적절한 대응 방식은 요청이 쓰로틀링되었음을 알리는 것입니다. 그러면 사용자는 사용 가능 용량이 있을 수 있는 다른 노드 또는 셀에 대해 요청을 다시 시도할 수 있습니다. Amazon API Gateway는 요청을 제한할 수 있는 방법을 제공합니다. Amazon SQS와 Amazon Kinesis는 요청을 버퍼링하고 요청 속도를 원활하게 하고 비동기식으로 처리할 수 있는 요청에 대한 조절 필요성을 완화할 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 요청을 제한합니다. 예기치 않은 수요 증가에 대응하기 위한 완화 패턴입니다. 일부 요청은 처리되지만 정의된 제한을 초과하는 요청은 거부되고 병목 현상이 발생했음을 나타내는 메시지를 반환합니다. 클라이언트는 요청을 다시 중단하고 중단하거나 더 느린 속도로 다시 시도할 것이라는 기대입니다.
+ Amazon API Gateway 사용
+ [처리량 향상을 위해 API 요청 조절](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
## 리소스
**관련 문서:**
+ [Amazon API Gateway: 처리량 향상을 위해 API 요청 제한](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS의 오류 재시도 및 지수 백오프](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders' Library: 분산 시스템의 폴백 방지](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: 심각한 수준의 대기열 백로그 방지](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: 시간 제한, 재시도 및 지터를 사용한 백오프](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [처리량 향상을 위해 API 요청 조절](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
**관련 동영상:**
+ [재시도, 백오프 및 지터: AWS re:Invent 2019: Introducing The Amazon Builders’ Library(Amazon Builders’ Library 소개)(DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP03 재시도 호출 제어 및 제한
지수 백오프를 사용하여 점진적으로 더 긴 간격 후에 다시 시도합니다. 지터를 도입하여 이러한 재시도 간격을 무작위로 지정하고 최대 재시도 횟수를 제한합니다.
분산 소프트웨어 시스템의 일반적인 구성 요소로는 서버, 로드 밸런서, 데이터베이스 및 DNS 서버가 있습니다. 작동 중일 때 장애가 발생하면 이러한 구성 요소 중 모든 구성 요소에서 오류가 생성되기 시작할 수 있습니다. 오류를 처리하는 기본 기술은 클라이언트 측에 재시도를 구현하는 것입니다. 이 기술은 애플리케이션의 안정성과 가용성을 높입니다. 그러나 오류가 발생하는 즉시 클라이언트가 실패한 작업을 대규모로 다시 시도할 경우 새 요청 및 만료된 요청이 각각 네트워크 대역폭을 두고 경합하여 네트워크가 빠르게 포화 상태가 될 수 있습니다. 이로 인해 *재시도 폭풍* 이 발생하고 서비스 가용성이 떨어집니다. 이 패턴은 전체 시스템 장애가 발생할 때까지 계속될 수 있습니다.
이러한 상황을 방지하려면 일반적인 *지수 백오프* )을 사용해야 합니다. 지수 백오프 알고리즘은 재시도가 수행되는 속도를 점진적으로 줄여 네트워크 정체를 방지합니다.
AWS의 SDK를 비롯한 많은 SDK 및 소프트웨어 라이브러리가 이러한 알고리즘 버전을 구현합니다. 하지만 **백오프 알고리즘이 존재한다고 가정하지 말고 항상 이를 테스트하고 확인하십시오.**
단순한 백오프만으로는 충분하지 않습니다. 분산 시스템에서는 모든 클라이언트가 동시에 백오프되어 재시도 호출의 클러스터가 생성될 수 있기 때문입니다. Marc Brooker의 블로그 게시물 [Exponential Backoff and Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/)에는 지수 백오프에서 wait() 함수를 수정하여 재시도 호출 클러스터를 방지하는 방법이 설명되어 있습니다. 해결 방법은 *지터* 를 wait() 함수에 추가하는 것입니다. 장시간의 재시도를 방지하려면 구현 시 백오프를 최대값으로 제한해야 합니다.
마지막으로, *최대 재시도 횟수* 또는 재시도를 실패로 처리할 경과 시간을 구성하는 것이 중요합니다. AWS SDK는 이 기능을 기본적으로 구현하며 이 기능은 구성이 가능합니다. 스택에서 아래에 있는 서비스의 경우 최대 재시도 제한이 0 또는 1이면 위험이 제한될 수 있지만, 재시도가 스택에서 더 위에 있는 서비스로 위임되므로 여전히 유효합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 재시도 호출을 제어 및 제한합니다. 지수 백오프를 사용하여 점진적으로 더 긴 간격 후에 다시 시도합니다. 지터를 도입하여 이러한 재시도 간격을 무작위로 지정하고 최대 재시도 횟수를 제한합니다.
+ [AWS의 오류 재시도 및 지수 백오프](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ Amazon SDK는 기본적으로 재시도와 지수 백오프를 구현합니다. 자체 종속 서비스를 호출할 때 종속성 계층에 비슷한 로직을 구현합니다. 사용 사례를 기반으로 시간 초과 대상 및 재시도 중단 시점을 결정합니다.
## 리소스
**관련 문서:**
+ [Amazon API Gateway: 처리량 향상을 위해 API 요청 제한](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS의 오류 재시도 및 지수 백오프](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders' Library: 분산 시스템의 폴백 방지](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: 심각한 수준의 대기열 백로그 방지](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: 캐싱 관련 당면 과제 및 전략](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Amazon Builders' Library: 시간 제한, 재시도 및 지터를 사용한 백오프](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**관련 동영상:**
+ [재시도, 백오프 및 지터: AWS re:Invent 2019: Introducing The Amazon Builders’ Library(Amazon Builders’ Library 소개)(DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP04 빠른 실패 및 대기열 제한
워크로드가 요청에 성공적으로 응답할 수 없는 경우 빠르게 실패합니다. 이렇게 하면 요청에 연결된 리소스를 해제할 수 있고 리소스가 부족한 경우 서비스 복구를 허용할 수 있습니다. 워크로드가 성공적으로 응답할 수 있지만 요청 속도가 너무 높은 경우에는 대기열을 사용하여 요청을 버퍼링합니다. 하지만 긴 대기열을 허용하지 마십시오. 대기열이 길면 클라이언트가 이미 포기한 무효 요청을 처리할 수 있습니다.
이 모범 사례는 요청의 서버 측 또는 수신자에 적용됩니다.
대기열은 시스템의 여러 수준에서 생성될 수 있습니다. 대기열에서는 최근 요청보다 더 이상 응답이 필요하지 않은 오래된 무효 요청이 먼저 처리되므로 빠른 복구 기능에 심각한 영향을 미칠 수 있습니다. 그러므로 대기열이 있는 위치를 숙지해야 합니다. 일반적으로 대기열은 워크플로 또는 데이터베이스에 기록된 작업에 숨겨집니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 빠르게 실패하고 대기열을 제한합니다. 워크로드가 요청에 성공적으로 응답할 수 없는 경우 빠르게 실패합니다. 이렇게 하면 요청에 연결된 리소스를 해제할 수 있고 리소스가 부족한 경우 서비스 복구를 허용할 수 있습니다. 워크로드가 성공적으로 응답할 수 있지만 요청 속도가 너무 높은 경우에는 대기열을 사용하여 요청을 버퍼링합니다. 하지만 긴 대기열을 허용하지 마십시오. 대기열이 길면 클라이언트가 이미 포기한 무효 요청을 처리할 수 있습니다.
+ 서비스가 부담을 받고 있는 상황에서 빠른 실패를 구현합니다.
+ [Fail Fast(빠른 실패)](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ 대기열을 제한합니다. 대기열 기반 시스템에서는 처리가 중지되었는데도 메시지가 계속 수신될 경우 처리되지 않은 메시지가 대용량 백로그에 누적되어 처리 시간이 늘어날 수 있습니다. 작업이 너무 늦게 완료되어 결과가 소용 없게 되고, 결국 대기열을 통해 방지되었어야 할 가용성 히트가 발생할 수 있습니다.
+ [Amazon Builders' Library: 심각한 수준의 대기열 백로그 방지](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
## 리소스
**관련 문서:**
+ [AWS에서의 오류 재시도 및 지수 백오프](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Fail Fast(빠른 실패)](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [Amazon Builders' Library: 분산 시스템의 폴백 방지](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: 심각한 수준의 대기열 백로그 방지](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: 캐싱 관련 당면 과제 및 전략](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Amazon Builders' Library: 시간 제한, 재시도 및 지터를 사용한 백오프](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**관련 동영상:**
+ [재시도, 백오프 및 지터: AWS re:Invent 2019: Amazon Builders’ Library 소개(DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP05 클라이언트 시간 제한 설정
시간 제한을 적절히 설정하고, 체계적으로 확인합니다. 기본값을 사용해서는 안 됩니다. 기본값은 일반적으로 너무 높게 설정됩니다.
이 모범 사례는 요청의 클라이언트 측 또는 발신자에 적용됩니다.
원격 호출과 일반적으로 프로세스 전체의 모든 호출에 연결 시간 제한과 요청 시간 제한을 모두 설정합니다. 기본적인 시간 제한 기능을 제공하는 프레임워크가 많지만 기본값이 무한하거나 너무 높은 경우가 많으므로 주의해야 합니다. 값이 너무 높으면 클라이언트가 시간 제한이 발생할 때까지 대기하는 동안 리소스가 계속 소비되기 때문에 시간 제한의 유용성이 감소합니다. 값이 너무 낮으면 백엔드에서 트래픽이 증가하고 너무 많은 요청이 재시도되므로 지연 시간이 증가할 수 있습니다. 일부 경우에는 모든 요청이 재시도되기 때문에 이로 인해 전체 중단이 발생할 수 있습니다.
Amazon에서 시간 제한, 재시도 및 지터를 사용한 백오프를 사용하는 방법에 대한 자세한 내용은 다음을 참조하십시오. [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card).
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 원격 호출과 일반적으로 프로세스 전체의 모든 호출에 연결 시간 제한과 요청 시간 제한을 모두 설정합니다. 기본적인 시간 제한 기능을 제공하는 프레임워크가 많지만 기본값이 무한하거나 너무 높은 경우가 많으므로 주의해야 합니다. 값이 너무 높으면 클라이언트가 시간 제한이 발생할 때까지 대기하는 동안 리소스가 계속 소비되기 때문에 시간 제한의 유용성이 감소합니다. 값이 너무 낮으면 백엔드에서 트래픽이 증가하고 너무 많은 요청이 재시도되므로 지연 시간이 증가할 수 있습니다. 일부 경우에는 모든 요청이 재시도되기 때문에 이로 인해 전체 중단이 발생할 수 있습니다.
+ [AWS SDK: 재시도 및 시간 제한](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
## 리소스
**관련 문서:**
+ [AWS SDK: 재시도 및 시간 제한](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon API Gateway: 처리량 향상을 위해 API 요청 제한](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS에서의 오류 재시도 및 지수 백오프](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders' Library: 시간 제한, 재시도 및 지터를 사용한 백오프](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**관련 동영상:**
+ [재시도, 백오프 및 지터: AWS re:Invent 2019: Amazon Builders’ Library 소개(DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP06 가능한 경우 서비스를 스테이트리스로 설계
서비스는 상태를 필요로 하지 않거나 디스크 및 메모리의 로컬로 저장된 데이터에 종속성이 없도록 서로 다른 클라이언트 요청 간에 상태를 오프로드해야 합니다. 이를 통해 가용성에 영향을 주지 않고 서버를 원하는 방식으로 교체할 수 있습니다. Amazon ElastiCache 또는 Amazon DynamoDB는 오프로드된 상태에 적합한 대상입니다.
![\[이 스테이스리스 웹 애플리케이션에서는 세션 상태가 Amazon ElastiCache로 오프로드됩니다.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/stateless-webapp.png)
사용자 또는 서비스는 애플리케이션과 상호 작용할 때 세션을 구성하는 일련의 상호 작용을 수행하는 경우가 많습니다. 세션은 애플리케이션을 사용하는 동안 요청 간에 유지되는 사용자의 고유한 데이터입니다. 상태 비저장 애플리케이션은 이전 상호 작용에 대한 지식을 필요로 하지 않으며 세션 정보를 저장하지 않는 애플리케이션입니다.
스테이스리스로 설계된 경우 AWS Lambda 또는 AWS Fargate와 같은 서버리스 컴퓨팅 서비스를 사용할 수 있습니다.
서버 대체 외에 상태 비저장 애플리케이션의 또 다른 이점은 사용 가능한 컴퓨팅 리소스(예: EC2 인스턴스 및 AWS Lambda 함수)로 모든 요청을 처리할 수 있기 때문에 수평적으로 확장할 수 있다는 것입니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 애플리케이션을 스테이스리스로 생성합니다. 무상태 애플리케이션은 수평 확장을 가능하게 하며, 개별 노드의 장애에 대한 내결함성이 있습니다.
+ 요청 파라미터에 실제로 저장될 수 있는 상태를 제거합니다.
+ 상태가 필요한지 여부를 조사한 후 상태 추적을 Amazon ElastiCache, Amazon RDS, Amazon DynamoDB 또는 서드 파티 분산 데이터 솔루션과 같은 복원성이 있는 다중 영역 캐시 데이터 스토어로 옮깁니다. 복원성이 있는 데이터 스토어로 옮길 수 없는 상태를 저장합니다.
+ 일부 데이터(쿠키 등)는 헤더 또는 쿼리 파라미터로 전달될 수 있습니다.
+ 리팩터링을 통해 요청에 빠르게 전달될 수 있는 상태를 제거합니다.
+ 일부 데이터는 요청별로 필요하지 않으며 요청에 따라 검색 시 검색될 수 있습니다.
+ 비동기식으로 검색할 수 있는 데이터를 제거합니다.
+ 필수 상태 요구 사항을 충족하는 데이터 스토어를 결정합니다.
+ 비관계형 데이터를 위한 NoSQL 데이터베이스를 고려합니다.
## 리소스
**관련 문서:**
+ [Amazon Builders' Library: 분산 시스템의 폴백 방지](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: 심각한 수준의 대기열 백로그 방지](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: 캐싱 관련 당면 과제 및 전략](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
# REL05-BP07 비상 레버 구현
비상 레버는 워크로드의 가용성에 미치는 영향을 신속하게 완화할 수 있는 프로세스입니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 비상 레버를 구현합니다. 이 프로세스는 워크로드의 가용성에 미치는 영향을 신속하게 완화할 수 있는 프로세스입니다. 이 프로세스는 근본 원인이 없는 상태에서 작동할 수 있습니다. 이상적인 비상 레버는 완전히 결정적인 활성화 및 비활성화 기준을 제공하여 확인자에 대한 인지 부담을 0으로 줄여줍니다. 레버는 수동인 경우가 많지만 자동화할 수도 있습니다.
+ 예시 레버:
+ 모든 로봇 트래픽 차단
+ 동적 페이지 대신 정적 페이지 제공
+ 종속성으로의 호출 빈도 축소
+ 종속성으로부터의 호출 제한
+ 비상 레버 구현 및 사용을 위한 팁
+ 레버가 활성화되면 더 적은 수의 작업을 수행
+ 단순하게 유지하고 바이모달 동작을 방지
+ 레버를 정기적으로 테스트
+ 다음은 비상 레버가 아닌 작업의 예입니다.
+ 용량 추가
+ 서비스를 사용하는 클라이언트의 서비스 소유자를 호출하고 호출을 줄이도록 요청
+ 코드 변경 및 릴리스