Blob 액세스 계층과 ADLS Gen2 (Hot, Cool, Cold, Archive, smart tier)

네 가지 액세스 계층

• 계정 기본 계층으로는 Hot, Cool, Cold 를 고를 수 있고 Archive 는 기본이 될 수 없습니다. 계층을 따로 정하지 않은 Blob 은 계정 기본값을 따르고, 포털에 "(inferred)" 로 보입니다.
• 계층은 Blob 단위로 정합니다. 같은 컨테이너에 여러 계층이 섞여도 됩니다.
• 실제 GB 당 단가는 리전과 중복성마다 다르므로 Blob 가격표에서 Korea Central 을 골라 봅니다. 이 사이트의 비용 계산기에 계층별 용량을 넣어 어림잡을 수 있습니다.

조기 삭제 요금

최소 보관 기간 전에 지우거나, 덮어쓰거나, 다른 계층으로 옮기면 남은 기간만큼 비례 요금이 붙습니다.

• Cool 로 옮기고 21일 만에 지우면 9일분(30 - 21)이 붙습니다.
• Archive 로 옮기고 45일 만에 Hot 으로 되돌리면 135일분(180 - 45)이 붙습니다.
• Put Blob, Put Block List, Copy Blob 으로 다시 쓰는 것도 해당됩니다. 매일 덮어쓰는 파일을 Cool 에 두면 손해입니다.

Archive 재수화

Archive 의 Blob 은 바로 읽을 수 없고, 온라인 계층으로 재수화(rehydrate) 해야 합니다.

우선순위는 Standard 와 High 두 가지이고, Standard 는 최대 15시간까지 걸릴 수 있습니다. High 는 빠르지만 비쌉니다. 수명 주기 관리 정책으로는 Archive 에서 되돌릴 수 없으므로, 감사 대응처럼 갑자기 많이 읽어야 할 데이터는 Archive 대신 Cold 를 고려합니다.

az storage blob copy start --auth-mode login \
  --account-name stshoparchive --destination-container restore --destination-blob 2024/orders.parquet \
  --source-uri "https://stshoparchive.blob.core.windows.net/archive/2024/orders.parquet" \
  --tier Hot --rehydrate-priority Standard

smart tier: 자동 계층

smart tier 는 2026-04 에 GA 가 된 자동 계층입니다(공용 클라우드의 영역 중복 지원 리전 기준). 계정의 기본 액세스 계층을 Smart 로 정하면 Azure 가 사용 패턴에 따라 옮깁니다.

• 새 데이터는 Hot 에 들어갑니다.
• 30일 동안 접근이 없으면 Cool, 그 뒤 60일(합계 90일) 더 없으면 Cold 로 내립니다.
• 다시 읽으면(Get Blob, Put Blob) Hot 으로 돌아가고 주기가 다시 시작됩니다. 속성, 메타데이터, 태그 조회는 접근으로 치지 않습니다.
• 128 KiB 이하 객체는 Hot 에 머뭅니다. Archive 는 쓰지 않습니다.

조건이 있습니다. Standard 범용 v2, ZRS, GZRS, RA-GZRS 계정, 블록 Blob 만 됩니다. 명시적으로 계층을 정한 Blob 은 smart tier 에 들어가지 않고, 한 번 명시 계층이 되면 되돌아오지 않습니다. 접근 패턴을 예측하기 어려운 데이터 레이크, 사용자 업로드 파일에 잘 맞습니다.

수명 주기 관리

규칙으로 계층 이동과 삭제를 자동화합니다. 마지막 수정 시각, 마지막 접근 시각(접근 추적을 켜야 함), 생성 시각을 조건으로 씁니다.

{
  "rules": [{
    "name": "logs-tiering",
    "enabled": true,
    "type": "Lifecycle",
    "definition": {
      "filters": { "blobTypes": ["blockBlob"], "prefixMatch": ["logs/"] },
      "actions": {
        "baseBlob": {
          "tierToCool":    { "daysAfterModificationGreaterThan": 30 },
          "tierToCold":    { "daysAfterModificationGreaterThan": 90 },
          "tierToArchive": { "daysAfterModificationGreaterThan": 180 },
          "delete":        { "daysAfterModificationGreaterThan": 2555 }
        },
        "version": { "delete": { "daysAfterCreationGreaterThan": 90 } }
      }
    }
  }]
}

정책은 하루에 한 번 정도 돌고, 반영까지 최대 48시간 걸릴 수 있습니다. 버전 관리를 켠 계정은 version 규칙으로 이전 버전도 정리해야 비용이 쌓이지 않습니다.

ADLS Gen2

Azure Data Lake Storage Gen2 는 별도 서비스가 아니라 계층 구조 네임스페이스(HNS)를 켠 스토리지 계정입니다.

• 진짜 디렉터리가 생겨서 디렉터리 이름 바꾸기, 지우기가 원자적이고 빠릅니다. Spark, Databricks, Fabric 같은 분석 엔진의 커밋 성능에 중요합니다.
• POSIX 형식 ACL 로 디렉터리, 파일 단위 권한을 줍니다. RBAC(계정, 컨테이너 범위)가 먼저 평가되고, RBAC 로 허용되지 않으면 ACL 을 봅니다.
• 엔드포인트는 dfs.core.windows.net 이고, 분석 도구는 abfss://<컨테이너>@<계정>.dfs.core.windows.net/경로 로 접근합니다.
• HNS 는 만들 때 켜는 것이 기본이고, 기존 계정은 업그레이드 마이그레이션이 가능하지만 일부 기능(예: 특정 Blob 기능)과 호환되지 않을 수 있습니다.

az storage account create -g rg-data-prod -n stlakeprodkrc -l koreacentral \
  --sku Standard_ZRS --kind StorageV2 --enable-hierarchical-namespace true
az storage fs access set --acl "user::rwx,group::r-x,other::---,group:<entra-group-id>:r-x" \
  -p sales -f raw --account-name stlakeprodkrc --auth-mode login

주의 ADLS Gen2 의 ACL 은 새로 만드는 하위 항목에 자동으로 상속되지 않습니다. 기본(default) ACL 을 디렉터리에 같이 설정해야 합니다. 기존 파일에는 az storage fs access update-recursive 로 적용합니다.

Microsoft Fabric 의 OneLake 는 ADLS Gen2 와 같은 API 를 쓰고, 바로가기(shortcut)로 기존 ADLS Gen2 데이터를 복사 없이 참조할 수 있습니다 (Fabric 과 분석).

공식 문서

• Access tiers for blob data
• Optimize Azure Blob Storage costs with smart tier
• Azure Data Lake Storage introduction