AWS SAA 합격으로 가는 길 #205

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

 

9월 셋째 주 월요일입니다! 아침에 창문을 열면 서늘한 공기가 훅 들어와서 이제 정말 가을이구나 싶은 요즘입니다.

따뜻한 음료 한 잔 곁에 두고 차분히 공부하기 딱 좋은 계절이라 생각됩니다.

 

오늘도 다양한 문제 3개를 풀어보죠. 그럼 시작하겠습니다! 😊

 

 

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

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

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

3. 선택지 분석하기

 

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

---

문제1

회사는 회사의 기본 웹 사이트를 사용할 수 없는 경우 사용자를 백업 정적 오류 페이지로 안내하려고 합니다. 기본 웹 사이트의 DNS 레코드는 Amazon Route 53에서 호스팅됩니다. 도메인은 Application Load Balancer(ALB)를 가리킵니다. 회사는 변경 및 인프라 오버헤드를 최소화하는 솔루션이 필요합니다. 

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

 

선택지

A. 지연 시간 라우팅 정책을 사용하도록 Route 53 레코드를 업데이트합니다. 트래픽이 가장 반응이 빠른 엔드포인트로 전송되도록 Amazon S3 버킷에서 호스팅되는 정적 오류 페이지를 레코드에 추가합니다.
B. Route 53 활성-수동 장애 조치 구성을 설정합니다. Route 53 상태 확인에서 ALB 엔드포인트가 비정상이라고 판단하면 Amazon S3 버킷에서 호스팅되는 정적 오류 페이지로 트래픽을 보냅니다.
C. 정적 오류 페이지를 엔드포인트로 호스팅하는 Amazon EC2 인스턴스와 ALB를 사용하여 Route 53 활성-활성 구성을 설정합니다. ALB에 대한 상태 확인이 실패한 경우에만 인스턴스에 요청을 보내도록 Route 53을 구성합니다.
D. 다중값 응답 라우팅 정책을 사용하도록 Route 53 레코드를 업데이트합니다. 상태 확인을 만듭니다. 상태 확인이 통과되면 트래픽을 웹사이트로 안내합니다. 상태 확인을 통과하지 못한 경우 Amazon S3에서 호스팅되는 정적 오류 페이지로 트래픽을 보냅니다.

---

풀이

평소에는 기본 사이트로 보내다가 문제가 생겼을 때만 대체 페이지로 넘겨야 합니다. Route 53의 활성-수동 장애 조치 구성은 상태 확인 결과에 따라 자동으로 두 번째 대상으로 전환해 주고, 정적 페이지는 S3에 두면 되므로 추가로 운영할 서버가 없습니다.

 

정답 : B

 

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

---

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

• 기본 웹 사이트 장애 시 백업 정적 페이지로의 자동 전환
• 정상 상황에서는 기본 사이트로만 트래픽 전달
• 변경 범위와 인프라 오버헤드의 최소화
• 별도 서버 운영이 필요 없는 구성

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

• Amazon Route 53 : 도메인 이름을 실제 서비스 주소로 연결해 주는 완전관리형 DNS 서비스입니다. 단순히 주소를 알려 주는 데 그치지 않고, 어떤 조건에서 어느 대상으로 안내할지를 정하는 여러 라우팅 정책과 대상이 살아 있는지 주기적으로 확인하는 상태 확인 기능을 함께 제공합니다. 이 둘을 엮어 두면 대상에 문제가 생겼을 때 DNS 응답 자체를 다른 곳으로 바꿔 주므로, 앞단에 별도 장치를 두지 않고도 전환을 자동화할 수 있습니다.
  
  • 장애 조치 라우팅 정책 : 기본 대상과 보조 대상을 지정해 두고, 기본 대상의 상태 확인이 실패할 때만 보조 대상으로 응답을 바꿔 주는 활성-수동 방식입니다.
  • 지연 시간 라우팅 정책 : 사용자에게 가장 빠르게 응답하는 리전의 대상으로 보내 주는 방식이며, 대상의 정상 여부가 아니라 응답 속도를 기준으로 삼습니다.
  • 다중값 응답 라우팅 정책 : 정상인 대상 여러 개의 주소를 함께 돌려주어 클라이언트가 그중 하나를 고르게 하는 방식이며, 부하를 고루 나누는 데 쓰입니다.
• Amazon S3 (Simple Storage Service) : 파일을 객체 단위로 담아 두는 완전관리형 객체 스토리지 서비스입니다. 정적 웹 사이트 호스팅 기능을 켜면 버킷에 올려 둔 HTML과 이미지 파일을 그대로 웹 페이지로 제공할 수 있어, 서버를 준비하지 않고도 안내용 페이지를 띄울 수 있습니다. 요청이 없으면 저장 비용만 발생하고 접속이 몰려도 알아서 감당하므로, 평소에는 쓰이지 않다가 비상시에만 열리는 대체 페이지를 두기에 잘 맞습니다.
• Application Load Balancer (ALB) : 들어오는 요청을 여러 대상에 나누어 보내 주는 로드 밸런서로, 요청의 경로나 호스트 이름 같은 내용을 보고 어디로 보낼지 판단합니다. 대상의 상태를 주기적으로 확인해 문제가 있는 대상은 제외하고 보내지만, 이는 자신이 관리하는 대상 그룹 안에서의 조정입니다. 로드 밸런서 자체가 응답하지 못하는 상황까지 대비하려면 그 앞단의 DNS 계층에서 다른 대상으로 넘겨 줄 방법을 마련해야 합니다.

3. 선택지 분석하기

A. 지연 시간 라우팅 정책을 사용하도록 Route 53 레코드를 업데이트합니다. 트래픽이 가장 반응이 빠른 엔드포인트로 전송되도록 Amazon S3 버킷에서 호스팅되는 정적 오류 페이지를 레코드에 추가합니다.
→ 응답 속도를 기준으로 삼는 정책이라 기본 사이트가 정상일 때도 오류 페이지로 안내될 수 있으므로, 적절치 않습니다.

B. Route 53 활성-수동 장애 조치 구성을 설정합니다. Route 53 상태 확인에서 ALB 엔드포인트가 비정상이라고 판단하면 Amazon S3 버킷에서 호스팅되는 정적 오류 페이지로 트래픽을 보냅니다.
→ 상태 확인 결과에 따라 자동으로 대체 페이지로 넘겨 주면서 추가로 운영할 서버도 없으므로, 가장 적절한 방법입니다.

C. 정적 오류 페이지를 엔드포인트로 호스팅하는 Amazon EC2 인스턴스와 ALB를 사용하여 Route 53 활성-활성 구성을 설정합니다. ALB에 대한 상태 확인이 실패한 경우에만 인스턴스에 요청을 보내도록 Route 53을 구성합니다.
→ 오류 페이지 하나를 위해 인스턴스와 로드 밸런서를 계속 띄워 두어야 해 인프라 오버헤드가 커지므로, 요구와 맞지 않습니다.

D. 다중값 응답 라우팅 정책을 사용하도록 Route 53 레코드를 업데이트합니다. 상태 확인을 만듭니다. 상태 확인이 통과되면 트래픽을 웹사이트로 안내합니다. 상태 확인을 통과하지 못한 경우 Amazon S3에서 호스팅되는 정적 오류 페이지로 트래픽을 보냅니다.
→ 정상인 대상들에 요청을 고루 나누는 정책이라 기본과 예비의 순서를 정하는 데는 맞지 않으므로, 요구를 충족하기 어렵습니다.

---

 

이어서 다음 문제입니다.

---

문제2

솔루션 설계자는 분석 애플리케이션을 관리합니다. 애플리케이션은 Amazon S3 버킷에 대량의 반구조화된 데이터를 저장합니다. 솔루션 설계자는 병렬 데이터 처리를 사용하여 데이터를 더 빠르게 처리하려고 합니다. 또한 솔루션 설계자는 Amazon Redshift 데이터베이스에 저장된 정보를 사용하여 데이터를 보강하려고 합니다. 

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

 

선택지

A. Amazon Athena를 사용하여 S3 데이터를 처리합니다. Amazon Redshift 데이터와 함께 AWS Glue를 사용하여 S3 데이터를 보강합니다.
B. Amazon EMR을 사용하여 S3 데이터를 처리합니다. Amazon Redshift 데이터와 함께 Amazon EMR을 사용하여 S3 데이터를 보강합니다.
C. Amazon EMR을 사용하여 S3 데이터를 처리합니다. 데이터를 보강할 수 있도록 Amazon Kinesis Data Streams를 사용하여 S3 데이터를 Amazon Redshift로 이동합니다.
D. AWS Glue를 사용하여 S3 데이터를 처리합니다. Amazon Redshift 데이터와 함께 AWS Lake Formation을 사용하여 S3 데이터를 보강합니다.

---

풀이

저장된 데이터를 병렬로 훑어 처리하고, 다른 저장소의 정보를 붙여 내용을 채워야 합니다. Athena는 S3의 데이터를 그 자리에서 병렬로 질의하고, Glue는 여러 저장소를 함께 읽어 결합하는 작업을 서버 준비 없이 수행하므로 두 요구에 맞습니다.

 

정답 : A

 

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

---

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

• S3에 저장된 대량 반구조화 데이터의 병렬 처리
• 처리 속도의 향상
• Amazon Redshift에 있는 정보를 이용한 데이터 보강
• 별도 클러스터 운영 부담이 적은 구성

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

• Amazon Athena : Amazon S3에 있는 데이터를 그 자리에서 표준 SQL로 질의할 수 있게 해 주는 서버리스 질의 서비스입니다. 데이터를 다른 곳으로 옮기거나 미리 적재할 필요 없이 어떤 형식으로 저장되어 있는지만 정의해 두면 바로 조회할 수 있고, 질의가 들어오면 내부적으로 작업을 여러 갈래로 나누어 동시에 처리합니다. JSON이나 로그처럼 형태가 딱 떨어지지 않는 반구조화 데이터도 다룰 수 있으며, 준비해 둘 서버가 없어 훑은 데이터 양만큼만 요금이 부과됩니다.
• AWS Glue : 여러 곳에 흩어진 데이터를 읽어 원하는 형태로 바꾸고 다른 곳에 실어 주는 서버리스 데이터 통합 서비스입니다. 데이터가 어디에 어떤 구조로 있는지 정리해 두는 데이터 카탈로그와, 실제 변환 작업을 수행하는 작업 실행 기능으로 이루어져 있습니다. Amazon S3와 Amazon Redshift, 관계형 데이터베이스 등 여러 저장소에 연결할 수 있어, 한쪽 데이터를 다른 쪽 정보와 결합해 내용을 채워 넣는 처리에 적합합니다. 실행에 필요한 자원을 서비스가 알아서 준비하므로 클러스터를 세우고 관리할 필요가 없습니다.
• Amazon EMR : Apache Spark와 Hadoop 같은 빅데이터 처리 프레임워크를 클러스터 형태로 실행해 주는 서비스입니다. 대규모 데이터를 여러 노드에 나눠 처리하는 데 강력하고 세밀한 조정이 가능하지만, 클러스터의 크기와 구성, 실행 시점을 직접 정하고 관리해야 합니다. 클러스터를 필요할 때만 띄웠다가 작업이 끝나면 내리는 방식으로 비용을 조절할 수도 있습니다. 정교한 처리 로직이 필요할 때 유용한 선택지이며, 그만큼 운영에 손이 더 갑니다.
• Amazon Redshift : 대량의 데이터를 모아 두고 분석 질의를 처리하도록 만들어진 데이터 웨어하우스 서비스입니다. 데이터를 열 단위로 저장하고 여러 노드가 나누어 처리하는 구조라 집계와 조인이 많은 질의에서 좋은 성능을 냅니다. 기준 정보나 마스터 데이터를 이곳에 두고 다른 데이터와 결합하는 형태로도 자주 활용됩니다. 다른 저장소에 있는 데이터를 직접 조회하는 기능도 제공해 웨어하우스 안팎의 데이터를 함께 다룰 수 있으며, 규모가 커지면 노드를 늘려 처리 능력을 확장합니다.

3. 선택지 분석하기

A. Amazon Athena를 사용하여 S3 데이터를 처리합니다. Amazon Redshift 데이터와 함께 AWS Glue를 사용하여 S3 데이터를 보강합니다.
→ 저장된 자리에서 병렬로 질의하고 여러 저장소를 함께 읽어 결합하는 처리를 서버 준비 없이 수행할 수 있으므로, 가장 적절한 방법입니다.

B. Amazon EMR을 사용하여 S3 데이터를 처리합니다. Amazon Redshift 데이터와 함께 Amazon EMR을 사용하여 S3 데이터를 보강합니다.
→ 처리 자체는 가능하지만 클러스터를 세우고 관리하는 부담이 따르므로, 서버리스로 해결되는 방식보다 효율적이지 않습니다.

C. Amazon EMR을 사용하여 S3 데이터를 처리합니다. 데이터를 보강할 수 있도록 Amazon Kinesis Data Streams를 사용하여 S3 데이터를 Amazon Redshift로 이동합니다.
→ Kinesis Data Streams는 실시간으로 흘러 들어오는 데이터를 받아 내는 서비스라 이미 저장된 데이터를 옮기는 용도와는 맞지 않으므로, 적절치 않습니다.

D. AWS Glue를 사용하여 S3 데이터를 처리합니다. Amazon Redshift 데이터와 함께 AWS Lake Formation을 사용하여 S3 데이터를 보강합니다.
→ Lake Formation은 데이터 레이크를 구축하고 접근 권한을 관리하는 서비스이며 데이터를 결합해 보강하는 처리 엔진이 아니므로, 요구를 충족하기 어렵습니다.

---

 

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

---

문제3

회사는 Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터와 온프레미스 Kubernetes 클러스터 모두에서 애플리케이션을 실행합니다. 회사는 중앙 위치에서 모든 클러스터와 워크로드를 보기를 원합니다. 

최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

 

선택지

A. Amazon CloudWatch Container Insights를 사용하여 클러스터 정보를 수집하고 그룹화합니다.
B. Amazon EKS 커넥터를 사용하여 모든 Kubernetes 클러스터를 등록하고 연결합니다.
C. AWS Systems Manager를 사용하여 클러스터 정보를 수집하고 봅니다.
D. Amazon EKS Anywhere를 기본 클러스터로 사용하여 기본 Kubernetes 명령으로 다른 클러스터를 봅니다.

---

풀이

AWS 안팎에 흩어진 Kubernetes 클러스터를 한 화면에서 보고 싶은 상황입니다. Amazon EKS 커넥터는 외부에서 운영 중인 클러스터를 EKS 콘솔에 등록해 주어, 클러스터를 옮기거나 새로 만들지 않고도 목록과 워크로드를 함께 확인할 수 있게 합니다.

 

정답 : B

 

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

---

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

• AWS와 온프레미스에 걸친 모든 Kubernetes 클러스터의 통합 조회
• 클러스터와 그 위에서 도는 워크로드의 확인
• 최소한의 운영 오버헤드
• 기존 클러스터 구성의 유지

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

• Amazon EKS (Elastic Kubernetes Service) : Kubernetes 제어 영역을 AWS가 대신 운영해 주는 관리형 Kubernetes 서비스입니다. 클러스터를 움직이는 핵심 구성 요소의 설치와 이중화, 업그레이드를 서비스가 맡아 주므로 사용자는 그 위에 올릴 워크로드에 집중할 수 있습니다. 표준 Kubernetes와 호환되어 기존에 쓰던 설정 파일과 도구를 그대로 사용할 수 있습니다.
  
  • EKS 커넥터 : AWS 밖에서 운영 중인 Kubernetes 클러스터를 EKS 콘솔에 등록해 함께 볼 수 있게 해 주는 기능이며, 클러스터에 연결용 구성 요소를 설치하는 것만으로 목록과 그 위의 워크로드를 한곳에서 확인할 수 있습니다.
  • EKS Anywhere : 자체 데이터 센터에 직접 Kubernetes 클러스터를 세워 운영할 수 있게 해 주는 배포판이며, 클러스터를 새로 구축하는 수단이지 이미 있는 클러스터들을 모아 보여 주는 도구는 아닙니다.
• Amazon CloudWatch Container Insights : 컨테이너 환경에서 발생하는 지표와 로그를 모아 대시보드로 보여 주는 모니터링 기능입니다. 클러스터와 노드, 파드 단위로 자원 사용량을 정리해 주고 이상 징후를 살피는 데 도움을 줍니다. 수집한 값에 경보를 걸어 임계값을 넘을 때 알림을 받도록 연결할 수도 있습니다. 성능과 상태를 관찰하는 데 초점이 맞춰져 있어, 어떤 클러스터가 어디에 존재하는지 목록으로 관리하는 용도와는 목적이 다릅니다.
• AWS Systems Manager : 여러 서버와 자원을 한곳에서 점검하고 조작하도록 도와주는 운영 관리 서비스 모음입니다. 하이브리드 환경의 서버를 등록해 명령을 내리고 상태를 확인하는 일도 가능합니다. 접속 경로를 대신 열어 주거나 설정 값을 안전하게 보관하는 기능도 함께 제공해 운영 작업 전반을 아우릅니다. 다만 다루는 단위가 서버와 인스턴스에 가까워, Kubernetes 클러스터와 그 위의 워크로드를 있는 그대로 보여 주지는 않습니다.

3. 선택지 분석하기

A. Amazon CloudWatch Container Insights를 사용하여 클러스터 정보를 수집하고 그룹화합니다.
→ 지표와 로그를 모아 성능을 관찰하는 기능이라 여러 클러스터를 목록으로 등록해 관리하는 용도와는 목적이 다르므로, 적절치 않습니다.

B. Amazon EKS 커넥터를 사용하여 모든 Kubernetes 클러스터를 등록하고 연결합니다.
→ 외부 클러스터까지 콘솔에 등록해 클러스터와 워크로드를 한곳에서 볼 수 있고 기존 구성도 그대로 두면 되므로, 가장 적절한 방법입니다.

C. AWS Systems Manager를 사용하여 클러스터 정보를 수집하고 봅니다.
→ 서버 단위의 운영 작업에 초점을 둔 서비스라 Kubernetes 클러스터와 워크로드를 그대로 보여 주지는 못하므로, 요구를 충족하기 어렵습니다.

D. Amazon EKS Anywhere를 기본 클러스터로 사용하여 기본 Kubernetes 명령으로 다른 클러스터를 봅니다.
→ 자체 환경에 클러스터를 새로 구축하는 수단이며 기존 클러스터들을 모아 보여 주는 기능이 아니므로, 적절치 않습니다.

---

 

 

오늘 문제들은 "이미 있는 것을 그대로 두고 앞이나 위에 얹는" 해법이 정답이었습니다.

 

이번 한 주도 힘내 봅시다! 😊