AWS 서비스 한도 증가 요청 및 처리 모범 사례

AWS 서비스 할당량은 서비스를 과도한 사용으로부터 보호하지만, 최악의 순간에 확장 계획을 중단시킬 수도 있습니다. 팀이 출시나 트래픽 급증 전에 할당량을 확인하지 않으면, 애플리케이션 코드가 정상이더라도 스로틀링, 배포 실패 또는 용량 오류가 발생할 수 있습니다.

Service Quotas 콘솔, CloudWatch 및 명확한 비즈니스 사유를 사용하여 정기적인 용량 계획의 일부로 한도를 관리하세요.

AWS 서비스 할당량 이해하기

요청을 시작하기 전에 AWS 한도의 특성을 이해하는 것이 필수적입니다. 이러한 한도는 일반적으로 리소스(예: EC2 인스턴스 수), 처리량(예: IOPS) 또는 초당 API 요청 수(RPS)를 기준으로 분류됩니다.

소프트 한도 vs 하드 한도

대부분의 할당량은 두 가지 범주 중 하나에 속합니다:

소프트 한도(조정 가능한 할당량): 이는 대부분의 할당량입니다. AWS가 새 계정에 설정하는 기본값이며, 충분한 비즈니스 사유가 있는 경우 AWS Support에 요청을 제출하여 일반적으로 증가시킬 수 있습니다.
하드 한도(조정 불가능한 할당량): 이러한 한도는 서비스 설계, 안전 또는 인프라 제약에 의해 결정됩니다. 일반적으로 증가시킬 수 없으므로 아키텍처 해결 방법이 필요합니다.

팁: 먼저 AWS Service Quotas 콘솔을 항상 확인하세요. 여기에 나열된 한도는 일반적으로 소프트 한도이며 요청을 제출하는 기본 방법입니다.

주의가 필요한 일반적인 한도

확장성이 높은 환경에서 다음 한도는 종종 가장 먼저 도달되며 면밀히 모니터링해야 합니다:

EC2 온디맨드 인스턴스 수: 리전의 모든 EC2 인스턴스 유형에서 실행 중인 vCPU의 총 수입니다.
EBS 볼륨 수/크기: 연결된 볼륨의 총 개수 또는 누적 크기에 대한 한도입니다.
VPC 리소스: VPC, 인터넷 게이트웨이, NAT 게이트웨이 및 탄력적 IP(EIP) 수에 대한 한도입니다.
API 스로틀링 한도: S3, DynamoDB 또는 Lambda 호출 속도와 같은 서비스에 대한 초당 요청 수(RPS) 한도입니다.

사전 모니터링 및 예측

스로틀링에 대응하는 것은 비용이 많이 들고 혼란을 야기합니다. 목표는 프로덕션에 영향을 미치기 훨씬 전에 한도 위반을 사전에 예측하는 것입니다.

1. Service Quotas 콘솔 활용

AWS Service Quotas 콘솔은 여러 서비스에서 현재 할당량을 확인하고 사용량을 추적할 수 있는 단일 권위 있는 소스입니다. 다양한 서비스 콘솔에서 한도를 확인할 필요가 없습니다.

실행 단계: Lambda, EC2, RDS, VPC 및 DynamoDB와 같이 애플리케이션에 중요한 서비스의 할당량을 정기적으로 감사하세요. 꾸준히 증가하거나 이미 알림 임계값에 가까운 할당량을 조사하세요.

2. CloudWatch 알람 구현

중요 한도의 경우 사용량이 위험한 임계값에 접근할 때 팀에 알리는 자동 알람을 설정하세요.

많은 리소스 메트릭(예: EC2 vCPU 사용량, Lambda 동시 실행)이 CloudWatch에 게시됩니다. Service Quotas와 직접 통합된 할당량의 경우 할당량 콘솔에서 직접 알람을 생성할 수 있으며, 일반적으로 80% 사용률로 설정합니다.

# 예: Lambda 동시 실행에 대한 80% 사용률 알람 설정
# (일반적으로 Service Quotas 콘솔 통합 또는 CloudFormation을 통해 구성)

AlarmName: LambdaConcurrencyWarning
MetricName: ConcurrentExecutions
Namespace: AWS/Lambda
Statistic: Maximum
Period: 300
Threshold: [현재 한도 * 0.80] 
ComparisonOperator: GreaterThanThreshold
EvaluationPeriods: 2
TreatMissingData: notBreaching

3. 예측 및 계획

개발 마일스톤 및 마케팅 캠페인에 맞춰 할당량 관리를 조정하세요. 주요 확장 이벤트나 제품 출시가 예정된 경우, 필요한 최대 용량을 계산하고 충분한 시간을 두고 증가 요청을 제출하세요. 일부 요청은 빠르게 완료되지만, 다른 요청은 인간 검토나 추가 사유가 필요합니다.

효율적인 서비스 한도 증가 요청 절차

AWS는 Service Quotas 콘솔을 통해 한도 증가 요청을 제출하는 것을 선호합니다. 이렇게 하면 라우팅이 자동화되고 승인 프로세스가 가속화됩니다.

1단계: Service Quotas 콘솔을 통해 제출(권장)

AWS Service Quotas 콘솔로 이동합니다.
특정 서비스(예: 'Amazon EC2')를 검색합니다.
관련 할당량(예: '실행 중인 온디맨드 모든 표준 인스턴스')을 클릭합니다.
증가 요청 버튼을 클릭합니다.
새 원하는 한도와 리전을 지정합니다.
자세한 사유(3단계 참조)를 제공합니다.

할당량이 Service Quotas 콘솔에 나열되지 않은 경우, 기존 AWS Support Center를 통해 '서비스 한도 증가' 케이스 유형으로 요청을 제출해야 합니다.

2단계: 요청에 포함할 주요 정보

AWS Support와의 불필요한 커뮤니케이션을 방지하려면 요청이 포괄적인지 확인하세요:

AWS 리전: 증가가 필요한 정확한 리전(예: us-east-1)을 지정합니다.
특정 한도 이름: 할당량의 정확한 이름(예: 실행 중인 Fargate 작업 수)을 제공합니다.
현재 한도: (선택 사항이지만 도움이 됨) 현재 도달하고 있는 기존 한도를 확인합니다.
요청된 새 한도: 필요한 정확한 최종 숫자(예: 100에서 500으로 증가)를 명시합니다.
비즈니스 사유: 이것이 가장 중요한 요소입니다.

3단계: 강력한 비즈니스 사유 작성

AWS 엔지니어는 요청된 한도가 필요하고, 지속 가능하며, 정확하다는 구체적인 증거를 필요로 합니다. 모호한 요청은 종종 지연되거나 거부됩니다.

사용하지 말아야 할 표현: "테스트를 위해 더 많은 리소스가 필요합니다." 사용해야 할 표현: "새로운 ECS Fargate 워크로드를 지원하기 위해 eu-west-1에서 총 750개를 위해 추가로 500개의 vCPU가 필요합니다. 부하 테스트 결과 출시 트래픽 중 최대 100개의 동시 작업이 필요함을 보여줍니다. 예정된 릴리스 기간 전에 용량을 사용할 수 있어야 합니다."

사유 구성 요소	예시 세부 사항
사용 사례	새 애플리케이션 출시, 고객 온보딩, 시즌 프로모션, 데이터베이스 마이그레이션.
계산 기준	부하 테스트 결과, 예상 트래픽 증가(RPS), 사용자 수, 동시성 요구 사항.
일정	용량이 필요한 시기(예: 2024-11-01까지 용량 운영 필요).
기간	영구적인 증가인가요, 아니면 일시적인 급증인가요?

고급 모범 사례 및 거부 처리

한도를 피하기 위한 아키텍처 전략

때로는 한도를 늘리는 것이 올바른 접근 방식이지만, 종종 병목 현상은 아키텍처 비효율성을 나타냅니다. 매우 큰 증가를 요청하기 전에 다음 완화 기술을 고려하세요:

지수 백오프 및 지터 구현: 실패한 API 호출을 재시도할 때 이 패턴을 사용하여(S3 또는 DynamoDB 한도에 특히 관련) 서비스를 압도하는 것을 방지하고 스로틀링 영향을 최소화합니다.
배치 최적화: 지원되는 경우 여러 개별 API 호출을 단일 배치 작업(예: DynamoDB BatchWriteItem)으로 통합합니다.
캐싱 활용: ElastiCache 또는 CloudFront를 구현하여 백엔드 서비스에 도달하는 요청 수를 줄여 RPS 한도에 도달할 확률을 낮춥니다.

거부된 요청 처리

AWS가 요청한 한도를 거부하거나 크게 낮추는 경우, 일반적으로 사유가 불충분하거나 요청이 안전 매개변수를 초과했음을 의미합니다.

거부에 대한 조치 계획:

즉시 재제출하지 마세요. AWS Support가 제공한 거부 이유를 검토하세요.
사유 개선: 더 구체적인 데이터 포인트, 내부 메트릭 및 명확한 계산 방법론을 제공하세요.
Support에 직접 문의: 문제가 긴급하거나 복잡한 경우 지원 케이스에 응답하여 설명을 요청하고 아키텍처 요구 사항을 검토하기 위한 전화 통화를 예약하세요.

증가 후 검토

한도가 증가된 후에는 CloudWatch 알람을 업데이트하여 새로운 80% 임계값을 반영하세요. 단순히 증가를 받는 것이 끝이 아닙니다. 지속적인 모니터링을 통해 나중에 예기치 않게 새 한도에 도달하지 않도록 해야 합니다.

결론

할당량 관리는 프로덕션 용량 계획의 일부입니다. 아키텍처가 의존하는 할당량을 추적하고, 여유 공간이 부족하기 전에 알림을 받으며, 확장 검토에서 사용하는 것과 동일한 증거(현재 사용량, 예상 최대치, 리전, 일정 및 숫자 계산 방법)를 사용하여 증가를 요청하세요.