AWS 미드레벨 시스템 설계 면접
새 면접Q. 마이크로서비스 아키텍처에서 여러 서비스에 걸친 분산 트랜잭션을 추적해야 합니다. CloudWatch Logs Insights와 X-Ray의 차이점을 설명하고, 각각 어떤 상황에서 사용해야 하는지 설명해주세요. 또한 두 서비스를 함께 사용하여 종합적인 관찰성(Observability)을 구현하는 방법을 제시해주세요.
CloudWatch Logs Insights는 로그 데이터를 쿼리하고 집계하는 서비스로, 비즈니스 메트릭 추출이나 에러 패턴 분석에 적합합니다. X-Ray는 분산 트레이싱 서비스로, 요청이 여러 서비스를 거치는 경로와 각 구간의 지연시간을 시각화하여 성능 병목을 찾는 데 특화되어 있습니다. X-Ray로 전체 트랜잭션 흐름과 성능을 파악하고, CloudWatch Logs로 각 서비스의 상세 로그를 분석하며, ServiceLens를 통해 두 데이터를 통합하여 서비스 맵과 트레이스를 함께 확인할 수 있습니다. X-Ray SDK를 애플리케이션에 통합하여 Trace ID를 로그에 포함시키면 특정 요청의 전체 여정을 추적할 수 있습니다.
- • CloudWatch Logs Insights는 로그 쿼리 및 집계, X-Ray는 분산 트레이싱 및 성능 분석에 특화
- • X-Ray는 서비스 간 의존성과 지연시간을 시각화하여 병목 지점 파악 가능
- • ServiceLens로 두 서비스 통합, Trace ID를 로그에 포함하여 end-to-end 추적 구현
X-Ray의 샘플링 레이트를 조정할 때 고려해야 할 요소는 무엇이며, 트래픽이 많은 프로덕션 환경에서 비용과 정확도 사이의 균형을 어떻게 맞출 수 있나요?
Q. 금융 서비스의 재해 복구(DR) 전략을 수립해야 합니다. AWS Backup, RDS Automated Backup, Snapshot을 활용한 백업 전략을 설계하고, RPO(Recovery Point Objective) 15분, RTO(Recovery Time Objective) 1시간을 만족하는 멀티 리전 DR 아키텍처를 제시해주세요. 각 백업 방식의 복구 시간과 비용을 비교하여 설명해주세요.
RPO 15분을 만족하려면 RDS의 자동 백업과 트랜잭션 로그를 활용하여 Point-in-Time Recovery를 구성하고, DynamoDB의 경우 Point-in-Time Recovery를 활성화합니다. RTO 1시간을 위해서는 Pilot Light 또는 Warm Standby 패턴을 사용하며, 주 리전의 RDS를 Cross-Region Read Replica로 DR 리전에 복제합니다. AWS Backup으로 중앙 집중식 백업 정책을 관리하고, S3 Cross-Region Replication으로 객체 스토리지를 복제하며, Route53 Health Check와 Failover 라우팅 정책으로 자동 페일오버를 구현합니다. Snapshot 기반 복구는 비용이 저렴하지만 RTO가 수 시간이므로, Read Replica 승격 방식(수 분)을 메인으로, Snapshot을 보조 수단으로 활용합니다.
- • RDS PITR과 Cross-Region Read Replica로 RPO 15분, RTO 1시간 달성
- • AWS Backup으로 중앙 집중식 백업 관리, S3 CRR로 객체 복제
- • Warm Standby 패턴 사용, Route53 Failover로 자동 페일오버 구현
- • Snapshot 복구는 저렴하나 RTO 길어 Read Replica 승격을 주 전략으로 사용
멀티 리전 DR 환경에서 데이터 정합성을 검증하는 방법과, 정기적인 DR 훈련(Drill)을 자동화하는 전략을 어떻게 구현하시겠습니까?
Q. RESTful API를 설계할 때 멱등성(Idempotency)이 중요한 이유를 설명하고, 결제 API처럼 중복 실행되면 안 되는 작업에서 멱등성을 보장하는 구현 방법을 제시해주세요. DynamoDB의 Conditional Write를 활용한 방법을 포함해주세요.
멱등성은 동일한 요청을 여러 번 실행해도 결과가 같음을 보장하는 속성으로, 네트워크 재시도나 클라이언트 중복 요청 시 데이터 불일치를 방지합니다. 결제 API에서는 클라이언트가 생성한 Idempotency Key(UUID)를 요청 헤더에 포함시키고, DynamoDB에 이 키를 저장합니다. DynamoDB의 Conditional Write(condition_expression: attribute_not_exists)를 사용하여 동일 키가 이미 존재하면 저장을 거부하고, 기존 결과를 반환합니다. TTL을 설정하여 일정 시간 후 키를 자동 삭제하고, 트랜잭션 상태(pending, completed, failed)를 함께 저장하여 진행 중인 요청은 대기하도록 구현합니다.
- • 멱등성은 중복 요청 시 데이터 불일치 방지를 위해 필수
- • 클라이언트 생성 Idempotency Key를 요청에 포함
- • DynamoDB Conditional Write로 중복 실행 방지, 기존 결과 반환
- • TTL로 키 자동 삭제, 트랜잭션 상태 관리로 진행 중 요청 처리
멱등성 키 저장소로 DynamoDB 대신 ElastiCache Redis를 사용할 때의 장단점은 무엇이며, 어떤 상황에서 Redis가 더 적합할까요?
Q. ECS에서 Blue/Green 배포를 구현하려고 합니다. CodeDeploy를 사용한 ECS Blue/Green 배포의 동작 원리를 설명하고, 배포 중 트래픽 전환 시점에서 발생할 수 있는 세션 유실 문제를 해결하는 방법을 제시해주세요. Target Group과 ALB Listener Rule이 어떻게 활용되는지 포함해주세요.
ECS Blue/Green 배포는 두 개의 Target Group(Blue, Green)을 생성하고, CodeDeploy가 새 태스크를 Green Target Group에 배포한 후 Health Check가 통과하면 ALB Listener의 트래픽을 전환합니다. 배포 시 Listener Rule이 Green Target Group을 가리키도록 변경되며, 기존 Blue 태스크는 설정된 시간(Termination Wait Time) 동안 유지되어 진행 중인 요청을 완료합니다. 세션 유실 방지를 위해 ElastiCache나 DynamoDB 기반 외부 세션 저장소를 사용하고, ALB의 Connection Draining을 적절히 설정하며, Canary 또는 Linear 배포 전략으로 점진적 트래픽 전환을 구현합니다. 애플리케이션은 Graceful Shutdown을 구현하여 SIGTERM 신호 수신 시 새 요청을 거부하고 기존 요청만 처리합니다.
- • 두 개의 Target Group 사용, CodeDeploy가 ALB Listener Rule을 전환하여 트래픽 이동
- • 외부 세션 저장소(ElastiCache, DynamoDB)로 세션 유실 방지
- • Connection Draining과 Termination Wait Time으로 진행 중 요청 보호
- • Canary/Linear 배포로 점진적 전환, Graceful Shutdown 구현 필수
ECS Blue/Green 배포 중 자동 롤백이 트리거되는 조건은 무엇이며, CloudWatch Alarm을 활용한 커스텀 롤백 전략을 어떻게 구성할 수 있나요?
Q. 월 AWS 비용이 급증하는 상황에서 비용 최적화 전략을 수립해야 합니다. Cost Explorer, Trusted Advisor, Compute Optimizer를 활용하여 비용 분석 및 최적화를 수행하는 체계적인 접근 방법을 제시하고, 각 서비스가 제공하는 인사이트의 차이점을 설명해주세요. 태그 기반 비용 할당 전략도 포함해주세요.
Cost Explorer로 서비스별, 리전별, 태그별 비용 추세를 분석하여 비용 증가 원인을 파악하고, 예약 인스턴스 및 Savings Plans 권장 사항을 확인합니다. Trusted Advisor는 유휴 리소스(미사용 EBS, Elastic IP), 과다 프로비저닝된 인스턴스, 보안 취약점을 점검하여 즉시 실행 가능한 권장 사항을 제공합니다. Compute Optimizer는 EC2, Lambda, EBS의 실제 사용 패턴을 ML로 분석하여 적정 크기 조정(Right-sizing) 권장 사항을 제공합니다. 비용 할당을 위해 Environment, Project, Owner 태그를 모든 리소스에 적용하고, Cost Allocation Tags를 활성화하여 팀별 비용을 추적하며, AWS Budgets으로 임계값 알림을 설정합니다.
- • Cost Explorer로 비용 추세 분석 및 RI/Savings Plans 권장 사항 확인
- • Trusted Advisor로 유휴 리소스 및 과다 프로비저닝 탐지
- • Compute Optimizer로 ML 기반 Right-sizing 권장 사항 확인
- • 태그 기반 비용 할당으로 팀별 비용 추적, AWS Budgets로 알림 설정
Savings Plans와 Reserved Instances의 차이점을 설명하고, 워크로드 특성에 따라 어떤 것을 선택해야 하는지 의사결정 기준을 제시해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!