안녕하세요! 넥스트클라우드의 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를 사용하여 워크로드 세부 정보를 봅니다. 관계를 사용하여 아키텍처 다이어그램을 구축합니다.
풀이
AWS Workload Discovery on 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를 사용하여 상세 보기 보고서에서 맵 보기를 생성합니다.
→ Workload Discovery on AWS를 사용하면 모든 AWS 계정과 리전에 분산된 워크로드의 관계를 자동으로 매핑할 수 있습니다.
B. AWS Step Functions를 사용하여 워크로드 세부 정보를 수집합니다. 워크로드의 아키텍처 다이어그램을 수동으로 작성합니다.
→ Step Functions는 워크로드 세부 정보를 수집할 수 있지만, 워크로드 아키텍처 다이어그램을 자동으로 생성할 수는 없습니다.
C. Workload Discovery on AWS를 사용하여 워크로드의 아키텍처 다이어그램을 생성합니다.
→ Systems Manager Inventory는 인스턴스 메타데이터만 수집하므로 이 요구사항을 충족하기에 부족합니다.
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 글로벌 테이블이 가장 적합합니다. 글로벌 테이블은 완전히 복제되며 지역 간 복제본을 자동으로 유지관리하므로, 전 세계 어디서나 일관된 데이터에 액세스할 수 있습니다. 또한 DynamoDB는 평균 대기 시간이 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를 사용하면 DynamoDB 글로벌 테이블로 전 세계에서 단일 예약 데이터베이스를 유지하면서도 밀리초 단위의 낮은 지연 시간을 제공할 수 있습니다.
B. 데이터베이스를 Amazon Aurora MySQL 데이터베이스로 마이그레이션합니다. 각 지역에 Aurora 읽기 전용 복제본을 배포합니다. 데이터베이스에 액세스하려면 각 지역 배포에서 올바른 지역 엔드포인트를 사용하세요.
→ Aurora MySQL 읽기 전용 복제본을 여러 리전에 배포하면 읽기 확장성은 높일 수 있지만, 쓰기 작업은 한 마스터 인스턴스에서만 가능하므로 요구사항을 완전히 충족하기 어렵습니다.
C. 데이터베이스를 Amazon RDS for MySQL 데이터베이스로 마이그레이션합니다. 각 리전에 MySQL 읽기 전용 복제본을 배포합니다. 데이터베이스에 액세스하려면 각 지역 배포에서 올바른 지역 엔드포인트를 사용하세요.
→ RDS MySQL과 읽기 전용 복제본을 사용하는 것도 B와 동일한 이유로 적절하지 않습니다.
D. 애플리케이션을 Amazon Aurora Serverless 데이터베이스로 마이그레이션합니다. 각 지역에 데이터베이스 인스턴스를 배포합니다. 각 지역 배포에서 올바른 지역 엔드포인트를 사용하여 데이터베이스에 액세스합니다. AWS Lambda 함수를 사용하여 각 리전에서 이벤트 스트림을 처리하여 데이터베이스를 동기화합니다.
→ AWS Lambda 함수로 데이터베이스를 동기화하는 방식은 운영 부담이 크고 대기 시간 요구사항을 만족하기 어려울 수 있습니다.
오늘은 DB에 관한 문제가 꽤 있었네요. DB 문제는 DB의 특징만 알면 문제 없습니다!
꼭꼭 DB 특징을 기억해주세요! 다음에 뵙겠습니다 ☺️
'AWS > SAA 준비' 카테고리의 다른 글
| AWS SAA 합격으로 가는 길 #118 (0) | 2025.09.22 |
|---|---|
| AWS SAA 합격으로 가는 길 #117 (0) | 2025.09.19 |
| AWS SAA 합격으로 가는 길 #115 (0) | 2025.09.12 |
| AWS SAA 합격으로 가는 길 #114 (0) | 2025.09.08 |
| AWS SAA 합격으로 가는 길 #113 (1) | 2025.09.01 |