AWS 미드레벨 시스템 설계 면접
새 면접Q. EKS 클러스터에서 Pod가 AWS 리소스(S3, DynamoDB 등)에 접근해야 하는 상황입니다. IRSA(IAM Roles for Service Accounts)의 동작 원리를 설명하고, 기존의 Instance Profile 방식과 비교하여 보안 및 권한 관리 측면에서 어떤 장점이 있는지 설명해주세요.
IRSA는 Kubernetes Service Account와 IAM Role을 매핑하여 Pod 단위로 세밀한 권한을 부여하는 메커니즘입니다. EKS는 OIDC Provider를 통해 Service Account Token을 검증하고, 해당 토큰으로 STS AssumeRoleWithWebIdentity를 호출하여 임시 자격증명을 발급받습니다. Instance Profile 방식은 노드의 모든 Pod가 동일한 권한을 공유하지만, IRSA는 Pod별로 최소 권한 원칙을 적용할 수 있어 보안이 강화됩니다. 또한 권한 변경 시 인스턴스 재시작 없이 Service Account만 수정하면 되어 운영 효율성이 높습니다.
- • OIDC Provider를 통한 Service Account Token 검증
- • STS AssumeRoleWithWebIdentity로 임시 자격증명 발급
- • Pod 단위 세밀한 권한 관리로 최소 권한 원칙 적용
- • Instance Profile 대비 보안 및 운영 효율성 향상
IRSA 구성 시 Service Account Annotation과 Pod Spec에 필요한 설정 항목은 무엇이며, 멀티 테넌트 환경에서 네임스페이스별로 권한을 격리하는 전략을 어떻게 수립하시겠습니까?
Q. 온프레미스 Oracle 데이터베이스를 Aurora PostgreSQL로 마이그레이션하는 프로젝트를 진행 중입니다. DMS(Database Migration Service)를 사용할 때 Full Load와 CDC(Change Data Capture) 단계에서 발생할 수 있는 성능 병목 지점을 각각 설명하고, 다운타임을 최소화하면서 데이터 정합성을 보장하는 마이그레이션 전략을 제시해주세요.
Full Load 단계에서는 대량 데이터 전송으로 인한 네트워크 대역폭 부족, 타겟 DB의 쓰기 처리 능력 한계, LOB 데이터 처리 지연이 주요 병목입니다. CDC 단계에서는 소스 DB의 트랜잭션 로그 처리 지연, 복제 지연(Replication Lag), 타겟 DB의 인덱스 업데이트 오버헤드가 문제가 됩니다. 다운타임 최소화를 위해 Full Load 시 병렬 처리를 위한 테이블 파티셔닝, CDC 시작 전 타겟 DB 인덱스 비활성화, 애플리케이션 읽기 트래픽을 먼저 타겟으로 전환 후 쓰기 트래픽 전환하는 단계적 컷오버 전략을 사용합니다. 데이터 정합성은 DMS의 Validation 기능과 체크섬 비교, 그리고 애플리케이션 레벨의 이중 쓰기(Dual Write) 검증으로 보장합니다.
- • Full Load 시 네트워크/쓰기 처리 능력/LOB 처리가 병목
- • CDC 시 트랜잭션 로그 처리/복제 지연/인덱스 오버헤드 발생
- • 병렬 처리, 인덱스 최적화, 단계적 컷오버로 다운타임 최소화
- • Validation 기능과 이중 쓰기 검증으로 데이터 정합성 보장
마이그레이션 중 소스와 타겟 간 스키마 차이(예: Oracle의 SEQUENCE를 PostgreSQL의 SERIAL로 변환)를 처리하는 방법과, 롤백 계획을 어떻게 수립하시겠습니까?
Q. 실시간 채팅 애플리케이션을 API Gateway WebSocket API와 Lambda로 구축하려고 합니다. 연결 관리($connect, $disconnect, $default 라우트)를 어떻게 구현해야 하는지 설명하고, 수만 명의 동시 접속자에게 메시지를 브로드캐스트할 때 발생할 수 있는 Lambda 동시성 제한 문제와 해결 방법을 제시해주세요.
$connect 라우트에서는 connectionId를 DynamoDB에 저장하여 연결 상태를 관리하고, $disconnect에서는 해당 레코드를 삭제합니다. $default 라우트는 클라이언트로부터 받은 메시지를 처리하여 다른 연결자들에게 전송합니다. 브로드캐스트 시 Lambda가 모든 connectionId를 순회하며 API Gateway Management API로 메시지를 전송하는데, 동시성 제한으로 인해 throttling이 발생할 수 있습니다. 이를 해결하기 위해 SQS를 중간에 두어 메시지를 큐잉하고, 여러 Lambda 함수가 병렬로 처리하도록 Fan-out 패턴을 적용하거나, 예약된 동시성(Reserved Concurrency)을 설정하여 안정적인 처리량을 보장합니다. 또한 DynamoDB의 connectionId를 파티션 키로 샤딩하여 읽기 성능을 최적화합니다.
- • DynamoDB로 connectionId 기반 연결 상태 관리
- • API Gateway Management API로 메시지 전송
- • SQS + Fan-out 패턴으로 동시성 제한 해결
- • 예약된 동시성 설정과 DynamoDB 샤딩으로 성능 최적화
WebSocket 연결이 유휴 상태로 장시간 유지될 때 비용을 최적화하는 방법과, 특정 채팅방의 사용자들에게만 메시지를 전송하는 룸 기반 메시징을 어떻게 구현하시겠습니까?
Q. 데이터 분석 워크로드를 위해 EMR 클러스터를 운영 중입니다. Spot Instance, Reserved Instance, On-Demand Instance를 조합하여 비용을 최적화하면서도 작업 안정성을 보장하는 클러스터 구성 전략을 제시하고, Spot Instance 중단 시 작업 실패를 방지하기 위한 체크포인팅 및 재시도 메커니즘을 설명해주세요.
Master 노드는 클러스터 안정성을 위해 On-Demand 또는 Reserved Instance로 구성하고, Core 노드는 HDFS 데이터를 저장하므로 Reserved Instance로 안정성을 확보합니다. Task 노드는 컴퓨팅만 담당하므로 Spot Instance를 적극 활용하여 비용을 절감합니다. Spot Fleet을 사용해 여러 인스턴스 타입과 가용 영역을 지정하여 중단 위험을 분산시킵니다. 작업 안정성을 위해 S3에 중간 결과를 체크포인팅하고, Spark의 Dynamic Allocation과 External Shuffle Service를 활성화하여 Spot 중단 시에도 작업을 재개할 수 있도록 합니다. EMR Managed Scaling을 활용하면 워크로드에 따라 자동으로 Task 노드를 추가/제거하여 비용 효율성을 극대화할 수 있습니다.
- • Master는 On-Demand, Core는 Reserved, Task는 Spot으로 역할별 차등 적용
- • Spot Fleet으로 여러 인스턴스 타입과 AZ 지정하여 중단 위험 분산
- • S3 체크포인팅과 External Shuffle Service로 작업 재개 가능
- • EMR Managed Scaling으로 동적 확장 및 비용 최적화
Spot Instance 중단 알림(2분 전 경고)을 활용하여 Graceful Shutdown을 구현하는 방법과, YARN의 Node Decommissioning을 통해 데이터 손실 없이 노드를 제거하는 프로세스를 설명해주세요.
Q. 금융 서비스를 위한 AWS 인프라에서 모든 데이터는 암호화되어야 하고, 암호화 키는 정기적으로 로테이션되어야 합니다. KMS(Key Management Service)의 CMK(Customer Master Key) 유형인 AWS Managed Key와 Customer Managed Key의 차이점을 설명하고, 자동 키 로테이션, 키 정책(Key Policy), 감사 로깅을 포함한 종합적인 키 관리 전략을 제시해주세요.
AWS Managed Key는 AWS 서비스가 자동으로 생성하고 관리하는 키로 3년마다 자동 로테이션되지만, 키 정책 수정이나 삭제가 불가능합니다. Customer Managed Key는 사용자가 직접 생성하고 관리하며, 키 정책 커스터마이징, 수동/자동 로테이션 설정, 삭제 예약이 가능합니다. 금융 서비스에서는 세밀한 권한 관리를 위해 Customer Managed Key를 사용하고, 1년 주기 자동 로테이션을 활성화합니다. 키 정책에서는 최소 권한 원칙에 따라 특정 IAM Role만 암호화/복호화 권한을 부여하고, CloudTrail로 모든 키 사용 내역을 로깅하여 CloudWatch Logs Insights로 분석합니다. 또한 키 삭제 시 7~30일의 대기 기간을 설정하여 실수로 인한 데이터 손실을 방지합니다.
- • Customer Managed Key로 세밀한 권한 관리 및 로테이션 제어
- • 자동 키 로테이션 활성화로 보안 강화
- • 키 정책으로 최소 권한 원칙 적용
- • CloudTrail 로깅과 키 삭제 대기 기간으로 감사 및 안전성 확보
멀티 리전 환경에서 동일한 데이터를 여러 리전에 복제할 때 KMS Multi-Region Key를 사용하는 것과 각 리전에 별도 키를 생성하는 것의 장단점을 비교하고, 재해 복구 시나리오에서 어떤 접근이 더 적합한지 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!