AWS SAA 합격으로 가는 길 #103

안녕하세요! 넥스트클라우드의 SA 김도겸입니다. 힘차게 7월24일 AWS SAA 준비 포스팅 시작해보겠습니다. 🤗

 

문제는 세 가지 단계를 거치며 풀어 나갈 거예요.

1. 문제의 요구사항 분석하기

2. 관련 AWS 서비스 생각하기

3. 선택지 분석하기

 

바로 문제 풀이 해볼까요?

---

문제1

회사에서 이전 애플리케이션을 AWS로 마이그레이션하고 있습니다. 애플리케이션은 매시간 배치 작업을 실행하며 CPU를 많이 사용합니다. 배치 작업은 온프레미스 서버에서 평균 15분이 소요됩니다. 서버에는 64개의 가상 CPU(vCPU)와 512GiB의 메모리가 있습니다. 최소한의 운영 오버헤드로 15분 이내에 배치 작업을 실행하는 솔루션은 무엇입니까?

 

선택지

A. 기능적 확장과 함께 AWS Lambda를 사용하십시오.

 

B. AWS Fargate와 함께 Amazon Elastic Container Service(Amazon ECS)를 사용합니다.

 

C. AWS Auto Scaling과 함께 Amazon Lightsail을 사용합니다.

 

D. Amazon EC2에서 AWS Batch를 사용합니다.

---

풀이

회사에서 기존 애플리케이션을 AWS로 마이그레이션하여 매시간 실행되는 CPU 집약적인 배치 작업을 처리해야 합니다. 64vCPU와 512GiB 메모리라는 고사양 리소스가 필요하고, 15분 이내 실행과 최소 운영 오버헤드라는 요구사항을 만족하는 최적의 솔루션은 Amazon EC2에서 AWS Batch를 사용하는 것입니다.

 

AWS Batch는 배치 작업에 특화된 완전관리형 서비스로, 필요한 컴퓨팅 리소스를 자동으로 프로비저닝하고 작업을 효율적으로 스케줄링하여 운영 오버헤드를 최소화합니다.

 

정답 : D

 

▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

1.  문제의 요구사항 분석하기

• 매시간 실행되는 CPU 집약적인 배치 작업: 정기적이고 예측 가능한 워크로드
• 고사양 리소스: 64vCPU, 512GiB 메모리가 필요한 대규모 작업
• 실행 시간 제약: 15분 이내 완료 필요
• 최소 운영 오버헤드: 인프라 관리 부담 최소화
• 기존 애플리케이션 마이그레이션: 기존 로직과 호환성 유지

2. 관련 AWS 서비스 생각하기

• AWS Batch: 배치 작업 전용 완전관리형 서비스, 동적 리소스 프로비저닝
• Amazon EC2: 유연한 컴퓨팅 인스턴스, 고사양 인스턴스 타입 지원
• AWS Lambda: 서버리스 컴퓨팅, 15분 최대 실행 시간 제한
• Amazon ECS with Fargate: 서버리스 컨테이너 실행 환경
• Amazon Lightsail: 간단한 VPS 서비스, 제한적인 스케일링

3. 선택지 분석하기

A. 기능적 확장과 함께 AWS Lambda를 사용하십시오.
→ Lambda는 최대 15분 실행 시간 제한과 10GB 메모리 제한으로 512GiB 메모리 요구사항을 충족할 수 없고, CPU 집약적인 작업에 적합하지 않습니다.

B. AWS Fargate와 함께 Amazon Elastic Container Service(Amazon ECS)를 사용합니다.
→ Fargate는 최대 16vCPU, 120GB 메모리 제한으로 64vCPU, 512GiB 요구사항을 충족할 수 없고, 배치 작업 관리에는 적절하지 않습니다.

C. AWS Auto Scaling과 함께 Amazon Lightsail을 사용합니다.
→ Lightsail은 가상 프라이빗 서버 제공 서비스로 배치 작업 관리에 적합하지 않고, 제한적인 인스턴스 타입으로 고사양 요구사항을 충족하기 어렵습니다.

✅ D. Amazon EC2에서 AWS Batch를 사용합니다.
→ AWS Batch는 배치 작업 실행 및 관리에 특화된 완전관리형 서비스로 운영 오버헤드를 최소화할 수 있고, 고사양 EC2 인스턴스를 활용하여 모든 요구사항을 충족할 수 있습니다.

 

이어서 다음 문제입니다.

---

문제2

솔루션 설계자는 대용량 SaaS(Software as a Service) 플랫폼에 대한 재해 복구(DR) 계획을 만들어야 합니다. 플랫폼의 모든 데이터는 Amazon Aurora MySQL DB 클러스터에 저 장됩니다. DR 계획은 데이터를 보조 AWS 리전에 복제해야 합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

선택지

A. 보조 리전의 Aurora 클러스터에 MySQL 바이너리 로그 복제를 사용합니다. 보조 리전에서 Aurora 클러스터용 DB 인스턴스 1개를 프로비저닝합니다.

B. DB 클러스터에 대한 Aurora 글로벌 데이터베이스를 설정합니다. 설정이 완료되면 보조 리전에서 DB 인스턴스를 제거합니다.

C. AWS Database Migration Service(AWS DMS)를 사용하여 데이터를 보조 리전의 Aurora 클러스터에 지속적으로 복제합니다. 보조 리전에서 DB 인스턴스를 제거합니다.

D. DB 클러스터에 대한 Aurora 글로벌 데이터베이스를 설정합니다. 보조 리전에서 최소 하나의 DB 인스턴스를 지정합니다.

---

풀이

대용량 SaaS 플랫폼의 재해 복구를 위해 Amazon Aurora MySQL DB 클러스터의 데이터를 보조 AWS 리전에 복제하는 가장 비용 효율적인 솔루션은 Aurora 글로벌 데이터베이스를 설정하고 보조 리전에서 최소 하나의 DB 인스턴스를 지정하는 것입니다.

Aurora 글로벌 데이터베이스는 스토리지 계층에서 자동으로 데이터를 복제하여 효율적이며, 보조 리전에 최소한의 인스턴스를 유지함으로써 재해 발생 시 빠른 복구가 가능하면서도 비용을 최적화할 수 있습니다.

정답 : D

 

▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

1.  문제의 요구사항 분석하기

• 대용량 SaaS 플랫폼의 재해 복구 계획 수립
• Amazon Aurora MySQL DB 클러스터 데이터를 보조 AWS 리전에 복제
• 비용 효율적인 솔루션 필요
• 재해 복구 시나리오에서 사용 가능한 구성

2. 관련 AWS 서비스 생각하기

• Amazon Aurora 글로벌 데이터베이스: Aurora 클러스터의 데이터를 여러 AWS 리전에 걸쳐 복제하는 완전관리형 서비스입니다. 스토리지 계층에서 데이터 복제가 이루어져 매우 효율적이며, 하나의 프라이머리 리전과 최대 5개의 보조 리전을 지원합니다.
  
  
• AWS Database Migration Service(AWS DMS): 소스 데이터베이스에서 타겟 데이터베이스로 데이터를 마이그레이션하고 지속적으로 복제하는 클라우드 서비스입니다. 다양한 데이터베이스 엔진 간 복제를 지원합니다.
  
  
• MySQL 바이너리 로그 복제: MySQL 고유의 복제 방식으로 바이너리 로그를 사용하여 데이터를 복제합니다.

3. 선택지 분석하기

A. 보조 리전의 Aurora 클러스터에 MySQL 바이너리 로그 복제를 사용합니다. 보조 리전에서 Aurora 클러스터용 DB 인스턴스 1개를 프로비저닝합니다.
→ 바이너리 로그 복제는 Aurora 글로벌 데이터베이스보다 복잡하고 관리 오버헤드가 크며, 비용 효율성이 낮습니다.

B. DB 클러스터에 대한 Aurora 글로벌 데이터베이스를 설정합니다. 설정이 완료되면 보조 리전에서 DB 인스턴스를 제거합니다.
→ 보조 리전에 DB 인스턴스가 없으면 재해 발생 시 인스턴스를 새로 생성해야 하므로 복구 시간이 길어집니다.

C. AWS Database Migration Service(AWS DMS)를 사용하여 데이터를 보조 리전의 Aurora 클러스터에 지속적으로 복제합니다. 보조 리전에서 DB 인스턴스를 제거합니다.
→ DMS는 지속적인 복제에는 유용하지만 Aurora 글로벌 데이터베이스보다 비용이 높고, 보조 리전에 인스턴스가 없으면 즉시 활용할 수 없습니다.

✅ D. DB 클러스터에 대한 Aurora 글로벌 데이터베이스를 설정합니다. 보조 리전에서 최소 하나의 DB 인스턴스를 지정합니다.
→ Aurora 글로벌 데이터베이스로 효율적인 데이터 복제가 가능하고, 보조 리전에 최소 인스턴스를 유지하여 재해 복구 시 즉시 활용 가능하면서도 비용 효율적입니다.

 

마지막 문제 살펴볼게요.

---

문제3

회사에는 자동차의 IoT 센서에서 데이터를 수집하는 애플리케이션이 있습니다. 데이터는 Amazon Kinesis Data Firehose를 통해 Amazon S3에 스트리밍 및 저장됩니다. 데이터는 매 년 수조 개의 S3 객체를 생성합니다. 매일 아침 회사는 지난 30일 동안의 데이터를 사용하여 일련의 기계 학습(ML) 모델을 재교육합니다. 매년 4회 회사는 이전 12개월의 데이터를 사용하여 분석을 수행하고 다른 ML 모델을 교육합니다. 데이터는 최대 1년 동안 최소한의 지연으로 사용할 수 있어야 합니다. 1년 후에는 데이터를 보관 목적으로 보관해야 합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 스토리지 솔루션은 무엇입니까?

선택지

A. S3 Intelligent-Tiering 스토리지 클래스를 사용합니다. 1년 후 객체를 S3 Glacier Deep Archive로 전환하는 S3 수명 주기 정책을 생성합니다.

B. S3 Intelligent-Tiering 스토리지 클래스를 사용합니다. 1년 후 자동으로 객체를 S3 Glacier Deep Archive로 이동하도록 S3 Intelligent-Tiering을 구성합니다.

C. S3 Standard-Infrequent Access(S3 Standard-IA) 스토리지 클래스를 사용합니다. 1년 후 객체를 S3 Glacier Deep Archive로 전환하는 S3 수명 주기 정책을 생성합니다.

D. S3 Standard 스토리지 클래스를 사용합니다. 30일 후에 객체를 S3 Standard-Infrequent Access(S3 Standard-IA)로 전환한 다음 1년 후에 S3 Glacier Deep Archive로 전 환하는 S3 수명 주기 정책을 생성합니다.

---

풀이

자동차 IoT 센서 데이터의 스토리지 요구사항을 가장 비용 효율적으로 충족하는 솔루션은 S3 Standard 스토리지 클래스를 사용하되, 30일 후에는 S3 Standard-IA로, 1년 후에는 S3 Glacier Deep Archive로 전환하는 S3 수명 주기 정책을 생성하는 것입니다. 이렇게 하면 최근 30일 데이터에 대한 최소 지연 액세스를 보장하면서도 시간이 지날수록 비용 효율적인 스토리지 클래스로 자동 전환되어 모든 요구사항을 만족할 수 있습니다.

 

정답 : D

 

▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

1.  문제의 요구사항 분석하기

• 자동차 IoT 센서 데이터를 Amazon S3에 저장 (매년 수조 개의 객체)
• 최근 30일 데이터는 매일 ML 모델 재교육에 사용 (최소 지연 필요)
• 연 4회 이전 12개월 데이터로 분석 및 ML 모델 교육
• 데이터는 최대 1년 동안 최소 지연으로 사용 가능해야 함
• 1년 후 데이터는 보관 목적으로 저장
• 비용 효율적인 스토리지 솔루션 필요

2. 관련 AWS 서비스 생각하기

• S3 Standard: 자주 액세스하는 데이터에 최적화된 스토리지 클래스로 높은 성능과 즉시 액세스를 제공하지만 비용이 가장 높습니다.
• S3 Intelligent-Tiering: 액세스 패턴에 따라 자동으로 스토리지 티어를 변경하는 클래스로 모니터링 및 자동화 비용이 발생합니다.
• S3 Standard-IA: 자주 액세스하지 않는 데이터용 저비용 스토리지로 S3 Standard보다 저렴하지만 액세스 요금이 부과됩니다.
• S3 Glacier Deep Archive: 장기 보관용 초저비용 스토리지로 데이터 검색 시 12시간 이상의 지연이 발생합니다.
• S3 수명 주기 정책: 객체 생성 후 시간 경과에 따라 자동으로 다른 스토리지 클래스로 전환하는 기능입니다.

3. 선택지 분석하기

A. S3 Intelligent-Tiering 스토리지 클래스를 사용합니다. 1년 후 객체를 S3 Glacier Deep Archive로 전환하는 S3 수명 주기 정책을 생성합니다.
→ Intelligent-Tiering은 모니터링 비용이 발생하고, 최근 30일 데이터가 자동으로 IA나 Archive 티어로 이동할 수 있어 최소 지연 요구사항을 보장하지 못합니다.

B. S3 Intelligent-Tiering 스토리지 클래스를 사용합니다. 1년 후 자동으로 객체를 S3 Glacier Deep Archive로 이동하도록 S3 Intelligent-Tiering을 구성합니다.
→ Intelligent-Tiering 자체는 Deep Archive로 자동 전환 기능이 없고, 최근 30일 데이터에 대한 최소 지연을 보장하지 못합니다.

C. S3 Standard-IA 스토리지 클래스를 사용합니다. 1년 후 객체를 S3 Glacier Deep Archive로 전환하는 S3 수명 주기 정책을 생성합니다.
→ 최근 30일 데이터가 Standard-IA에 저장되어 매일 ML 모델 재교육 시 액세스 요금이 발생하고, 최소 지연 요구사항을 충족하지 못합니다.

✅ D. S3 Standard 스토리지 클래스를 사용합니다. 30일 후에 객체를 S3 Standard-IA로 전환한 다음 1년 후에 S3 Glacier Deep Archive로 전환하는 S3 수명 주기 정책을 생성합니다.
→ 최근 30일 데이터는 S3 Standard에서 최소 지연으로 액세스하고, 30일 후 Standard-IA로 전환하여 비용을 절약하며, 1년 후 Deep Archive로 보관하여 모든 요구사항을 비용 효율적으로 충족합니다.

 

감사합니다. 다음 글에서 만나요! 😊