AWS 주니어 기술면접
새 면접Q. DynamoDB에서 Global Secondary Index(GSI)와 Local Secondary Index(LSI)의 차이점을 설명하고, 각각을 생성할 수 있는 시점과 제약사항은 무엇인가요?
인덱스의 파티션 키 구성과 생성 시점, 프로비저닝 방식의 차이를 생각해보세요.
GSI는 기본 테이블과 다른 파티션 키와 정렬 키를 사용할 수 있으며, 테이블 생성 후에도 추가/삭제가 가능합니다. LSI는 기본 테이블과 동일한 파티션 키를 사용하되 다른 정렬 키를 지정하며, 반드시 테이블 생성 시에만 정의할 수 있습니다. GSI는 독립적인 읽기/쓰기 용량을 가지지만, LSI는 기본 테이블의 용량을 공유합니다. GSI는 eventual consistency를 제공하지만, LSI는 strong consistency 옵션을 선택할 수 있습니다. 테이블당 GSI는 최대 20개, LSI는 최대 5개까지 생성 가능합니다.
- • GSI는 다른 파티션 키 사용 가능, LSI는 동일 파티션 키 필수
- • GSI는 생성 후 추가 가능, LSI는 테이블 생성 시에만 정의
- • GSI는 독립 용량, LSI는 테이블 용량 공유
- • LSI는 strong consistency 지원
사용자 이메일로 검색하거나 생성일자 기준으로 정렬이 필요한 경우 적절한 인덱스를 선택해야 합니다.
특정 쿼리 패턴에서 GSI와 LSI 중 어느 것을 선택해야 하는지 판단하는 기준은 무엇인가요?
Q. 프로덕션 환경에서 API Gateway + Lambda 구조의 API 응답 시간이 갑자기 느려졌습니다. 어떤 순서로 원인을 진단하고, 각 단계에서 확인해야 할 CloudWatch 메트릭은 무엇인가요?
API Gateway, Lambda, 외부 의존성 순서로 병목 지점을 좁혀가며 확인하세요.
먼저 API Gateway의 IntegrationLatency와 Latency 메트릭을 비교하여 지연이 Lambda에서 발생하는지 확인합니다. Lambda의 Duration, ConcurrentExecutions, Throttles 메트릭을 확인하여 실행 시간 증가나 동시성 제한 문제를 파악합니다. Lambda 로그에서 Cold Start 발생 빈도를 확인하고, 메모리 사용량이 할당량에 근접하는지 체크합니다. Lambda 내부에서 호출하는 DynamoDB나 RDS 등 외부 서비스의 응답 시간을 CloudWatch Logs Insights로 분석합니다. VPC Lambda의 경우 ENI 생성 지연이나 NAT Gateway 병목도 확인해야 합니다.
- • API Gateway IntegrationLatency로 Lambda 지연 확인
- • Lambda Duration과 ConcurrentExecutions 분석
- • Cold Start 빈도와 메모리 사용량 체크
- • 외부 서비스 응답 시간 분석
사용자 증가로 API 응답이 느려질 때 병목 지점을 빠르게 찾아 대응해야 합니다.
Lambda 동시 실행 제한에 도달했을 때 즉시 취할 수 있는 조치와 장기적인 해결 방법은 무엇인가요?
Q. S3 버킷에 저장된 민감한 사용자 데이터를 보호하기 위한 암호화 방법 3가지(SSE-S3, SSE-KMS, SSE-C)를 비교하고, 각각의 키 관리 방식과 적합한 사용 사례를 설명해주세요.
누가 암호화 키를 관리하는지, 키 회전과 감사 로그 필요성을 기준으로 생각해보세요.
SSE-S3는 AWS가 관리하는 키로 자동 암호화하며, 별도 설정 없이 간편하게 사용할 수 있어 일반적인 데이터 보호에 적합합니다. SSE-KMS는 AWS KMS에서 관리하는 고객 마스터 키를 사용하며, 키 회전 자동화와 CloudTrail을 통한 키 사용 감사가 가능해 규제 준수가 필요한 환경에 적합합니다. SSE-C는 고객이 직접 제공하는 암호화 키를 사용하며, AWS는 키를 저장하지 않고 요청마다 키를 전달해야 하므로 완전한 키 통제가 필요한 경우 사용합니다. SSE-KMS는 API 호출 비용과 요청 제한이 있지만, 가장 세밀한 접근 제어와 감사가 가능합니다.
- • SSE-S3는 AWS 관리 키로 간편한 암호화
- • SSE-KMS는 키 회전과 감사 로그 지원
- • SSE-C는 고객이 키를 완전히 통제
- • 규제 준수 요구사항에 따라 선택
개인정보나 금융 데이터를 S3에 저장할 때 규제 요구사항에 맞는 암호화 방식을 선택해야 합니다.
S3 버킷 정책과 KMS 키 정책을 함께 사용하여 특정 IAM 역할만 데이터를 복호화할 수 있도록 설정하는 방법은 무엇인가요?
Q. 모바일 앱에서 대용량 동영상 파일을 S3에 업로드해야 합니다. 안정적이고 효율적인 업로드를 위한 아키텍처를 설계할 때 Presigned URL, Multipart Upload, S3 Transfer Acceleration을 어떻게 조합하고, 업로드 실패 시 재개 로직을 어떻게 구현해야 하나요?
클라이언트 직접 업로드와 대용량 파일 분할, 네트워크 최적화를 고려하세요.
먼저 Lambda 함수를 통해 Presigned URL을 생성하여 클라이언트가 서버를 거치지 않고 S3에 직접 업로드하도록 구성합니다. 100MB 이상의 대용량 파일은 Multipart Upload를 사용하여 5MB~5GB 크기의 파트로 분할하고, 각 파트를 병렬로 업로드하여 속도를 높입니다. 글로벌 사용자를 위해 S3 Transfer Acceleration을 활성화하여 CloudFront 엣지 로케이션을 통한 최적 경로로 업로드합니다. 업로드 실패 시 재개를 위해 클라이언트는 각 파트의 ETag를 로컬에 저장하고, 실패한 파트만 재전송하며, 모든 파트 업로드 완료 후 CompleteMultipartUpload API를 호출합니다. 7일 내 완료되지 않은 Multipart Upload는 Lifecycle Policy로 자동 삭제하여 비용을 절감합니다.
- • Presigned URL로 클라이언트 직접 업로드
- • Multipart Upload로 파일 분할 및 병렬 업로드
- • Transfer Acceleration으로 글로벌 성능 향상
- • ETag 저장으로 실패 파트만 재전송
동영상 스트리밍 서비스에서 사용자가 대용량 콘텐츠를 안정적으로 업로드할 수 있도록 구현할 때 사용합니다.
Multipart Upload 중 일부 파트만 업로드되고 중단된 경우, 스토리지 비용이 계속 발생하는 것을 방지하기 위한 자동화 방법은 무엇인가요?
Q. RDS MySQL 데이터베이스의 읽기 성능을 개선하기 위해 ElastiCache Redis를 도입하려고 합니다. 캐시 전략(Cache-Aside, Write-Through)을 비교하고, TTL 설정 시 고려사항과 캐시 무효화 시나리오를 설명해주세요.
데이터 일관성과 캐시 미스 처리 방식, 업데이트 빈도를 기준으로 비교하세요.
Cache-Aside 패턴은 애플리케이션이 먼저 캐시를 조회하고, 미스 시 DB에서 읽어 캐시에 저장하는 방식으로 읽기 위주 워크로드에 적합합니다. Write-Through 패턴은 데이터 쓰기 시 DB와 캐시를 동시에 업데이트하여 캐시가 항상 최신 상태를 유지하지만, 쓰기 지연이 증가할 수 있습니다. TTL은 데이터 변경 빈도에 따라 설정하며, 자주 변경되는 데이터는 짧게(5분~1시간), 정적 데이터는 길게(수 시간~하루) 설정합니다. 데이터 업데이트 시에는 해당 키를 명시적으로 삭제하거나 새 값으로 덮어써서 캐시를 무효화하고, 대량 업데이트의 경우 캐시 키에 버전 번호를 포함시켜 일괄 무효화합니다. 캐시 워밍 전략으로 배포 후 주요 데이터를 미리 캐시에 적재하여 초기 성능 저하를 방지합니다.
- • Cache-Aside는 읽기 위주, Write-Through는 일관성 중시
- • TTL은 데이터 변경 빈도에 따라 조정
- • 업데이트 시 명시적 캐시 무효화
- • 캐시 워밍으로 초기 성능 확보
상품 목록이나 사용자 프로필처럼 자주 조회되지만 변경은 적은 데이터의 읽기 성능을 개선할 때 사용합니다.
캐시 서버 장애 시 DB에 급격한 부하가 몰리는 것을 방지하기 위한 Circuit Breaker 패턴을 어떻게 구현하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!