AWS SAA 합격으로 가는 길 #110

안녕하세요! 넥스트클라우드의 SA 백종훈입니다.

 

문제는 세 가지 단계를 거치며 풀어 나갈 거예요.

1. 문제의 요구사항 분석하기

2. 관련 AWS 서비스 생각하기

3. 선택지 분석하기

 

바로 문제 풀이 해볼까요?

---

문제1

회사에서 온프레미스 데이터 세트의 보조 사본으로 Amazon S3를 사용하려고 합니다. 회사는 이 복사본에 액세스할 필요가 거의 없습니다. 스토리지 솔루션의 비용은 최소화되어야 합니다.

이러한 요구 사항을 충족하는 스토리지 솔루션은 무엇입니까

 

선택지

A. S3 Standard

B. S3 Intelligent-Tiering

C. S3 Standard-Infrequent Access(S3 Standard-IA)

D. S3 One Zone-Infrequent Access(S3 One Zone-IA)

 

풀이

온프레미스 데이터의 보조 사본으로 활용하며 액세스 빈도가 매우 낮은 경우, S3 One Zone-IA가 가장 비용 효율적인 선택입니다. 단일 가용 영역에 데이터를 저장하여 비용을 최소화하면서도, 보조 사본이라는 특성상 높은 가용성이 반드시 필요하지 않기 때문에 적합한 솔루션입니다.

정답 : D

 

▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

1.  문제의 요구사항 분석하기

• 온프레미스 데이터 세트의 보조 사본으로 S3 활용
• 복사본에 액세스할 필요가 거의 없음 (매우 낮은 액세스 빈도)
• 스토리지 비용 최소화가 최우선 목표

2. 관련 AWS 서비스 생각하기

• Amazon S3는 다양한 스토리지 클래스를 제공하여 액세스 패턴과 비용 요구사항에 맞는 최적의 선택을 할 수 있습니다. S3 Standard-IA와 S3 One Zone-IA는 모두 액세스 빈도가 낮은 데이터를 위해 설계되었지만, 가용성과 비용 측면에서 차이가 있습니다. S3 Standard-IA는 여러 가용 영역에 데이터를 복제하여 99.9%의 가용성을 제공하는 반면, S3 One Zone-IA는 단일 가용 영역에만 데이터를 저장하여 99.5%의 가용성을 제공합니다. 하지만 S3 One Zone-IA는 Standard-IA 대비 약 20% 저렴한 비용을 제공합니다. 보조 사본이라는 특성상 원본 데이터가 온프레미스에 존재하므로, 높은 가용성보다는 비용 최소화가 더 중요한 요소가 됩니다.

3. 선택지 분석하기

A. S3 Standard

→ 자주 액세스하는 데이터를 위한 스토리지 클래스로, 액세스 빈도가 낮은 보조 사본에는 비용 측면에서 비효율적입니다.

B. S3 Intelligent-Tiering

→ 액세스 패턴이 변화하거나 예측하기 어려운 경우에 적합하지만, 이미 액세스 빈도가 매우 낮다고 명시된 상황에서는 추가 모니터링 비용이 발생하여 비효율적입니다.

C. S3 Standard-Infrequent Access(S3 Standard-IA)

→ 액세스 빈도가 낮은 데이터에 적합하지만, 여러 가용 영역에 데이터를 저장하므로 S3 One Zone-IA보다 비용이 높습니다.

D. S3 One Zone-Infrequent Access(S3 One Zone-IA)

→ 액세스 빈도가 낮은 보조 사본에 최적화되어 있으며, 단일 가용 영역 저장으로 비용을 최대한 절감할 수 있습니다.

 

이어서 다음 문제입니다.

---

문제2

게임 회사는 공개 점수판을 데이터 센터에서 AWS 클라우드로 옮기고 있습니다. 이 회사는 Application Load Balancer 뒤에 Amazon EC2 Windows Server 인스턴스를 사용하여 동적 애플리케이션을 호스팅합니다. 회사는 애플리케이션을 위한 고가용성 스토리지 솔루션이 필요합니다. 애플리케이션은 정적 파일과 동적 서버 측 코드로 구성됩니다.

이러한 요구 사항을 충족하기 위해 솔루션 설계자는 어떤 단계 조합을 수행해야 합니까? (두 가지를 선택하세요.)

 

선택지

A. Amazon S3에 정적 파일을 저장합니다. Amazon CloudFront를 사용하여 엣지에서 객체를 캐싱합니다.

B. 정적 파일을 Amazon S3에 저장합니다. Amazon ElastiCache를 사용하여 엣지에서 객체를 캐싱합니다.

C. Amazon Elastic File System(Amazon EFS)에 서버 측 코드를 저장합니다. 파일을 공유할 각 EC2 인스턴스에 EFS 볼륨을 탑재합니다.

D. Windows File Server용 Amazon FSx에 서버 측 코드를 저장합니다. 파일을 공유할 각 EC2 인스턴스에 FSx for Windows File Server 볼륨을 탑재합니다.

E. 범용 SSD(gp2) Amazon Elastic Block Store(Amazon EBS) 볼륨에 서버 측 코드를 저장합니다. 각 EC2 인스턴스에 EBS 볼륨을 탑재하여 파일을 공유합니다.

 

풀이

게임 애플리케이션의 정적 파일은 S3와 CloudFront를 통해 글로벌 배포하고, Windows Server 환경의 동적 서버 측 코드는 FSx for Windows File Server를 통해 고가용성 공유 스토리지를 구성하는 것이 최적입니다. 이 조합은 성능과 호환성을 모두 만족시킵니다.

정답 : A,D

 

▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

1.  문제의 요구사항 분석하기

• 게임 회사의 공개 점수판 애플리케이션 AWS 마이그레이션
• EC2 Windows Server 인스턴스에서 동적 애플리케이션 호스팅
• 정적 파일과 동적 서버 측 코드 분리 저장 필요
• 고가용성 스토리지 솔루션 필요

2. 관련 AWS 서비스 생각하기

• Amazon S3와 CloudFront의 조합은 정적 콘텐츠 배포의 표준 패턴입니다. S3는 높은 내구성(99.999999999%)과 가용성을 제공하며, CloudFront는 전 세계 엣지 로케이션을 통해 지연 시간을 최소화하고 사용자 경험을 향상시킵니다. 게임의 정적 자산(이미지, CSS, JavaScript 등)을 빠르게 로드하는 것은 사용자 경험에 매우 중요합니다. Amazon FSx for Windows File Server는 Windows 환경에 최적화된 완전 관리형 파일 시스템으로, SMB 프로토콜을 지원하여 Windows Server 인스턴스와의 호환성이 뛰어납니다. 여러 EC2 인스턴스에서 동시에 접근할 수 있으며, Active Directory 통합, VSS 백업, 중복 제거 등 Windows 환경에서 필요한 기능들을 제공합니다. 다중 AZ 배포를 통해 고가용성도 보장합니다.

3. 선택지 분석하기

A. Amazon S3에 정적 파일을 저장합니다. Amazon CloudFront를 사용하여 엣지에서 객체를 캐싱합니다.

→ 정적 파일의 글로벌 배포와 성능 최적화를 위한 표준 아키텍처로, 게임 애플리케이션의 사용자 경험 향상에 필수적입니다.

 

B. 정적 파일을 Amazon S3에 저장합니다. Amazon ElastiCache를 사용하여 엣지에서 객체를 캐싱합니다.

→ ElastiCache는 애플리케이션 데이터 캐싱을 위한 인메모리 서비스로, 정적 파일의 엣지 캐싱에는 부적합합니다.

 

C. Amazon EFS에 서버 측 코드를 저장합니다.

→ EFS는 Linux 환경에 최적화된 NFS 파일 시스템으로, Windows Server 인스턴스와의 호환성이 제한적입니다.

 

D. Windows File Server용 Amazon FSx에 서버 측 코드를 저장합니다.

→ Windows Server 환경에 최적화된 파일 시스템으로 SMB 프로토콜을 지원하여 여러 Windows EC2 인스턴스에서 안전하게 서버 측 코드를 공유할 수 있습니다.

 

E. 범용 SSD(gp2) Amazon EBS 볼륨에 서버 측 코드를 저장합니다.

→ EBS 볼륨은 단일 EC2 인스턴스에만 연결할 수 있어 여러 인스턴스 간 파일 공유가 불가능합니다.

 

마지막 문제 살펴볼게요.

---

문제3

연구소는 약 8TB의 데이터를 처리해야 합니다. 실험실에는 스토리지 하위 시스템에 대해 1밀리초 미만의 대기 시간과 최소 6GBps의 처리량이 필요합니다. Amazon Linux를 실행하는 수백 개의 Amazon EC2 인스턴스가 데이터를 배포하고 처리합니다.

성능 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. NetApp ONTAP 파일 시스템용 Amazon FSx를 생성합니다. 각 볼륨의 계층화 정책을 ALL로 설정합니다. 원시 데이터를 파일 시스템으로 가져옵니다. EC2 인스턴스에 파일 시스템을 탑재합니다.

B. 원시 데이터를 저장할 Amazon S3 버킷을 생성합니다. 영구 SSD 스토리지를 사용하는 Amazon FSx for Lustre 파일 시스템을 생성합니다. Amazon S3에서 데이터를 가져오고 내보내는 옵션을 선택합니다. EC2 인스턴스에 파일 시스템을 탑재합니다.

C. 원시 데이터를 저장할 Amazon S3 버킷을 생성합니다. 영구 HDD 스토리지를 사용하는 Amazon FSx for Lustre 파일 시스템을 생성합니다. Amazon S3에서 데이터를 가져오고 내보내는 옵션을 선택합니다. EC2 인스턴스에 파일 시스템을 탑재합니다.

D. NetApp ONTAP 파일 시스템용 Amazon FSx를 생성합니다. 각 볼륨의 계층화 정책을 NONE으로 설정합니다. 원시 데이터를 파일 시스템으로 가져옵니다. EC2 인스턴스에 파일 시스템을 탑재합니다.

 

풀이

극한의 성능 요구사항(1ms 미만 지연시간, 6GBps 이상 처리량)을 만족하려면 고성능 컴퓨팅(HPC) 워크로드에 특화된 Amazon FSx for Lustre가 필요합니다. 특히 영구 SSD 스토리지를 사용하면 하위 밀리초 지연시간과 높은 처리량을 모두 확보할 수 있으며, S3와의 통합을 통해 데이터 관리 효율성도 높일 수 있습니다.

 

정답 : A

 

▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.

1.  문제의 요구사항 분석하기

• 약 8TB의 대용량 데이터 처리
• 극한의 성능 요구사항: 1밀리초 미만 대기시간, 최소 6GBps 처리량
• 수백 개의 Amazon Linux EC2 인스턴스에서 병렬 데이터 처리
• 고성능 컴퓨팅(HPC) 워크로드 특성

2. 관련 AWS 서비스 생각하기

• Amazon FSx for Lustre는 고성능 컴퓨팅 워크로드를 위해 특별히 설계된 완전 관리형 파일 시스템입니다. Lustre는 원래 대규모 슈퍼컴퓨터 환경에서 사용되던 병렬 분산 파일 시스템으로, 수백 또는 수천 개의 클라이언트에서 동시에 접근할 때도 일관된 고성능을 제공합니다. FSx for Lustre는 두 가지 스토리지 유형을 제공합니다: 영구 SSD 스토리지는 하위 밀리초 지연시간과 초당 수백 GB의 처리량을 제공하며, 영구 HDD 스토리지는 비용을 절감하지만 성능이 상대적으로 낮습니다. 또한 S3와 네이티브 통합되어 있어 S3 버킷의 데이터를 파일 시스템으로 직접 가져오고, 처리 결과를 다시 S3로 내보낼 수 있습니다. 이를 통해 데이터 레이크 아키텍처와 HPC 환경을 효율적으로 연결할 수 있습니다.

3. 선택지 분석하기

A. NetApp ONTAP 파일 시스템용 Amazon FSx를 생성합니다. 각 볼륨의 계층화 정책을 ALL로 설정합니다.

→ FSx for NetApp ONTAP는 엔터프라이즈 워크로드에 적합하지만, 극한의 성능 요구사항(1ms 미만 지연시간, 6GBps 처리량)을 충족하기에는 한계가 있습니다.

 

B. 영구 SSD 스토리지를 사용하는 Amazon FSx for Lustre 파일 시스템을 생성합니다.

→ FSx for Lustre는 HPC 워크로드에 최적화되어 하위 밀리초 지연시간과 높은 처리량을 제공하며, 영구 SSD 스토리지로 극한의 성능 요구사항을 만족합니다.

 

C. 영구 HDD 스토리지를 사용하는 Amazon FSx for Lustre 파일 시스템을 생성합니다.

→ HDD 스토리지는 비용 효율적이지만 1ms 미만 지연시간과 6GBps 처리량이라는 극한의 성능 요구사항을 충족하지 못합니다.

 

D. NetApp ONTAP 파일 시스템용 Amazon FSx를 생성합니다. 각 볼륨의 계층화 정책을 NONE으로 설정합니다.

→ 계층화 정책을 NONE으로 설정해도 FSx for NetApp ONTAP는 HPC 워크로드의 극한 성능 요구사항에는 적합하지 않습니다.

 

감사합니다. 다음 글에서 만나요.☺️