안녕하세요! 넥스트클라우드 솔루션 아키텍트 백종훈입니다.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 RDS 프록시는 데이터베이스와 애플리케이션 간의 연결 풀링을 제공하여 연결 시간 초과 문제를 해결할 수 있습니다. 운영 오버헤드를 최소화하면서도 데이터베이스 연결을 효율적으로 관리할 수 있어 요구사항을 가장 잘 충족합니다.
정답 : D
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 다양한 런타임으로 분당 최대 800회 Lambda 함수를 호출
- Lambda 함수가 Aurora MySQL DB 클러스터에 액세스
- 사용자 활동 증가로 연결 시간 초과 발생
- 데이터베이스는 과부하 징후 없음
- 최소한의 운영 오버헤드로 문제 해결
2. 관련 AWS 서비스 생각하기
- AWS Lambda: 서버리스 컴퓨팅 서비스로, 이벤트 기반 애플리케이션에 적합합니다.
- Amazon Aurora MySQL: 완전 관리형 MySQL 호환 데이터베이스 서비스로, 높은 성능과 가용성을 제공합니다.
- Amazon ElastiCache for Redis: 인 메모리 데이터 스토어 서비스로, 데이터베이스 부하를 줄이고 성능을 개선할 수 있습니다.
- Amazon RDS 프록시: RDS 데이터베이스와 애플리케이션 간 연결 풀링을 제공하여 연결 오버헤드를 줄입니다.
3. 선택지 분석하기
A. Aurora MySQL 노드의 크기를 조정하고 재시도 논리를 구성합니다.
→ 데이터베이스가 과부하 상태가 아니므로 불필요한 작업이며, 운영 오버헤드가 증가할 수 있습니다.
B. ElastiCache를 설정하고 Lambda 함수를 ElastiCache에 연결하도록 구성합니다.
→ 읽기 성능은 개선될 수 있지만, 연결 시간 초과 문제를 근본적으로 해결하지는 못합니다.
C. Aurora 복제본을 리더 노드로 추가하고 Lambda 함수를 리더 엔드포인트에 연결하도록 구성합니다.
→ 읽기 성능은 개선될 수 있지만, 연결 시간 초과 문제를 근본적으로 해결하지는 못합니다.
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을 사용합니다. 데이터베이스 감사 매개변수를 활성화하십시오.
풀이
이 문제는 프로비저닝된 IOPS를 사용하는 Amazon RDS와 5시간마다 스냅샷을 수행하는 것이 가장 적합합니다. RDS는 데이터베이스 감사 매개변수를 활성화하여 7일 동안 감사 기록을 보관할 수 있습니다. 5시간마다 스냅샷을 수행하면 5시간 미만의 RPO를 달성할 수 있습니다.
정답 : C
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 고객 대면 애플리케이션의 데이터베이스
- 연중 시간별로 가변적인 읽기/쓰기 액세스 패턴
- 7일 동안 감사 기록 보관
- RPO는 5시간 미만
2. 관련 AWS 서비스 생각하기
- Amazon DynamoDB: NoSQL 데이터베이스 서비스로, 온디맨드 백업과 스트림을 지원합니다.
- Amazon Redshift: 완전 관리형 페타바이트 규모의 데이터 웨어하우스 서비스입니다.
- Amazon RDS: 관계형 데이터베이스 서비스로, 프로비저닝된 IOPS를 지원하고 감사 로깅과 자동 백업을 제공합니다.
- Amazon Aurora: 완전 관리형 MySQL 및 PostgreSQL 호환 데이터베이스 서비스입니다.
3. 선택지 분석하기
A. DynamoDB를 사용하고 온디맨드 백업과 DynamoDB 스트림을 활용합니다.
→ DynamoDB는 감사 기록 보관과 RPO 요구사항을 충족하기 어렵습니다.
B. Redshift를 사용하고 동시성 확장, 감사 로깅, 4시간마다 스냅샷을 수행합니다.
→ Redshift는 데이터 웨어하우징에 적합하지만, 고객 대면 애플리케이션에는 과하게 규모가 큽니다. RPO 요구사항도 충족하지 못합니다.
C. RDS를 사용하고 프로비저닝된 IOPS, 감사 매개변수 활성화, 5시간마다 스냅샷을 수행합니다.
→ RDS는 감사 기록 보관과 RPO 요구사항을 모두 충족하며, 액세스 패턴 변동에 대응할 수 있는 프로비저닝된 IOPS를 제공합니다.
D. Aurora MySQL을 사용하고 감사 매개변수를 활성화합니다.
→ Aurora는 감사 기록 보관 요구사항은 충족하지만, RPO 요구사항을 충족하지 못합니다.
마지막 문제 살펴볼게요.
문제3
회사는 단일 Amazon EC2 온디맨드 인스턴스에서 웹 사이트 분석 애플리케이션을 호스팅합니다. 분석 소프트웨어는 PHP로 작성되었으며 MySQL 데이터베이스를 사용합니다. 분석 소프 트웨어, PHP를 제공하는 웹 서버 및 데이터베이스 서버는 모두 EC2 인스턴스에서 호스팅됩니다. 애플리케이션이 사용량이 많은 시간 동안 성능 저하의 징후를 보이고 있으며 5xx 오류를 표 시하고 있습니다. 회사는 애플리케이션을 원활하게 확장해야 합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?
선택지
A. 데이터베이스를 Amazon RDS for MySQL DB 인스턴스로 마이그레이션합니다. 웹 애플리케이션의 AMI를 생성합니다. AMI를 사용하여 두 번째 EC2 온디맨드 인스턴스를 시작합 니다. Application Load Balancer를 사용하여 각 EC2 인스턴스에 로드를 분산합니다.
B. 데이터베이스를 Amazon RDS for MySQL DB 인스턴스로 마이그레이션합니다. 웹 애플리케이션의 AMI를 생성합니다. AMI를 사용하여 두 번째 EC2 온디맨드 인스턴스를 시작합 니다. Amazon Route 53 가중 라우팅을 사용하여 2개의 EC2 인스턴스에 로드를 분산합니다.
C. 데이터베이스를 Amazon Aurora MySQL DB 인스턴스로 마이그레이션합니다. EC2 인스턴스를 중지하고 인스턴스 유형을 변경하는 AWS Lambda 함수를 생성합니다. CPU 사용 률이 75%를 초과하면 Lambda 함수를 호출하는 Amazon CloudWatch 경보를 생성합니다.
D. 데이터베이스를 Amazon Aurora MySQL DB 인스턴스로 마이그레이션합니다. 웹 애플리케이션의 AMI를 생성합니다. 시작 템플릿에 AMI를 적용합니다. 시작 템플릿으로 Auto Scaling 그룹 생성 스팟 플릿을 사용하도록 시작 템플릿을 구성합니다. Application Load Balancer를 Auto Scaling 그룹에 연결합니다
풀이
이 문제에서는 Amazon Aurora MySQL DB 인스턴스로 데이터베이스를 마이그레이션하고, 웹 애플리케이션의 AMI를 생성하여 Auto Scaling 그룹을 구성하는 것이 가장 적합합니다. Auto Scaling 그룹은 트래픽 증가에 따라 자동으로 확장되며, 스팟 플릿을 사용하여 비용을 절감할 수 있습니다. Application Load Balancer를 사용하여 로드를 분산시키면 애플리케이션의 원활한 확장이 가능해집니다.
정답 : D
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 단일 EC2 인스턴스에서 웹 사이트 분석 애플리케이션 호스팅
- PHP 웹 애플리케이션과 MySQL 데이터베이스 사용
- 사용량이 많은 시간 동안 성능 저하와 5xx 오류 발생
- 애플리케이션을 원활하게 확장
- 비용 효율적인 솔루션 필요
2. 관련 AWS 서비스 생각하기
- Amazon RDS for MySQL: 완전 관리형 MySQL 데이터베이스 서비스입니다.
- Amazon Aurora MySQL: 완전 관리형 MySQL 호환 데이터베이스 서비스로, 높은 성능과 가용성을 제공합니다.
- Amazon EC2 Auto Scaling: EC2 인스턴스 수를 자동으로 조정하여 애플리케이션 가용성을 유지합니다.
- AWS Lambda: 서버리스 컴퓨팅 서비스로, 이벤트에 의해 트리거되어 코드를 실행합니다.
- Elastic Load Balancing: 인바운드 트래픽을 EC2 인스턴스에 자동으로 분산시켜 애플리케이션의 가용성을 높입니다.
3. 선택지 분석하기
A. RDS for MySQL로 마이그레이션, AMI 생성, 두 번째 EC2 인스턴스 시작, Application Load Balancer 사용
→ 확장성과 비용 효율성이 있지만, Auto Scaling 기능이 없어 트래픽 변동에 유연하게 대응하기 어려울 수 있습니다.
B. RDS for MySQL로 마이그레이션, AMI 생성, 두 번째 EC2 인스턴스 시작, Route 53 가중 라우팅 사용
→ 가중 라우팅은 부하 분산에 적합하지 않아 원활한 확장이 어려울 수 있습니다.
C. Aurora MySQL로 마이그레이션, EC2 인스턴스 유형 변경을 위한 Lambda 함수와 CloudWatch 경보 생성
→ 단일 인스턴스만 있어 확장성이 부족하며, 인스턴스 유형 변경으로는 애플리케이션 확장에 한계가 있습니다.
D. Aurora MySQL로 마이그레이션, AMI로 시작 템플릿 생성, Auto Scaling 그룹 생성(스팟 플릿 사용), Application Load Balancer 연결
→ Auto Scaling을 통해 트래픽 변동에 따라 자동으로 확장되며, 스팟 플릿을 사용하여 비용 효율성을 높일 수 있습니다. Load Balancer를 사용하여 원활한 확장이 가능합니다.
이상으로 SAA 핵심 내용 정리를 마치겠습니다. 오늘 다룬 개념들은 솔루션 아키텍트로서 알아야 할 기본 중의 기본입니다. 단순히 시험 합격을 위한 암기가 아닌, 실제 현장에서 활용할 수 있는 지식으로 체화하시길 권장합니다.
'AWS > SAA 준비' 카테고리의 다른 글
| AWS SAA 합격으로 가는 길 #61 (0) | 2025.02.28 |
|---|---|
| AWS SAA 합격으로 가는 길 #60 (0) | 2025.02.24 |
| AWS SAA 합격으로 가는 길 #59 (1) | 2025.02.17 |
| AWS SAA 합격으로 가는 길 #58 (0) | 2025.02.14 |
| AWS SAA 합격으로 가는 길 #57 (0) | 2025.02.10 |