AWS DEA-C01 공식 샘플 문제 — 노드 RAM 볼륨 실전 문제 + 정답 해설

 

 

AWS DEA-C01 데이터 엔지니어 EKS · 컨테이너 스토리지 최소 지연

EKS 컨테이너 임시 스토리지 최소 지연 — 노드 RAM 볼륨이 정답인 이유

AWS DEA-C01 시험에 자주 나오는 EKS 스토리지 선택 문제입니다. 컨테이너가 독립적으로 데이터를 변환하면서 변환 완료 전 중간 데이터를 최소 지연(Minimum Latency)으로 저장해야 할 때, RAM 임시 볼륨 / DAX / NFS PersistentVolume / MemoryDB 중 무엇이 최선인지 도식과 함께 비교 정리합니다.

📋 문제

데이터 엔지니어가 Amazon EKS에서 관리하는 컨테이너의 데이터를 변환하는 애플리케이션을 설계하고 있다. 컨테이너는 Amazon EC2 노드에서 실행된다. 컨테이너화된 각 애플리케이션은 독립적인 데이터 집합을 변환한 다음 데이터 레이크에 데이터를 저장한다. 데이터를 다른 컨테이너와 공유할 필요는 없다. 데이터 엔지니어는 변환이 완료되기 전에 데이터를 저장할 위치를 정해야 한다.

다음 중 최소한의 지연 시간으로 이러한 요구 사항을 충족하는 솔루션은 무엇인가?

✅ 핵심 요구사항 체크

• ⚡
  최소 지연 시간 (Minimum Latency)
  데이터를 읽고 쓸 때 지연이 가장 적은 방식 선택 → 네트워크 I/O 없는 로컬 스토리지가 유리
• 🔒
  컨테이너 독립 저장 (공유 불필요)
  각 컨테이너가 자신만의 데이터를 처리 → 다른 컨테이너와 공유 스토리지 필요 없음
• 🔄
  변환 중 임시 저장 (중간 처리 버퍼)
  변환 완료 후 데이터 레이크로 이동 → 최종 저장소가 아닌 임시(Ephemeral) 공간이면 충분

📐 스토리지 지연 시간 계층 비교

⚡ 지연 시간 빠른 순 (위일수록 빠름)

🧠

노드 RAM (메모리 기반 emptyDir)

CPU가 직접 RAM 접근 — 네트워크 I/O 없음, 마이크로초(μs) 단위

~수십 ns

💾

로컬 SSD (NVMe emptyDir)

디스크 기반 임시 볼륨 — 네트워크 없음, 밀리초(ms) 미만

~수십 μs

🌐

외부 네트워크 스토리지 (NFS, EFS, EBS)

네트워크 왕복 필요 — 상대적으로 높은 지연

~ms 이상

☁️

외부 서비스 (DAX, MemoryDB)

네트워크 + API 호출 오버헤드 — 낮지만 RAM보단 느림

~ms 단위

🗄️ 선택지별 스토리지 특성 비교

🧠

RAM 임시 볼륨

emptyDir (medium: Memory)

• 노드 RAM을 마운트 포인트로 직접 사용
• 네트워크 I/O 완전 없음
• 컨테이너 종료 시 자동 삭제 (임시)
• 컨테이너 간 공유 불필요 → 완벽 적합

✅ 최소 지연 + 요구사항 모두 충족

⚡

Amazon DAX

DynamoDB Accelerator (인메모리 캐시)

• DynamoDB 전용 읽기 캐시 서비스
• 네트워크 호출 필요 (VPC 내부)
• 임시 변환 버퍼 용도가 아님
• RAM 볼륨보다 지연 큼

❌ 불필요한 네트워크 오버헤드

📁

NFS PersistentVolume

Kubernetes 영구 볼륨 (NFS)

• 네트워크 파일 시스템 — 항상 네트워크 I/O 발생
• 공유 스토리지 (공유 불필요한 요구사항에 과분)
• 영구 저장 (임시 버퍼 용도에 불필요)
• 지연 시간 가장 큼

❌ 가장 높은 지연 + 불필요한 공유

🔴

Amazon MemoryDB

Redis 호환 인메모리 DB

• Redis 호환 완전관리형 인메모리 DB
• 네트워크 호출 + API 오버헤드
• 내구성 중심 설계 (임시 버퍼 용도에 과분)
• RAM 볼륨보다 지연 큼

❌ 불필요한 네트워크 오버헤드

📝 선택지 해설

각 항목을 클릭하면 해설이 펼쳐집니다.

A

✅ 노드 RAM 임시 볼륨 — 컨테이너는 노드의 RAM에서 제공하는 임시 볼륨을 사용해야 한다

Kubernetes emptyDir (medium: Memory) — 노드 RAM 기반 임시 볼륨

 

💡 정답. Kubernetes의 emptyDir 볼륨에 medium: Memory를 설정하면 노드의 RAM을 tmpfs로 마운트합니다. 네트워크 I/O가 전혀 없어 가장 낮은 지연 시간을 달성하며, 컨테이너마다 독립된 볼륨이 생성되어 공유 불필요 조건도 충족합니다. 컨테이너 종료 시 자동 삭제되어 임시 버퍼 용도에 완벽합니다.

B

❌ Amazon DAX — 애플리케이션 코드 내에서 DAX에 연결되도록 설정해야 한다

Amazon DynamoDB Accelerator — DynamoDB 읽기 전용 인메모리 캐시

 

💡 DAX는 DynamoDB 읽기 성능을 높이기 위한 캐시 서비스입니다. 데이터 변환 중 임시 버퍼 용도가 아니며, 네트워크 호출이 필요해 RAM 볼륨보다 지연이 큽니다. 또한 변환용 임시 스토리지로 DynamoDB + DAX를 조합하는 것은 불필요하게 복잡합니다.

C

❌ NFS PersistentVolume — NFS 스토리지에서 제공하는 PersistentVolume 객체를 사용해야 한다

Kubernetes PersistentVolume (NFS 기반) — 네트워크 파일 시스템

 

💡 NFS 기반 PersistentVolume은 모든 읽기/쓰기 작업에 네트워크 I/O가 발생합니다. 선택지 중 지연 시간이 가장 높습니다. 또한 공유 스토리지인데 "다른 컨테이너와 공유 불필요" 조건에도 불필요하게 과분합니다. 영구 볼륨(PV)이라 임시 버퍼 용도에도 맞지 않습니다.

D

❌ Amazon MemoryDB — 애플리케이션 코드 내에서 MemoryDB에 연결되도록 설정해야 한다

Amazon MemoryDB for Redis — Redis 호환 완전관리형 인메모리 데이터베이스

 

💡 MemoryDB는 인메모리 DB이지만 외부 네트워크 서비스입니다. 컨테이너에서 MemoryDB로의 요청마다 네트워크 왕복(RTT)이 발생해 로컬 RAM 볼륨보다 지연이 큽니다. 내구성(durability)에 최적화된 서비스로 단순 임시 변환 버퍼 용도에는 과도합니다.

정답 및 핵심 정리 (클릭)

정답: A — 노드 RAM 임시 볼륨 (emptyDir, medium: Memory)

변환 완료 전 임시 저장 + 공유 불필요 + 최소 지연 → 세 조건 모두 로컬 RAM 볼륨이 최적입니다. 네트워크 I/O가 전혀 없는 유일한 선택지이며, 컨테이너마다 독립적으로 생성·삭제됩니다.

# Kubernetes 설정 예시 volumes: - name: temp-transform-buffer emptyDir: medium: Memory # ← RAM을 tmpfs로 마운트 sizeLimit: 2Gi # 흐름 요약 EC2 노드 RAM └─ emptyDir (medium: Memory) 마운트 └─ 컨테이너가 /tmp/buffer 에 변환 중 데이터 저장 └─ 변환 완료 → 데이터 레이크(S3 등)로 이동 └─ 컨테이너 종료 → RAM 볼륨 자동 삭제 ✅

📊 선택지 비교 요약

스토리지	위치	네트워크	지연 시간	공유 가능	임시 여부
RAM 볼륨 ⭐	노드 로컬	없음	최저 (ns)	컨테이너 내부만	✅ 임시
DAX	외부 서비스	있음	낮음 (ms)	가능	❌ 영구
NFS PV	외부 NFS	있음	높음 (ms+)	가능	❌ 영구
MemoryDB	외부 서비스	있음	낮음 (ms)	가능	❌ 영구

#AWS_DEA-C01 #AWS데이터엔지니어 #AmazonEKS #컨테이너스토리지 #emptyDir #RAM볼륨 #최소지연 #KubernetesPV #AmazonDAX #MemoryDB #NFSPersistentVolume #AWS자격증 #서버리스컴퓨팅