# 워크로드 아키텍처
**Topics**
+ [REL 3 워크로드 서비스 아키텍처는 어떻게 설계합니까?](w2aac19b9b7b5.md)
+ [REL 4 분산 시스템에서 장애 방지를 위한 상호 작용은 어떻게 설계합니까?](w2aac19b9b7b7.md)
+ [REL 5 분산 시스템에서 장애 완화 또는 극복을 위한 상호 작용은 어떻게 설계합니까?](w2aac19b9b7b9.md)
# REL 3 워크로드 서비스 아키텍처는 어떻게 설계합니까?
SOA(서비스 지향 아키텍처) 또는 마이크로서비스 아키텍처를 사용하여 확장성과 안정성이 뛰어난 워크로드를 구축합니다. SOA(서비스 지향 아키텍처)는 서비스 인터페이스를 통해 소프트웨어 구성 요소를 재사용 가능하게 만드는 방식입니다. 마이크로서비스 아키텍처는 구성 요소를 더 작고 간단하게 만듭니다.
**Topics**
+ [REL03-BP01 워크로드를 세그먼트화하는 방법 선택](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 특정 비즈니스 도메인 및 기능을 중심으로 서비스 구축](rel_service_architecture_business_domains.md)
+ [REL03-BP03 API별로 서비스 계약 제공](rel_service_architecture_api_contracts.md)
# REL03-BP01 워크로드를 세그먼트화하는 방법 선택
워크로드 세그먼트화는 애플리케이션의 복원력 요구 사항을 결정할 때 중요합니다. 되도록 모놀리식 아키텍처는 피해야 합니다. 대신 어떤 애플리케이션 구성 요소를 마이크로 서비스로 나눌 수 있을지 신중하게 고려합니다. 가능한 경우 애플리케이션 요구 사항에 따라 서비스 지향 아키텍처(SOA)와 마이크로 서비스의 결합으로 마무리될 수도 있습니다. 상태 비저장일 수 있는 워크로드는 마이크로 서비스로 배포할 수 있습니다.
**원하는 결과:** 워크로드는 지원 가능하고 확장 가능하며 가능한 한 느슨하게 결합되어 있어야 합니다.
워크로드를 세그먼트화하는 방법을 선택할 때 복잡성 대비 이점의 균형을 고려합니다. 신제품의 첫 출시에 필요한 것과 처음부터 워크로드를 확장할 때 필요한 것은 다릅니다. 기존 모놀리식을 리팩터링할 때 애플리케이션이 상태 비저장을 향한 해체를 얼마나 잘 지원하는지 고려해야 합니다. 서비스를 더 작은 부분으로 나누면 잘 정의된 소규모 팀에서 이러한 부분을 개발하고 관리할 수 있습니다. 그러나 크기가 작은 서비스는 복잡성을 불러올 수 있고 여기에는 지연 시간 증가, 디버깅 복잡성, 운영 부담 증가가 포함됩니다.
**일반적인 안티 패턴:**
+ [마이크로서비스 *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) 는 원자성 구성 요소의 상호 의존성이 커져 한 구성 요소의 장애가 훨씬 더 큰 장애로 이어져 구성 요소가 모놀리식처럼 경직되고 취약해질 수 있습니다.
**이 모범 사례 정립의 이점:**
+ 보다 구체적인 세그먼트를 사용하면 민첩성, 조직의 유연성 및 확장성이 향상됩니다.
+ 서비스 중단의 영향이 감소합니다.
+ 애플리케이션 구성 요소가 원자성이 더 큰 세그먼트화로 지원할 수 있는 여러 가능성 요구 사항을 가질 수 있습니다.
+ 워크로드를 지원하는 팀의 책임이 잘 정의됩니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 가이드
워크로드를 분할하는 방법에 따라 아키텍처 유형 선택 SOA 또는 마이크로서비스 아키텍처(또는 드문 경우 모놀리식 아키텍처)를 선택합니다. 처음에 모놀리식 아키텍처를 선택하더라도, 사용자 채택에 따라 제품을 확장할 때 SOA 또는 마이크로서비스로 변경할 수 있는 모듈식 아키텍처인지 확인해야 합니다. SOA와 마이크로서비스는 더 작게 분할할 수 있기 때문에 현대의 확장 가능하고 안정적인 아키텍처로 선호되지만 특히 마이크로서비스 아키텍처를 배포하는 경우 절충을 고려해야 합니다.
한 가지 주요 절충은 분산 컴퓨팅 아키텍처가 구축되므로 사용자 지연 시간 요구 사항을 충족하기가 더 어려워지며, 사용자 상호 작용을 디버그하고 추적하는 과정이 더 복잡해진다는 것입니다. AWS X-Ray을(를) 사용하면 이 문제를 해결할 수 있습니다. 관리 중인 애플리케이션의 수가 증가함에 따라 운영 복잡성이 증가하므로 다수의 독립 구성 요소를 배포해야 한다는 점도 고려해야 합니다.
![\[모놀리식, 서비스 지향, 마이크로서비스 아키텍처 간 비교 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## 구현 단계
+ 애플리케이션을 리팩터링 또는 구축하기에 적절한 아키텍처를 결정합니다. SOA 및 마이크로서비스는 상태적으로 더 세분화된 조각화를 제공하며, 이는 확장 가능하고 안정적인 최신 아키텍처로서 선호됩니다. SOA는 마이크로서비스의 복잡성을 어느 정도 피하면서 더 세분화된 조각화를 실현하기에 좋은 절충안이 될 수 있습니다. 자세한 내용은 [Microservice Trade-Offs를 참조하세요](https://martinfowler.com/articles/microservice-trade-offs.html).
+ 이를 워크로드에 적용할 수 있고 조직에서 지원할 수 있는 경우, 마이크로서비스 아키텍처를 사용하여 최고의 민첩성과 안정성을 실현해야 합니다. 자세한 내용은 [AWS에서 마이크로서비스 구현을 참조하세요.](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ 모놀리식을 더 작은 구성 요소로 리팩터링하려면 [*스트랭글러 피그* 패턴](https://martinfowler.com/bliki/StranglerFigApplication.html) 을 따라 고려하세요. 여기에는 특정 애플리케이션을 새 애플리케이션 및 서비스로 점차적으로 교체하는 작업이 포함됩니다. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) 은(는) 점진적 리팩터링을 위한 시작점 역할을 합니다. 자세한 내용은 [스트랭글러 패턴을 사용하여 원활하게 온프레미스 레거시 워크로드 마이그레이션을 참조하세요](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ 마이크로 서비스를 구현하려면 분산된 서비스가 서로 통신하기 위한 서비스 검색 메커니즘이 필요할 수 있습니다. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) 을(를) 서비스 지향 아키텍처와 함께 사용하여 안정적인 서비스 검색 및 액세스를 제공할 수 있습니다. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) 은(는) 동적 DNS 기반 서비스 검색에도 사용할 수 있습니다.
+ 모놀리식에서 SOA로 마이그레이션하는 경우 [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) 은(는) 클라우드에서 레거시 애플리케이션을 다시 설계하는 경우 서비스 버스로 격차를 해소하는 데 도움이 될 수 있습니다.
+ 공유 데이터베이스 하나를 사용하는 기존 모놀리식의 경우 데이터를 더 작은 세그먼트로 재구성하는 방법을 선택합니다. 사업부, 액세스 패턴 또는 데이터 구조별로 선택할 수 있습니다. 리팩터링 프로세스 중 이 지점에서 데이터베이스의 관계형 또는 비관계형(NoSQL) 유형을 사용하여 진행할지 선택해야 합니다. 자세한 내용은 [SQL에서 NoSQL로를 참조하세요](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**구현 계획의 작업 수준:** 높음
## 리소스
**관련 모범 사례:**
+ [REL03-BP02 특정 비즈니스 도메인 및 기능을 중심으로 서비스 구축](rel_service_architecture_business_domains.md)
**관련 문서:**
+ [Amazon API Gateway: OpenAPI를 사용하여 REST API 구성](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [서비스 지향 아키텍처란 무엇인가요?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [경계 컨텍스트(도메인 주도 설계의 주요 패턴)](https://martinfowler.com/bliki/BoundedContext.html)
+ [AWS에서 마이크로서비스 구현](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Microservice Trade-Offs](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices - a definition of this new architectural term](https://www.martinfowler.com/articles/microservices.html)
+ [AWS 마이크로서비스](https://aws.amazon.com/microservices/)
+ [AWS App Mesh란 무엇인가요?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**관련 예시:**
+ [반복적 앱 데이터베이스 현대화 워크숍](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**관련 동영상:**
+ [Delivering Excellence with Microservices on AWS(AWS에서 마이크로서비스를 사용하여 우수성 제공)](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 특정 비즈니스 도메인 및 기능을 중심으로 서비스 구축
서비스 지향 아키텍처(SOA)는 비즈니스 요구 사항에 따라 명확하게 정의된 기능으로 서비스를 구축합니다. 마이크로서비스는 도메인 모델과 경계 컨텍스트를 사용하여 이를 추가로 제한함으로써 각 서비스가 한 가지 작업을 수행하도록 합니다. 특정 기능에 집중하면 다양한 서비스의 안정성 요구 사항을 구분하고 보다 구체적으로 투자의 대상을 지정할 수 있습니다. 또한 비즈니스 문제가 간단해지고 각 서비스에 소규모 팀이 연결되므로 조직의 확장이 수월해집니다.
마이크로서비스 아키텍처를 설계할 때는 DDD(Domain-Driven Design)에서 엔터티를 사용하여 비즈니스 문제를 모델링하는 것이 도움이 됩니다. 예를 들어 Amazon.com 웹 사이트에서 엔터티에는 패키지, 배송, 일정, 가격, 할인 및 통화가 포함될 수 있습니다. 이 모델은 [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html)를 사용하여 유사한 기능 및 속성을 공유하는 엔터티를 그룹화하는 더 작은 모델로 구분됩니다. 따라서 Amazon.com 예시 패키지에서 배송 및 일정은 배송 컨텍스트에 포함되지만 가격, 할인 및 통화는 요금 컨텍스트에 포함됩니다. 모델을 컨텍스트로 나누면 마이크로서비스의 경계를 지정하는 방법에 대한 템플릿을 사용할 수 있게 됩니다.
![\[마이크로서비스의 경계 지정 방법을 위한 모델 템플릿\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/building-services.png)
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 비즈니스 도메인과 해당 기능을 기준으로 워크로드를 설계합니다. 특정 기능에 집중하면 다양한 서비스의 안정성 요구 사항을 구분하고 보다 구체적으로 투자의 대상을 지정할 수 있습니다. 또한 비즈니스 문제가 간단해지고 각 서비스에 소규모 팀이 연결되므로 조직의 확장이 수월해집니다.
+ 도메인 분석을 수행하여 워크로드에 대한 DDD(도메인 중심 설계)를 매핑합니다. 그러면 워크로드의 요구 사항에 맞는 아키텍처 유형을 선택할 수 있습니다.
+ [모놀리식 유형을 마이크로서비스로 분할하는 방법](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [레거시 시스템으로 둘러싸여 있을 때 DDD 시작](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans ‘Domain-Driven Design: Tackling Complexity in the Heart of Software’](https://www.amazon.com/gp/product/0321125215)
+ [AWS에서 마이크로서비스 구현](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ 가능한 한 가장 작은 구성 요소로 서비스를 분해합니다. 마이크로서비스 아키텍처를 사용하면 워크로드를 최소 기능 단위의 구성 요소로 분리하여 조직을 확장하고 민첩성을 실현할 수 있습니다.
+ 워크로드 및 설계 목표, 한도 및 사용에 대한 기타 고려 사항과 관련하여 API를 정의합니다.
+ API 정의.
+ API 정의는 확장 및 추가 파라미터를 허용해야 합니다.
+ 설계된 가용성 정의.
+ API는 다양한 기능에 대해 여러 설계 목표를 가질 수 있습니다.
+ 한도 수립
+ 테스트를 사용하여 워크로드 기능의 한도를 정의합니다.
## 리소스
**관련 문서:**
+ [Amazon API Gateway: OpenAPI를 사용하여 REST API 구성](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [경계 컨텍스트(도메인 주도 설계의 주요 패턴)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans ‘Domain-Driven Design: Tackling Complexity in the Heart of Software’](https://www.amazon.com/gp/product/0321125215)
+ [레거시 시스템으로 둘러싸여 있을 때 DDD 시작](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [모놀리식 유형을 마이크로서비스로 분할하는 방법](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [AWS에서 마이크로서비스 구현](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Microservice Trade-Offs](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices - a definition of this new architectural term](https://www.martinfowler.com/articles/microservices.html)
+ [AWS 마이크로서비스](https://aws.amazon.com/microservices/)
# REL03-BP03 API별로 서비스 계약 제공
서비스 계약은 서비스 통합에 대한 팀 간의 문서화된 계약으로, 머신 판독 가능한 API 정의, 속도 제한 및 성능 기대치를 포함합니다. 버전 관리 전략을 사용하면 클라이언트에서 기존 API를 계속 사용하면서 준비가 될 때 애플리케이션을 최신 API로 마이그레이션할 수 있습니다. 계약을 위반하지 않는 한 언제든지 배포가 가능합니다. 서비스 공급자 팀은 원하는 기술 스택을 사용하여 API 계약을 충족할 수 있습니다. 마찬가지로 서비스 소비자는 자체 기술을 사용할 수 있습니다.
마이크로서비스는 서비스 지향 아키텍처(SOA) 개념을 적용하여 최소한의 기능 세트만 포함된 서비스를 생성합니다. 각 서비스는 API 및 설계 목표, 한도 및 서비스 사용을 위한 기타 고려 사항을 게시합니다. 이렇게 하면 호출 애플리케이션과의 *계약이* 성립됩니다. 이러한 방식에서 제공되는 세 가지 주요 이점은 다음과 같습니다.
+ 서비스에서 간단한 업무상의 문제만 처리하면 되며, 소규모 팀이 업무상의 문제를 소유할 수 있습니다. 그러므로 조직 크기를 더 효율적으로 조정할 수 있습니다.
+ 팀은 API 및 ‘계약’ 요구 사항을 충족하는 경우에 한해 언제든지 서비스를 배포할 수 있습니다.
+ 팀은 API 및 ‘계약’ 요구 사항을 충족하는 경우에 한해 원하는 모든 기술 스택을 사용할 수 있습니다.
Amazon API Gateway는 어떤 규모에서든 개발자가 API를 손쉽게 생성, 게시, 유지 관리, 모니터링 및 보안할 수 있게 해주는 완전관리형 서비스입니다. 트래픽 관리, 권한 부여 및 접근 제어, 모니터링 및 API 버전 관리를 비롯하여 최대 수십만 건의 동시 API 호출을 수락하고 처리하는 데 관련된 모든 작업을 처리합니다. 이전의 Swagger Specification인 OpenAPI Specification(OAS)을 사용하여 API 계약을 정의한 다음 이 정의를 API Gateway로 가져올 수 있습니다. 그런 다음 API Gateway를 사용하여 API를 버전 관리하고 배포할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ API당 서비스 계약 제공: 서비스 계약은 서비스 통합에 대한 팀 간의 문서화된 계약으로, 머신 판독 가능한 API 정의, 속도 제한 및 성능 기대치를 포함합니다.
+ [Amazon API Gateway: OpenAPI를 사용하여 REST API 구성](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ 버전 관리 전략을 사용하면 클라이언트에서 기존 API를 계속 사용하면서 준비가 될 때 애플리케이션을 최신 API로 마이그레이션할 수 있습니다.
+ Amazon API Gateway는 어떤 규모에서든 개발자가 API를 손쉽게 생성할 수 있게 해주는 완전관리형 서비스입니다. 이전의 Swagger Specification인 OpenAPI Specification(OAS)을 사용하여 API 계약을 정의한 다음 이 정의를 API Gateway로 가져올 수 있습니다. 그런 다음 API Gateway를 사용하여 API를 버전 관리하고 배포할 수 있습니다.
## 리소스
**관련 문서:**
+ [Amazon API Gateway: OpenAPI를 사용하여 REST API 구성](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [경계 컨텍스트(도메인 주도 설계의 주요 패턴)](https://martinfowler.com/bliki/BoundedContext.html)
+ [AWS에서 마이크로서비스 구현](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Microservice Trade-Offs](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices - a definition of this new architectural term](https://www.martinfowler.com/articles/microservices.html)
+ [AWS 마이크로서비스](https://aws.amazon.com/microservices/)
# 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)
# 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으로 줄여줍니다. 레버는 수동인 경우가 많지만 자동화할 수도 있습니다.
+ 예시 레버:
+ 모든 로봇 트래픽 차단
+ 동적 페이지 대신 정적 페이지 제공
+ 종속성으로의 호출 빈도 축소
+ 종속성으로부터의 호출 제한
+ 비상 레버 구현 및 사용을 위한 팁
+ 레버가 활성화되면 더 적은 수의 작업을 수행
+ 단순하게 유지하고 바이모달 동작을 방지
+ 레버를 정기적으로 테스트
+ 다음은 비상 레버가 아닌 작업의 예입니다.
+ 용량 추가
+ 서비스를 사용하는 클라이언트의 서비스 소유자를 호출하고 호출을 줄이도록 요청
+ 코드 변경 및 릴리스