안녕하세요! 넥스트클라우드의 SA 손유림입니다. 😊
어려운 문제 앞에서 주눅 들지 마세요. 한 번에 안 되면 두 번, 세 번 도전하면 돼요!
문제는 세 가지 단계를 거치며 풀어 나갈 거예요.
1. 문제의 요구사항 분석하기
2. 관련 AWS 서비스 생각하기
3. 선택지 분석하기
바로 문제 풀이 해볼까요?
문제1
회사는 여러 AWS 리전 및 계정에 걸쳐 리소스를 보유하고 있습니다. 새로 고용된 솔루션 설계자는 이전 직원이 리소스 인벤토리에 대한 세부 정보를 제공하지 않은 것을 발견했습니다. 솔루션설계자는 모든 계정에서 다양한 워크로드의 관계 세부 정보를 구축하고 매핑해야 합니다. 운영상 가장 효율적인 방식으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
선택지
A. AWS Systems Manager Inventory를 사용하여 상세 보기 보고서에서 맵 보기를 생성합니다.
B. AWS Step Functions를 사용하여 워크로드 세부 정보를 수집합니다. 워크로드의 아키텍처 다이어그램을 수동으로 작성합니다.
C. Workload Discovery on AWS를 사용하여 워크로드의 아키텍처 다이어그램을 생성합니다.
D. AWS X-Ray를 사용하여 워크로드 세부 정보를 봅니다. 관계를 사용하여 아키텍처 다이어그램을 구축합니다.
풀이
Workload Discovery on AWS는 여러 AWS 계정과 리전에 분산된 리소스를 자동으로 검색하고, 리소스 간 관계를 분석하여 아키텍처 다이어그램을 자동 생성하는 솔루션입니다. 별도의 에이전트 설치나 수동 작업 없이 기존 AWS 환경을 시각화할 수 있어 운영 효율성이 가장 높습니다.
정답 : C
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- AWS 리전 및 계정에 걸쳐 리소스를 보유
- 모든 계정에서 다양한 워크로드의 관계 세부 정보를 구축 및 매핑
2. 관련 AWS 서비스 생각하기
AWS Systems Manager Inventory는 관리형 인스턴스에 대한 메타데이터만 수집하고 보고할 수 있습니다. 워크로드 전체의 관계를 파악하기에는 부족합니다.
AWS Step Functions는 분산 애플리케이션을 쉽게 구축할 수 있는 서버리스 오케스트레이션 서비스입니다. 워크로드 세부 정보를 수집할 수 있지만, 워크로드 아키텍처 다이어그램을 자동으로 생성할 수는 없습니다.
Workload Discovery on AWS는 기존 데이터 센터의 애플리케이션 워크로드를 검색하고 매핑하여 AWS 마이그레이션을 지원합니다. 모든 AWS 계정과 리전에 분산된 워크로드의 관계를 자동으로 매핑하고 아키텍처 다이어그램을 생성할 수 있습니다.
AWS X-Ray는 분산 애플리케이션의 성능 데이터를 수집하는 서비스입니다. 워크로드 아키텍처 전체를 자동으로 매핑하고 다이어그램을 생성할 수는 없습니다.
3. 선택지 분석하기
A. AWS Systems Manager Inventory를 사용하여 상세 보기 보고서에서 맵 보기를 생성합니다.
→ Systems Manager Inventory는 EC2 인스턴스의 소프트웨어 및 구성 정보만 수집하며, 워크로드 간 관계나 아키텍처 다이어그램을 자동 생성하지 않습니다.
B. AWS Step Functions를 사용하여 워크로드 세부 정보를 수집합니다. 워크로드의 아키텍처 다이어그램을 수동으로 작성합니다.
→ Step Functions는 워크플로우 오케스트레이션 서비스로 리소스 검색 기능이 없으며, 다이어그램을 수동으로 작성해야 하므로 운영 효율성이 낮습니다.
C. Workload Discovery on AWS를 사용하여 워크로드의 아키텍처 다이어그램을 생성합니다.
→ Workload Discovery on AWS는 다중 계정/리전의 리소스를 자동 검색하고 관계를 매핑하여 아키텍처 다이어그램을 생성하므로 가장 운영 효율적입니다.
D. AWS X-Ray를 사용하여 워크로드 세부 정보를 봅니다. 관계를 사용하여 아키텍처 다이어그램을 구축합니다.
→ X-Ray는 애플리케이션 추적 서비스로 코드에 계측이 필요하며, 기존 인프라 전체의 리소스 인벤토리나 관계 매핑에는 적합하지 않습니다.
이어서 다음 문제입니다.
문제2
회사에는 트랜잭션 데이터를 처리하는 온프레미스 MySQL 데이터베이스가 있습니다. 회사는 데이터베이스를 AWS 클라우드로 마이그레이션하고 있습니다. 마이그레이션된 데이터베이스는 데이터베이스를 사용하는 회사의 애플리케이션과 호환성을 유지해야 합니다. 마이그레이션된 데이터베이스는 또한 수요가 증가하는 기간 동안 자동으로 확장되어야 합니다. 이러한 요구 사항을 충족하는 마이그레이션 솔루션은 무엇입니까?
선택지
A. 기본 MySQL 도구를 사용하여 데이터베이스를 MySQL용 Amazon RDS로 마이그레이션합니다. 탄력적 스토리지 확장을 구성합니다.
B. mysqldump 유틸리티를 사용하여 데이터베이스를 Amazon Redshift로 마이그레이션합니다. Amazon Redshift 클러스터에 대해 Auto Scaling을 켭니다.
C. AWS Database Migration Service(AWS DMS)를 사용하여 데이터베이스를 Amazon Aurora로 마이그레이션합니다. Aurora Auto Scaling을 켭니다.
D. AWS Database Migration Service(AWS DMS)를 사용하여 데이터베이스를 Amazon DynamoDB로 마이그레이션합니다. Auto Scaling 정책을 구성합니다.
풀이
데이터베이스 마이그레이션 및 자동 확장이 필요한 이 요구사항을 가장 잘 충족하는 솔루션은 AWS Database Migration Service(DMS)를 사용하여 데이터베이스를 Amazon Aurora로 마이그레이션하고, Aurora Auto Scaling을 활성화하는 것입니다. Aurora는 MySQL 및 PostgreSQL과 호환되며, Auto Scaling으로 수요에 따라 자동으로 확장됩니다.
정답 : C
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- MySQL 데이터베이스를 AWS 클라우드로 마이그레이션
- 애플리케이션과의 호환성 유지
- 수요 증가 시 자동 확장
2. 관련 AWS 서비스 생각하기
AWS Database Migration Service(DMS)는 데이터베이스를 AWS 클라우드로 마이그레이션할 수 있는 안전하고 완전관리형 서비스입니다. 소스 데이터베이스의 유형과 상관없이 대부분의 상업용 및 오픈 소스 데이터베이스로 마이그레이션할 수 있습니다.
Amazon RDS는 관계형 데이터베이스(MySQL, PostgreSQL 등)를 클라우드에서 쉽게 설치하고 운영할 수 있는 관리형 서비스입니다. 장애에 복원력이 있고 자동 백업, 읽기 전용 복제본 등의 기능을 제공합니다.
Amazon Aurora는 RDS와 호환되며, MySQL 및 PostgreSQL 호환 에디션을 제공합니다. Aurora Auto Scaling을 활성화하면 수요에 따라 자동으로 확장되어 워크로드 변화에 대응할 수 있습니다. 기존 애플리케이션과의 호환성도 유지됩니다.
Amazon Redshift는 완전관리형 데이터 웨어하우스 서비스로 관계형 데이터베이스와 호환되지 않습니다.
Amazon DynamoDB는 NoSQL 키-값 및 문서 데이터베이스 서비스입니다. 관계형 데이터베이스와 호환되지 않습니다.
3. 선택지 분석하기
A. 기본 MySQL 도구를 사용하여 데이터베이스를 MySQL용 Amazon RDS로 마이그레이션합니다. 탄력적 스토리지 확장을 구성합니다.
→ RDS MySQL로 마이그레이션하고 탄력적 스토리지 확장을 구성하면 스토리지만 자동 확장되므로 요구사항을 완전히 충족하지 못합니다.
B. mysqldump 유틸리티를 사용하여 데이터베이스를 Amazon Redshift로 마이그레이션합니다. Amazon Redshift 클러스터에 대해 Auto Scaling을 켭니다.
→ Redshift로 마이그레이션하면 애플리케이션과의 호환성이 깨지므로 적절하지 않습니다.
C. AWS Database Migration Service(AWS DMS)를 사용하여 데이터베이스를 Amazon Aurora로 마이그레이션합니다. Aurora Auto Scaling을 켭니다.
→ DMS를 사용하여 Aurora로 마이그레이션하고 Auto Scaling을 활성화하면 모든 요구사항을 만족합니다.
D. AWS Database Migration Service(AWS DMS)를 사용하여 데이터베이스를 Amazon DynamoDB로 마이그레이션합니다. Auto Scaling 정책을 구성합니다.
→ DynamoDB는 관계형 데이터베이스와 호환되지 않으므로 적절하지 않습니다.
마지막 문제 살펴볼게요.
문제3
회사에 여행 발권을 위한 웹 애플리케이션이 있습니다. 이 애플리케이션은 북미 지역의 단일 데이터 센터에서 실행되는 데이터베이스를 기반으로 합니다. 회사는 글로벌 사용자 기반에 서비스 를 제공하기 위해 응용 프로그램을 확장하려고 합니다. 회사는 애플리케이션을 여러 AWS 리전에 배포해야 합니다. 예약 데이터베이스 업데이트 시 평균 대기 시간은 1초 미만이어야 합니다. 이 회사는 여러 지역에 걸쳐 웹 플랫폼을 별도로 배포하려고 합니다. 그러나 회사는 전 세계적으로 일관된 단일 기본 예약 데이터베이스를 유지해야 합니다. 솔루션 설계자는 이러한 요구 사항을 충족하기 위해 어떤 솔루션을 권장해야 합니까?
선택지
A. Amazon DynamoDB를 사용하도록 애플리케이션을 변환합니다. 중앙 예약 테이블에 전역 테이블을 사용합니다. 각 지역 배포에서 올바른 지역 엔드포인트를 사용합니다.
B. 데이터베이스를 Amazon Aurora MySQL 데이터베이스로 마이그레이션합니다. 각 지역에 Aurora 읽기 전용 복제본을 배포합니다. 데이터베이스에 액세스하려면 각 지역 배포에서 올 바른 지역 엔드포인트를 사용하세요.
C. 데이터베이스를 Amazon RDS for MySQL 데이터베이스로 마이그레이션합니다. 각 리전에 MySQL 읽기 전용 복제본을 배포합니다. 데이터베이스에 액세스하려면 각 지역 배포에서 올바른 지역 엔드포인트를 사용하세요.
D. 애플리케이션을 Amazon Aurora Serverless 데이터베이스로 마이그레이션합니다. 각 지역에 데이터베이스 인스턴스를 배포합니다. 각 지역 배포에서 올바른 지역 엔드포인트를 사용하여 데이터베이스에 액세스합니다. AWS Lambda 함수를 사용하여 각 리전에서 이벤트 스트림을 처리하여 데이터베이스를 동기화합니다.
풀이
DynamoDB 글로벌 테이블은 여러 리전에 걸쳐 다중 활성(multi-active) 복제를 제공하여 각 리전에서 읽기와 쓰기가 모두 가능합니다. 한 리전의 업데이트가 다른 리전으로 복제되는 시간이 일반적으로 1초 이내이며, 각 리전의 로컬 엔드포인트를 사용하므로 낮은 지연 시간을 보장합니다.
정답 : A
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 예약 데이터베이스를 여러 지역에서 글로벌하게 액세스
- 데이터베이스 액세스 시 평균 대기 시간 1초 미만
- 전 세계에서 일관된 단일 예약 데이터베이스 유지
2. 관련 AWS 서비스 생각하기
Amazon DynamoDB는 키-값 및 문서 데이터베이스로, 밀리초 단위의 지연 시간과 거의 무한한 확장성을 제공합니다. DynamoDB 글로벌 테이블을 사용하면 다중 마스터 복제본 없이도 전 세계 리전에 걸쳐 데이터를 자동으로 복제할 수 있습니다. 읽기와 쓰기 작업은 로컬 복제본에 대해 수행되므로 빠른 성능을 제공합니다.
Amazon Aurora는 MySQL 및 PostgreSQL 호환 관계형 데이터베이스 서비스입니다. 여러 리전에 읽기 전용 복제본을 배포할 수 있지만, 쓰기 작업은 한 리전의 단일 마스터 인스턴스에서만 가능하므로 전 세계에 걸쳐 일관된 단일 데이터베이스를 유지하기 어렵습니다.
Amazon RDS는 여러 데이터베이스 엔진(MySQL, PostgreSQL 등)을 제공하는 관리형 관계형 데이터베이스 서비스입니다. 마찬가지로 여러 리전에 읽기 전용 복제본을 배포할 수 있지만, 쓰기 작업은 한 마스터 인스턴스에서만 가능합니다.
Amazon Aurora Serverless를 사용하더라도 여러 리전에 걸쳐 일관된 단일 데이터베이스를 유지하기에는 적절하지 않습니다. 각 리전에 별도의 데이터베이스 인스턴스를 배포해야 하며, Lambda 함수를 사용해 동기화하는 것은 운영 부담이 크고 대기 시간 요구사항을 만족하기 어려울 수 있습니다.
3. 선택지 분석하기
A. Amazon DynamoDB를 사용하도록 애플리케이션을 변환합니다. 중앙 예약 테이블에 전역 테이블을 사용합니다. 각 지역 배포에서 올바른 지역 엔드포인트를 사용합니다.
→ DynamoDB 글로벌 테이블은 다중 리전 쓰기를 지원하고 리전 간 복제가 1초 이내로 이루어져 모든 요구사항을 충족합니다.
B. 데이터베이스를 Amazon Aurora MySQL 데이터베이스로 마이그레이션합니다. 각 지역에 Aurora 읽기 전용 복제본을 배포합니다. 데이터베이스에 액세스하려면 각 지역 배포에서 올 바른 지역 엔드포인트를 사용하세요.
→ Aurora 읽기 전용 복제본은 쓰기가 불가능하므로 각 리전에서 예약 생성/수정이 불가능하며, 단일 마스터로의 쓰기는 지연 시간이 높습니다.
C. 데이터베이스를 Amazon RDS for MySQL 데이터베이스로 마이그레이션합니다. 각 리전에 MySQL 읽기 전용 복제본을 배포합니다. 데이터베이스에 액세스하려면 각 지역 배포에서 올바른 지역 엔드포인트를 사용하세요.
→ RDS 읽기 전용 복제본도 B와 동일한 문제가 있으며, 리전 간 복제 지연이 더 길 수 있습니다.
D. 애플리케이션을 Amazon Aurora Serverless 데이터베이스로 마이그레이션합니다. 각 지역에 데이터베이스 인스턴스를 배포합니다. 각 지역 배포에서 올바른 지역 엔드포인트를 사용하여 데이터베이스에 액세스합니다. AWS Lambda 함수를 사용하여 각 리전에서 이벤트 스트림을 처리하여 데이터베이스를 동기화합니다.
→ Lambda를 이용한 수동 동기화는 복잡하고 운영 부담이 크며, 1초 이내 복제를 보장하기 어렵고 충돌 해결도 어렵습니다.
감사합니다. 다음 글에서 만나요! 😊
'AWS > SAA 준비' 카테고리의 다른 글
| AWS SAA 합격으로 가는 길 #127 (0) | 2025.10.24 |
|---|---|
| AWS SAA 합격으로 가는 길 #126 (0) | 2025.10.20 |
| AWS SAA 합격으로 가는 길 #124 (0) | 2025.10.13 |
| AWS SAA 합격으로 가는 길 #123 (0) | 2025.10.10 |
| AWS SAA 합격으로 가는 길 #122 (1) | 2025.10.06 |
