AWS SAA 합격으로 가는 길 #161

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

3월부터도 잘 부탁드립니다!

 

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

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

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

3. 선택지 분석하기

 

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

---

문제1

한 회사의 전자상거래 웹사이트에 예측할 수 없는 트래픽이 있으며 AWS Lambda 기능을 사용하여 PostgreSQL을 프라임한 Amazon RDS DB 인스턴스에 직접 액세스합니다. 회사는 예측 가능한 데이터베이스 상륭을 유지하고 Lambda 호출이 너무 많은 연결로 인해 데이터베이스에 과부하가 걸리지 않도록 하려고 합니다.

솔루션 설계자는 이러한 요구 사항을 충족하기 위해 무엇을 해야 합니까?

 

선택지

A. RDS 사용자 지정 엔드포인트에서 클라이언트 드라이버를 커집니다. VPC 내부에 Lambda 함수를 배포합니다.

B. RDS 프록시 엔드포인트에서 클라이언트 드라이버를 커집니다. VPC 내부에 Lambda 함수를 배포합니다.

C. RDS 사용자 지정 엔드포인트에서 클라이언트 드라이버를 커집니다. VPC 외부에 Lambda 함수를 배포합니다.

D. RDS 프록시 엔드포인트에서 클라이언트 드라이버를 커집니다. VPC 외부에 Lambda 함수를 배포합니다.

---

풀이

트래픽 급증 시 수천 개의 Lambda 함수가 DB에 동시 접속하면 연결 한도(max_connections)를 초과해 데이터베이스 장애가 발생할 수 있습니다. 이를 방지하려면 Amazon RDS Proxy의 연결 풀링 기능을 사용해 데이터베이스 연결을 효율적으로 공유하고 재사용해야 합니다. 또한 RDS Proxy는 VPC 내부에서만 접근 가능하므로 Lambda 역시 VPC 내부에 배포해야 정상적으로 통신할 수 있습니다.

 

정답 : B

 

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

---

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

• 예측할 수 없는 트래픽으로 인해 Lambda가 급격히 확장됨
• Lambda의 과도한 연결 요청으로부터 RDS 데이터베이스를 보호해야 함
• 데이터베이스 부하를 관리하고 예측 가능한 성능을 유지해야 함

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

• Amazon RDS Proxy : 애플리케이션과 RDS 데이터베이스 사이에 위치하여 데이터베이스 연결을 풀링하고 공유하는 완전 관리형 데이터베이스 프록시입니다. 서버리스 애플리케이션의 연결 폭주를 제어하여 데이터베이스 효율성을 높입니다.
  • RDS 사용자 지정 엔드포인트 : 읽기 전용 복제본 그룹 등 특정 인스턴스 집합에 연결하기 위한 기능이며, 연결 풀링 기능을 제공하지 않습니다.
• VPC (Virtual Private Cloud) : RDS Proxy는 VPC 내에서만 생성되고 접근 가능합니다. 따라서 프록시에 연결하려는 컴퓨팅 리소스(Lambda)는 해당 VPC에 접근할 수 있는 네트워크 설정이 필요합니다.

3. 선택지 분석하기

A. RDS 사용자 지정 엔드포인트에서 클라이언트 드라이버를 가리킵니다. VPC 내부에 Lambda 함수를 배포합니다.

→ RDS 사용자 지정 엔드포인트는 트래픽을 특정 DB 인스턴스 그룹으로 라우팅하는 역할만 하기에 데이터베이스 과부하를 막을 수 없습니다.

 

B. RDS 프록시 엔드포인트에서 클라이언트 드라이버를 가리킵니다. VPC 내부에 Lambda 함수를 배포합니다.

→ RDS Proxy로 데이터베이스 연결을 풀링하여 과부하를 막고, 프록시 접근을 위해 Lambda를 동일한 VPC 내부에 배포하여 적절한 선택지입니다.

 

C. RDS 사용자 지정 엔드포인트에서 클라이언트 드라이버를 가리킵니다. VPC 외부에 Lambda 함수를 배포합니다.

→ 사용자 지정 엔드포인트는 트래픽이 몰릴 때 발생하는 연결 고갈 문제를 근본적으로 해결할 수 없습니다.

 

D. RDS 프록시 엔드포인트에서 클라이언트 드라이버를 가리킵니다. VPC 외부에 Lambda 함수를 배포합니다.

→ Amazon RDS Proxy는 설계상 퍼블릭 액세스가 불가하며 VPC 내부에서만 접근할 수 있도록 제한되어 있습니다. 따라서 VPC 외부에 배포된 Lambda 함수는 프록시 엔드포인트에 아예 연결할 수 없어 올바르지 않습니다.

---

 

이어서 다음 문제입니다.

---

문제2

회사는 AWS 클라우드에서 3계층 웹 애플리케이션을 호스팅합니다. MySQL용 다중 AZAmazon RDS 서버는 데이터베이스 계층을 형성합니다. Amazon ElastiCache는 캐시 계층을 형성합니다. 회사는 고객이 데이터베이스에 항목을 추가할 때 캐시의 데이터를 추가하거나 업데이트하는 캐싱 전략을 원합니다. 캐시의 데이터는 항상 데이터베이스의 데이터와 일치해야 합니다.

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

 

선택지

A. 지연 로딩 캐싱 전략 구현

B. write-through 캐싱 전략 구현

C. 추가 TTL 캐싱 전략 구현

D. AWS AppConfig 캐싱 전략 구현

---

풀이

데이터베이스에 데이터가 기록되는 시점에 캐시에도 동시에 데이터를 기록하여 싱크를 맞추는 방식을 Write-Through 전략이라고 합니다. 이 방식은 데이터베이스와 캐시의 데이터가 항상 일치해야 하는 요구사항에 가장 적합한 전략입니다.

 

정답 : B

 

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

---

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

• 데이터베이스에 항목이 추가/업데이트될 때, 캐시에도 즉시 반영되어야 함
• 캐시 데이터와 DB 데이터가 항상 일치(Stale Data 방지)해야 함
• 데이터 불일치를 허용하지 않는 엄격한 동기화 필요

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

•  AWS ElastiCache : AWS가 제공하는 인메모리 캐싱 서비스로, Redis 또는 Memcached를 관리형 서비스로 제공합니다. 데이터베이스 앞단에 캐시 계층을 두어 자주 조회하는 데이터의 응답 속도를 크게 높일 수 있습니다. 자동 스케일링, 고가용성, 백업 등의 운영 이슈를 AWS가 처리하므로 개발에만 집중할 수 있습니다.

3. 선택지 분석하기

A. 지연 로딩 캐싱 전략 구현

→ 지연 로딩은 데이터 요청 시에 캐시를 채우는 방식이므로, DB 업데이트 시점에 즉시 캐시를 갱신하지 않아 데이터 불일치가 발생할 수 있습니다.

 

B. write-through 캐싱 전략 구현

→ DB에 쓸 때 캐시도 함께 업데이트하므로 데이터가 항상 일치하며, 데이터베이스에 항목을 추가할 때 캐시를 추가 및 업데이트하려는 요구사항에 완벽히 부합합니다.

 

C. 추가 TTL 캐싱 전략 구현

→ TTL(Time To Live)은 데이터의 유효 기간을 설정하는 기능이기에 DB와 캐시 간의 쓰기 동기화 전략에 적합하지 않습니다.

 

D. AWS AppConfig 캐싱 전략 구현

→ AWS AppConfig는 애플리케이션 구성(Configuration) 데이터를 관리하고 배포하는 서비스로, RDS와 ElastiCache 간의 데이터 캐싱 전략과는 관련이 없습니다.

---

 

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

---

문제3

한 회사에서 모바일 장치용 멀티플레이어 게임을 배포했습니다. 이 게임에는 위도와 경도를 기반으로 플레이어의 실시간 위치 추적이 필요합니다. 게임의 데이터 저장소는 신속한 업데이트와 위치 검색을 지원해야 합니다.

이 게임은 읽기 전용 복제본이 있는 PostgreSQL DB 인스턴스용 Amazon RDS를 사용하여 위치 데이터를 저장합니다. 사용량이 가장 많은 기간에는 데이터베이스가 업데이트를 읽고 쓰 는 데 필요한 성능을 유지할 수 없습니다. 게임의 사용자 기반이 빠르게 증가하고 있습니다.

데이터 계층의 성능을 향상하려면 솔루션 설계자가 무엇을 해야 합니까?

 

선택지

A. 기존 DB 인스턴스의 스냅샷을 찍습니다. 다중 AZ가 활성화된 스냅샷을 복원합니다.

B. OpenSearch 대시보드를 사용하여 Amazon RDS에서 Amazon OpenSearch Service로 마이그레이션합니다.

C. 기존 DB 인스턴스 앞에 Amazon DynamoDB Accelerator(DAX)를 배포합니다. DAX를 사용하도록 게임을 수정합니다.

D. 기존 DB 인스턴스 앞에 Redis용 Amazon ElastiCache 클러스터를 배포합니다. Redis를 사용하도록 게임을 수정합니다.

---

풀이

게임의 실시간 위치 데이터(위도, 경도) 처리는 빈번한 쓰기와 읽기가 발생하므로 디스크 기반의 RDS만으로는 성능 한계가 있습니다. Amazon ElastiCache for Redis는 1밀리초 미만의 지연 시간을 제공하는 인메모리 데이터 스토어이며, 특히 지리 공간 데이터를 효율적으로 처리할 수 있는 기능을 내장하고 있어 위치 기반 게임 데이터 처리에 최적입니다.

 

정답 : D

 

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

---

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

• 실시간 위치 추적(위도/경도)을 위한 데이터 저장소 필요
• 사용량이 폭증하는 기간에도 신속한 업데이트(쓰기)와 검색(읽기) 성능 유지
• 기존 RDS의 성능 병목을 해결하고 데이터 계층을 최적화해야 함

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

• Amazon ElastiCache for Redis : AWS의 관리형 인메모리 캐싱 서비스로, 실시간 위치 데이터를 초고속으로 저장·조회할 수 있습니다. Redis의 지역 데이터 타입과 명령어(GEORADIUS 등)를 활용하면 좌표 기반 범위 검색을 밀리초 단위로 처리합니다. PostgreSQL 앞단에 배치하여 대부분의 조회를 메모리에서 처리하므로 데이터베이스 부하를 획기적으로 줄일 수 있습니다.
• Amazon DynamoDB : AWS의 완전 관리형 NoSQL 데이터베이스로, 프로비저닝한 용량 또는 온디맨드 방식으로 무제한 확장이 가능합니다. 글로벌 보조 인덱스를 통해 위치 데이터를 효율적으로 검색할 수 있으며, 자동으로 여러 가용 영역에 복제되어 고가용성을 보장합니다. 

3. 선택지 분석하기

A. 기존 DB 인스턴스의 스냅샷을 찍습니다. 다중 AZ가 활성화된 스냅샷을 복원합니다.

→ 다중 AZ는 장애 조치(Failover)를 위한 기능이지 성능 향상을 위한 기능이 아닙니다. 동기식 복제로 인해 쓰기 지연이 늘어날 수도 있습니다.

 

B. OpenSearch 대시보드를 사용하여 Amazon RDS에서 Amazon OpenSearch Service로 마이그레이션합니다.

→ OpenSearch는 검색 및 분석 엔진입니다. 초고속 트랜잭션 처리가 필요한 실시간 게임 위치 업데이트에는 적합하지 않습니다.

 

C. 기존 DB 인스턴스 앞에 Amazon DynamoDB Accelerator(DAX)를 배포합니다. DAX를 사용하도록 게임을 수정합니다.

→ DAX는 오직 Amazon DynamoDB와만 작동하는 캐시 서비스입니다. 현재 사용 중인 PostgreSQL(RDS) 앞에는 배치할 수 없습니다.

 

D. 기존 DB 인스턴스 앞에 Redis용 Amazon ElastiCache 클러스터를 배포합니다. Redis를 사용하도록 게임을 수정합니다.

→ Redis의 인메모리 성능과 지리 공간 데이터 지원 기능을 활용하여 RDS의 부하를 덜고 실시간성을 보장하는 가장 이상적인 솔루션입니다.

---

 

3월부터도 화이팅입니다! 금요일에 뵙겠습니다 😊