안녕하세요! 넥스트클라우드의 SA 백종훈입니다.
문제는 세 가지 단계를 거치며 풀어 나갈 거예요.
1. 문제의 요구사항 분석하기
2. 관련 AWS 서비스 생각하기
3. 선택지 분석하기
바로 첫번째 문제를 풀어 볼게요!
문제1
회사에 산발적인 사용 패턴을 가진 웹 애플리케이션이 있습니다.
매달 초에는 사용량이 많고, 매주 초에는 보통 사용량이 있으며, 주중에는 예측할 수 없는 사용량이 있습니다.
이 애플리케이션은 웹 서버와 데이터 센터 내에서 실행되는 MySQL 데이터베이스 서버로 구성됩니다.
이 회사는 애플리케이션을 AWS 클라우드로 이동하려고 하며 데이터베이스 수정이 필요하지 않는 비용 효율적인 데이터베이스 플랫폼을 선택해야합니다. 이러한 요구 사항을 충족한느 솔루션은 무엇입니까?
선택지
A. Amazon DynamoDB
B. MySQL용 Amazon RDS
C. MySQL 호환 Amazon Serverless
D. Auto Scaling 그룹의 Amazon EC2에 배포된 MySQL
▼ 단어 뜻 확인하기
DynamoDB
→빠르고 유연한 NoSQL 데이터베이스 서비스
Amazon RDS
→관리가 쉬운 관계형 데이터베이스 서비스
Amazon Serverless
→서버 관리 없이 애플리케이션을 실행할 수 있는 기술
Auto Scaling
→트래픽에 따라 자동으로 서버 용량을 조절하는 서비스
EC2
→클라우드에서 가상 서버를 생성하고 운영할 수 있는 서비스
풀이
MySQL 호환 Amazon Aurora Serverless는 기존 MySQL 애플리케이션을 수정 없이 마이그레이션할 수 있으면서도, 사용량에 따라 자동으로 확장 및 축소되는 특성을 가집니다. 이는 산발적인 사용 패턴에 효과적으로 대응하며, 실제 사용량에 기반한 요금 체계로 비용 효율성도 제공합니다.
정답 : C
▼ 자세한 문제 풀이 확인하기
1. 문제의 요구사항 분석하기
- 산발적인 사용 패턴에 대응할 수 있는 유연성
- AWS 클라우드로 애플리케이션 이전
- 비용 효율적인 데이터베이스 플랫폼 선택
- 데이터베이스 수정이 필요하지 않음 (기존 MySQL과 호환)
2. 관련 AWS 서비스 생각하기
- 산발적인 사용 패턴에 대응할 수 있는 유연성
- Amazon Aurora Serverless: 자동으로 시작 및 종료되며 용량을 확장 또는 축소하는 온디맨드 자동 확장 구성입니다. 예측할 수 없는 워크로드에 대응하여 자동으로 용량을 조정합니다.
- AWS 클라우드로 애플리케이션 이전
- AWS Database Migration Service (DMS): 기존 MySQL 데이터베이스를 Amazon Aurora Serverless로 안전하고 효율적으로 마이그레이션할 수 있습니다. 마이그레이션 중 소스 데이터베이스를 계속 사용할 수 있어 다운타임을 최소화합니다.
- 비용 효율적인 데이터베이스 플랫폼 선택
- Amazon Aurora Serverless: 실제 사용한 데이터베이스 용량에 대해서만 비용을 지불합니다. 사용량이 적을 때는 비용이 절감되며, 필요할 때만 자동으로 확장되어 비용을 최적화합니다.
- 데이터베이스 수정이 필요하지 않음 (기존 MySQL과 호환)
- Amazon Aurora MySQL-Compatible Edition: MySQL과 완벽하게 호환되는 서버리스 데이터베이스 옵션입니다. 기존 MySQL 애플리케이션을 거의 또는 전혀 수정하지 않고 Aurora Serverless로 마이그레이션할 수 있습니다.
3. 선택지 분석하기
A. Amazon DynamoDB
→ MySQL과 호환되지 않아 애플리케이션 수정이 필요함.
B. MySQL용 Amazon RDS
→ 자동 스케일링 기능이 제한적이고 항상 실행되어야 해서 비용 효율성이 낮음.
C. MySQL 호환 Amazon Aurora Serverless
→ MySQL 호환성, 자동 스케일링, 비용 효율성을 모두 제공함.
D. Auto Scaling 그룹의 Amazon EC2에 배포된 MySQL
→ 관리 부담이 크고 설정이 복잡하며 완전한 서버리스 솔루션이 아님.
두번째 문제입니다.
문제2.
회사는 여러 가용 영역에 걸쳐 Amazon EC2 Linux 인스턴스에서 애플리케이션을 실행합니다.
애플리케이션에는 고가용성 및 POSIX(Portable Operating System Interface)호환 스토리지 계층이 필요합니다.
스토리지 계층은 최대 데이터 내구성을 제공해야 하며 EC2 인스턴스 간에 공유 가능해야 합니다. 저장소 계층의 데이터는 처음 30일 동안 자주 엑세스되고 그 이후에는 드물게 엑세스됩니다.
이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?
선택지
A. Amazon S3 Standard 스토리지 클래스를 사용하십시오. S3 수명 주기 정책을 생성하여 자주 액세스하지 않는 데이터를 S3 Glacier로 이동합니다.
B. Amazon S3 Standard 스토리지 클래스를 사용합니다. S3 수명 주기 정책을 생성하여 자주 액세스하지 않는 데이터를 S3 Standard-Infrequent Access(S3 Standard-IA)로 이동합니다.
C. Amazon Elastic File System(Amazon EFS) Standard 스토리지 클래스를 사용합니다. 자주 액세스하지 않는 데이터를 EFS Standard-Infrequent Access(EFS Standard-IA)로 이동하는 수명 주기 관리 정책을 만듭니다.
D. Amazon Elastic File System(Amazon EFS) One Zone 스토리지 클래스를 사용합니다. 자주 액세스하지 않는 데이터를 EFS One Zone-Infrequent Access(EFS One Zone-IA)로 이동하는 수명 주기 관리 정책을 만듭니다.
▼ 단어 뜻 확인하기
POSIX
→다양한 운영 체제에서 프로그램이 동일하게 작동하도록 도와주는 표준 규칙
스토리지 계층
→데이터 중요도와 접근 빈도에 따라 저장소를 구분하는 방식
Amazon S3 Standard
→자주 접근하는 데이터를 위한 기본 스토리지 옵션
S3 수명 주기 정책
→데이터의 나이에 따라 자동으로 저장 방식을 변경하는 규칙
S3 Glacier
→장기 보관용 저비용 스토리지 옵션
S3 Standard-IA
→자주 접근하지 않는 데이터를 위한 저비용 스토리지
Amazon EFS Standard
→여러 서버에서 동시에 사용할 수 있는 파일 저장소
EFS Standard-IA
→EFS에서 자주 접근하지 않는 데이터를 위한 저비용 옵션
Amazon EFS One Zone
→단일 가용 영역에서 운영되는 저비용 EFS 옵션
EFS One Zone-IA
→One Zone에서 자주 접근하지 않는 데이터를 위한 더 저렴한 옵션
풀이
Amazon EFS Standard는 여러 가용 영역에 걸쳐 고가용성과 높은 내구성을 제공하며, POSIX 호환 파일 시스템으로 EC2 인스턴스 간 공유가 가능합니다. 30일 이후 자주 액세스하지 않는 데이터를 EFS Standard-IA로 이동하는 수명 주기 정책을 통해 비용 효율성도 확보할 수 있어, 주어진 요구사항을 가장 잘 충족합니다.
정답 : C
▼ 자세한 문제 풀이 확인하기
1. 문제의 요구사항 분석하기
- 여러 가용 영역에 걸친 고가용성
- POSIX 호환 스토리지 계층
- 최대 데이터 내구성 제공
- EC2 인스턴스 간 스토리지 공유 가능
- 처음 30일은 자주 접근, 이후 드물게 접근하는 데이터 특성
- 비용 효율적인 솔루션
2. 관련 AWS 서비스 생각하기
- 여러 가용 영역에 걸친 고가용성 및 POSIX 호환 스토리지 계층
- Amazon Elastic File System (Amazon EFS): 여러 가용 영역에 걸쳐 데이터를 자동으로 복제하여 고가용성을 제공합니다. POSIX 호환 파일 시스템 인터페이스를 제공하여 Linux 기반 EC2 인스턴스에서 쉽게 사용할 수 있습니다.
- 최대 데이터 내구성 제공 및 EC2 인스턴스 간 스토리지 공유 가능
- Amazon EFS: 99.999999999%의 내구성을 제공하며, 여러 EC2 인스턴스에서 동시에 마운트하여 데이터를 공유할 수 있습니다.
- 처음 30일은 자주 접근, 이후 드물게 접근하는 데이터 특성
- Amazon EFS 수명 주기 관리: EFS Standard 스토리지 클래스와 EFS Standard-Infrequent Access(EFS Standard-IA) 스토리지 클래스를 제공합니다. 수명 주기 정책을 설정하여 30일 이후 자주 접근하지 않는 파일을 자동으로 Standard-IA로 이동시킬 수 있습니다.
- 비용 효율적인 솔루션
- Amazon EFS 스토리지 클래스: Standard 클래스는 자주 접근하는 데이터에, Standard-IA 클래스는 드물게 접근하는 데이터에 사용됩니다. 이를 통해 스토리지 비용을 최적화할 수 있습니다.
- EC2 Linux 인스턴스에서 애플리케이션 실행
- Amazon EC2 (Elastic Compute Cloud): 여러 가용 영역에 걸쳐 Linux 인스턴스를 배포하여 애플리케이션의 고가용성을 확보할 수 있습니다.
3. 선택지 분석하기
A. Amazon S3 Standard 스토리지 클래스를 사용하십시오. S3 수명 주기 정책을 생성하여 자주 액세스하지 않는 데이터를 S3 Glacier로 이동합니다.
→ S3는 POSIX 호환이 아니며 EC2 인스턴스 간 직접 공유가 어렵습니다. Glacier는 접근 시간이 길어 "드물게 액세스"하는 데이터에도 부적합할 수 있습니다.
B. Amazon S3 Standard 스토리지 클래스를 사용합니다. S3 수명 주기 정책을 생성하여 자주 액세스하지 않는 데이터를 S3 Standard-Infrequent Access(S3 Standard-IA)로 이동합니다.
→ A와 마찬가지로 POSIX 호환 및 EC2 인스턴스 간 공유 요구사항을 충족하지 못합니다. 다만 S3 Standard-IA는 Glacier보다 접근성이 좋습니다.
C. Amazon Elastic File System(Amazon EFS) Standard 스토리지 클래스를 사용합니다. 자주 액세스하지 않는 데이터를 EFS Standard-Infrequent Access(EFS Standard-IA)로 이동하는 수명 주기 관리 정책을 만듭니다.
→ POSIX 호환, 고가용성, 최대 데이터 내구성, EC2 인스턴스 간 공유 가능성, 비용 효율적인 스토리지 관리 등 모든 요구사항을 충족합니다.
D. Amazon Elastic File System(Amazon EFS) One Zone 스토리지 클래스를 사용합니다. 자주 액세스하지 않는 데이터를 EFS One Zone-Infrequent Access(EFS One Zone-IA)로 이동하는 수명 주기 관리 정책을 만듭니다.
→ 단일 가용 영역 사용으로 고가용성과 최대 데이터 내구성 요구사항을 충족하지 못합니다. 비용 효율적이지만 중요한 요구사항들을 만족시키지 못합니다.
세번째 문제입니다.
문제3.
솔루션 설계자는 소프트웨어 데모 환경을 위한 아키텍처를 설계하고 있습니다. 환경은 Applicaition Load Balancer(ALB) 뒤에 있는 Auto Scaling 그룹의 Amazon EC2 인스턴스에서 실행됩니다. 시스템은 근무 시간 동안 트래픽이 크게 증가하지만 주말에는 작동하지 않아도 됩니다.
수요에 맞게 시스템을 확장할 수 있도록 하기 위해 솔루션 설계자는 어떤 조치 조합을 취해야 합니까? (두가지를 선택하세요.)
선택지
A. AWS Auto Scaling을 사용하여 요청 속도에 따라 ALB 용량을 조정하십시오.
B. AWS Auto Scaling을 사용하여 VPC 인터넷 게이트웨이의 용량을 확장합니다.
C. 여러 AWS 지역에서 EC2 인스턴스를 시작하여 여러 지역에 로드를 분산합니다.
D. 대상 추적 조정 정책을 사용하여 인스턴스 CPU 사용률을 기반으로 Auto Scaling 그룹을 조정합니다.
E. 예약된 조정을 사용하여 Auto Scaling 그룹의 최소, 최대 및 원하는 용량을 주말동안 0으로 변경합니다. 주의 시작 시 기본 값으로 되돌립니다.
▼ 단어 뜻 확인하기
Applicaition Load Balancer(ALB)
→웹 애플리케이션으로 들어오는 트래픽을 여러 서버에 효율적으로 분산시키는 서비스
트래픽
→네트워크나 웹사이트를 통해 오가는 데이터의 양
VPC
→클라우드 내에서 사용자가 정의하고 제어할 수 있는 가상의 독립된 네트워크 환경
풀이
D는 CPU 사용률 기반의 대상 추적 조정 정책을 통해 근무 시간 중 트래픽 증가에 효과적으로 대응할 수 있게 해줍니다.
E는 주말에 시스템을 완전히 중지시켜 불필요한 비용을 절감할 수 있게 해줍니다.
이 두 옵션을 결합하면 평일의 변동하는 수요에 탄력적으로 대응하면서도 주말에는 비용을 최소화할 수 있어, 문제의 요구사항을 가장 잘 충족시킵니다.
정답 : D,E
▼ 자세한 문제 풀이 확인하기
1. 문제의 요구사항 분석하기
- 근무 시간 동안 트래픽 증가에 대응할 수 있는 확장성
- 주말에는 시스템을 비활성화할 수 있는 유연성
- Auto Scaling 그룹과 Application Load Balancer(ALB)를 활용한 아키텍처 설계
2. 관련 AWS 서비스 생각하기
- 근무 시간 동안 트래픽 증가에 대응할 수 있는 확장성
- Amazon EC2 Auto Scaling: 트래픽 패턴에 따라 EC2 인스턴스의 수를 자동으로 조정합니다. CPU 사용률이나 네트워크 트래픽과 같은 지표를 기반으로 인스턴스를 추가하거나 제거할 수 있습니다.
- 주말에는 시스템을 비활성화할 수 있는 유연성
- Amazon EC2 Auto Scaling의 예약된 작업: 특정 시간에 Auto Scaling 그룹의 크기를 조정하도록 예약할 수 있습니다. 이를 통해 주말에 인스턴스 수를 0으로 줄이고, 평일 시작 시 다시 증가시킬 수 있습니다.
- Auto Scaling 그룹과 Application Load Balancer(ALB)를 활용한 아키텍처 설계
- Amazon EC2 Auto Scaling: Auto Scaling 그룹을 생성하여 EC2 인스턴스를 관리합니다. 이는 애플리케이션의 가용성을 유지하고 비용을 최적화하는 데 도움을 줍니다.
- Application Load Balancer (ALB): 들어오는 애플리케이션 트래픽을 여러 EC2 인스턴스로 분산시킵니다. Auto Scaling 그룹과 통합되어 새로 추가된 인스턴스로 자동으로 트래픽을 라우팅합니다.
3. 선택지 분석하기
A. AWS Auto Scaling을 사용하여 요청 속도에 따라 ALB 용량을 조정하십시오.
→ ALB는 자동으로 확장되므로 용량을 수동으로 조정할 필요가 없습니다.
B. AWS Auto Scaling을 사용하여 VPC 인터넷 게이트웨이의 용량을 확장합니다.
→ VPC 인터넷 게이트웨이는 확장이 필요 없는 완전 관리형 서비스입니다.
C. 여러 AWS 지역에서 EC2 인스턴스를 시작하여 여러 지역에 로드를 분산합니다.
→ 여러 지역에 걸친 분산은 문제의 요구사항에 불필요하며 복잡성만 증가시킵니다.
D. 대상 추적 조정 정책을 사용하여 인스턴스 CPU 사용률을 기반으로 Auto Scaling 그룹을 조정합니다.
→ CPU 사용률 기반의 대상 추적 조정 정책은 근무 시간 동안의 트래픽 증가에 효과적으로 대응할 수 있습니다.
E. 예약된 조정을 사용하여 Auto Scaling 그룹의 최소, 최대 및 원하는 용량을 주말동안 0으로 변경합니다. 주의 시작 시 기본 값으로 되돌립니다.
→ 예약된 조정을 통해 주말에 시스템을 비활성화하고 평일에 다시 활성화할 수 있어 비용을 절감할 수 있습니다.
여러분, 정말 대단하십니다! 👏
"천리 길도 한 걸음부터"라는 말이 있죠.
오늘 이 글을 읽으신 여러분은 이미 새로운 지식의 세계로 첫 발을 내딛으셨습니다.
꾸준히 노력하고 실천해 나간다면, 언젠가 이 분야의 전문가가 되어 있는 자신을 발견하실 거예요.
여러분의 열정과 노력을 응원합니다! 함께 성장해요! 🌱💪
'AWS > SAA 준비' 카테고리의 다른 글
| AWS SAA 합격으로 가는 길 #14 (0) | 2024.09.09 |
|---|---|
| AWS SAA 합격으로 가는 길 #13 (1) | 2024.09.06 |
| AWS SAA 합격으로 가는 길 #11 (2) | 2024.09.04 |
| AWS SAA 합격으로 가는 길 #10 (5) | 2024.09.03 |
| AWS SAA 합격으로 가는 길 #9 (2) | 2024.09.02 |
