[AWS DEA] 개념정리 - Domain2 데이터 스토어 관리

AWS DEA-C01 › Domain 2 · 전체 압축 정리

Domain 2 — 데이터 스토어 관리
핵심만 압축 정리

스토어 선택 · 데이터 카탈로그 · 수명주기 · 스키마진화 · Task 1~4 한 페이지

2.1

데이터 스토어 선택

Task 1 · 용도에 맞는 스토리지 서비스를 고르는 법

26%

스토리지 유형 3종 — 기초 구분

유형	서비스	비유	사용 사례
객체	Amazon S3	무한 창고	데이터 레이크, 백업, 미디어, 정적 콘텐츠
파일	Amazon EFS	공유 네트워크 드라이브	여러 EC2 공유 파일, 웹호스팅, 빅데이터
블록	Amazon EBS	서버 내부 SSD	DB 실행, 트랜잭션 앱, 짧은 지연시간 필요
파일	FSx for Lustre	고속 병렬 드라이브	HPC, 머신러닝, 대규모 병렬 데이터 처리

Amazon S3 스토리지 클래스 — 비용 최적화 핵심

클래스

비유

액세스

복원 시간

Standard

냉장고 (자주 꺼냄)

자주

즉시

Intelligent-Tiering

자동 분류 로봇

패턴 자동 감지

즉시

Standard-IA

일반 창고

가끔

즉시

Glacier Instant

지하 창고

분기 1회

밀리초

Glacier Flexible

외딴 창고

연 1회

분~시간

Deep Archive

북극 창고

거의 안 함

최대 12시간

데이터베이스 서비스 비교

서비스	유형	비유	핵심 특징 / 사용 사례
Amazon RDS	관계형	관리형 파일 캐비닛	MySQL·PostgreSQL·Oracle·SQL Server. 패치·백업 자동. Multi-AZ 고가용성
Amazon Aurora	관계형	터보 캐비닛	MySQL 5배·PostgreSQL 3배 성능. 스토리지 최대 128TB 자동 확장. Serverless v2
Amazon DynamoDB	NoSQL (KV/문서)	초고속 인덱스 카드함	1ms 미만. 자동 스케일. 게임·IoT·실시간. TTL로 항목 자동 삭제
Amazon Redshift	데이터 웨어하우스	대형 분석 연구소	컬럼 기반. 페타바이트 규모. COPY 명령(S3→Redshift). Spectrum(S3 직접 조회)
Amazon OpenSearch	검색 엔진	구글 같은 검색 DB	전문 검색·로그 분석. Firehose와 연동. OpenSearch Dashboards 내장
Amazon ElastiCache	인메모리 캐시	책상 위 메모지	Redis·Memcached. 자주 쓰는 데이터 캐싱. 세션·실시간 리더보드
Amazon Timestream	시계열 DB	기상 관측 기록지	IoT 센서·메트릭 특화. 자동 데이터 티어링(최신/과거 분리)
Amazon DocumentDB	문서 DB	JSON 서류 캐비닛	MongoDB 호환. 유연한 스키마. 콘텐츠 관리·사용자 프로필

AWS Lake Formation — 데이터 레이크 권한 관리

🏛️ Lake Formation = S3 + 세밀한 출입증 시스템 S3만으로는 누구나 버킷에 접근 가능 → Lake Formation으로 열(Column) 수준·행(Row Filter) 수준 접근제어 추가.
Glue Data Catalog 위에서 동작. LF-Tags 기반 ABAC(속성 기반 접근제어) 지원.
교차 계정(Cross-Account) 데이터 공유 가능 → 4개 AWS 계정 데이터를 중앙 레이크로 통합 관리.

📝 시험 시나리오 — Redshift를 선택하는 이유

30TB 비압축 데이터, 매일 수천 개 집계 쿼리, 복잡한 조인, 테이블 열의 작은 하위 집합만 쿼리. → 어떤 서비스?

Amazon Redshift. 컬럼 기반 아키텍처 → 열 하위 집합 쿼리 시 I/O 최소화. 열 단위 압축으로 스토리지 절감. 병렬 처리(MPP). SQL 조인 지원. 집계 쿼리에 최적화.

📝 시험 시나리오 — EMR + Hive + DynamoDB

페타바이트 규모 키/값 데이터 저장, 즉시 액세스, SQL 유사 인터페이스 필요. → 솔루션은?

EMR + Hive + DynamoDB. Hive = SQL 유사 인터페이스로 페타바이트 읽기·쓰기·관리. DynamoDB = 즉시 액세스(1ms). 단기 작업은 가동/중단하며 초당 과금, 장기는 자동 확장 HA 클러스터.

---

2.2

데이터 카탈로그 작성 시스템

Task 2 · 데이터가 어디 있는지, 어떻게 생겼는지 기록하기

📖 데이터 카탈로그란? 데이터의 위치 + 스키마 + 런타임 지표를 저장하는 메타데이터 리포지토리. AWS에서는 AWS Glue Data Catalog가 핵심. Athena·EMR·Redshift Spectrum이 모두 이 카탈로그를 참조해서 쿼리함.

Glue Data Catalog 구성 요소

구성 요소	역할	비유
Database	논리적 그룹 (테이블 묶음)	창고 건물
Table	데이터 스키마 + S3 위치 매핑	창고 구역 목록표
Crawler	데이터 소스 자동 스캔 → 스키마 추론 → 테이블 등록	창고 탐색 자동 로봇
Connection	소스(S3·RDS·Redshift) 접속 정보	창고 입장 열쇠
Partition	날짜·리전 등 파티션 정보 동기화	창고 구역 구분 칸막이

메타데이터 구성 요소 vs 데이터 카탈로그 구성 요소

📋 메타데이터 구성 요소

• 스키마 — 데이터 유형·필드명·관계
• 데이터 유형 — string, int, timestamp 등
• 데이터 소스 — DB·레이크·웨어하우스 오리진
• 타임스탬프 — 생성·수정 시간
• 데이터 품질 지표 — 정확성·완전성·일관성
• 소유권·접근제어 — 누가 소유하고 접근 가능한지

🗂️ 데이터 카탈로그 구성 요소

• 테이블 스키마 — 열 이름·데이터 유형·속성
• 파티셔닝 정보 — 쿼리 효율 향상용
• 위치/스토리지 — S3 경로·DB 엔드포인트
• 통계·크롤링 메타데이터 — Crawler 수집 정보
• 데이터 계보 — 데이터 흐름·변환 추적
• 태깅·레이블 — 분류·검색 기능
• 액세스 제어 정책 — 승인된 사용자만 접근

파티션 ↔ 데이터 카탈로그 동기화 프로세스 (S3 예시)

① Glue DB 생성카탈로그 컨테이너

→

② Crawler 생성S3 버킷 대상

→

③ 파티션 스키마 정의날짜·리전 등

→

④ Crawler 실행스캔·메타데이터 수집

→

⑤ 예약 실행주기적 최신화

→

⑥ Athena 쿼리파티션 기반 효율적 조회

💡 Lake Formation vs Glue Data Catalog 차이 Glue Catalog = 테이블 수준에서 키/값 태그 기반 메타데이터
Lake Formation = 데이터베이스·테이블·열 수준까지 키/값 속성 추가 + 행 필터 접근제어 추가. Lake Formation이 Glue Catalog의 상위 집합.

📝 시험 시나리오 — 교차 계정 데이터 레이크

4개 AWS 계정의 데이터를 중앙 데이터 레이크로 통합하되, 각 사업부가 관련 데이터에만 접근하도록 역할 기반 접근 제어(RBAC)를 유지해야 한다면?

① 4개 계정 각각에 데이터 레이크 스토리지(S3) 구성
② Lake Formation으로 여러 계정 데이터를 중앙 레이크 계정으로 카탈로그화
③ Lake Formation 서비스 연결 역할로 각 계정 S3 버킷 정책 업데이트
④ Lake Formation 권한으로 열/행 수준 세밀한 접근 제어 부여

---

2.3

데이터 수명주기 관리

Task 3 · 핫·웜·콜드 데이터, S3 수명주기, 보존·복제

핫 / 웜 / 콜드 데이터 개념

분류

특징

S3 클래스

비용

🔥 핫 (Hot)

자주 액세스. 최신 데이터

S3 Standard

높음

🌡️ 웜 (Warm)

가끔 액세스. 수개월 이후

Standard-IA

중간

❄️ 콜드 (Cold)

거의 안 씀. 보관 목적

Glacier / Deep Archive

낮음

S3 수명주기 정책 — 자동 계층 이동 예시

0~6개월S3 Standard

→

6개월~2년Standard-IA

→

2년 이후S3 Glacier

→

규정 기간 후삭제 또는 Deep Archive

💡 Redshift 수명주기 최적화 탄력적 크기 조정으로 노드 추가·제거. 노드 유형 변경 가능. 오래된 데이터는 S3로 내보내고 Redshift Spectrum으로 과거 데이터를 현재 데이터와 조인·보고.

데이터 보호 — 복제·백업·버전관리

방법	서비스	핵심
다중 AZ 복제	S3 (자동), RDS Multi-AZ	가용 영역 장애 시 자동 장애 조치
크로스 리전 복제	S3 CRR, Aurora Global	리전 전체 장애 대비. DR(재해복구)
백업	AWS Backup, RDS 스냅샷	일정 기반 자동 백업. 특정 시점 복구(PITR)
버전 관리	S3 Versioning	객체 여러 버전 보존. 실수 삭제/덮어쓰기 방지
TTL 자동 삭제	DynamoDB TTL	만료 날짜 기반 항목 자동 삭제. 오래된 데이터 정리

📝 시험 시나리오 — Redshift 시계열 테이블

Redshift 클러스터에 데이터가 쌓이면서 쿼리 성능이 저하. 고정 보존 기간이 있는 경우 어떻게 해결?

같은 구조, 다른 시간 범위의 데이터를 시계열 테이블로 분리 → 오래된 테이블에 DROP TABLE 실행.
대규모 DELETE 대신 DROP TABLE을 쓰는 이유: DELETE 후 공간 회수를 위한 VACUUM 불필요. 테이블 수 감소로 인덱스·최적화 효율 향상. 비용·시간 절약.

📝 시험 시나리오 — S3 수명주기 + Athena

S3 CSV 데이터. 6개월 후 거의 안 씀. 2년 후 보관 필요. Athena로 쿼리. 비용 최적화 방법은?

① Glue ETL로 CSV → Parquet(컬럼 기반) + 압축 + 파티셔닝 변환 (Athena 스캔 비용 절감)
② S3 수명주기: 0~6개월 = Standard → 6개월 후 Standard-IA → 2년 후 S3 Glacier

---

2.4

데이터 모델 설계 & 스키마 진화

Task 4 · 데이터 모델링, 스키마 변경 관리, 마이그레이션 도구

데이터 유형별 저장 서비스

데이터 유형	적합 서비스	특징
정형 (Structured)	RDS, Aurora, Redshift	SQL 쿼리, 고정 스키마, 트랜잭션 ACID
반정형 (Semi-structured)	DynamoDB, DocumentDB, Athena, S3	JSON·XML. 유연한 스키마. 읽기 스키마(Schema-on-read)
비정형 (Unstructured)	S3, Rekognition, Transcribe, Comprehend	이미지·영상·음성·텍스트. ML 서비스로 분석

Redshift 데이터 모델링 패턴

⭐ 스타 스키마 (Star Schema)

중앙의 팩트 테이블 + 주변의 차원 테이블. 조인 단순. 쿼리 성능 우수. Kimball 방법론. Redshift에서 권장.

❄️ 눈송이 스키마 (Snowflake Schema)

차원 테이블이 추가로 정규화됨. 중복 최소화. 조인 복잡도 증가. 스토리지 절약.

스키마 진화 — 서비스별 처리 방법

서비스	스키마 진화 방식	주의 사항
DynamoDB	새 속성 자동 수용. 이전 데이터는 그대로 유지	스키마리스. 가장 유연
S3 (Data Lake)	Schema-on-read. Athena/Glue로 해석 시 스키마 적용	원시 데이터는 그대로 저장
AWS Glue	스키마 버전 관리. Avro·Parquet·ORC 포맷 스키마 진화 지원	자동화된 ETL로 스키마 변환
RDS / Aurora	DMS로 무중단 스키마 변경. 저장 프로시저로 제어된 업데이트	NoSQL 대비 복잡. 충분한 테스트 필요

스키마 변환·마이그레이션 도구

도구	역할	함께 쓰는 서비스
AWS SCT (Schema Conversion Tool)	한 DB 엔진 → 다른 엔진으로 스키마 변환. 데이터 유형 매핑·저장 프로시저·인덱스 자동 변환. 마이그레이션 전 평가 보고서 제공	AWS DMS와 함께 사용
AWS DMS	이기종 DB 마이그레이션 + CDC(실시간 복제). SCT와 연동해 스키마 변환 포함	RDS, Aurora, Redshift 대상 지원
AWS Glue	자동화된 ETL로 한 스키마 → 다른 스키마 변환. 스키마 버전 관리	S3, Redshift, RDS

최적화 기술 — 서비스별 정리

기술	서비스	방법
인덱싱	RDS	WHERE·JOIN 자주 사용하는 열에 인덱스 생성
보조 인덱스	DynamoDB	GSI·LSI로 다양한 쿼리 패턴 지원. 기본 키 선택이 핵심
파티셔닝	S3, Athena, Glue	year=/month=/day=/ 경로로 스캔 범위 최소화
배포키·정렬키	Redshift	노드 전체에 데이터 균등 분산. 쿼리 중 데이터 이동 최소화
압축	S3, Redshift	gzip/bzip2 (S3). 열 압축 인코딩 (Redshift). Parquet/ORC (Athena)
캐싱	ElastiCache, CloudFront	자주 읽는 데이터 캐시 → DB 부하 절감
데이터 아카이빙	S3 Glacier	자주 안 쓰는 과거 데이터 → 비용 효율 계층 이동
데이터 계보 추적	SageMaker ML Lineage	ML 워크플로 입력 데이터·변환·모델 아티팩트 자동 추적

📌 스키마 진화 사전 대응 기술 — 시험 포인트 스키마 레지스트리 사용 (MSK Schema Registry·Glue Schema Registry)
스키마 검증·버전 관리 구현
배달 못한 편지 대기열(DLQ) — 처리 실패 메시지 보관
스키마 변경 전 백업 수행
모니터링·경고 설정 — 스키마 변경 탐지

---

🎯 Domain 2 시험 핵심 — 이것만 기억

• ①S3 스토리지 클래스 순서 — Standard → Standard-IA → Glacier Instant → Glacier Flexible → Deep Archive (비용 낮아짐, 복원 시간 길어짐)
• ②Redshift를 선택하는 이유 — 컬럼 기반 + 병렬 처리 + 열 하위 집합 쿼리 + 페타바이트 집계
• ③Redshift COPY 명령 = S3/EMR에서 테이블로 대량 데이터 로드
• ④Redshift Spectrum = S3에 있는 데이터를 Redshift에서 직접 쿼리 (현재 데이터 + 과거 S3 데이터 조인)
• ⑤Lake Formation = Glue Catalog + 열/행 수준 세밀한 접근제어 + 교차 계정 공유
• ⑥Glue Crawler = 데이터 소스 자동 스캔 → 스키마 추론 → 카탈로그 등록. 파티션 동기화 자동화
• ⑦DynamoDB TTL = 만료 날짜 기반 항목 자동 삭제 (타임스탬프 이후 자동 정리)
• ⑧DROP TABLE vs DELETE (Redshift 시계열) — DROP은 VACUUM 불필요, 성능 좋음
• ⑨스키마 진화 포맷 — Avro·Parquet·ORC = 설계상 스키마 진화 지원 (필드 추가·제거·수정 가능)
• ⑩AWS SCT + DMS = 이기종 DB 스키마 변환 + 마이그레이션 콤보
• ⑪FSx for Lustre = 병렬 파일시스템. HPC·ML·대규모 병렬 처리
• ⑫ElastiCache = 인메모리 캐시(Redis/Memcached). 자주 쓰는 데이터 캐싱·세션

AWS DEA-C01 Domain 2 압축 정리 · hyeonlee.net

Domain 1 정리도 확인해보세요 😊