AWS SAA 합격으로 가는 길 #109

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

 

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

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

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

3. 선택지 분석하기

 

바로 문제 풀이 해볼까요?

---

문제1

회사는 AWS Lambda와 통합된 Amazon API Gateway API 백엔드를 사용하는 프런트엔드 애플리케이션을 호스팅합니다. API가 요청을 받으면 Lambda 함수는 많은 라이브러리를 로드합니다. 그런 다음 Lambda 함수는 Amazon RDS 데이터베이스에 연결하여 데이터를 처리하고 프런트엔드 애플리케이션에 데이터를 반환합니다. 회사는 회사 운영에 대한 변경 횟수를 최소화하면서 모든 사용자의 응답 대기 시간을 가능한 한 낮추고자 합니다.

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

 

선택지

A. API를 우회하여 쿼리 속도를 높이려면 프런트엔드 애플리케이션과 데이터베이스 사이에 연결을 설정합니다.

B. 요청을 처리하는 Lambda 함수에 대해 프로비저닝된 동시성을 구성합니다.

C. 유사한 데이터 세트를 더 빠르게 검색하기 위해 쿼리 결과를 Amazon S3에 캐시합니다.

D. Lambda가 한 번에 설정할 수 있는 연결 수를 늘리려면 데이터베이스 크기를 늘입니다.

 

풀이

Lambda 함수의 콜드 스타트 문제를 해결하기 위해서는 프로비저닝된 동시성이 핵심입니다. 많은 라이브러리를 로드하는 Lambda 함수는 초기화 시간이 길어지는데, 프로비저닝된 동시성을 통해 미리 준비된 실행 환경을 유지하면 응답 대기 시간을 크게 단축할 수 있으며, 운영상 변경도 최소화할 수 있습니다.

정답 : B

 

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

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

• Lambda 함수가 많은 라이브러리를 로드하여 초기화 시간이 오래 걸림
• 모든 사용자의 응답 대기 시간 최소화 필요
• 회사 운영에 대한 변경 횟수 최소화

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

• AWS Lambda의 프로비저닝된 동시성(Provisioned Concurrency)은 Lambda 함수의 콜드 스타트 문제를 해결하는 핵심 기능입니다. 일반적으로 Lambda 함수는 요청이 올 때마다 새로운 실행 환경을 초기화하는데, 이 과정에서 라이브러리 로딩, 데이터베이스 연결 설정 등으로 인해 지연이 발생합니다. 특히 많은 라이브러리를 로드하는 함수의 경우 이런 초기화 시간이 수 초에 이를 수 있습니다. 프로비저닝된 동시성을 구성하면 지정된 수만큼의 실행 환경을 미리 초기화하여 대기 상태로 유지합니다. 이렇게 하면 요청이 들어왔을 때 즉시 함수를 실행할 수 있어 응답 시간을 대폭 단축할 수 있습니다. 또한 이는 Lambda 서비스 차원의 설정 변경이므로 애플리케이션 코드나 인프라 아키텍처를 변경할 필요가 없어 운영 변경을 최소화할 수 있습니다.

3. 선택지 분석하기

A. API를 우회하여 쿼리 속도를 높이려면 프런트엔드 애플리케이션과 데이터베이스 사이에 연결을 설정합니다.

→ 프런트엔드에서 직접 데이터베이스에 접근하는 것은 보안상 매우 위험하며, 데이터베이스 자격 증명 노출 등의 문제가 발생할 수 있습니다.

B. 요청을 처리하는 Lambda 함수에 대해 프로비저닝된 동시성을 구성합니다.

→ 프로비저닝된 동시성을 통해 콜드 스타트를 제거하여 응답 시간을 크게 단축할 수 있으며, 운영 변경도 최소화됩니다.

C. 유사한 데이터 세트를 더 빠르게 검색하기 위해 쿼리 결과를 Amazon S3에 캐시합니다.

→ S3는 객체 스토리지로 캐싱 용도로는 부적합하며, 캐시 구현을 위해서는 상당한 아키텍처 변경이 필요합니다.

D. Lambda가 한 번에 설정할 수 있는 연결 수를 늘리려면 데이터베이스 크기를 늘입니다.

→ 데이터베이스 크기 증가는 연결 수 문제를 해결하지 못하며, 콜드 스타트로 인한 지연 시간도 개선되지 않습니다.

 

이어서 다음 문제입니다.

---

문제2

회사는 단일 가용 영역의 Amazon RDS for MySQL DB 인스턴스에 저장된 온라인 광고 비즈니스용 대규모 데이터 세트를 보유하고 있습니다. 회사는 프로덕션 DB 인스턴스에 대한 쓰기 작업에 영향을 주지 않고 비즈니스 보고 쿼리를 실행하기를 원합니다.

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

 

선택지

A. RDS 읽기 복제본을 배포하여 비즈니스 보고 쿼리를 처리합니다.

B. DB 인스턴스를 Elastic Load Balancer 뒤에 배치하여 수평으로 확장합니다.

C. DB 인스턴스를 더 큰 인스턴스 유형으로 확장하여 쓰기 작업 및 쿼리를 처리합니다.

D. 비즈니스 보고 쿼리를 처리하기 위해 여러 가용 영역에 DB 인스턴스를 배포합니다.

 

풀이

프로덕션 데이터베이스의 쓰기 성능에 영향을 주지 않으면서 읽기 워크로드를 분산하려면 RDS 읽기 복제본이 최적의 솔루션입니다. 읽기 복제본은 마스터 DB와 비동기적으로 데이터를 복제하여 읽기 전용 쿼리를 별도로 처리할 수 있게 해주므로, 비즈니스 보고 쿼리로 인한 프로덕션 시스템 부하를 완전히 분리할 수 있습니다.

정답 : A

 

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

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

• 단일 AZ의 Amazon RDS MySQL에 대규모 데이터 세트 저장
• 프로덕션 DB의 쓰기 작업에 영향 없이 비즈니스 보고 쿼리 실행 필요
• 읽기 워크로드와 쓰기 워크로드의 분리 필요

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

• Amazon RDS 읽기 복제본(Read Replica)은 마스터 DB 인스턴스의 데이터를 비동기적으로 복제하여 읽기 전용 데이터베이스 인스턴스를 생성하는 기능입니다. 읽기 복제본은 마스터 DB와 별개의 엔드포인트를 가지며, 읽기 전용 쿼리만 처리할 수 있습니다. 이를 통해 프로덕션 시스템의 쓰기 성능에 전혀 영향을 주지 않으면서 대용량 분석 쿼리나 보고서 생성 작업을 수행할 수 있습니다. RDS MySQL의 경우 최대 5개의 읽기 복제본을 생성할 수 있으며, 각 복제본은 마스터 DB와 동일한 구성을 가집니다. 읽기 복제본은 다른 AZ나 심지어 다른 리전에도 생성할 수 있어 지리적 분산과 재해 복구 목적으로도 활용할 수 있습니다.

3. 선택지 분석하기

A. RDS 읽기 복제본을 배포하여 비즈니스 보고 쿼리를 처리합니다.

→ 읽기 복제본을 통해 읽기 워크로드를 완전히 분리하여 프로덕션 DB의 쓰기 성능에 영향을 주지 않으면서 보고 쿼리를 처리할 수 있습니다.

B. DB 인스턴스를 Elastic Load Balancer 뒤에 배치하여 수평으로 확장합니다.

→ ELB는 애플리케이션 트래픽을 분산하는 서비스로, 단일 데이터베이스 인스턴스의 부하 분산에는 사용할 수 없습니다.

C. DB 인스턴스를 더 큰 인스턴스 유형으로 확장하여 쓰기 작업 및 쿼리를 처리합니다.

→ 수직 확장(scale-up)은 전체적인 성능을 향상시킬 수 있지만, 쓰기와 읽기 워크로드가 여전히 동일한 인스턴스에서 경합하므로 근본적인 해결책이 되지 않습니다.

D. 비즈니스 보고 쿼리를 처리하기 위해 여러 가용 영역에 DB 인스턴스를 배포합니다.

→ 다중 AZ 배포는 고가용성을 위한 것으로, 읽기 워크로드 분산이나 성능 향상과는 직접적인 관련이 없습니다.

 

마지막 문제 살펴볼게요.

---

문제3

솔루션 설계자는 고객 사례 파일을 저장할 시스템을 설계해야 합니다. 파일은 핵심 회사 자산이며 중요합니다. 파일 수는 시간이 지남에 따라 증가합니다. 파일은 Amazon EC2 인스턴스에서 실행되는 여러 애플리케이션 서버에서 동시에 액세스할 수 있어야 합니다. 솔루션에는 중복성이 내장되어 있어야 합니다.

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

 

선택지

A. Amazon Elastic File System(Amazon EFS)

B. Amazon Elastic Block Store(Amazon EBS)

C. Amazon S3 Glacier Deep Archive

D. AWS Backup

 

풀이

여러 EC2 인스턴스에서 동시에 액세스해야 하는 파일 스토리지 요구사항에는 Amazon EFS가 최적의 솔루션입니다. EFS는 완전 관리형 NFS 기반 파일 시스템으로, 여러 인스턴스에서 동시 접근이 가능하며, 자동으로 확장되고 내장된 중복성을 통해 높은 내구성과 가용성을 제공합니다.

정답 : A

 

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

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

• 중요한 고객 사례 파일 저장 시스템 필요
• 시간이 지남에 따라 증가하는 파일 수에 대응
• 여러 EC2 인스턴스에서 동시 액세스 가능해야 함
• 내장된 중복성으로 높은 내구성 보장

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

• Amazon EFS(Elastic File System)는 Amazon EC2와 함께 사용할 수 있는 간단하고 확장 가능한 완전 관리형 엘라스틱 NFS 파일 시스템입니다. EFS의 핵심 장점은 여러 EC2 인스턴스에서 동시에 마운트하여 공유 파일 스토리지로 사용할 수 있다는 점입니다. EFS는 사용한 만큼만 비용을 지불하는 탄력적 확장 방식으로 작동하며, 페타바이트 규모까지 자동으로 확장됩니다. 또한 여러 가용 영역에 걸쳐 데이터를 자동으로 복제하여 99.999999999%(11 9's)의 내구성을 제공합니다. POSIX 호환 파일 시스템으로 기존 애플리케이션과의 호환성도 뛰어나며, 암호화 및 액세스 제어 기능도 내장되어 있어 중요한 비즈니스 파일을 안전하게 저장할 수 있습니다.

3. 선택지 분석하기

A. Amazon Elastic File System(Amazon EFS)

→ 여러 EC2 인스턴스에서 동시 액세스가 가능하며, 자동 확장과 내장된 중복성을 제공하여 모든 요구사항을 완벽하게 충족합니다.

B. Amazon Elastic Block Store(Amazon EBS)

→ EBS는 블록 레벨 스토리지로 한 번에 하나의 EC2 인스턴스에만 연결할 수 있어 동시 액세스 요구사항을 충족하지 못합니다.

C. Amazon S3 Glacier Deep Archive

→ 장기 아카이빙을 위한 스토리지 클래스로, 자주 액세스하는 고객 사례 파일에는 부적합하며 검색 시간도 매우 깁니다.

D. AWS Backup

→ 백업 및 복원 서비스로 파일 스토리지 시스템 자체가 아니라 기존 스토리지 서비스의 백업을 관리하는 도구입니다.

 

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