REL01-BP03 아키텍처를 통해 고정된 서비스 할당량 및 제약 조건 수용

변경할 수 없는 서비스 할당량, 서비스 제약 조건 및 물리적 리소스 한도를 알고 있어야 합니다. 이러한 한도가 신뢰성에 영향을 미치지 않도록 애플리케이션 및 서비스의 아키텍처를 설계합니다.

네트워크 대역폭, 서버리스 기능 간접 호출 페이로드 크기, API 게이트웨이의 제한 버스트 속도 및 데이터베이스에 대한 동시 사용자 연결 등이 여기에 포함됩니다.

원하는 성과: 애플리케이션 또는 서비스가 정상 조건 및 트래픽이 많은 조건에서 예상대로 수행됩니다. 해당 리소스의 고정 제약 조건 또는 서비스 할당량의 한계 내에서 작동하도록 설계되었습니다.

일반적인 안티 패턴:

• 확장 시 해당 설계에서 장애를 유발하는 설계 제약 조건이 있다는 사실을 인지하지 못한 채 하나의 서비스 리소스를 사용하는 설계 방식을 선택합니다.

• 비현실적이며 테스트 중에 고정된 서비스 할당량에 도달하는 벤치마킹을 수행합니다. 예를 들어, 버스트 한도에서 테스트를 실행하면서, 오랜 시간 실행합니다.

• 고정된 서비스 할당량을 초과하는 경우 확장할 수 없거나 수정할 수 없는 설계를 선택합니다. 예를 들어, SQS 페이로드 크기는 256KB입니다.

• 높은 트래픽 이벤트 동안 위험에 처할 수 있는 서비스 할당량의 임곗값을 모니터링하고 경고하도록 관찰성이 설계 및 구현되지 않았습니다.

이 모범 사례 확립의 이점: 애플리케이션이 중단이나 성능 저하 없이 예상되는 모든 서비스 부하 수준에서 실행되는지 확인합니다.

이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준: 중간

구현 가이드

더 큰 용량 단위로 대체되는 소프트 서비스 할당량 또는 리소스와 달리 AWS 서비스의 고정 할당량은 변경할 수 없습니다. 따라서 이러한 모든 유형의 AWS 서비스는 애플리케이션 설계에 사용될 때 잠재적인 하드 용량 한도에 대해 평가되어야 합니다.

하드 한도는 Service Quotas 콘솔에 표시됩니다. 열에 ADJUSTABLE = No가 표시된 경우 서비스에 하드 한도가 있는 것입니다. 하드 한도는 일부 리소스 구성 페이지에도 표시됩니다. 예를 들어 Lambda에는 조정할 수 없는 특정 하드 한도가 있습니다.

예를 들어 Python 애플리케이션을 Lambda 함수에서 실행하도록 설계할 때 Lambda가 15분 이상 실행될 가능성이 있는지 확인하기 위해 애플리케이션을 평가해야 합니다. 코드가 이 서비스 할당량 한도보다 더 오래 실행될 수 있는 경우 대체 기술 또는 설계를 고려해야 합니다. 프로덕션 배포 후 이 한도에 도달하면 애플리케이션은 문제를 해결할 수 있을 때까지 성능 저하 및 중단이 발생합니다. 소프트 할당량과 달리 긴급 심각도 1 이벤트에서도 이러한 한도를 변경할 수 있는 방법이 없습니다.

애플리케이션이 테스트 환경에 배포되면 하드 한도에 도달할 수 있는지 확인하기 위한 전략을 사용해야 합니다. 스트레스 테스트, 부하 테스트 및 카오스 테스트는 도입 테스트 계획의 일부여야 합니다.

구현 단계

• 애플리케이션 설계 단계에서 사용할 수 있는 AWS 서비스의 전체 목록을 검토합니다.

• 이러한 모든 서비스에 대한 소프트 할당량 한도 및 하드 할당량 한도를 검토합니다. 모든 한도가 Service Quotas 콘솔에 표시되는 것은 아닙니다. 일부 서비스에서는 대체 위치에서 이러한 제한을 설명합니다.

• 애플리케이션을 설계할 때 비즈니스 결과, 사용 사례, 종속 시스템, 가용성 목표 및 재해 복구 개체와 같은 워크로드의 비즈니스 및 기술 동인을 검토합니다. 비즈니스 및 기술 동인이 워크로드에 적합한 분산 시스템을 식별하는 프로세스를 안내하도록 합니다.

• 리전 및 계정 전체에서 서비스 부하를 분석합니다. 서비스의 많은 하드 한도가 리전을 기반으로 합니다. 그러나 일부 한도는 계정을 기반으로 합니다.

• 영역 장애 및 리전 장애 시 리소스 사용량에 대한 복원력 아키텍처를 분석합니다. 액티브/액티브, 액티브/패시브 - 핫, 액티브/패시브 - 콜드 및 액티브/패시브 - 파일럿 라이트 접근 방식을 사용하는 다중 리전 설계의 진행에서 이러한 실패 사례는 더 높은 사용량을 야기할 것입니다. 이는 하드 한도에 도달할 수 있는 잠재적 사용 사례를 생성합니다.

리소스

관련 모범 사례:

• REL01-BP01 서비스 할당량 및 제약 조건 인식

• REL01-BP02 계정 및 리전 전체에서 서비스 할당량 관리

• REL01-BP04 할당량 모니터링 및 관리

• REL01-BP05 할당량 관리 자동화

• REL01-BP06 현재의 할당량과 최대 사용량 간에 장애 조치를 수용할 만큼 여유가 충분히 있는지 확인

• REL03-BP01 워크로드를 세그먼트화하는 방법 선택

• REL10-BP01 워크로드를 여러 위치에 배포

• REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지

• REL11-BP03 모든 계층에서 복구 자동화

• REL12-BP04 카오스 엔지니어링을 이용한 복원력 테스트

관련 문서:

• AWS Well-Architected Framework 신뢰성 원칙: 가용성

• AWS Service Quotas(이전의 서비스 한도)

• AWS Trusted Advisor Best Practice Checks (see the Service Limits section)

• AWS Limit Monitor on AWS 질문

• Amazon EC2 서비스 한도

• What is Service Quotas?

• How to Request Quota Increase

• Service endpoints and quotas

• Service Quotas 사용 설명서

• Quota Monitor for AWS

• AWS Fault Isolation Boundaries

• Availability with redundancy

• AWS for Data

• 지속적 통합이란 무엇입니까?

• 지속적 전달이란 무엇입니까?

• APN 파트너: 구성 관리를 지원할 수 있는 파트너

• Managing the account lifecycle in account-per-tenant SaaS environments on AWS

• Managing and monitoring API throttling in your workloads

• View AWS Trusted Advisor recommendations at scale with AWS Organizations

• Automating Service Limit Increases and Enterprise Support with AWS Control Tower

• Actions, resources, and condition keys for Service Quotas

관련 비디오:

• AWS Live re:Inforce 2019 - Service Quotas

• View and Manage Quotas for AWS Services Using Service Quotas

• AWS IAM Quotas Demo

• AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small

관련 도구:

• AWS CodeDeploy

• AWS CloudTrail

• Amazon CloudWatch

• Amazon EventBridge

• Amazon DevOps Guru

• AWS Config

• AWS Trusted Advisor

• AWS CDK

• AWS Systems Manager

• AWS Marketplace