AWS Certified Developer - Associate (DVA-C02) #13 Domain 4-2 트러블슈팅과 최적화: 최적화와 문제 해결

인프라 AWS 자격증
4 분 소요

#12 관측에서 무엇이 일어나는지 보는 법을 잡았습니다. 마지막 글은 성능을 개선하고 흔한 오류를 해결하는 법입니다. 시험은 성능,비용 최적화와 함께, 구체적인 오류 코드를 해석하는 능력을 묻습니다.

캐싱 계층 #

같은 데이터를 반복 조회한다면 캐시로 지연,비용,백엔드 부하를 줄입니다. 어느 계층의 캐시인지가 핵심 구분입니다.

캐시위치용도
CloudFront엣지(전 세계)정적,동적 콘텐츠 CDN
API Gateway 캐시API 스테이지REST API 응답 캐싱
ElastiCache애플리케이션 계층DB 앞 범용 인메모리 캐시(Redis/Memcached)
DAXDynamoDB 앞DynamoDB 전용 마이크로초 캐시
  • “전 세계 사용자에게 정적 자산을 빠르게” → CloudFront.
  • “관계형 DB의 반복 쿼리 결과를 캐시” → ElastiCache.
  • “DynamoDB 읽기를 마이크로초로” → DAX.
  • “API Gateway의 같은 응답 반복 호출을 줄이기” → API Gateway 캐시.

캐싱 전략 #

  • Lazy Loading(Cache-Aside). 캐시에 없으면 DB에서 읽어 채움. 쓰지 않는 데이터는 캐시하지 않음.
  • Write-Through. 쓸 때 캐시도 함께 갱신. 항상 최신이지만 안 읽힐 데이터도 캐시.
  • TTL. 만료로 오래된 데이터(stale)를 방지.

Lambda 성능 튜닝 #

손잡이효과
메모리 설정메모리를 올리면 CPU,네트워크도 비례해 증가. 종종 더 큰 메모리가 더 싸고 빠름
콜드 스타트프로비저닝 동시성, 핸들러 밖 초기화 재사용
동시성예약 동시성으로 격리, 스로틀링 방지
패키지 크기작게 유지, 레이어로 의존성 분리

시험 핵심: Lambda는 메모리만 설정하고 CPU는 그에 비례합니다. “CPU가 부족해 느리다"의 답은 메모리를 올리는 것입니다. Lambda Power Tuning으로 비용,성능 최적점을 찾습니다.

자주 나오는 오류 코드 #

트러블슈팅 도메인은 오류 코드를 보고 원인을 맞히는 문항을 냅니다. 외워 두면 즉답할 수 있습니다.

코드의미대응
429 Too Many Requests / ThrottlingException스로틀링(API Gateway,SDK,서비스 한도)지수 백오프 재시도, 한도 상향
ProvisionedThroughputExceededExceptionDynamoDB 용량 초과용량 상향,키 분산,백오프
502 Bad GatewayAPI GW 프록시 통합 Lambda 응답 형식 오류응답 statusCode/body 형식 수정
504 Gateway Timeout통합 타임아웃(29초) 초과처리 단축,비동기 패턴
403 / AccessDenied권한 부족IAM 정책,리소스 정책 확인
ConditionalCheckFailedException조건부 쓰기 조건 불일치낙관적 잠금 충돌 → 재시도
ProvisionedConcurrency / TooManyRequestsException(Lambda)동시성 한도 초과예약/계정 한도 조정

핵심 매핑 몇 가지:

  • 502 = Lambda 응답 형식 문제(프록시 통합에서 잘못된 반환).
  • 504 = 너무 오래 걸림(29초 통합 타임아웃).
  • 429 = 스로틀링 → 지수 백오프.
  • ConditionalCheckFailed = 동시 수정 충돌 → 재시도.

비용 최적화 포인트 #

  • Lambda 메모리 적정화. 너무 작으면 느려서 오히려 비싸고, 너무 크면 낭비. Power Tuning으로 최적점.
  • DynamoDB 용량 모드. 트래픽이 간헐적이면 온디맨드, 예측 가능하면 프로비저닝 + Auto Scaling.
  • S3 수명 주기 + 스토리지 클래스. 오래된 데이터를 저렴한 계층으로.
  • 캐싱. 백엔드 호출,데이터 전송 비용 절감.

시험 출제 패턴 #

  • “Lambda가 느리고 CPU가 부족하다.” → 메모리 상향(CPU 비례).
  • “API에서 502가 난다.” → 프록시 통합 Lambda 응답 형식.
  • “API에서 504가 난다.” → 29초 타임아웃 초과, 처리 단축/비동기화.
  • “DynamoDB 읽기에서 throughput exceeded.” → 용량,키 분산,백오프.
  • “조건부 업데이트가 실패한다.” → 동시 수정 충돌, 재시도.
  • “DynamoDB 반복 읽기를 마이크로초로.” → DAX.
  • “전 세계 정적 콘텐츠 지연을 줄인다.” → CloudFront.
  • “스로틀링(429)에 어떻게 대응.” → 지수 백오프 재시도.

자주 만나는 함정 #

1) Lambda CPU를 직접 설정하려 함 #

CPU는 직접 설정할 수 없습니다. 메모리에 비례합니다.

2) 502와 504 혼동 #

502는 응답 형식 오류, 504는 타임아웃입니다.

3) 캐시 계층 혼동 #

DynamoDB 전용은 DAX, 범용은 ElastiCache, 엣지는 CloudFront입니다.

정리 #

이번 글에서 잡은 것:

  • 캐싱. CloudFront(엣지),ElastiCache(범용),DAX(DynamoDB),API GW 캐시. Lazy Loading vs Write-Through
  • Lambda는 메모리 = CPU. 느리면 메모리 상향
  • 오류 코드. 502(응답 형식),504(타임아웃),429(스로틀링),ConditionalCheckFailed(동시 충돌)
  • 비용. 메모리 적정화, 용량 모드, 수명 주기, 캐싱

다음: 시험 팁 #

열세 편으로 네 도메인을 모두 다뤘습니다. #14 시험 팁에서는 시간 관리, 제약 키워드로 선택지를 거르는 법, 자주 헷갈리는 개념 쌍, 그리고 응시 직전 체크리스트를 정리하겠습니다.

X