Amazon DEA-C01: 데이터 저장 및 레이크 아키텍처 — 학습 가이드

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

다음의 일부입니다: Amazon Data Engineer Associate DEA-C01 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

이 도메인은 AWS 스토리지 서비스와 데이터베이스 엔진이 최신 데이터 플랫폼에서 대규모 데이터 수집, 영구적 아카이빙, 쿼리 성능, 안전한 거버넌스를 어떻게 지원하는지 다룹니다. 데이터 엔지니어는 S3, Lake Formation, Redshift, DynamoDB와 같은 서비스를 파이프라인에 통합하면서 비용, 액세스 지연 시간, 내구성, 세분화된 액세스 제어 간의 균형을 맞춰야 합니다. 스토리지 클래스 간의 장단점, 수명 주기 자동화, 관리형 스토리지와 로컬 스토리지 비교, 파티셔닝 패턴을 이해하면 프로덕션 환경에서 성능 및 비용 관련 예기치 않은 문제를 방지할 수 있습니다.

Amazon S3 스토리지 클래스 및 수명 주기 정책

S3는 비용과 액세스 패턴을 최적화하기 위해 여러 스토리지 클래스와 수명 주기 제어 기능을 제공합니다. 업로드 시 스토리지 클래스를 구성하거나(콘솔 또는 CLI: aws s3 cp file s3://bucket/key –storage-class INTELLIGENT_TIERING) 버킷 수명 주기 규칙을 사용할 수 있습니다(aws s3api put-bucket-lifecycle-configuration –bucket my-bucket –lifecycle-configuration file://lifecycle.json). Intelligent-Tiering은 객체를 빈번한 액세스 계층과 드문 액세스 계층 간에 자동으로 이동시키며, 소액의 모니터링 요금이 부과됩니다. 액세스 패턴을 알 수 없거나 변경될 때 이 기능을 활성화하세요. 수명 주기 규칙을 사용하여 객체를 장기 보존을 위해 GLACIER 또는 DEEP_ARCHIVE로 전환하고 오래된 버전을 만료/삭제할 수 있습니다.

결정 기준 및 장단점:

Intelligent-Tiering: 가변적인 액세스에 대한 운영 오버헤드가 낮고, 객체당 월별 모니터링 요금이 부과됩니다. 액세스 패턴을 예측할 수 없을 때 가장 좋습니다.
Glacier vs Glacier Deep Archive: Glacier는 더 높은 스토리지 비용으로 더 빠른 표준 및 신속 검색 옵션을 제공합니다. Deep Archive는 대량/표준 검색 시간(수 시간)이 소요되지만 수년간의 장기 보존에 가장 저렴합니다.
Standard-IA vs Intelligent-Tiering: Standard-IA는 30일 최소 요금 및 검색 요금이 있습니다. 자주 액세스하는 데이터나 수명이 짧은 객체에는 사용을 피하세요.

운영 참고 사항:

불변성을 위해 버전 관리(aws s3api put-bucket-versioning –bucket my-bucket –versioning-configuration Status=Enabled)와 객체 잠금(aws s3api put-object-lock-configuration –bucket my-bucket –object-lock-configuration file://lock.json)을 활성화하세요. MFA Delete를 활성화하려면 특별한 CLI 작업과 MFA가 활성화된 버킷 소유자 계정이 필요합니다.
수명 주기 전환은 객체 버전에 적용되며 접두사/태그로 범위를 지정할 수 있습니다. 스토리지 누수를 방지하려면 abort-incomplete-multipart-upload를 사용하세요.

S3 및 Lake Formation을 사용한 데이터 레이크 설계

S3를 중앙 객체 스토어로, Lake Formation을 중앙 집중식 액세스 제어 및 카탈로깅 도구로 사용하여 데이터 레이크를 설계합니다. S3 위치를 Lake Formation 리소스로 등록하고, AWS Glue Data Catalog를 설정한 후, 데이터베이스/테이블에 Lake Formation 권한을 부여합니다(aws lakeformation grant-permissions –principal arn:aws:iam::123456789012:user/analyst –permissions SELECT –resource ‘{…}’). Lake Formation은 LF-태그와 Glue/Athena 쿼리에 적용되는 데이터 필터를 사용하여 열 수준, 행 수준(필터 표현식), 셀 수준 마스킹과 같은 세분화된 제어를 적용할 수 있습니다.

주요 구성 및 거버넌스 패턴:

위치 등록: Lake Formation 콘솔을 사용하여 s3://bucket/path를 등록하고, Lake Formation이 크롤링/읽기를 할 수 있도록 허용하는 IAM 역할을 연결합니다.
세분화된 정책: LF-태그를 정의하고 테이블/열에 연결합니다. column-list와 함께 권한을 부여하여 열을 제한하고, row-filter 표현식을 사용하여 보안 주체에게 반환되는 행을 제한합니다.
Lake Formation 권한은 Glue/Athena 액세스에 대한 IAM S3 권한을 재정의하거나 차단할 수 있다는 점을 기억하세요. 필요한 경우 Lake Formation과 S3 수준 액세스 권한을 모두 부여해야 합니다.

결정 포인트:

중앙 집중식 카탈로깅, LF-태그, 여러 분석 엔진에 걸친 세분화된 정책 적용이 필요할 때 Lake Formation을 사용하세요.
간단한 액세스 제어나 외부 도구 액세스의 경우 S3 버킷 정책과 IAM을 고려할 수 있지만, Lake Formation의 관리를 받는 분석 엔진은 IAM 전용 권한 부여를 무시할 수 있으므로 주의해야 합니다.

Amazon Redshift 아키텍처 및 스토리지

Redshift는 RA3 노드의 컴퓨팅 및 관리형 스토리지와 DS2 노드의 로컬 SSD 기반 스토리지를 분리합니다. RA3 노드는 Redshift Managed Storage(RMS)를 사용하며, 데이터는 클러스터에서 관리하는 Amazon S3에 상주합니다. 일관된 쿼리 성능을 제공하는 확장 가능한 스토리지와 컴퓨팅 비용을 별도로 지불할 수 있는 기능이 필요할 때 RA3를 선택하세요. DS2 노드는 인스턴스 로컬 디스크에 데이터를 저장하므로 데이터가 증가할 때 신중한 크기 조정 및 크기 변경이 필요합니다.

구성 및 운영 세부 정보:

콘솔 또는 CLI를 통해 RA3 클러스터 생성: aws redshift create-cluster –cluster-identifier my-cluster –node-type ra3.xlplus –number-of-nodes 2 –master-username admin –master-user-password Passw0rd.
COPY 명령: S3 읽기 액세스 권한을 부여하는 IAM 역할이 연결된 클러스터에서 실행해야 합니다. 클러스터 생성 시 역할을 연결하거나 클러스터를 수정하여 iam roles를 추가합니다. 역할 ARN(arn:aws:iam::acct:role/RedshiftS3Role)은 COPY에서 credentials ‘aws_iam_role=arn:…‘로 참조됩니다.
WLM 큐, 짧은 쿼리 가속, 자동 vacuum을 모니터링하고 SORT/ENCODE를 사용하여 스토리지와 성능을 최적화합니다.

비교 (RA3 vs DS2):

RA3: 분리된 스토리지, S3로의 자동 데이터 티어링, 스토리지 관리 부담 감소, 증가하는 데이터 세트에 가장 적합합니다.
DS2: 로컬 SSD 스토리지, 로컬 데이터에 대한 지연 시간은 짧지만 용량이 제한되고 확장이 더 어렵습니다.

DynamoDB 및 용도별 데이터베이스 선택

한 자릿수 밀리초의 지연 시간이 필요한 대규모 키-값 및 문서 워크로드의 경우 DynamoDB를 선택합니다. 테이블 설계는 파티션 키(및 선택적 정렬 키) 선택에 따라 결정됩니다. 핫 파티션을 방지하려면 카디널리티가 높고 잘 분산된 키를 사용하십시오. 순차적 또는 타임스탬프 기반 키의 경우, 무작위 접두사 추가(샤딩)를 구현하거나 UUID를 사용하여 쓰기를 분산시키십시오. 프로비저닝을 피하려면 온디맨드 용량을 사용하되, 예측 가능한 워크로드와 핫 파티션에 대한 적응형 용량을 활용하려면 오토스케일링을 사용하는 프로비저닝된 용량을 고려하십시오.

실용적인 구성 참고 사항:

테이블 생성 CLI: aws dynamodb create-table –table-name Events –attribute-definitions AttributeName=pk,AttributeType=S AttributeName=sk,AttributeType=S –key-schema AttributeName=pk,KeyType=HASH AttributeName=sk,KeyType=RANGE –billing-mode PAY_PER_REQUEST.
대체 액세스 패턴에는 GSI를 사용하고, 자동 만료에는 TTL을 활성화하며, 데이터 변경 캡처 패턴에는 DynamoDB Streams + Lambda를 사용합니다.
읽기 중심 워크로드 캐싱을 위해서는 DAX를 추가하고, 복잡한 쿼리나 관계형 요구사항이 있는 경우 쿼리 복잡성 및 일관성 요구사항에 따라 Aurora 또는 Redshift Spectrum을 선택합니다.

엔진 선택을 위한 결정 기준:

예측 가능한 단일 테이블 액세스 패턴과 짧은 지연 시간의 대규모 확장이 필요할 경우 DynamoDB를 사용합니다.
복잡한 분석 및 대규모 OLAP에는 Redshift를 사용합니다.
트랜잭션 기반 관계형 워크로드에는 Aurora를 사용합니다.

일반적인 실수 및 결정 기준

자주 액세스하는 데이터에 S3 Standard-IA 사용 — Standard-IA는 최소 30일의 요금이 부과됩니다. 수명이 짧거나 자주 액세스하는 객체에는 Standard 또는 Intelligent-Tiering을 사용하십시오.
Glue/Athena에 대한 Lake Formation 권한이 IAM S3 권한을 재정의한다는 사실을 간과 — Glue/Athena를 사용할 때는 Lake Formation과 S3 액세스 권한을 모두 부여하고 Lake Formation 콘솔에서 유효 권한을 확인하십시오.
Redshift COPY는 사용자 권한뿐만 아니라 클러스터에 연결된 IAM 역할이 필요 — S3 액세스 IAM 역할을 클러스터에 연결하고 COPY 작업에서 해당 ARN을 참조하십시오.
순차적 키로 인한 DynamoDB 핫 파티션 — 단조 증가/감소 키를 피하고, 해시 키, 무작위 접두사 또는 UUID를 사용하고 온디맨드 또는 오토스케일링되는 프로비저닝된 용량을 고려하십시오.
S3 객체 잠금 및 MFA 삭제의 잘못된 활성화 — 객체 잠금은 버전 관리가 활성화되어야 하고 적절한 권한이 필요합니다. MFA 삭제는 MFA를 사용하여 CLI로만 활성화/비활성화할 수 있으며 엄격한 버킷 소유자 요구사항이 있습니다.
검색 비용 및 시간을 테스트하지 않고 부적절한 수명 주기 전환 수행 — Glacier 클래스에 대한 검색 워크플로우를 테스트하여 예상치 못한 검색 지연 및 요금을 방지하십시오.

실제 문제: 사용 사례 시나리오

Acme Media는 50TB의 원본 비디오 수집 데이터를 저장하고, 분석가에게 변환된 메타데이터에 대한 쿼리 액세스를 제공하며, 스토리지 비용을 최소화하면서 여러 사업부에 대해 행 및 열 수준 액세스를 강제해야 합니다.

멀티파트 업로드를 사용하여 원본 비디오를 S3에 수집하고, 수집 날짜 및 데이터 세트별로 객체를 태깅하며, 초기 액세스 패턴을 알 수 없으므로 Intelligent-Tiering을 사용합니다.
구성 가능한 보존 기간이 지나면 미디어를 GLACIER 또는 DEEP_ARCHIVE로 전환하도록 수명 주기 규칙을 구성합니다(Standard-IA를 고려하는 경우 30일 이상 보관 기간과 일치하도록 보장).
Lake Formation에 S3 위치를 등록하고, Glue 크롤러를 구축하여 데이터 카탈로그를 채우며, 사업부에 LF-태그 기반 행 및 열 수준 권한을 부여합니다.
분석을 위해 큐레이션된 메타데이터를 Redshift RA3에 저장합니다. S3로부터의 COPY 작업을 위해 클러스터에 IAM 역할을 연결하고, 유지 관리 기간에 VACUUM/ANALYZE 작업을 사용합니다.
비디오 매니페스트의 처리량이 높은 조회 테이블에 해시된 UUID 키를 사용하는 DynamoDB를 사용하고, 트래픽 급증을 흡수하기 위해 온디맨드 용량을 활성화합니다.

근거: 이 접근 방식은 Glacier 클래스를 사용하여 콜드 스토리지 비용을 분리하고, 알 수 없는 패턴에 Intelligent-Tiering을 사용하며, 분석 엔진 전반에 걸쳐 안전하고 세분화된 액세스 제어를 위해 Lake Formation을 적용하고, 확장 가능한 분석 스토리지를 위해 RA3를 선택하는 동시에 DynamoDB가 지연 시간이 짧은 운영 조회를 처리하도록 합니다.

← 데이터 인제스천 및 수집 · 모든 도메인 · 데이터 카탈로깅 및 메타데이터 관리 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →