AWS SAA 합격으로 가는 길 #72

안녕하세요, NxtCloud SA 이수민입니다. AWS SAA 자격증 준비를 위한 실전 문제 풀이를 진행하겠습니다. 문제를 함께 다루며 AWS 서비스에 대한 이해도를 높이는 시간이 되길 바랍니다.

 

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

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

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

3. 선택지 분석하기

 

바로 문제 풀이 해보겠습니다!

---

문제1

회사에는 다양한 런타임으로 분당 최대 800회 AWS Lambda 함수를 호출하는 이벤트 기반 애플리케이션이 있습니다. Lambda 함수는 Amazon Aurora MySQL DB 클러스터에 저장된 데이터에 액세스합니다. 회사는 사용자 활동이 증가함에 따라 연결 시간 초과를 인지하고 있습니다. 데이터베이스는 과부하의 징후를 보이지 않습니다. CPU, 메모리 및 디스크 액세스 메트릭이 모두 낮습니다. 최소한의 운영 오버헤드로 이 문제를 해결하는 솔루션은 무엇입니까?

 

선택지

A. 더 많은 연결을 처리하려면 Aurora MySQL 노드의 크기를 조정하십시오. 데이터베이스 연결 시도에 대한 Lambda 함수의 재시도 논리를 구성합니다.

B. Redis용 Amazon ElastiCache를 설정하여 데이터베이스에서 일반적으로 읽은 항목을 캐시합니다. 읽기를 위해 ElastiCache에 연결하도록 Lambda 함수를 구성합니다.

C. Aurora 복제본을 리더 노드로 추가합니다. 라이터 엔드포인트가 아닌 DB 클러스터의 리더 엔드포인트에 연결하도록 Lambda 함수를 구성합니다.

D. Amazon RDS 프록시를 사용하여 프록시를 생성합니다. DB 클러스터를 대상 데이터베이스로 설정합니다. DB 클러스터가 아닌 프록시에 연결하도록 Lambda 함수를 구성합니다.

 

풀이

Amazon Aurora MySQL 클러스터에서 다중 AZ 아키텍처와 리더 노드를 활용하면 과도한 읽기 트래픽으로 인한 병목 현상을 완화할 수 있습니다. 리더 엔드포인트에 Lambda 함수를 연결하면 읽기 요청이 리더 노드로 분산되어 성능이 향상됩니다. RDS 프록시를 함께 사용하면 데이터베이스 연결 관리도 간소화되고 장애 조치 시 자동 연결 리디렉션이 가능합니다.

 

정답 : C

 

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

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

• 분당 최대 800회 AWS Lambda 함수 호출로 인한 Aurora MySQL 클러스터의 연결 시간 초과 문제
• 데이터베이스 과부하 징후 없음
• 최소한의 운영 오버헤드로 문제 해결

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

• Amazon Aurora는 MySQL 및 PostgreSQL과 호환되는 완전 관리형 관계형 데이터베이스 서비스입니다. Aurora 클러스터는 기본적으로 다중 AZ(가용성 영역) 아키텍처를 제공하여 고가용성을 보장합니다. 또한 읽기 전용 복제본(리더 노드)을 생성하여 읽기 트래픽을 분산시킬 수 있습니다. 리더 노드를 통해 읽기 워크로드를 오프로딩하면 쓰기 워크로드를 처리하는 기본 인스턴스의 부하를 줄일 수 있습니다.
• Amazon RDS 프록시는 Amazon RDS 데이터베이스와 애플리케이션 간의 연결을 관리하는 완전 관리형 서비스입니다. 연결 풀링 기능으로 데이터베이스 리소스 사용을 최적화하고 성능을 향상시킵니다. 또한 장애 조치 시에도 새로운 데이터베이스 인스턴스로 자동 연결 리디렉션이 가능합니다. RDS 프록시는 연결 관리를 간소화하고 운영 오버헤드를 줄여줍니다.

3. 선택지 분석하기

A. Aurora MySQL 노드의 크기를 조정하고 Lambda 함수에 재시도 논리를 구성합니다.

→ 데이터베이스 과부화가 아닌 과도한 읽기 트래픽 때문에 발생한 문제이므로, 노드의 크기를 늘리는 것만으로는 해결되지 않습니다. 또한 재시도 논리 구성은 운영 오버헤드를 발생시킵니다.

 

B. Amazon ElastiCache for Redis를 설정하고 Lambda 함수를 연결합니다.

→ 캐싱은 읽기 성능을 향상시킬 수 있지만, 모든 데이터를 캐시에 저장하기에는 한계가 있습니다. 또한 캐시 관리를 위한 운영 오버헤드가 추가로 발생합니다.

 

C. Aurora 복제본을 리더 노드로 추가하고 Lambda 함수를 리더 엔드포인트에 연결합니다.

→ Aurora 복제본을 추가하면 읽기 트래픽을 여러 노드로 분산시킬 수 있습니다. 리더 엔드포인트를 사용하면 모든 읽기 요청이 자동으로 여러 리더 노드로 분산되므로 연결 시간 초과 문제를 효과적으로 해결할 수 있습니다. 또한 관리형 서비스이므로 운영 오버헤드가 최소화됩니다.

 

D. Amazon RDS 프록시를 생성하고 Lambda 함수를 프록시에 연결합니다.

→ RDS 프록시는 데이터베이스 연결 관리를 효율화하지만, 읽기 트래픽 분산 기능은 제공하지 않습니다.

 

이어서 다음 문제입니다.

---

문제2

솔루션 아키텍트가 회사의 고객 대면 애플리케이션을 설계하고 있습니다. 응용 프로그램의 데이터베이스는 일년 내내 명확하게 정의된 액세스 패턴을 가지며 연중 시간에 따라 가변적인 읽기 및 쓰기 횟수를 갖게 됩니다. 회사는 데이터베이스에 대한 감사 기록을 7일 동안 보관해야 합니다. RPO(복구 지점 목표)는 5시간 미만이어야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

선택지

A. Auto Scaling과 함께 Amazon DynamoDB 사용 온디맨드 백업 및 Amazon DynamoDB 스트림을 사용합니다.

B. Amazon Redshift를 사용하십시오. 동시성 확장을 구성합니다. 감사 로깅을 활성화합니다. 4시간마다 데이터베이스 스냅샷을 수행합니다.

C. 프로비저닝된 IOPS와 함께 Amazon RDS 사용 데이터베이스 감사 매개변수 활성화 5시간마다 데이터베이스 스냅샷을 수행합니다.

D. Auto Scaling과 함께 Amazon Aurora MySQL을 사용합니다. 데이터베이스 감사 매개변수를 활성화하십시오.

 

풀이

이 문제의 요구사항을 모두 충족하려면 Amazon Aurora PostgreSQL 데이터베이스와 프로비저닝된 IOPS 스토리지를 사용해야 합니다. Aurora는 자동 스케일링과 고성능, 고가용성을 제공하므로 가변적 액세스 패턴에 잘 대응할 수 있습니다. 프로비저닝된 IOPS 스토리지를 사용하면 IO 성능을 보장할 수 있어 읽기/쓰기 처리량 요구사항을 만족시킬 수 있습니다. 또한 5시간 미만의 RPO를 달성하기 위해 5시간마다 스냅샷을 생성하면 됩니다.

 

정답 : C

 

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

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

• 연중 가변적인 읽기/쓰기 액세스 패턴
• 7일 동안 데이터베이스 감사 기록 보관
• RPO(복구 지점 목표) 5시간 미만

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

• Amazon DynamoDB는 완전 관리형 NoSQL 데이터베이스 서비스로, 자동 확장성과 높은 가용성을 제공합니다. 온디맨드 백업과 스트림을 통해 백업 및 감사 기능을 제공합니다. 하지만 프로비저닝된 처리량 모드에서는 사전에 처리량을 지정해야 하므로 가변적 액세스 패턴에 적합하지 않습니다.
• Amazon Redshift는 완전 관리형 페타바이트 규모의 데이터 웨어하우스 서비스입니다. 쿼리 성능과 확장성이 뛰어나지만, 주로 분석 워크로드에 사용되며 OLTP(온라인 트랜잭션 처리) 워크로드에는 적합하지 않습니다.
• Amazon Aurora는 완전 관리형 관계형 데이터베이스 서비스로, MySQL과 PostgreSQL 호환 엔진을 지원합니다. Auto Scaling을 통해 워크로드 변화에 자동으로 대응하고, 다중 AZ 아키텍처를 기반으로 높은 가용성과 내구성을 제공합니다. 또한 프로비저닝된 IOPS 스토리지를 지원하여 IO 성능을 보장할 수 있습니다. 데이터베이스 스냅샷을 통해 백업 및 복구 지점 생성이 가능합니다.

3. 선택지 분석하기

A. Amazon DynamoDB를 사용하고 온디맨드 백업 및 DynamoDB 스트림을 활용합니다.

→ DynamoDB는 프로비저닝된 처리량 모드에서 가변적 액세스 패턴 대응에 어려움이 있고, 5시간 미만의 RPO 달성도 어렵습니다.

 

B. Amazon Redshift를 사용하고 동시성 확장을 구성하며 4시간마다 스냅샷을 생성합니다.

→ Redshift는 데이터 웨어하우징 용도로 설계되어 있어 이 문제의 OLTP 워크로드에는 적합하지 않습니다.

 

C. 프로비저닝된 IOPS와 함께 Amazon Aurora MySQL을 사용하고 데이터베이스 감사 매개변수를 활성화하며 5시간마다 스냅샷을 생성합니다.

→ 프로비저닝된 IOPS를 사용하면 가변적 읽기/쓰기 액세스 패턴에 맞게 디스크 처리량을 보장할 수 있습니다. 데이터베이스 감사 매개변수를 활성화하면 7일 동안의 데이터베이스 감사 로그를 유지할 수 있고, 5시간마다 스냅샷을 생성하면 RPO 5시간 미만 요구사항을 충족할 수 있습니다.

 

D. Amazon Aurora MySQL을 사용하고 데이터베이스 감사 매개변수를 활성화합니다.

→ Aurora의 자동 스케일링만으로는 가변적 읽기/쓰기 처리량 요구사항을 만족시키기 어려우며, 5시간 미만 RPO도 달성할 수 없습니다.

 

마지막 문제 살펴볼게요.

---

문제3

회사는 EC2 인스턴스에서 실행되는 MySQL 데이터베이스를 사용하는 웹 사이트 분석 애플리케이션을 호스팅합니다. 사용량이 많은 시간대에 애플리케이션 성능이 저하되고 5xx 오류가 발생합니다. 솔루션 아키텍트는 비용 효율적인 방식으로 확장성을 향상시켜야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

선택지

A. RDS MySQL DB로 마이그레이션하고 AMI를 생성하여 두 번째 EC2 온디맨드 인스턴스를 시작하며 ELB로 로드 분산합니다.

B. RDS MySQL DB로 마이그레이션하고 AMI를 생성하여 두 번째 EC2 온디맨드 인스턴스를 시작하며 Route 53 가중치 기반 라우팅으로 로드 분산합니다.

C. Amazon Aurora MySQL DB로 마이그레이션하고 CloudWatch 경보로 Lambda 함수를 호출하여 EC2 인스턴스 유형을 변경합니다.

D. Amazon Aurora MySQL DB로 마이그레이션하고 AMI를 사용하여 Auto Scaling 그룹을 만들며 스팟 인스턴스를 활용하고 ELB에 연결합니다.

 

풀이

이 문제를 비용 효율적으로 해결하기 위해서는 기존 EC2 인스턴스를 Auto Scaling 그룹에 통합하고 스팟 인스턴스를 활용해야 합니다. 데이터베이스도 Aurora 클러스터로 마이그레이션하여 읽기 트래픽을 분산시키고 Auto Scaling 기능을 활용하면 됩니다. 또한 Application Load Balancer를 사용하여 트래픽을 효율적으로 분산시켜야 합니다.

 

정답 : D

 

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

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

• 웹 사이트 분석 애플리케이션 호스팅
• 사용량 많은 시간대에 성능 저하 및 5xx 오류 발생
• 비용 효율적인 방식으로 애플리케이션 확장성 확보

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

• Amazon EC2 Auto Scaling은 Amazon EC2 인스턴스의 수를 자동으로 조정하여 애플리케이션의 가용성을 유지하고 비용을 최적화합니다. Auto Scaling 그룹과 스팟 인스턴스를 결합하면 높은 확장성과 비용 절감 효과를 얻을 수 있습니다. 또한 Auto Scaling 그룹에 AMI(Amazon Machine Image)를 적용한 시작 템플릿을 사용하면 쉽게 인스턴스를 복제할 수 있습니다.
• Amazon RDS는 관리형 관계형 데이터베이스 서비스로 MySQL, PostgreSQL 등 다양한 엔진을 지원합니다. Amazon Aurora는 RDS와 호환되는 고성능 데이터베이스 엔진으로, 읽기 전용 복제본을 이용하면 읽기 트래픽을 분산시킬 수 있습니다. Aurora 클러스터는 자동으로 확장되므로 변화하는 워크로드에 대응할 수 있습니다.
• Elastic Load Balancing은 수신 트래픽을 여러 대상으로 자동 분산하여 애플리케이션의 내결함성을 높이고 트래픽 급증에도 대응할 수 있게 해줍니다. Application Load Balancer는 HTTP/HTTPS 트래픽에 최적화되어 있습니다.
• Amazon Route 53은 AWS 클라우드의 가용성과 확장성을 활용하여 안정적이고 비용 효율적인 도메인 이름 시스템(DNS) 웹 서비스를 제공합니다. 도메인 이름과 IP 주소 간 매핑을 제공하므로 트래픽 라우팅 및 로드 밸런싱에는 적합하지 않습니다.

3. 선택지 분석하기

A. RDS MySQL DB로 마이그레이션하고 AMI를 생성하여 두 번째 EC2 온디맨드 인스턴스를 시작하며 ELB로 로드 분산합니다.

→ 온디맨드 인스턴스 사용으로 비용 효율성이 낮고, EC2 인스턴스 수동 확장을 통한 운영 오버헤드가 발생합니다.

 

B. RDS MySQL DB로 마이그레이션하고 AMI를 생성하여 두 번째 EC2 온디맨드 인스턴스를 시작하며 Route 53 가중치 기반 라우팅으로 로드 분산합니다.

→ A와 마찬가지로 온디맨드 인스턴스를 사용하고 수동 확장이 필요한 단점이 있습니다. 또한 Route 53은 DNS 라우팅 용도로 적합하지만 로드 밸런싱에는 적절하지 않습니다.

 

C. Amazon Aurora MySQL DB로 마이그레이션하고 CloudWatch 경보로 Lambda 함수를 호출하여 EC2 인스턴스 유형을 변경합니다.

→ EC2 인스턴스 유형 변경으로는 읽기 트래픽 분산이 어렵고 운영 오버헤드가 발생합니다. 또한 애플리케이션 확장성에 한계가 있습니다.

 

D. Amazon Aurora MySQL DB로 마이그레이션하고 AMI를 사용하여 Auto Scaling 그룹을 만들며 스팟 인스턴스를 활용하고 ELB에 연결합니다.

→ Aurora는 기존 MySQL 데이터베이스보다 성능이 우수하고, Auto Scaling 그룹과 스팟 인스턴스를 활용하면 트래픽 변동에 자동으로 대응하면서 비용을 최소화할 수 있습니다. ELB를 통한 로드 밸런싱으로 가용성이 향상되며, 완전 관리형 서비스로 운영 오버헤드가 최소화됩니다.

 

감사합니다