데이터에는 수명이 있습니다. 오늘 생성된 로그 파일은 내일도 자주 조회되지만, 3년 전 로그는 거의 열어보지 않습니다. 그럼에도 같은 비용의 스토리지에 저장하는 것은 낭비입니다. 데이터 수명 주기 관리는 데이터를 얼마나 오랫동안, 어떤 형태로 보관할지 계획하는 것입니다. 스키마 진화는 데이터 구조가 변해도 기존 데이터를 계속 읽을 수 있게 하는 기술입니다. DEA-C01 시험에서 이 두 개념은 비용 최적화와 운영 안정성 문제로 자주 출제됩니다.
S3 Lifecycle 정책
S3는 여러 스토리지 클래스를 제공합니다. 접근 빈도가 줄어들수록 저렴한 클래스로 데이터를 이동하면 비용을 크게 절감할 수 있습니다.
| 스토리지 클래스 | 특징 | 적합한 데이터 | |--------------|------|-------------| | S3 Standard | 빠른 접근, 높은 비용 | 자주 읽는 최신 데이터 | | S3 Standard-IA | 가끔 접근, 중간 비용 | 30일 이후 데이터 | | S3 Glacier Instant Retrieval | 드문 접근, 낮은 비용, 즉시 복구 | 90일 이후 데이터 | | S3 Glacier Flexible Retrieval | 드문 접근, 매우 낮은 비용, 수분~수시간 복구 | 장기 보관 아카이브 | | S3 Glacier Deep Archive | 거의 접근 안 함, 최저 비용, 12시간 복구 | 수년간 보관 규정 준수 데이터 |
Lifecycle 정책은 이 전환을 자동으로 처리합니다. 예를 들어 다음과 같이 설정할 수 있습니다.
생성 후 30일: Standard → Standard-IA로 자동 이동 생성 후 90일: Standard-IA → Glacier Instant Retrieval로 이동 생성 후 365일: Glacier Deep Archive로 이동 생성 후 2555일(7년): 자동 삭제
전환(Transition)은 데이터를 저렴한 클래스로 옮기는 것이고, 만료(Expiration)는 데이터를 자동으로 삭제하는 것입니다. Lifecycle 정책은 버킷 전체, 특정 prefix(폴더), 특정 태그가 붙은 객체에 적용할 수 있습니다.
DynamoDB TTL — 만료된 레코드 자동 삭제
DynamoDB는 NoSQL 데이터베이스입니다. 세션 데이터, 임시 토큰, 장바구니 정보처럼 일정 시간이 지나면 불필요해지는 데이터를 저장하는 데 자주 사용됩니다.
TTL(Time To Live)은 각 아이템에 만료 시간을 설정하는 기능입니다. 만료 시간이 지나면 DynamoDB가 자동으로 해당 아이템을 삭제합니다. 사용자가 직접 삭제 코드를 작성할 필요가 없습니다.
동작 방식: 테이블에 TTL 속성을 지정합니다 (예: ) 각 아이템에 Unix 타임스탬프 형식의 만료 시간을 저장합니다 DynamoDB가 백그라운드에서 만료된 아이템을 찾아 삭제합니다 삭제는 보통 만료 후 48시간 이내에 처리됩니다
주의사항: TTL 삭제는 무료입니다 (쓰기 용량 소비 없음) 만료 후 즉시 삭제되지 않으므로 애플리케이션에서 만료 여부를 직접 체크해야 합니다 DynamoDB Streams와 함께 사용하면 삭제 이벤트를 캡처해 추가 처리를 할 수 있습니다
Redshift 데이터 관리
Redshift는 페타바이트 규모의 데이터 웨어하우스입니다. 데이터를 효율적으로 넣고 빼는 방법이 중요합니다.
COPY 명령: S3, DynamoDB, EMR 등에서 Redshift로 데이터를 대량으로 로드합니다. 개별 INSERT보다 훨씬 빠릅니다.
UNLOAD 명령: Redshift에서 S3로 데이터를 내보냅니다. 분석 결과를 저장하거나 다른 시스템으로 전달할 때 사용합니다.
스냅샷: Redshift 클러스터 전체의 백업입니다. 자동 스냅샷(매 8시간 또는 매 5GB마다)과 수동 스냅샷이 있습니다. 스냅샷으로 다른 리전에 클러스터를 복원하거나 재해 복구에 사용할 수 있습니다.
스키마 설계 원칙
데이터를 어떻게 배열하느냐에 따라 조회 성능이 크게 달라집니다.
Redshift DISTKEY와 SORTKEY:
REDSHIFT는 데이터를 여러 노드에 분산 저장합니다. DISTKEY는 분산 기준 열을 지정합니다. 조인에 자주 사용되는 열을 DISTKEY로 지정하면 같은 키를 가진 데이터가 같은 노드에 모여 네트워크 통신이 줄어듭니다.
SORTKEY는 각 블록 내에서 데이터를 정렬하는 기준 열입니다. 날짜 범위 쿼리가 많다면 날짜 열을 SORTKEY로 지정하면 불필요한 블록을 건너뛰어 빠르게 조회할 수 있습니다.
DynamoDB 파티션 키: DynamoDB는 파티션 키를 기준으로 데이터를 분산합니다. 특정 파티션 키에 데이터가 몰리면 핫 파티션이 발생하고 성능이 저하됩니다. 파티션 키는 카디널리티(고유 값의 수)가 높을수록 좋습니다. 예를 들어 성별(남/여)보다 사용자 ID가 훨씬 좋은 파티션 키입니다.
S3 파티셔닝: S3에 저장할 때 데이터를 어떤 폴더 구조로 나눌지 결정합니다. Athena로 쿼리할 때 파티션을 활용하면 스캔하는 데이터 양을 줄여 비용과 속도를 모두 개선할 수 있습니다.
예시:
스키마 진화 — 데이터 구조가 바뀔 때
비즈니스는 변합니다. 오늘 설계한 데이터 구조가 6개월 후에 맞지 않을 수 있습니다. 스키마 진화는 기존에 저장된 데이터를 건드리지 않고 스키마를 변경하는 것입니다.
Apache Iceberg: 테이블 형식 레이어입니다. 컬럼 추가, 컬럼 타입 변경, 컬럼 삭제를 지원합니다. 타임 트래블 기능으로 과거 시점의 데이터를 조회할 수 있습니다. AWS Glue와 Athena에서 네이티브로 지원합니다.
Apache Avro: 스키마를 데이터와 함께 저장하는 직렬화 포맷입니다. 스키마가 변경되어도 이전 스키마로 작성된 데이터를 읽을 수 있습니다. Kafka와 조합해 스트리밍 데이터 스키마 진화에 자주 사용됩니다.
SCT(Schema Conversion Tool)와 DMS(Database Migration Service): 다른 데이터베이스 엔진 간 마이그레이션에 사용합니다. SCT는 오라클, SQL Server 등의 스키마를 Redshift나 Aurora에 맞게 변환합니다. DMS는 실제 데이터를 이전 데이터베이스에서 새 데이터베이스로 마이그레이션합니다.
데이터 계보 — 데이터의 여정 추적
데이터 계보(Data Lineage)는 데이터가 어디서 왔고, 어떤 변환을 거쳤고, 어디로 갔는지를 추적하는 것입니다. 금융 규제 준수, 감사, 오류 추적에 필수적입니다.
예를 들어 보고서의 숫자가 틀렸을 때, 계보 추적이 없으면 "원본 데이터 문제인가, ETL 변환 오류인가, 집계 쿼리 문제인가"를 하나씩 확인해야 합니다. 계보가 있으면 데이터가 이동한 경로를 역추적해 문제 지점을 빠르게 찾을 수 있습니다.
AWS에서 계보를 구현하는 방법: AWS Glue: 작업 실행 이력과 변환 단계를 자동으로 기록 Amazon DataZone: 조직 전체 데이터 자산의 계보 시각화 CloudTrail: API 호출 수준의 감사 로그 Lake Formation: 데이터 레이크 전체의 접근 기록
시험 핵심 정리
"오래된 데이터를 자동으로 저렴한 스토리지로" → S3 Lifecycle 정책 "DynamoDB 만료된 아이템 자동 삭제" → TTL "S3에서 Redshift로 대량 로드" → COPY 명령 "Redshift에서 S3로 데이터 내보내기" → UNLOAD 명령 "Redshift 조인 성능 최적화" → DISTKEY "Redshift 범위 쿼리 최적화" → SORTKEY "스키마 변경 후 과거 데이터도 읽기" → Apache Iceberg 또는 Avro "온프레미스 DB를 AWS로 마이그레이션" → SCT + DMS "데이터 이동 경로 추적" → 데이터 계보(Lineage)