[AWS - SAA] 개념정리 및 문제풀이 16일차

개념정리

AWS DMS(AWS Database Migration Service)

개념: AWS에서 제공하는 데이터베이스 마이그레이션 서비스로, 온프레미스 또는 다른 클라우드에 있는 데이터베이스를 AWS 클라우드로 안전하게 마이그레이션하는 데 사용됩니다. 또한, AWS DMS는 AWS 내의 데이터베이스 간 데이터 마이그레이션도 지원합니다. 이 서비스는 비용 효율적이며, 데이터베이스의 다운타임을 최소화할 수 있는 방식으로 설계되었습니다.

 

주요 특징

• 지원되는 소스 및 대상: AWS DMS는 다양한 데이터베이스 소스와 대상 간의 마이그레이션을 지원합니다. MySQL, PostgreSQL, Oracle, Microsoft SQL Server, MariaDB, Amazon Aurora, MongoDB 등의 관계형 및 NoSQL 데이터베이스를 포함하여, 데이터 웨어하우스(예: Amazon Redshift)까지 마이그레이션할 수 있습니다.
• 연속적인 데이터 복제: AWS DMS는 데이터베이스의 변경 사항을 실시간으로 캡처하고 대상 데이터베이스에 적용하여 지속적인 복제를 수행할 수 있습니다. 이를 통해 데이터베이스가 운영 중일 때도 마이그레이션이 가능해 다운타임을 최소화할 수 있습니다.
• 자동화 및 관리형 서비스: AWS DMS는 완전 관리형 서비스로, 인프라를 프로비저닝하고 유지보수할 필요가 없습니다. AWS DMS는 데이터 복사 및 동기화, 오류 감지 및 자동 복구 기능을 제공합니다.
• 비용 효율성: AWS DMS는 실제로 마이그레이션 작업을 수행한 시간에 대해서만 비용이 발생하며, 온디맨드로 사용 가능하여 효율적입니다.
• 이질적 및 동질적 데이터베이스 마이그레이션: AWS DMS는 동일한 종류의 데이터베이스 간의 마이그레이션뿐만 아니라, 서로 다른 데이터베이스 엔진 간의 마이그레이션도 지원합니다. 이를 위해 AWS Schema Conversion Tool(SCT)을 함께 사용할 수 있습니다.

주요 사용 사례

• 데이터베이스 마이그레이션: 온프레미스의 데이터베이스를 클라우드로 이동하거나 AWS 내의 데이터베이스 엔진 간에 이동할 때 사용됩니다.
• 데이터베이스 복제: 운영 환경과 분석 환경을 분리하기 위해 실시간 데이터베이스 복제를 수행할 수 있습니다.
• 데이터베이스 통합: 다양한 소스의 데이터를 통합하여 중앙 데이터베이스로 전송할 때 사용됩니다.

 

작동 방식

1. 소스 및 대상 데이터베이스 연결: 사용자가 소스 데이터베이스와 대상 데이터베이스의 연결을 설정합니다.
2. 복제 작업 구성: 전체 데이터베이스 마이그레이션, 증분 데이터 복제 등 원하는 작업을 구성할 수 있습니다.
3. 복제 작업 실행: DMS는 복제 작업을 시작하고, 실시간으로 데이터 변화를 캡처하여 대상 데이터베이스로 복제합니다.
4. 마이그레이션 완료 및 검증: 초기 데이터 전송이 완료된 후, 지속적인 동기화 작업을 통해 소스 데이터와 대상 데이터가 동기화되도록 유지합니다.

장점

• 자동화된 모니터링 및 복구: DMS는 마이그레이션 중에 발생하는 오류를 자동으로 감지하고 복구합니다.
• 간편한 설정: 복잡한 설정 없이 콘솔에서 몇 번의 클릭만으로 마이그레이션 작업을 시작할 수 있습니다.
• 높은 호환성: 다양한 데이터베이스 소스 및 대상 지원으로 유연한 마이그레이션이 가능합니다.

 

AWS Storage Gateway

개념 : 온프레미스 환경과 AWS 클라우드 간의 원활한 데이터 통합을 지원하는 하이브리드 클라우드 스토리지 서비스입니다. 이 서비스는 온프레미스 애플리케이션에서 AWS 클라우드를 스토리지 백엔드로 사용할 수 있도록 다양한 게이트웨이 모드를 제공합니다. 이를 통해 기업은 기존의 온프레미스 인프라를 활용하면서 AWS의 확장성과 경제성을 누릴 수 있습니다.

 

주요 기능 및 특징

• 파일 게이트웨이 (File Gateway):
  • 기능: 파일 게이트웨이는 온프레미스 애플리케이션에서 AWS S3를 파일 기반의 NFS(Network File System) 또는 SMB(Server Message Block) 프로토콜을 통해 사용할 수 있게 합니다.
  • 용도: 이 모드는 파일 데이터를 S3 버킷에 저장하고, 자주 사용하는 파일을 로컬 캐시로 유지합니다. 주로 백업, 파일 공유, 데이터 아카이브, 데이터 분석 워크로드에 활용됩니다.
• 볼륨 게이트웨이 (Volume Gateway):
  • 기능: 볼륨 게이트웨이는 iSCSI 프로토콜을 사용하여 온프레미스 애플리케이션이 AWS 클라우드에 저장된 블록 스토리지에 액세스할 수 있도록 지원합니다. 두 가지 모드가 있습니다:
  • 캐시 볼륨 모드: 자주 사용하는 데이터를 로컬에 캐싱하고, 나머지 데이터를 AWS에 저장하여 온프레미스의 저장 공간을 절약합니다.
  • 저장 볼륨 모드: 모든 데이터를 온프레미스에 유지하고, AWS 클라우드에 백업하여 이중화 및 데이터 보호를 제공합니다.
  • 용도: 주로 온프레미스의 중요한 데이터를 백업하고, 클라우드로의 스토리지 확장 및 재해 복구 시나리오에서 사용됩니다.
• 테이프 게이트웨이 (Tape Gateway):
  • 기능: 테이프 게이트웨이는 기존의 물리적 테이프 백업 시스템을 가상화하여 클라우드로 이전하는 데 사용됩니다. 이를 통해 온프레미스 백업 소프트웨어가 가상 테이프 라이브러리를 사용하여 Amazon S3 및 Amazon Glacier에 데이터를 백업할 수 있습니다.
  • 용도: 주로 기존의 테이프 백업 시스템을 클라우드로 전환하여 데이터 보관 비용을 절감하고, 데이터 아카이빙 및 장기 보관 요구사항을 충족할 때 사용됩니다.

주요 사용 사례

• 온프레미스 데이터 백업 및 아카이빙:
  • AWS Storage Gateway를 통해 온프레미스의 데이터 백업을 AWS 클라우드로 확장할 수 있습니다. 파일 게이트웨이와 볼륨 게이트웨이를 사용하여 데이터를 S3 또는 EBS에 백업하고, 테이프 게이트웨이를 통해 장기 보관용으로 Glacier에 안전하게 저장할 수 있습니다.
• 하이브리드 클라우드 스토리지 확장:
  • 온프레미스의 제한된 스토리지 용량을 확장하기 위해 AWS Storage Gateway를 사용할 수 있습니다. 이를 통해 자주 액세스하지 않는 데이터를 클라우드에 저장하면서 로컬 스토리지의 사용량을 줄일 수 있습니다.
• 클라우드 기반 데이터 분석 및 머신 러닝:
  • AWS Storage Gateway를 사용하여 파일을 Amazon S3에 업로드하고, 이를 기반으로 AWS의 데이터 분석 및 머신 러닝 서비스와 통합하여 다양한 인사이트를 도출할 수 있습니다.

AWS Storage Gateway의 장점

 

• 유연성: 다양한 스토리지 요구 사항에 맞춰 파일, 블록, 테이프 게이트웨이 모드를 선택하여 사용할 수 있습니다.
• 비용 효율성: 클라우드 스토리지를 백엔드로 사용하여 온프레미스 스토리지 비용을 절감할 수 있습니다.
• 보안: 데이터를 전송 및 저장할 때 AWS의 보안 기능을 통해 암호화와 액세스 제어를 제공합니다.
• 확장성: 온프레미스의 스토리지 용량 제한 없이 AWS 클라우드 스토리지의 무한한 확장성을 활용할 수 있습니다.
• 간편한 관리: AWS 관리 콘솔을 통해 게이트웨이를 설정하고 관리할 수 있으며, 모니터링 및 로그 기능을 통해 상태를 확인할 수 있습니다.

Amazon Route 53

개념 :  AWS에서 제공하는 완전 관리형 DNS(도메인 네임 시스템) 웹 서비스입니다. Route 53은 도메인 이름을 IP 주소로 변환하거나, 다양한 라우팅 정책을 통해 애플리케이션 트래픽을 효율적으로 관리하는 기능을 제공합니다. 이름의 ‘53’은 DNS에서 사용하는 기본 포트 번호인 53번 포트를 의미합니다.

 

주요 기능

 

• DNS 관리 및 도메인 등록:
  • Route 53은 도메인을 AWS에서 직접 등록하고 관리할 수 있는 기능을 제공합니다. 도메인을 등록한 후, 호스팅 영역(Hosted Zone)을 생성하여 도메인에 대한 DNS 레코드를 관리할 수 있습니다.
  • A 레코드, AAAA 레코드, CNAME 레코드, MX 레코드 등 다양한 유형의 DNS 레코드를 지원하여 도메인의 트래픽을 효율적으로 관리할 수 있습니다.
• 라우팅 정책: Route 53은 여러 라우팅 정책을 제공하여, 애플리케이션의 요구에 맞게 트래픽을 분산하거나 제어할 수 있습니다.
  • 단순 라우팅(Simple Routing): 기본적인 라우팅 정책으로, 하나의 IP 주소 또는 레코드를 반환합니다.
  • 가중치 기반 라우팅(Weighted Routing): 여러 리소스에 가중치를 부여하여 특정 비율로 트래픽을 분산할 수 있습니다.
  • 지연 시간 기반 라우팅(Latency-Based Routing): 사용자의 위치와 AWS 리전의 지연 시간을 기준으로, 가장 낮은 지연 시간을 제공하는 리소스로 트래픽을 라우팅합니다.
  • 지리 위치 기반 라우팅(Geolocation Routing): 사용자의 위치를 기반으로 특정 리소스로 트래픽을 분산합니다. 예를 들어, 특정 국가에서 오는 요청을 특정 서버로 라우팅할 수 있습니다.
  • 장애 조치 라우팅(Failover Routing): 주(primary) 리소스와 보조(secondary) 리소스를 설정하여, 주 리소스가 비정상 상태일 때 자동으로 보조 리소스로 트래픽을 전환합니다.
  • 다중값 응답 라우팅(Multi-Value Answer Routing): 여러 리소스의 상태를 확인하고, 정상 상태의 리소스 IP 주소를 여러 개 반환하여 클라이언트가 선택할 수 있게 합니다.
• 헬스 체크(Health Check):
  • Route 53은 헬스 체크 기능을 제공하여, 설정된 리소스의 상태를 지속적으로 모니터링할 수 있습니다. 헬스 체크는 HTTP, HTTPS, TCP 등의 프로토콜을 사용하여 리소스의 정상 여부를 판단합니다.
  • 헬스 체크를 통해 비정상 리소스를 감지하면, 자동으로 트래픽을 정상 리소스로 라우팅하여 애플리케이션의 가용성을 높일 수 있습니다.
• 가용성 및 확장성:
  • Route 53은 전 세계에 분산된 AWS의 엣지 로케이션(Edge Location)을 통해 높은 가용성과 성능을 제공합니다. 이를 통해 사용자의 위치와 가까운 DNS 서버를 사용하여 도메인 이름을 빠르게 해석할 수 있습니다.

주요 사용 사례

 

• 웹 애플리케이션의 트래픽 관리:
  • Route 53을 통해 웹 애플리케이션의 트래픽을 여러 리소스에 분산하거나, 장애가 발생했을 때 다른 리소스로 트래픽을 전환하여 애플리케이션의 고가용성을 보장할 수 있습니다.
• 지리적 라우팅 및 지연 시간 최적화:
  • 사용자 위치에 따라 특정 리소스로 트래픽을 라우팅하거나, 지연 시간을 기반으로 가장 빠른 리소스로 트래픽을 전달하여 사용자 경험을 개선할 수 있습니다.
• 하이브리드 클라우드 환경에서의 트래픽 관리:
  • 온프레미스와 AWS 클라우드 리소스 간의 트래픽을 관리하고, 특정 조건에 따라 적절한 리소스로 트래픽을 분산하는 데 Route 53을 사용할 수 있습니다.

 

AWS Transfer Family

개념 :  기존의 SFTP(Secure File Transfer Protocol), FTPS(File Transfer Protocol Secure), FTP(File Transfer Protocol)를 AWS 서비스와 통합하여 사용할 수 있도록 지원하는 관리형 서비스입니다. 이를 통해 기존 파일 전송 워크플로우를 변경하지 않고도 안전하고 확장성 있는 클라우드 인프라로 마이그레이션할 수 있습니다.

 

주요 기능

• 지원되는 프로토콜:
  • SFTP (Secure File Transfer Protocol): 파일을 암호화된 연결로 전송하는 프로토콜.
  • FTPS (File Transfer Protocol Secure): FTP를 SSL/TLS 보안 계층과 결합하여 안전하게 전송하는 프로토콜.
  • FTP (File Transfer Protocol): 보안이 필요 없는 간단한 파일 전송에 사용되는 프로토콜.
• AWS 서비스와의 통합:
  • AWS Transfer Family는 Amazon S3와 Amazon EFS와 통합됩니다. 이를 통해 전송된 파일을 S3 버킷이나 EFS 파일 시스템에 안전하게 저장할 수 있습니다.
  • AWS IAM, AWS CloudWatch, AWS CloudTrail과도 통합되어, 액세스 제어 및 모니터링, 로깅 기능을 제공합니다.
• 사용자 관리:
  • AWS Transfer Family는 사용자별로 개별적인 홈 디렉터리 및 권한을 설정할 수 있습니다. 이를 통해 각 사용자가 자신의 디렉터리와 데이터에만 접근할 수 있도록 제어할 수 있습니다.
  • 사용자 인증은 IAM, LDAP, 또는 API를 통해 관리할 수 있습니다.
• 보안 및 규정 준수:
  • AWS Transfer Family는 데이터 전송 중 및 저장 중 암호화를 지원합니다. 전송 중에는 SSL/TLS를 사용하고, 저장 중에는 S3의 서버 측 암호화(SSE)를 활용할 수 있습니다.
  • 또한, Transfer Family는 AWS의 다양한 보안 인증 및 규정 준수 요건을 충족합니다.
• 자동 확장:
  • Transfer Family는 AWS의 관리형 서비스이므로, 별도의 인프라를 관리할 필요가 없으며, 자동으로 확장됩니다. 트래픽 양에 따라 유연하게 대응할 수 있습니다.

주요 사용 사례

 

• 기존 파일 전송 워크플로우의 AWS 통합:
  • 기존에 SFTP, FTPS, FTP 서버를 사용하여 온프레미스에서 파일 전송을 수행하던 워크플로우를 변경 없이 AWS로 이전할 수 있습니다. 이를 통해 기존 시스템과의 호환성을 유지하면서 클라우드의 이점을 누릴 수 있습니다.
• 데이터 레이크 및 데이터 분석 워크플로우:
  • 데이터를 AWS Transfer Family를 통해 S3에 업로드하여, 데이터 레이크를 구성하고, 이후 데이터 분석 워크플로우에서 데이터를 활용할 수 있습니다. 데이터를 S3에 저장하면 다양한 AWS 서비스(Redshift, Athena, EMR 등)와 통합하여 분석할 수 있습니다.
• 파트너 및 클라이언트와의 안전한 데이터 공유:
  • 외부 파트너 또는 고객과 안전하게 파일을 주고받아야 할 때, SFTP/FTPS/FTP 프로토콜을 사용하여 AWS 클라우드에서 직접 파일 전송 서비스를 제공할 수 있습니다. AWS Transfer Family는 액세스 로그와 CloudTrail을 통해 모든 전송을 추적할 수 있습니다.
• 기존 백업 워크플로우의 클라우드 이전:
  • 온프레미스에서 FTP 기반으로 수행되던 데이터 백업을 Transfer Family를 사용하여 AWS S3 또는 EFS로 안전하게 이전할 수 있습니다. 이를 통해 백업 데이터를 안정적으로 보관하고 관리할 수 있습니다.

장점

• 관리형 서비스: Transfer Family는 서버 인프라를 직접 설정하거나 관리하지 않아도 되므로 운영 부담을 줄입니다.
• 보안 강화: 파일 전송 중 SSL/TLS 암호화를 지원하며, AWS IAM과의 통합으로 세밀한 권한 관리를 제공합니다.
• 유연성 및 확장성: SFTP, FTPS, FTP와의 호환성을 제공하며, 전송 양에 따라 자동으로 확장됩니다.
• 비용 효율성: 사용한 만큼만 비용을 지불하는 구조로, 서버를 직접 관리하는 것보다 비용 효율적입니다.

 

요약

 

용어정리

• AWS DMS는 데이터베이스 마이그레이션을 안전하고 효율적으로 수행할 수 있는 도구로, 기존 데이터베이스의 서비스 중단을 최소화하면서 클라우드로의 이전을 지원합니다.
• AWS Storage Gateway는 온프레미스 인프라와 AWS 클라우드를 원활하게 연결해주는 다목적 스토리지 솔루션입니다. 파일, 블록, 테이프 기반의 다양한 게이트웨이 옵션을 제공하며, 이를 통해 클라우드 백업, 스토리지 확장, 데이터 아카이빙, 재해 복구 시나리오 등을 구현할 수 있습니다. AWS Storage Gateway는 클라우드와 온프레미스를 연결하는 다리 역할을 하며, 기존 인프라를 그대로 활용하면서 AWS 클라우드의 이점을 누릴 수 있도록 도와줍니다.
• Amazon Route 53은 도메인 이름 관리, 트래픽 라우팅, 헬스 체크, 도메인 등록 등 다양한 기능을 제공하는 AWS의 DNS 서비스입니다. Route 53은 여러 라우팅 정책을 지원하여, 지리적 위치나 지연 시간, 리소스 상태에 따라 트래픽을 유연하게 분산할 수 있습니다. 이를 통해 고가용성 및 내결함성을 유지하며, 사용자의 요구에 맞게 트래픽을 효율적으로 제어할 수 있습니다.
• AWS Transfer Family는 기존의 파일 전송 프로토콜(SFTP, FTPS, FTP)을 AWS의 스토리지 서비스(Amazon S3 및 EFS)와 통합할 수 있는 관리형 서비스입니다. 이를 통해 기존 워크플로우를 유지하면서도 AWS의 확장성과 보안성을 활용할 수 있습니다. Transfer Family는 서버 인프라의 관리 부담을 줄이고, 사용자별 권한 관리, 데이터 암호화, 로깅 및 모니터링을 포함한 다양한 기능을 제공하여, 클라우드 기반의 파일 전송을 효율적으로 지원합니다.

문제풀이

문제 1. : 회사에 여러 Amazon EC2 인스턴스에서 실행되는 애플리케이션이 있습니다. 각 EC2 인스턴스에는 여러 Amazon Elastic Block Store(Amazon EBS) 데이터 볼륨이 연결되어 있습니다. 애플리케이션의 EC2 인스턴스 구성 및 데이터를 야간에 백업해야 합니다. 다른 AWS 리전에서 애플리케이션도 복구 가능해야 합니다. 운영상 가장 효율적인 방식으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

A. 애플리케이션 EBS 볼륨의 야간 스냅샷을 예약하고 스냅샷을 다른 리전에 복사하는 AWS Lambda 함수를 작성

• AWS Lambda를 사용하여 EBS 스냅샷을 생성하고 다른 리전에 복사하는 방법은 자동화된 백업 솔루션을 제공할 수 있습니다. 하지만 이 방법은 EC2 인스턴스 자체의 복구는 다루지 않습니다.

B. 야간 백업을 수행하기 위해 AWS Backup을 사용하여 백업 계획 생성. 백업을 다른 리전에 복사. 애플리케이션의 EC2 인스턴스를 리소스로 추가.

• AWS Backup을 사용하여 백업 계획을 생성하고, 백업을 다른 리전에 복사한 후 EC2 인스턴스를 리소스로 추가하는 방법입니다. 이 방법은 EBS 볼륨과 EC2 인스턴스 모두를 포함하는 종합적인 백업 솔루션을 제공합니다.

C. 야간 백업을 수행하기 위해 AWS Backup을 사용하여 백업 계획 생성. 백업을 다른 리전에 복사. 애플리케이션의 EBS 볼륨을 리소스로 추가.

• AWS Backup을 사용하여 백업 계획을 생성하고, 백업을 다른 리전에 복사한 후 EBS 볼륨을 리소스로 추가하는 방법입니다. 이 방법은 EBS 볼륨만을 다루며 EC2 인스턴스 자체는 포함하지 않습니다.

D. 애플리케이션 EBS 볼륨의 야간 스냅샷을 예약하고 스냅샷을 다른 가용 영역에 복사하는 AWS Lambda 함수를 작성.

• AWS Lambda를 사용하여 EBS 스냅샷을 생성하고 다른 가용 영역에 복사하는 방법입니다. 하지만 이 방법은 다른 리전으로의 복구를 다루지 않아 요구사항을 완전히 충족하지 못합니다.

문제 2 : 한 회사에 단일 AWS 리전에서 실행되는 리전 구독 기반 스트리밍 서비스가 있습니다. 아키텍처는 Amazon EC2 인스턴스의 웹 서버와 애플리케이션 서버로 구성됩니다. EC2 인스턴스는 Elastic Load Balancer 뒤의 Auto Scaling 그룹에 있습니다. 아키텍처에는 여러 가용 영역에 걸쳐 확장되는 Amazon Aurora 데이터베이스 클러스터가 포함됩니다. 이 회사는 전 세계적으로 확장하고 응용 프로그램의 가동 중지 시간을 최소화하기를 원합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까? 

 

A. 웹 계층 및 애플리케이션 계층에 대한 Auto Scaling 그룹을 확장하여 두 번째 리전의 가용 영역에 인스턴스를 배포. Aurora 글로벌 데이터베이스를 사용하여 기본 리전과 두 번째 리전에 데이터베이스를 배포. 두 번째 리전에 대한 장애 조치 라우팅 정책과 함께 Amazon Route 53 상태 확인을 사용. 

• Auto Scaling을 두 리전에 확장하고 Aurora 글로벌 데이터베이스를 사용하는 접근법입니다. 하지만 Aurora 글로벌 데이터베이스는 문제에서 언급되지 않았습니다.

B. 웹 계층과 애플리케이션 계층을 두 번째 리전에 배포. 두 번째 리전에 Aurora PostgreSQL 교차 리전 Aurora 복제본을 추가. 두 번째 리전에 대한 장애 조치 라우팅 정책과 함께 Amazon Route 53 상태 확인을 사용하고 필요에 따라 보조를 기본으로 승격.

• 두 리전에 웹/앱 계층을 배포하고 Aurora PostgreSQL 교차 리전 복제본을 사용합니다. 그러나 이는 Aurora 글로벌 데이터베이스의 기능이 아니며, 복잡성을 증가시킬 수 있습니다.

C. 웹 계층과 애플리케이션 계층을 두 번째 리전에 배포. 두 번째 리전에서 Aurora PostgreSQL 데이터베이스를 생성. AWS Database Migration Service(AWS DMS)를 사용하여 기본 데이터베이스를 두 번째 리전에 복제. 두 번째 리전에 대한 장애 조치 라우팅 정책과 함께 Amazon Route 53 상태 확인을 사용.

• 두 리전에 웹/앱 계층을 배포하고 AWS DMS를 사용하여 데이터베이스를 복제합니다. 하지만 이 방법은 실시간 복제와 빠른 장애 조치를 제공하지 않습니다.

D. 웹 계층과 애플리케이션 계층을 두 번째 리전에 배포. Amazon Aurora 글로벌 데이터베이스를 사용하여 기본 리전과 두 번째 리전에 데이터베이스를 배포. 두 번째 리전에 대한 장애 조치 라우팅 정책과 함께 Amazon Route 53 상태 확인을 사용. 필요에 따라 보조를 기본으로 승격.

•  두 리전에 웹/앱 계층을 배포하고 Aurora 글로벌 데이터베이스를 사용합니다. 이 방법은 다음과 같은 이점을 제공합니다:
  • 글로벌 확장 지원
  • 빠른 로컬 읽기와 글로벌 쓰기 기능
  • 1초 미만의 재해 복구 시간(RPO)
  • 간단한 설정 및 관리

문제 3 : 주로 온프레미스에서 애플리케이션 서버를 실행하는 회사가 AWS로 마이그레이션하기로 결정했습니다. 회사는 온프레미스에서 iSCSI(Internet Small Computer Systems Interface) 스토리지를 확장해야 할 필요성을 최소화하려고 합니다. 회사는 최근에 액세스한 데이터만 로컬에 저장하기를 원합니다. 회사는 이러한 요구 사항을 충족하기 위해 어떤 AWS 솔루션을 사용해야 합니까?

 

A. Amazon S3 파일 게이트웨이

• 파일 게이트웨이는 온프레미스 애플리케이션이 Amazon S3에 파일을 저장하고 액세스할 수 있게 해주는 솔루션입니다. 이는 파일 기반(NFS, SMB)으로 동작하며, iSCSI를 지원하지 않습니다. 따라서 현재 문제의 요구 사항과는 맞지 않습니다.

B. AWS Storage Gateway 테이프 게이트웨이

• 테이프 게이트웨이는 물리적 테이프 백업 인프라를 가상화하여 클라우드 기반의 테이프 솔루션으로 마이그레이션하는 데 사용됩니다. 이는 주로 백업 및 아카이브 용도로 사용되며, iSCSI 스토리지를 대체하는 데 적합하지 않습니다.

C. AWS Storage Gateway 볼륨 게이트웨이 저장 볼륨

• 저장 볼륨 모드는 iSCSI 인터페이스를 통해 온프레미스 애플리케이션에 AWS 스토리지를 연결해주는 솔루션입니다. 온프레미스에 모든 데이터를 로컬로 저장하며, 데이터가 AWS에 백업되므로 안전합니다. 하지만 문제에서 요구한 “최근에 접근한 데이터만 로컬에 저장” 조건에는 적합하지 않습니다.

D. AWS Storage Gateway 볼륨 게이트웨이 캐시 볼륨

• 캐시 볼륨 모드는 iSCSI 인터페이스를 통해 AWS의 스토리지와 온프레미스를 연결하며, 자주 액세스하는 데이터를 로컬에 캐싱하고 나머지 데이터를 AWS에 저장합니다. 즉, 최근에 접근한 데이터를 온프레미스에서 캐싱하여 빠르게 접근할 수 있으며, 나머지 데이터는 AWS에 안전하게 저장할 수 있습니다. 이는 문제에서 요구한 조건에 부합합니다.

문제 4 : 한 회사에서 Java Spring Boot 애플리케이션을 프라이빗 서브넷의 Amazon Elastic Kubernetes Service(Amazon EKS)에서 실행되는 포드로 배포했습니다. 애플리케이션은 Amazon DynamoDB 테이블에 데이터를 써야 합니다. 솔루션 설계자는 애플리케이션이 인터넷에 트래픽을 노출하지 않고 DynamoDB 테이블과 상호 작용할 수 있는지 확인해야 합니다. 이 목표를 달성하기 위해 솔루션 설계자는 어떤 단계 조합을 수행해야 합니까? (두 가지를 선택하세요.)

A. EKS 포드에 충분한 권한이 있는 IAM 역할을 연결:

• 포드에 IAM 역할을 연결하여 DynamoDB에 접근할 수 있는 권한을 부여할 수 있습니다. 이는 포드가 DynamoDB에 안전하게 접근할 수 있도록 해줍니다.
• EKS에서는 IAM 역할을 포드에 연결하는 기능인 IAM 역할(AWS IAM Role for Service Accounts)을 제공하여 포드 단위로 세밀하게 권한을 관리할 수 있습니다.

B. EKS 포드에 충분한 권한이 있는 IAM 사용자 연결:

• IAM 사용자 자격 증명을 직접 포드에 연결하는 것은 보안 모범 사례에 어긋납니다. 포드마다 IAM 사용자 자격 증명을 관리해야 하는 어려움이 있고, IAM 역할에 비해 관리 효율성이 떨어집니다. 일반적으로 사용하지 않는 방식입니다.

C. 프라이빗 서브넷의 네트워크 ACL을 통해 DynamoDB 테이블에 대한 아웃바운드 연결을 허용:

 

• NACL(Network ACL)은 서브넷 단위의 트래픽을 제어하지만, 이 문제에서는 인터넷 노출 없이 DynamoDB와의 통신을 보장해야 하므로 NACL을 설정하는 것만으로는 충분하지 않습니다.

 

D. DynamoDB용 VPC 엔드포인트를 생성:

• VPC 엔드포인트는 VPC 내부에서 AWS 서비스와의 연결을 인터넷을 거치지 않고 안전하게 구성할 수 있는 방법입니다. DynamoDB용 VPC 엔드포인트를 생성하면 프라이빗 서브넷에 있는 EKS 포드가 인터넷에 나가지 않고도 DynamoDB에 접근할 수 있습니다.

E. Java Spring Boot 코드에 액세스 키를 포함:

• 액세스 키를 코드에 포함하는 것은 보안상 매우 좋지 않은 방법입니다. 이는 키 유출의 위험이 있으며, 관리 효율성도 떨어집니다. 보안 모범 사례에 어긋나는 방식입니다.

 

문제 5 : 한 회사가 최근 단일 AWS 리전의 Amazon EC2 인스턴스에서 애플리케이션을 다시 호스팅하여 웹 애플리케이션을 AWS로 마이그레이션했습니다. 이 회사는 응용 프로그램 아키텍처를 고가용성 및 내결함성을 갖도록 재설계하려고 합니다. 트래픽은 실행 중인 모든 EC2 인스턴스에 무작위로 도달해야 합니다. 회사는 이러한 요구 사항을 충족하기 위해 어떤 조합의 단계를 수행해야 합니까? (두 가지를 선택하세요.)

 

A. Amazon Route 53 장애 조치 라우팅 정책을 생성:

• 장애 조치 라우팅(failover routing) 정책은 Route 53에서 제공하는 기능으로, 주(primary) 리소스가 비정상 상태일 때 보조(secondary) 리소스로 트래픽을 자동으로 전환합니다. 이 방법은 주로 두 개의 주요 리소스 그룹을 설정할 때 사용됩니다.
• 그러나 문제에서 요구하는 상황은 모든 EC2 인스턴스가 무작위로 장애를 겪을 수 있다는 것이며, 특정 주/보조 리소스가 구분되지 않았습니다. 따라서 장애 조치 라우팅 정책보다는 다중 인스턴스를 균등하게 관리할 수 있는 방법이 필요합니다.

B. Amazon Route 53 가중치 기반 라우팅 정책을 생성:

• 가중치 기반 라우팅(weighted routing) 정책은 여러 리소스에 가중치를 설정하여, 가중치에 따라 트래픽을 분배하는 방식입니다. 이 방법은 특정 인스턴스나 리소스에 더 많은 트래픽을 보내거나, 부하 분산을 위해 특정 비율로 트래픽을 분산할 때 사용됩니다.
• 그러나 문제의 조건에서는 특정 리소스에 가중치를 부여하는 것이 아닌, 모든 인스턴스가 무작위로 장애를 겪을 수 있다는 점을 고려해야 합니다. 가중치 기반 라우팅은 문제의 조건에 맞지 않는 선택입니다.

C. Amazon Route 53 다중값 응답 라우팅 정책을 생성:

• 다중값 응답 라우팅(Multi-Value Answer Routing) 정책은 여러 인스턴스의 상태를 확인하고, 정상 상태의 인스턴스들에 대해 IP 주소를 반환하는 방식입니다. 이를 통해 각 인스턴스의 상태를 지속적으로 모니터링하고, 정상 인스턴스로 트래픽을 분배할 수 있습니다.
• 이 방법은 인스턴스가 무작위로 장애를 겪는 상황에서 적절한 대응이 가능합니다. 여러 인스턴스가 있을 때, 특정 인스턴스가 장애를 겪더라도 나머지 정상 인스턴스로 트래픽을 보낼 수 있기 때문입니다.

D. 3개의 EC2 인스턴스를 시작: 하나의 가용 영역에 두 개의 인스턴스가 있고, 다른 가용 영역에 하나의 인스턴스가 있음:

• 이 선택지는 세 개의 인스턴스를 배포하지만, 하나의 가용 영역(AZ)에 두 개의 인스턴스를 배치하고, 다른 가용 영역에 하나의 인스턴스를 두는 전략입니다. 이는 특정 가용 영역에 장애가 발생했을 때, 두 개의 인스턴스가 동시에 영향을 받을 수 있어 내결함성에 취약한 구조입니다.
• 따라서 가용 영역 간에 균등하게 분산된 아키텍처가 아니므로, 고가용성 및 내결함성 측면에서 적합하지 않습니다.

E. 4개의 EC2 인스턴스를 시작: 하나의 가용 영역에 2개의 인스턴스가 있고, 다른 가용 영역에 2개의 인스턴스가 있음:

• 이 선택지는 인스턴스를 두 개의 가용 영역(AZ)에 균등하게 분산하여 배치하는 전략입니다. 한 가용 영역이 장애를 겪더라도 다른 가용 영역의 인스턴스가 서비스를 유지할 수 있기 때문에, 고가용성과 내결함성을 확보할 수 있는 적절한 접근 방법입니다.
• 인스턴스를 다중 가용 영역에 배치하여 내결함성과 가용성을 보장하는 것은 AWS 아키텍처 설계의 기본 원칙 중 하나입니다.

문제 6 : 데이터 분석 회사에서 일괄 처리 시스템을 AWS로 마이그레이션하려고 합니다. 회사는 FTP를 통해 하루 동안 주기적으로 수천 개의 작은 데이터 파일을 받습니다. 온프레미스 배치 작업은 밤새 데이터 파일을 처리합니다. 그러나 배치 작업 실행을 완료하는 데 몇 시간이 걸립니다. 회사는 파일을 전송하는 FTP 클라이언트에 대한 최소한의 변경으로 수신 데이터 파일을 처리할 수 있는 AWS 솔루션을 원합니다. 솔루션은 파일이 성공적으로 처리된 수신 데이터 파일을 삭제해야 합니다. 각 파일을 처리하는 데 3~8분이 소요됩니다. 운영상 가장 효율적인 방식으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

A. FTP 서버를 실행하는 Amazon EC2 인스턴스를 사용하여 수신 파일을 Amazon S3 Glacier Flexible Retrieval의 객체로 저장. AWS Batch에서 작업 대기열을 구성. Amazon EventBridge 규칙을 사용하여 S3 Glacier Flexible Retrieval에서 야간에 객체를 처리하는 작업을 호출. 작업이 개체를 처리한 후 개체를 삭제.

• S3 Glacier는 데이터 아카이빙 및 장기 보관에 적합하지만, 파일을 빈번하게 처리하는 경우에는 비용과 시간적인 측면에서 적합하지 않습니다. Glacier에서 데이터를 검색하는 데 시간이 걸리며, 온디맨드 작업에 대한 유연성이 떨어집니다.

B. FTP 서버를 실행하는 Amazon EC2 인스턴스를 사용하여 수신 파일을 Amazon Elastic Block Store(Amazon EBS) 볼륨에 저장. AWS Batch에서 작업 대기열을 구성. Amazon EventBridge 규칙을 사용하여 야간에 EBS 볼륨에서 파일 프로세스를 호출. 작업이 파일을 처리한 후 파일을 삭제.

• EBS 볼륨은 블록 스토리지로, EC2 인스턴스와 함께 사용되며, 성능이 높은 스토리지입니다. 하지만 수많은 파일을 EBS에 저장하고 처리하기 위해서는 EC2 인스턴스의 유지 관리와 스토리지 관리에 대한 추가적인 노력이 필요합니다. 또한, 비용적으로도 효율적이지 않을 수 있습니다.

C. AWS Transfer Family를 사용하여 Amazon Elastic Block Store(Amazon EBS) 볼륨에 수신 파일을 저장할 FTP 서버를 생성. AWS Batch에서 작업 대기열을 구성. 각 파일이 도착하면 Amazon S3 이벤트 알림을 사용하여 AWS Batch에서 작업을 호출. 작업이 파일을 처리한 후 파일을 삭제.

• AWS Transfer Family를 사용하면 기존 FTP 프로토콜을 쉽게 AWS와 통합할 수 있습니다. 하지만 EBS 볼륨을 사용하는 경우 EC2 인스턴스와의 연동이 필요하므로 서버 관리와 관련된 유지 관리가 필요합니다.

D. AWS Transfer Family를 사용하여 Amazon S3 Standard에 수신 파일을 저장할 FTP 서버를 생성. 파일이 처리된 후 파일을 삭제하는 AWS Lambda 함수를 생성. 파일이 도착하면 Lambda 함수를 호출하도록 S3 이벤트 알림을 설정.

• 이 선택지는 AWS Transfer Family를 통해 S3에 파일을 직접 저장하고, S3 이벤트를 통해 Lambda를 트리거하여 파일을 처리합니다. Lambda는 서버리스 방식으로, 인프라 관리의 부담이 없으며, 필요한 만큼 자동으로 확장됩니다.
• 처리된 파일은 Lambda 함수를 통해 삭제할 수 있어 파일 관리가 간편해집니다. 또한, S3는 데이터 저장과 관리 측면에서 비용 효율적이고 확장성이 뛰어납니다.

문제 7 :회사의 보고 시스템은 매일 수백 개의 .csv 파일을 Amazon S3 버킷에 전달합니다. 회사는 이러한 파일을 Apache Parquet 형식으로 변환하고 변환된 데이터 버킷에 파일을 저장해야 합니다. 최소한의 개발 노력으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

A. Apache Spark가 설치된 Amazon EMR 클러스터를 생성합니다. 데이터를 변환하는 Spark 애플리케이션을 작성합니다. EMRFS(EMR 파일 시스템)를 사용하여 변환된 데이터 버킷에 파일을 씁니다.

• Amazon EMR은 대규모 데이터를 처리할 수 있는 Hadoop 기반의 관리형 클러스터 서비스입니다. Apache Spark를 사용하여 .csv 파일을 Parquet 형식으로 변환할 수 있습니다.
• EMR을 사용하는 것은 매우 유연하지만, 클러스터 관리 및 설정, Spark 애플리케이션 개발이 필요하여 개발 및 운영의 복잡도가 높습니다. 이로 인해 최소한의 개발 노력이라는 조건과는 다소 맞지 않습니다.

B. 데이터를 검색할 AWS Glue 크롤러를 생성합니다. AWS Glue 추출, 변환 및 로드(ETL) 작업을 생성하여 데이터를 변환합니다. 출력 단계에서 변환된 데이터 버킷을 지정합니다.

• AWS Glue는 서버리스 데이터 통합 서비스로, ETL(Extract, Transform, Load) 작업을 자동화할 수 있습니다. Glue 크롤러를 사용하여 .csv 파일을 스캔하고, ETL 작업을 통해 데이터를 Parquet 형식으로 변환한 후 S3 버킷에 저장할 수 있습니다.
• Glue는 서버리스로 관리 부담이 적고, Glue Studio를 통해 시각적인 방식으로 ETL 작업을 정의할 수 있어 개발 노력이 상대적으로 적습니다.

C. AWS Batch를 사용하여 Bash 구문으로 작업 정의를 생성하여 데이터를 변환하고 데이터를 변환된 데이터 버킷으로 출력합니다. 작업 정의를 사용하여 작업을 제출합니다. 어레이 작업을 작업 유형으로 지정합니다.

• AWS Batch는 컴퓨팅 자원을 관리하고 배포하여 대규모 배치 작업을 처리하는 서비스입니다. Batch를 통해 데이터를 변환할 수 있지만, Bash 스크립트를 작성하고 작업 정의를 구성해야 하므로 상대적으로 개발의 복잡도가 높습니다.

D. 데이터를 변환하고 변환된 데이터 버킷에 데이터를 출력하는 AWS Lambda 함수를 생성합니다. S3 버킷에 대한 이벤트 알림을 구성하여 Lambda 함수를 지정합니다.

• Lambda는 서버리스로 관리 부담이 없지만, 수백 개의 .csv 파일을 Parquet 형식으로 변환하는 작업에는 적합하지 않을 수 있습니다. Lambda의 실행 시간과 메모리 제한으로 인해 대용량 데이터 처리에는 적합하지 않습니다. 따라서 데이터 변환의 규모가 클 경우 Lambda를 사용하는 것은 비효율적일 수 있습니다.

문제 8 : 회사는 AWS 리전에 워크로드가 있습니다. 고객은 Amazon API Gateway REST API를 사용하여 워크로드에 연결하고 액세스합니다. 이 회사는 Amazon Route 53을 DNS 공급자로 사용합니다. 회사는 모든 고객에게 개별적이고 안전한 URL을 제공하고자 합니다.

가장 높은 운영 효율성으로 이러한 요구 사항을 충족하는 단계 조합은 무엇입니까? (3개를 선택하세요.)

 

A. 등록기관에 필요한 도메인을 등록합니다. Route 53 호스팅 영역에서 와일드카드 사용자 지정 도메인 이름을 생성하고 API 게이트웨이 엔드포인트를 가리키는 영역 레코드를 생성.

• 이 선택지는 등록기관에 도메인을 등록하고 Route 53에서 도메인 설정을 수행하는 과정입니다. 와일드카드 도메인(예: *.example.com)을 사용하면, 모든 하위 도메인에 대해 하나의 와일드카드 인증서를 적용할 수 있습니다.
• 이렇게 하면 여러 하위 도메인을 관리하는 데 있어 편리하고 효율적입니다. 고객별로 개별적인 URL을 제공하려면 와일드카드 도메인이 적합한 선택입니다.

B. 다른 리전에 있는 AWS Certificate Manager(ACM)의 도메인과 일치하는 와일드카드 인증서를 요청.

• 이 선택지는 다른 리전에 있는 ACM의 인증서를 활용하는 방법입니다. 하지만 ACM 인증서는 리전 간에 자동으로 공유되지 않기 때문에, 같은 리전 내에서 사용하는 것이 일반적입니다.
• 따라서 이 선택지는 운영 효율성을 높이는 데 있어 적합하지 않습니다.

C. Route 53에서 필요에 따라 각 고객에 대한 호스팅 영역을 생성. API 게이트웨이 엔드포인트를 가리키는 영역 레코드를 생성.

• 이 방법은 고객마다 별도의 호스팅 영역을 생성하여 고객별로 도메인을 설정하는 방식입니다. 하지만 고객 수가 많아질수록 수동 작업과 관리 부담이 크게 증가하므로 운영 효율성이 떨어집니다.

D. 동일한 리전의 AWS Certificate Manager(ACM)에서 사용자 지정 도메인 이름과 일치하는 와일드카드 인증서를 요청.

• 이 선택지는 와일드카드 인증서를 사용하여 동일 리전의 ACM에서 관리하도록 설정하는 것입니다. 와일드카드 인증서는 동일한 도메인의 여러 하위 도메인에 대해 하나의 인증서로 보안을 유지할 수 있습니다.
• 따라서 고객별로 하위 도메인을 쉽게 생성하고, 이를 보안할 수 있는 방법입니다.

E. API Gateway에서 고객별로 여러 API 엔드포인트를 생성.

• 고객별로 엔드포인트를 생성하는 방식은 수동 작업이 많아 관리 효율이 떨어질 수 있습니다. API Gateway에서 개별 엔드포인트를 만드는 대신, 와일드카드 도메인과 ACM 인증서를 사용하여 효율적으로 관리할 수 있습니다.

F. API Gateway에서 REST API용 사용자 지정 도메인 이름을 생성. AWS Certificate Manager(ACM)에서 인증서를 가져옴.

• 이 선택지는 API Gateway에서 사용자 지정 도메인을 생성하고, ACM을 통해 인증서를 적용하는 과정입니다. 이를 통해 API Gateway의 기본 URL 대신 사용자 지정 URL을 사용할 수 있어, 고객에게 제공할 개별 URL을 설정하는 데 유리합니다.