본문 바로가기
AWS/SAA 준비

AWS SAA 합격으로 가는 길 #25

by Pacloud 2024. 10. 11.
반응형

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

 

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

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

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

3. 선택지 분석하기

 

문제1

회사는 Application Load Balancer(ALB) 뒤에 있는 Amazon EC2 인스턴스 플릿에서 동적 웹 사이트를 제공합니다. 웹 사이트는 전 세계 고객에게 서비스를 제공하기 위해 여러 언어를 지원해야 합니다. 웹 사이트의 아키텍처는 us-west-1 지역에서 실행 중이며 세계의 다른 지역에 있는 사용자에 대해 높은 요청 지연 시간을 보이고 있습니다.

웹사이트는 사용자의 위치에 관계없이 빠르고 효율적으로 요청을 처리해야 합니다. 그러나 회사는 여러 지역에 걸쳐 기존 아키텍처를 다시 생성하기를 원하지 않습니다.

 

솔루션 설계자는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?

 

선택지

A. 기존 아키텍처를 Amazon S3 버킷에서 제공되는 웹 사이트로 교체하십시오. S3 버킷을 오리진으로 사용하여 Amazon CloudFront 배포를 구성합니다. Accept-Language 요청 헤 더를 기반으로 캐시 동작 설정을 캐시로 설정합니다.

B. ALB를 오리진으로 사용하여 Amazon CloudFront 배포를 구성합니다. Accept-Language 요청 헤더를 기반으로 캐시 동작 설정을 캐시로 설정합니다.

C. ALB와 통합되는 Amazon API Gateway API를 생성합니다. HTTP 통합 유형을 사용하도록 API를 구성합니다. Accept-Language 요청 헤더를 기반으로 API 캐시를 활성화하도록 API Gateway 단계를 설정합니다.

D. 각 추가 지역에서 EC2 인스턴스를 시작하고 해당 지역의 캐시 서버 역할을 하도록 NGINX를 구성합니다. 지리적 위치 라우팅 정책을 사용하여 Amazon Route 53 레코드 세트 뒤에 모든 EC2 인스턴스와 ALB를 배치합니다.

풀이

이 방법은 기존 아키텍처를 유지하면서 CloudFront를 통해 글로벌 사용자에게 빠른 접근성을 제공할 수 있습니다. Accept-Language 헤더를 기반으로 한 캐싱은 다국어 지원에 적합합니다.

정답 : B

 

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

더보기

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

  • 전 세계 고객에게 다국어 서비스 제공 필요
  • 현재 us-west-1 리전에서만 운영 중
  • 전 세계 사용자에 대한 높은 지연 시간 문제 해결 필요
  • 기존 아키텍처를 여러 리전에 복제하지 않고 해결책 찾아야 함
  • 사용자 위치에 관계없이 빠르고 효율적인 요청 처리 필요

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

  • Amazon CloudFront:
    • 글로벌 콘텐츠 전송 네트워크(CDN) 서비스
    • 전 세계 엣지 로케이션을 통해 콘텐츠를 캐싱하고 제공
    • 오리진 서버의 부하를 줄이고 전 세계 사용자에게 낮은 지연 시간으로 콘텐츠 제공 가능
    • 다양한 오리진(예: ALB, S3)을 지원
    • 요청 헤더를 기반으로 캐싱 동작을 설정할 수 있어 다국어 지원에 유용

3. 선택지 분석하기

A. 기존 아키텍처를 Amazon S3 버킷에서 제공되는 웹 사이트로 교체하십시오. S3 버킷을 오리진으로 사용하여 Amazon CloudFront 배포를 구성합니다. Accept-Language 요청 헤 더를 기반으로 캐시 동작 설정을 캐시로 설정합니다.

→ 이 방법은 CloudFront를 사용하여 글로벌 사용자에게 빠른 접근성을 제공할 수 있지만, 동적 웹사이트를 정적 웹사이트로 변경해야 하므로 기존 아키텍처를 크게 수정해야 합니다.

 

B. ALB를 오리진으로 사용하여 Amazon CloudFront 배포를 구성합니다. Accept-Language 요청 헤더를 기반으로 캐시 동작 설정을 캐시로 설정합니다.

→ 이 방법은 기존 아키텍처를 유지하면서 CloudFront를 통해 글로벌 사용자에게 빠른 접근성을 제공할 수 있습니다. Accept-Language 헤더를 기반으로 한 캐싱은 다국어 지원에 적합합니다.

 

C. ALB와 통합되는 Amazon API Gateway API를 생성합니다. HTTP 통합 유형을 사용하도록 API를 구성합니다. Accept-Language 요청 헤더를 기반으로 API 캐시를 활성화하도록 API Gateway 단계를 설정합니다.

→ API Gateway는 RESTful API를 위한 서비스로, 웹사이트 전체를 제공하는 데는 적합하지 않습니다. 또한 글로벌 엣지 로케이션을 통한 콘텐츠 전송을 제공하지 않아 지연 시간 문제를 완전히 해결하기 어렵습니다.

 

D. 각 추가 지역에서 EC2 인스턴스를 시작하고 해당 지역의 캐시 서버 역할을 하도록 NGINX를 구성합니다. 지리적 위치 라우팅 정책을 사용하여 Amazon Route 53 레코드 세트 뒤에 모든 EC2 인스턴스와 ALB를 배치합니다.

→ 이 방법은 여러 지역에 인프라를 복제해야 하므로 회사가 원하지 않는 방식입니다. 또한 관리 복잡성이 증가하고 비용이 증가할 수 있습니다.

 

이어서 다음 문제입니다.

문제2

회사의 애플리케이션이 AWS에서 실행됩니다. 애플리케이션은 S3 Standard-infrequent Access(S3 Standerd-IA) 스토리지 클래스를 사용하는 Amazon S3 버킷에 대용량 문서를 저장합니다. 회사는 데이터 저장 비용을 계속 지불하지만 총 S3 비용을 절감하고자 합니다. 회사는 승인된 외부 사용자가 밀리초 단위로 문서에 액세스할 수 있기를 원합니다.

이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

 

선택지

A. 요청자 지불 버킷이 되도록 S3 버킷을 구성합니다.

B. 모든 기존 객체와 향후 객체에 대해 스토리지 계층을 S3 Standard로 변경합니다.

C. S3 Docket에서 S3 Transfer Acceleration을 켭니다.

D. Amazon CloudFront를 사용하여 S3 버킷에 대한 모든 요청을 처리합니다.

풀이

CloudFront를 사용하면 엣지 로케이션을 통해 콘텐츠를 캐싱하고 전송할 수 있어 액세스 속도가 향상됩니다. 또한 S3 요청 비용을 줄일 수 있어 총 S3 비용을 절감할 수 있습니다. 캐싱을 통해 밀리초 단위 액세스가 가능하며, 데이터 전송 비용도 절감할 수 있습니다.

 

정답 : D

 

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

더보기

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

  • AWS에서 실행되는 애플리케이션
  • S3 Standard-IA 스토리지 클래스 사용 중
  • 데이터 저장 비용은 유지하면서 총 S3 비용 절감 필요
  • 승인된 외부 사용자의 밀리초 단위 액세스 요구
  • 가장 비용 효율적인 솔루션 필요

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

  • Amazon S3 (Simple Storage Service):
    • 다양한 스토리지 클래스 제공 (Standard, Standard-IA, Glacier 등)
    • 요청자 지불 기능 제공
    • Transfer Acceleration 기능으로 빠른 데이터 전송 가능
    • 정적 웹사이트 호스팅 가능
  • Amazon CloudFront:
    • CDN (Content Delivery Network) 서비스
    • S3와 통합하여 콘텐츠 전송 속도 향상 및 비용 절감 가능
    • 엣지 로케이션을 통한 글로벌 콘텐츠 전송

3. 선택지 분석하기

A. 요청자 지불 버킷이 되도록 S3 버킷을 구성합니다.

→ 이 옵션은 데이터 전송 및 요청 비용을 요청자에게 전가할 수 있어 회사의 S3 비용을 절감할 수 있습니다. 그러나 스토리지 비용은 여전히 회사가 부담하며, 밀리초 단위 액세스 요구사항을 직접적으로 해결하지 않습니다.

 

B. 모든 기존 객체와 향후 객체에 대해 스토리지 계층을 S3 Standard로 변경합니다.

→ S3 Standard는 S3 Standard-IA보다 스토리지 비용이 더 높습니다. 이 옵션은 비용을 증가시키므로 요구사항을 충족하지 않습니다.

 

C. S3 버킷에서 S3 Transfer Acceleration을 켭니다.

→ Transfer Acceleration은 데이터 전송 속도를 향상시킬 수 있지만, 추가 비용이 발생하며 주로 대용량 데이터 업로드에 유용합니다. 읽기 액세스 속도 향상에는 제한적이며, 비용 절감 요구사항을 충족하지 않습니다.

 

D. Amazon CloudFront를 사용하여 S3 버킷에 대한 모든 요청을 처리합니다.

→ CloudFront를 사용하면 엣지 로케이션을 통해 콘텐츠를 캐싱하고 전송할 수 있어 액세스 속도가 향상됩니다. 또한 S3 요청 비용을 줄일 수 있어 총 S3 비용을 절감할 수 있습니다. 캐싱을 통해 밀리초 단위 액세스가 가능하며, 데이터 전송 비용도 절감할 수 있습니다.

 

 

마지막 문제 살펴볼게요.

문제3

회사에서 Amazon EC2 인스턴스 플릿을 사용하여 온프레미스 데이터 소스에서 데이터를 수집하고 있습니다. 데이터는 JSON 형식이며 수집 속도는 최대 1MB/s입니다. EC2 인스턴스가 재부팅되면 진행 중인 데이터가 손실됩니다. 회사의 데이터 과학 팀은 거의 실시간으로 수집된 데이터를 쿼리하려고 합니다.

데이터 손실을 최소화하면서 확장 가능한 거의 실시간 데이터 쿼리를 제공하는 솔루션은 무엇입니까?

 

선택지

A. Amazon Kinesis Data Streams에 데이터를 게시하고 Kinesis Data Analytics를 사용하여 데이터를 쿼리합니다.

B. Amazon Redshift를 대상으로 사용하여 Amazon Kinesis Data Firehose에 데이터를 게시합니다. Amazon Redshift를 사용하여 데이터를 쿼리합니다.

C. 수집된 데이터를 EC2 인스턴스 스토어에 저장합니다. Amazon S3를 대상으로 Amazon Kinesis Data Firehose에 데이터를 게시합니다. Amazon Athena를 사용하여 데이터를 쿼리합니다.

D. 수집된 데이터를 Amazon Elastic Block Store(Amazon EBS) 볼륨에 저장합니다. Redis용 Amazon ElastiCache에 데이터를 게시합니다. Redis 채널을 구독하여 데이터를 쿼리합니다.

 

 

풀이

이 방법은 실시간 데이터 스트리밍과 쿼리를 제공합니다. Kinesis Data Streams는 데이터 지속성을 제공하여 EC2 재부팅 시 데이터 손실을 방지하며, Kinesis Data Analytics를 통해 실시간 쿼리가 가능합니다. 확장성도 뛰어나 요구사항을 잘 충족합니다.

정답 : A

 

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

더보기

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

  • EC2 인스턴스 플릿으로 온프레미스 데이터 소스에서 데이터 수집
  • JSON 형식의 데이터, 최대 수집 속도 1MB/s
  • EC2 인스턴스 재부팅 시 진행 중인 데이터 손실 문제
  • 거의 실시간으로 수집된 데이터 쿼리 필요
  • 데이터 손실 최소화 및 확장 가능한 솔루션 필요

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

  • Amazon Kinesis Data Streams:
    • 실시간 데이터 스트리밍 처리 서비스
    • 대규모 데이터 수집 및 처리 가능
    • 데이터 지속성 제공으로 데이터 손실 최소화
  • Amazon Kinesis Data Firehose:
    • 실시간 데이터 전송 서비스
    • 데이터를 S3, Redshift 등의 목적지로 자동 전송
  • Amazon Kinesis Data Analytics:
    • 스트리밍 데이터에 대한 실시간 분석 서비스
    • SQL 쿼리를 사용하여 스트리밍 데이터 분석 가능

3. 선택지 분석하기

A. Amazon Kinesis Data Streams에 데이터를 게시하고 Kinesis Data Analytics를 사용하여 데이터를 쿼리합니다.

→ 이 방법은 실시간 데이터 스트리밍과 쿼리를 제공합니다. Kinesis Data Streams는 데이터 지속성을 제공하여 EC2 재부팅 시 데이터 손실을 방지하며, Kinesis Data Analytics를 통해 실시간 쿼리가 가능합니다. 확장성도 뛰어나 요구사항을 잘 충족합니다.

 

B. Amazon Redshift를 대상으로 사용하여 Amazon Kinesis Data Firehose에 데이터를 게시합니다. Amazon Redshift를 사용하여 데이터를 쿼리합니다.

→ Kinesis Data Firehose와 Redshift의 조합은 데이터 손실을 최소화할 수 있지만, Redshift는 실시간 쿼리보다는 대규모 데이터 웨어하우징에 더 적합합니다. 거의 실시간 쿼리 요구사항을 완전히 충족하지 못할 수 있습니다.

 

C. 수집된 데이터를 EC2 인스턴스 스토어에 저장합니다. Amazon S3를 대상으로 Amazon Kinesis Data Firehose에 데이터를 게시합니다. Amazon Athena를 사용하여 데이터를 쿼리합니다.

→ EC2 인스턴스 스토어는 인스턴스 재부팅 시 데이터가 손실되므로 적합하지 않습니다. S3와 Athena의 조합은 쿼리 기능을 제공하지만, 완전한 실시간 쿼리는 아닙니다.

 

D. 수집된 데이터를 Amazon Elastic Block Store(Amazon EBS) 볼륨에 저장합니다. Redis용 Amazon ElastiCache에 데이터를 게시합니다. Redis 채널을 구독하여 데이터를 쿼리합니다.

→ EBS는 EC2 재부팅 시 데이터를 보존할 수 있지만, ElastiCache는 주로 캐싱용으로 사용되며 대규모 데이터 저장 및 쿼리에는 적합하지 않습니다. 확장성과 실시간 쿼리 요구사항을 완전히 충족하기 어렵습니다.

 

"아는 것을 안다고 하고 모르는 것을 모른다고 하는 것이 바로 앎이다." - 공자

저작자표시

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

AWS SAA 합격으로 가는 길 #27  (1) 2024.10.18
AWS SAA 합격으로 가는 길 #26  (0) 2024.10.14
AWS SAA 합격으로 가는 길 #24  (0) 2024.10.07
AWS SAA 합격으로 가는 길 #23  (0) 2024.10.04
AWS SAA 합격으로 가는 길 #22  (0) 2024.09.30

관련글

티스토리툴바