571
회사가 REST API를 생성 + TLS 사용에 대한 엄격한 요구사항을 가지고 있음 + API 엔드포인트에서 TLSv1.3을 요구 + 특정 공공 제 3자 인증기관(ca)이 TLS인증서에 서명하도록 요구
A. 로컬 머신을 사용하여 타사가 서명한 인증서를 만듭니다. AWS Certificate Manager(ACM)로 인증서를 가져옵니다. 사용자 지정 도메인이 있는 Amazon API Gateway에서 HTTP API를 만듭니다. 인증서를 사용하도록 사용자 지정 도메인을 구성합니다.
⇒ ACM에서 직접 공개적으로 신뢰할 수 있는 인증서를 요청하거나 제3자가 발급한 공개적으로 신뢰할 수 있는 인증서를 가져올 수 있지만 만들 수는 없음 + 자체 서명 인증서도 지원함
TLS: 클라이언트와 서버 간 전송 데이터 암호화. 인증 기관(CA)에서 발급한 인증서 사용하여 신원 확인. TLS는 HTTP 트래픽을 보호. VPN 프로토콜은 TLS를 사용하여 연결.
572
애플리케이션 실행 + 일관되지 않은 양의 사용량 수신 + Direct Connect 사용하여 온프레미스 MYSQL 호환 데이터베이스에 연결 (최소 2GiB)의 메모리를 지속적으로 사용 → AWS로 데이터베이스 마이그레이션 + 자동 확장 기능을 사용하여 예상치 못한 작업 부하 증가를 관리하려고함 + 최소한의 관리 오버헤드 자동 확장 기능
→ 예상치 못한 작업 부하 증가 관리 + 최소한의 관리 오버헤드(서버리스)
C. 최소 1 Aurora 용량 단위(ACU)의 용량을 갖춘 Amazon Aurora Serverless v2 데이터베이스를 프로비저닝합니다.
⇒ Aurora Serverless는 자동 확장 제공(관리자 개입 없이 일관되지 않은 작업 부하와 급증 자동 처리 가능
573
Lambda에서 이벤트 기반 프로그래밍 모델을 사용 + Java 11에서 실행되는 Lambda 함수의 시작 지연 시간을 줄이고자함 + 엄격한 지연 시간 요구 사항이 없음 + 함수가 확장될 때 콜드 스타트와 이상치 지연 시간을 줄이고자 함 + 가장 비용 효율적 충족
D. Lambda SnapStart를 구성합니다.
⇒ Lambda의 SnapStart: Java 언어와 함께 Lambda를 사용할 때 cold start 시간을 대폭 개선하기 위한 기능 + 함수 코드를 변경하지 않고도 추가 비용 없음
574
RDS for MYSQL 데이터베이스를 사용하는 새로운 애플리케이션 출시 + 주식 시장 동향 추적 → 매주 말에 2시간만 애플리케이션을 운영해야함 + 데이터베이스 운영 비용을 최적화 + 가장 비용 효율적
A. 기존 RDS for MySQL 데이터베이스를 Aurora Serverless v2 MySQL 데이터베이스 클러스터로 마이그레이션합니다.
⇒ Aurora Serverless v2 ⇒ 실제 사용량에 따라 자동으로 컴퓨팅 용량을 확장하며, 사용하지 않을 때는 0까지 줄임 이를 통해 간헐적 사용에 대한 비용이 최소화 주당 2시간만 실행되므로 이 애플리케이션은 Aurora Serverless와 같은 서버리스 아키텍처에 이상적
575
AWS 지역의 ALB 뒤에 있는 EKS에 애플리케이션을 배포 + PostgreSQL 데이터베이스 엔진에 데이터를 저장 + 고가용성 + 읽기 워크로드 용량 늘려야함 + 가장 높은 운영 효율성
C. 다중 AZ DB 클러스터 배포를 통해 Amazon RDS 데이터베이스를 만듭니다.
* PostgreSQL=관계형 DATABASE
⇒ 다중 AZ DB 클러스터 배포는 읽기 전용 복제본을 지원
다중 AZ 배포는 읽기 성능 향상을 위한 읽기 복제본을 제공 X → 읽기 성능 향상을 위해서는 별도의 읽기 복제본 구성이 필요
576
회사가 API Gateway와 Lambda를 사용하여 RESTful 서버리스 웹 애플리케이션을 구축 + 사용자는 지리적으로 분산되어있음
→ 이러한 사용자에게 API 요청 지연시간을 줄이고자함
D. Edge 최적화 엔드포인트
지리적으로 분산된 사용자 + 낮은 대기 시간 = Edge 최적화된 endpoint
⇒ 엣지 최적화 API 엔드포인트: 일반적으로 클라이언트가 지리적으로 분산된 경우 도움이 되는 가장 가까운 CloudFront 접속 지점(POP)으로 요청을 라우팅
577
회사가 CloudFront 배포판을 사용하여 웹 사이트의 콘텐츠 페이지를 제공 + 클라이언트가 회사 웹사이트에 액세스할 때 TLS 인증서를 사용하도록 해야함 → TLS 인증서의 생성 및 갱신을 자동화하려고함 + 가장 높은 운영 효율성
C. AWS Certificate Manager(ACM)를 사용하여 인증서를 만듭니다. 도메인에 대한 DNS 검증을 사용합니다.
AWS Certificate Manager(ACM): 무료 공개 TLS/SSL 인증서를 제공하고 인증서 갱신을 자동으로 처리
ACM에서 DNS 검증을 사용하면 수동 검증 단계가 필요 없이 Route 53을 자동으로 변경하므로 운영상 효율적
→ 이메일 검증에는 각 갱신에 대한 도메인 검증 이메일을 승인하기 위한 수동 단계가 필요
578
DynamoDB를 데이터베이스 계층으로 사용하는 서버리스 애플리케이션 배포 + 사용자가 크게 증가 → 데이터베이스 응답 시간을 밀리초에서 마이크로초로 개선하고 데이터베이스에 대한 요청을 캐시하려고함 + 최소한의 운영 오버헤드
A. DynamoDB Accelerator(DAX)를 사용하세요.
⇒ DAX(DynamoDB Accelerator): 테이블에 대한 읽기 성능을 크게 향상시키는 인메모리 캐시 + 지연시간이 짧음
579
PostgreSQL용 RDS를 사용하는 애플리케이션 실행 + 평일 업무 시간에만 트래픽 수신 → 사용량에 따라 비용을 최적화하고 운영 오버헤드를 줄이려고함
A. AWS의 인스턴스 스케줄러를 사용하여 시작 및 중지 일정을 구성합니다.
⇒ 인스턴스 스케줄러: 켜 놓는 시간에 비례하여 과금되기 때문에 쓰지 않을 때는 꺼놓는 것이 현명→ 시작 및 중지 일정 구성
인스턴스 스케줄러는 AWS Systems Manager Parameter Store와 함께 사용하여 인스턴스의 시작 및 중지 일정을 자동으로 관리 → 수동으로 인스턴스를 관리할 필요가 없어 운영 오버헤드를 줄일 수 있음
580
로컬로 연결된 스토리지를 사용하여 사내에서 지연에 민감한 애플리케이션 실행 + 리프트 앤 시프트 방식을 사용하여 AWS 클라우드로 이동 → 아키텍처를 변경하고 싶지 않음 + 가장 비용 효율적으로 충족
* 리프트 앤 시프트 방식: 클라우드 환경으로 이동할 때 구조적인 변화를 최소화로옮기는 전략.
D. Amazon EC2 인스턴스에서 애플리케이션을 호스팅합니다. Amazon Elastic Block Store(Amazon EBS) GP3 볼륨을 사용하여 애플리케이션을 실행합니다.
⇒ GP2, GP3 모두 최대 IOPS는 16000이지만 GP3가 비용 효율적
* GP2, GP3: 클라우드 환경에서 저장 장치의 성능과 가격을 맞춤형으로 제공. SSD 스토리지
581
애플리케이션은 항상 최소 2개의 EC2 인스턴스 필요 + 고가용성 및 내결함성 아키텍처를 설계해야함 + EC2 인스턴스의 자동확장 그룹 생성 → 요구사항 충족
B. 자동 확장 그룹의 최소 용량을 4로 설정합니다. 한 가용성 영역에 두 개의 온디맨드 인스턴스를 배포하고 두 번째 가용성 영역에 두 개의 온디맨드 인스턴스를 배포합니다.
⇒ Auto Scaling 그룹의 최소 용량을 4로 설정함으로써 아키텍트는 항상 최소 두 개의 실행 인스턴스가 있도록 설정 → 두 개의 가용성 영역에 두 개의 온디맨드 인스턴스를 배포하면 애플리케이션이 고가용성 및 내결함성을 보장 (한 AZ가 무너지더라도 다른 AZ에는 2개의 인스턴스 사용 가능)
스팟 인스턴스: 중단되어도 상관없는 작업. 비용 절감
온디멘드 인스턴스: 중단 없이 안정적. 예측 불가능한 사용 패턴.
582
회사가 DNS 공급자로 Route 53 사용 + 사내 데이터 센터는 us-west-1 지역 근처에 있음 + 회사는 eu-central-1 지역을 사용하여 웹사이트를 호스팅 → 회사는 웹사이트의 로드시간을 최대한 최소화 하려고함
A. 지리적 위치 라우팅 정책을 설정합니다. us-west-1 근처의 트래픽을 온프레미스 데이터 센터로 보냅니다. eu-central-1 근처의 트래픽을 eu-central-1로 보냅니다.
⇒ 지리적 위치 라우팅을 사용하면 사용자의 지리적 위치를 기준으로 가장 가까운 엔드포인트로 사용자를 라우팅 → 지연 시간이 가장 짧음
us-west-1 근처의 트래픽: 사용자가 us-west-1 지역 근처에 있는 경우, 트래픽을 온프레미스 데이터 센터(즉, 회사의 사내 데이터 센터)로 보냄
eu-central-1 근처의 트래픽: 사용자가 eu-central-1 지역 근처에 있는 경우, 트래픽을eu-central-1에 위치한 AWS 클라우드로 보냄
583
물리적 테이프에 5PB의 보관 데이터 보관 + 규정 준수를 위해 테이프의 데이터를 10년 더 보존해야함 + 6개월 안에 AWS로 마이그레이션 + 1Gbps의 업링크 인터넷 연결을 갖추고 있음 +가장 비용 효율적 충족
C. Tape Gateway가 있는 여러 AWS Snowball 장치를 주문합니다. Snowball의 가상 테이프에 물리적 테이프를 복사합니다. Snowball 장치를 AWS로 배송합니다. 테이프를 Amazon S3 Glacier Deep Archive로 옮기는 수명 주기 정책을 만듭니다.
⇒ 테이프의 데이터를 10년 더 보존 ⇒ S3 Glacier Deep Archive
⇒AWS Snowball을 사용하여 물리적 테이프에 저장된 페타바이트 규모의 데이터를 aws로 마이그레이션
584
대량의 데이터를 병렬로 처리하는 애플리케이션 배포 + 워크로드에 EC2 인스턴스를 사용할 계획
→ 노드 그룹이 동일한 기본 하드웨어를 공유하지 못하도록 구성 가능해야함
A. EC2 인스턴스를 분산된 배치 그룹에서 실행합니다.
* 전용 테넌시: 다른 AWS 계정과 공유되지 않는 하드웨어에서 실행되도록 보장 한 계정안에서는 공유 가능
* 공유 테넌시: 여러 AWS 계정이 동일한 물리적 하드웨어를 공유하는 방식
* 분산 배치 그룹: 하드웨어 수준에서 인스턴스 격리 가능
585
장애 조치 AWS 지역에서 EC2 용량을 제공하기 위한 재해 복구(DR)전략을 설계 → DR 전략은 장애 조치 지역의 용량을 충족
D. 장애 조치 지역에서 용량 예약을 구매합니다.
⇒ 용량 예약: 온디맨드 또는 예약 인스턴스를 사용하던 관계없이 인스턴스에 대한 특정 지역에서 용량을 예약했는지 확인
→ 필요한 EC2 용량을 필요할 때 사용할 수 있도록 보장하기 때문
특정 인스턴스를 구매하지 않고도 주어진 지역에서 인스턴스 용량 예약 가능
586
Organizations에서 조직의 일부로 5개의 조직 단위(OU) → 회사의 연구 개발 사업은 회사와 분리되어 자체조직이 필요함 + 이 목적을 위해 별도의 새 관리 계정을 만듬 + 새 관리 계정에서 무엇을
B. R&D AWS 계정이 이전 조직을 떠난 후 R&D AWS 계정을 새 조직에 초대합니다.
⇒ 계정은 첫 번째 조직을 먼저 떠나야 다른 조직에 가입 가능
587
분석을 처리하고 예측을 하기 위해 다양한 웹 애플리케이션에서 고객 활동을 포착하는 솔루션 설계 + 고객활동은 예측할 수 없으며 갑자기 증가할 수 있음 → 다른 웹 애플리케이션과 통합되는 솔루션 필요 + 보안을 위한 권한 부여 단계 포함
C. Amazon S3 버킷에서 회사가 수신하는 정보를 저장하는 Amazon Kinesis Data Firehose 앞에 Amazon API Gateway 엔드포인트를 구성합니다. API Gateway Lambda 권한 부여자를 사용하여 권한을 확인합니다.
⇒ 권한부여자: Lambda 권한 부여자(이전 사용자 지정 권한 부여자)는 Lambda 함수를 사용하여 API 메서드에 대한 액세스를 제어하는 API Gateway 기능
* Kinesis Data Firehose ↔ S3 연동 가능 (Kinesis Data Stream은 s3와 불가능)
+ ECS에 정보를 저장하는 것은 지나친 선택
GWLB는 네트워크 트래픽을 처리하고 라우팅만 하고 권한 부여는 x
Lambda 함수를 사용하여 권한을 확인할 수 있지만, API Gateway가 권한 부여를 처리하지 않고 Lambda 자체에서 권한을 확인하는 방식은 적절한 보안 계층이 부족
588
RDS DB 인스턴스 재해 복구 솔루션 → 현재 복구 지점 목표(RPO)와 복구 시간 목표(RTO)는 24시간 → 가장 비용 효율적 충족
D. 24시간마다 다른 지역으로 자동 스냅샷을 복사합니다.
* RDS 자동 스냅샷: 사용자가 정해둔 일정에 따라 주기적으로 rds 인스턴스의 상태를 저장
사용자의 설정에 따라 각각의 스냅샷은 보존기간을 가지고 있음 + 중지가 될지 안 될지를 결정하는 것은 다중 AZ 설정 여부
→ 지속적인 리전 간 복제를 유지하는 것에 비하면 비용 효율적
589
웹 서버 중단 시 고가용성 보장 + 사용자 세션 상태 손실 방지
B. Amazon ElastiCache for Redis를 사용하여 세션 상태를 저장합니다. ElastiCache for Redis를 사용하여 세션 상태를 저장하도록 애플리케이션을 업데이트합니다.
⇒ Amazon ElastiCache for Redis는 Redis가 메모리 내 데이터 스토리지와 지속성 옵션을 모두 제공하기 때문에 세션 상태 스토리지에 적합, Redis는 복제, 지속성 및 고가용성
+ Memcached는 고가용성 X
세션 데이터는 짧은 수명과 빠른 접근이 필요한 특징
590
보고서 쿼리 → 한 달에 한 번, 데이터베이스가 느리게 실행, 일일 작업 부하의 성능 유지 할 수 있는 기능
A. 데이터베이스의 읽기 복제본을 만듭니다. 쿼리를 읽기 복제본으로 보냅니다.
→ 보고서에 대한 쿼리 = 읽기 복제본
591
EKS를 사용하여 컨테이너 애플리케이션을 실행 + 고객을 관리하고 주문을 하는 마이크로서비스가 포함 → 들어오는 요청을 적절한 마이크로서비스로 라우팅 + 가장 비용 효율적
B. AWS Load Balancer Controller를 사용하여 Application Load Balancer를 프로비저닝합니다.
* AWS Load Balancer Controller: AWS 로드 밸런서 컨트롤러는 Amazon EKS 클러스터에 대한 애플리케이션 로드 밸런서(ALB) 또는 네트워크 로드 밸런서(NLB)를 쉽게 설정할 수 있는 Kubernetes 컨트롤러+ EKS에서 실행되는 애플리케이션의 로드 밸런서를 관리하는 프로세스를 간소화
비용 : ALB < NLB
592
저작권이 있는 이미지에 대한 액세스를 판매 + 글로벌 고객 기반은 이러한 이미지에 빠르게 액세스할 수 있어야함 → 특정 국가의 사용자에게 액세스를 거부해야함 + 비용 최적화
D. Amazon S3를 사용하여 이미지를 저장합니다. Amazon CloudFront를 사용하여 지리적 제한이 있는 이미지를 배포합니다. 각 고객이 CloudFront의 데이터에 액세스할 수 있도록 서명된 URL을 제공합니다.
→ CloudFront 지리적 제한 기능 ⇒ 지정된 웹 배포를 통해 배포하는 모든 파일에 대해 국가 수준에서 콘텐츠 배포를 제어 가능
593
Redis 기반 솔루션을 위한 고가용성 Amazon ElastiCache 설계 + 장애로 인해 로컬 및 AWS 리전 내에서 성능 저하 또는 데이터 손실이 발생하지 않도록 해야함 + 노드 수준과 리전 수준에서 고가용성을 제공
A. 여러 노드가 포함된 샤드가 있는 다중 AZ Redis 복제 그룹을 사용합니다.
노드 수준의 고가용성 ⇒ 샤드 및 다중 AZ = 리전 수준
샤드는 복제를 지원 + 샤드에서 노드 하나가 읽기/쓰기 기본 노드로 사용, 샤드에 있는 다른 모든 노드는 기본 노드의 읽기 전용 복제본 역할
두 개 이상의 읽기 복제본만으로는 리전 수준의 장애에 대비 X
594
AWS로 마이그레이션하고 EC2 On-Demand 인스턴스를 애플리케이션에 사용할 계획 → 마이그레이션 테스트단계에서 기술 팀은 애플리케이션이 완전히 생산적이되기 위해 메모리를 시작하고 로드하는데 오랜 시간이 걸린다는 것을 관찰 → 애플리케이션의 시작
시간을 줄이는 솔루션
C. 최대 절전 모드를 켜고 EC2 온디맨드 인스턴스를 시작합니다. 다음 테스트 단계에서 EC2 자동 확장 웜 풀을 구성합니다.
⇒ EC2 최대 절전 모드 (하이버네이션): EC2 인스턴스의 메모리 내 상태를 영구 저장소에 저장하고 인스턴스를 종료, 인스턴스가 다시 시작되면 메모리 내 상태가 복원되어 새 인스턴스를 시작하는 것보다 훨씬 빠르게 시작
* 웜 풀: EC2 인스턴스를 미리 초기화하고 요청을 충족할 준비를 하여 시작 시간을 줄임
595
애플리케이션이 주중 임의의 요일에 갑자기 트래픽이 증가하는 것을 발견 → 갑자기 트래픽이 증가하는 동안 애플리케이션의 성능 유지 + 가장 비용 효율적 충족
C. 자동 크기 조정 그룹의 크기를 변경하려면 동적 크기 조정을 사용합니다.
* 동적 크기 조정: 인스턴스 수가 수신된 트래픽에 따라 자동으로 변경 + 예측할 수 없는 트래픽이 많은 경우에 좋은 선택
596
PostgreSQL 데이터베이스 사용 + 월별 이벤트 동안 사용량이 증가하고 애플리케이션에 대한 데이터베이스 연결 문제 발생 + 이벤트 트래픽은 예측할 수 없으며, 판매 예측에 영향을 줌 → 트래픽이 예측할 수 없이 증가할 때 성과를 유지해야함 + 가장 비용 효율적인
방식
A. PostgreSQL 데이터베이스를 Amazon Aurora Serverless v2로 마이그레이션합니다.
* Aurora Serverless v2: 자동 확장 기능, 높은 가용성 , 저렴
597
API Gateway + Lambda 사용하여 AWS에서 내부 서버리스 애플리케이션을 호스팅 → 매일 시작할 때 지연 시간이 길다는 문제 + 지연 시간을 줄이고자함
B. 직원들이 매일 애플리케이션을 사용하기 전에 Lambda 프로비저닝 동시성을 늘리기 위해 예약된 확장을 설정합니다.
⇒ 프로비저닝된 동시성 사용: 함수에 대한 실행 환경을 사전 초기화 → 하루 시작 시 들어오는 함수 요청에 즉시 응답 가능
(※콜드 스타트 지연 시간을 줄일 수 있음)
598
.csv 파일 생성 + SMB 파일 공유에 데이터 쓰는 것을 지원 + SQL 명령을 사용하여 데이터를 쿼리 → 가장 비용 효율적으로 충족
A. Amazon S3 파일 게이트웨이 모드에서 온프레미스에 AWS Storage Gateway를 배포합니다.
⇒ 온프레미스의 .csv 파일을 SMB 파일 공유로 자동 업로드.
FSx for Windows File Server와 같은 고성능 파일 시스템은 비용이 더 높음
C. Amazon S3에 있는 데이터를 기반으로 테이블을 생성하기 위해 AWS Glue 크롤러를 설정합니다.
F. Amazon S3에 있는 데이터를 쿼리하기 위해 Amazon Athena를 설정합니다. 분석가에게 액세스를 제공합니다.
S3에 있는 .csv → 데이터 변환 (AWS Glue) 쿼리 → Amazon Athena
* AWS Glue: S3에 저장된 CSV파일을 분석, 추출, 테이블 생성. 쿼리 준비.
* AWS Athena: 직접 쿼리. 사용한 만큼 지불
599
ECS 클러스터 + RDS DB를 사용하여 결제 처리 애플리케이션 빌드 실행 + 규정 준수 + AWS Outposts
→ 운영 팀의 책임
A. Outposts 랙에 탄력적인 전원 및 네트워크 연결 제공
C. 데이터 센터 환경의 물리적 보안 및 접근 제어
F. 서버 오류 및 유지 관리 이벤트를 완화하기 위해 Amazon ECS 클러스터에 추가 용량 제공
Outpost를 작동 상태로 유지하고 Outpost를 Region에 다시 연결하기 위한 네트워크 연결을 제공하기 위해 충분한 전력, 공간 및 냉각을 제공
Outpost 용량은 유한하며 AWS가 사이트에 설치하는 랙의 크기와 수에 따라 결정되므로 초기 작업 부하를 실행 + 향후 성장을 수용하고, 서버 오류와 유지 관리 이벤트를 완화하기 위한 추가 용량을 제공하는 데 필요한 EC2, EBS, Outposts 용량을 결정
AWS책임: Outposts 랙 내의 전원 공급 장치, 서버 및 네트워킹 장비를 포함한 Outposts 인프라의 가용성을 담당.
Outposts에서 실행되는 가상화 하이퍼바이저, 스토리지 시스템 및 AWS 서비스를 관리
600
TCP 기반 애플리케이션을 회사의 VPC로 마이그레이션 + 회사 데이터 센터의 하드웨어 어플라이언스를 통해 비표준 TCP 포트에서 공개적으로 액세스 + 퍼블릭 엔드포인트는 낮은 지연 시간으로 초당 최대 300만 개의 요청을 처리 → 새로운 퍼블릭 엔드포인트에 대해 동일한 수준의 성능 필요
A. 네트워크 로드 밸런서(NLB)를 배포합니다. 애플리케이션에 필요한 TCP 포트를 통해 공개적으로 액세스할 수 있도록 NLB를 구성합니다.
→ CloudFront: 콘텐츠 전송 네트워크. HTTP기반 트래픽 최적화
'클라우드 > AWS' 카테고리의 다른 글
| [Associate SAA-C03] - dump 정리 631 ~ 650 (0) | 2024.10.12 |
|---|---|
| [Associate SAA-C03] - dump 정리 601 ~ 630 (0) | 2024.10.12 |
| [Associate SAA-C03] - dump 정리 531 ~ 570 (0) | 2024.10.12 |
| [Associate SAA-C03] - dump 정리 501 ~ 530 (0) | 2024.10.08 |
| [Associate SAA-C03] - dump 정리 471~500 (0) | 2024.10.08 |