AWS SAA 합격으로 가는 길 #208

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

 

오늘은 추석입니다! 가족들과 따뜻한 시간 보내고 계신가요? 넉넉한 한가위 보내시길 진심으로 바랍니다. 

명절이라 오늘은 조금 가볍게, 실무에서도 자주 마주치는 익숙한 주제들로 준비했습니다. 

 

송편 하나 드시면서 편하게 읽어 보세요! 😊

 

 

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

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

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

3. 선택지 분석하기

 

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

---

문제1

최근 한 회사가 AWS 클라우드로 마이그레이션했습니다. 회사는 반구조화된 데이터 세트의 대규모 병렬 주문형 처리를 위한 서버리스 솔루션을 원합니다. 데이터는 Amazon S3에 저장되는 로그, 미디어 파일, 판매 거래 및 IoT 센서 데이터로 구성됩니다. 회사는 데이터 세트에 있는 수천 개의 항목을 병렬로 처리하는 솔루션을 원합니다. 

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

 

선택지

A. 인라인 모드에서 AWS Step Functions 맵 상태를 사용하여 데이터를 병렬로 처리합니다.
B. 분산 모드에서 AWS Step Functions 맵 상태를 사용하여 데이터를 병렬로 처리합니다.
C. AWS Glue를 사용하여 데이터를 병렬로 처리합니다.
D. 여러 AWS Lambda 함수를 사용하여 데이터를 병렬로 처리합니다.

---

풀이

수천 개가 넘는 항목을 서버 없이 동시에 처리해야 합니다. Step Functions의 맵 상태는 분산 모드로 실행하면 저장소의 객체를 직접 읽어 아주 많은 자식 실행으로 펼쳐 주므로, 별도 구성 없이 대규모 병렬 처리를 맡길 수 있습니다.

 

정답 : B

 

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

---

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

• 서버 관리가 필요 없는 서버리스 처리 방식
• 수천 개 이상 항목의 동시 병렬 처리
• 요청이 있을 때만 실행되는 주문형 동작
• 최소한의 운영 부담

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

• AWS Step Functions : 여러 처리 단계를 순서와 조건에 따라 이어 주는 서버리스 워크플로 오케스트레이션 서비스입니다. 각 단계를 상태라고 부르며, 어떤 단계를 어떤 조건에서 실행하고 실패하면 몇 번 다시 시도할지를 정의로 적어 두면 서비스가 그대로 실행하고 진행 상황을 시각적으로 보여 줍니다. 실행 흐름을 코드 안에 숨기지 않고 밖으로 드러내므로, 문제가 생긴 지점을 찾고 재실행하기가 수월합니다.
  
  • 맵 상태의 인라인 모드 : 워크플로 실행 안에서 배열의 각 항목을 반복 처리하는 기본 방식이며, 동시에 처리할 수 있는 개수와 전달 가능한 데이터 크기에 제한이 있어 적은 수의 항목에 적합합니다.
  • 맵 상태의 분산 모드 : 항목마다 별도의 자식 워크플로 실행을 만들어 아주 많은 수를 동시에 처리하는 방식입니다. Amazon S3(Simple Storage Service)에 있는 객체 목록이나 파일 내용을 직접 입력으로 삼을 수 있고, 만 단위의 동시 실행까지 확장되며 실패한 항목만 따로 다시 처리하는 기능도 제공합니다.
• AWS Lambda : 코드만 올려 두면 요청이 있을 때 실행해 주는 서버리스 컴퓨팅 서비스입니다. 실행에 필요한 자원은 서비스가 알아서 마련해 주고 호출 수에 맞춰 자동으로 확장되므로 병렬 처리에 적합합니다. 다만 한 번의 실행 시간과 사용할 수 있는 메모리에 상한이 있어 아주 오래 걸리는 작업에는 맞지 않으며, 처리할 항목을 나누어 호출하고 결과를 모으고 실패를 다시 시도하는 흐름은 직접 만들어 관리해야 합니다.
• AWS Glue : 흩어진 데이터를 읽어 변환하고 다른 곳으로 실어 주는 서버리스 데이터 통합 서비스입니다. 데이터가 어디에 어떤 구조로 있는지 정리해 두는 데이터 카탈로그도 함께 제공합니다. 대규모 데이터를 일괄 처리하는 데 강점이 있으나, 정해진 스키마를 기준으로 데이터를 다루는 데이터 처리 작업에 초점이 맞춰져 있어 항목 단위의 개별 처리 흐름을 오케스트레이션하는 용도와는 결이 다릅니다.

3. 선택지 분석하기

A. 인라인 모드에서 AWS Step Functions 맵 상태를 사용하여 데이터를 병렬로 처리합니다.
→ 동시 처리 개수와 입력 크기에 제한이 있어 수천 개 규모의 항목을 감당하기 어려우므로, 적절치 않습니다.

B. 분산 모드에서 AWS Step Functions 맵 상태를 사용하여 데이터를 병렬로 처리합니다.
→ 저장소의 객체를 직접 입력으로 삼아 아주 많은 자식 실행으로 펼쳐 주고 실패 항목 재처리까지 맡길 수 있으므로, 가장 적절한 방법입니다.

C. AWS Glue를 사용하여 데이터를 병렬로 처리합니다.
→ 일괄 변환 작업에 맞춰진 서비스라 항목 단위 처리 흐름을 다루기에는 결이 맞지 않으므로, 요구를 충족하기 어렵습니다.

D. 여러 AWS Lambda 함수를 사용하여 데이터를 병렬로 처리합니다.
→ 처리 자체는 가능하지만 분배와 결과 취합, 재시도 로직을 직접 만들어야 해 운영 부담이 커지므로, 다른 방식보다 효율적이지 않습니다.

---

 

이어서 다음 문제입니다.

---

문제2

회사는 6주 안에 10PB의 데이터를 Amazon S3로 마이그레이션할 예정입니다. 현재 데이터 센터에는 인터넷에 대한 500Mbps 업링크가 있습니다. 다른 온프레미스 애플리케이션은 업링크를 공유합니다. 회사는 이 일회성 마이그레이션 작업에 인터넷 대역폭의 80%를 사용할 수 있습니다. 

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

 

선택지

A. 데이터를 Amazon S3로 마이그레이션하고 자동으로 데이터를 확인하도록 AWS DataSync를 구성합니다.
B. rsync를 사용하여 데이터를 Amazon S3로 직접 전송합니다.
C. AWS CLI와 여러 복사 프로세스를 사용하여 데이터를 Amazon S3에 직접 보냅니다.
D. 여러 AWS Snowball 디바이스를 주문합니다. 데이터를 장치에 복사합니다. 디바이스를 AWS로 보내 데이터를 Amazon S3에 복사합니다.

---

풀이

쓸 수 있는 대역폭이 400Mbps 남짓이라 10PB를 모두 보내려면 회선을 온전히 다 써도 6년이 넘게 걸립니다. 네트워크로는 어떤 도구를 쓰더라도 6주라는 기한을 맞출 수 없으므로, 물리 장치에 데이터를 담아 배송하는 방식을 여러 대로 나누어 진행해야 합니다.

 

정답 : D

 

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

---

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

• 10PB 규모 데이터의 Amazon S3 이전
• 6주라는 명확한 기한
• 업링크 500Mbps 중 80%만 사용 가능한 제약
• 일회성 이전 작업에 적합한 수단

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

• AWS Snowball : 대용량 데이터를 물리적인 저장 장치에 담아 AWS로 옮기는 데이터 전송 서비스입니다. 신청하면 견고하게 만들어진 장치가 배송되고, 온프레미스 네트워크로 데이터를 복사한 뒤 다시 돌려보내면 AWS가 이를 Amazon S3(Simple Storage Service)에 넣어 줍니다. 데이터는 장치 안에서 암호화되어 보관되며, 여러 대를 동시에 받아 나누어 담으면 규모가 커져도 처리 기간을 줄일 수 있습니다. 인터넷 회선을 거의 쓰지 않으므로 대역폭이 좁거나 다른 업무와 회선을 나눠 써야 하는 환경에서 특히 유용합니다.
• AWS DataSync : 온프레미스 스토리지와 AWS 스토리지 사이의 파일 전송을 자동화해 주는 서비스입니다. 전송한 데이터가 온전한지 검증하고 실패한 부분을 다시 시도해 주며 전송 속도를 조절하는 기능도 갖추고 있어 편리합니다. 전송 일정을 정해 두고 반복 실행하도록 구성하는 것도 가능합니다. 다만 데이터가 네트워크를 통해 오가므로 실제로 낼 수 있는 속도는 확보된 회선 대역폭을 넘어설 수 없습니다.
• Amazon S3 (Simple Storage Service) : 파일을 객체 단위로 담아 두는 완전관리형 객체 스토리지 서비스입니다. 저장 용량에 사실상 제한이 없고 여러 시설에 나누어 복제해 보관하므로 내구성이 매우 높습니다. 접근 빈도에 따라 여러 스토리지 클래스를 골라 저장 비용을 조절할 수도 있습니다. 여러 부분으로 나누어 동시에 올리는 멀티파트 업로드를 지원해 큰 파일도 효율적으로 올릴 수 있지만, 이 역시 회선이 감당할 수 있는 범위 안에서만 빨라집니다.

3. 선택지 분석하기

A. 데이터를 Amazon S3로 마이그레이션하고 자동으로 데이터를 확인하도록 AWS DataSync를 구성합니다.
→ 검증과 재시도는 편리하지만 결국 좁은 회선을 통해 보내야 해 기한 안에 끝낼 수 없으므로, 요구를 충족하기 어렵습니다.

B. rsync를 사용하여 데이터를 Amazon S3로 직접 전송합니다.
→ rsync는 파일 시스템 사이의 동기화를 위한 도구라 객체 스토리지로 직접 보낼 수 없고, 별도 도구로 우회하더라도 회선 속도는 그대로여서 기한을 맞출 수 없으므로, 적절치 않습니다.

C. AWS CLI와 여러 복사 프로세스를 사용하여 데이터를 Amazon S3에 직접 보냅니다.
→ 여러 갈래로 동시에 보내더라도 사용할 수 있는 총 대역폭은 그대로이므로, 다른 방식보다 효율적이지 않습니다.

D. 여러 AWS Snowball 디바이스를 주문합니다. 데이터를 장치에 복사합니다. 디바이스를 AWS로 보내 데이터를 Amazon S3에 복사합니다.
→ 인터넷 회선을 거의 쓰지 않고 여러 대로 나누어 동시에 담아 보낼 수 있어 기한 안에 이전을 마칠 수 있으므로, 가장 적절한 방법입니다.

 

---

 

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

---

문제3

솔루션 아키텍트는 비즈니스 사용자가 Amazon S3에 객체를 업로드할 수 있는 애플리케이션을 설계하고 있습니다. 솔루션은 객체 내구성을 극대화해야 합니다. 또한 객체는 언제든지 쉽게 사용할 수 있어야 합니다. 사용자는 객체가 업로드된 후 처음 30일 이내에 객체에 자주 액세스하지만 30일보다 오래된 객체에는 사용자가 액세스할 가능성이 훨씬 적습니다. 

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

 

선택지

A. S3 수명 주기 규칙을 사용하여 모든 객체를 S3 Standard에 저장하여 30일 후에 객체를 S3 Glacier로 전환합니다.
B. 30일 후에 객체를 S3 Standard-Infrequent Access(S3 Standard-IA)로 전환하려면 S3 수명 주기 규칙을 사용하여 모든 객체를 S3 Standard에 저장합니다.
C. 30일 후에 객체를 S3 One Zone-Infrequent Access(S3 One Zone-IA)로 전환하는 S3 수명 주기 규칙을 사용하여 모든 객체를 S3 Standard에 저장합니다.
D. S3 수명 주기 규칙을 사용하여 모든 객체를 S3 Intelligent-Tiering에 저장하여 30일 후에 객체를 S3 Standard-Infrequent Access(S3 Standard-IA)로 전환합니다.

---

풀이

오래된 객체도 언제든 바로 꺼내 쓸 수 있어야 하고 내구성도 최대여야 합니다. 처음 30일은 S3 Standard에 두고 이후 S3 Standard-IA로 옮기면 즉시 조회 가능성과 여러 가용 영역 복제를 유지하면서 저장 비용을 낮출 수 있습니다.

 

정답 : B

 

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

---

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

• 객체 내구성의 극대화
• 시점과 무관하게 즉시 사용 가능한 접근성
• 업로드 후 30일 이내의 잦은 접근과 이후의 낮은 접근 빈도
• 접근성을 해치지 않는 범위의 비용 절감

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

• Amazon S3 (Simple Storage Service) : 파일을 객체 형태로 담아 두는 완전관리형 객체 스토리지 서비스입니다. 저장한 객체는 기본적으로 리전 내 여러 가용 영역(AZ)에 자동으로 복제되어 매우 높은 내구성을 갖습니다. 접근 빈도와 필요한 응답 속도에 따라 여러 스토리지 클래스를 고를 수 있고, 수명 주기 규칙을 걸어 두면 지정한 기간이 지난 객체를 다른 클래스로 자동으로 옮겨 관리 부담 없이 비용을 조절할 수 있습니다.
  
  • S3 Standard : 자주 접근하는 데이터를 위한 기본 클래스이며, 즉시 조회가 가능하고 여러 가용 영역에 복제됩니다.
  • S3 Standard-IA(Standard-Infrequent Access) : 접근 빈도가 낮은 데이터를 위한 클래스이며, 저장 단가가 더 낮으면서도 여러 가용 영역 복제와 즉시 조회를 그대로 유지합니다. 대신 데이터를 꺼낼 때 조회 요금이 별도로 발생합니다.
  • S3 One Zone-IA(One Zone-Infrequent Access) : 하나의 가용 영역에만 데이터를 두어 더 저렴한 대신, 그 영역에 문제가 생기면 데이터를 잃을 수 있어 내구성 측면에서 불리합니다.
  • S3 Glacier 계열 : 아주 오래 보관할 자료를 위한 저비용 아카이브 클래스이며, 저장 단가가 매우 낮은 대신 데이터를 꺼내는 데 별도의 복원 과정과 시간이 필요합니다.
  • S3 Intelligent-Tiering : 접근 패턴을 관찰해 알아서 계층을 옮겨 주는 클래스이며, 접근 빈도를 예측하기 어려울 때 유용하고 객체마다 소액의 모니터링 요금이 붙습니다.

3. 선택지 분석하기

A. S3 수명 주기 규칙을 사용하여 모든 객체를 S3 Standard에 저장하여 30일 후에 객체를 S3 Glacier로 전환합니다.
→ 저장 비용은 가장 낮지만 꺼낼 때 복원 과정과 시간이 필요해 언제든 바로 쓸 수 있어야 한다는 조건과 맞지 않으므로, 적절치 않습니다.

B. 30일 후에 객체를 S3 Standard-Infrequent Access(S3 Standard-IA)로 전환하려면 S3 수명 주기 규칙을 사용하여 모든 객체를 S3 Standard에 저장합니다.
→ 여러 가용 영역 복제와 즉시 조회를 유지하면서 접근이 뜸해지는 시점부터 저장 단가를 낮출 수 있으므로, 가장 적절한 방법입니다.

C. 30일 후에 객체를 S3 One Zone-Infrequent Access(S3 One Zone-IA)로 전환하는 S3 수명 주기 규칙을 사용하여 모든 객체를 S3 Standard에 저장합니다.
→ 데이터를 한 가용 영역에만 두게 되어 내구성을 극대화해야 한다는 조건과 어긋나므로, 요구를 충족하기 어렵습니다.

D. S3 수명 주기 규칙을 사용하여 모든 객체를 S3 Intelligent-Tiering에 저장하여 30일 후에 객체를 S3 Standard-Infrequent Access(S3 Standard-IA)로 전환합니다.
→ 접근 패턴이 이미 분명한 상황에서는 자동 계층 이동과 모니터링 요금이 덧붙어, 다른 방식보다 효율적이지 않습니다.

---

 

오늘 문제들은 "제한을 먼저 계산해 보라"는 공통점이 있었습니다.

특히, 세 번째 문제의 스토리지 클래스는 시험에 정말 자주 나오니, "즉시 꺼낼 수 있는가"와 "몇 개의 가용 영역에 두는가" 두 가지 기준으로 정리해 두시면 헷갈리지 않습니다.

 

남은 연휴도 편안하게 보내세요! 😊