Amazon SAP-C02: 마이그레이션 및 현대화 — 학습 가이드

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

다음의 일부입니다: AWS Solutions Architect Professional SAP-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

마이그레이션 전략 및 계획

효과적인 마이그레이션은 체계적인 검색(discovery), 종속성 매핑, 위험 기반 우선순위 지정에서 시작됩니다. AWS Application Discovery Service와 AWS Migration Hub를 사용하여 서버 인벤토리를 작성하고, 성능 지표를 수집하며, 애플리케이션 종속성을 시각화합니다. 여기에 에이전트 없는 네트워크 흐름 분석과 구성 관리 데이터를 보완하여 숨겨진 상태 저장(stateful) 연결을 찾습니다. 검색 결과를 랜딩 존(landing-zone) 결정으로 전환합니다. AWS Control Tower와 Organizations로 계정 전략을 선택하고, Transit Gateway로 네트워크 토폴로지를 정의하며, Compute Optimizer와 적정 규모(right-sizing) 가이드라인을 사용하여 대상 컴퓨팅 규모를 산정합니다. 전환(Cutover) 전략은 애플리케이션별로 선택해야 합니다. 작고 위험이 낮은 시스템에는 빅뱅(big-bang) 방식, 비즈니스에 중요한 제품군에는 단계적(phased) 또는 웨이브(wave-based) 방식, 사용자 영향을 최소화해야 하는 고객 대면 서비스에는 블루/그린(blue/green) 또는 카나리(canary) 방식을 사용합니다. 전환을 계획할 때는 데이터 동기화 시간, DNS TTL, 대역폭 제약, 규제 제약 등을 고려해야 합니다. 일반적인 함정으로는 데이터 전송 시간과 비용을 과소평가하거나, 리프트 앤 시프트(lift-and-shift)를 최종 상태로 간주하거나, 라이선스 이전 가능성을 소홀히 하거나, 롤백(rollback) 계획을 세우지 않는 것 등이 있습니다. 의사 결정 기준은 종종 비용과 운영 노력 및 복원력(resilience) 사이의 트레이드오프 관계에 있습니다. 관리형 서비스(RDS/Aurora, DocumentDB)는 OPEX 예측 가능성과 복원력을 높이지만 스키마 변경이 필요할 수 있습니다. 관리형 서비스로 리플랫포밍(replatforming)하면 마이그레이션 복잡성이 증가하는 대신 운영 부담을 줄일 수 있습니다.

리프트 앤 시프트 및 데이터 마이그레이션 도구

신속한 리호스팅(rehosting)을 위해 AWS Application Migration Service(MGN)는 VMware, Hyper-V, 물리적 서버에서 EC2로의 블록 수준 복제를 자동화하여 전환 시간을 최소화하고 OS 수준 구성을 보존합니다. 대용량 또는 오프라인 데이터 마이그레이션의 경우, 파일 및 POSIX/NFS 워크로드에는 AWS Snow Family 또는 DataSync가 필요할 수 있으며, Amazon S3 Transfer Acceleration과 Direct Connect는 객체 및 대량 전송을 가속화합니다. 데이터베이스 마이그레이션은 동종(homogeneous) 또는 이기종(heterogeneous) 마이그레이션을 위해 AWS Database Migration Service(DMS)를 사용하며, 구조적 변경이 필요할 때는 Schema Conversion Tool(SCT)과 함께 사용됩니다. DMS의 제한 사항에 유의해야 합니다. MongoDB 소스/타겟 동작에는 버전 및 기능 제약, 대용량 LOB 처리, CDC(변경 데이터 캡처) 중 발생할 수 있는 복제 지연(replication lag) 등이 있습니다. 데이터 무결성을 고려하여 아키텍처를 설계해야 합니다. 체크섬(checksum)으로 검증하고, 다운타임을 최소화하기 위해 전체 로드(full load) 후 CDC를 실행하며, 트래픽이 적은 시간에 전환을 준비합니다. 설계상의 트레이드오프는 속도와 충실도(fidelity)를 중심으로 이루어집니다. MGN 또는 리호스트는 애플리케이션 변경을 최소화하지만 레거시 운영 모델을 그대로 유지하게 됩니다. 반면 리플랫포밍은 장기적인 운영 부담을 줄이지만 리팩터링과 테스트가 필요합니다. 일반적인 함정으로는 엔드포인트 보안 소홀, 불충분한 사전 전환 검증, 클라우드 스토리지의 IOPS/처리량이 온프레미스와 동일하다고 가정하는 것 등이 있습니다.

현대화: 컨테이너, 서버리스 및 리팩터링 패턴

현대화 옵션은 컨테이너 오케스트레이션으로 리플랫포밍하는 것부터 서버리스로 완전히 리팩터링하는 것까지 다양합니다. 인프라 관리를 최소화하면서 컨테이너화된 배포를 신속하게 하려면 Amazon ECS on Fargate를, 이식성과 복잡한 오케스트레이션이 필요한 Kubernetes 네이티브 워크로드에는 Amazon EKS를 선택합니다. 이벤트 기반 마이크로서비스의 경우, AWS Lambda를 API Gateway, EventBridge, Step Functions와 결합하여 운영 오버헤드를 줄이고 요청별로 확장할 수 있습니다. 데이터 서비스는 관리형 백엔드로 전환해야 합니다. 관계형 데이터베이스에는 Amazon RDS/Aurora, NoSQL/문서 저장소에는 Amazon DynamoDB 또는 Amazon DocumentDB, 지연 시간이 짧은 캐싱에는 ElastiCache를 사용합니다. 트레이드오프는 운영 복잡성과 비용 및 성능 예측 가능성 사이에서 결정됩니다. EKS는 더 높은 운영 비용으로 제어와 이식성을 제공하고, Fargate는 운영을 단순화하지만 대규모 환경에서는 더 비쌀 수 있습니다. 서버리스는 변동이 심한(spiky) 워크로드에 비용 효율적이지만 콜드 스타트(cold start), 동시성 제한, 관찰 가능성(observability) 문제를 야기합니다. 아키텍트가 빠지기 쉬운 일반적인 함정으로는 상태 저장 컴포넌트를 분해하지 않고 모놀리스(monolith)를 컨테이너로 그대로 옮기는 것, 배포를 관리하기 위한 CI/CD 및 IaC(CloudFormation, CDK, Terraform)가 불충분한 것, 태스크 역할(task role) 및 Lambda 실행 역할에 대한 IAM 최소 권한 원칙을 무시하는 것 등이 있습니다.

컷오버, 하이브리드 네트워킹 및 마이그레이션 후 운영

성공적인 컷오버는 하이브리드 네트워킹 및 자격 증명 통합, 그리고 견고한 관측 가능성 및 롤백 계획에 달려 있습니다. VPC와 온프레미스 Active Directory 간의 하이브리드 DNS 확인을 위해서는 Amazon Route 53 Resolver 인바운드 및 아웃바운드 엔드포인트를 배포하거나, EC2 Windows 인스턴스의 도메인 조인을 위해 AD Connector/Managed Microsoft AD를 사용합니다. 네트워크 연결 옵션으로는 확장 가능한 다중 계정 토폴로지를 위한 AWS Direct Connect와 Transit Gateway가 있습니다. 예측 가능한 대역폭과 낮은 이그레스 비용이 중요할 때는 Direct Connect를 선택하고, 다대다(many-to-many) VPC 및 온프레미스 연결을 단순화하려면 Transit Gateway를 선택합니다. 마이그레이션 후 운영은 모니터링(CloudWatch, X-Ray), 중앙 집중식 로깅 및 분석(CloudWatch Logs, 중앙 계정으로 보내는 Kinesis Firehose), 백업 및 리전 간 스냅샷 전략(AWS Backup, 리전 간 스냅샷 복사), 그리고 AWS Config 및 IAM 경계 정책을 통해 시행되는 보안 기준선을 포함해야 합니다. 일반적인 함정으로는 컷오버 전에 DNS TTL을 낮추지 않거나, 대규모 AD 통합을 테스트하지 않거나, Transit Gateway 대역폭을 부족하게 프로비저닝하거나 라우팅 전파 구성을 누락하는 것 등이 있습니다. 여기서의 결정 기준은 복원력 대 비용입니다. 액티브-액티브 다중 리전 설계는 가용성을 높이지만 복제 비용과 복잡성을 증가시키고, 액티브-패시브는 비용을 단순화하지만 RTO를 길게 만듭니다.

실용적인 문제: 사용 사례 시나리오

시나리오: 글로벌 연구 기업인 Acme Energy는 AWS Organizations 하에 여러 계정이 있는 기존 AWS 환경과 프라이빗 Direct Connect 링크로 연결된 온프레미스 데이터 센터를 보유하고 있습니다. 이들은 Linux 시뮬레이션 서버 제품군, a MongoDB 복제 세트, 야간 이미지 파일 공유를 최소한의 중단으로 AWS로 마이그레이션해야 합니다.

과제: 시뮬레이션을 위한 컷오버 다운타임을 2시간 이내로 보장하고 MongoDB 복제 세트 및 야간 이미지 수집에 대한 데이터 손실을 없애면서, 운영 부담을 줄이고 탄력적인 확장을 활성화해야 합니다.

권장 접근 방식:

AWS Application Migration Service(MGN) 에이전트를 배포하여 시뮬레이션 서버를 전용 마이그레이션 계정으로 복제합니다. 낮은 RPO로 지속적인 블록 수준 복제를 구성하고, 중요하지 않은 노드부터 단계적 컷오버 웨이브를 예약합니다.
MongoDB를 소스로, Amazon DocumentDB(MongoDB 호환)를 대상으로 하여 AWS DMS를 사용하고, 전체 로드와 CDC를 실행한 후, 체크섬과 병렬 읽기 복제본을 사용하여 문서 수준의 일관성을 검증합니다.
AWS DataSync를 사용하여 야간 이미지를 S3 수명 주기 규칙이 적용된 Amazon S3 버킷으로 마이그레이션합니다. NFS 시맨틱이 필요한 POSIX 기반 워크로드를 위해 Amazon FSx for Lustre 또는 Amazon EFS를 프로비저닝하고, 최대 부하 상태에서 읽기/쓰기 성능을 테스트합니다.
낮춰진 Route 53 TTL, 블루/그린 트래픽 전환을 위한 Route 53 가중치 기반 라우팅으로 컷오버를 오케스트레이션하고, 성공적인 스모크 테스트 후 DNS 스왑을 완료합니다. IAM 역할을 강제하고 CloudWatch X-Ray, 중앙 집중식 CloudWatch Logs, 스냅샷을 위한 AWS Backup을 활성화합니다.

근거: 이 접근 방식은 단계적 복제 및 CDC를 통해 다운타임을 최소화하고, 관리형 서비스(DocumentDB, S3, DataSync)를 채택하여 운영 오버헤드를 줄이며, 최종 컷오버 전에 정확성을 검증할 수 있는 안전한 롤백 지점과 관측 가능성을 제공합니다. 이는 마이그레이션 및 현대화를 위한 전문 아키텍처 모범 사례와 일치합니다.

← 데이터베이스 및 분석 · 모든 도메인 · 회복탄력성 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →