[Associate SAA-C03] - dump 정리 271 ~ 280
271
인스턴스 용량 도달 전에 매일 밤 일괄 처리 작업이 1시간동안 자동으로 확장 / 최대 용량은 매일 밤 동일하고 일괄 작업은 항상 오전 1시에 시작
→ 용량에 빠르게 도달하고 일괄 작업이 완료된 후 자동 확장 그룹이 축소할 수 있도록 하는 비용 효율적인 솔루션
C. 원하는 컴퓨팅 수준까지 확장하도록 예약된 확장을 구성합니다.
* 예약 스케일링: 원하는 컴퓨팅 수준까지 확장, 일괄 작업이 시작 전에 원하는 컴퓨팅 수준까지 미리 확장하고 작업이 완료되면 자동 확장이 축소되도록 설정.
272
ALB뒤의 인스턴스 플릿에서 동적 웹사이트 제공 / 전 세계 고객에게 제공하기 위해 여러 언어 지원 / 아키텍처는 현재 us-west-1 지역에서 실행 / 전 세계 다른 지역에서는 높은 요청 지연 시간
→ 사용자의 위치에 관계없이 요청을 빠르고 효율적으로 처리하는 솔루션. 기존 아키텍처는 유지.
B. ALB를 원본으로 하여 Amazon CloudFront 배포를 구성합니다. Accept-Language 요청 헤더에 따라 캐시하도록 캐시 동작 설정을 설정합니다.
273
단일 AWS 지역에서 워크로드 실행 / 다른 AWS 지역을 포함하는 재해 복구(DR) 전략 →
가능한 지연 시간을 최소화하면서 DR 지역에서 DB를 최신 상태로 유지하고자 함 + 나머지 인프라는 감소된 용량으로 실행하며 필요한 경우 확장 → 가장 낮은 복구 시간 목표(RTO)
B. 웜 스탠바이 배포를 통해 Amazon Aurora 글로벌 데이터베이스를 사용합니다.
* 파일럿 라이트: 전체 인프라를 DR 지역에 즉시 복제하지 않고, 필수적인 핵심 시스템을 최소한의 구성으로 준비해 두는 방법
* 웜 스탠바이: 주 데이터 센터의 주요 시스템과 데이터를 DR 지역에 복제하고, 이들을 지속적으로 동기화하여 빠르게 전환할 수 있는 상태를 유지하는 방법
⇒ 다른 Region이므로 Multi-AZ는 필요없음
274
재해 복구 (DR) 솔루션 구현 + 4시간 미만의 복구 시간 목표(RTO) + 솔루션은 정상 운영중에 가능한 가장 적은 AWS 리소스를 사용 +가장 운영적으로 효율적인 방식
B. EC2 인스턴스를 백업하기 위해 Amazon Machine Images(AMI)를 만듭니다. AMI를 보조 AWS 리전에 복사합니다. AWS CloudFormation을 사용하여 보조 리전에서 인프라 배포를 자동화합니다.
* AMI: 인스턴스의 상태와 구성을 저장하여 쉽고 빠르게 백업, 복구
* IaC : 인프라를 코드로 정의하고 관리. / IaC가 없으면 수동으로 복원
* CloudFormation 템플릿을 사용하면 복구 영역에서 인프라를 빠르게 재배포 / RTO 충족.
백업 및 복원은 데이터 손실/손상의 결과를 완화하는데 적합
AWS Cloudformation을 사용하는 IAC를 사용하여 배포 수행.
275
ALB / ASG에서 실행 / 근무 시간 동안 최대 20개의 인스턴스로 확장되지만 밤새 2개의 인스턴스로 축소 / 오전 중반까지는 인스턴스가 잘 실행되지만 하루가 시작될 때 매우 느리다고 불편
→ 비용 최소화 솔루션.
C. 낮은 CPU 임계값에서 트리거되는 대상 추적 동작을 구현하고 쿨다운 기간을 줄입니다.
대상 추적 확장 정책 사용: CPU 사용률과 같은 특정 메트릭에 대해 인스턴스 수 자동 조정.
CPU 임계값 낮추기: 작업 부하가 증가할때 평소보다 사전에 인스턴스를 추가하여 하루의 시작 시 느림을 해결하는데 도움이 된다
쿨다운 기간 단축: ASG가 더 빠르게 확장 및 축소 가능
A. 사무실이 문을 열기 직전에 원하는 수용 인원을 20명으로 설정하는 예약된 작업을 구현합니다.
→ 20개를 유지하면 비용 효율적 x
276
Oracle 특정 PL/SQL 함수를 사용 / 애플리케이션에 대한 트래픽 꾸준히 증가 → 인스턴스 과부화 , RDS 스토리지 부족 +
ASG에는 확장 메트릭이 없고 최소 정상 인스턴스 수만 정의 / 트래픽이 안정적이지만 예측할 수 없는 속도로 계속 증가한 후 평준화 될것으로 예측 → 증가한 트래픽에 맞게 자동으로 확장될 수 있도록
A. RDS for Oracle 인스턴스에서 스토리지 자동 크기 조정을 구성합니다.
→ 스토리지 자동 크기 조정: 원하는 최대 스토리지를 설정하기만 하면 Auto Scailing이 나머지를 처리
D. 자동 크기 조정 그룹을 구성하여 평균 CPU를 크기 조정 지표로 사용합니다.
→ Auto Scailing 그룹에서 평균 CPU를 확장 메트릭으로 사용: 애플리케이션 수요에 따라 EC2 인스턴스 수를 동적으로 조정 가능 = 증가된 트래픽 처리 가능
277
비디오 콘텐츠 게시 / 모든 플랫폼에서 사용할 수 있도록 트랜스코딩하는 서비스 / EFS 사용 / 서비스가 인기가 높아짐에 따라 저장 비용이 너무 비싸짐 / 가장 비용 효율적
D. 비디오 콘텐츠를 저장하기 위해 Amazon S3를 사용합니다. 파일을 처리를 위해 서버에 연결된 Amazon Elastic Block Store(Amazon EBS) 볼륨으로 임시로 옮깁니다.
* Storage Gateway: 컨텐츠를 저장하는데 사용되지 않으며 클라우드로 전송하는데만 사용
* S3: 비디오와 같은 대용량 데이터를 저장하는데 내구성, 확장성, 비용 효율적. EFS에 비해 저장 비용이 낮고 대용량 파일을 저장하는데 적합함
* EBS: Amazon S3에 데이터를 백업할 수 있는 스냅샷 기능을 제공
278
직원 데이터를 계층 구조적 관계로 저장하는 애플리케이션
→ 직원 데이터에 대한 트래픽이 많은 쿼리에 대한 최소 지연 응답이 필요 / 민감한 데이터 보호 / 재무 정보가 있을 경우 월별 이메일 메시지를 받아야함.
B. Amazon DynamoDB를 사용하여 직원 데이터를 계층 구조로 저장합니다. 매월 Amazon S3로 데이터를 내보냅니다.
E. AWS 계정에 대해 Amazon Macie를 구성합니다. Macie를 Amazon EventBridge와 통합하여 Amazon Simple Notification Service(Amazon SNS) 구독을 통해 월별 알림을 보냅니다.
* DynamoDB: 복잡한 계층적 데이터를 단일 항목 내에 저장
* Macie: 민감한 정보를 다루는 AWS 서비스,
* SNS: 월별 알림
279
DynamoDB 테이블로 백업된 애플리케이션 / 규정 준수 요구 사항에는 DB 백업을 매월 수행 / 6개월 동안 사용 / 7년 동안 보관
A. 매월 1일에 DynamoDB 테이블을 백업하기 위한 AWS 백업 계획을 만듭니다. 6개월 후 백업을 콜드 스토리지로 전환하는 수명 주기 정책을 지정합니다. 각 백업의 보관 기간을 7년으로 설정합니다.
콜드 스토리지: 자주 엑세스 되지 않는 데이터를 보관하는 목적의 스토리지
DynamoDB: Amazon S3 Glacier로의 백업 전환을 지원 X
S3 Glacier: 접근이 적은 데이터를 장기적으로 데이터를 안전하게 보관하는 저비용 클라우드 스토리지 서비스
cli와 cron 작업만으로는 콜드 스토리지로의 전환이 불가능. BCD의 옵션은 aws Badckup이 이미 수행.
280
CloudFront 사용 / 배포에서 로깅을 활성화 / S3 버킷에 로그 저장 /
→ 로그에 대한 고급 분석을 수행하고 시각화
B. Amazon Athena에서 표준 SQL 쿼리를 사용하여 S3 버킷의 CloudFront 로그를 분석합니다. Amazon QuickSight로 결과를 시각화합니다.
로그 분석 → Athena
시각화 → QuickSight : 데이터를 시각화. RDS, Athena, S3와 연동이 가능
Glue : 완전 관리형 데이터 ETL.