안녕하세요! 넥스트클라우드의 테크니컬 트레이너 김유림입니다.
모두 기다리셨죠? 드디어 해피 금요일 모닝입니다! 😄
당장 주말이 기다려지실 텐데도 분위기에 휩쓸리지 않고 묵묵히 책상에 앉아있는 여러분을 응원합니다. 오늘도 힘차게 시작해볼까요? 💪
오늘도 문제는 세 가지 단계를 거치며 풀어나갑니다.
1. 문제의 요구사항 분석하기
2. 관련 AWS 서비스 생각하기
3. 선택지 분석하기
바로 문제 풀이 시작합니다.
문제1
솔루션 아키텍트는 Amazon S3 버킷의 파일을 Amazon Elastic File System(Amazon EFS) 파일 시스템과 다른 S3 버킷으로 복사해야 합니다. 파일은 계속해서 복사되어야 합니다. 새 파일은 원본 S3 버킷에 지속적으로 추가됩니다. 복사된 파일은 원본 파일이 변경된 경우에만 덮어써야 합니다.
최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
선택지
A. 대상 S3 버킷과 EFS 파일 시스템 모두에 대한 AWS DataSync 위치를 생성합니다. 대상 S3 버킷 및 EFS 파일 시스템에 대한 작업을 생성합니다. 변경된 데이터만 전송하도록 전송 모드를 설정하세요.
B. AWS Lambda 함수를 생성합니다. 파일 시스템을 함수에 마운트합니다. Amazon S3에서 파일이 생성되고 변경될 때 함수를 호출하도록 S3 이벤트 알림을 설정합니다. 파일 시스템과 대상 S3 버킷에 파일을 복사하는 기능을 구성합니다.
C. 대상 S3 버킷과 EFS 파일 시스템 모두에 대한 AWS DataSync 위치를 생성합니다. 대상 S3 버킷 및 EFS 파일 시스템에 대한 작업을 생성합니다. 모든 데이터를 전송하려면 전송 모드를 설정하세요.
D. 파일 시스템과 동일한 VPC에서 Amazon EC2 인스턴스를 시작합니다. 파일 시스템을 마운트합니다. 원본 S3 버킷에서 변경된 모든 객체를 대상 S3 버킷 및 탑재된 파일 시스템에 정기적으로 동기화하는 스크립트를 만듭니다.
풀이
대상 S3 버킷과 EFS 파일 시스템 모두에 대한 AWS DataSync 위치를 생성하고, 대상 S3 버킷 및 EFS 파일 시스템에 대한 작업을 생성하며, 변경된 데이터만 전송하도록 전송 모드를 설정하는 것이 가장 적절합니다.
정답 : A
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- S3 버킷의 파일을 EFS 파일 시스템과 다른 S3 버킷으로 복사
- 새 파일은 계속 복사되어야 함
- 원본 파일 변경 시에만 복사된 파일 덮어쓰기
- 최소한의 운영 오버헤드로 요구사항 충족
2. 관련 AWS 서비스 생각하기
- AWS DataSync : 온프레미스 스토리지와 AWS 스토리지 서비스 간, 또는 AWS 스토리지 서비스 간 데이터를 자동으로 이동하고 동기화하는 관리형 서비스입니다. S3, EFS, FSx 등을 지원하며, 증분 전송 모드를 통해 변경된 데이터만 전송할 수 있습니다. 스케줄링, 검증, 암호화를 자동으로 처리하여 운영 오버헤드가 최소화됩니다.
3. 선택지 분석하기
A. 대상 S3 버킷과 EFS 파일 시스템 모두에 대한 AWS DataSync 위치를 생성합니다. 대상 S3 버킷 및 EFS 파일 시스템에 대한 작업을 생성합니다. 변경된 데이터만 전송하도록 전송 모드를 설정하세요.
→ DataSync로 S3 → EFS 및 S3 → S3 작업을 생성하고, 변경된 데이터만 전송하도록 설정하면 증분 복사가 자동으로 처리되며 운영 오버헤드가 최소화됩니다.
B. AWS Lambda 함수를 생성합니다. 파일 시스템을 함수에 마운트합니다. Amazon S3에서 파일이 생성되고 변경될 때 함수를 호출하도록 S3 이벤트 알림을 설정합니다. 파일 시스템과 대상 S3 버킷에 파일을 복사하는 기능을 구성합니다.
→ Lambda 함수로 구현하면 S3 이벤트 처리, EFS 마운트, 파일 복사 로직, 에러 처리 등을 직접 구현해야 하므로 운영 오버헤드가 높습니다.
C. 대상 S3 버킷과 EFS 파일 시스템 모두에 대한 AWS DataSync 위치를 생성합니다. 대상 S3 버킷 및 EFS 파일 시스템에 대한 작업을 생성합니다. 모든 데이터를 전송하려면 전송 모드를 설정하세요.
→ 모든 데이터를 전송하면 변경되지 않은 파일도 매번 복사되므로, "변경된 경우에만 덮어쓴다"는 요구사항을 충족하지 못하고 비효율적입니다.
D. 파일 시스템과 동일한 VPC에서 Amazon EC2 인스턴스를 시작합니다. 파일 시스템을 마운트합니다. 원본 S3 버킷에서 변경된 모든 객체를 대상 S3 버킷 및 탑재된 파일 시스템에 정기적으로 동기화하는 스크립트를 만듭니다.
→ EC2 인스턴스에서 스크립트를 실행하면 인스턴스 관리, 스크립트 유지보수, 장애 처리, 스케줄링 등 운영 오버헤드가 매우 높습니다.
이어서 다음 문제입니다.
문제2
애플리케이션은 Amazon RDS MySQL DB 인스턴스를 사용합니다. RDS 데이터베이스의 디스크 공간이 부족해지고 있습니다. 솔루션 설계자는 다운타임 없이 디스크 공간을 늘리고 싶어 합니다.
최소한의 노력으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
선택지
A. RDS에서 스토리지 자동 확장 활성화
B. RDS 데이터베이스 인스턴스 크기 늘리기
C. RDS 데이터베이스 인스턴스 스토리지 유형을 프로비저닝된 IOPS로 변경
D. RDS 데이터베이스 백업, 저장 용량 증가, 데이터베이스 복원 및 이전 인스턴스 중지
풀이
RDS에서 스토리지 자동 확장을 활성화하는 것이 가장 적절합니다.
정답 : A
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- RDS MySQL DB 인스턴스의 디스크 공간 부족
- 다운타임 없이 디스크 공간 증가
- 최소한의 노력
2. 관련 AWS 서비스 생각하기
- Amazon RDS(Relational Database Service) : 클라우드에서 관계형 데이터베이스를 쉽게 설정, 운영 및 확장할 수 있게 해주는 웹 서비스입니다. RDS는 데이터베이스 관리 작업을 자동화하여 프로비저닝, 패치 적용, 백업, 복구 등의 작업을 간소화합니다. RDS는 스토리지 자동 확장 기능을 제공하여 디스크 공간이 부족해질 때 RDS가 자동으로 스토리지 공간을 할당하고 데이터베이스 인스턴스의 스토리지를 확장합니다. 이를 통해 다운타임 없이 스토리지 문제를 해결할 수 있습니다.
3. 선택지 분석하기
A. RDS에서 스토리지 자동 확장 활성화
→ 스토리지 자동 확장을 활성화하면 용량 부족 시 자동으로 확장되며, 다운타임 없이 처리되고 지속적으로 관리되므로 최소 노력으로 요구사항을 충족합니다.
B. RDS 데이터베이스 인스턴스 크기 늘리기
→ 인스턴스 크기를 변경하면 다운타임이 발생하므로 요구사항에 부합하지 않습니다.
C. RDS 데이터베이스 인스턴스 스토리지 유형을 프로비저닝된 IOPS로 변경
→ 스토리지 유형 변경은 성능 개선이지 용량 증가가 아니며, 유형 변경 시에도 다운타임이 발생할 수 있습니다.
D. RDS 데이터베이스 백업, 저장 용량 증가, 데이터베이스 복원 및 이전 인스턴스 중지
→ 백업-복원 프로세스는 다운타임이 길고, 수동 작업이 많아 운영 노력이 크며 복잡한 절차가 필요합니다.
마지막 문제 살펴보겠습니다.
문제3
회사는 Amazon API Gateway를 사용하여 동일한 VPC에서 두 개의 REST API로 프라이빗 게이트웨이를 실행합니다. BuyStock RESTful 웹 서비스는 CheckFunds RESTful 웹 서비스를 호출하여 주식을 구매하기 전에 충분한 자금을 사용할 수 있는지 확인합니다. 회사는 VPC 흐름 로그에서 BuyStock RESTful 웹 서비스가 VPC 대신 인터넷을 통해 CheckFunds RESTful 웹 서비스를 호출한다는 사실을 확인했습니다. 솔루션 설계자는 API가 VPC를 통해 통신하도록 솔루션을 구현해야 합니다.
코드를 가장 적게 변경하여 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
선택지
A. 인증을 위해 HTTP 헤더에 X-API-Key 헤더를 추가합니다.
B. 인터페이스 엔드포인트를 사용합니다.
C. 게이트웨이 엔드포인트를 사용합니다.
D. 두 REST API 사이에 Amazon Simple Queue Service(Amazon SQS) 대기열을 추가합니다.
풀이
문제 상황에서 BuyStock 웹 서비스가 CheckFunds 웹 서비스를 호출할 때 VPC 외부로 나가 인터넷을 거치고 있습니다. 이는 보안 위험이 있으므로 VPC 내부에서 통신하도록 해야 합니다. 인터페이스 엔드포인트를 사용하는 것이 적합합니다.
정답 : B
▼ 자세한 문제 풀이를 원하신 분은 아래 더보기를 통해 확인해 주세요.
1. 문제의 요구사항 분석하기
- 동일 VPC 내에서 두 개의 REST API 실행 중
- BuyStock API가 CheckFunds API를 VPC 외부에서 호출하고 있는 문제 발생
- VPC 내부 통신으로 변경하여 보안 강화 필요
- 코드 변경 최소화
2. 관련 AWS 서비스 생각하기
- 동일 VPC 내에서 두 개의 REST API 실행 중
- BuyStock API가 CheckFunds API를 VPC 외부에서 호출하고 있는 문제 발생
- VPC 내부 통신으로 변경하여 보안 강화 필요
- 코드 변경 최소화
3. 선택지 분석하기
A. 인증을 위해 HTTP 헤더에 X-API-Key 헤더를 추가합니다.
→ HTTP 헤더에 API 키를 추가하는 것은 인증 문제일 뿐, 네트워크 라우팅 경로(인터넷 vs VPC)와는 무관합니다.
B. 인터페이스 엔드포인트를 사용합니다.
→ API Gateway용 인터페이스 엔드포인트를 생성하면 VPC 내부에서 프라이빗하게 API를 호출할 수 있으며, 프라이빗 DNS를 활성화하면 코드 변경 없이 자동으로 VPC 내부 통신이 가능합니다.
C. 게이트웨이 엔드포인트를 사용합니다.
→ 게이트웨이 엔드포인트는 S3와 DynamoDB만 지원하며, API Gateway는 지원하지 않습니다.
D. 두 REST API 사이에 Amazon Simple Queue Service(Amazon SQS) 대기열을 추가합니다.
→ SQS 대기열을 추가하면 아키텍처가 복잡해지고 코드 변경이 불가피해집니다.
공부를 포기하지 않는 한, 실패는 없습니다.
계획했던 공부량 꼭 채우시고 다음 주에 만나요. 감사합니다! 🙏
'AWS > SAA 준비' 카테고리의 다른 글
| AWS SAA 합격으로 가는 길 #142 (0) | 2025.12.19 |
|---|---|
| AWS SAA 합격으로 가는 길 #141 (0) | 2025.12.15 |
| AWS SAA 합격으로 가는 길 #139 (1) | 2025.12.08 |
| AWS SAA 합격으로 가는 길 #138 (1) | 2025.12.05 |
| AWS SAA 합격으로 가는 길 #137 (0) | 2025.12.01 |