- 1 . 질문
소매 조직은 데이터베이스에서 데이터를 읽고 쓰는 새로운 응용 프로그램을 배포하고 있습니다. 이 회사는 액티브-액티브 구성의 세 가지 AWS 리전에 애플리케이션을 배포하려고합니다. 정보를 동기화 상태로 유지하려면 데이터베이스를 복제해야합니다.
이러한 요구 사항을 가장 잘 충족하는 솔루션은 무엇입니까?
- Amazon S3 교차 리전 복제를 사용하는 Amazon Athena
- 변경 데이터 캡처 기능이있는 AWS Database Migration Service
- Amazon Aurora 글로벌 데이터베이스
- 글로벌 테이블이있는 Amazon DynamoDB
설명:
Amazon DynamoDB 전역 테이블은 다중 지역, 다중 마스터 데이터베이스 배포를위한 완전 관리 형 솔루션을 제공합니다. 이것은 완전한 양방향 동기화를 통해 여러 지역에서 읽기 및 쓰기가 발생할 수있는 활성-활성 구성을 제공하는 유일한 솔루션입니다.
정답 : “전역 테이블이있는 Amazon DynamoDB”가 정답입니다.
INCORRECT : DMS에이 소스로부터 목적지로 데이터 마이그레이션에 사용되는 "변경 데이터 캡처와 AWS 데이터베이스 마이그레이션 서비스는"올바르지 않습니다. 그러나이 예에서는 다중 마스터 데이터베이스가 필요하며 DMS는이 구성을 허용하지 않습니다.
올바르지 않음 : "Amazon Athena with Amazon S3 교차 리전 복제"가 올바르지 않습니다. S3 교차 리전 복제를 사용하는 Amazon Athena는 적합하지 않습니다. 이것은 트랜잭션 데이터베이스 솔루션 (Athena가 분석에 사용됨) 또는 활성-활성 동기화를 제공하는 솔루션이 아닙니다.
올바르지 않음 : "Amazon Aurora 글로벌 데이터베이스"가 올바르지 않습니다. Amazon Aurora 글로벌 데이터베이스는 여러 리전의 데이터베이스에 대한 읽기 액세스를 제공합니다. 양방향 동기화가있는 활성-활성 구성을 제공하지 않습니다 (읽기 전용 DB로 장애 조치하여 쓰기 가능 상태로 승격 할 수 있음).
참고 문헌 :
시험 관련 치트 시트로 시간 절약 :
- 2 . 질문
Elastic Load Balancer (ELB) 뒤에있는 Amazon EC2 인스턴스의 Auto Scaling 그룹이 Amazon VPC에서 실행 중입니다. 상태 확인은 EC2 상태 확인을 사용하도록 ASG에서 구성됩니다. ELB는 EC2 인스턴스가 비정상임을 확인하여 서비스에서 제거했습니다. 솔루션 아키텍트는 인스턴스가 아직 실행 중이며 EC2 Auto Scaling에 의해 종료되지 않았 음을 확인했습니다.
이 동작에 대한 설명은 무엇입니까?
- ELB 상태 확인 유형이 ASG에 대해 선택되지 않았으므로 인스턴스가 ELB에 의해 비정상으로 확인되어 서비스에서 제거되었음을 알지 못합니다.
- 연결 드레 이닝이 활성화되고 ASG가 진행중인 요청이 완료되기를 기다리고 있습니다.
- ASG는 인스턴스를 종료하기 전에 휴지 타이머가 만료되기를 기다리고 있습니다.
- 상태 확인 유예 기간이 아직 만료되지 않았습니다.
설명:
ELB를 사용하는 경우 ELB 상태 확인을 활성화하는 것이 가장 좋습니다. 그렇지 않으면 EC2 상태 확인에서 ELB가 비정상이라고 판단한 인스턴스가 정상으로 표시 될 수 있습니다. 이 경우 인스턴스는 ELB에 의해 서비스에서 제거되지만 Auto Scaling에 의해 종료되지는 않습니다.
ASG 상태 확인에 대한 추가 정보 :
- 기본적으로 EC2 상태 확인을 사용합니다.
- ELB 상태 확인 및 사용자 지정 상태 확인을 사용할 수도 있습니다.
- ELB 상태 확인은 EC2 상태 확인에 추가됩니다.
- 상태 확인이 비정상 상태를 반환하면 인스턴스가 종료됩니다.
- ELB를 사용하면 ELB가 OutOfService로보고하면 인스턴스가 비정상으로 표시됩니다.
- 정상 인스턴스는 InService 상태가됩니다.
- 인스턴스가 비정상으로 표시되면 교체가 예약됩니다.
- 연결 드레 이닝이 활성화 된 경우 Auto Scaling은 인스턴스를 종료하기 전에 진행중인 요청이 완료되거나 시간 초과 될 때까지 기다립니다.
- 상태 확인 유예 기간은 상태 확인을 수행하기 전에 새 인스턴스가 워밍업 할 수있는 기간을 허용합니다 (기본적으로 300 초).
정답 : "ASG에 대해 ELB 상태 확인 유형이 선택되지 않았으므로 인스턴스가 ELB에 의해 비정상으로 확인되어 서비스에서 제거되었음을 알지 못합니다."가 정답입니다.
INCORRECT : "재사용 대기 시간 타이머가 인스턴스를 종료하기 전에 만료위한 ASG가 기다리고있다"는 ASG가 만료 재사용 대기 시간을 대기하지 않기 때문에 올바르지 않습니다.
올바르지 않음 : "연결 드레 이닝이 활성화되었으며 ASG가 진행중인 요청이 완료되기를 기다리고 있습니다."가 올바르지 않습니다. 연결 드레 이닝은 ELB가 인스턴스를 서비스에서 제외시켜 활성 연결이 없기 때문에 정답이 아닙니다.
올바르지 않음 : "상태 확인 유예 기간이 아직 만료되지 않았습니다."가 올바르지 않습니다. 상태 확인 유예 기간은 상태 확인을 수행하기 전에 새 인스턴스가 워밍업 할 수있는 기간을 허용합니다.
참고 문헌 :
https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroupLifecycle.html
시험 관련 치트 시트로 시간 절약 :
- 3 . 질문
아키텍트는 전 세계 사용자가 업로드 한 이미지를 허용하는 서버리스 애플리케이션을 설계하고 있습니다. 애플리케이션은 백엔드 서비스에 대한 API 호출을 만들고 사용자의 세션 상태 데이터를 데이터베이스에 저장합니다.
대기 시간을 최소화하면서 비용 효율적인 솔루션을 제공하는 서비스 조합은 무엇입니까?
- Amazon S3, API 게이트웨이, AWS Lambda, Amazon RDS
- Amazon CloudFront, API 게이트웨이, Amazon S3, AWS Lambda, Amazon RDS
- API 게이트웨이, Amazon S3, AWS Lambda, DynamoDB
- Amazon CloudFront, API 게이트웨이, Amazon S3, AWS Lambda, DynamoDB
설명:
Amazon CloudFront는 전 세계 엣지 로케이션의 사용자에게 더 가까운 콘텐츠를 캐시합니다. 콘텐츠 업로드를위한 가장 낮은 지연 시간 옵션입니다. API Gateway 및 AWS Lambda는 모든 옵션에 있습니다. DynamoDB는 세션 상태 데이터를 저장하는 데 사용할 수 있습니다. 이것은 100 % 서버리스 애플리케이션입니다.
정답 : “Amazon CloudFront, API Gateway, Amazon S3, AWS Lambda, DynamoDB”가 정답입니다.
올바르지 않음 : "Amazon CloudFront, API Gateway, Amazon S3, AWS Lambda, Amazon RDS"가 올바르지 않습니다. Amazon RDS는 서버리스 서비스가 아니므로이 옵션을 배제 할 수 있습니다.
올바르지 않음 : "Amazon S3, API Gateway, AWS Lambda, Amazon RDS"가 올바르지 않습니다. Amazon S3만으로는 다른 리전에 버킷이 많고 사용자를 가장 가까운 버킷으로 안내하는 방법 (예 : Route 3 지연 시간 기반 라우팅)이 아니면 전 세계 사용자에게 최소 지연 시간을 제공하지 않습니다. 그러나 그런 다음 데이터 복제를 관리해야합니다.
올바르지 않음 : "API Gateway, Amazon S3, AWS Lambda, DynamoDB"가 올바르지 않습니다. 이 답변은 사용자가 콘텐츠를 업로드 할 수있는 프런트 엔드를 제공하지 않습니다.
참고 문헌 :
https://aws.amazon.com/blogs/aws/amazon-cloudfront-content-uploads-post-put-other-methods/
시험 관련 치트 시트로 시간 절약 :
- 4 . 질문
Auto Scaling 그룹은 변경 사항을로드 할만큼 빠르게 응답하지 못하여 다른 애플리케이션 계층에서 메시지가 손실됩니다. 메시지의 크기는 일반적으로 약 128KB입니다.
메시지 손실을 방지하는 가장 좋은 설계 옵션은 무엇입니까?
- 더 큰 EC2 인스턴스 크기 사용
- SQS 대기열에 메시지 저장
- Amazon S3에 메시지 저장
- Elastic Load Balancer 시작
설명:
이 상황에서 ASG는 EC2 인스턴스를 충분히 빠르게 시작할 수 없습니다. EC2 인스턴스가 시작되는 동안 메시지가 손실되지 않도록 메시지를 어딘가에 저장할 수 있어야합니다. 이것은 디커플링에 대한 고전적인 사용 사례이며 SQS는 정확히 이러한 목적을 위해 설계되었습니다.
Amazon Simple Queue Service (Amazon SQS)는 처리 대기중인 메시지를 저장하는 메시지 대기열에 대한 액세스를 제공하는 웹 서비스입니다. SQS는 컴퓨터간에 전송되는 메시지를 저장하기 위해 안정적이고 확장 성이 뛰어난 호스팅 대기열을 제공합니다. SQS 대기열을 사용하여 분산 / 분리 된 애플리케이션을 만들 수 있습니다.
정답 : "SQS 대기열에 메시지 저장"이 정답입니다.
올바르지 않음 : "Amazon S3에 메시지 저장"이 올바르지 않습니다. S3에 메시지를 저장하는 것은 잠재적으로 가능하지만 SQS는 디커플링을 위해 설계되었으므로 선호되는 솔루션입니다. 메시지가 256KB를 초과하여 SQS에 저장할 수없는 경우 S3 사용을 고려할 수 있으며 Java 용 Amazon SQS 확장 클라이언트 라이브러리를 사용하여 SQS와 함께 사용할 수 있습니다.
올바르지 않음 : “Launch an Elastic Load Balancer”가 올바르지 않습니다. ELB는 들어오는 연결을 백엔드 EC2 인스턴스로 분산하는 데 도움이 될 수 있지만 ASG가 충분히 빠르게 확장되지 않으면 ELB가 트래픽을 분산 할 리소스가 충분하지 않습니다.
올바르지 않음 : "더 큰 EC2 인스턴스 크기 사용"이 올바르지 않습니다. 수평 확장 및 분리는 더 큰 인스턴스 크기를 사용하는 것보다 더 큰 영향을 미칩니다.
참고 문헌 :
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html
시험 관련 치트 시트로 시간 절약 :
- 5 . 질문
한 회사가 HPC (고성능 컴퓨팅) 애플리케이션 및 관련 데이터를 온 프레미스 데이터 센터에서 AWS 클라우드로 마이그레이션 할 계획입니다. 이 회사는 애플리케이션을 주기적으로 실행하는 동안 애플리케이션을 지원하기 위해 핫 고성능 병렬 스토리지가있는 온 프레미스 계층 형 스토리지를 사용하고 애플리케이션이 활발하게 실행되지 않을 때 데이터를 보관하기 위해보다 경제적 인 콜드 스토리지를 사용합니다.
솔루션 아키텍트는 애플리케이션의 스토리지 요구 사항을 지원하기 위해 어떤 솔루션 조합을 권장해야합니까? (2 개를 선택하십시오.)
- 콜드 데이터 스토리지를위한 Amazon EFS
- 고성능 병렬 스토리지를위한 Amazon S3
- 고성능 병렬 스토리지를위한 Windows 용 Amazon FSx
- 콜드 데이터 스토리지를위한 Amazon S3
- 고성능 병렬 스토리지를위한 Amazon FSx for Lustre
설명:
Amazon FSx for Luster는 기계 학습, 고성능 컴퓨팅 (HPC), 비디오 처리, 재무 모델링 및 전자 설계 자동화 (EDA)와 같은 워크로드의 빠른 처리에 최적화 된 고성능 파일 시스템을 제공합니다.
이러한 워크로드는 일반적으로 빠르고 확장 가능한 파일 시스템 인터페이스를 통해 데이터를 제공해야하며 일반적으로 Amazon S3와 같은 장기 데이터 저장소에 데이터 세트를 저장합니다.
Amazon FSx는 기본적으로 Amazon S3와 함께 작동하므로 S3 데이터에 쉽게 액세스하여 데이터 처리 워크로드를 실행할 수 있습니다. S3 객체는 파일 시스템에 파일로 표시되며 결과를 다시 S3에 쓸 수 있습니다. 이를 통해 FSx for Luster에서 데이터 처리 워크로드를 실행하고 S3 또는 온 프레미스 데이터 저장소에 장기 데이터를 저장할 수 있습니다.
따라서이 시나리오에 가장 적합한 조합은 콜드 데이터에 S3를 사용하고 병렬 HPC 작업에 Lustre에 FSx를 사용하는 것입니다.
정답 : “콜드 데이터 스토리지 용 Amazon S3”가 정답입니다.
정답 : "고성능 병렬 스토리지를위한 Lustre 용 Amazon FSx"가 정답입니다.
잘못된 예 : "아마존 EFS 차가운 데이터 저장을 위해"FSX는 경제적 인 기본적 S3와 함께 작동하기 때문에 올바르지 않습니다.
올바르지 않음 : "고성능 병렬 스토리지 용 Amazon S3"는 S3가 고성능 컴퓨팅 작업을 실행하는 데 적합하지 않기 때문에 올바르지 않습니다.
잘못된 예 : 광택에 대한 FSX는 HPC 활용 사례 및 S3에 데이터를 저장하는 필요 사용 사례에 사용해야으로 "고성능 병렬 스토리지를위한 Windows 용 아마존 FSX는"올바르지 않습니다.
참고 문헌 :
https://aws.amazon.com/fsx/lustre/
시험 관련 치트 시트로 시간 절약 :
- 6 . 질문
한 회사의 온 프레미스 파일 공유에 Amazon S3 Glacier로 이동해야하는 500TB의 데이터가 있습니다. 마이그레이션으로 인해 회사의 저 대역폭 인터넷 연결이 포화 상태가되어서는 안되며 마이그레이션은 몇 주 이내에 완료되어야합니다.
가장 비용 효율적인 솔루션은 무엇입니까?
- AWS Direct Connect 연결을 생성하고 데이터를 Amazon Glacier로 직접 마이그레이션
- 7 개의 AWS Snowball 어플라이언스를 주문하고 S3 Glacier 볼트를 대상으로 선택합니다. VPC 엔드 포인트를 적용하기위한 버킷 정책 생성
- AWS Global Accelerator를 사용하여 업로드를 가속화하고 사용 가능한 대역폭의 사용을 최적화하십시오.
- 7 개의 AWS Snowball 어플라이언스를 주문하고 Amazon S3 버킷을 대상으로 선택합니다. S3 객체를 Amazon S3 Glacier로 전환하는 수명주기 정책 생성
설명:
회사의 인터넷 링크가 저 대역폭이기 때문에 Amazon S3에 직접 업로드하면 (Glacier로 전환 할 준비가 됨) 링크가 포화됩니다. 가장 좋은 대안은 AWS Snowball 어플라이언스를 사용하는 것입니다. Snowball Edge Appliance는 최대 80TB의 데이터를 저장할 수 있으므로 500TB의 데이터를 마이그레이션하려면 7 개의 장치가 필요합니다.
Snowball은 하드웨어 디바이스를 사용하여 데이터를 AWS로 이동 한 다음 선택한 Amazon S3 버킷에 데이터를 복사합니다. 여기에서 수명주기 정책은 S3 객체를 Amazon S3 Glacier로 전환 할 수 있습니다.
올바름 : “7 개의 AWS Snowball 어플라이언스를 주문하고 Amazon S3 버킷을 대상으로 선택하십시오. S3 객체를 Amazon S3 Glacier로 전환하는 수명주기 정책 생성”이 정답입니다.
올바르지 않음 : “7 개의 AWS Snowball 어플라이언스를 주문하고 S3 Glacier 볼트를 대상으로 선택하십시오. VPC 엔드 포인트를 적용하기위한 버킷 정책 생성”은 Glacier 저장소를 대상으로 설정할 수 없으며 S3 버킷이어야하므로 올바르지 않습니다. 또한 버킷 정책을 사용하여 VPC 엔드 포인트를 시행 할 수 없습니다.
올바르지 않음 : "AWS Direct Connect 연결을 생성하고 데이터를 Amazon Glacier로 직접 마이그레이션"은 가장 비용 효율적인 옵션이 아니고 설정하는 데 시간이 걸리기 때문에 올바르지 않습니다.
잘못된 예 : "사용 AWS 글로벌 가속기가 사용 가능한 대역폭의 업로드 및 최적화 사용을 촉진하기 위해"이 서비스가 가속 또는 온 - 프레미스 네트워크에서 데이터의 업로드를 최적화으로 이용되지 않는 올바르지 않습니다.
참고 문헌 :
https://docs.aws.amazon.com/snowball/latest/developer-guide/specifications.html
시험 관련 치트 시트로 시간 절약 :
- 7 . 질문
조직은 Amazon S3에 데이터 레이크가 있으며 데이터 레이크에서 데이터 자산의 인플레 이스 쿼리를 수행하기위한 솔루션을 찾아야합니다. 요구 사항은 BI 도구를 사용하여 많은 동시 사용자로부터 데이터 검색 및 SQL 쿼리와 복잡한 쿼리를 모두 수행하는 것입니다.
이 상황에서 사용할 수있는 가장 좋은 AWS 서비스 조합은 무엇입니까? (2 개를 선택하십시오.)
- 임시 SQL 쿼리를위한 AWS Glue
- 임시 SQL 쿼리를위한 Amazon Athena
- 복잡한 쿼리를위한 AWS Lambda
- 복잡한 쿼리를위한 Amazon Kinesis
- 복잡한 쿼리를위한 RedShift Spectrum
설명:
데이터 레이크에서 인플레 이스 쿼리를 수행하면 데이터웨어 하우스에로드하지 않고도 S3의 데이터에서 직접 정교한 분석 쿼리를 실행할 수 있습니다.
동일한 데이터 자산에 대해 Athena 및 Redshift Spectrum을 모두 사용할 수 있습니다. 일반적으로 임시 데이터 검색 및 SQL 쿼리에 Athena를 사용하고, 많은 데이터 레이크 사용자가 동시 BI 및보고 워크로드를 실행하려는 더 복잡한 쿼리 및 시나리오에 Redshift Spectrum을 사용합니다.
정답 : “복잡한 쿼리를위한 RedShift Spectrum”이 정답입니다.
정답 : "Ad Hoc SQL 쿼리를위한 Amazon Athena"도 정답입니다.
올바르지 않음 : "임시 SQL 쿼리 용 AWS Glue"가 올바르지 않습니다. AWS Glue는 추출, 변환 및로드 (ETL) 서비스입니다.
올바르지 않음 : "복잡한 쿼리에 대한 AWS Lambda"가 올바르지 않습니다. AWS Lambda는 함수 실행을위한 서버리스 기술이지만 분석 쿼리 실행을위한 최상의 솔루션은 아닙니다.
올바르지 않음 : "복잡한 쿼리에 대한 Amazon Kinesis"가 올바르지 않습니다. Amazon Kinesis는 쿼리를 수행하지 않고 실시간 스트리밍 데이터를 수집하고 처리하는 데 사용됩니다.
참고 문헌 :
https://docs.aws.amazon.com/aws-technical-content/latest/building-data-lakes/in-place-querying.html
https://aws.amazon.com/redshift/
https://aws.amazon.com/athena/
시험 관련 치트 시트로 시간 절약 :
- 8 . 질문
데이터 처리 애플리케이션은 단일 100GB EBS gp2 볼륨이있는 i3.large EC2 인스턴스에서 실행됩니다. 애플리케이션은 EBS 루트 볼륨에있는 소규모 데이터베이스 (30GB 미만)에 임시 데이터를 저장합니다. 애플리케이션은 데이터를 충분히 빠르게 처리하기 위해 고군분투하고 있으며 솔루션 아키텍트는 임시 데이터베이스의 I / O 속도가 병목 현상이라고 판단했습니다.
데이터베이스 응답 시간을 개선하는 가장 비용 효율적인 방법은 무엇입니까?
- 인스턴스에서 EBS 최적화를 활성화하고 기존 볼륨에 임시 파일을 유지합니다.
- 3000 IOPS가 할당 된 새 50GB EBS io1 볼륨에 임시 데이터베이스를 배치합니다.
- 새 50GB EBS gp2 볼륨에 임시 데이터베이스 배치
- 임시 데이터베이스를 인스턴스 저장소로 이동
설명:
EC2 인스턴스 스토어는 EC2 인스턴스에 물리적으로 연결된 고속 임시 스토리지입니다. i3.large 인스턴스 유형은 단일 475GB NVMe SSD 인스턴스 스토어와 함께 제공되므로 연결된 인스턴스 스토어를 사용하여 비용을 낮추고 성능을 향상시키는 좋은 방법입니다. 파일이 임시 파일이므로 임시 저장소 (인스턴스가 중지되면 데이터가 손실 됨)가 충분하다고 가정 할 수 있습니다.
정답 : "임시 데이터베이스를 인스턴스 스토리지로 이동"이 정답입니다.
잘못된 예 : "3000 IOPS 할당과 새로운 50-GB EBS IO1 볼륨에 임시 데이터베이스를 넣어"올바르지 않습니다. 3000 IOPS가 할당 된 새로운 50GB EBS io1 볼륨으로 DB를 이동하면 성능이 향상되지만 비용이 더 많이 들기 때문에 가장 비용 효율적인 솔루션은 아닙니다.
올바르지 않음 : "새 50GB EBS gp2 볼륨에 임시 데이터베이스 배치"가 올바르지 않습니다. DB를 새로운 50GB EBS gp2 볼륨으로 이동해도 GB 당 IOPS가 할당되므로 성능이 향상되지 않으므로 볼륨이 작을수록 성능이 저하됩니다.
올바르지 않음 : "인스턴스에서 EBS 최적화를 활성화하고 기존 볼륨에 임시 파일 유지"가 올바르지 않습니다. EBS 최적화를 활성화해도 비용이 절감되지는 않습니다. 또한 EBS 최적화는 네트워크 트래픽 최적화이며 볼륨의 I / O 성능을 변경하지 않습니다.
참고 문헌 :
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html
시험 관련 치트 시트로 시간 절약 :
- 9 . 질문
솔루션 아키텍트가 AWS에서 애플리케이션을 설계하고 있습니다. 컴퓨팅 계층은 EC2 인스턴스에서 병렬로 실행됩니다. 컴퓨팅 계층은 처리 할 작업 수에 따라 확장되어야합니다. 컴퓨팅 계층은 상태 비 저장입니다. 솔루션 아키텍트는 애플리케이션이 느슨하게 결합되고 작업 항목이 영구적으로 저장되도록해야합니다.
솔루션 아키텍트는 어떤 디자인을 사용해야합니까?
- 처리해야하는 작업을 보관할 Amazon SQS 대기열을 생성합니다. 컴퓨팅 애플리케이션에 대한 Amazon EC2 Auto Scaling 그룹을 생성합니다. 네트워크 사용량에 따라 노드를 추가 및 제거하도록 Auto Scaling 그룹에 대한 조정 정책 설정
- 처리해야하는 작업을 보낼 Amazon SNS 주제를 생성합니다. 컴퓨팅 애플리케이션에 대한 Amazon EC2 Auto Scaling 그룹을 생성합니다. CPU 사용량에 따라 노드를 추가 및 제거하도록 Auto Scaling 그룹에 대한 조정 정책 설정
- 처리해야하는 작업을 보관할 Amazon SQS 대기열을 생성합니다. 컴퓨팅 애플리케이션에 대한 Amazon EC2 Auto Scaling 그룹을 생성합니다. Auto Scaling 그룹에 대한 조정 정책을 설정하여 SQS 대기열의 항목 수에 따라 노드를 추가 및 제거합니다.
- 처리해야하는 작업을 보낼 Amazon SNS 주제를 생성합니다. 컴퓨팅 애플리케이션에 대한 Amazon EC2 Auto Scaling 그룹을 생성합니다. SNS 주제에 게시 된 메시지 수에 따라 노드를 추가 및 제거하도록 Auto Scaling 그룹에 대한 조정 정책을 설정합니다.
설명:
이 경우 작업 저장을위한 내구성 있고 느슨하게 결합 된 솔루션을 찾아야합니다. Amazon SQS는이 사용 사례에 이상적이며 대기열에서 대기중인 작업 수에 따라 동적 조정을 사용하도록 구성 할 수 있습니다.
이 조정을 구성하려면 유지 관리 할 인스턴스 당 허용되는 백 로그 가 대상 값인 인스턴스 당 백 로그 지표를 사용할 수 있습니다 . 이 숫자는 다음과 같이 계산할 수 있습니다.
- 인스턴스 당 백 로그 : 인스턴스 당 백 로그 를 계산하려면 ApproximateNumberOfMessages 큐 속성으로 시작하여 SQS 큐의 길이 (큐에서 검색 할 수있는 메시지 수)를 결정합니다. 이 숫자를 플릿의 실행 용량 (Auto Scaling 그룹의 경우 InService 상태의 인스턴스 수)으로 나누어 인스턴스 당 백 로그를 가져옵니다.
- 인스턴스 당 허용 가능한 백 로그 : 목표 값을 계산하려면 먼저 애플리케이션에서 허용 할 수있는 지연 시간을 결정하세요. 그런 다음 허용 가능한 지연 시간 값을 EC2 인스턴스가 메시지를 처리하는 데 걸리는 평균 시간으로 나눕니다.
이 솔루션은 SQS 대기열에서 대기중인 작업 수에 따라 Auto Scaling을 사용하여 EC2 인스턴스를 확장합니다.
CORRECT : “처리해야하는 작업을 보관할 Amazon SQS 대기열을 생성합니다. 컴퓨팅 애플리케이션에 대한 Amazon EC2 Auto Scaling 그룹을 생성합니다. SQS 대기열의 항목 수에 따라 노드를 추가 및 제거하도록 Auto Scaling 그룹에 대한 조정 정책 설정”이 정답입니다.
올바르지 않음 : “처리해야하는 작업을 보관할 Amazon SQS 대기열을 생성합니다. 컴퓨팅 애플리케이션에 대한 Amazon EC2 Auto Scaling 그룹을 생성합니다. 네트워크 사용량에 대한 조정이 처리 대기중인 작업 수와 관련이 없기 때문에 Auto Scaling 그룹이 네트워크 사용량에 따라 노드를 추가 및 제거하도록 조정 정책을 설정하십시오.
올바르지 않음 : “처리해야하는 작업을 보낼 Amazon SNS 주제를 생성합니다. 컴퓨팅 애플리케이션에 대한 Amazon EC2 Auto Scaling 그룹을 생성합니다. CPU 사용량에 따라 노드를 추가 및 제거하도록 Auto Scaling 그룹에 대한 조정 정책 설정”이 잘못되었습니다. Amazon SNS는 알림 서비스이므로 구독자에게 알림을 전달합니다. 데이터를 지속적으로 저장하지만이 사용 사례에서는 SQS보다 적합하지 않습니다. CPU 사용량을 조정하는 것은 처리 대기중인 작업 수와 관련이 없기 때문에 최상의 솔루션이 아닙니다.
올바르지 않음 : “처리해야하는 작업을 보낼 Amazon SNS 주제를 생성합니다. 컴퓨팅 애플리케이션에 대한 Amazon EC2 Auto Scaling 그룹을 생성합니다. SNS 주제에 게시 된 메시지 수에 따라 노드를 추가 및 제거하도록 Auto Scaling 그룹에 대한 조정 정책 설정”이 잘못되었습니다. Amazon SNS는 알림 서비스이므로 구독자에게 알림을 전달합니다. 데이터를 지속적으로 저장하지만이 사용 사례에서는 SQS보다 적합하지 않습니다. SNS에서 알림 수를 조정할 수 없습니다.
참고 문헌 :
https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html
시험 관련 치트 시트로 시간 절약 :
- 10 . 질문
Solutions Architect는 ALB (Application Load Balancer)에서 액세스 로그를 활성화했으며 호스팅 된 Hadoop 서비스를 사용하여 로그 파일을 처리해야합니다. 이 요구 사항을 제공하기 위해 어떤 구성 변경 및 서비스를 활용할 수 있습니까?
- S3에 전달되도록 액세스 로그를 구성하고 로그 파일을 처리하기 위해 Kinesis를 사용합니다.
- DynamoDB로 전달되도록 액세스 로그를 구성하고 로그 파일을 처리하기 위해 EMR을 사용합니다.
- S3에 전달할 액세스 로그를 구성하고 로그 파일을 처리하기 위해 EMR을 사용합니다.
- EC2에 전달할 액세스 로그를 구성하고 로그 파일 처리를 위해 Hadoop을 설치합니다.
설명:
ALB에서 액세스 로그를 활성화하고 S3 버킷에 데이터를 저장하도록 구성 할 수 있습니다. Amazon EMR은 기업, 연구원, 데이터 분석가 및 개발자가 방대한 양의 데이터를 쉽고 비용 효율적으로 처리 할 수 있도록 지원하는 웹 서비스입니다. EMR은 Amazon EC2 및 Amazon S3에서 실행되는 호스팅 된 Hadoop 프레임 워크를 사용합니다.
정답 : "S3에 전달할 액세스 로그 구성 및 로그 파일 처리에 EMR 사용"이 정답입니다.
올바르지 않음 : "EC2에 전달할 액세스 로그 구성 및 로그 파일 처리를 위해 Hadoop 설치"가 올바르지 않습니다. EC2는 호스팅 된 Hadoop 서비스를 제공하지 않습니다.
올바르지 않음 : "DynamoDB로 전달 될 액세스 로그 구성 및 로그 파일 처리에 EMR 사용"이 올바르지 않습니다. DynamoDB로 전달되도록 액세스 로그를 구성 할 수 없습니다.
올바르지 않음 : "S3에 전달 될 액세스 로그 구성 및 로그 파일 처리에 Kinesis 사용"이 올바르지 않습니다. Kinesis는 호스팅 된 Hadoop 서비스를 제공하지 않습니다.
참고 문헌 :
https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-what-is-emr.html
시험 관련 치트 시트로 시간 절약 :
'AWS Associate: Solution Architect > AWS migration' 카테고리의 다른 글
| migration 연습문제 2 (0) | 2021.02.27 |
|---|
댓글