AWS SAA 합격으로 가는 길 #106

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

오늘 준비한 문제들이 여러분의 SAA 합격에 든든한 디딤돌이 되길 바라며, 함께 시작해볼까요?

 

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

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

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

3. 선택지 분석하기

 

바로 문제 풀이 해볼까요?

---

문제1

한 회사가 AWS 클라우드에서 3계층 전자상거래 애플리케이션을 호스팅하고 있습니다. 회사는 Amazon S3에서 웹사이트를 호스팅하고 웹사이트를 판매 요청을 처리하는 API와 통합합니다. 이 회사는 ALB(Application Load Balancer) 뒤에 있는 3개의 Amazon EC2 인스턴스에서 API를 호스팅합니다. API는 판매 요청을 비동기식으로 처리하는 백엔드 작업자와 함께 정적 및 동적 프런트 엔드 콘텐츠로 구성됩니다. 회사는 신제품 출시 이벤트 기간 동안 판매 요청 건수가 급격하게 급증할 것으로 예상하고 있습니다.

모든 요청이 성공적으로 처리되도록 하려면 솔루션 설계자가 무엇을 권장해야 합니까?

 

선택지

A. 동적 콘텐츠에 대한 Amazon CloudFront 배포를 추가합니다. 트래픽 증가를 처리하기 위해 EC2 인스턴스 수를 늘립니다.

B. 정적 콘텐츠에 대한 Amazon CloudFront 배포를 추가합니다. Auto Scaling 그룹에 EC2 인스턴스를 배치하여 네트워크 트래픽을 기반으로 새 인스턴스를 시작합니다.

C. 동적 콘텐츠에 대한 Amazon CloudFront 배포를 추가합니다. ALB 앞에 Amazon ElastiCache 인스턴스를 추가하여 API가 처리할 트래픽을 줄입니다.

D. 정적 콘텐츠에 대한 Amazon CloudFront 배포를 추가합니다. Amazon Simple Queue Service(Amazon SQS) 대기열을 추가하여 나중에 EC2 인스턴스에서 처리할 수 있도록 웹 사이트에서 요청을 수신합니다.

---

풀이

전자상거래 애플리케이션에서 급증하는 트래픽을 처리하려면 정적 콘텐츠 캐싱과 비동기 메시지 처리가 핵심입니다. CloudFront를 통해 정적 콘텐츠 부하를 줄이고, SQS를 통해 판매 요청을 큐에 저장하여 순차적으로 처리함으로써 모든 요청의 성공적인 처리를 보장할 수 있습니다.

 

정답 : D

 

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

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

• 신제품 출시 이벤트로 인한 급격한 트래픽 증가 예상
• 모든 판매 요청이 성공적으로 처리되어야 함
• 3계층 아키텍처에서 정적/동적 콘텐츠 분리 처리 필요

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

• Amazon CloudFront는 AWS의 콘텐츠 전송 네트워크(CDN) 서비스로, 정적 콘텐츠를 엣지 로케이션에 캐싱하여 빠르게 전송할 수 있습니다. 동적 콘텐츠는 실시간으로 생성되므로 캐싱에 적합하지 않습니다. Amazon SQS는 완전 관리형 메시지 큐 서비스로, 분산 애플리케이션에서 데이터 전송과 처리를 분리하여 확장성과 가용성을 높일 수 있습니다. 특히 급증하는 트래픽 상황에서 요청을 큐에 저장하고 백엔드 시스템이 처리 가능한 속도로 순차적으로 처리할 수 있어 시스템 안정성을 보장합니다. 이벤트 기반 비동기 처리 아키텍처에 매우 적합합니

3. 선택지 분석하기

A. 동적 콘텐츠에 대한 Amazon CloudFront 배포를 추가합니다.

→ 동적 콘텐츠는 실시간으로 생성되므로 CloudFront 캐싱에 적합하지 않으며, 단순히 EC2 인스턴스 수를 늘리는 것은 비용 효율적이지 않습니다.

B. 정적 콘텐츠에 대한 Amazon CloudFront 배포를 추가합니다. Auto Scaling 그룹에 EC2 인스턴스를 배치합니다.

→ CloudFront를 통한 정적 콘텐츠 최적화는 적절하지만, Auto Scaling만으로는 급격한 트래픽 증가 시 모든 요청의 성공적인 처리를 보장하기 어렵습니다.

C. 동적 콘텐츠에 대한 Amazon CloudFront 배포를 추가합니다.

→ 동적 콘텐츠에 CloudFront를 사용하는 것은 부적절하며, ElastiCache는 데이터 캐싱 용도로 트래픽 증가 문제 해결에 직접적인 도움이 되지 않습니다.

D. 정적 콘텐츠에 대한 Amazon CloudFront 배포를 추가합니다. Amazon SQS 대기열을 추가합니다.

→ CloudFront로 정적 콘텐츠 부하를 줄이고, SQS로 판매 요청을 큐에 저장하여 백엔드에서 안정적으로 순차 처리할 수 있어 모든 요청의 성공적인 처리를 보장합니다.

 

이어서 다음 문제입니다.

---

문제2

회사에서 AWS에 웹 애플리케이션을 배포했습니다. 이 회사는 조정 요구 사항을 지원하기 위해 기본 DB 인스턴스와 5개의 읽기 전용 복제본을 사용하여 MySQL용 Amazon RDS에서 백엔드 데이터베이스를 호스팅합니다. 읽기 전용 복제본은 기본 DB 인스턴스보다 1초 이상 뒤처져서는 안 됩니다. 데이터베이스는 정기적으로 예약된 저장 프로시저를 실행합니다. 웹 사이트의 트래픽이 증가함에 따라 복제본은 피크 로드 기간 동안 추가 지연을 경험합니다. 솔루션 설계자는 복제 지연을 최대한 줄여야 합니다. 솔루션 설계자는 애플리케이션 코드에 대한 변경을 최소화하고 지속적인 운영 오버헤드를 최소화해야 합니다.

이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. 데이터베이스를 Amazon Aurora MySQL로 마이그레이션합니다. 읽기 전용 복제본을 Aurora 복제본으로 교체하고 Aurora Auto Scaling을 구성합니다. 저장 프로시저를 Aurora MySQL 기본 함수로 바꿉니다.

B. 데이터베이스 앞에 Redis 클러스터용 Amazon ElastiCache를 배포합니다. 응용 프로그램이 데이터베이스를 쿼리하기 전에 캐시를 확인하도록 응용 프로그램을 수정하십시오. 저장 프로시저를 AWS Lambda 함수로 바꿉니다.

C. 데이터베이스를 Amazon EC2 인스턴스에서 실행되는 MySQL 데이터베이스로 마이그레이션합니다. 모든 복제본 노드에 대해 컴퓨팅에 최적화된 대규모 EC2 인스턴스를 선택합니다. EC2 인스턴스에서 저장 프로시저를 유지합니다.

D. 데이터베이스를 Amazon DynamoDB로 마이그레이션합니다. 필요한 처리량을 지원하고 온디맨드 용량 확장을 구성하기 위해 많은 수의 RCU(읽기 용량 단위)를 프로비저닝합니다. 저장 프로시저를 DynamoDB 스트림으로 바꿉니다.

---

풀이

Amazon Aurora MySQL은 MySQL과 호환되는 클라우드 네이티브 관리형 데이터베이스 서비스입니다. Aurora의 고성능 저지연 복제 기술과 Auto Scaling 기능을 통해 복제 지연 문제를 해결하고, MySQL 호환성으로 애플리케이션 코드 변경을 최소화하며, 완전 관리형 서비스로 운영 오버헤드를 크게 줄일 수 있습니다.

 

정답 : A

 

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

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

• 읽기 전용 복제본의 복제 지연 최소화 (1초 이내)
• 애플리케이션 코드 변경 최소화
• 지속적인 운영 오버헤드 최소화
• 저장 프로시저 호환성 유지

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

• Amazon Aurora MySQL은 AWS 클라우드 환경에 최적화된 클라우드 네이티브 관리형 데이터베이스 서비스입니다. Aurora는 MySQL과 완전 호환되는 엔진을 제공하며, 기존 MySQL 애플리케이션을 거의 수정 없이 마이그레이션할 수 있습니다. Aurora의 클러스터 아키텍처는 기본 인스턴스와 최대 15개의 읽기 전용 복제본으로 구성되며, 공유 스토리지 볼륨을 통해 거의 실시간으로 데이터를 동기화하여 복제 지연을 최소화합니다. Aurora Auto Scaling을 활성화하면 읽기 워크로드에 맞춰 읽기 전용 복제본의 개수를 자동으로 조정할 수 있어 성능과 비용을 동시에 최적화할 수 있습니다.

3. 선택지 분석하기

A. 데이터베이스를 Amazon Aurora MySQL로 마이그레이션합니다.

→ Aurora는 고성능 저지연 복제 기술을 제공하며, Auto Scaling으로 부하에 따라 복제본을 자동 조절할 수 있어 복제 지연 문제를 최소한의 코드 변경과 운영 오버헤드로 해결할 수 있습니다.

B. 데이터베이스 앞에 Redis 클러스터용 Amazon ElastiCache를 배포합니다.

→ ElastiCache는 캐싱을 통해 읽기 성능을 향상시킬 수 있지만, 복제 지연 자체를 해결하지는 못하며, 애플리케이션 코드의 대폭적인 수정이 필요합니다.

C. 데이터베이스를 Amazon EC2 인스턴스에서 실행되는 MySQL 데이터베이스로 마이그레이션합니다.

→ 자체 관리형 MySQL로 마이그레이션하면 운영 오버헤드가 크게 증가하고, 복제 지연 문제를 근본적으로 해결하기 어렵습니다.

D. 데이터베이스를 Amazon DynamoDB로 마이그레이션합니다.

→ DynamoDB는 NoSQL 데이터베이스로 MySQL과 완전히 다른 데이터 모델을 사용하므로, 애플리케이션 코드를 대폭 수정해야 하고 저장 프로시저 기능을 대체하기 어렵습니다.

 

 

마지막 문제 살펴볼게요.

---

문제3

회사는 Amazon EC2 인스턴스에서 실행되는 RESTful 웹 서비스 애플리케이션을 사용하여 수천 개의 원격 장치에서 데이터를 수집합니다. EC2 인스턴스는 원시 데이터를 수신하고 원시 데이터를 변환하며 모든 데이터를 Amazon S3 버킷에 저장합니다. 원격 장치의 수는 곧 수백만 개로 증가할 것입니다. 이 회사는 운영 오버헤드를 최소화하는 확장성이 뛰어난 솔루션이 필요합니다.

이러한 요구 사항을 충족하기 위해 솔루션 설계자는 어떤 단계 조합을 수행해야 합니까? (두 가지를 선택하세요.)

 

선택지

A. AWS Glue를 사용하여 Amazon S3에서 원시 데이터를 처리합니다.

B. Amazon Route 53을 사용하여 트래픽을 다른 EC2 인스턴스로 라우팅합니다.

C. 들어오는 데이터의 양을 수용하기 위해 더 많은 EC2 인스턴스를 추가합니다.

D. 원시 데이터를 Amazon Simple Queue Service(Amazon SQS)로 보냅니다. EC2 인스턴스를 사용하여 데이터를 처리합니다.

E. Amazon API Gateway를 사용하여 원시 데이터를 Amazon Kinesis 데이터 스트림으로 보냅니다. 데이터 스트림을 소스로 사용하여 데이터를 Amazon S3에 전달하도록 Amazon Kinesis Data Firehose를 구성합니다.

 

풀이

수백만 개의 원격 장치에서 데이터를 수집하는 시스템에서는 실시간 스트리밍 데이터 처리와 배치 데이터 처리 아키텍처가 필요합니다. API Gateway와 Kinesis를 통한 실시간 스트리밍 데이터 수집과 AWS Glue를 통한 서버리스 데이터 처리를 결합하여 운영 오버헤드를 최소화하면서 확장성을 확보할 수 있습니다.

 

정답 : A,E

 

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

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

• 원격 장치 수가 수천 개에서 수백만 개로 대폭 증가 예정
• 운영 오버헤드 최소화 필요
• 높은 확장성이 요구되는 솔루션
• 데이터 수집, 변환, 저장 과정의 최적화

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

• Amazon API Gateway는 완전 관리형 API 서비스로 수백만 개의 동시 API 호출을 처리할 수 있으며, 자동 확장과 DDoS 보호 기능을 제공합니다. Amazon Kinesis Data Streams는 실시간 스트리밍 데이터를 수집하고 처리할 수 있는 서비스로, 대규모 데이터 스트림을 안정적으로 수집할 수 있습니다. Amazon Kinesis Data Firehose는 스트리밍 데이터를 자동으로 S3, Redshift 등으로 전달하는 완전 관리형 서비스로, 데이터 변환과 압축도 수행할 수 있습니다. AWS Glue는 완전 관리형 ETL 서비스로, S3에 저장된 대용량 데이터를 서버리스 방식으로 처리하고 변환할 수 있어 운영 오버헤드가 매우 낮습니다.

3. 선택지 분석하기

A. AWS Glue를 사용하여 Amazon S3에서 원시 데이터를 처리합니다.

→ AWS Glue는 완전 관리형 ETL 서비스로 서버리스 방식으로 대용량 데이터를 처리할 수 있어 운영 오버헤드를 최소화하면서 확장성을 제공합니다.

B. Amazon Route 53을 사용하여 트래픽을 다른 EC2 인스턴스로 라우팅합니다.

→ Route 53은 DNS 서비스로 데이터 수집 아키텍처의 확장성 문제 해결에 직접적인 도움이 되지 않습니다.

C. 들어오는 데이터의 양을 수용하기 위해 더 많은 EC2 인스턴스를 추가합니다.

→ 단순히 EC2 인스턴스를 추가하는 것은 운영 오버헤드를 증가시키며, 확장성 측면에서도 비효율적입니다.

D. 원시 데이터를 Amazon SQS로 보냅니다. EC2 인스턴스를 사용하여 데이터를 처리합니다.

→ SQS는 메시지 큐 서비스로 유용하지만, EC2 인스턴스를 계속 사용하면 운영 오버헤드가 증가합니다.

E. Amazon API Gateway를 사용하여 원시 데이터를 Amazon Kinesis 데이터 스트림으로 보냅니다.

→ API Gateway와 Kinesis를 통한 실시간 스트리밍 데이터 수집은 수백만 개의 장치에서 발생하는 대용량 데이터를 효율적으로 처리할 수 있는 확장성 높은 솔루션입니다.

 

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