Day 4 - S3 스토리지 관리와 비용 최적화

비용은 어디서 나오나

데이터 레이크는 시간이 갈수록 커지고, 데이터의 접근 빈도는 시간이 갈수록 떨어진다. S3 요금은 네 갈래로 나오며, 스토리지 클래스는 이 넷의 비율을 바꾼다.

여기에 객체당 요금이 붙는 경우가 둘 있다. Intelligent-Tiering 의 모니터링·자동화 요금, 그리고 Glacier Flexible Retrieval·Deep Archive 의 객체당 메타데이터 오버헤드다. 둘 다 객체 수에 비례하므로 작은 파일이 많은 레이크에서 문제가 된다.

S3 스토리지 클래스

• 내구성은 모든 클래스가 99.999999999%(11 9's)로 같다. 클래스 사이에서 달라지는 것은 가용성과 AZ 수다. One Zone-IA 만 AZ 하나에 저장되어 그 AZ 가 물리적으로 소실되면 데이터를 잃는다.
• "최소 과금 크기 128KB"는 그보다 작은 객체도 128KB 로 과금한다는 뜻이다. 수 KB 짜리 파일을 IA 로 보내면 Standard 보다 비쌀 수 있다.
• Glacier Flexible Retrieval·Deep Archive 는 객체마다 40KB 가 덧붙는다. 32KB 는 해당 Glacier 단가로, 8KB 는 Standard 단가로 과금된다(객체 이름과 메타데이터를 실시간으로 나열할 수 있게 유지하는 비용이다).

💡 관련 이론: IA(Infrequent Access) 계열은 저장 단가를 낮춘 대신 읽을 때 GB당 검색 요금을 받는다. 그래서 손익분기는 "얼마나 자주, 얼마나 많이 읽는가"에 달려 있다. 매일 대시보드가 훑는 Curated 데이터를 IA 로 내리면 검색 요금이 저장 절감액을 넘는다. 클래스는 데이터의 나이가 아니라 접근 빈도로 고른다.

아카이브 계층의 복원

Glacier Flexible Retrieval 과 Deep Archive 의 객체는 실시간으로 읽을 수 없다. RestoreObject 로 임시 사본을 만들어 달라고 요청하고, 기다린 뒤, 지정한 일수 동안만 읽는다.

# Deep Archive 객체를 Bulk 로 복원 요청하고 임시 사본을 7일간 유지
aws s3api restore-object \
  --bucket acme-datalake-raw-prod \
  --key raw/orders/dt=2023-01-15/part-0000.json.gz \
  --restore-request '{"Days": 7, "GlacierJobParameters": {"Tier": "Bulk"}}'

• 복원해도 객체의 스토리지 클래스는 그대로다. 복원 기간에는 아카이브 요금 + 임시 사본의 Standard 요금을 함께 낸다.
• Flexible Retrieval 의 Bulk 복원은 무료이고, Expedited 는 프리미엄 요금이다. Expedited 는 수요가 몰리면 거절될 수 있어, 확실히 필요하면 프로비저닝된 용량을 산다.
• 객체가 수천만 개면 복원 요청 자체가 일이다. S3 Batch Operations 로 한 번에 요청한다.
• 클래스를 영구히 되돌리려면 복원한 뒤 원하는 클래스로 복사(copy) 해야 한다. 수명주기 전환은 아래로만 흐른다.

데이터 레이크 존별 스토리지 매핑

• Athena·Redshift Spectrum 으로 조회할 가능성이 남아 있는 데이터는 Glacier Instant Retrieval 까지만 내린다. Flexible Retrieval·Deep Archive 로 넘어간 객체는 Athena 가 오류 없이 건너뛰므로 "오래된 파티션이 조용히 결과에서 빠지는" 사고가 난다.
• 복원한 객체를 Athena 로 읽으려면 테이블 속성 read_restored_glacier_objects 를 true 로 설정해야 한다(엔진 버전 3, Hive 테이블). 복원 자체는 Athena 가 해 주지 않는다.
• 오픈 테이블 포맷(Iceberg 등)의 데이터 파일은 수명주기로 아카이브하거나 만료시키지 않는다. 메타데이터가 가리키는 파일이 읽히지 않으면 테이블이 깨진다.

수명주기(Lifecycle) 정책

수명주기 규칙은 객체의 나이에 따라 전환(transition) 하거나 만료(expiration) 시킨다. 버킷 하나에 구성 하나, 규칙은 1,000개까지다.

{
  "Rules": [
    {
      "ID": "raw-tiering",
      "Filter": { "Prefix": "raw/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30,  "StorageClass": "STANDARD_IA" },
        { "Days": 90,  "StorageClass": "GLACIER" },
        { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "Expiration": { "Days": 2555 },
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30 }
    },
    {
      "ID": "cleanup-incomplete-uploads",
      "Filter": {},
      "Status": "Enabled",
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

aws s3api put-bucket-lifecycle-configuration \
  --bucket acme-datalake-raw-prod \
  --lifecycle-configuration file://lifecycle.json

전환은 폭포수 모델이다. 위에서 아래로만 내려간다.

Standard → Standard-IA → Intelligent-Tiering → One Zone-IA → Glacier Instant Retrieval
        → Glacier Flexible Retrieval → Glacier Deep Archive
(위 단계에서 아래 단계로 건너뛰는 것은 가능, 거슬러 올라가는 것은 불가)

규칙을 짤 때 걸리는 제약은 다음과 같다.

• 128KB 기본 동작은 2024년 9월에 바뀐 것이다. 그 전에는 128KB 미만 객체도 Glacier Flexible Retrieval·Deep Archive 로는 전환됐다. 오래된 자료는 옛 동작으로 설명할 수 있다.
• 전환은 객체 하나가 요청 하나다. 작은 파일 수억 개를 전환하면 전환 요청 비용이 절감액을 넘는다. 먼저 합치고 나서 내린다.

버전 관리 버킷에서의 수명주기

버전 관리가 켜진 버킷에서는 "만료"의 뜻이 달라진다.

• 버전 관리 버킷에 Expiration 만 걸면 요금이 줄지 않는다. 데이터가 비현행 버전으로 그대로 남기 때문이다. NoncurrentVersionExpiration 을 함께 건다.
• NewerNoncurrentVersions 로 "최근 N개 비현행 버전은 남긴다"를 지정할 수 있다(1~100).
• 만료 규칙은 불완전 멀티파트 업로드를 지우지 않는다. 별도의 AbortIncompleteMultipartUpload 규칙이 필요하다. 이 액션과 ExpiredObjectDeleteMarker 는 태그 필터가 있는 규칙에는 쓸 수 없다.

⚠️ 함정: 덮어쓰기가 잦은 ETL 출력 버킷에 버전 관리를 켜면, 잡이 돌 때마다 이전 출력 전체가 비현행 버전으로 쌓인다. 콘솔에는 최신 객체만 보이니 "데이터는 100GB 인데 요금은 몇 TB 치"가 된다. 버전 관리 + 비현행 버전 만료 규칙은 한 세트다.

S3 Intelligent-Tiering

접근 패턴을 예측하기 어려운 데이터는 S3 가 객체별 접근을 지켜보며 계층을 옮기게 한다. 계층이 바뀌어도 스토리지 클래스는 Intelligent-Tiering 그대로다.

• 자동 3계층은 모두 즉시 읽힌다. 아래 계층에 있던 객체를 읽으면 Frequent Access 로 되돌아간다.
• 검색 요금이 없고 최소 보관 기간도 없다. 대신 객체당 월 모니터링·자동화 요금을 낸다.
• 128KB 미만 객체는 모니터링되지 않고 항상 Frequent Access 계층에 머문다. 작은 파일뿐인 프리픽스에는 효과가 없다.
• 선택형 아카이브 계층은 켜야만 쓰이고, 켜면 그 계층의 객체는 복원해야 읽힌다. Athena 로 조회하는 데이터에는 켜지 않는다.
• GetObject 는 접근으로 치지만 HeadObject·목록 조회·태그 조회는 접근으로 치지 않는다.

# 버킷의 Intelligent-Tiering 객체에 선택형 아카이브 계층 활성화
aws s3api put-bucket-intelligent-tiering-configuration \
  --bucket acme-datalake-clean-prod \
  --id archive-config \
  --intelligent-tiering-configuration '{
    "Id": "archive-config",
    "Status": "Enabled",
    "Tierings": [
      {"Days": 90, "AccessTier": "ARCHIVE_ACCESS"},
      {"Days": 180, "AccessTier": "DEEP_ARCHIVE_ACCESS"}
    ]
  }'

Intelligent-Tiering 은 "잘못 예측했을 때의 벌금을 없애는 보험"이다. 패턴이 확실하면(30일 뒤에는 거의 안 본다) 보험료인 모니터링 요금 없이 수명주기로 직접 내리는 편이 싸다. 패턴이 불확실하면 IA 로 내렸다가 다시 읽혀 검색 요금을 내는 위험이 더 크므로 Intelligent-Tiering 이 낫다.

비용 가시성 도구

• Inventory 는 ListObjects 를 수억 번 호출하지 않고 객체 목록을 얻는 방법이다. Athena 로 "프리픽스별 평균 객체 크기"를 뽑으면 작은 파일 문제의 위치가 드러난다.
• 스토리지 클래스 분석은 Standard 와 Standard-IA 사이의 판단을 돕는다. 수명주기 일수를 감으로 정하지 않게 해 준다.

근본적인 절감 순서는 ① 저장량 자체를 줄인다(Parquet + 압축) → ② 객체 수를 줄인다(컴팩션) → ③ 필요 없는 것을 지운다(만료, 비현행 버전, 불완전 업로드) → ④ 남은 것을 맞는 클래스로 보낸다이다. ④부터 손대면 작은 파일의 전환 요청 비용과 최소 과금 크기에 걸린다.

증상 → 원인 → 조치

지문 단서 → 정답 판별표

내일은 이번 주의 네 주제를 하나의 레이크 운영 시나리오로 묶어 복습한다.

📖 용어

• 스토리지 클래스 : 접근 빈도와 검색 지연에 따라 저장 단가가 달라지는 S3 의 저장 등급.
• 검색 요금(retrieval fee) : IA·Glacier 계열에서 데이터를 읽어 낼 때 GB당 부과되는 요금.
• 최소 보관 기간 : 그 전에 삭제·전환하면 남은 기간만큼 과금되는 기간. 클래스마다 30·90·180일이다.
• 수명주기 정책 : 객체의 나이에 따라 클래스를 전환하거나 삭제하는 버킷 단위 규칙 모음.
• 전환(transition)과 만료(expiration) : 다른 스토리지 클래스로 옮기는 것과 삭제하는 것.
• 비현행 버전(noncurrent version) : 버전 관리 버킷에서 덮어쓰이거나 삭제되어 최신이 아니게 된 객체 버전. 요금은 계속 나온다.
• 삭제 마커 : 버전 관리 버킷에서 삭제 요청 시 추가되는 표식. 객체가 없는 것처럼 보이게 할 뿐 데이터를 지우지는 않는다.
• 불완전 멀티파트 업로드 : 완료되지 않은 멀티파트 업로드가 남긴 파트. 목록에 보이지 않지만 저장 요금이 나온다.
• 복원(restore) : 아카이브된 객체의 임시 사본을 만들어 일정 기간 읽을 수 있게 하는 작업.
• S3 Inventory : 버킷의 객체와 메타데이터 목록을 정기적으로 파일로 내보내는 기능.