본문 바로가기
클라우드

SAA - C03 Examtopics Dump (#21 - 25)

by somoony 2025. 1. 15.

#021번

#021번
한 전자 상거래 회사가 AWS에서 하루에 한 번 거래하는 웹 사이트를 시작하려고 합니다. 매일 24시간 동안 정확히 하나의 제품이 판매됩니다. 회사는 피크 시간 동안 밀리초의 대기 시간으로 매시간 수백만 건의 요청을 처리할 수 있기를 원합니다.
최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?


A. Amazon S3를 사용하여 다양한 S3 버킷에서 전체 웹 사이트를 호스팅하십시오. Amazon CloudFront 배포를 추가합니다. S3 버킷을 배포 원본으로 설정합니다. Amazon S3에 주문 데이터를 저장합니다.

B. 여러 가용 영역에 걸쳐 Auto Scaling 그룹에서 실행되는 Amazon EC2 인스턴스에 전체 웹 사이트를 배포합니다. 웹 사이트 트래픽을 분산하려면 ALB(Application Load Balancer)를 추가하세요. 백엔드 API를 위한 또 다른 ALB를 추가합니다. MySQL용 Amazon RDS에 데이터를 저장합니다.

C. 컨테이너에서 실행되도록 전체 애플리케이션을 마이그레이션합니다. Amazon Elastic Kubernetes Service(Amazon EKS)에서 컨테이너를 호스팅합니다. Kubernetes Cluster Autoscaler를 사용하여 트래픽 버스트를 처리할 Pod 수를 늘리거나 줄입니다. MySQL용 Amazon RDS에 데이터를 저장합니다.

D. Amazon S3 버킷을 사용하여 웹 사이트의 정적 콘텐츠를 호스팅합니다. Amazon CloudFront 배포를 배포합니다. S3 버킷을 원본으로 설정합니다. 백엔드 API에는 Amazon API Gateway 및 AWS Lambda 함수를 사용하십시오. Amazon DynamoDB에 데이터를 저장합니다.

정답 : D

 

A : 이 방법은 정적 웹 사이트 호스팅에 적합하나, 주문 데이터 저장 방식으로 Amazon S3를 사용하면 주문 처리에 필요한 동적 기능을 수행하기 어렵습니다. S3는 정적 파일 저장에는 뛰어나지만, 실시간 트랜잭션 처리에는 부적합합니다.

 

B :  이 방법은 높은 가용성과 확장성을 제공하지만, EC2에서 서버를 운영해야 하므로 운영 오버헤드가 상대적으로 큽니다. 특히 서버 관리와 관련된 여러 가지 요소(패치, 스케일링 등)를 고려해야 합니다.

 

C :  Docker 기반 애플리케이션에서 고급 스케일링과 관리를 지원하지만, EKS는 복잡성을 증가시킬 수 있습니다. 운영 오버헤드가 큰 고려 요소가 될 수 있습니다.

 

D : 이 방법은 정적 콘텐츠를 S3에서 제공하고, API Gateway와 Lambda를 통해 동적 요청을 처리하는 구조입니다. Lambda는 서버리스 아키텍처로 최소한의 운영 오버헤드로 트래픽을 관리할 수 있습니다. 또, DynamoDB는 높은 성능을 제공하는 NoSQL 데이터베이스로 실시간 트랜잭션 처리에 적합합니다.

 

#022번

#022번
솔루션 설계자는 Amazon S3를 사용하여 새로운 디지털 미디어 애플리케이션의 스토리지 아키텍처를 설계하고 있습니다. 미디어 파일은 가용 영역이 손실되더라도 복원력이 있어야 합니다. 일부 파일은 자주 액세스되는 반면 다른 파일은 예측할 수 없는 패턴으로 거의 액세스되지 않습니다. 솔루션 설계자는 미디어 파일 저장 및 검색 비용을 최소화해야 합니다.
이러한 요구 사항을 충족하는 스토리지 옵션은 무엇입니까?

A. S3 표준

B. S3  Intelligent-Tiering (지능형 계층화)

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

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

 

정답: B

 

A : 특징: 이 옵션은 자주 액세스되는 데이터를 위한 스토리지입니다. 높은 내구성과 가용성을 제공하지만, 비용이 가장 비쌉니다. 자주 액세스되지 않는 데이터를 저장할 때 비용 면에서 비효율적일 수 있습니다

 

B : 특징: 이 옵션은 파일에 대한 액세스 패턴을 자동으로 분석하여 적절한 스토리지 클래스로 이동하는 방식입니다. 자주 사용되는 파일은 S3 표준에 저장되고, 거의 사용되지 않는 파일은 S3 Standard-IA로 이동하여 비용을 절감할 수 있습니다. 이 옵션은 가용 영역 손실에 대한 복원력도 제공합니다

 

C : 특징: 이 스토리지 클래스는 자주 액세스되지 않는 데이터를 위한 스토리지입니다. 높은 내구성과 가용성을 제공하지만, 자주 접근하는 데이터에 대해서는 비효율적입니다. 여전히 다중 가용 영역에 걸쳐 복원력이 제공됩니다.

 

D : 특징: 이 옵션은 자주 액세스되지 않는 데이터에 적합하지만, 단일 가용 영역에 저장되므로 가용 영역 손실에 대한 복원력이 없습니다. 이는 데이터의 복원력을 보장할 수 없기 때문에 본 문제의 요구 사항을 충족하지 않습니다.

 

 

B 인 이유는 이 스토리지 옵션이 자주 액세스되는 파일과 덜 액세스되는 파일을 자동으로 관리하여 비용 효율성을 극대화하며, 가용 영역 손실에도 대비한 복원력을 제공하기 때문입니다. 자주 액세스되는 파일은 필요한 때에 빠르게 접근할 수 있고, 가끔 사용되는 파일은 더 저렴한 스토리지 계층으로 이동하여 비용을 절감할 수 있습니다.

 

리전 가용영역의 차이점 : 참고 자료 https://zigispace.net/1116

 

리전(Region)과 가용영역(Availability zone)

리전(Region)과 가용영역(Availability zone) 클라우드 관련 기사를 접하다보면 “서울 리전 추가” 혹은 “가용 영역 장애”와 같은 기사를 보게 됩니다. ‘리전(region)’과 ‘가용영역(availability zone)’

zigispace.net

 

 

#023번

#023번
한 회사에서 Amazon S3 Standard 스토리지를 사용하여 백업 파일을 저장하고 있습니다. 해당 파일은 1개월간 자주 접속됩니다. 단, 1개월이 지나면 해당 파일에 접근할 수 없습니다. 회사는 해당 파일을 무기한 보관해야 합니다.
이러한 요구 사항을 가장 비용 효율적으로 충족하는 스토리지 솔루션은 무엇입니까?

A. 객체를 자동으로 마이그레이션하도록 S3 Intelligent-Tiering을 구성합니다.

B. Create an S3 Lifecycle configuration to transition objects from S3 Standard to S3 Glacier Deep Archive after 1 month.

C. 1개월 후에 객체를 S3 Standard에서 S3 Standard-Infrequent Access(S3 Standard-IA)로 전환하기 위한 S3 수명 주기 구성을 생성합니다.

D. 1개월 후에 객체를 S3 Standard에서 S3 One Zone-Infrequent Access(S3 One Zone-IA)로 전환하기 위한 S3 수명 주기 구성을 생성합니다.

 

정답 : B

 

A : S3 Intelligent-Tiering은 액세스 패턴에 따라 객체를 자동으로 적절한 스토리지 클래스로 이동시킵니다. 그러나 1개월 후에는 파일에 접근할 필요가 없기 때문에, 자주 사용하는 데이터가 아닌 경우 이 방식은 비용 효율적이지 않을 수 있습니다.

 

B : S3 Glacier Deep Archive는 장기 보관을 위해 매우 저렴한 비용으로 설계되었습니다. 파일이 1개월 동안 자주 접근된 후 더 이상 접근할 필요가 없다면, 이 솔루션이 비용 효율적입니다. Glacier Deep Archive로의 전환은 무기한 보관 및 비용 절감에 적합합니다.

 

C : S3 Standard-IA는 자주 사용되지 않는 데이터에 대한 스토리지로 설계되었습니다. 그러나 임의로 보관하기에는 비용이 더 높기 때문에 장기 보관이 필요한 경우 적합하지 않습니다. 또한, 1개월 후에 접근이 전혀 필요 없는 경우 더 이상 사용하지 않아야 합니다.

 

D : S3 One Zone-IA는 자주 액세스되지 않는 데이터에 대해 저렴한 비용으로 제공되지만, 단일 가용 영역에만 저장되므로 가용성이 떨어집니다. 데이터의 무기한 보관 및 복원력 면에서 최적의 선택이 아닙니다.

 

 

#024번

#024번
한 회사가 가장 최근 청구서에서 Amazon EC2 비용이 증가한 것을 확인했습니다. 청구 팀은 몇 개의 EC2 인스턴스에 대해 원치 않는 인스턴스 유형의 수직적 확장을 발견했습니다. 솔루션 아키텍트는 지난 2개월간 EC2 비용을 비교하는 그래프를 작성하고 심층 분석을 수행하여 수직 확장의 근본 원인을 파악해야 합니다. 솔루션 설계자는 운영 오버헤드를 최소화하면서 어떻게 정보를 생성해야 합니까?

A. AWS 예산을 사용하여 예산 보고서를 생성하고 인스턴스 유형에 따라 EC2 비용을 비교하십시오.

B. Cost Explorer의 세분화된 필터링 기능을 사용하여 인스턴스 유형을 기반으로 EC2 비용에 대한 심층 분석을 수행합니다.

C. AWS Billing and Cost Management 대시보드의 그래프를 사용하여 지난 2개월 동안 인스턴스 유형을 기준으로 EC2 비용을 비교합니다.

D. Use AWS Cost and Usage Reports to create a report and send it to an Amazon S3 bucket. Use Amazon QuickSight with Amazon S3 as a source to generate an interactive graph based on instance types.

정답 : B

 

A : AWS 예산은 비용을 예측하고 관리하는 데 유용하지만, 특정 인스턴스 유형에 대한 상세한 분석을 제공하지 않습니다. 따라서 심층 분석을 수행하기에는 적합하지 않습니다.

 

B : AWS Cost Explorer는 사용자가 비용 및 사용 추세를 분석하는 데 필요한 다양한 필터링 도구를 제공합니다. 인스턴스 유형별로 EC2 비용을 심층적으로 분석할 수 있으며, 지난 2개월 동안의 비용을 시각적으로 비교할 수 있습니다. 이 과정은 운영 오버헤드도 최소화합니다.

 

C : AWS 청구 및 비용 관리 대시보드도 비용을 시각적으로 보여줄 수 있지만, 특정 인스턴스 유형에 대한 심층 분석 기능이 제한적입니다. 따라서 보다 상세한 분석을 요구하는 경우 적합하지 않습니다.

 

D : AWS Cost and Usage Reports는 매우 상세한 사용 및 비용 데이터 보고서를 제공합니다. 하지만, S3에 저장하고 QuickSight로 시각화하는 과정은 추가적인 설정 및 관리 작업이 필요합니다. 이는 운영 오버헤드를 증가시킬 수 있습니다.

 

 

Cost Explorer :

- AWS 비용관리 및 사용량 보고 분석

- 최대 지난 12개월간의 데이터를 보고 이후 12개월 동안의 지출에 대한 금액 예측 가능

- Cost Explorer API를 이용하여 데이터 액세스 가능 (페이지 지정 API 1건당 0.01 USD 과금)

 

AWS Billing and Cost Management

 

AWS Billing and Cost Management 서비스는 AWS 사용자가 소비한 클라우드 리소스에 대한 비용을 모니터링하고 관리할 수 있도록 도와주는 서비스입니다. 이 서비스를 사용하면 AWS 비용 및 사용량에 대한 상세한 정보를 확인하고, 예산을 설정하고 모니터링하며, 비용을 최적화하며, 예산을 설정하여 예상치 못한 비용을 방지할 수 있습니다. 이는 클라우드 리소스를 효율적으로 사용하고 비용을 관리하는 데 도움이 됩니다.

AWS Billing and Cost Management 서비스의 주요 기능은 다음과 같습니다:

  • 비용 대시보드: AWS Management Console에서 제공되는 비용 대시보드를 통해 현재 비용 및 사용량에 대한 간략한 개요를 확인할 수 있습니다. 이 대시보드는 비용의 주요 구성 요소 및 예산 초과 알림을 표시합니다.
  • 사용량 보고서: 다양한 사용량 보고서를 통해 특정 기간 동안의 리소스 사용량 및 비용에 대한 세부 정보를 확인할 수 있습니다. 이를 통해 어떤 서비스 및 리소스에서 비용이 발생했는지를 파악할 수 있습니다.
  • 예산 및 알림: 예산을 설정하고 모니터링하여 특정 금액에 도달하거나 초과할 때 알림을 받을 수 있습니다. 이를 통해 예상치 못한 비용 증가를 방지하고 제어할 수 있습니다.
  • 비용 최적화 권장 사항: AWS는 비용 최적화를 위한 권장 사항을 제공하여 효율적으로 리소스를 사용할 수 있도록 도움을 줍니다.
  • 가격 계산기: AWS의 가격 계산기를 사용하여 특정 서비스 및 리소스의 사용에 따른 비용을 추정할 수 있습니다.
  • 비용 액세스 및 권한 관리: AWS IAM(Identity and Access Management)을 사용하여 비용 및 사용량 정보에 대한 액세스 및 권한을 관리할 수 있습니다.
  • 리포트 및 API 액세스: 월간 및 사용량 리포트를 생성하고, AWS Cost Explorer API를 사용하여 비용 및 사용량 데이터에 프로그래밍 방식으로 액세스할 수 있습니다.

 

 

#025번

#025번
회사에서 애플리케이션을 설계하고 있습니다. 애플리케이션은 AWS Lambda 함수를 사용하여 Amazon API Gateway를 통해 정보를 수신하고 해당 정보를 Amazon Aurora PostgreSQL 데이터베이스에 저장합니다.
개념 증명 단계에서 회사는 데이터베이스에 로드해야 하는 대량의 데이터를 처리하기 위해 Lambda 할당량을 크게 늘려야 합니다. 솔루션 설계자는 확장성을 향상하고 구성 노력을 최소화하기 위해 새로운 디자인을 권장해야 합니다.
어떤 솔루션이 이러한 요구 사항을 충족합니까?

A. Amazon EC2 인스턴스에서 실행되는 Apache Tomcat 코드로 Lambda 함수 코드를 리팩터링합니다. 기본 JDBC(Java Database Connectivity) 드라이버를 사용하여 데이터베이스를 연결합니다.

B. 플랫폼을 Aurora에서 Amazon DynamoDProvision DynamoDB Accelerator(DAX) 클러스터로 변경합니다. DAX 클라이언트 SDK를 사용하여 DAX 클러스터에서 기존 DynamoDB API 호출을 가리킵니다.

C. Set up two Lambda functions. Configure one function to receive the information. Configure the other function to load the information into the database. Integrate the Lambda functions by using Amazon Simple Notification Service (Amazon SNS).

D. 두 개의 Lambda 함수를 설정합니다. 정보를 수신하는 하나의 기능을 구성하십시오. 정보를 데이터베이스에 로드하도록 다른 기능을 구성하십시오. Amazon Simple Queue Service(Amazon SQS) 대기열을 사용하여 Lambda 함수를 통합합니다.

정답 : D

 

A :  Lambda 대신 EC2를 사용하면 서버 관리 및 유지보수 오버헤드가 필요합니다. 서버리스 아키텍처의 장점을 상실하게 되며, 확장성과 관리의 용이성이 떨어질 수 있습니다.

 

B : 이 솔루션은 Aurora PostgreSQL을 DynamoDB로 변경하는 것인데, 이는 데이터베이스 구조나 요구 사항이 변경되므로 적합하지 않을 수 있습니다. 기존 데이터베이스와의 호환성이 필요합니다.

 

C : 이 방법은 두 개의 Lambda 함수를 사용하여 데이터 수신과 로드를 분리하여 확장성을 제공할 수 있지만, SNS는 메시지를 송신하고 수신하는 데 적합한 방법이지 데이터 로드에는 적합하지 않을 수 있습니다.

 

D : 이 방법은 두 개의 Lambda 함수를 사용하여 하나는 정보를 수신하고, 다른 하나는 SQS에서 메시지를 처리하여 데이터를 데이터베이스에 로드합니다. SQS는 비동기 처리를 지원하며, 대량의 요청을 효과적으로 처리할 수 있습니다. 이를 통해 확장성과 구성의 유연성을 높일 수 있습니다.

 

D 인 이유는 D 옵션이 두 개의 Lambda 함수를 설정하고, SQS를 사용하여 비동기적이고 안정적인 메시지 전송 및 처리 기능을 제공하기 때문입니다. 이렇게 하면 대량의 데이터 처리가 가능하며, Lambda 할당량을 넘지 않고도 확장할 수 있습니다.

 

 

프로비저닝

:프로비저닝은 IT 인프라를 생성하고 설정하는 프로세스로서, 다양한 리소스에 대한 사용자 및 시스템 액세스를 관리하는 데 필요한 단계를 포함합니다. 프로비저닝은 서버, 애플리케이션, 네트워크 구성, 스토리지, 엣지 기기 등을 배포하는 과정에서 초기 단계에 해당합니다

 

 

Apache Tomcat

아파치 톰캣으로 부르는 이유?

기본적으로 위처럼 아파치 톰캣의 기능은 나뉘어져 있지만,
톰캣 안에 있는 컨테이너를 통해 일부 아파치의 기능을 발휘하기 때문에
보통 아파치 톰캣으로 합쳐서 부르곤 한다.

요약

아파치 - 아파치 소프트웨어 단체
아파치 서버 - 정적인 파일 처리해주는 웹 서버 (80 포트)
톰캣 - DB처리와 같은 동적인 기능들을 가공하여 HTML파일로 만들어 클라이언트에게 제공(8080 포트)