AWS 시니어 아키텍트 기술면접
새 면접Q. AWS KMS의 Envelope Encryption 동작 원리를 설명하고, CMK(Customer Master Key)와 Data Key의 역할을 설명해주세요. 또한 대용량 데이터 암호화 시 성능을 고려한 아키텍처 설계 방안과, Multi-Region Key를 활용한 재해복구 전략을 제시해주세요.
Envelope Encryption은 데이터를 암호화하는 Data Key를 다시 CMK로 암호화하는 2단계 암호화 방식입니다. CMK는 KMS 내부에서만 사용되며 절대 외부로 노출되지 않고, Data Key는 평문과 암호화된 형태 모두 반환되어 실제 데이터 암호화에 사용됩니다. 대용량 데이터는 Data Key로 로컬에서 암호화하여 네트워크 오버헤드를 줄이고, Multi-Region Key를 사용하면 리전 간 암호화된 데이터를 복호화 키 복제 없이 처리할 수 있어 글로벌 DR 시나리오에 유용합니다. S3의 경우 SSE-KMS를 활용하면 자동으로 Envelope Encryption이 적용되며, 감사 로그를 CloudTrail로 추적할 수 있습니다.
- • Data Key로 실제 데이터 암호화, CMK로 Data Key 암호화하는 이중 구조
- • CMK는 KMS 내부에만 존재하여 보안성 강화, 대용량 데이터 암호화 시 네트워크 부하 최소화
- • Multi-Region Key를 통한 크로스 리전 복호화 지원 및 글로벌 재해복구 전략
- • CloudTrail을 통한 모든 암호화 작업의 감사 추적 가능
KMS의 요청 제한(Rate Limit)으로 인한 throttling 문제를 겪을 때 어떻게 해결하시겠습니까? Data Key Caching 전략과 보안 트레이드오프를 설명해주세요.
Q. CloudFront의 Origin Shield와 Regional Edge Cache의 차이점을 설명하고, 캐시 계층 구조에서 각각의 역할을 설명해주세요. 또한 Origin 서버 부하를 최소화하기 위한 Cache-Control 헤더 전략과, 동적 콘텐츠 가속을 위한 Lambda@Edge와 CloudFront Functions의 선택 기준을 제시해주세요.
Regional Edge Cache는 Edge Location과 Origin 사이의 중간 캐시 계층으로 자동으로 동작하며, Origin Shield는 특정 리전에 추가 캐시 계층을 명시적으로 구성하여 Origin 요청을 단일 지점으로 집중시킵니다. Origin Shield는 여러 Regional Edge Cache의 캐시 미스를 통합하여 Origin 부하를 최대 60% 감소시킬 수 있습니다. Cache-Control에서 max-age는 브라우저 캐시를, s-maxage는 CDN 캐시를 제어하며, stale-while-revalidate로 백그라운드 갱신을 구현할 수 있습니다. Lambda@Edge는 복잡한 로직(인증, A/B 테스트)에 적합하지만 비용이 높고, CloudFront Functions는 간단한 헤더 조작이나 URL 리라이트에 적합하며 지연시간이 1ms 미만으로 매우 낮습니다.
- • Origin Shield는 명시적 추가 계층으로 Origin 요청 집중화, Regional Edge Cache는 자동 중간 캐시
- • Cache-Control 헤더의 max-age, s-maxage, stale-while-revalidate를 통한 계층별 캐시 제어
- • Lambda@Edge는 Node.js/Python 지원 및 복잡한 로직 처리, CloudFront Functions는 JavaScript 경량 처리
- • Origin Shield로 캐시 적중률 향상 및 Origin 부하 60% 감소 가능
글로벌 서비스에서 사용자별로 다른 콘텐츠를 제공해야 하는 경우, Cache Key 설계 전략과 캐시 적중률을 유지하면서 개인화를 구현하는 방법을 설명해주세요.
Q. RDS Proxy의 Connection Pooling 메커니즘과 IAM 인증 통합 방식을 설명하고, Lambda와 같은 서버리스 환경에서 데이터베이스 연결 관리 문제를 어떻게 해결하는지 설명해주세요. 또한 Pinning 현상의 원인과 이를 방지하기 위한 전략, 그리고 Failover 시나리오에서 RDS Proxy의 역할을 설명해주세요.
RDS Proxy는 클라이언트 연결을 풀링하여 실제 데이터베이스 연결 수를 줄이고, Lambda의 동시 실행 환경에서 발생하는 연결 고갈 문제를 해결합니다. IAM 인증을 사용하면 데이터베이스 암호를 코드에 하드코딩하지 않고 IAM 역할 기반으로 인증할 수 있으며, 토큰은 15분마다 자동 갱신됩니다. Pinning은 트랜잭션이나 세션 변수 사용 시 특정 연결에 고정되어 풀링 효과가 감소하는 현상으로, 트랜잭션을 짧게 유지하고 세션 변수 사용을 최소화해야 합니다. Failover 시 RDS Proxy는 자동으로 새 Writer 인스턴스로 연결을 라우팅하며, 애플리케이션은 연결 문자열 변경 없이 투명하게 장애조치를 처리할 수 있습니다.
- • Connection Pooling으로 Lambda 동시 실행 시 데이터베이스 연결 고갈 방지
- • IAM 인증 통합으로 암호 관리 부담 제거 및 15분 자동 토큰 갱신
- • Pinning 현상은 트랜잭션/세션 변수 사용 시 발생, 짧은 트랜잭션으로 완화
- • Failover 시 자동 라우팅으로 애플리케이션 투명성 제공 및 연결 재사용
Read Replica 스케일링 시나리오에서 RDS Proxy를 Reader Endpoint와 함께 사용할 때의 아키텍처 설계와, 읽기 부하 분산 전략을 설명해주세요.
Q. ECS Fargate와 EKS의 네트워킹 모델 차이를 설명하고, EKS의 CNI(Container Network Interface) 플러그인이 ENI와 보조 IP를 할당하는 방식을 설명해주세요. 또한 대규모 클러스터에서 IP 주소 고갈 문제를 해결하기 위한 방법과, Service Mesh(App Mesh 또는 Istio)를 도입할 때의 트레이드오프를 설명해주세요.
ECS Fargate는 각 태스크가 전용 ENI를 받아 VPC 네이티브 통신을 하며, EKS는 AWS VPC CNI를 사용해 노드의 ENI에서 보조 IP를 Pod에 할당하여 Pod가 VPC IP를 직접 사용합니다. EKS에서 인스턴스 타입에 따라 ENI와 IP 개수 제한이 있어 대규모 클러스터에서 IP 고갈이 발생할 수 있으며, 이는 IP Prefix Mode를 활성화하거나 별도 CIDR 블록을 추가하거나 Calico 같은 Overlay 네트워크로 해결할 수 있습니다. Service Mesh는 트래픽 관리, 보안, 관찰성을 향상시키지만 사이드카 프록시로 인한 레이턴시 증가와 리소스 오버헤드, 운영 복잡도 증가라는 트레이드오프가 있습니다. App Mesh는 AWS 네이티브 통합이 강점이고, Istio는 기능이 풍부하지만 학습 곡선이 가파릅니다.
- • Fargate는 태스크별 전용 ENI, EKS는 AWS VPC CNI로 Pod에 VPC IP 직접 할당
- • IP Prefix Mode, 추가 CIDR, Overlay 네트워크로 IP 고갈 문제 해결
- • Service Mesh는 트래픽 제어와 관찰성 향상하지만 레이턴시와 복잡도 증가
- • App Mesh는 AWS 통합 우수, Istio는 기능 풍부하나 운영 복잡
EKS 클러스터에서 Pod 간 통신 보안을 강화하기 위한 Network Policy 구현 방법과, Calico를 사용할 때 AWS 보안 그룹과의 관계를 설명해주세요.
Q. EventBridge와 SNS/SQS의 차이점을 설명하고, 각각의 메시지 라우팅 메커니즘과 적합한 사용 사례를 설명해주세요. 또한 이벤트 기반 마이크로서비스 아키텍처에서 멱등성(Idempotency) 보장 방법과, DLQ(Dead Letter Queue) 설계 시 고려해야 할 재처리 전략 및 모니터링 방안을 제시해주세요.
EventBridge는 스키마 레지스트리와 콘텐츠 기반 필터링을 제공하여 복잡한 이벤트 라우팅에 적합하고, 20개 이상의 AWS 서비스와 SaaS 통합을 지원합니다. SNS는 Pub/Sub 패턴의 간단한 팬아웃에 적합하며, SQS는 워크로드 디커플링과 버퍼링에 적합합니다. 멱등성은 DynamoDB의 조건부 쓰기나 Redis를 활용한 메시지 ID 추적으로 구현하며, 처리 완료 후에만 메시지를 삭제해야 합니다. DLQ는 재시도 횟수(보통 3-5회)를 설정하고, CloudWatch 알람으로 DLQ 메시지 수를 모니터링하며, Lambda를 통해 자동 재처리하거나 수동 검토 프로세스를 구축해야 합니다. 메시지에는 타임스탬프와 재시도 카운트를 포함하여 디버깅을 용이하게 합니다.
- • EventBridge는 콘텐츠 기반 필터링과 SaaS 통합 지원, SNS는 간단한 팬아웃, SQS는 디커플링
- • 멱등성은 DynamoDB 조건부 쓰기 또는 메시지 ID 추적으로 구현
- • DLQ는 재시도 횟수 제한 설정 및 CloudWatch 알람으로 모니터링
- • 메시지에 메타데이터(타임스탬프, 재시도 카운트) 포함하여 추적성 확보
순서 보장이 필요한 이벤트 처리 시나리오에서 SQS FIFO 큐의 제약사항과, EventBridge에서 순서를 보장하기 위한 아키텍처 패턴을 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!