데이터를 "어디에 저장할 것인가"는 데이터 엔지니어링에서 가장 중요한 설계 결정 중 하나입니다. 잘못된 저장소를 선택하면 쿼리가 수십 배 느려지거나, 비용이 폭발하거나, 아예 원하는 기능을 구현할 수 없게 됩니다. 반대로 올바른 저장소를 선택하면 쿼리가 빠르고, 비용이 절감되며, 시스템이 단순해집니다. AWS DEA-C01 시험에서는 주어진 요구사항과 액세스 패턴을 분석해 최적의 저장소를 선택하는 능력을 테스트합니다.
저장소 선택 가이드 — 어떤 상황에 무엇을 쓸까?
| 요구사항 | 추천 서비스 | |---------|-----------| | 대규모 분석 쿼리(OLAP), SQL로 집계·조인 | Amazon Redshift | | 키-값 조회, 밀리초 응답, 대규모 쓰기/읽기 | Amazon DynamoDB | | S3 기반 데이터 레이크, 서버리스 SQL 분석 | Lake Formation + Athena | | 관계형 데이터, OLTP (트랜잭션 처리) | Amazon RDS / Aurora | | 초저지연 인메모리 캐시 | Amazon ElastiCache / MemoryDB | | S3 데이터에 ACID 트랜잭션, 타임 트래블 | Apache Iceberg | | 검색, 로그 분석, 전문 검색 | Amazon OpenSearch Service |
이 표를 외우는 것보다 중요한 것은 "왜 이 저장소를 쓰는지"를 이해하는 것입니다. 각 서비스의 설계 원리를 이해하면, 처음 보는 시나리오에서도 올바른 답을 추론할 수 있습니다.
!데이터 저장소 선택: Redshift, Iceberg, Lake Formation
Amazon Redshift — 분석에 최적화된 데이터 웨어하우스
Amazon Redshift는 대규모 데이터 분석(OLAP)을 위한 완전 관리형 데이터 웨어하우스입니다. 수백억 개의 행에 걸친 집계 쿼리를 빠르게 실행하도록 설계되었습니다.
열 기반 스토리지(Columnar Storage)가 핵심
일반 데이터베이스는 행 단위로 데이터를 저장합니다. "고객 1의 이름, 나이, 주소, 구매금액, 포인트"를 한 줄로 저장하는 방식입니다. 반면 Redshift는 열 단위로 저장합니다. 모든 고객의 "구매금액"만 따로 모아 저장합니다.
왜 이것이 분석에 유리할까요? "지난 1년간 평균 구매금액을 계산해줘"라는 쿼리를 실행할 때, 행 기반 DB는 모든 고객의 모든 데이터를 읽어야 합니다. 하지만 Redshift는 "구매금액" 열만 읽으면 됩니다. 수백 개의 열 중 필요한 몇 개만 읽으므로 I/O가 대폭 줄어듭니다.
Redshift Spectrum — S3 데이터를 직접 쿼리
Redshift에 데이터를 로드하지 않고, S3에 있는 데이터를 직접 SQL로 쿼리하는 기능입니다. 데이터 레이크(S3)와 데이터 웨어하우스(Redshift)를 연결하는 다리 역할을 합니다.
예를 들어 최근 3년치 데이터는 Redshift에 로드하고, 5년 이상 된 오래된 데이터는 S3에 저렴하게 보관하면서 Spectrum으로 필요할 때만 조회합니다. "콜드 데이터는 S3에, 핫 데이터는 Redshift에"라는 전략입니다.
Federated Query (연합 쿼리)
Redshift에서 Amazon RDS, Aurora, S3에 있는 데이터를 직접 조회합니다. 데이터를 먼저 Redshift로 복사하지 않아도 됩니다. 여러 소스의 데이터를 하나의 SQL 쿼리에서 JOIN할 수 있습니다.
Concurrency Scaling (동시성 스케일링)
피크 시간에 쿼리가 몰릴 때 Redshift가 자동으로 추가 클러스터 용량을 확장합니다. 월말 보고서 시즌처럼 특정 시간에 수십 명의 분석가가 동시에 쿼리를 실행해도 성능이 유지됩니다.
RA3 인스턴스 — 컴퓨팅과 스토리지 분리
전통적인 Redshift 노드는 컴퓨팅과 스토리지가 묶여 있었습니다. 데이터가 늘면 컴퓨팅도 함께 늘려야 했습니다. RA3 인스턴스는 컴퓨팅과 스토리지를 분리합니다. 데이터가 늘었지만 분석 쿼리 수는 그대로라면, 스토리지만 늘리면 됩니다. 반대로 분석이 늘었지만 데이터 양은 그대로라면 컴퓨팅만 늘릴 수 있습니다.
Apache Iceberg — 데이터 레이크에 데이터 웨어하우스 기능을 더하다
S3는 저렴하고 무한히 확장되는 스토리지입니다. 하지만 기본적으로 S3의 데이터는 파일을 덮어쓰거나 수정하는 것이 어렵고, 여러 프로세스가 동시에 쓰기를 하면 데이터 불일치가 생길 수 있습니다. Apache Iceberg는 S3 같은 데이터 레이크 위에서 관계형 데이터베이스 수준의 기능을 제공하는 오픈 테이블 형식입니다.
도서관 카탈로그 시스템에 비유해보면: S3는 책들이 쌓여 있는 창고이고, Iceberg는 "어느 책이 어디에 있고, 언제 추가되었고, 어떤 버전인지"를 추적하는 정교한 카탈로그 시스템입니다.
ACID 트랜잭션
ACID는 데이터베이스 트랜잭션의 4가지 속성입니다: Atomicity(원자성): 작업이 전부 성공하거나 전부 실패합니다. 중간 상태가 없습니다. Consistency(일관성): 데이터는 항상 유효한 상태를 유지합니다. Isolation(격리성): 동시에 실행되는 트랜잭션은 서로 간섭하지 않습니다. Durability(지속성): 완료된 트랜잭션은 시스템 장애가 있어도 유지됩니다.
Iceberg를 사용하면 S3에 저장된 데이터도 이런 특성을 갖게 됩니다. 예를 들어 1억 개의 레코드를 업데이트하는 중에 시스템이 다운되어도, 반쯤 업데이트된 상태가 남지 않습니다.
타임 트래블(Time Travel)
Iceberg는 데이터의 변경 이력을 추적합니다. "어제 오전 10시 시점의 데이터를 보여줘"라고 쿼리할 수 있습니다. 실수로 데이터를 삭제했을 때 이전 시점으로 복구하거나, 특정 시점의 스냅샷을 분석에 사용할 때 매우 유용합니다.
스키마 진화(Schema Evolution)
기존 데이터를 다시 쓰지 않고 테이블 스키마를 변경할 수 있습니다. 새 컬럼 추가, 기존 컬럼 이름 변경, 컬럼 삭제 — 이 모든 것이 S3에 저장된 기존 파일을 건드리지 않고 가능합니다. 이전 데이터는 새 스키마와 호환되어 정상 작동합니다.
Iceberg는 Amazon Athena, Amazon EMR, AWS Glue, Redshift Spectrum과 완전히 호환됩니다.
AWS Lake Formation — 데이터 레이크의 보안 관리자
Lake Formation은 S3 기반 데이터 레이크를 구축하고 세밀한 보안 정책을 관리하는 서비스입니다. 건물의 출입 관리 시스템에 비유하면, Lake Formation은 "어떤 직원이 어떤 층의 어떤 방에 접근할 수 있는지"를 관리합니다.
세분화된 접근 제어(Fine-Grained Access Control)
Lake Formation은 데이터 레이크의 접근 권한을 매우 세밀하게 제어합니다:
데이터베이스/테이블 수준: 특정 팀은 특정 테이블만 볼 수 있습니다. 열(Column) 수준: HR 부서는 "급여" 열을 볼 수 있지만, 다른 부서는 볼 수 없습니다. 행(Row) 수준: 영업팀은 자신의 지역 데이터만 볼 수 있습니다. 셀(Cell) 수준: 특정 사용자는 특정 행의 특정 열만 볼 수 있습니다.
이런 세밀한 제어는 IAM 정책만으로는 구현하기 어렵습니다. Lake Formation이 이 복잡한 권한 관리를 중앙에서 처리합니다.
데이터 필터(Data Filters)
Lake Formation의 데이터 필터를 사용하면 동일한 물리적 테이블에서 사용자마다 다른 뷰를 보여줄 수 있습니다. 예를 들어 전 세계 고객 데이터가 있는 테이블에서, 미국 팀은 US 고객만, 유럽 팀은 EU 고객만 볼 수 있도록 설정합니다. 물리적 데이터는 하나이지만, 접근 권한에 따라 필터링되어 보입니다.
Glue Data Catalog와의 통합
Lake Formation은 AWS Glue Data Catalog를 메타데이터 저장소로 사용합니다. Glue Crawler가 데이터를 스캔해 테이블 메타데이터를 카탈로그에 등록하면, Lake Formation이 그 테이블에 대한 접근 권한을 관리합니다. Athena, Redshift Spectrum, EMR은 모두 Glue Data Catalog를 통해 Lake Formation의 권한 제어를 받습니다.
시험 핵심 정리
| 키워드 | 선택 서비스/개념 | |--------|----------------| | 대규모 OLAP, SQL 집계 분석 | Amazon Redshift | | S3 데이터를 Redshift에 로드하지 않고 SQL 쿼리 | Redshift Spectrum | | 여러 소스(RDS, S3, Redshift) 데이터를 하나의 SQL로 | Federated Query | | 피크 시간 쿼리 급증 처리 | Concurrency Scaling | | 컴퓨팅과 스토리지 독립 스케일링 | Redshift RA3 인스턴스 | | S3 데이터에 ACID 트랜잭션 | Apache Iceberg | | 특정 시점의 데이터 조회 | Iceberg 타임 트래블 | | 기존 데이터 재작성 없이 스키마 변경 | Iceberg 스키마 진화 | | 데이터 레이크 열/행 수준 접근 제어 | AWS Lake Formation | | 사용자별 다른 행/열 뷰 제공 | Lake Formation 데이터 필터 | | 키-값 조회, 밀리초 응답 | Amazon DynamoDB |
Iceberg의 핵심 메시지: "데이터 레이크(S3의 저렴함과 확장성)에 데이터 웨어하우스 수준의 기능(ACID, 타임 트래블, 스키마 진화)을 더한다."