[Associate SAA-C03] - dump 정리 201 ~ 210

---

201

커뮤니케이션 서비스 개발 / 사용자에게 단문 메시지 서비스로 확인 메시지 /사용자는 메시지에 답장 / 1년 동안 응답 저장

 

B. Amazon Pinpoint 여정을 구축합니다. Amazon Pinpoint를 구성하여 분석 및 보관을 위해 Amazon Kinesis 데이터 스트림으로 이벤트를 보냅니다.

* Amazon Pinpoint: 여러 메시징 채널을 통해 고객과 소통하는 데 사용할 수 있는 AWS 서비스

 1년 동안 응답 저장 -> Kinesis 데이터 스트림을 분석 및 보관 목적으로 사용 가능.

---

#202

데이터를 S3 버킷으로 옮기려고 계획 → S3 버킷에 저장될 때 암호화 / 암호화 키는 매년 자동으로 순환

A. 데이터를 S3 버킷으로 이동합니다. Amazon S3 관리 암호화 키(SSE-S3)로 서버 측 암호화를 사용합니다. SSE-S3 암호화 키의 기본 제공 키 회전 동작을 사용합니다.

 

* SSE-S3: 사용자가 키를 직접 관리할 필요 없이, S3가 암호화와 키 관리를 자동으로 처리하는 방식.

* 기본 제공 키 순환(로테이션): Amazon S3는 자체 관리 암호화 키를 1년마다 자동으로 순환(로테이션)

B. AWS Key Management Service(AWS KMS) 고객 관리 키를 만듭니다. 자동 키 로테이션을 활성화합니다. S3 버킷의 기본 암호화 동작을 고객 관리 KMS 키를 사용하도록 설정합니다. 데이터를 S3 버킷으로 이동합니다.

⇒ KMS 고객 관리 키 + 자동 키 로테이션 활성화

---

203

고객이 문자 메시지를 보내 약속 요청, 수락 / SQS 대기열에 게시 / 이메일 메세지 고객에게 전송 / Amazon DynamoDB 데이터베이스에 회의 정보를 저장 / 회사가 확장됨에 따라 고객은 회의 초대장이 도착하는데 시간이 더 걸린다고 보고

 

D. 회의 초대장을 보내는 애플리케이션에 대한 자동 확장 그룹을 추가합니다. SQS 대기열의 깊이에 따라 자동 확장 그룹을 확장하도록 구성합니다. 

 

⇒ 대기열에 보류 중인 메시지 수에 따라 자동으로 용량 조정 가능

* DynamoDB Accelerator( DAX) 클러스터 : DynamoDB의 읽기 성능은 향상 / 지연된 회의 초대장 문제는 해결 x

---

204

5000만 명 이상의 활성 고객 보유 / 매일 25000건 이상의 주문 / 고객의 구매 데이터 S3에 저장 / 추가 고객 데이터는 RDS에 저장

요구사항 → 모든 데이터를 다양한 팀에 제공하여 팀이 분석 /  세분화된 권한을 관리하는 기능  / 운영 오버헤드 최소화

 

C. AWS Lake Formation을 사용하여 데이터 레이크를 만듭니다. Amazon RDS에 AWS Glue JDBC 연결을 만듭니다. Lake Formation에 S3 버킷을 등록합니다. Lake Formation 액세스 제어를 사용하여 액세스를 제한합니다. 

* Lake Formation: 데이터에 대한 세분화된 권한을 쉽게 관리

 

* AWS Glue : 완전 관리형 ETL(추출, 변환, 로드) /데이터 통합, 분석 / 서버리스

* JDBC : AWS Glue가 데이터베이스에 접근할 수 있도록 설정. 

* Amazon Redshift 클러스터: 대규모 데이터 분석. 분산형 데이터베이스. 

* Amazon Athena: S3 데이터를 SQL을 사용해 분석. 대화형 쿼리 / 서버리스 

---

205

온프레미스 데이터 센터에 마케팅 웹사이트 호스팅 / 정적 문서로 구성, 단일 서버에서 실행 / 관리자는 웹 사이트 콘텐츠를 드물게 업데이트 하고 SFTP 클라이언트를 사용하여 새 문서 업로드

→ CloudFront 오리진 역할 웹 사이트 호스팅을 위한 가장 비용 효율적이고 복원력 있는 아키텍처 설계 

 

C. 개인 Amazon S3 버킷을 만듭니다. S3 버킷 정책을 사용하여 CloudFront 원본 액세스 ID(OAI)에서 액세스를 허용합니다. AWS CLI를 사용하여 웹사이트 콘텐츠를 업로드합니다.

 

→ S3 업로드에 비해 SFTP 업로드는 추가 비용과 복잡성 발생.

* 원본 액세스 ID(OAI): CloudFront 배포가 Amazon S3 버킷에서 제공되는 콘텐츠에 접근할 수 있도록 허용

* SFTP 클라이언트: SSH를 통해 데이터를 암호화한 원격 FTP 파일 전송 프로토콜. 

* Amazon Lightsail: 간편하고 저렴한 클라우드 서비스

* S3 버킷: 정적 콘텐츠 호스팅에 매우 비용 효율적

---

206

AMI를 AMI가 생성된 동일한 리전에 복사 / AWS API 호출을 캡처하고 계정내에서 EC2 CreateImage API 작업이 호출될 때마다 알림을 보내는 애플리케이션 설계 / 최소한의 운영 오버헤드

C. CreateImage API 호출에 대한 Amazon EventBridge(Amazon CloudWatch Events) 규칙을 만듭니다. CreateImage API 호출이 감지되면 알림을 보내도록 대상을 Amazon Simple Notification Service(Amazon SNS) 토픽으로 구성합니다.

 

* EventBridge: API호출 실시간 감지 

* CloudTrail: API 호출을 기록하지만 로그 데이터가 생성되기까지 시간 지연이 발생

---

207

비동기 API 소유 / API Gateway를 사용하여 API 프런트 엔드 배포, DynamoDB 호출하여 사용자 요청을 저장 / 마이크로서비스에 전송하는 Lambda 함수 사용 / DynamoDB 처리량을 프로비저닝했지만, 여전히 가용성 문제 발생 + 사용자 요청 손실

→ 기존 사용자에게 영향을 미치지 않고 문제 해결.

D. Amazon Simple Queue Service(Amazon SQS) 대기열과 Lambda를 사용하여 DynamoDB에 대한 쓰기를 버퍼링합니다.

 

⇒ SQS 대기열 사용(사용자 요청 손실 방지)

 

* DAX: DynamoDB의 성능을 개선하기 위해 캐싱 + 읽기 성능을 개선 + 데이터의 응답 시간을 줄이는 데 최적화 + 쓰기 성능 x

---

208

Amazon EC2 인스턴스에서 Amazon S3 버킷으로 데이터를 이동
API 호출과 데이터가 공개 인터넷 경로를 통해 라우팅되지 않도록 / EC2 인스턴스만 S3 버킷에 데이터 업로드 가능

 

A. EC2 인스턴스가 있는 서브넷에서 Amazon S3에 대한 인터페이스 VPC 엔드포인트를 만듭니다. S3 버킷에 리소스 정책을 연결하여 EC2 인스턴스의 IAM 역할만 액세스할 수 있도록 허용합니다.

⇒ 공개 인터넷 경로를 통하지 않는 것은 VPC Endpoint 사용 (gateway, interface)  

 

Gateway Endpoint에는 보안 그룹을 연결할 수 없으므로 Interface Endpoint 사용

---

209

Amazon EC2 On-Demand 인스턴스는 하루 종일 자주 확장 및 축소 / ALB가 부하 분산 처리 / 아키텍처는 분산 세션 데이터 관리를 지원해야함 / 필요한 경우 코드 변경 의향 있음

 

A. Amazon ElastiCache를 사용하여 세션 데이터를 관리하고 저장합니다.

 

* ElastiCache: 애플리케이션 코드에 큰 변화 , 분산 데이터 저장소 → 여러 가용성 영역에 걸쳐 여러 EC2 인스턴스에서 세션 데이터를 저장하고 액세스 가능(확장 가능하고 고가용성)

* Sticky Session: 로그인 후 스티키 세션을 통해 인증 상태를 지속적으로 유지 + 세션 데이터를 단일 EC2 인스턴스에만 저장할 수 있으므로 여러 가용성 영역에 걸쳐 확장 불가능

---

210

성장으로 인해 주문 처리 시스템 최대 트래픽 시간에 확장 문제 /주문 수집 프로세스는 빠르게 진행되지만 주문 이행 프로세스는 더 오래 걸릴 수 있음 /확장 이벤트로 인해 데이터가 손실되어서는 안 됨.

(주문 이행: 고객이 주문한 상품이나 서비스를 준비하고 제공하는 프로세스를 의미)

D. 두 개의 Amazon Simple Queue Service(Amazon SQS) 대기열을 제공합니다. 하나는 주문 수집용이고 다른 하나는 주문 이행용입니다. EC2 인스턴스가 해당 대기열을 폴링하도록 구성합니다. 인스턴스당 백로그 계산을 기반으로 메트릭을 만듭니다. 이 메트릭을 기반으로 Auto Scaling 그룹을 확장합니다. 

 

⇒ 데이터가 손실되면 안되므로 SQS 대기열 사용

⇒ 대기열에 백로그가 쌓일 때 풀을 스케일링 해야함

 

* poll : 주기적으로 큐를 확인하여 새로운 메세지나 작업을 처리하는 것. 

* 백로그: 처리되지 않은 메세지 수

 

“알림”에 따라 Auto Scailing Group 확장은 말이 안되는 말 → 주문 수집은 빠르게 처리되지만 이행이 어려움을 겪고 있으므로 들어오는 요청 수에 따라서가 아니라 대기열에 백로그가 쌓일 때 폴을 스케일링 해야함

---