AWS 미드레벨 성능 최적화 면접
새 면접Q. Lambda 함수의 메모리 설정을 512MB에서 1024MB로 증가시켰더니 실행 시간이 절반으로 줄었지만, 비용은 오히려 감소했습니다. 이러한 현상이 발생하는 원리를 Lambda의 리소스 할당 방식과 과금 모델을 기반으로 설명하고, 최적의 메모리 설정을 찾기 위한 체계적인 접근 방법을 제시해주세요.
Lambda는 메모리 크기에 비례하여 CPU와 네트워크 대역폭도 함께 증가하며, 과금은 실행 시간과 메모리 크기의 곱으로 계산됩니다.
Lambda는 메모리 설정에 비례하여 CPU 성능과 네트워크 대역폭을 할당합니다. 메모리를 2배 증가시키면 vCPU도 비례하여 증가하므로 CPU 집약적 작업의 실행 시간이 크게 단축될 수 있습니다. 과금은 GB-seconds 단위로 계산되므로, 메모리가 2배 증가해도 실행 시간이 절반 이하로 줄면 총 비용이 감소합니다. 최적 메모리를 찾기 위해서는 AWS Lambda Power Tuning 도구를 사용하여 다양한 메모리 설정에서 비용과 성능을 자동으로 측정하고 비교할 수 있습니다. 또한 CloudWatch Logs에서 실제 메모리 사용량을 모니터링하여 과도한 할당을 방지해야 합니다. CPU 집약적 작업일수록 메모리 증가의 효과가 크지만, I/O 대기 시간이 긴 작업은 메모리 증가로 인한 성능 향상이 제한적입니다.
- • Lambda는 메모리에 비례하여 CPU와 네트워크 리소스를 할당
- • 과금은 GB-seconds 단위로 실행 시간과 메모리의 곱
- • Lambda Power Tuning 도구를 활용한 최적화
- • 실제 메모리 사용량 모니터링 필요
서버리스 애플리케이션에서 Lambda 함수의 메모리 설정을 최적화하여 비용을 30-50% 절감하면서도 성능을 개선하는 상황에서 사용됩니다.
Lambda 함수에서 외부 API 호출이 대부분의 실행 시간을 차지하는 경우, 메모리 증가가 성능 개선에 효과적일까요? 이러한 I/O 바운드 작업을 최적화하는 다른 방법은 무엇인가요?
Q. DynamoDB 테이블에서 특정 파티션 키에 대한 읽기 요청이 집중되어 ProvisionedThroughputExceededException이 발생하고 있습니다. 프로비저닝된 RCU는 충분하지만 Hot Partition 문제가 의심됩니다. 이 문제를 진단하는 방법과 해결하기 위한 다층적 접근 방법을 데이터 모델링, 캐싱, 읽기 전략 관점에서 설명해주세요.
DynamoDB는 파티션 단위로 처리량을 분산하므로, 전체 RCU가 충분해도 특정 파티션에 요청이 집중되면 throttling이 발생할 수 있습니다.
Hot Partition 문제는 CloudWatch Metrics의 UserErrors와 SystemErrors를 모니터링하고, Contributor Insights를 활성화하여 어떤 파티션 키가 가장 많은 요청을 받는지 확인하여 진단할 수 있습니다. 데이터 모델링 측면에서는 파티션 키에 랜덤 접미사를 추가하여 쓰기를 분산시키거나, 복합 파티션 키를 사용하여 데이터를 여러 파티션에 분산시킬 수 있습니다. 캐싱 측면에서는 DAX(DynamoDB Accelerator)를 도입하여 자주 읽히는 데이터를 메모리에 캐싱하고 DynamoDB에 대한 직접 요청을 줄일 수 있습니다. 읽기 전략으로는 Eventually Consistent Read를 사용하여 읽기 비용을 절반으로 줄이고, 배치 작업에는 BatchGetItem을 사용하여 요청 수를 줄일 수 있습니다. On-Demand 모드로 전환하면 자동으로 워크로드에 맞춰 확장되지만 비용이 증가하므로 트래픽 패턴을 고려해야 합니다. 근본적으로는 액세스 패턴을 분석하여 GSI(Global Secondary Index)를 추가하거나 테이블 설계를 재검토해야 합니다.
- • Contributor Insights로 Hot Partition 식별
- • 파티션 키 설계 개선으로 데이터 분산
- • DAX를 통한 읽기 요청 캐싱
- • Eventually Consistent Read와 BatchGetItem 활용
- • 액세스 패턴 기반 테이블 재설계
인기 상품에 대한 조회가 집중되는 전자상거래 시스템에서 특정 상품 정보 조회 시 throttling이 발생하는 문제를 해결하는 상황에서 사용됩니다.
DAX를 도입할 때 TTL 설정이 부적절하면 오히려 stale data 문제가 발생할 수 있습니다. 실시간성이 중요한 데이터와 그렇지 않은 데이터를 구분하여 캐싱 전략을 수립하는 방법을 설명해주세요.
Q. RDS PostgreSQL 데이터베이스에서 특정 쿼리가 10초 이상 소요되어 애플리케이션 응답이 느려지고 있습니다. Performance Insights와 Slow Query Log를 활용하여 문제 쿼리를 식별하고, EXPLAIN ANALYZE 결과를 해석하여 최적화하는 체계적인 절차를 설명해주세요. 인덱스 추가, 쿼리 재작성, 파티셔닝 중 어떤 접근을 우선해야 하는지도 포함해주세요.
Performance Insights는 데이터베이스 부하를 시각화하고 가장 많은 리소스를 소비하는 쿼리를 식별하는 데 유용합니다.
먼저 Performance Insights 대시보드에서 DB Load 그래프를 확인하여 CPU, I/O, Lock 등 어떤 리소스가 병목인지 파악하고, Top SQL 섹션에서 가장 많은 시간을 소비하는 쿼리를 식별합니다. Slow Query Log를 활성화하여 실행 시간이 긴 쿼리를 로깅하고, log_min_duration_statement 파라미터를 조정하여 임계값을 설정합니다. 문제 쿼리를 식별한 후 EXPLAIN ANALYZE를 실행하여 실행 계획을 분석하며, Seq Scan이 발생하는지, Index Scan이 효율적인지, Join 순서가 적절한지 확인합니다. 우선순위는 먼저 적절한 인덱스가 있는지 확인하고 없다면 추가하며, WHERE 절과 JOIN 조건에 사용되는 컬럼에 인덱스를 생성합니다. 인덱스가 있는데도 사용되지 않는다면 쿼리를 재작성하여 인덱스를 활용하도록 하고, 불필요한 컬럼 조회를 제거하거나 서브쿼리를 JOIN으로 변경합니다. 테이블 크기가 매우 크고 특정 범위만 자주 조회된다면 파티셔닝을 고려하지만, 이는 스키마 변경이 필요하므로 가장 나중에 검토합니다.
- • Performance Insights로 리소스 병목 식별
- • Slow Query Log로 문제 쿼리 추적
- • EXPLAIN ANALYZE로 실행 계획 분석
- • 인덱스 추가 → 쿼리 재작성 → 파티셔닝 순서로 접근
사용자가 증가하면서 특정 페이지의 로딩 시간이 급격히 느려질 때, 데이터베이스 쿼리 성능을 분석하고 최적화하는 상황에서 사용됩니다.
인덱스를 추가했는데도 쿼리 성능이 개선되지 않고 오히려 쓰기 성능이 저하되는 경우가 있습니다. 인덱스의 Selectivity와 Cardinality를 고려하여 효과적인 인덱스를 설계하는 방법을 설명해주세요.
Q. 글로벌 서비스를 운영 중인데 CloudFront의 Cache Hit Ratio가 30% 이하로 낮아 Origin 서버에 부하가 집중되고 있습니다. CloudWatch Metrics를 통해 캐시 효율성을 측정하고, Cache Behavior 설정, Origin Response Header, Invalidation 전략을 종합적으로 개선하여 Cache Hit Ratio를 80% 이상으로 높이는 방법을 설명해주세요.
Cache Hit Ratio가 낮은 주요 원인은 Query String, Cookie, Header 등이 캐시 키에 포함되어 동일한 콘텐츠가 여러 번 캐싱되는 경우가 많습니다.
먼저 CloudWatch에서 CacheHitRate, OriginLatency, Requests 메트릭을 모니터링하여 현재 캐시 효율성을 측정합니다. Cache Behavior 설정에서 Query String Whitelist를 사용하여 캐싱에 실제로 영향을 주는 파라미터만 캐시 키에 포함시키고, 불필요한 파라미터는 제외합니다. Cookie와 Header도 마찬가지로 필요한 것만 Forward하도록 설정하며, 특히 Authorization 헤더나 User-Agent는 필요한 경우에만 포함시킵니다. Origin 서버에서 Cache-Control과 ETag 헤더를 적절히 설정하여 콘텐츠의 캐시 가능 여부와 TTL을 명확히 지정합니다. 정적 리소스는 max-age를 길게 설정하고, 동적 콘텐츠는 짧게 설정하되 Vary 헤더를 활용하여 조건부 캐싱을 구현합니다. Invalidation은 비용이 발생하므로 자주 사용하지 말고, 대신 버전 관리된 URL(예: /assets/v2/style.css)을 사용하여 캐시 무효화 없이 새 콘텐츠를 배포합니다. Lambda@Edge를 활용하여 Origin Request/Response를 조작하고 캐시 키를 정규화할 수도 있습니다.
- • Query String, Cookie, Header를 선택적으로 캐시 키에 포함
- • Origin에서 Cache-Control과 ETag 헤더 적절히 설정
- • Invalidation 대신 버전 관리된 URL 사용
- • Lambda@Edge로 캐시 키 정규화
글로벌 사용자에게 미디어 콘텐츠를 제공하는 서비스에서 Origin 서버 비용을 절감하고 응답 속도를 개선하기 위해 CDN 캐싱을 최적화하는 상황에서 사용됩니다.
사용자마다 다른 콘텐츠를 보여줘야 하는 개인화된 페이지에서도 캐싱을 활용하려면 어떻게 해야 하나요? Edge Side Includes나 Lambda@Edge를 활용한 부분 캐싱 전략을 설명해주세요.
Q. ECS Fargate 서비스에서 Application Auto Scaling을 설정했지만, 갑작스러운 트래픽 증가 시 스케일 아웃이 늦어져 5xx 에러가 발생합니다. Target Tracking Scaling Policy와 Step Scaling Policy의 차이를 설명하고, 스케일 아웃 속도를 개선하기 위한 Cooldown Period, Warmup Time, Metric 선택 전략을 제시해주세요. Scheduled Scaling과 Predictive Scaling을 함께 활용하는 방법도 포함해주세요.
Auto Scaling의 반응 속도는 메트릭 수집 주기, 평가 기간, Cooldown 시간의 합으로 결정되며, 예측 가능한 트래픽 패턴이 있다면 사전에 스케일링할 수 있습니다.
Target Tracking Scaling Policy는 특정 메트릭(예: CPU 사용률 70%)을 목표값으로 유지하도록 자동으로 조정하며 설정이 간단하지만, Step Scaling Policy는 메트릭 값의 변화 폭에 따라 다른 크기로 스케일링하여 급격한 부하 증가에 더 빠르게 대응할 수 있습니다. 스케일 아웃 속도를 개선하려면 먼저 메트릭으로 CPU보다는 ALB의 TargetResponseTime이나 RequestCountPerTarget을 사용하여 실제 사용자 경험과 직결된 지표를 추적합니다. Cooldown Period를 스케일 아웃 시에는 짧게(60초), 스케일 인 시에는 길게(300초) 설정하여 빠르게 확장하되 불필요한 축소는 방지합니다. Warmup Time을 설정하여 새로 시작된 태스크가 트래픽을 받기 전 준비 시간을 확보하고, 이 시간 동안은 메트릭 계산에서 제외하여 연쇄적인 스케일 아웃을 방지합니다. 예측 가능한 트래픽 패턴(예: 매일 오전 9시 급증)이 있다면 Scheduled Scaling으로 미리 용량을 늘려두고, AWS Auto Scaling의 Predictive Scaling을 활성화하여 과거 데이터를 기반으로 자동으로 예측하여 사전 스케일링할 수 있습니다. 또한 최소 태스크 수를 적절히 설정하여 기본 용량을 확보하는 것도 중요합니다.
- • Step Scaling으로 급격한 부하 변화에 빠른 대응
- • TargetResponseTime 같은 사용자 경험 중심 메트릭 사용
- • 스케일 아웃 Cooldown은 짧게, 스케일 인은 길게 설정
- • Warmup Time으로 새 태스크 준비 시간 확보
- • Scheduled/Predictive Scaling으로 사전 대응
이벤트나 프로모션으로 트래픽이 급증하는 커머스 서비스에서 서버 용량을 자동으로 조정하여 안정적인 서비스를 유지하면서도 비용을 최적화하는 상황에서 사용됩니다.
컨테이너 이미지가 커서 태스크 시작에 2분 이상 소요되는 경우, Auto Scaling만으로는 갑작스러운 트래픽 증가에 대응하기 어렵습니다. 이런 상황에서 SQS를 활용한 버퍼링이나 오버프로비저닝 전략을 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!