AWS SAA 합격으로 가는 길 #16

안녕하세요! 넥스트클라우드의 SA 손유림입니다. 😊

 

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

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

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

3. 선택지 분석하기

 

바로 문제 풀이 해볼까요?

---

문제1

회사는 월 단위로 통화 기록 파일을 저장합니다.

사용자는 통화 후 1년 이내에 임의로 파일에 엑세스하지만 1년 후에는 드물게 파일에 액세스합니다.

이 회사는 사용자에게 1년 미만의 파일을 가능한 한 빨리 쿼리하고 검색할 수 있는 기능을 제공하여 솔루션을 최적화하려고 합니다.

이전 파일 검색 지연은 허용됩니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

선택지

A. Amazon S3 Glacier Instant Retrieval에 태그가 있는 개별 파일을 저장합니다. 태그를 쿼리하여 S3 Glacier Instant Retrieval에서 파일을 검색합니다.

B. Amazon S3 Intelligent-Tiering에 개별 파일을 저장합니다. S3 수명 주기 정책을 사용하여 1년 후 파일을 S3 Glacier Flexible Retrieval로 이동합니다. Amazon Athena를 사용하여 Amazon S3에 있는 파일을 쿼리하고 검색합니다. S3 Glacier Select를 사용하여 S3 Glacier에 있는 파일을 쿼리하고 검색합니다.

C. Amazon S3 Standard 스토리지에 태그가 있는 개별 파일을 저장합니다. Amazon S3 Standard 스토리지의 각 아카이브에 대한 검색 메타데이터를 저장합니다. S3 수명 주기 정책을 사용하여 1년 후 파일을 S3 Glacier Instant Retrieval로 이동합니다. Amazon S3에서 메타데이터를 검색하여 파일을 쿼리하고 검색합니다.

D. Amazon S3 Standard 스토리지에 개별 파일을 저장합니다. S3 수명 주기 정책을 사용하여 1년 후 파일을 S3 Glacier Deep Archive로 이동합니다. Amazon RDS에 검색 메타데이터를 저장합니다. Amazon RDS에서 파일을 쿼리합니다. S3 Glacier Deep Archive에서 파일을 검색합니다.

---

풀이

가장 적합한 해결책은 Amazon S3 Intelligent-Tiering을 사용하는 것입니다. 이 서비스는 데이터 접근 패턴을 자동으로 분석하여 가장 적절한 스토리지 계층에 데이터를 저장합니다. 1년 동안은 자주 접근하는 데이터로 간주되어 빠른 접근이 가능한 계층에 저장될 것입니다. 1년이 지난 후 S3 수명 주기 정책을 통해 S3 Glacier Flexible Retrieval로 데이터를 이동시키면 자주 접근하지 않는 오래된 데이터의 저장 비용을 크게 줄일 수 있어요.

데이터 검색을 위해서는 Amazon Athena를 사용합니다. Athena는 S3에 저장된 데이터를 SQL 쿼리로 빠르게 검색할 수 있게 해 줍니다. 1년이 지나 Glacier로 이동한 데이터는 S3 Glacier Select를 사용하여 검색합니다. 이 기능을 통해 전체 파일을 복원하지 않고도 필요한 데이터만 효율적으로 검색할 수 있어요.

정답 : B

 

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

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

• 1년 이내의 파일에 자주 접근하지만 1년 이후의 파일에는 드물게 접근
• 1년 미만의 파일은 빠르게 검색할 수 있어야 하며, 1년 이상된 파일은 검색 지연 허용
• 비용 효율적

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

S3(Simple Storage Service)는 확장성이 뛰어난 객체 스토리지 서비스로, 데이터를 버킷에 저장하고 관리할 수 있게 해 줍니다. 다양한 스토리지 클래스를 제공하여 데이터 접근 빈도와 비용 효율성을 고려한 저장소 선택이 가능해요. 

아래 표는 모든 보기에 언급된 스토리지 클래스만 가져와 정리했어요.
전체 스토리지 클래스가 궁금하신 분은 Amazon S3 스토리지 클래스 비교 (👈 클릭) 참고해 주세요.

스토리지 클래스	설계	최소 스토리지 기간
S3 Intelligent-Tiering	알 수 없거나 변경되거나 예측할 수 없는 액세스 패턴이 있는 데이터	없음
S3 Glacier Instant Retrieval	밀리초 단위의 액세스로 분기에 한 번 액세스하는 수명이 긴 아카이브 데이터	90일
S3 Glacier Flexible Retrieval	몇 분에서 몇 시간의 검색 시간으로 1년에 한 번 액세스하는 수명이 긴 아카이브 데이터	90일
S3 Glacier Deep Archive	몇 시간의 검색 시간으로 1년에 한 번 미만 액세스하는 수명이 긴 아카이브 데이터	180일
S3 Standard	자주 액세스하는 데이터(한 달에 한 번 이상), 밀리초 단위의 액세스	없음

 

S3 Intelligent-Tiering은 데이터 접근 패턴을 자동으로 모니터링하고 가장 비용 효율적인 스토리지 계층으로 데이터를 이동시키는 S3의 스토리지 클래스입니다. 이 서비스는 자주 접근하는 데이터와 드물게 접근하는 데이터를 자동으로 구분하여 관리해요. 하지만 1년 이상 지난 데이터에 대해서는 더욱 비용 효율적인 저장 방법이 필요합니다.

 

S3 Glacier Flexible Retrieval은 자주 접근하지 않는 데이터를 저비용으로 장기 보관할 수 있는 스토리지 클래스입니다. 이 서비스는 1년 이상된 데이터를 저장하기에 적합하며, 필요시 데이터를 검색할 수 있습니다. 검색에는 약간의 시간이 소요되지만, 비용 효율적입니다. 

 

이러한 두 스토리지 클래스 간의 자동 전환을 위해 S3 수명 주기 정책을 활용할 수 있습니다. S3 수명 주기 정책은 S3에서 객체의 수명 주기를 자동으로 관리할 수 있게 해주는 기능입니다. 이 정책을 사용하면 객체의 저장 기간, 접근 빈도 등에 따라 다른 스토리지 클래스로 자동 이동하거나 삭제할 수 있어요. 수명 주기 정책의 주요 특징은 다음과 같습니다:

1. 스토리지 클래스 전환: 예를 들어, 1년이 지난 객체를 S3 Glacier Flexible Retrieval로 이동하는 규칙 설정
2. 객체 만료: 특정 기간이 지난 후 객체를 자동으로 삭제
3. 버전 관리: 버전 관리가 활성화된 버킷에서는 이전 버전의 객체에 대해서도 수명 주기 규칙 적용 
4. 필터링: 객체의 접두사(prefix)나 태그를 기반으로 특정 객체 그룹에만 규칙 적용 

이렇게 데이터 저장 방식이 결정되었다면, 효율적인 검색 방법이 필요합니다. Athena는 표준 SQL을 사용하여 S3에 저장된 데이터를 직접 분석할 수 있는 대화형 쿼리 서비스입니다. Athena를 사용하면 S3에 저장된 1년 미만의 데이터를 빠르게 쿼리하고 검색할 수 있습니다.

 

1년 이상 지난 파일에 대해서는 S3 Glacier Select가 유용해요. S3 Glacier Select는 S3 Glacier에 저장된 데이터를 전체 파일을 복원하지 않고도 SQL 쿼리를 사용하여 필요한 데이터만 검색할 수 있는 기능입니다. 

3. 선택지 분석하기

A. Amazon S3 Glacier Instant Retrieval에 태그가 있는 개별 파일을 저장합니다. 태그를 쿼리하여 S3 Glacier Instant Retrieval에서 파일을 검색합니다.

→ 빠른 검색이 가능하지만, 모든 파일에 대해 높은 비용이 발생하여 비용 효율성이 떨어집니다.

 

B. Amazon S3 Intelligent-Tiering에 개별 파일을 저장합니다. S3 수명 주기 정책을 사용하여 1년 후 파일을 S3 Glacier Flexible Retrieval로 이동합니다. Amazon Athena를 사용하여 Amazon S3에 있는 파일을 쿼리하고 검색합니다. S3 Glacier Select를 사용하여 S3 Glacier에 있는 파일을 쿼리하고 검색합니다.

 

C. Amazon S3 Standard 스토리지에 태그가 있는 개별 파일을 저장합니다. Amazon S3 Standard 스토리지의 각 아카이브에 대한 검색 메타데이터를 저장합니다. S3 수명 주기 정책을 사용하여 1년 후 파일을 S3 Glacier Instant Retrieval로 이동합니다. Amazon S3에서 메타데이터를 검색하여 파일을 쿼리하고 검색합니다.

→ 메타데이터를 통해 빠른 검색이 가능하지만, 초기 1년간 높은 스토리지 비용이 발생합니다.

→ "메타데이터"란 데이터를 설명하는 데이터예요. 예를 들어, 휴대폰으로 사진을 찍으면 사진에 대한 메타데이터는 날짜 및 시간, 파일 크기, 이미지 크기 등이 될 수 있어요.

 

D. Amazon S3 Standard 스토리지에 개별 파일을 저장합니다. S3 수명 주기 정책을 사용하여 1년 후 파일을 S3 Glacier Deep Archive로 이동합니다. Amazon RDS에 검색 메타데이터를 저장합니다. Amazon RDS에서 파일을 쿼리합니다. S3 Glacier Deep Archive에서 파일을 검색합니다.

→ 장기 보관 시 매우 저렴하지만, Glacier Deep Archive의 긴 검색 시간으로 인해 요구사항을 충족시키지 못합니다.

 

 

이어서 다음 문제입니다.

---

문제2

한 회사에서 사용자가 작은 파일을 Amazon S3에 업로드하는 애플리케이션을 설계하고 있습니다.

사용자가 파일을 업로드한 후 파일은 나중에 분석할 수 있도록 데이터를 변환하고 데이터를 JSON 형식으로 저장하는 일회성 간단한 처리가 필요합니다. 각 파일은 업로드된 후 가능한 한 빨리 처리되어야 합니다. 수요는 다양할 것입니다.

어떤 날에는 사용자가 많은 수의 파일을 업로드합니다. 다른 날에는 사용자가 몇 개의 파일을 업로드하거나 파일을 전혀 업로드하지 않습니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

선택지

A. Amazon S3에서 텍스트 파일을 읽도록 Amazon EMR을 구성합니다. 처리 스크립트를 실행하여 데이터를 변환합니다. 결과 JSON 파일을 Amazon Aurora DB 클러스터에 저장합니다.

B. 이벤트 알림을 Amazon Simple Queue Service(Amazon SQS) 대기열로 보내도록 Amazon S3를 구성합니다. Amazon EC2 인스턴스를 사용하여 대기열에서 읽고 데이터를 처리합니다. 결과 JSON 파일을 Amazon DynamoDB에 저장합니다.

C. 이벤트 알림을 Amazon Simple Queue Service(Amazon SQS) 대기열로 보내도록 Amazon S3를 구성합니다. AWS Lambda 함수를 사용하여 대기열에서 읽고 데이터를 처리합니다. 결과 JSON 파일을 Amazon DynamoDB에 저장합니다.

D. 새 파일이 업로드되면 Amazon Kinesis Data Streams로 이벤트를 보내도록 Amazon EventBridge(Amazon CloudWatch Events)를 구성합니다. AWS Lambda 함수를 사용하여 스트림에서 이벤트를 소비하고 데이터를 처리합니다. 결과 JSON 파일을 Amazon Aurora DB 클러스터에 저장합니다.

---

풀이

S3에 파일이 업로드되면 이벤트 알림이 SQS 대기열로 전송됩니다. 이 대기열은 버퍼 역할을 하여 갑작스러운 대량의 업로드도 안정적으로 처리할 수 있습니다. Lambda 함수는 이 대기열에서 메시지를 읽어 파일을 처리하고 JSON 형식으로 변환합니다. Lambda는 서버리스이므로 운영 오버헤드가 최소화되며, 수요에 따라 자동으로 확장됩니다. 처리된 데이터는 DynamoDB에 저장되는데, DynamoDB는 NoSQL 데이터베이스로 JSON 형식의 데이터를 저장하기에 적합해요.

정답 : C

 

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

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

• 파일의 일회성 간단한 처리 필요 (데이터 변환, JSON 저장)
• 다양한 수요 
• 최소한의 운영 오버헤드

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

S3(Simple Storage Service)는 확장성이 뛰어난 객체 스토리지 서비스로, 데이터를 버킷에 저장하고 관리할 수 있게 해 줍니다. S3는 높은 내구성과 가용성을 제공하며, 다양한 사용 사례에 적합합니다. 이벤트 알림 기능을 통해 파일 업로드 시 다른 서비스를 트리거할 수 있기 때문에 S3는 데이터 처리 워크플로우의 시작점으로 자주 사용됩니다.

 

SQS(Simple Queue Service)는 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 쉽게 분리하고 확장할 수 있게 해주는 완전관리형 메시지 대기열 서비스입니다. SQS는 메시지의 손실 없이 안정적인 전달을 보장하며, 시스템 간의 결합도를 낮추고, 처리량의 변동에 대응할 수 있는 버퍼 역할을 합니다. SQS를 사용하면 부하 분산과 시스템의 탄력성을 향상할 수 있습니다.

→ "완전관리형"이란 AWS가 인프라의 운영, 유지보수, 패치 관리, 보안 업데이트 등을 담당하는 서비스를 말합니다. 사용자는 서비스의 구성과 관리에 집중할 수 있지만, 용량 계획이나 스케일링과 같은 일부 관리 작업을 수행해야 할 수 있어요. 

 

Lambda는 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있게 해주는 서버리스 컴퓨팅 서비스입니다. Lambda는 높은 가용성을 자동으로 제공하며, 사용한 컴퓨팅 시간에 대해서만 비용을 지불합니다. 다양한 AWS 서비스의 이벤트에 반응하여 실행될 수 있으며, 사용량에 따라 자동으로 확장됩니다. 간헐적이거나 변동이 심한 워크로드 처리에 적합해요.

→ "서버리스"란 완전 관리형 서비스의 개념을 한 단계 더 발전시킨 것으로, 사용자가 서버나 인스턴스에 대해 전혀 생각할 필요가 없습니다. 용량 계획, 확장, 서버 관리 등 모든 것을 AWS가 자동으로 처리해요. 사용자는 오직 코드나 데이터에만 집중하면 되는 거죠.

 

DynamoDB는 모든 규모에서 일관된 한 자릿수 밀리초 응답 시간을 제공하는 완전관리형 NoSQL 데이터베이스 서비스입니다. 자동 확장을 지원하며, 서버리스 애플리케이션에 적합해요. 구조화되지 않은 데이터를 저장하는 데 유용하며, JSON 형식의 데이터를 효율적으로 처리할 수 있습니다. 대규모의 읽기 및 쓰기 처리량을 지원합니다.

3. 선택지 분석하기

A. Amazon S3에서 텍스트 파일을 읽도록 Amazon EMR을 구성합니다. 처리 스크립트를 실행하여 데이터를 변환합니다. 결과 JSON 파일을 Amazon Aurora DB 클러스터에 저장합니다.

→ EMR은 대규모 데이터 처리에 적합하지만, 작은 파일을 빠르게 처리하는 데에는 오버헤드가 크고 비용 효율적이지 않습니다.

 

B. 이벤트 알림을 Amazon Simple Queue Service(Amazon SQS) 대기열로 보내도록 Amazon S3를 구성합니다. Amazon EC2 인스턴스를 사용하여 대기열에서 읽고 데이터를 처리합니다. 결과 JSON 파일을 Amazon DynamoDB에 저장합니다.

→ 유연하지만, EC2 인스턴스를 계속 실행해야 하므로 운영 오버헤드가 높습니다.

→ "오버헤드"란

 

C. 이벤트 알림을 Amazon Simple Queue Service(Amazon SQS) 대기열로 보내도록 Amazon S3를 구성합니다. AWS Lambda 함수를 사용하여 대기열에서 읽고 데이터를 처리합니다. 결과 JSON 파일을 Amazon DynamoDB에 저장합니다.

 

D. 새 파일이 업로드되면 Amazon Kinesis Data Streams로 이벤트를 보내도록 Amazon EventBridge(Amazon CloudWatch Events)를 구성합니다. AWS Lambda 함수를 사용하여 스트림에서 이벤트를 소비하고 데이터를 처리합니다. 결과 JSON 파일을 Amazon Aurora DB 클러스터에 저장합니다.

→ 효과적일 수 있지만, 작은 파일을 처리하는 데에는 복잡하고 오버헤드가 큽니다.

 

 

마지막 문제 살펴볼게요.

---

문제3

솔루션 아키텍트는 AWS에 배포되는 새로운 애플리케이션을 위한 클라우드 아키텍처를 설계하고 있습니다.

프로세스는 처리할 작업 수에 따라 필요에 따라 애플리케이션 노드를 추가 및 제거 하는 동안 병렬로 실행되어야 합니다.

프로세서 애플리케이션은 상태 비저장입니다. 솔루션 설계자는 애플리케이션이 느슨하게 결합되고 작업 항목이 지속적으로 저장되는지 확인해야 합니다. 솔루션 설계자는 어떤 디자인을 사용해야 합니까?

선택지

A. 처리해야 할 작업을 보낼 Amazon SNS 주제를 생성합니다. 프로세서 애플리케이션으로 구성된 Amazon 머신 이미지(AMI)를 생성합니다. AMI를 사용하는 시작 구성을 생성합니다. 시작 구성을 사용하여 Auto Scaling 그룹을 생성합니다. CPU 사용량에 따라 노드를 추가 및 제거하도록 Auto Scaling 그룹에 대한 조정 정책을 설정합니다.

B. 처리해야 하는 작업을 보관할 Amazon SQS 대기열을 생성합니다. 프로세서 애플리케이션으로 구성된 Amazon 머신 이미지(AMI)를 생성합니다. AMI를 사용하는 시작 구성을 생성합 니다. 시작 구성을 사용하여 Auto Scaling 그룹을 생성합니다. 네트워크 사용량에 따라 노드를 추가 및 제거하도록 Auto Scaling 그룹에 대한 조정 정책을 설정합니다.

C. 처리해야 할 작업을 보관할 Amazon SQS 대기열을 생성합니다. 프로세서 애플리케이션으로 구성된 Amazon 머신 이미지(AMI)를 생성합니다. AMI를 사용하는 시작 템플릿을 생성합니다. 시작 템플릿을 사용하여 Auto Scaling 그룹을 생성합니다. SQS 대기열의 항목 수에 따라 노드를 추가 및 제거하도록 Auto Scaling 그룹에 대한 조정 정책을 설정합니다.

D. 처리해야 할 작업을 보낼 Amazon SNS 주제를 생성합니다. 프로세서 애플리케이션으로 구성된 Amazon 머신 이미지(AMI)를 생성합니다. AMI를 사용하는 시작 템플릿을 생성합니다. 시작 템플릿을 사용하여 Auto Scaling 그룹을 생성합니다. SNS 주제에 게시된 메시지 수에 따라 노드를 추가 및 제거하도록 Auto Scaling 그룹에 대한 조정 정책을 설정합니다.

---

풀이

프로세서 애플리케이션으로 구성된 Amazon 머신 이미지(AMI)를 생성하고, 이를 사용하는 시작 템플릿을 만듭니다. 시작 템플릿은 일관된 구성으로 새 노드를 생성할 수 있게 해줍니다. 이 시작 템플릿을 사용하여 Auto Scaling 그룹을 생성합니다.

Auto Scaling 그룹의 조정 정책은 SQS 대기열의 항목 수에 따라 노드를 추가하거나 제거하도록 설정됩니다. 이는 실제 작업량에 따라 정확하게 스케일링할 수 있게 해 주며, 처리해야 할 작업 수에 따라 노드를 동적으로 관리해야 한다는 요구사항을 충족시켜요. 또한 SQS를 사용함으로써 작업 항목의 지속성을 보장하고, 애플리케이션 컴포넌트 간의 느슨한 결합을 실현합니다.

정답 : C 

 

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

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

• 애플리케이션은 처리할 작업 수에 따라 노드를 동적으로 추가/제거
• 프로세스는 병렬로 실행
• 애플리케이션은 상태비저장이며 느슨하게 결합
• 작업 항목은 지속적으로 저장 

→ "상태 비저장(Stateless)"이란 각 요청을 독립적으로 처리하며, 이전 요청의 정보를 저장하지 않는 특성을 말해요. 쉽게 말해, 프로그램이 이전에 무엇을 했는지 기억하지 않고 매 요청을 새롭게 처리한다고 생각하면 돼요. 

→ "느슨한 결합"이란 시스템 구성 요소 간의 의존성이 낮아 유연성과 확장성이 높은 구조예요. 마치 레고 블록과 같이 각 부품이 독립적이면서도 필요할 때 쉽게 조합할 수 있는 상태를 말해요. 시스템의 한 부분을 변경하거나 교체해도 다른 부분에 미치는 영향이 최소화되므로, 전체 시스템의 유연성과 확장성이 높아집니다. 

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

SQS(Simple Queue Service)는 완전관리형 메시지 대기열 서비스로, 분산 시스템의 구성 요소를 효과적으로 분리하고 확장할 수 있게 해 줍니다. SQS는 메시지의 손실 없이 안정적인 전달을 보장하며, 수요 변동에 따른 자동 확장을 지원합니다. 이 서비스는 작업 항목의 지속성을 보장하고 시스템 컴포넌트 간의 느슨한 결합을 가능하게 합니다.

 

EC2(Elastic Compute Cloud)는 클라우드에서 안전하고 크기 조정이 가능한 컴퓨팅 용량을 제공하는 웹 서비스입니다. EC2는 개발자가 웹 규모의 클라우드 컴퓨팅을 더 쉽게 수행할 수 있도록 설계되었습니다. SQS의 메시지를 처리하는 애플리케이션을 실행하는 가상 서버 역할을 하며, Auto Scaling과 함께 사용하여 동적 확장성 요구사항을 충족시킬 수 있습니다. 

 

EC2 인스턴스를 더욱 효율적으로 관리하기 위해 Amazon Machine Image(AMI)를 활용할 수 있습니다. AMI는 EC2 인스턴스를 시작하는 데 필요한 정보를 제공하는 AWS에서 지원하는 이미지입니다.  AMI에는 인스턴스에 대한 루트 볼륨 템플릿(예: 운영 체제, 애플리케이션 서버, 애플리케이션), 시작 권한, 그리고 시작될 때 인스턴스에 연결할 볼륨을 지정하는 블록 디바이스 매핑이 포함됩니다. AMI는 프로세서 애플리케이션이 사전 설치된 상태로 구성되어, 일관된 환경에서 새로운 EC2 인스턴스를 빠르게 시작할 수 있게 해 줘요.

 

이러한 EC2 인스턴스의 수를 자동으로 조절하기 위해 AWS Auto Scaling을 사용할 수 있습니다. Auto Scaling은 애플리케이션을 모니터링하고 용량을 자동으로 조정하여, 최적의 비용으로 안정적이고 예측 가능한 성능을 유지합니다. SQS 대기열의 메시지 수와 같은 다양한 메트릭에 기반하여 EC2 인스턴스를 동적으로 추가하거나 제거할 수 있어, 변동하는 워크로드에 효과적으로 대응할 수 있습니다. 

 

최소 크기, 최대 크기, 원하는 용량이라는 세 가지 주요 매개변수로 구성됩니다.

• 최소 크기(Minimum size) : 항상 유지해야 하는 인스턴스의 최소 수 → 애플리케이션의 기본 가용성 보장
• 최대 크기(Maximum size) : 확장될 수 있는 인스턴스의 최대 수 제한 → 비용 통제
• 원하는 용량(Desired capacity) : 현재 실행 중인 인스턴스의 수 → 최소 크기와 최대 크기 사이에서 동적으로 조정

Auto Scaling 그룹은 이러한 설정을 기반으로 트래픽 증가 시 자동으로 새 인스턴스를 추가하고, 수요가 감소하면 인스턴스를 제거하여 리소스 사용을 최적화하고 비용을 효율적으로 관리합니다. 이를 통해 사용자는 수동 개입 없이도 애플리케이션의 성능과 가용성을 일관되게 유지할 수 있죠.

3. 선택지 분석하기

A. 처리해야 할 작업을 보낼 Amazon SNS 주제를 생성합니다. 프로세서 애플리케이션으로 구성된 Amazon 머신 이미지(AMI)를 생성합니다. AMI를 사용하는 시작 구성을 생성합니다. 시작 구성을 사용하여 Auto Scaling 그룹을 생성합니다. CPU 사용량에 따라 노드를 추가 및 제거하도록 Auto Scaling 그룹에 대한 조정 정책을 설정합니다.

→ SNS는 메시지를 지속적으로 저장하지 않아 작업 항목의 지속성 요구사항을 충족하지 못합니다. 또한 CPU 사용량은 실제 작업량을 정확히 반영하지 않을 수 있어, 효율적인 스케일링이 어려울 수 있습니다.

 

B. 처리해야 하는 작업을 보관할 Amazon SQS 대기열을 생성합니다. 프로세서 애플리케이션으로 구성된 Amazon 머신 이미지(AMI)를 생성합니다. AMI를 사용하는 시작 구성을 생성합 니다. 시작 구성을 사용하여 Auto Scaling 그룹을 생성합니다. 네트워크 사용량에 따라 노드를 추가 및 제거하도록 Auto Scaling 그룹에 대한 조정 정책을 설정합니다.

→ SQS는 메시지를 지속적으로 저장하여 작업 항목의 지속성 요구사항을 충족합니다. 하지만 네트워크 사용량은 실제 작업량을 정확히 반영하지 않을 수 있어, 효율적인 스케일링이 어려울 수 있습니다.

 

C. 처리해야 할 작업을 보관할 Amazon SQS 대기열을 생성합니다. 프로세서 애플리케이션으로 구성된 Amazon 머신 이미지(AMI)를 생성합니다. AMI를 사용하는 시작 템플릿을 생성합니다. 시작 템플릿을 사용하여 Auto Scaling 그룹을 생성합니다. SQS 대기열의 항목 수에 따라 노드를 추가 및 제거하도록 Auto Scaling 그룹에 대한 조정 정책을 설정합니다.

 

D. 처리해야 할 작업을 보낼 Amazon SNS 주제를 생성합니다. 프로세서 애플리케이션으로 구성된 Amazon 머신 이미지(AMI)를 생성합니다. AMI를 사용하는 시작 템플릿을 생성합니다. 시작 템플릿을 사용하여 Auto Scaling 그룹을 생성합니다. SNS 주제에 게시된 메시지 수에 따라 노드를 추가 및 제거하도록 Auto Scaling 그룹에 대한 조정 정책을 설정합니다.

→ SNS는 메시지를 지속적으로 저장하지 않아 작업 항목의 지속성 요구사항을 충족하지 못합니다. 또한 SNS 메시지 수를 기반으로 한 Auto Scaling은 일반적이지 않고 구현이 복잡할 수 있습니다.

 

 

요즘 날씨가 너무 더운 것 같아요. 9월인데도 이렇게 덥다니...

얼른 가을 날씨가 왔으면 좋겠네요. 선선한 바람이 불어오면 공부하기에도 더 좋을 테니까요! 

오늘 하루도 새로운 지식으로 가득 채우시길 바라요. 파이팅!

 

감사합니다. 다음 글에서 만나요! 😊