351
회사가 데이터 관리 애플리케이션을 AWS로 옮김 / 이벤트 기반 아키텍처로 전환 → 아키텍처는 더욱 분산되어야 하며 워크플로의 다양한 측면을 수행하는 동안 서버리스 개념 사용해야함 + 운영 오버헤드 최소화
D. AWS Step Functions에서 워크플로를 구축합니다. Step Functions를 사용하여 상태 머신을 만듭니다. 상태 머신을 사용하여 AWS Lambda 함수를 호출하여 워크플로 단계를 처리합니다.
* AWS Step Functions: 서버리스 오케스트레이션 서비스로, 분산 애플리케이션이나 마이크로서비스 워크플로우를 구축하고 조정 하는 시각적 워크플로 서비스 + 서버리스 서비스이므로 EC2 사용하는 것이 아닌 Lambda 사용하는 것이 적합
* EventBridge: 이벤트 기반 아키텍처 / 워크플로우, 오케스트레이션 x
352
온라인 멀티 플레이어 게임을 위한 네트워크 설계 / UDP 프로토콜을 사용하며 8개의 AWS 지역에 배포
→ 최종 사용자에게 고품질 경험을 제공하기 위해 지연 시간과 패킷 손실을 최소화
B. 각 지역에서 UDP 리스너와 엔드포인트 그룹을 사용하여 AWS Global Accelerator를 설정합니다.
⇒ UDP 리스너로 UDP 트래픽을 수신하고 해당 트래픽을 적절한 엔드포인트(게임서버)로 라우팅.
AWS Global Accelerator를 통해 글로벌 사용자에게 제공하는 애플리케이션의 가용성과 성능을 향상하는데 도움이 되는 네트워킹 서비스로 TCP/UDP 지연시간 최소화
* AWS Global Accelerator : UDP와 TCP 프로토콜을 모두 지원하여, 게임과 같은 실시간 데이터 전송에 적합 / 사용자 요청을 가장 가까운 AWS 리전의 엔드포인트로 자동으로 라우팅하여 지연 시간을 최소화 / 패킷 손실 감소
353
EBS 볼륨에 데이터를 저장 / 현재 1TB Provisioned IOPS SSD(io2) EBS 볼륨 사용 / 최대 트래픽에서 읽기와 쓰기 모두에 대해 1,000 IOPS의 트래픽을 예상
→ 중단을 최소화 + 성능을 안정화 + 비용을 절감 / 동시에 IOPS를 두 배로 증가 + 고가용성과 내결함성이 있는 완전 관리형 솔루션 + 비용 효율적
B. 범용 SSD(gp2) EBS 볼륨이 있는 Amazon RDS for MySQL DB 인스턴스의 다중 AZ 배포를 사용합니다.
* RDS 스토리지 유형
- 프로비저닝된 IOPS SSD(io1): 낮은 I/O 지연시간과 일관된 I/O 처리량이 필요한 워크로드.
- 범용 SSD(gp2): 중간 크기 DB 인스턴스에서 실행되는 광범위한 워크로드에 이상적 / 자동으로 IOPS를 프로비저닝 / 3 IOPS/GB ~ 최대 16,000 IOPS까지 지원 / 저렴한 비용
- io2 Block Express: 높은 IOPS와 낮은 대기 시간 / 높은 비용 / 1,000 IOPS ~ 최대 64,000 IOPS
* S3 Intelligent-Tiering : AWS S3에서 사용되는 객체 스토리지로, 데이터 접근 패턴에 따라 자동으로 비용을 최적화
354
서버리스 / Amazon API Gateway, AWS Lambda, PostgreSQL 데이터베이스용 Amazon RDS를 사용 / 트래픽이 많거나 예측할 수 없는 시간대에 연결 시간 초과로 인한 오류 증가 ⇒ 코드 최소한으로 변경
B. RDS DB 인스턴스에서 RDS 프록시를 활성화합니다.
* RDS Proxy: RDS를 위한 완전 관리형, 고가용성, 확장 가능한 프록시 / Lambda에서 실행되는 애플리케이션에서 RDS 인스턴스에 쉽게 연결 가능 / 데이터베이스에 대한 연결 / 서버리스에 유용 / 관리를 오프로드하여 성능과 안정성 개선
355
오래된 애플리케이션 AWS로 마이그레이션 + 매 시간 배치 작업을 실행 + CPU 많이 사용 + 64개의 가상 CPU(vCPU)와 512GiB의 메모리 + 배치 작업 평균 15분
→ 가장 적은 운영 오버헤드로 15분 이내 배치 작업 실행
D. Amazon EC2에서 AWS Batch를 사용합니다.
* AWS Batch: 15분 이내에 배치 작업 / 대규모 배치 처리 작업 / 다양한 인스턴스 유형과 시작 모드를 사용할 수 있는 옵션과 함께 배치 작업에 필요한 인프라를 자동으로 프로비저닝 하는 완전 관리형 서비스
356
S3 스토리지에 데이터 객체 저장 → 30일 이후에 데이터의 75%가 거의 액세스되지 않음
→ 모든 데이터를 고가용성과 복원력으로 즉시 액세스할 수 있어야함 + 스토리지 비용 최적화
B. 30일 후에 데이터 객체를 S3 Standard-Infrequent Access(S3 Standard-IA)로 이동합니다.
* S3 Standard-IA: 높은 가용성과 복원력으로 데이터에 즉시 액세스할 수 있도록 유지 + 스토리지 비용 최소화
* S3 One Zone-IA => 단일 AZ 사용
357
데이터 센터에서 AWS 클라우드로 공개 스코어보드를 옮김 → 동적 애플리케이션 호스팅을 위해 Windows Server 인스턴스 사용 → 정적 파일과 동적 서버 측 코드로 구성 → 고가용성 스토리지 솔루션 필요
A. 정적 파일을 Amazon S3에 저장합니다. Amazon CloudFront를 사용하여 에지에서 객체를 캐시합니다.
D. Amazon FSx for Windows File Server에 서버 측 코드를 저장합니다. 각 EC2 인스턴스에 FSx for Windows File Server 볼륨을 마운트하여 파일을 공유합니다.
EFS : Windows X
CloudFront: Edge에서 캐시 가능 ↔ ElastiCache: Edge에서 캐시 불가능
Windows Server 인스턴스 ⇒ FSx for Windows File Server
358
ALB는 CloudFront 배포의 원점 + S3 버킷에 저장된 10억 개의 이상의 이미지를 가지고 있으며 매초 수천 개의 이미지 처리 → 이미지 크기를 동적으로 조정하고 적절한 형식을 클라이언트에 제공 + 최소한의 운영 오버헤드
C. 외부 이미지 관리 라이브러리와 함께 Lambda@Edge 함수를 사용합니다. Lambda@Edge 함수를 이미지를 제공하는 CloudFront 동작과 연결합니다.
→ 외부 이미지 관리 라이브러리 사용하여 이미지 크기를 조정하고 적절한 형식 제공 가능
* Lambda@Edge: CloudFront 네트워크의 에지에서 실행되는 서버리스 함수
359
S3 버킷에 환자 기록 저장 → 모든 보호된 건강 정보 (PHI)가 전송 중 및 저장 중에 암호화되도록 → 그 팀이 저장 중인 데이터에 대한 암호화 키 관리
C. S3 버킷 정책에서 aws:SecureTransport 조건을 사용하여 HTTPS(TLS)를 통한 암호화된 연결만 허용합니다. 각 S3 버킷에 대한 기본 암호화를 구성하여 AWS KMS 키(SSE-KMS)로 서버 측 암호화를 사용합니다. 규정 준수 팀을 할당하여 KMS 키를 관리합니다.
=> aws:SecureTransport : 요청이 HTTPS (TLS)(전송 계층 보안)을 통해 보호된 경우에만 조건을 만족하는 것 + S3 버킷에 대한 기본 암호화를 구성하여 AWS KMS 키(SSE-KMS)로 서버 측 암호화를 사용 + KMS 키는 별도로 관리할 수 있어 컴플라이언스 요구 사항을 충족하는데 적합
360
API Gateway를 사용하여 동일한 VPC에서 두 개의 REST API가 있는 프라이빗 게이트웨이 실행 → 웹 서비스가 VPC를 통하지 않고 인터넷을 통해 웹 서비스를 호출 → API가 VPC를 통해 통신할 수 있는 솔루션 구현 + 코드를 가장 적게 변경
B. 인터페이스 엔드포인트 Interface Endpoint(private link) 를 사용합니다.
* Gateway Endpoint: VPC 내에서 S3 및 DynamoDB에만 적용.
* Interface Endpoint(AWS PrivateLink): vpc 내부에서 프라이빗 ip를 통해 연결
361
멀티플레이어 게임 애플리케이션 호스팅
→ 밀리초 미만의 지연 시간으로 데이터를 읽고 과거 데이터에 대한 일회성 쿼리를 실행 + 가장 적은 운영 오버헤드
C. 자주 액세스하는 데이터의 경우 Amazon DynamoDB를 DynamoDB Accelerator(DAX)와 함께 사용합니다. DynamoDB 테이블 내보내기를 사용하여 데이터를 Amazon S3 버킷으로 내보냅니다. Amazon Athena를 사용하여 Amazon S3의 데이터에 대한 일회성 쿼리를 실행합니다.
DynamoDB + DAX => 낮은 지연 시간
DynamoDB에서 S3로 내보내기를 사용하면 Athena, Glue와 같은 다른 리소스를 사용하여 데이터에 대한 분석 및 복잡한 쿼리 수행 가능
* DynamoDB: NoSQL 서비스로, 밀리초 단위의 지연 시간을 보장. 쿼리 성능 최적화, 실시간 애플리케이션에 적합.
* Amazon Athena: S3에 저장된 데이터를 SQL로 분석할 수 있는 서버리스 쿼리 서비스. 일회성 쿼리에 적합.
362
특정 결제 ID에 대한 메시지를 보낸 순서대로 수신해야 하는 결제 처리 시스템을 사용
B. 결제 ID를 파티션 키로 사용하여 Amazon Kinesis 데이터 스트림에 메시지를 작성합니다.
E. Amazon Simple Queue Service(Amazon SQS) FIFO 대기열에 메시지를 씁니다. 메시지 그룹을 설정하여 결제 ID를 사용합니다.
* Kinesis Data Stream: 실시간으로 읽고 쓸 수 있는 정렬된 순서의 데이터 레코드
* SQS FIFO: 순서 보장
363
이벤트를 동시에 보내야하는 게임 시스템 / 이벤트 순서를 보장하는 AWS 이벤트 기반 시스템
B. Amazon Simple Notification Service(Amazon SNS) FIFO 주제
* SNS: 애플리케이션이 토픽을 통해 여러 구독자에게 메시지를 보낼 수 있는 고가용성 및 내구성이 뛰어난 게시-구독 메시징 서비스 -> 여러 대상에게 동시에 보낼 수 있음
* SNS FIFO: 메시지가 전송된 순서대로 전달되도록 설계 -> 각 대기열 이벤트를 개별적으로 전송
364
병원은 SQS와 SNS를 사용하기로 결정 → 데이터는 저장 시와 전송 시 암호화 + 승인된 병원 직원만 데이터에 액세스할 수 있어야함
B. AWS Key Management Service(AWS KMS) 고객 관리 키를 사용하여 SNS 구성 요소에서 서버 측 암호화를 켭니다. 키 사용을 승인된 주체 집합으로 제한하기 위해 키 정책을 적용합니다.
D. AWS Key Management Service(AWS KMS) 고객 관리 키를 사용하여 SQS 구성 요소에서 서버 측 암호화를 켭니다. 키 정책을 적용하여 키 사용을 승인된 주체 집합으로 제한합니다. TLS를 통한 암호화된 연결만 허용하도록 대기열 정책에 조건을 설정합니다.
* IAM 정책: 사용자 또는 역할에 적용되므로 ID 기반 정책에서 주체 지정 불가능
* SNS/SQS 구성 요소에서 서버 측 암호화: KMS 고객 관리 키를 사용하여 SNS/SQS에서 서버 측 암호화를 설정하면 데이터 저장 시 암호화 가능
* TLS: TLS를 통한 암호화된 연결만 허용하면 데이터 전송시에도 암호화 보장
* KMS: 항상 키 정책이 필요. 키 정책을 통해 액세스 제어가 이루어짐.
365
RDS에서 지원하는 웹 애플리케이션 + 실수로 테이블 정보를 편집하여 데이터 손실 초래 → 지난 30일 동안 변경 사항이 발생하기 5분 전의 상태로 복원할 수 있는 기능
C. 자동 백업
RDS: 자동 백업을 제공하며, 데이터베이스 인스턴스의 정기적인 스냅샷을 찍도록 구성 + 보관 기간 내에서 특정 시점 복구를 허용하여 지난 기간 내의 모든 지점, 변경 5분 전을 포함하여 원래 상태로 복원할 수 있다
366
AWS Lambda 함수 앞에 있는 Amazon API Gateway API와 Amazon DynamoDB 데이터베이스로 구성 / 애플리케이션은 Cognito 사용자 풀을 사용하여 개별 사용자 식별 + 구독이 있는 사용자만 프리미엄 콘텐츠에 액세스할 수 있도록 업데이트 + 최소한의 운영 오버헤드
D. 구독하지 않은 사용자의 접근을 제한하기 위해 API 사용 계획과 API 키를 구현합니다.
* API 사용 계획: 배포된 하나 이상의 API 단계 및 메서드에 액세스할 수 있는 사용자를 지정하고 선택적으로 요청 제한을 시작, 계획은 * API 키를 사용하여 API 클라이언트와 각 키에 대해 연결된 API 단계에 액세스할 수 있는 사용자 식별 => 운영 오버헤드 적음
367
UDP 기반 애플리케이션 라우팅하기 위해 Route 53 지연 기반 라우팅 사용 + 애플리케이션은 온프레미스에서 호스팅 → 성능과 가용성을 개선
A. 온프레미스 엔드포인트를 처리하기 위해 3개의 AWS 리전에 3개의 네트워크 로드 밸런서(NLB)를 구성합니다. AWS Global Accelerator를 사용하여 가속기를 만들고 NLB를 엔드포인트로 등록합니다. 가속기 DNS를 가리키는 CNAME을 사용하여 애플리케이션에 대한 액세스를 제공합니다.
→ Network Load Balancer, Global Accerelator: UDP 트래픽 허용
→ ALB, CloudFront는 UDP 지원 X
368
모든 신규 사용자에게 IAM 사용자 비밀번호에 대한 특정 복잡성 요구사항과 필수 로테이션 기간을 요구
A. AWS 계정 전체에 대한 전반적인 암호 정책을 설정합니다.
AWS 전반적인 암호 정책: AWS내의 모든 IAM 사용자에게 적용. 비밀번호, 로테이션 등을 한 번에 관리 가능
369
인스턴스 중 하나가 일정에 따라 여러 1시간 작업을 실행 → 단일 인스턴스에서 실행되는 동안 성능과 확장성에 대해 우려 + 최소한의 운영 오버헤드
A. AWS Batch를 사용하여 작업을 작업으로 실행합니다. Amazon EventBridge(Amazon CloudWatch Events)를 사용하여 작업을 예약합니다.
‘일정에 따라’ => EventBridge
1시간 작업 => Lambda X -> Batch
370
프라이빗 서브넷에서 실행되는 EC2 인스턴스는 인터넷을 통해 서버와 통신해야함 + 운영 유지 관리를 최소화하는 관리형 솔루션
C. 퍼블릭 서브넷에 NAT 게이트웨이를 프로비저닝합니다. NAT 게이트웨이를 가리키는 기본 경로로 각 프라이빗 서브넷의 경로 테이블을 수정합니다.
* NAT Gateway: 관리자 오버헤드 없이 자동 확장, 고가용성 및 완전 관리형 서비스 제공
* NAT Instance는 더 많은 직접 관리가 필요하므로 운영 오버헤드 증가
'클라우드 > AWS' 카테고리의 다른 글
| [Associate SAA-C03] - dump 정리 401 ~ 440 (0) | 2024.10.07 |
|---|---|
| [Associate SAA-C03] - dump 정리 371 ~ 400 (0) | 2024.10.06 |
| [Associate SAA-C03] - dump 정리 321 ~ 350 (0) | 2024.10.04 |
| [Associate SAA-C03] - dump 정리 301 ~ 320 (0) | 2024.10.02 |
| [Associate SAA-C03] - dump 정리 281 ~ 300 (0) | 2024.10.01 |