AWS SAA 합격으로 가는 길 #197

안녕하세요! 넥스트클라우드의 테크니컬 트레이너 김서윤입니다. 🌤️

연휴를 보내고 다시 만나는 월요일이에요! 늘어진 리듬 되찾기 좋게, 오늘도 세 문제 가볍게 함께 풀어볼게요.

 

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

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

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

3. 선택지 분석하기

 

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

---

문제1

회사에는 Amazon Simple Queue Service(Amazon SQS)를 사용하여 메시지를 구문 분석하는 Java 애플리케이션이 있습니다. 애플리케이션은 크기가 256KB보다 큰 메시지를 구문 분석할 수 없습니다. 회사는 응용 프로그램이 50MB만큼 큰 메시지를 구문 분석할 수 있는 기능을 제공하는 솔루션을 구현하려고 합니다.

 

코드를 가장 적게 변경하여 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. Java용 Amazon SQS 확장 클라이언트 라이브러리를 사용하여 Amazon S3에서 256KB보다 큰 메시지를 호스팅합니다.

B. Amazon SQS 대신 Amazon EventBridge를 사용하여 애플리케이션에서 큰 메시지를 게시합니다.

C. 256KB보다 큰 메시지를 처리하도록 Amazon SQS의 제한을 변경합니다.

D. Amazon Elastic File System(Amazon EFS)에 256KB보다 큰 메시지를 저장합니다. 메시지에서 이 위치를 참조하도록 Amazon SQS를 구성합니다.

---

풀이

대기열 메시지의 최대 크기가 256KB로 고정되어 있어 더 큰 본문은 대기열 밖에 두어야 합니다. Java용 확장 클라이언트 라이브러리는 큰 본문을 Amazon S3에 저장하고 참조만 주고받는 과정을 대신 처리해 주므로, 코드 변경을 가장 적게 하면서 요구를 충족합니다.

 

정답 : A

 

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

---

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

• 최대 50MB 크기 메시지의 처리
• 256KB인 대기열 메시지 크기 제한의 우회
• 기존 Java 애플리케이션 코드 변경의 최소화

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

• Amazon SQS(Simple Queue Service) : 애플리케이션 사이에 메시지를 안전하게 전달하도록 중간에서 보관해 주는 완전관리형 메시지 대기열 서비스입니다. 보내는 쪽과 받는 쪽이 서로의 상태에 영향을 받지 않도록 분리해 주기 때문에, 한쪽이 잠시 멈추어도 메시지가 유실되지 않고 대기열에 남아 있습니다. 처리량에 맞춰 자동으로 확장되며 사용자가 용량을 미리 준비할 필요가 없고, 서버를 직접 세우거나 관리하지 않아도 됩니다.
  • 메시지 하나의 최대 크기는 256KB로 정해져 있으며, 이 값은 사용자가 늘릴 수 없는 서비스 자체의 제한입니다.
  • Java용 확장 클라이언트 라이브러리(Extended Client Library)를 사용하면 본문을 Amazon S3에 저장하고 대기열에는 그 위치를 가리키는 참조만 넣는 처리를 라이브러리가 자동으로 수행합니다. 최대 2GB까지의 본문을 다룰 수 있습니다.
• Amazon S3(Simple Storage Service) : 파일을 객체 단위로 저장하는 오브젝트 스토리지 서비스로, 저장 용량에 제한을 두지 않고 사용한 만큼만 요금을 냅니다. 여러 시설에 걸쳐 데이터를 중복 저장해 높은 내구성을 제공하며, 버킷 정책과 액세스 제어로 접근 권한을 세밀하게 지정할 수 있습니다. 크기가 큰 데이터를 보관해 두고 다른 서비스가 그 위치를 참조하도록 구성하는 용도로 널리 쓰이며, 객체 하나의 크기는 최대 5TB까지 지원합니다.
• Amazon EventBridge : 여러 서비스와 애플리케이션에서 발생한 이벤트를 받아 규칙에 따라 원하는 대상으로 전달해 주는 서버리스 이벤트 버스 서비스입니다. 이벤트 내용에 조건을 걸어 필요한 대상에게만 보내는 필터링이 가능하고, 수신 대상으로 Lambda 함수나 대기열 등 다양한 서비스를 지정할 수 있습니다. 다만 하나의 이벤트가 담을 수 있는 크기 역시 256KB로 제한되어 있습니다.

3. 선택지 분석하기

A. Java용 Amazon SQS 확장 클라이언트 라이브러리를 사용하여 Amazon S3에서 256KB보다 큰 메시지를 호스팅합니다.

→ 라이브러리만 적용하면 S3 저장과 참조 전달이 자동 처리되는 표준 방식입니다.

 

B. Amazon SQS 대신 Amazon EventBridge를 사용하여 애플리케이션에서 큰 메시지를 게시합니다.

→ EventBridge도 이벤트 크기가 256KB로 제한되고 코드 변경이 큽니다.

 

C. 256KB보다 큰 메시지를 처리하도록 Amazon SQS의 제한을 변경합니다.

→ 메시지 최대 크기는 사용자가 늘릴 수 있는 설정이 아닙니다.

 

D. Amazon Elastic File System(Amazon EFS)에 256KB보다 큰 메시지를 저장합니다. 메시지에서 이 위치를 참조하도록 Amazon SQS를 구성합니다.

→ 저장·참조·정리를 직접 구현해야 해 코드 변경이 많아집니다.

---

 

이어서 다음 문제입니다.

---

문제2

회사의 데이터 센터에 노후화된 NAS(Network-Attached Storage) 어레이가 있습니다. NAS 어레이는 SMB 공유 및 NFS 공유를 클라이언트 워크스테이션에 제공합니다. 회사는 새 NAS 어레이를 구매하기를 원하지 않습니다. 회사는 또한 NAS 어레이의 지원 계약을 갱신하는 데 드는 비용을 원하지 않습니다. 일부 데이터는 자주 액세스되지만 대부분의 데이터는 비활성 상태입니다. 솔루션 설계자는 데이터를 Amazon S3로 마이그레이션하고 S3 수명 주기 정책을 사용하며 클라이언트 워크스테이션에 대해 동일한 모양과 느낌을 유지하는 솔루션을 구현해야 합니다. 솔루션 설계자는 AWS Storage Gateway를 솔루션의 일부로 식별했습니다.

 

솔루션 설계자는 이러한 요구 사항을 충족하기 위해 어떤 유형의 스토리지 게이트웨이를 프로비저닝해야 합니까?

 

선택지

A. 볼륨 게이트웨이

B. 테이프 게이트웨이

C. Amazon FSx 파일 게이트웨이

D. Amazon S3 파일 게이트웨이

---

풀이

워크스테이션에는 기존과 같은 파일 공유 방식을 그대로 제공하면서 실제 데이터는 Amazon S3에 객체로 두고 수명 주기 정책까지 적용해야 합니다. Amazon S3 파일 게이트웨이는 SMB와 NFS 공유를 모두 제공하면서 데이터를 S3 객체로 저장하므로 이 조건을 만족합니다.

 

정답 : D

 

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

---

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

• 클라이언트 워크스테이션에 SMB와 NFS 공유를 동일하게 제공
• 데이터를 Amazon S3에 객체로 저장
• S3 수명 주기 정책을 통한 비활성 데이터 관리
• 신규 NAS 구매와 지원 계약 갱신의 회피

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

• AWS Storage Gateway : 온프레미스 환경에서 익숙한 방식으로 접근하면 그 데이터를 AWS 스토리지에 보관해 주는 하이브리드 클라우드 스토리지 서비스입니다. 온프레미스에 게이트웨이를 두고 자주 쓰는 데이터는 로컬에 캐시해 응답 속도를 확보하므로, 사용자는 클라우드에 저장되고 있다는 사실을 의식하지 않고 기존과 같은 방식으로 파일을 다룰 수 있습니다. 제공하는 접근 방식에 따라 여러 유형으로 나뉩니다.
  • Amazon S3 파일 게이트웨이 : NFS와 SMB 프로토콜로 파일 공유를 제공하며, 저장된 파일을 Amazon S3의 객체로 보관합니다. 객체로 저장되므로 S3 수명 주기 정책이나 버전 관리 같은 기능을 그대로 적용할 수 있습니다.
  • Amazon FSx 파일 게이트웨이 : SMB 프로토콜로 Amazon FSx for Windows File Server에 저지연 접근을 제공하며, 데이터는 S3 객체가 아니라 FSx 파일 시스템에 저장됩니다.
  • 볼륨 게이트웨이 : iSCSI 블록 볼륨을 제공하는 유형으로, 데이터는 Amazon EBS 스냅샷 형태로 보관되어 파일 단위 객체 관리와는 성격이 다릅니다.
  • 테이프 게이트웨이 : 기존 백업 소프트웨어가 인식하는 가상 테이프 라이브러리를 제공하며, 장기 보관용 아카이브 백업에 사용합니다.
• Amazon S3(Simple Storage Service) : 파일을 객체 단위로 저장하는 오브젝트 스토리지 서비스로, 용량 제한 없이 사용한 만큼만 요금을 냅니다. 접근 빈도에 따라 여러 스토리지 클래스를 선택할 수 있으며, 수명 주기 정책을 설정하면 일정 기간이 지난 객체를 자동으로 저렴한 클래스로 옮기거나 삭제하도록 만들 수 있습니다. 자주 쓰이지 않는 데이터의 보관 비용을 낮추는 데 효과적이며, 접근 패턴이 일정하지 않을 때 자동으로 계층을 조정해 주는 Intelligent-Tiering 클래스도 제공합니다.

3. 선택지 분석하기

A. 볼륨 게이트웨이

→ iSCSI 블록 볼륨을 제공해 파일 공유 형태로 쓰기 어렵습니다.

 

B. 테이프 게이트웨이

→ 백업 소프트웨어용 가상 테이프라 일상 파일 공유 용도가 아닙니다.

 

C. Amazon FSx 파일 게이트웨이

→ SMB만 제공하고 데이터가 FSx에 저장돼 S3 수명 주기를 못 씁니다.

 

D. Amazon S3 파일 게이트웨이

→ SMB·NFS를 그대로 제공하며 S3 객체로 저장해 수명 주기까지 적용되는 표준 방식입니다.

---

 

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

---

문제3

회사는 고유한 이벤트를 별도의 리더보드, 매치메이킹 및 인증 서비스로 동시에 전송해야 하는 게임 시스템을 구축하고 있습니다. 회사에는 이벤트 순서를 보장하는 AWS 이벤트 기반 시스템이 필요합니다.

 

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

 

선택지

A. Amazon EventBridge 이벤트 버스

B. Amazon Simple Notification Service(Amazon SNS) FIFO 주제

C. Amazon Simple Notification Service(Amazon SNS) 표준 주제

D. Amazon Simple Queue Service(Amazon SQS) FIFO 대기열

---

풀이

하나의 이벤트를 여러 서비스에 동시에 보내는 팬아웃과 순서 보장을 동시에 만족해야 합니다. SNS FIFO 주제는 구독한 모든 대상에게 같은 이벤트를 전달하면서 메시지 그룹 단위로 순서를 지켜 주므로 두 요구를 함께 충족합니다.

 

정답 : B

 

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

---

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

• 하나의 이벤트를 세 서비스로 동시 전송
• 이벤트 순서의 보장
• 중복 없는 고유 이벤트 처리

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

• Amazon SNS(Simple Notification Service) : 하나의 메시지를 여러 수신 대상에게 한꺼번에 전달하는 발행·구독(pub/sub) 방식의 완전관리형 메시징 서비스입니다. 발행자는 주제(Topic)에 메시지를 보내기만 하면 되고, 그 주제를 구독한 대상들이 각자 같은 메시지를 받습니다. 하나의 이벤트를 여러 시스템이 동시에 처리해야 하는 팬아웃 구조를 손쉽게 구성할 수 있습니다. 구독 대상으로는 SQS 대기열과 Lambda 함수를 비롯해 HTTP 엔드포인트, 이메일, 문자 메시지 등을 지정할 수 있습니다.
  • FIFO 주제 : 메시지 그룹 단위로 발행 순서를 그대로 유지해 전달하며 중복 전달을 방지합니다. 구독 대상으로는 SQS FIFO 대기열을 연결합니다.
  • 표준 주제 : 처리량이 매우 크고 지연이 낮은 대신 순서 보장이 이루어지지 않으며 같은 메시지가 두 번 전달될 수 있습니다.
• Amazon SQS(Simple Queue Service) : 메시지를 대기열에 보관해 두었다가 소비자가 가져가도록 하는 완전관리형 메시지 대기열 서비스입니다. 보내는 쪽과 받는 쪽을 분리해 시스템의 안정성을 높이며, 한 메시지는 기본적으로 하나의 소비자가 가져가 처리하는 구조입니다. 소비자가 메시지를 가져가면 다른 소비자에게 보이지 않도록 잠시 감추는 가시성 제한 시간이 적용되고, 처리에 반복 실패한 메시지는 배달 못 한 편지 대기열로 따로 옮겨 원인을 살펴볼 수 있습니다.
  • FIFO 대기열 : 메시지 그룹 단위로 순서와 중복 없는 처리를 보장하지만, 한 대기열의 메시지를 여러 서비스가 각각 온전히 받아 가는 팬아웃 구조에는 바로 맞지 않습니다.
• Amazon EventBridge : 여러 서비스에서 발생한 이벤트를 규칙에 따라 원하는 대상으로 전달하는 서버리스 이벤트 버스 서비스입니다. 이벤트 내용에 조건을 걸어 필요한 대상에게만 보내는 세밀한 필터링과 다양한 대상 연동이 강점이며, 다른 SaaS 애플리케이션이나 사용자 정의 애플리케이션이 만들어 내는 이벤트도 함께 받아 처리할 수 있습니다. 일정에 맞춰 이벤트를 발생시키는 스케줄 기능도 제공합니다. 다만 이벤트가 전달되는 순서를 보장하지는 않습니다.

3. 선택지 분석하기

A. Amazon EventBridge 이벤트 버스

→ 여러 대상 전달은 되지만 전달 순서를 보장하지 않습니다.

 

B. Amazon Simple Notification Service(Amazon SNS) FIFO 주제

→ 구독한 모든 대상에 동시 전달하면서 순서와 중복 없는 처리를 보장하는 표준 방식입니다.

 

C. Amazon Simple Notification Service(Amazon SNS) 표준 주제

→ 동시 전달은 되지만 순서 보장이 없고 중복 전달이 생길 수 있습니다.

 

D. Amazon Simple Queue Service(Amazon SQS) FIFO 대기열

→ 순서는 보장되나 한 메시지를 한 소비자가 가져가는 구조입니다.

---

 

오늘도 함께해 주셔서 감사합니다. 연휴 뒤 첫 주, 무리하지 않는 속도로 꾸준히 가시길 응원합니다!