AWS SAA 합격으로 가는 길 #207

안녕하세요! 넥스트클라우드의 테크니컬 트레이너 김유림입니다. 🌾 

 

9월 넷째 주 월요일입니다! 이번 주 금요일이 추석이라 벌써 마음이 조금 들뜨시는 분들도 계실 것 같습니다. 

명절 전 한 주는 유난히 빨리 지나가니, 오늘 배운 개념 하나만이라도 확실히 챙겨 가시면 좋겠습니다. 

 

오늘은 아주 큰 데이터를 옮기는 방법, 필요할 때 자리를 확보해 두는 방법, 그리고 갑자기 몰리는 요청을 안전하게 받아 내는 방법을 함께 보겠습니다. 그럼 시작하겠습니다! 😊

 

 

문제는 세 가지 단계를 거치며 풀어가겠습니다.

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

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

3. 선택지 분석하기

 

바로 문제 풀이 시작합니다.

---

문제1

회사는 물리적 테이프에 5PB의 아카이빙된 데이터를 가지고 있습니다. 회사는 규정 준수를 위해 테이프의 데이터를 10년 더 보존해야 합니다. 회사는 향후 6개월 내에 AWS로 마이그레이션하기를 원합니다. 테이프를 저장하는 데이터 센터에는 1Gbps 업링크 인터넷 연결이 있습니다. 

이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

 

선택지

A. 온프레미스에서 테이프의 데이터를 읽습니다. 로컬 NFS 스토리지에 데이터를 준비합니다. AWS DataSync를 사용하여 데이터를 Amazon S3 Glacier Flexible Retrieval로 마이그레이션합니다.
B. 온프레미스 백업 애플리케이션을 사용하여 테이프에서 데이터를 읽고 Amazon S3 Glacier Deep Archive에 직접 씁니다.
C. 테이프 게이트웨이가 있는 여러 AWS Snowball 디바이스를 주문합니다. Snowball의 가상 테이프에 물리적 테이프를 복사합니다. Snowball 디바이스를 AWS로 배송합니다. 수명 주기 정책을 생성하여 테이프를 Amazon S3 Glacier Deep Archive로 이동합니다.
D. 온프레미스 테이프 게이트웨이를 구성합니다. AWS 클라우드에서 가상 테이프를 생성합니다. 백업 소프트웨어를 사용하여 물리적 테이프를 가상 테이프에 복사합니다.

---

풀이

5PB를 1Gbps 회선으로 올리면 정해진 기간 안에 끝내기 어렵고 네트워크 비용도 부담이 큽니다. 물리 장치에 데이터를 담아 배송하는 방식을 쓰면 회선과 무관하게 옮길 수 있고, 옮긴 뒤 장기 보관용 스토리지 클래스로 내려 비용을 낮출 수 있습니다.

 

정답 : C

 

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

---

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

• 5PB 규모 테이프 데이터의 AWS 이전
• 6개월 이내라는 제한된 이전 기간
• 1Gbps 업링크라는 좁은 네트워크 대역폭
• 10년 장기 보존에 맞춘 비용 효율적 보관

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

• AWS Snowball : 대용량 데이터를 물리적인 저장 장치에 담아 AWS로 실어 나르는 데이터 전송 서비스입니다. 장치를 신청하면 실물이 배송되고, 여기에 데이터를 복사한 뒤 다시 돌려보내면 AWS가 해당 데이터를 지정한 스토리지로 옮겨 줍니다. 네트워크 회선의 속도와 무관하게 옮길 수 있어, 회선이 좁거나 데이터 양이 아주 큰 경우 전송 시간과 비용을 크게 줄일 수 있습니다. 여러 대를 함께 사용하면 나누어 담아 동시에 진행할 수도 있습니다.
  
  • 테이프 게이트웨이 기능 : 장치가 가상 테이프 라이브러리처럼 보이게 해 주어, 기존에 쓰던 백업 소프트웨어가 테이프를 다루던 방식 그대로 데이터를 기록할 수 있습니다.
• AWS Storage Gateway : 온프레미스 환경과 AWS 스토리지를 이어 주는 하이브리드 스토리지 서비스입니다. 파일, 볼륨, 테이프 형태 중 필요한 방식으로 연결할 수 있으며, 테이프 게이트웨이는 클라우드에 만들어 둔 가상 테이프에 백업을 기록하도록 해 줍니다. 자주 쓰는 데이터는 온프레미스 쪽에 캐시로 두어 빠르게 읽도록 구성할 수도 있습니다. 다만 데이터가 네트워크를 통해 올라가므로 전송 속도는 보유한 회선 대역폭에 좌우됩니다.
• Amazon S3 Glacier Deep Archive : Amazon S3(Simple Storage Service)에서 가장 저렴한 장기 보관용 스토리지 클래스입니다. 몇 년에 한 번 꺼내 볼까 말까 한 규정 준수 자료나 오래된 기록을 담아 두기에 적합하며, 저장 비용이 매우 낮은 대신 데이터를 꺼내는 데 몇 시간이 걸립니다. 객체를 처음부터 이 클래스로 올릴 수도 있고, 수명 주기 정책을 걸어 일정 기간이 지나면 자동으로 옮기게 할 수도 있습니다.
  
  • S3 Glacier Flexible Retrieval : 같은 아카이브 계열이지만 꺼내는 시간이 더 짧은 대신 저장 단가는 조금 높은 클래스이며, 가끔 꺼내 볼 가능성이 있는 자료에 어울립니다.
• AWS DataSync : 온프레미스 스토리지와 AWS 스토리지 사이에서 파일을 자동으로 옮겨 주는 데이터 전송 서비스입니다. 전송 일정을 정해 반복 실행하거나 사용할 대역폭의 상한을 지정해 다른 업무에 영향을 덜 주도록 조절할 수도 있습니다. 전송 과정의 검증과 재시도를 알아서 처리해 주어 편리하지만, 네트워크를 통해 데이터를 보내므로 옮길 양이 매우 크면 회선 대역폭이 곧 한계가 됩니다.

3. 선택지 분석하기

A. 온프레미스에서 테이프의 데이터를 읽습니다. 로컬 NFS 스토리지에 데이터를 준비합니다. AWS DataSync를 사용하여 데이터를 Amazon S3 Glacier Flexible Retrieval로 마이그레이션합니다.
→ 좁은 회선으로 페타바이트급 데이터를 보내야 해 기간을 맞추기 어렵고 보관 단가도 더 높은 클래스를 쓰므로, 요구를 충족하기 어렵습니다.

B. 온프레미스 백업 애플리케이션을 사용하여 테이프에서 데이터를 읽고 Amazon S3 Glacier Deep Archive에 직접 씁니다.
→ 보관 클래스는 알맞지만 결국 같은 회선으로 전부 올려야 해 정해진 기간 안에 끝내기 어려우므로, 적절치 않습니다.

C. 테이프 게이트웨이가 있는 여러 AWS Snowball 디바이스를 주문합니다. Snowball의 가상 테이프에 물리적 테이프를 복사합니다. Snowball 디바이스를 AWS로 배송합니다. 수명 주기 정책을 생성하여 테이프를 Amazon S3 Glacier Deep Archive로 이동합니다.
→ 회선 제약을 받지 않고 대용량을 옮기면서 기존 백업 방식을 그대로 쓰고 장기 보관 비용까지 낮출 수 있으므로, 가장 적절한 방법입니다.

D. 온프레미스 테이프 게이트웨이를 구성합니다. AWS 클라우드에서 가상 테이프를 생성합니다. 백업 소프트웨어를 사용하여 물리적 테이프를 가상 테이프에 복사합니다.
→ 데이터를 모두 네트워크로 올려야 하므로 대역폭이 곧 병목이 되어, 다른 방식보다 효율적이지 않습니다.

---

 

이어서 다음 문제입니다.

---

문제2

솔루션 아키텍트는 장애 조치 AWS 지역에서 Amazon EC2 용량을 제공하기 위한 재해 복구(DR) 전략을 설계하고 있습니다. 비즈니스 요구 사항에 따르면 DR 전략은 장애 조치 지역의 용량을 충족해야 합니다. 

어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

선택지

A. 장애 조치 지역에서 온디맨드 인스턴스를 구매합니다.
B. 장애 조치 지역에서 EC2 Savings Plan을 구매합니다.
C. 장애 조치 지역에서 지역 예약 인스턴스를 구매합니다.
D. 장애 조치 지역에서 용량 예약을 구매합니다.

---

풀이

재해 상황에서 필요한 만큼의 인스턴스를 반드시 확보할 수 있어야 하는 상황입니다. 요금 할인 약정은 비용을 낮춰 줄 뿐 자원을 대신 잡아 주지는 않으므로, 가용 영역에 인스턴스 유형과 수량을 지정해 자리를 미리 확보하는 온디맨드 용량 예약을 사용해야 합니다.

 

정답 : D

 

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

---

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

• 장애 조치 대상 리전에서의 EC2 용량 확보 보장
• 재해 발생 시점의 인스턴스 시작 실패 방지
• 특정 인스턴스 유형과 가용 영역에 대한 자리 확보
• 요금 할인이 아닌 가용성 중심의 선택

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

• Amazon EC2 (Elastic Compute Cloud) : 필요한 사양의 가상 서버를 원하는 만큼 빌려 쓰는 컴퓨팅 서비스입니다. 인스턴스는 리전 안의 가용 영역(AZ)에 배치되며, 각 가용 영역의 실제 물리 자원은 무한하지 않기 때문에 특정 유형의 수요가 몰리면 요청이 거절될 수 있습니다. 평소에는 거의 겪지 않는 상황이지만, 넓은 범위의 장애로 여러 고객이 동시에 다른 리전으로 몰리는 경우에는 충분히 일어날 수 있습니다.
  
  • 온디맨드 용량 예약 : 특정 가용 영역에 인스턴스 유형과 수량을 지정해 자리를 미리 잡아 두는 기능입니다. 예약해 둔 자리는 다른 곳에 배정되지 않으므로 필요할 때 확실히 시작할 수 있으며, 인스턴스를 실제로 켜지 않아도 예약된 용량에 대한 요금이 발생합니다.
• AWS 요금 약정 옵션 : 사용량을 미리 약속하는 대신 요금을 낮춰 주는 구매 방식들이며, 자원을 대신 잡아 두는 기능과는 목적이 다릅니다.
  
  • Savings Plans : 일정 기간 동안 시간당 일정 금액 이상을 쓰기로 약속하고 할인을 받는 방식이며, 인스턴스 유형이나 리전을 폭넓게 바꿔 가며 쓸 수 있는 대신 용량을 보장하지는 않습니다.
  • 지역 예약 인스턴스 : 리전 단위로 적용되는 할인 약정이며, 어느 가용 영역에서 실행하든 요금 혜택을 받지만 자리 확보는 포함되지 않습니다.
  • 영역 예약 인스턴스 : 특정 가용 영역을 지정하는 약정이며, 할인과 함께 해당 영역의 용량 확보 효과도 함께 제공됩니다.
• 온디맨드 인스턴스 : 약정 없이 필요할 때 켜고 쓴 만큼만 지불하는 가장 기본적인 사용 방식입니다. 시작과 종료가 자유로워 사용 기간을 예측하기 어려운 개발이나 시험 환경에 자주 쓰이며, 같은 사양이라면 단가는 약정 방식보다 높습니다. 다만 시작 시점에 남는 자원이 있어야 실행되므로 자리를 미리 확보해 두는 성격은 없으며, 필요할 때 바로 켤 수 있다는 점과 그 시점에 자원이 남아 있다는 보장은 서로 다른 이야기입니다.

3. 선택지 분석하기

A. 장애 조치 지역에서 온디맨드 인스턴스를 구매합니다.
→ 시작하려는 시점에 남는 자원이 있어야 실행되므로 필요한 순간의 용량을 보장하지 못해, 요구를 충족하기 어렵습니다.

B. 장애 조치 지역에서 EC2 Savings Plan을 구매합니다.
→ 사용 금액을 약속하고 할인을 받는 방식일 뿐 자원을 잡아 두지는 않으므로, 적절치 않습니다.

C. 장애 조치 지역에서 지역 예약 인스턴스를 구매합니다.
→ 리전 단위 할인 혜택만 제공하고 가용 영역의 자리를 확보해 주지는 않으므로, 요구를 충족하기 어렵습니다.

D. 장애 조치 지역에서 용량 예약을 구매합니다.
→ 지정한 가용 영역에 인스턴스 유형과 수량만큼 자리를 미리 잡아 두어 필요한 순간에 확실히 시작할 수 있으므로, 가장 적절한 방법입니다.

---

 

마지막 문제 살펴보겠습니다.

---

문제3

한 회사는 분석을 처리하고 예측하기 위해 다양한 웹 애플리케이션에서 고객 활동을 캡처하는 솔루션을 설계하고 있습니다. 웹 애플리케이션에서의 고객 활동은 예측할 수 없으며 갑자기 증가할 수 있습니다. 회사에는 다른 웹 애플리케이션과 통합되는 솔루션이 필요합니다. 솔루션에는 보안 목적을 위한 인증 단계가 포함되어야 합니다.

어떤 솔루션이 이러한 요구 사항을 충족합니까?

 

선택지

A. 회사가 Amazon Elastic File System(Amazon EFS) 파일 시스템에서 수신하는 정보를 저장하는 Amazon Elastic Container Service(Amazon ECS) 컨테이너 인스턴스 앞에 게이트웨이 로드 밸런서(GWLB)를 구성합니다. 승인은 GWLB에서 해결됩니다.
B. 회사가 Amazon S3 버킷에 수신하는 정보를 저장하는 Amazon Kinesis 데이터 스트림 앞에 Amazon API Gateway 엔드포인트를 구성합니다. AWS Lambda 함수를 사용하여 인증을 해결합니다.
C. 회사가 Amazon S3 버킷에 수신하는 정보를 저장하는 Amazon Kinesis Data Firehose 앞에 Amazon API Gateway 엔드포인트를 구성합니다. API Gateway Lambda 권한 부여자를 사용하여 권한 부여를 해결합니다.
D. 회사가 Amazon Elastic File System(Amazon EFS) 파일 시스템에서 수신하는 정보를 저장하는 Amazon Elastic Container Service(Amazon ECS) 컨테이너 인스턴스 앞에 게이트웨이 로드 밸런서(GWLB)를 구성합니다. AWS Lambda 함수를 사용하여 인증을 해결합니다.

---

풀이

여러 애플리케이션이 붙을 수 있는 진입점, 갑작스러운 증가를 견디는 수집 경로, 그리고 인증 단계가 모두 필요합니다. API Gateway에 Lambda 권한 부여자를 붙여 인증을 처리하고 Kinesis Data Firehose로 받아 S3에 적재하면 세 가지가 한 번에 해결됩니다.

 

정답 : C

 

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

---

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

• 여러 웹 애플리케이션과 연동 가능한 표준 수집 엔드포인트
• 예측하기 어려운 급격한 트래픽 증가의 수용
• 수집 데이터의 분석용 저장소 적재
• 요청에 대한 인증 및 권한 부여 단계 포함

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

• Amazon API Gateway : 여러 애플리케이션이 공통으로 호출할 수 있는 API 진입점을 만들어 주는 완전관리형 서비스입니다. 요청량에 맞춰 자동으로 확장되므로 갑자기 호출이 몰려도 별도의 서버 증설 없이 받아 낼 수 있고, 뒤쪽의 AWS 서비스로 요청을 그대로 연결하는 통합 기능을 제공합니다.
  
  • Lambda 권한 부여자 : 요청이 뒤쪽으로 전달되기 전에 지정한 Lambda 함수를 먼저 호출해 토큰이나 헤더를 검사하고 통과 여부를 판단하게 하는 기능입니다. 인증과 권한 부여 로직을 API 계층에서 일관되게 적용할 수 있어, 뒤쪽 구성 요소마다 검증 코드를 따로 두지 않아도 됩니다.
• Amazon Kinesis Data Firehose : 흘러 들어오는 데이터를 받아 지정한 저장소로 자동으로 실어 나르는 완전관리형 전송 서비스입니다. 데이터를 일정 크기나 시간 단위로 모아 Amazon S3(Simple Storage Service)나 Amazon Redshift 같은 대상에 넣어 주며, 처리량에 맞춰 알아서 확장되므로 사용자가 샤드 수나 노드 수를 조정할 필요가 없습니다. 적재 과정에서 형식을 바꾸거나 압축하는 기능도 제공합니다.
• Amazon Kinesis Data Streams : 실시간으로 들어오는 데이터를 잠시 보관하며 여러 소비자가 나누어 읽을 수 있게 해 주는 스트리밍 서비스입니다. 데이터는 지정한 기간 동안 보관되어 같은 데이터를 여러 용도로 나누어 읽거나 처리에 실패했을 때 다시 읽을 수 있으며, 처리량은 샤드 단위로 조절합니다. 매우 유연하지만 데이터를 최종 저장소에 넣으려면 이를 읽어서 쓰는 처리 구성 요소를 따로 만들어야 합니다.
• 게이트웨이 로드 밸런서 (GWLB) : 방화벽이나 침입 탐지 같은 네트워크 가상 어플라이언스로 트래픽을 흘려보내 검사하도록 돕는 로드 밸런서입니다. 트래픽을 검사 장비로 보냈다가 되돌려 받는 경로를 투명하게 만들어 주어, 보안 장비를 여러 VPC(Virtual Private Cloud)가 함께 쓰도록 구성할 때 주로 사용됩니다. 네트워크 계층에서 동작하며 요청의 인증이나 권한 부여를 판단하는 기능은 제공하지 않습니다.

3. 선택지 분석하기

A. 회사가 Amazon Elastic File System(Amazon EFS) 파일 시스템에서 수신하는 정보를 저장하는 Amazon Elastic Container Service(Amazon ECS) 컨테이너 인스턴스 앞에 게이트웨이 로드 밸런서(GWLB)를 구성합니다. 승인은 GWLB에서 해결됩니다.
→ 게이트웨이 로드 밸런서는 요청의 인증을 판단하는 기능이 없고 직접 운영해야 할 구성 요소도 늘어나므로, 적절치 않습니다.

B. 회사가 Amazon S3 버킷에 수신하는 정보를 저장하는 Amazon Kinesis 데이터 스트림 앞에 Amazon API Gateway 엔드포인트를 구성합니다. AWS Lambda 함수를 사용하여 인증을 해결합니다.
→ 진입점 구성은 비슷하지만 스트림에서 저장소로 넣는 처리를 별도로 만들어야 하므로, 다른 방식보다 효율적이지 않습니다.

C. 회사가 Amazon S3 버킷에 수신하는 정보를 저장하는 Amazon Kinesis Data Firehose 앞에 Amazon API Gateway 엔드포인트를 구성합니다. API Gateway Lambda 권한 부여자를 사용하여 권한 부여를 해결합니다.
→ 표준 진입점과 자동 확장되는 수집 경로, 저장소 자동 적재, 인증 단계까지 모두 관리형으로 갖추므로, 가장 적절한 방법입니다.

D. 회사가 Amazon Elastic File System(Amazon EFS) 파일 시스템에서 수신하는 정보를 저장하는 Amazon Elastic Container Service(Amazon ECS) 컨테이너 인스턴스 앞에 게이트웨이 로드 밸런서(GWLB)를 구성합니다. AWS Lambda 함수를 사용하여 인증을 해결합니다.
→ 네트워크 검사용 로드 밸런서로 요청 인증을 처리할 수 없고 급증하는 트래픽에 맞춰 직접 확장을 관리해야 하므로, 요구를 충족하기 어렵습니다.

---

 

오늘 문제들은 "제약을 먼저 읽어야 답이 보이는" 유형이었습니다.

 

이번 주도 힘내 봅시다! 😊