Source: Dev.to

AP‑Southeast‑2에서 발생한 DynamoDB 오류 해결 방법

이 글에서는 ap‑southeast‑2(시드니) 리전에서 DynamoDB를 사용할 때 흔히 마주치는 오류들을 정리하고, 각각에 대한 해결책을 제시합니다.
문제의 원인을 정확히 파악하고, 적절한 코드를 적용하면 서비스 가용성을 크게 높일 수 있습니다.

---

1️⃣ ProvisionedThroughputExceededException

원인

• 테이블에 설정된 프로비저닝된 읽기/쓰기 용량을 초과했을 때 발생합니다.
• 급격한 트래픽 피크 혹은 Hot Partition(특정 파티션 키에 집중된 요청) 때문에 발생할 수 있습니다.

해결책

1. 자동 스케일링을 활성화합니다.
2. **지수 백오프(Exponential Backoff)**와 Jitter를 적용해 재시도 로직을 구현합니다.
3. 파티션 키 설계를 재검토하여 키 분산을 개선합니다.

// 예시: AWS SDK for JavaScript (v3) 재시도 정책
const { DynamoDBClient } = require("@aws-sdk/client-dynamodb");
const { defaultProvider } = require("@aws-sdk/credential-provider-node");
const { RetryStrategy } = require("@aws-sdk/middleware-retry");

const client = new DynamoDBClient({
  region: "ap-southeast-2",
  retryStrategy: new RetryStrategy({
    maxAttempts: 5,
    retryDelayBase: 100, // ms
    retryDelayCustom: (attempt) => Math.pow(2, attempt) * 100 + Math.random() * 100
  })
});

---

2️⃣ ThrottlingException

원인

• 읽기/쓰기 용량 초과와 비슷하지만, DynamoDB가 내부적으로 리소스 제한을 적용했을 때 발생합니다.
• Global Secondary Index (GSI) 에 대한 과도한 요청도 원인이 될 수 있습니다.

해결책

• 지수 백오프와 재시도를 적용합니다.
• GSI에 대한 프로비저닝 용량을 별도로 조정합니다.
• BatchWriteItem / BatchGetItem 사용 시, 요청당 아이템 수를 25 이하로 제한합니다.

---

3️⃣ AccessDeniedException

원인

• IAM 정책에 DynamoDB에 대한 권한이 부족하거나, 리전 제한이 잘못 설정된 경우 발생합니다.

해결책

1. IAM 역할/사용자 정책에 다음 권한을 추가합니다.

{
  "Effect": "Allow",
  "Action": [
    "dynamodb:PutItem",
    "dynamodb:GetItem",
    "dynamodb:Query",
    "dynamodb:Scan",
    "dynamodb:UpdateItem",
    "dynamodb:DeleteItem"
  ],
  "Resource": "arn:aws:dynamodb:ap-southeast-2:123456789012:table/YourTableName"
}

2. 조건(Condition) 절에 aws:RequestedRegion이 ap-southeast-2 로 지정되어 있는지 확인합니다.

---

4️⃣ ValidationException

원인

• 요청 파라미터가 잘못된 형식이거나, 필수 속성이 누락된 경우 발생합니다.
• 예: Key에 정의되지 않은 속성을 사용하거나, ExpressionAttributeValues에 타입이 맞지 않을 때.

해결책

• SDK가 자동으로 직렬화하도록 DocumentClient를 사용합니다.
• 요청 객체를 JSON.stringify 로 출력해 실제 전송되는 형태를 확인합니다.

const params = {
  TableName: "YourTableName",
  Key: { pk: "USER#123", sk: "METADATA" },
  UpdateExpression: "SET #name = :name",
  ExpressionAttributeNames: { "#name": "name" },
  ExpressionAttributeValues: { ":name": "홍길동" }
};

console.log(JSON.stringify(params, null, 2));

---

5️⃣ ResourceNotFoundException

원인

• 지정한 테이블 혹은 인덱스가 존재하지 않을 때 발생합니다.
• 리전이 다르거나, 테이블 이름에 오타가 있는 경우가 일반적입니다.

해결책

• 콘솔 또는 CLI(aws dynamodb describe-table) 로 테이블 존재 여부를 확인합니다.
• 환경 변수에 저장된 리전 값이 ap-southeast-2 로 정확히 설정됐는지 검증합니다.

aws dynamodb describe-table --table-name YourTableName --region ap-southeast-2

---

6️⃣ 기타 팁

---

🎯 결론

• 오류 종류를 정확히 파악하고, 각각에 맞는 재시도 전략과 리소스 설정을 적용하면 대부분의 DynamoDB 오류를 손쉽게 해결할 수 있습니다.
• 특히 ap‑southeast‑2 리전에서는 네트워크 지연과 리전‑특화 IAM 정책이 문제를 일으키는 경우가 많으니, 위에서 제시한 체크리스트를 정기적으로 검토하세요.

Tip: 오류가 지속될 경우, AWS Support에 Request ID와 CloudWatch 로그를 첨부해 문의하면 빠른 해결을 받을 수 있습니다.

TL;DR

DynamoDB 오류가 ap‑southeast‑2에서 발생하고, 종종 ProvisionedThroughputExceededException 또는 연결 타임아웃으로 나타나는 경우는 용량 문제라기보다 특정 가용 영역 내 로컬 네트워크 “그레이 실패” 때문인 경우가 많습니다. 해결 방법은 인스턴스 재부팅 같은 간단한 방법부터 AWS SDK 클라이언트 타임아웃을 조정하고 DynamoDB Gateway VPC Endpoint를 구현하여 프라이빗 네트워크 연결을 제공하는 등 견고한 아키텍처 수정까지 다양합니다.

왜 발생하는가

• AWS 리전 = 가용 영역(AZ)들의 집합입니다.
• 단일 AZ에서 발생하는 “그레이 실패”는 전체 리전 상태가 정상(그린)이라도 DynamoDB 연결에 장애를 일으킬 수 있습니다.
• AWS SDK는 dynamodb.ap-southeast-2.amazonaws.com을 호출자 AZ에 최적화된 지연 시간을 갖는 IP로 해석합니다. 해당 프런트엔드에 일시적인 네트워크 결함이 발생하면 그 AZ에 있는 인스턴스만 장애를 경험합니다.

팁: 리전이 단일 장애 지점이 되는 단일한 서비스라고 가정하지 마세요. 개별 AZ 내에서의 장애를 대비해 설계하세요.

사고 (실제 사례)

“2:47 AM. PagerDuty가 울리고 있다. 시드니(ap‑southeast‑2)에 있는 우리의 주요 인증 서비스가 ProvisionedThroughputExceededException와 DynamoDB에 대한 연결 타임아웃을 발생시키고 있었다. prod‑users‑table에 대한 CloudWatch 메트릭은 평탄했으며—용량 고갈이 없었다. 로그인 시도 중 절반이 실패했다.”

After an hour of debugging we discovered:

• AZ ap‑southeast‑2a에 있는 인스턴스만 실패하고 있었다.
• 2b와 2c에 있는 인스턴스는 정상이었다.

이는 AWS “그레이 실패”의 전형적인 징후이다: 로컬화된, 종종 네트워크와 관련된 문제로 AWS 상태 페이지가 빨간색으로 바뀌지 않는다.

세 가지 플레이북 – 빠른 해결부터 장기 해결까지

플레이 #2 – 예시: 공격적인 SDK 구성 (Python/Boto3)

# Example in Python using Boto3
from botocore.config import Config
from boto3 import resource

# Configure a more aggressive timeout and retry strategy
#   • Connect timeout: 1 s
#   • Read timeout:    1 s
#   • Retries: 5 attempts with backoff
config = Config(
    connect_timeout=1,
    read_timeout=1,
    retries={'max_attempts': 5}
)

# Pass this config when creating your client or resource
dynamodb = resource('dynamodb',
                    region_name='ap-southeast-2',
                    config=config)

table = dynamodb.Table('prod-users-table')
# All calls using `table` now inherit the new timeouts.

이 변경으로 30초 동안 사용자에게 보였던 장애를 대부분의 사용자가 전혀 눈치채지 못하는 빠른 실패‑재시도 시나리오로 전환할 수 있습니다.

Play #3 – 문제를 존재하지 않게 설계하기

DynamoDB 게이트웨이 VPC 엔드포인트

• 프라이빗하고 직접적인 연결 VPC와 DynamoDB 사이.
• 트래픽은 AWS 프라이빗 네트워크에 머무르며—공용 인터넷에 절대 노출되지 않음.
• 신뢰성을 향상시키고, 지연 시간을 감소시키며, 보안 경계를 추가합니다 (NAT/IGW 아웃바운드가 필요 없음).

구현 단계 (고수준):

1. VPC 콘솔을 열고 → Endpoints → Create Endpoint.
2. Service category: AWS services를 선택하고 com.amazonaws.ap-southeast-2.dynamodb를 선택합니다.
3. 엔드포인트를 해당 **subnet(s)**와 route tables에 연결합니다.
4. (선택 사항) 접근 가능한 DynamoDB 테이블을 제한하는 policy를 추가합니다.
5. 애플리케이션의 SDK 설정을 업데이트하여 VPC 엔드포인트를 사용하도록 합니다 (보통 DNS가 엔드포인트를 해석하면 자동 적용됩니다).

요약

• Grey failures는 단일 AZ에서 용량 문제처럼 보일 수 있습니다.
• 빠른 해결책: 영향을 받은 인스턴스를 재시작합니다.
• 단기 복원력: SDK 타임아웃 및 재시도를 조정합니다.
• 장기 견고성: DynamoDB Gateway VPC 엔드포인트를 배포합니다.

이러한 접근 방식을 계층화함으로써, 단일 AZ에 문제가 발생하더라도 인증 서비스(또는 DynamoDB 기반 워크로드)를 원활하게 운영할 수 있습니다. 🚀

DynamoDB용 VPC 엔드포인트

VPC 엔드포인트를 생성하면 퍼블릭 DNS 해석 및 “그레이‑실패”를 일으키는 예측 불가능한 네트워크 경로를 우회합니다. 트래픽이 VPC 내부에 머무르므로 신뢰성과 보안이 모두 보장됩니다.

설정 방법

1. Create a Gateway Endpoint in your VPC. → VPC에서 게이트웨이 엔드포인트를 생성합니다.
2. Associate the endpoint with the route tables of the subnets that host your application instances. → 엔드포인트를 애플리케이션 인스턴스가 위치한 서브넷의 라우팅 테이블에 연결합니다.
3. Update Security Groups to allow traffic to the DynamoDB service via the endpoint’s prefix list. → 엔드포인트의 프리픽스 리스트를 통해 DynamoDB 서비스로의 트래픽을 허용하도록 보안 그룹을 업데이트합니다.

It’s a bit more work, but it virtually eliminates this class of problems while keeping database traffic off the Internet.
조금 더 작업이 필요하지만, 데이터베이스 트래픽을 인터넷에서 차단하면서 이 유형의 문제를 사실상 제거합니다.

솔루션 옵션

TL;DR

특이하고 특정 지역에 한정된 DynamoDB 오류가 발생했을 때:

1. 코드나 용량 계획을 바로 탓하지 마세요.
2. 어떤 가용 영역(AZ)에서 문제가 발생했는지 확인하세요.
3. 문제가 반복되거나 프로덕션 안정성에 영향을 미친다면 VPC 엔드포인트를 고려하세요.

기억하세요: 클라우드는 단지 다른 사람의 컴퓨터일 뿐이며, 때때로 그 컴퓨터들 사이의 네트워크 케이블이 조금 느슨해질 수 있습니다.

---

👉 원문은 TechResolve.blog에서 확인하세요

☕ 제 작업을 지원하고 싶다면
이 글이 도움이 되었다면 커피 한 잔 사주세요:
👉