안녕하세요, AI 서비스 & 솔루션 프로바이더 베스핀글로벌입니다.
AWS re:Invent 2025의 [Maximize the value of cold data with Amazon S3 Glacier storage classes]을 확인해보시기 바랍니다.

Maximize the value of cold data with Amazon S3 Glacier storage classes

1. 콜드 데이터의 중요성과 S3 Glacier 스토리지 클래스 개요

1-1. 콜드 데이터의 중요성

S3에는 현재 수백조 개의 객체가 있으며, 데이터의 70~80%가 콜드 데이터로 추정됩니다.

• 콜드 데이터 정의: 몇 달, 몇 년, 심지어 수십 년 동안 거의 접근되지 않는 데이터입니다.
• 가치 증가: 이러한 데이터의 양은 매일 증가하고 있으며, 산업 전반에서 그 가치가 커지고 있습니다.
• 혁신의 촉매제: 콜드 데이터는 더 이상 저장만 되고 잊히는 것이 아니라, 혁신의 촉매제이자 비즈니스의 차별화 요소로 부상하고 있습니다.
  • 고객들은 잠자고 있던 데이터를 활용하여 실행 가능한 인텔리전스를 얻고 있습니다.
  • 활용 예시:
    • 역사적인 필사본 기록을 활용한 머신러닝 훈련.
    • 보관된 분석 데이터에서 새로운 인사이트 도출.
    • 금융/주식 데이터를 활용한 신규 애플리케이션 구축.
• 목표: 모든 콜드 데이터 바이트를 기회로 전환하는 것이 중요합니다.

1-2. S3 스토리지 클래스 연속체

 스토리지 클래스는 접근 속도와 비용 효율성이라는 두 가지 핵심 요소를 균형 있게 조정하는 연속체로 이해할 수 있습니다.

• 자주 접근 데이터 (왼쪽): 밀리초(millisecond) 단위 접근이 가능하지만 비용이 높습니다.
• 점점 차가워지는 영역 (오른쪽): 접근 빈도는 낮아지지만, 스토리지 비용은 크게 감소합니다.

1-3. 주요 스토리지 클래스

• S3 Standard: 활성 데이터에 대한 밀리초 접근을 제공합니다.
• S3 Standard 및 S3 One Zone-IA: 이 단계부터 비용 절감이 시작됩니다.
• Glacier 계층: 콜드 데이터에 대한 진정한 마법이 일어나는 곳입니다.
  • Glacier Instant Retrieval: 밀리초 접근이 필요하지만 보관된 데이터에 적합합니다. (예: 의료 기록, 마감 기한이 촉박한 아카이브 클립, 규정 준수 요구 사항이 있는 데이터)
  • Glacier Flexible Retrieval: 몇 분 내에 데이터 접근이 필요한 경우에 사용됩니다. (예: 대규모 데이터 분석, 유연한 타이밍의 백업 아카이브, 가끔 대량 처리가 필요한 기록)
    • 특징: 무료 대량 검색(free bulk retrievals)이 가능합니다.
  • Glacier Deep Archive: 클라우드에서 가장 낮은 비용의 스토리지 옵션입니다
    • 용도: 법적으로 보관해야 하지만 사용하지 않기를 바라는 데이터의 장기 보존(수년 또는 수십 년)에 사용됩니다.
• 비용 최적화: 데이터가 자연스럽게 냉각되고 접근 패턴이 감소함에 따라 이러한 계층을 점진적으로 이동하여 필요할 때 검색 능력을 희생하지 않으면서 스토리지 비용을 지속적으로 최적화할 수 있습니다.

2. 데이터 수명 주기 관리 및 접근 패턴이 불규칙한 경우

2-1. S3 수명 주기 정책 (Life Cycle Policies)

데이터를 스토리지 클래스로 전환하고 관리하는 방법입니다.

• 기능: 데이터가 냉각됨에 따라 비정기적 액세스 또는 아카이브 스토리지 클래스로 전환할 수 있으며, 수명 종료 시 데이터를 자동으로 삭제할 수 있습니다.
• 비용 제어: 알려진 접근 패턴을 기반으로 비용을 자동으로 제어할 수 있습니다.
• 자동 전환 예시:
  • Day 0에 생성되어 처음 90일 동안 자주 접근되다가 그 이후 드물게 접근되는 객체는 90일 후 Glacier Instant Retrieval로 자동 전환됩니다. (접근 시 밀리초 응답)
  • 180일 후 접근이 극히 드물어지면, 비용 최적화를 위해 Glacier Deep Archive로 전환할 수 있습니다.
• 자동 삭제: 금융 산업과 같이 7~10년 보관 요구 사항이 있는 경우, 해당 기간 종료 시 데이터를 자동으로 삭제하도록 정책을 설정할 수 있습니다.
• 필터링 옵션: 수명 주기 정책에 적용할 수 있는 다양한 필터가 제공됩니다.
  • 전체 버킷에 적용 가능합니다.
  • 특정 접두사(prefix) 또는 객체 태그와 일치하는 객체에 적용 가능합니다.
  • 객체 크기로 필터링 가능합니다. (작은 객체 다수를 아카이브 전송 방지 시 유용)
    객체 버전 수로 필터링 가능합니다. (불필요한 버전 생성을 방지)

2-2. S3 Intelligent-Tiering

접근 패턴이 예측 불가능하거나 불규칙한 경우를 위한 스토리지 클래스입니다.

• 목적: 데이터 접근 패턴이 변경될 때 성능 영향, 운영 오버헤드, 수명 주기 수수료 또는 검색 수수료 없이 스토리지 비용을 자동으로 최적화하도록 설계되었습니다.
• 작동 방식: 계층 간 데이터 이동을 통해 자동 절감 효과를 제공합니다.
• 계층 구조: 총 5개의 계층이 있습니다.
  • 동기식 계층 (3개): 가입 즉시 자동으로 제공됩니다.
  • 비동기식 계층 (2개): 사용자가 옵트인(opt-in)해야 합니다.
• 선택: 옵트인 후, Intelligent-Tiering이 자동으로 적절한 계층을 선택합니다.

3. 보관된 데이터 검색 및 복원 옵션

3-1. 데이터 검색의 필요성

스토리지 비용을 최적화한 후, 데이터가 다시 활성화(hot)될 때 발생하는 상황에 대비해야 합니다.

3-2. 고객의 데이터 복원 패턴

• 미디어 파일 재활용: 수십 년 된 영상을 현대 청중을 위한 콘텐츠로 변환하여 새로운 생명을 불어넣고 있습니다.
• 전략적 가치 활용: 백업 및 규정 준수를 넘어, 역사적 기록을 활용하여 장기 패턴을 추적하고 미래 결정을 알리고 있습니다.
• 머신러닝 연료: 콜드 데이터는 머신러닝 모델의 로켓 연료 역할을 하며, 과거 데이터 훈련을 통해 이전에는 볼 수 없었던 패턴을 발견할 수 있습니다.
  • 예시: 자율 주행차 기술 개발 시, 좌회전 관련 모든 콘텐츠를 복원하여 모델 훈련에 사용할 수 있습니다.
• 메타데이터 생성: 아카이브 콘텐츠에서 풍부한 메타데이터를 생성하여 방대한 데이터 링크를 검색 가능하고 실행 가능하게 만들고 있습니다.

3-3. Glacier 스토리지 클래스별 접근 방법

• Glacier Instant Retrieval
  • 접근: Standard 및 Intelligent-Tiering과 동일한 요청을 사용하며 밀리초 접근이 가능합니다.
    단점: 검색 및 API 요금이 더 높습니다.
  • 장점: 애플리케이션 변경 없이 스토리지 비용을 절감할 수 있습니다.
• Glacier Flexible Retrieval 및 Deep Archive
  • 접근 시간: 몇 분에서 몇 시간, 며칠까지 견딜 수 있는 검색에 적합합니다.
  • 비용: 스토리지 비용과 대량 데이터 검색 비용을 모두 절감할 수 있습니다.
  • 전제 조건: 데이터 접근 전에 요청(request)이 필요합니다.
  • 복원 후: 복원된 후에는 일반적인 get 요청을 통해 객체를 가져올 수 있습니다.

3-4. Glacier 검색의 3단계 프로세스

Flexible Retrieval 및 Deep Archive에 적용됩니다.

• 1단계: 요청 초기화: 복원 요청을 시작해야 합니다.
• 2단계: 복원 완료 확인: 복원이 완료되었는지 확인해야 합니다.
• 3단계: 데이터 액세스: 복원된 데이터에 접근합니다.

3-5. 1단계 상세: 요청 제출

• 대규모 복원 시 고려 사항: 수백만 또는 수십억 개의 객체 복원 시, 모든 요청을 제출하는 데 걸리는 시간을 고려해야 합니다.
• 요청 속도 제한: Glacier는 초당 1,000건의 트랜잭션(TPS)을 지원하며, 이는 Flexible Retrieval 및 Deep Archive의 모든 표준 및 대량 검색 요청에 적용됩니다.
• 시간 계산 예시: 1,000 TPS 기준으로 1,000만 건의 복원 요청을 3시간 이내에 제출할 수 있으며, 표준 복원(Flexible Retrieval 기준) 시 총 복원 완료까지 약 6시간이 소요됩니다 (제출 3시간 + 복원 3~5시간).
• 성능 극대화: 배치 작업(Batch Operations)을 활용하여 TPS를 최대화하고 자동 재시도를 이용할 수 있습니다.

3-6. 2단계 상세: 복원 상태 모니터링

• 이벤트 발행: S3는 복원 시작 및 완료 시 이벤트를 생성하며, 이를 Amazon EventBridge로 발행할 수 있습니다.
• 팬아웃 구성: EventBridge를 통해 SNS 토픽이나 SQS 큐로 이벤트를 팬아웃(fan out)하거나 Lambda 함수를 트리거할 수 있습니다.
• 자동 후속 조치: 완료 이벤트를 SNS 토픽으로 보내면, 애플리케이션이 구독하여 객체 복원 즉시 get 또는 copy와 같은 다음 단계로 자동 진행할 수 있습니다.

3-7. 3단계 상세: 복원된 데이터 액세스

• 접근 방식: 객체가 복원되면 S3 Standard 객체처럼 get 요청 또는 동기식 계층에서처럼 다른 방식으로 접근할 수 있습니다.
• 팁: 복원된 데이터는 객체의 임시 복사본입니다.
  • 데이터를 Glacier에서 이동시키려면 동일 키에 덮어쓰기 복사(copy)를 하거나 새 버킷에 복사해야 합니다.
  • 동일 키에 복사 시, 추가 버전을 유지하고 싶지 않다면 버전 관리에 유의해야 합니다.

3-8. 배치 작업(Batch Operations) 활용

• 문제점: 초당 1,000 TPS 미만의 요청을 처리할 경우, 요청 제출 시간이 길어져 총 복원 시간이 최대 40배까지 증가할 수 있습니다 (예: 25 TPS 요청 시).
• 해결책: 소프트웨어 최적화나 멀티스레딩 대신 배치 작업을 사용하여 복원 경험을 극적으로 개선할 수 있습니다.
  • 배치 작업은 초당 복원 요청을 자동으로 최대화하고, 오류 발생 시 자동 재시도를 수행하며, 완료 보고서를 제공합니다.
• 작업 생성: 복원할 키 목록(매니페스트)을 생성하여 배치 작업에 제출하면, 작업이 TPS를 분할하여 처리합니다.

4. 새로운 아카이브 관련 기능 소개

4-1. 보관된 데이터의 무결성 검사: Compute Checksum Operation

• 해결하려는 문제: 미디어/엔터테인먼트, 생명 과학, 법 집행, 보존 기관 등에서 데이터 무결성을 확인하기 위해 주기적인 데이터 무결성 검사를 수행해야 합니다.
  • 검증의 중요성: 이는 업계 표준이며, 고객들은 S3에서 이러한 검사를 수행할 도구를 요청했습니다.
  • 선택 사항: S3는 전송 중 및 저장 중인 모든 바이트의 무결성을 보장하기 위해 초당 수십억 건의 체크섬 연산을 수행하지만, 이 기능은 고객이 자체적으로 검사를 수행할 수 있도록 돕는 선택적 기능입니다.
• 체크섬 기본 개념
  • 정의: 체크섬은 객체의 디지털 지문입니다.
  • 작동 원리: CRC32와 같은 알고리즘을 사용하며, 단 하나의 비트라도 변경되면 다른 체크섬 값이 생성됩니다.
  • 검증 과정: 고객은 원본 체크섬 값을 진실 공급원(Source of Truth)으로 저장해 두었다가, 나중에 객체의 최신 체크섬을 계산하여 비교함으로써 데이터가 손상되지 않았음을 증명합니다.
• 기존 검증 방식의 문제점
  • 과거 방식: 기존에는 객체를 다운로드해야 했으며, 이는 대역폭 비용과 시간이 소요됩니다.
  • 추가 비용: 이후 EC2 인스턴스 등을 사용하여 로컬에서 체크섬을 계산해야 했으므로 추가적인 컴퓨팅 비용과 시간이 발생했습니다.
  • 필요성: 객체 다운로드 및 로컬 계산 단계를 제거하고, 인플레이스(in-place) 읽기를 통해 새로운 체크섬을 계산하는 혁신적인 방법이 필요했습니다.
• Compute Checksum Operation
  • 특징: S3 배치 작업(Batch Operations) 내의 새로운 기능으로, Glacier를 포함한 모든 스토리지 클래스에 저장된 데이터 세트의 콘텐츠를 효율적으로 검증하고 데이터 무결성 보고서를 자동으로 생성합니다.
  • 적용 범위: 스토리지 클래스나 객체 크기에 관계없이 S3의 모든 객체에 작동합니다.
  • 이점: 규정 준수, 디지털 보존, 모델 피딩 전 정확성 확인 시 시간, 비용, 노력을 줄일 수 있습니다.
  • 배치 작업 통합: 실패 시 자동 재시도 및 상세 완료 보고서(데이터 무결성 보고서로 사용 가능)를 제공합니다.
• 작업 생성 방법 (3가지 구성 요소):
  • 객체 목록 제공 (매니페스트):
    • 큐레이션된 목록을 CSV 파일로 제출하거나, S3 배치 작업의 자동 매니페스트 생성 서비스를 사용할 수 있습니다.
    • 인벤토리 보고서를 매니페스트로 사용할 수도 있습니다.
  • 체크섬 알고리즘 선택: 업로드 시 지원되는 모든 알고리즘(CRC32, CRC32C, CRC64, MD5, SHA1, SHA256)이 지원됩니다.
    • 규정 준수/보안 중시: SHA 1 또는 SHA 256과 같은 보안 해시 알고리즘을 선택합니다.
    • 성능 중시: CRC 64, 32, 또는 32C를 선택할 수 있습니다.
  • 체크섬 유형 지정:
    • 전체 객체(Full Object): 미디어 공급망 등에서 표준화된 검증이 필요할 때 사용합니다.
    • 복합(Composite): 내부적으로 사용하며, 대규모 객체에 대해 병렬 체크섬 연산을 수행할 때 사용합니다.
  • 권한: S3 배치 작업이 바이트를 읽고 완료 보고서를 작성할 수 있도록 IAM 권한을 제공해야 합니다.
• 결과 및 비용
  • 완료 보고서: 버킷, 키, 버전 ID, 오류 코드, 결과 메시지 (체크섬 값 포함) 필드를 포함합니다.
  • 자동화: Lambda 함수를 사용하여 주기적으로 이 작업을 자동화할 수 있습니다.
  • 비용: 복원 또는 검색에 대한 수수료는 발생하지 않습니다. Intelligent-Tiering 데이터가 워밍업되지 않으며 Glacier 객체를 복원할 필요가 없습니다.
  • 처리 비용: 데이터를 처리하는 데 GB당 $0.004 (TB당 $4)의 단일 요금이 부과되며, 이는 모든 스토리지 클래스에서 일관됩니다.

4-2. S3 메타데이터를 활용한 빠른 검색

• S3 메타데이터 소개: 작년 re:Invent에서 출시되었으며 개선되었습니다.
  • 기능: 객체에서 메타데이터를 자동으로 추출하여 단순 SQL 쿼리 또는 자연어를 사용하여 가치 있는 인사이트를 생성할 수 있게 합니다.
  • 목표: 고객이 콜드/아카이브 데이터에서 가치를 추출하는 방식을 근본적으로 변화시키는 것입니다.
• 해결하려는 문제 (기존 방식의 비효율성):
  • 상황: 수백만 개의 아카이브된 객체가 있는 버킷에 Project Odin, Loki, Thor 등의 태그가 지정되어 있고, 일부는 Glacier, 일부는 Standard에 있습니다.
  • 질문: "Project Odin에 속하며 Glacier에 있는 모든 데이터를 Standard로 이동하려면 얼마나 많은 데이터가 필요합니까?"
  • 기존 옵션:
    • API 요청(list, get object tags)을 페이지네이션하여 스토리지 스캔 및 클래스별 계산.
    • S3 인벤토리 보고서 사용 (일 2회 또는 48시간마다 새로 고침).
  • 문제: 이 두 옵션 모두 대규모에서 시간 지연이 발생하거나 수행하기 쉽지 않습니다.
  • 개선 목표: 단일 쿼리 작성만으로 몇 초 만에 이 질문에 답할 수 있도록 하는 것입니다.
• S3 메타데이터 작동 방식
  • 서비스: 모든 객체 메타데이터(태그, 스토리지 클래스, 크기 등)를 자동으로 캡처하여 쿼리 가능한 Apache Iceberg 테이블에 저장하는 완전 관리형 서비스입니다.
    장점: API 호출이나 인벤토리 보고서 대기 없이 즉각적인 SQL 쿼리가 가능합니다.
• 메타데이터 테이블 유형
  • 저널 테이블 (Journal Table): 작년에 출시되었으며, 버킷에서 발생하는 모든 변경 사항(Put, Delete, 태그 변경 등)을 거의 실시간으로 캡처합니다. 버킷의 전체 변경 로그 역할을 합니다.
  • 라이브 인벤토리 테이블 (Live Inventory Table): 올해 7월에 추가되었으며, 버킷의 모든 객체에 대한 현재 상태를 보여줍니다. 활성화 시 기존 데이터를 백필(backfill)하며 매시간 새로 고침됩니다.
  • 특징: 두 테이블 모두 읽기 전용이며 AWS에서 관리하며, 버킷 내 모든 항목에 대한 권위 있는 기록 시스템으로 간주됩니다.
• 메타데이터 테이블 쿼리 방법
  • 표준 SQL 쿼리: Athena, Redshift, SageMaker Unified Studio 등 Iceberg 테이블을 지원하는 모든 분석 도구를 통해 가능합니다.
  • 자연어: Amazon Q, Kirro 또는 MCP 서버를 지원하는 에이전트를 통해 가능합니다.

• 쿼리 활용 예시
  • 스토리지 사용량 파악: "프로젝트별 Glacier 데이터가 얼마나 있습니까?"라는 SQL 쿼리로 스냅샷을 얻을 수 있습니다.
  • 분류: 태그가 지정되지 않은 모든 객체를 식별하여 적절하게 분류할 수 있습니다.
  • 감사: 저널 테이블을 사용하여 삭제된 데이터, 삭제 주체, 시점, 위치 등을 추적할 수 있습니다.

• 자연어 접근의 민주화
  • MCP 서버 지원: 최근 S3 테이블에 대한 MCP 서버 지원이 추가되어 AI 비서(예: 클라우드 맞춤형 에이전트, Kirro)를 메타데이터 테이블에 직접 연결할 수 있습니다.
  • 이점: 데이터 엔지니어/과학자가 아니더라도 재무, 운영, 규정 준수 팀 등 누구나 일반 영어로 질문하면 에이전트가 쿼리로 변환하여 요약 형태로 인사이트를 제공받을 수 있습니다.

5. 데모 시연: Compute Checksum 및 S3 메타데이터 통합

데모는 우주 기술 스타트업이 NASA 이미지/비디오를 사용하여 자율 우주 차량 시뮬레이션 모델을 훈련하는 시나리오를 가정합니다.

5-1. 데모 목표

• 인벤토리 테이블을 사용하여 Project Odin 관련 객체를 찾습니다.
• 이 객체들의 체크섬을 계산합니다.
• Kirro를 사용하여 배치 작업 완료 보고서의 체크섬을 객체 태그에 저장된 원본 체크섬과 비교 검증합니다.

5-2. 데이터 준비 및 태그 확인

• 데이터 위치: reinvent storage 208 demo 버킷에 NASA 웹사이트에서 다운로드한 이미지와 비디오가 Glacier Instant Retrieval 및 Standard 등 여러 스토리지 클래스에 저장되어 있습니다.
• 객체 태그: 객체 속성에는 SHA 256 알고리즘, 체크섬 타임스탬프, 프로젝트 이름(Odin), 기준 체크섬(원본 체크섬 16진수 코드) 등이 태그로 추가되어 있습니다. 일부 객체는 의도적으로 태그가 없습니다.

5-3. 매니페스트 생성 (라이브 인벤토리 테이블 사용)

• 쿼리 도구: SageMaker Unified Studio를 사용하여 라이브 인벤토리 테이블을 쿼리합니다.
• 쿼리 조건: 배치 작업에 사용 가능하도록 bucket과 key를 포함하고, WHERE object tags have project name as Odin 조건을 추가합니다.
• 결과: Project Odin과 관련된 25개 파일이 확인되었습니다.
• 포맷 조정: 배치 작업 수용 형식에 맞게 CSV 파일의 첫 번째 행을 제거하고 Odin manifest v2로 저장합니다.

5-4. S3 배치 작업 설정

• 버킷 준비: 매니페스트 저장용 버킷과 배치 작업 결과를 받을 대상 위치 버킷을 준비합니다.
• 작업 생성: 새 작업을 생성하고 기존 매니페스트(Odin manifest v2)를 선택합니다.
• 작업 유형 선택: Compute Checksum Operation을 선택합니다.
• 파라미터 설정: 체크섬 유형은 Full Object, 알고리즘은 SHA-256을 선택합니다.
• 중요 확인: 완료 보고서에 평문 데이터의 체크섬 값이 포함되므로, 버킷 소유자가 이 보고서에 접근할 수 있음을 인정(acknowledge)해야 합니다.
• 권한 및 제출: 대상 위치를 지정하고 S3 배치 체크섬용 IAM 역할을 부여한 후 작업을 제출하고 완료를 기다립니다.

5-5. 결과 확인 및 검증

• 보고서 확인: 배치 결과 폴더에서 완료 보고서를 열어봅니다.
• 결과 메시지: 결과 메시지 열에는 체크섬 알고리즘(SHA-256), 체크섬 유형(Full Object), 체크섬 값(Base64 및 Hex 코드)이 포함되어 있습니다.
• 최종 비교 (Kirro 사용): Kirro CLI를 사용하여 배치 작업 출력 CSV 파일 링크를 제공하고, Project Odin 체크섬을 검증하도록 지시합니다.
• 검증 결과: Kirro가 생성한 Python 스크립트를 통해 Project Odin과 관련된 25개 객체 모두가 태그로 저장된 체크섬과 일치함이 확인되었습니다.

6. 세션 요약 및 주요 시사점

6-1. AI 시대의 차별화: AI 발전과 함께 아카이브 데이터가 비즈니스의 차별화 요소가 될 수 있습니다.

6-2. 다양한 스토리지 옵션: S3는 접근 패턴, 스토리지 기간 또는 비용에 따라 특정 비즈니스 요구 사항에 맞춰진 다양한 스토리지 옵션을 제공합니다.

6-3. 새로운 기능: Compute Checksum Operation 및 S3 메타데이터와 같은 새로운 기능은 아카이브 데이터를 쉽게 관리하고 그 가치를 더 많이 추출할 수 있도록 돕습니다.