Q141
문제: 한 회사는 사용자에게 글로벌 속보, 지역 경보 및 날씨 업데이트를 제공하는 웹 기반 포털을 운영합니다. 포털은 정적 콘텐츠와 동적 콘텐츠를 혼합하여 각 사용자에게 개인화된 보기를 제공합니다. 콘텐츠는 ALB(Application Load Balancer) 뒤의 Amazon EC2 인스턴스에서 실행되는 API 서버를 통해 HTTPS를 통해 제공됩니다. 회사는 포털이 이 콘텐츠를 가능한 한 빨리 전 세계 사용자에게 제공하기를 원합니다. 솔루션 설계자는 모든 사용자의 대기 시간을 최소화하도록 애플리케이션을 어떻게 설계해야 합니까?
답: A. 단일 AWS 리전에 애플리케이션 스택을 배포합니다. Amazon CloudFront를 사용하여 ALB를 오리진으로 지정하여 모든 정적 및 동적 콘텐츠를 제공합니다.
핵심 지문 및 개념:
- 전 세계 사용자에게 빠른 콘텐츠 제공
- 정적 및 동적 콘텐츠 제공
- 대기 시간 최소화
사용 기술 및 개념 설명:
Amazon CloudFront:
- 개념: 글로벌 콘텐츠 전송 네트워크(CDN) 서비스로, 전 세계적으로 사용자에게 콘텐츠를 빠르게 전달합니다.
- 기능: 정적 콘텐츠 및 동적 콘텐츠 모두를 캐싱하고 전달하여 사용자 대기 시간을 최소화합니다.
- 사용 이유: ALB를 오리진으로 설정하여 전 세계 사용자에게 콘텐츠를 빠르게 제공할 수 있습니다.
Application Load Balancer (ALB):
- 개념: EC2 인스턴스와 같은 백엔드 서버에 트래픽을 분산하는 로드 밸런서입니다.
- 기능: HTTPS를 통해 정적 및 동적 콘텐츠를 제공하는 API 서버와 통합됩니다.
- 사용 이유: CloudFront와 함께 사용하여 전 세계 사용자에게 빠르게 콘텐츠를 전달할 수 있습니다.
Q142
문제: 게임 회사는 고가용성 아키텍처를 설계하고 있습니다. 애플리케이션은 수정된 Linux 커널에서 실행되며 UDP 기반 트래픽만 지원합니다. 회사는 최상의 사용자 경험을 제공하기 위해 프런트 엔드 계층이 필요합니다. 해당 계층은 대기 시간이 짧고 가장 가까운 엣지 로케이션으로 트래픽을 라우팅하고 애플리케이션 엔드포인트에 진입하기 위한 고정 IP 주소를 제공해야 합니다. 솔루션 설계자는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?
답: C. 요청을 Network Load Balancer로 전달하도록 AWS Global Accelerator를 구성합니다. EC2 Auto Scaling 그룹의 애플리케이션에 Amazon EC2 인스턴스를 사용합니다.
핵심 지문 및 개념:
- UDP 기반 트래픽 지원
- 대기 시간 최소화
- 고정 IP 주소 제공
사용 기술 및 개념 설명:
AWS Global Accelerator:
- 개념: 전 세계 사용자에게 애플리케이션을 가속화하여 성능을 최적화하는 서비스입니다.
- 기능: 고정 IP 주소를 제공하고, UDP와 TCP 트래픽 모두를 지원하며, 가장 가까운 엣지 로케이션으로 트래픽을 라우팅합니다.
- 사용 이유: UDP 기반 트래픽과 고정 IP 주소 요구 사항을 충족합니다.
Network Load Balancer (NLB):
- 개념: 높은 처리량과 낮은 지연 시간을 요구하는 애플리케이션을 위해 설계된 로드 밸런서입니다.
- 기능: TCP 및 UDP 트래픽을 처리하고, 고정 IP를 지원합니다.
- 사용 이유: Global Accelerator와 함께 사용하여 높은 성능과 낮은 지연 시간을 보장합니다.
Q143
문제: 회사에서 기존 온프레미스 모놀리식 애플리케이션을 AWS로 마이그레이션하려고 합니다. 회사는 프론트엔드 코드와 백엔드 코드를 최대한 많이 유지하려고 합니다. 그러나 회사는 응용 프로그램을 더 작은 응용 프로그램으로 나누기를 원합니다. 다른 팀에서 각 애플리케이션을 관리합니다. 회사는 운영 오버헤드를 최소화하는 확장성이 뛰어난 솔루션이 필요합니다.
답: D. Amazon Elastic Container Service(Amazon ECS)에서 애플리케이션을 호스팅합니다. Amazon ECS를 대상으로 하여 Application Load Balancer를 설정합니다.
핵심 지문 및 개념:
- 모놀리식 애플리케이션을 작은 애플리케이션으로 분할
- 운영 오버헤드 최소화
- 확장성 필요
사용 기술 및 개념 설명:
Amazon Elastic Container Service (ECS):
- 개념: 컨테이너화된 애플리케이션을 관리하고 오케스트레이션하는 서비스입니다.
- 기능: 애플리케이션을 더 작은 서비스로 나누고, 각 서비스는 독립적으로 배포 및 관리될 수 있습니다.
- 사용 이유: 운영 오버헤드를 최소화하고, 애플리케이션의 확장성을 높일 수 있습니다.
Application Load Balancer (ALB):
- 개념: EC2 인스턴스 또는 컨테이너에 트래픽을 분산하는 로드 밸런서입니다.
- 기능: ECS와 통합하여 트래픽을 여러 컨테이너에 분산합니다.
- 사용 이유: 높은 가용성과 확장성을 제공할 수 있습니다.
Q144
문제: 한 회사는 최근 글로벌 전자 상거래 애플리케이션의 데이터 저장소로 Amazon Aurora를 사용하기 시작했습니다. 대규모 보고서가 실행되면 개발자는 전자상거래 애플리케이션의 성능이 좋지 않다고 보고합니다. Amazon CloudWatch의 지표를 검토한 후 솔루션 설계자는 월별 보고서가 실행될 때 ReadIOPS 및 CPUUtilization 지표가 급증하고 있음을 발견했습니다. 가장 비용 효율적인 솔루션은 무엇입니까?
답: B. 월별 보고를 Aurora 복제본으로 마이그레이션합니다.
핵심 지문 및 개념:
- 월별 보고서 실행 시 성능 문제
- ReadIOPS 및 CPUUtilization 급증
사용 기술 및 개념 설명:
Aurora Replicas:
- 개념: Amazon Aurora 클러스터 내에서 추가적인 읽기 처리 능력을 제공하는 복제본입니다.
- 기능: 읽기 요청을 Aurora 복제본으로 분산하여 주 데이터베이스의 부하를 줄입니다.
- 사용 이유: 보고서 실행 시의 읽기 부하를 Aurora 복제본으로 분산하여 성능 문제를 해결할 수 있습니다.
Amazon CloudWatch:
- 개념: AWS 리소스 및 애플리케이션 모니터링 서비스입니다.
- 기능: 지표 수집 및 분석, 알람 설정 등을 통해 성능 문제를 조기에 파악할 수 있습니다.
- 사용 이유: 성능 저하의 원인을 파악하고 적절한 대응 방안을 모색할 수 있습니다.
Q145
문제: 회사는 단일 Amazon EC2 온디맨드 인스턴스에서 웹 사이트 분석 애플리케이션을 호스팅합니다. 분석 소프트웨어는 PHP로 작성되었으며 MySQL 데이터베이스를 사용합니다. 분석 소프트웨어, PHP를 제공하는 웹 서버 및 데이터베이스 서버는 모두 EC2 인스턴스에서 호스팅됩니다. 응용 프로그램은 바쁜 시간 동안 성능 저하 징후를 보이고 5xx 오류를 표시합니다. 회사는 애플리케이션을 원활하게 확장해야 합니다. 어떤 솔루션이 이러한 요구 사항을 가장 비용 효율적으로 충족합니까?
답: D. 데이터베이스를 Amazon Aurora MySQL DB 인스턴스로 마이그레이션합니다. 웹 애플리케이션의 AMI를 생성합니다. 시작 템플릿에 AMI를 적용합니다. 시작 템플릿으로 Auto Scaling 그룹 생성 스팟 집합을 사용하도록 시작 템플릿을 구성합니다. Auto Scaling 그룹에 Application Load Balancer를 연결합니다.
핵심 지문 및 개념:
- 성능 저하 및 5xx 오류
- 원활한 확장 필요
- 비용 효율적인 솔루션 필요
사용 기술 및 개념 설명:
Amazon Aurora MySQL:
- 개념: 고성능, 고가용성의 MySQL 호환 관리형 데이터베이스 서비스입니다.
- 기능: 자동 스케일링, 다중 AZ 배포, 읽기 전용 복제본을 통해 성능과 가용성을 높일 수 있습니다.
- 사용 이유: 성능 저하와 5xx 오류 문제를 해결할 수 있습니다.
Auto Scaling:
- 개념: EC2 인스턴스를 자동으로 확장하거나 축소하는 서비스입니다.
- 기능: 수요 변화에 따라 EC2 인스턴스의 수를 자동으로 조절하여 애플리케이션의 가용성을 유지합니다.
- 사용 이유: 바쁜 시간 동안에도 애플리케이션이 원활하게 확장되어 성능을 유지할 수 있습니다.
Spot Instances:
- 개념: AWS의 여유 컴퓨팅 용량을 저렴한 비용으로 사용할 수 있는 인스턴스입니다.
- 기능: 인스턴스가 언제든지 종료될 수 있지만, 매우 저렴한 비용으로 사용할 수 있습니다.
- 사용 이유: 비용 효율성을 높이기 위해 사용될 수 있습니다.
Q146
문제: 회사는 Application Load Balancer 뒤의 Amazon EC2 온디맨드 인스턴스 그룹에서 프로덕션 환경에서 상태 비저장 웹 애플리케이션을 실행합니다. 매일 8시간 동안 애플리케이션 사용량이 많습니다. 응용 프로그램 사용량은 보통이고 밤새 안정적입니다. 주말에는 애플리케이션 사용량이 적습니다. 이 회사는 애플리케이션의 가용성에 영향을 주지 않으면서 EC2 비용을 최소화하려고 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?
답: B. 기본 사용량 수준에 대해 예약 인스턴스를 사용합니다. 애플리케이션에 필요한 추가 용량에 대해 스팟 인스턴스를 사용합니다.
핵심 지문 및 개념:
- 기본 사용량과 추가 용량 구분
- 비용 절감 필요
- 가용성 유지
사용 기술 및 개념 설명:
예약 인스턴스 (Reserved Instances):
- 개념: 특정 기간 동안(1년 또는 3년) 인스턴스를 예약하여 할인된 요금으로 사용할 수 있는 EC2 인스턴스입니다.
- 기능: 기본 사용량이 예상 가능할 때 비용을 절감할 수 있습니다.
- 사용 이유: 기본 사용량 수준에 대해 예약 인스턴스를 사용하면, 매일 8시간 동안의 높은 사용량과 주말의 적은 사용량에도 안정적으로 운영할 수 있습니다.
스팟 인스턴스 (Spot Instances):
- 개념: AWS의 여유 컴퓨팅 용량을 저렴한 가격에 사용할 수 있는 인스턴스입니다.
- 기능: 필요할 때 추가 용량을 저렴하게 사용할 수 있지만, AWS의 필요에 따라 언제든지 인스턴스가 종료될 수 있습니다.
- 사용 이유: 추가 용량을 필요로 할 때 비용을 절감할 수 있는 가장 경제적인 옵션입니다.
Q147
문제: 회사는 중요한 애플리케이션에 대한 애플리케이션 로그 파일을 10년 동안 보관해야 합니다. 애플리케이션 팀은 문제 해결을 위해 지난 달의 로그에 정기적으로 액세스하지만 1개월 이상 된 로그는 거의 액세스하지 않습니다. 애플리케이션은 매월 10TB 이상의 로그를 생성합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 스토리지 옵션은 무엇입니까?
답: B. Amazon S3에 로그를 저장합니다. S3 수명 주기 정책을 사용하여 1개월 이상 된 로그를 S3 Glacier Deep Archive로 이동합니다.
핵심 지문 및 개념:
- 1개월 동안 자주 액세스, 그 이후로는 거의 액세스하지 않음
- 비용 효율성 필요
- 장기 보관 필요
사용 기술 및 개념 설명:
Amazon S3:
- 개념: 확장 가능하고 내구성이 뛰어난 객체 스토리지 서비스입니다.
- 기능: 다양한 스토리지 클래스를 제공하여 데이터를 저장하고 필요에 따라 접근할 수 있습니다.
- 사용 이유: 로그를 저장하고 1개월 후에 비용 효율적인 스토리지 클래스로 이동할 수 있습니다.
S3 수명 주기 정책:
- 개념: 객체의 수명 주기를 정의하여 특정 조건에 따라 스토리지 클래스를 변경할 수 있는 정책입니다.
- 기능: 일정 기간이 지나면 데이터를 자동으로 저렴한 스토리지 클래스로 이동합니다.
- 사용 이유: 1개월이 지난 로그를 자동으로 S3 Glacier Deep Archive로 이동하여 비용을 절감할 수 있습니다.
S3 Glacier Deep Archive:
- 개념: S3의 가장 저렴한 스토리지 클래스 중 하나로, 장기 보관을 위한 데이터 아카이빙에 적합합니다.
- 기능: 저비용으로 데이터를 장기 보관하지만, 접근 시간은 길어집니다.
- 사용 이유: 자주 접근하지 않는 데이터를 장기 보관하는 데 최적의 선택입니다.
Q148
문제: 회사에는 다음 구성 요소를 포함하는 데이터 수집 워크플로가 있습니다. 새로운 데이터 전송에 대한 알림을 받는 Amazon Simple Notation Service(Amazon SNS) 주제입니다. 데이터를 처리하고 저장하는 AWS Lambda 함수입니다. 네트워크 연결 문제로 인해 수집 워크플로가 때때로 실패합니다. 임기가 발생하면 회사에서 수동으로 작업을 다시 실행하지 않는 한 해당 데이터가 수집되지 않습니다. 모든 알림이 최종적으로 처리되도록 하려면 솔루션 설계자가 무엇을 해야 합니까?
답: D. Amazon Simple Queue Service(Amazon SQS) 대기열을 장애 시 대상으로 구성합니다. 대기열의 메시지를 처리하도록 Lambda 함수를 수정합니다.
핵심 지문 및 개념:
- 네트워크 연결 문제로 인해 워크플로 실패
- 모든 알림이 최종적으로 처리되어야 함
- 수동 재실행 방지
사용 기술 및 개념 설명:
Amazon SQS:
- 개념: 완전 관리형 메시지 대기열 서비스로, 애플리케이션 구성 요소 간에 메시지를 전달하고 수신할 수 있습니다.
- 기능: 메시지를 안전하게 저장하고, 실패 시에도 메시지를 유실하지 않도록 합니다.
- 사용 이유: 네트워크 연결 문제로 인해 실패한 메시지를 SQS 대기열에 저장하여 후속 처리가 가능하도록 합니다.
Dead Letter Queue (DLQ):
- 개념: 처리 실패한 메시지를 저장하는 대기열입니다.
- 기능: 재처리가 필요한 메시지를 보관하여 손실을 방지하고, 문제를 분석할 수 있습니다.
- 사용 이유: Lambda 함수가 실패한 메시지를 SQS DLQ에 저장하여 최종적으로 모든 메시지가 처리되도록 보장합니다.
Q149
문제: 회사에 이벤트 데이터를 생성하는 서비스가 있습니다. 회사는 AWS를 사용하여 이벤트 데이터를 수신하는 대로 처리하려고 합니다. 데이터는 처리 전반에 걸쳐 유지되어야 하는 특정 순서로 작성됩니다. 회사는 운영 오버헤드를 최소화하는 솔루션을 구현하려고 합니다. 솔루션 설계자는 이를 어떻게 달성해야 합니까?
답: A. 메시지를 보관할 Amazon Simple Queue Service(Amazon SQS) FIFO 대기열을 생성합니다. 대기열의 메시지를 처리하도록 AWS Lambda 함수를 설정합니다.
핵심 지문 및 개념:
- 이벤트 데이터를 특정 순서로 처리 필요
- 운영 오버헤드 최소화
사용 기술 및 개념 설명:
Amazon SQS FIFO Queue:
- 개념: First-In-First-Out 순서로 메시지를 처리하는 대기열입니다.
- 기능: 메시지 순서 보장 및 중복 제거 기능을 제공합니다.
- 사용 이유: 특정 순서로 처리되어야 하는 이벤트 데이터를 안전하게 처리할 수 있습니다.
AWS Lambda:
- 개념: 이벤트에 응답하여 코드를 실행하는 서버리스 컴퓨팅 서비스입니다.
- 기능: SQS FIFO Queue와 통합하여 메시지를 자동으로 처리할 수 있습니다.
- 사용 이유: 운영 오버헤드를 최소화하면서 특정 순서로 메시지를 처리할 수 있습니다.
Q150
문제: 회사는 온프레미스 서버에서 Amazon EC2 인스턴스로 애플리케이션을 마이그레이션하고 있습니다. 마이그레이션 설계 요구 사항의 일부로 솔루션 설계자는 인프라 메트릭 경보를 구현해야 합니다. CPU 사용률이 단기간에 50% 이상으로 증가하는 경우 회사는 조치를 취할 필요가 없습니다. 하지만 CPU 사용률이 50% 이상으로 증가하고 디스크의 읽기 IOPS가 동시에 높다면 회사에서 최대한 빨리 조치를 취해야 합니다. 솔루션 설계자는 또한 오경보를 줄여야 합니다. 솔루션 설계자는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?
답: A. 가능한 경우 Amazon CloudWatch 복합 경보를 생성합니다.
핵심 지문 및 개념:
- CPU 사용률 50% 이상 증가 및 디스크 읽기 IOPS 높음
- 오경보 줄이기
사용 기술 및 개념 설명:
Amazon CloudWatch 복합 경보 (Composite Alarms):
- 개념: 여러 경보를 조합하여 하나의 경보로 만드는 기능입니다.
- 기능: 여러 조건을 조합하여 경보를 생성함으로써 오경보를 줄이고, 실제 중요한 이벤트에만 대응할 수 있습니다.
- 사용 이유: CPU 사용률과 디스크 IOPS가 동시에 높을 때만 경보를 발생시키도록 설정하여, 불필요한 경보를 줄이고 실제 중요한 이벤트에만 대응할 수 있습니다.
Amazon CloudWatch:
- 개념: AWS 리소스와 애플리케이션 모니터링을 위한 서비스입니다.
- 기능: 지표 수집, 경보 설정, 로그 모니터링 등을 통해 리소스 상태를 실시간으로 모니터링할 수 있습니다.
- 사용 이유: 인프라 메트릭을 모니터링하고, 특정 조건이 만족될 때 경보를 발생시켜 문제를 조기에 감지하고 대응할 수 있습니다.