본문 바로가기
AWS/SAA 준비

AWS SAA 합격으로 가는 길 #20

by Pacloud 2024. 9. 23.
반응형

안녕하세요! 넥스트클라우드의 SA 백종훈입니다. 😊

 

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

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

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

3. 선택지 분석하기

 

문제1

전자상거래 회사는 분석을 위해 판매 기록을 집계하고 필터링하기 위해 예약된 일일 작업을 실행해야 합니다. 회사는 판매 기록을 Amazon S3 버킷에 저장합니다. 각 개체의 크기는 최대 10GB입니다. 판매 이벤트 수에 따라 작업을 완료하는 데 최대 1시간이 걸릴 수 있습니다. 작업의 CPU 및 메모리 사용량은 일정하며 미리 알려져 있습니다.

솔루션 설계자는 작업을 실행하는 데 필요한 운영 노력을 최소화해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

선택지

A. Amazon EventBridge 알림이 있는 AWS Lambda 함수를 생성합니다. EventBridge 이벤트가 하루에 한 번 실행되도록 예약합니다.

B. AWS Lambda 함수를 생성합니다. Amazon API Gateway HTTP API를 생성하고 API를 함수와 통합합니다. API를 호출하고 함수를 호출하는 Amazon EventBridge 예약 이벤트를 생성합니다.

C. AWS Fargate 시작 유형으로 Amazon Elastic Container Service(Amazon ECS) 클러스터를 생성합니다. 작업을 실행하기 위해 클러스터에서 ECS 작업을 시작하는 Amazon EventBridge 예약 이벤트를 생성합니다.

D. Amazon EC2 시작 유형이 있는 Amazon Elastic Container Service(Amazon ECS) 클러스터와 하나 이상의 EC2 인스턴스가 있는 Auto Scaling 그룹을 생성합니다. 작업을 실행하기 위해 클러스터에서 ECS 작업을 시작하는 Amazon EventBridge 예약 이벤트를 생성합니다.

풀이

AWS Fargate를 사용한 ECS는 서버리스이며 확장 가능해 최대 1시간 걸리는 대규모 작업을 처리하기에 적합합니다. 또한 EventBridge와 쉽게 통합되어 일일 예약 작업을 자동화할 수 있어 운영 노력을 최소화합니다.

정답 : C

 

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

더보기

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

  • 판매 기록을 일일 집계 및 필터링하는 예약 작업 실행
  • Amazon S3 버킷에 저장된 최대 10GB 크기의 판매 기록 처리
  • 작업 완료에 최대 1시간 소요 가능
  • CPU 및 메모리 사용량이 일정하고 예측 가능함
  • 운영 노력 최소화

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

  • 일일 예약 작업 실행
    • Amazon EventBridge: 서버리스 이벤트 버스 서비스로, 규칙을 사용하여 매일 정해진 시간에 작업을 트리거할 수 있습니다.
  • 대용량 데이터 처리 (최대 10GB)
    • AWS Fargate: 서버리스 컨테이너 실행 환경으로, 대용량 데이터 처리에 필요한 컴퓨팅 리소스를 제공할 수 있습니다.
    • Amazon ECS (Elastic Container Service): 컨테이너화된 애플리케이션을 쉽게 배포, 관리 및 확장할 수 있는 완전관리형 컨테이너 오케스트레이션 서비스입니다.
  • 장시간 실행 (최대 1시간)
    • AWS Fargate: 시간 제한 없이 컨테이너를 실행할 수 있어 장시간 작업에 적합합니다.
    • Amazon ECS: 장시간 실행되는 작업을 지원합니다.
  • 예측 가능한 리소스 사용
    • AWS Fargate: 작업에 필요한 CPU 및 메모리를 정확하게 지정할 수 있습니다.
    • Amazon ECS: 태스크 정의에서 리소스 요구사항을 명시할 수 있습니다.
  • 운영 노력 최소화
    • AWS Fargate: 서버리스 솔루션으로, 인프라 관리가 필요 없습니다.
    • Amazon ECS: 컨테이너 오케스트레이션을 자동화하여 운영 부담을 줄입니다.
    • Amazon EventBridge: 완전관리형 서비스로, 스케줄링 인프라 관리가 필요 없습니다.

3. 선택지 분석하기

A. Amazon EventBridge 알림이 있는 AWS Lambda 함수를 생성합니다. EventBridge 이벤트가 하루에 한 번 실행되도록 예약합니다.

→ Lambda 함수는 실행 시간이 최대 15분으로 제한되어 있어, 1시간까지 걸릴 수 있는 이 작업에는 적합하지 않습니다. 또한 Lambda의 메모리 제한(최대 10GB)으로 인해 대용량 데이터 처리에 어려움이 있을 수 있습니다. 따라서 이 옵션은 요구사항을 충족하지 못합니다.

 

B. AWS Lambda 함수를 생성합니다. Amazon API Gateway HTTP API를 생성하고 API를 함수와 통합합니다. API를 호출하고 함수를 호출하는 Amazon EventBridge 예약 이벤트를 생성합니다.

→ 이 옵션도 A와 마찬가지로 Lambda의 실행 시간 및 메모리 제한으로 인해 요구사항을 충족하지 못합니다. API Gateway를 추가로 사용하는 것은 불필요한 복잡성을 증가시키며, 운영 노력을 최소화해야 한다는 요구사항에 부합하지 않습니다.

 

C. AWS Fargate 시작 유형으로 Amazon Elastic Container Service(Amazon ECS) 클러스터를 생성합니다. 작업을 실행하기 위해 클러스터에서 ECS 작업을 시작하는 Amazon EventBridge 예약 이벤트를 생성합니다.

→ 이 옵션은 모든 요구사항을 충족합니다. Fargate는 서버리스 컨테이너 서비스로, 대용량 데이터 처리와 장시간 실행을 지원합니다. ECS를 통해 컨테이너를 쉽게 관리할 수 있으며, EventBridge로 일일 예약 작업을 자동화할 수 있습니다. 또한 서버리스 아키텍처를 사용하여 운영 노력을 최소화할 수 있습니다.

 

D. Amazon EC2 시작 유형이 있는 Amazon Elastic Container Service(Amazon ECS) 클러스터와 하나 이상의 EC2 인스턴스가 있는 Auto Scaling 그룹을 생성합니다. 작업을 실행하기 위해 클러스터에서 ECS 작업을 시작하는 Amazon EventBridge 예약 이벤트를 생성합니다.

→ 이 옵션은 요구사항을 부분적으로 충족하지만, EC2 인스턴스를 관리해야 하므로 운영 노력을 최소화해야 한다는 요구사항에 완전히 부합하지 않습니다. 또한, 지속적으로 실행되는 EC2 인스턴스로 인해 비용이 증가할 수 있어 비용 효율성 측면에서도 최적이 아닙니다.

 

이어서 다음 문제입니다.

문제2

회사는 대규모 Amazon EC2 인스턴스 플릿에서 애플리케이션을 실행합니다. 애플리케이션은 항목을 읽고 Amazon DynamoDB 테이블에 씁니다. DynamoDB 테이블의 크기는 지속적 으로 증가하지만 애플리케이션에는 지난 30일 동안의 데이터만 필요합니다. 회사는 비용과 개발 노력을 최소화하는 솔루션이 필요합니다.

어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

선택지

A. AWS CloudFormation 템플릿을 사용하여 전체 솔루션을 배포합니다. 30일마다 CloudFormation 스택을 재배포하고 원래 스택을 삭제합니다.

B. AWS Marketplace에서 모니터링 애플리케이션을 실행하는 EC2 인스턴스를 사용합니다. Amazon DynamoDB Streams를 사용하여 테이블에 새 항목이 생성될 때 타임스탬프를 저장하도록 모니터링 애플리케이션을 구성합니다. EC2 인스턴스에서 실행되는 스크립트를 사용하여 30일보다 오래된 타임스탬프가 있는 항목을 삭제합니다.

C. 테이블에 새 항목이 생성될 때 AWS Lambda 함수를 호출하도록 Amazon DynamoDB Streams를 구성합니다. 테이블에서 30일보다 오래된 항목을 삭제하도록 Lambda 함수를 구성합니다.

D. 애플리케이션을 확장하여 현재 타임스탬프에 30일을 더한 값을 테이블에 생성된 각 새 항목에 추가하는 속성을 추가합니다. 속성을 TTL 속성으로 사용하도록 DynamoDB를 구성합니다.

풀이

DynamoDB의 TTL 기능을 사용하는 D 옵션은 추가 비용 없이 오래된 데이터를 자동으로 삭제할 수 있어 비용 효율적입니다. 애플리케이션에 간단한 수정만 필요하고 추가 인프라 없이 구현 가능하여 개발 노력을 최소화합니다. 또한 데이터 증가에 따라 자동으로 확장되므로, 요구사항을 가장 효과적으로 충족시킵니다.

 

정답 : D

 

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

더보기

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

  • DynamoDB 테이블의 데이터 중 최근 30일 데이터만 유지
  • 비용 최소화
  • 개발 노력 최소화

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

  • DynamoDB 테이블의 데이터 중 최근 30일 데이터만 유지
    • Amazon DynamoDB: NoSQL 데이터베이스 서비스로, 대규모 데이터 저장 및 검색에 사용됩니다.
    • DynamoDB TTL (Time To Live): DynamoDB의 기능으로, 지정된 시간이 지난 항목을 자동으로 삭제합니다. 이를 통해 30일이 지난 데이터를 자동으로 제거할 수 있습니다.
    • AWS Lambda: 서버리스 컴퓨팅 서비스로, 필요한 경우 데이터 처리나 삭제 작업을 수행할 수 있습니다.
    • Amazon DynamoDB Streams: DynamoDB 테이블의 데이터 수정 이벤트를 캡처하고 이를 다른 서비스와 연동할 수 있게 해주는 기능입니다.
  • 비용 최소화
    • DynamoDB TTL: 추가 비용 없이 오래된 데이터를 자동으로 삭제할 수 있어 스토리지 비용을 절감할 수 있습니다.
    • AWS Lambda: 실행 시간과 리소스 사용량에 따라 비용이 청구되므로, 필요한 경우에만 비용이 발생합니다.
  • 개발 노력 최소화
    • DynamoDB TTL: 간단한 설정만으로 데이터 수명 주기 관리를 자동화할 수 있어 개발 노력을 크게 줄일 수 있습니다.
    • AWS Lambda: 서버리스 아키텍처를 사용하여 서버 관리나 패치 적용 등의 인프라 유지 관리 작업이 필요 없습니다.

3. 선택지 분석하기

A. AWS CloudFormation 템플릿을 사용하여 전체 솔루션을 배포합니다. 30일마다 CloudFormation 스택을 재배포하고 원래 스택을 삭제합니다.

→ 이 방법은 복잡하고 위험할 수 있으며, 데이터 손실 가능성이 있습니다. 또한 주기적인 재배포로 인해 개발 노력이 증가하고 비용 효율성이 떨어집니다.

 

B. AWS Marketplace에서 모니터링 애플리케이션을 실행하는 EC2 인스턴스를 사용합니다. Amazon DynamoDB Streams를 사용하여 테이블에 새 항목이 생성될 때 타임스탬프를 저장하도록 모니터링 애플리케이션을 구성합니다. EC2 인스턴스에서 실행되는 스크립트를 사용하여 30일보다 오래된 타임스탬프가 있는 항목을 삭제합니다.

→ 추가 EC2 인스턴스와 모니터링 애플리케이션 사용으로 비용이 증가하고, 구현 및 유지 관리에 많은 개발 노력이 필요합니다.

 

C. 테이블에 새 항목이 생성될 때 AWS Lambda 함수를 호출하도록 Amazon DynamoDB Streams를 구성합니다. 테이블에서 30일보다 오래된 항목을 삭제하도록 Lambda 함수를 구성합니다.

→ 이 방법은 자동화된 접근 방식을 제공하지만, Lambda 함수의 지속적인 실행으로 인해 비용이 증가할 수 있으며, 구현 및 유지 관리에 일정 수준의 개발 노력이 필요합니다.

 

D. 애플리케이션을 확장하여 현재 타임스탬프에 30일을 더한 값을 테이블에 생성된 각 새 항목에 추가하는 속성을 추가합니다. 속성을 TTL 속성으로 사용하도록 DynamoDB를 구성합니다.

→ DynamoDB의 TTL 기능을 활용하여 추가 비용 없이 오래된 데이터를 자동으로 삭제할 수 있습니다. 애플리케이션에 간단한 수정만 필요하며, 추가 리소스 없이 자동으로 확장되어 비용과 개발 노력을 최소화합니다.

 

 

마지막 문제 살펴볼게요.

문제3

회사는 기본 온프레미스 파일 스토리지 볼륨에 대한 재해 복구 계획을 구현하려고 합니다. 파일 스토리지 볼륨은 로컬 스토리지 서버의 iSCSI(Internet Small Computer Systems Interface) 장치에서 마운트됩니다. 파일 스토리지 볼륨은 수백 테라바이트(TB)의 데이터를 보유합니다.

회사는 최종 사용자가 대기 시간 없이 온프레미스 시스템의 모든 파일 유형에 즉시 액세스할 수 있기를 원합니다.

회사의 기존 인프라를 최소한으로 변경하면서 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

 

선택지

A. 온프레미스에서 호스팅되는 가상 머신(VM)으로 Amazon S3 파일 게이트웨이를 프로비저닝합니다. 로컬 캐시를 10TB로 설정합니다. NFS 프로토콜을 통해 파일에 액세스하도록 기존 애플리케이션을 수정합니다. 재해에서 복구하려면 Amazon EC2 인스턴스를 프로비저닝하고 파일이 포함된 S3 버킷을 탑재합니다.

B. AWS Storage Gateway 테이프 게이트웨이를 프로비저닝합니다. 데이터 백업 솔루션을 사용하여 모든 기존 데이터를 가상 테이프 라이브러리에 백업하십시오. 초기 백업이 완료된 후 야간에 실행되도록 데이터 백업 솔루션을 구성합니다. 재해에서 복구하려면 Amazon EC2 인스턴스를 프로비저닝하고 가상 테이프 라이브러리의 볼륨에서 Amazon Elastic Block Store(Amazon EBS) 볼륨으로 데이터를 복원합니다.

C. AWS Storage Gateway 볼륨 게이트웨이 캐시 볼륨을 프로비저닝합니다. 로컬 캐시를 10TB로 설정합니다. iSCSI를 사용하여 볼륨 게이트웨이 캐싱 볼륨을 기존 파일 서버에 마운트 하고 모든 파일을 스토리지 볼륨에 복사합니다. 스토리지 볼륨의 예약된 스냅샷을 구성합니다. 재해에서 복구하려면 스냅샷을 Amazon Elastic Block Store(Amazon EBS) 볼륨으 로 복원하고 EBS 볼륨을 Amazon EC2 인스턴스에 연결합니다.

D. 기존 파일 스토리지 볼륨과 동일한 양의 디스크 공간으로 AWS Storage Gateway 볼륨 게이트웨이 저장 볼륨을 프로비저닝합니다. iSCSI를 사용하여 볼륨 게이트웨이 저장 볼륨을 기존 파일 서버에 마운트하고 모든 파일을 스토리지 볼륨에 복사합니다. 스토리지 볼륨의 예약된 스냅샷을 구성합니다. 재해에서 복구하려면 스냅샷을 Amazon Elastic Block Store (Amazon EBS) 볼륨으로 복원하고 EBS 볼륨을 Amazon EC2 인스턴스에 연결합니다.

 

풀이

AWS Storage Gateway 볼륨 게이트웨이 저장 볼륨을 사용하면 현재의 iSCSI 기반 구조를 그대로 유지하면서 온프레미스 데이터를 AWS에 백업할 수 있습니다. 또한 전체 볼륨을 로컬에 저장하므로 최종 사용자가 지연 없이 모든 파일에 즉시 액세스할 수 있습니다.

정답 : D

 

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

더보기

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

  • 온프레미스 파일 스토리지에 대한 재해 복구 계획 구현
  • 수백 TB의 데이터 보유
  • 최종 사용자가 지연 없이 모든 파일에 즉시 액세스 가능
  • 기존 인프라를 최소한으로 변경

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

  • 온프레미스 파일 스토리지에 대한 재해 복구 계획 구현
    • AWS Storage Gateway: 온프레미스 환경과 AWS 클라우드를 연결하는 하이브리드 클라우드 스토리지 서비스입니다. 볼륨 게이트웨이를 통해 기존 iSCSI 프로토콜을 유지하면서 AWS에 데이터를 백업할 수 있습니다.
    • Amazon S3: 대규모 데이터 백업 및 장기 보관에 적합한 내구성 높은 객체 스토리지 서비스입니다.
  • 수백 TB의 데이터 보유 및 즉시 액세스
    • AWS Storage Gateway (볼륨 게이트웨이 - 저장 볼륨 모드): 전체 데이터 세트를 로컬에 저장하면서 AWS에 비동기적으로 백업합니다. 이를 통해 대용량 데이터에 대한 즉각적인 액세스를 제공할 수 있습니다.
  • 기존 인프라를 최소한으로 변경
    • AWS Storage Gateway (볼륨 게이트웨이): 기존 iSCSI 프로토콜을 그대로 사용할 수 있어 인프라 변경을 최소화할 수 있습니다.
  • 재해 복구 시 데이터 복원
    • Amazon EBS: Storage Gateway에서 생성한 스냅샷을 EBS 볼륨으로 복원하여 재해 복구 시 사용할 수 있습니다.
    • Amazon EC2: 복원된 EBS 볼륨을 연결하여 재해 복구 시 파일 서비스를 신속하게 재개할 수 있습니다.

3. 선택지 분석하기

A. 온프레미스에서 호스팅되는 가상 머신(VM)으로 Amazon S3 파일 게이트웨이를 프로비저닝합니다. 로컬 캐시를 10TB로 설정합니다. NFS 프로토콜을 통해 파일에 액세스하도록 기존 애플리케이션을 수정합니다.

→ NFS 프로토콜로의 변경이 필요하여 기존 인프라 변경 최소화 요구사항에 부합하지 않습니다. 또한 10TB 캐시로는 수백 TB 데이터의 즉시 액세스 요구사항을 충족하기 어렵습니다. 재해 복구 시 EC2 인스턴스에 S3 버킷을 마운트하는 방식은 성능 저하를 일으킬 수 있습니다.

 

B. AWS Storage Gateway 테이프 게이트웨이를 프로비저닝합니다. 데이터 백업 솔루션을 사용하여 모든 기존 데이터를 가상 테이프 라이브러리에 백업하십시오.

→ 테이프 게이트웨이는 백업에 적합하지만, 최종 사용자의 즉시 액세스 요구사항을 충족하지 못합니다. 데이터 복원 과정이 필요하여 지연이 발생할 수 있으며, 기존 인프라를 크게 변경해야 합니다. 또한 야간 백업 방식은 실시간 데이터 보호에 취약할 수 있습니다.

 

C. AWS Storage Gateway 볼륨 게이트웨이 캐시 볼륨을 프로비저닝합니다. 로컬 캐시를 10TB로 설정합니다.

→ 캐시 볼륨은 자주 접근하는 데이터만 로컬에 저장하므로, 수백 TB 데이터에 대한 즉시 액세스 요구사항을 충족하기 어렵습니다. 10TB 캐시로는 전체 데이터셋을 커버하기에 부족하여 빈번한 캐시 미스로 인한 지연이 발생할 수 있습니다. 그러나 기존 iSCSI 프로토콜을 유지할 수 있어 인프라 변경은 최소화됩니다.

 

D. 기존 파일 스토리지 볼륨과 동일한 양의 디스크 공간으로 AWS Storage Gateway 볼륨 게이트웨이 저장 볼륨을 프로비저닝합니다.

→ 이 옵션은 모든 요구사항을 가장 잘 충족합니다. 기존 iSCSI 프로토콜을 유지하여 인프라 변경을 최소화하고, 전체 데이터를 로컬에 저장하여 최종 사용자의 즉시 액세스 요구사항을 충족합니다. AWS에 데이터를 비동기적으로 백업하여 효과적인 재해 복구 계획을 제공하며, 수백 TB의 대용량 데이터를 수용할 수 있습니다. 스냅샷 기반 복구로 신속한 재해 복구가 가능합니다.

"물방울이 바위를 뚫는다 - 힘으로가 아니라 끊임없이 떨어짐으로써." - 오비디우스, 로마의 시인

 

저작자표시

'AWS > SAA 준비' 카테고리의 다른 글

AWS SAA 합격으로 가는 길 #22  (0) 2024.09.30
AWS SAA 합격으로 가는 길 #21  (0) 2024.09.27
AWS SAA 합격으로 가는 길 #19  (1) 2024.09.20
AWS SAA 합격으로 가는 길 #18  (7) 2024.09.16
AWS SAA 합격으로 가는 길 #17  (2) 2024.09.13

관련글

티스토리툴바