DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

S3 스토리지 클래스 설명: 비용 효율적인 옵션 선택하기

AWS S3 비용 최적화를 마스터하려면 스토리지 클래스를 이해해야 합니다. 이 가이드는 S3 Standard, Intelligent-Tiering, One Zone-IA 및 Glacier 제품군을 비교하며 가용성, 내구성 및 중요한 검색 비용 간의 트레이드오프를 자세히 설명합니다. 수명 주기 정책을 사용하여 데이터 액세스 패턴을 가장 예산 친화적인 스토리지 옵션에 자동으로 맞추는 방법을 알아보세요.

S3 스토리지 클래스 설명: 비용 효율적인 옵션 선택하기

Amazon Simple Storage Service(S3)는 다양한 액세스 패턴에 맞는 여러 스토리지 클래스를 제공하고 확장성이 뛰어나 많은 AWS 워크로드의 기본 객체 스토리지입니다. 그러나 모든 데이터가 동일하게 액세스되는 것은 아닙니다. 자주 액세스하는 중요 데이터를 드물게 액세스하는 아카이브 데이터와 동일한 클래스에 저장하면 불필요한 클라우드 비용이 크게 발생할 수 있습니다. 다양한 S3 스토리지 클래스 간의 미묘한 차이를 이해하는 것은 비용 최적화된 아키텍처를 설계하는 데 중요합니다.

S3 내구성 및 가용성 이해

클래스를 살펴보기 전에 S3의 두 가지 핵심 지표를 정의하는 것이 중요합니다.

  • 내구성: 시간이 지나도 데이터가 손상되지 않고 유지될 가능성. S3는 특정 클래스에 사용되는 인프라 전반에 걸쳐 99.999999999%(11 9's) 의 내구성을 제공하도록 설계되었습니다.
  • 가용성: 데이터를 검색할 수 있는 시간의 백분율. 일반적으로 연간 기준으로 측정됩니다(예: 99.9%).

이러한 지표는 선택한 특정 스토리지 클래스에 따라 약간씩 다릅니다.

핵심 S3 스토리지 클래스: 상세 비교

AWS는 다양한 액세스 빈도와 다운타임 허용 오차에 최적화된 여러 스토리지 클래스를 제공합니다. 가장 일반적인 옵션에 대한 자세한 내용은 다음과 같습니다.

1. S3 Standard

S3 Standard는 기본 범용 스토리지 클래스로, 자주 액세스하는 데이터에 가장 적합합니다.

  • 사용 사례: 활성 데이터, 콘텐츠 배포, 동적으로 생성된 콘텐츠, 모바일/게임 애플리케이션.
  • 내구성: 11 9's.
  • 가용성: 99.99%(고가용성).
  • 검색 시간: 밀리초.
  • 가격: 자주 액세스하는 계층 중에서 스토리지 비용이 가장 높지만 검색 수수료가 없습니다.

모범 사례: 지연 시간이 최소화된 즉각적인 액세스가 필요한 데이터에 사용하세요.

2. S3 Intelligent-Tiering(S3-IT)

S3 Intelligent-Tiering은 알 수 없거나 변경되는 액세스 패턴을 가진 데이터를 위해 설계되었습니다. 사용량에 따라 객체를 두 개 이상의 액세스 계층 간에 자동으로 이동시켜 운영 오버헤드 없이 스토리지 비용을 최적화합니다.

  • 사용 사례: 데이터 레이크, 예측 불가능한 액세스 패턴의 데이터, 또는 시간이 지남에 따라 비용을 최적화하면서 즉각적인 액세스를 보장하려는 경우.
  • 작동 방식: 액세스를 모니터링합니다. 객체에 30일 연속으로 액세스하지 않으면 IA(Infrequent Access) 계층으로 이동합니다. 다시 액세스하면 Frequent Access 계층으로 돌아갑니다.
  • 포함된 계층: Frequent Access, Infrequent Access, Archive Instant Access(선택 사항).
  • 비용 요소: 객체당 소액의 월별 모니터링 및 자동화 수수료와 객체가 위치한 계층에 따라 변경되는 스토리지 비용이 포함됩니다.

실행 가능한 팁: 데이터 액세스 빈도를 확신할 수 없는 경우 S3 Intelligent-Tiering은 비용 절감과 성능 일관성 간의 최상의 균형을 제공하는 경우가 많습니다.

3. S3 One Zone-Infrequent Access(S3 One Zone-IA)

이 클래스는 S3 Standard-IA와 유사하지만 가용성에 큰 차이가 있는 드물게 액세스되지만 빠른 검색이 필요한 데이터에 이상적입니다.

  • 사용 사례: 보조 백업, 재생성 가능한 데이터(예: 소스에서 재생성할 수 있는 데이터), 또는 다중 AZ 이중화가 필요하지 않은 비즈니스 크리티컬 데이터 저장.
  • 내구성: 11 9's.
  • 가용성: 99.5%(Standard보다 낮은 가용성).
  • 스토리지 위치: 데이터는 여러 AZ에 걸쳐 있는 다른 클래스와 달리 단일 AWS 가용 영역(AZ) 에 중복 저장됩니다.
  • 비용 요소: Standard보다 스토리지 비용이 훨씬 저렴하지만 데이터 검색 시 수수료가 발생합니다.

⚠️ One Zone-IA 경고: 데이터가 하나의 AZ에만 있기 때문에 해당 AZ에 치명적인 이벤트(예: 대규모 정전 또는 자연 재해)가 발생하면 이 계층의 데이터가 손실될 수 있습니다. 따라서 중요하지 않고 쉽게 교체할 수 있는 데이터에만 사용하는 것이 중요합니다.

4. S3 Glacier 스토리지 클래스(아카이브)

Glacier 스토리지 클래스는 분에서 시간 단위의 검색 시간이 허용되는 장기 아카이브에 최적화되어 있습니다.

S3 Glacier Instant Retrieval(S3 Glacier IR)

Infrequent Access와 딥 아카이브 사이의 격차를 해소합니다.

  • 사용 사례: 분기당 한 번 이하로 액세스하지만 필요할 때 밀리초 단위 검색이 필요한 데이터(예: 의료 이미지, 뉴스 미디어 아카이브).
  • 검색 시간: 밀리초(IA 클래스와 유사한 지연 시간).
  • 비용 요소: 매우 낮은 스토리지 비용과 검색 수수료.

S3 Glacier Flexible Retrieval(이전 S3 Glacier)

분에서 시간 단위의 검색이 허용될 때 사용하는 장기 아카이브 옵션입니다.

  • 사용 사례: 규정 준수 아카이브, 거의 또는 전혀 필요하지 않은 재해 복구 데이터.
  • 검색 옵션(및 지연 시간):
    • Expedited: 1~5분
    • Standard: 3~5시간
    • Bulk: 5~12시간
  • 비용 요소: 매우 낮은 스토리지 비용이지만 검색 수수료가 발생하고 시간이 소요됩니다.

S3 Glacier Deep Archive

AWS S3에서 가장 저렴한 스토리지 옵션입니다.

  • 사용 사례: 일반적으로 규정 준수를 위해 연간 한두 번만 액세스할 수 있는 데이터.
  • 검색 옵션(및 지연 시간):
    • Standard: 12시간
    • Bulk: 48시간
  • 비용 요소: 가장 낮은 스토리지 요금, 가장 높은 검색 수수료, 가장 긴 검색 시간.

선택 방법: 의사 결정 프레임워크

올바른 클래스를 선택하려면 데이터 수명 주기에 대한 세 가지 주요 질문에 답해야 합니다.

질문 주요 고려 사항 권장 클래스 경로
얼마나 자주 액세스합니까? 액세스 빈도 자주 → Standard; 드물게 → IA 또는 Glacier
허용 가능한 다운타임/손실은 무엇입니까? 내구성/가용성 중요 → Standard/Intelligent-Tiering; 폐기 가능 → One Zone-IA
얼마나 빨리 검색해야 합니까? 지연 시간 요구 사항 밀리초 → Standard/Intelligent-Tiering/Glacier IR; 시간 → Glacier Flexible/Deep Archive

예시 시나리오: 회사 미디어 자산

마케팅 팀이 매일 수백 개의 원시 비디오 파일을 업로드합니다.

  1. 현재 편집/프로모션(최근 30일): S3 Standard(높은 액세스, 낮은 지연 시간).
  2. 가끔 검토가 필요한 오래된 자산(30일~1년): S3 Intelligent-Tiering(초기 핫 기간 후 비용 절감 효과를 얻기 위해).
  3. 완료된 감사 최종 마스터(1년 이상): S3 Glacier Deep Archive(가장 저렴한 비용, 규정 준수 감사에만 필요).

예시 시나리오: 로그, 백업 및 사용자 업로드

단일 회사는 종종 세 가지 매우 다른 S3 패턴을 가지고 있습니다.

애플리케이션 로그의 경우 엔지니어가 인시던트 중에 검색하므로 최근 데이터가 중요합니다. 인시던트 기간이 지나면 대부분의 로그는 규정 준수 또는 추세 데이터가 됩니다. 합리적인 수명 주기는 30~90일을 Standard 또는 Standard-IA에 유지하고, 오래된 로그를 아카이브 계층으로 이동하며, 고정된 보존 기간 후에 가치가 낮은 디버그 로그를 만료시키는 것입니다. 정확한 숫자는 보존 정책과 사람들이 실제로 오래된 접두사를 쿼리하는 빈도에 따라 결정되어야 합니다.

데이터베이스 백업의 경우 스토리지 클래스는 복원 약속을 따라야 합니다. 팀이 프로덕션 복원이 몇 분 안에 시작되어야 한다고 말하면 즉시 검색이 가능한 클래스에 최신 백업을 유지하세요. 빠른 복구보다는 감사 보존을 위해 있는 경우 오래된 월별 또는 연간 복사본을 더 콜드하게 이동할 수 있습니다. 선택한 클래스에서 복원을 테스트하세요. 한 번도 복원된 적이 없는 백업 정책은 대부분 청구 규칙에 불과합니다.

사용자 업로드의 경우 액세스를 예측하기가 더 어렵습니다. 프로필 사진은 작지만 지속적으로 가져올 수 있습니다. 대용량 원본 비디오는 한 번 다운로드되고 트랜스코딩된 후 거의 건드리지 않을 수 있습니다. 파생 자산과 원본을 별도의 접두사 아래에 저장하여 수명 주기 규칙이 다르게 처리할 수 있도록 하세요. 제품에 실제로 필요한 것이 아니라면 썸네일 정책이 수 기가바이트 원본과 동일한 아카이브 규칙을 상속받지 않도록 하세요.

버킷을 변경하기 전에 물어봐야 할 질문

수명 주기 규칙을 추가하기 전에 누가 데이터를 읽는지, 어떻게 읽는지, 검색이 지연되면 어떻게 되는지 물어보세요. 엔지니어는 업로드가 애플리케이션의 일부인 반면 읽기는 분석, 지원 도구, 규정 준수 내보내기 또는 수동 인시던트 대응을 통해 나중에 발생하기 때문에 쓰기 경로를 읽기 경로보다 더 잘 아는 경우가 많습니다.

오래된 접두사를 스캔하는 배치 작업을 찾아보세요. 모든 객체를 나열하거나, 메타데이터를 열거나, 오래된 파일을 샘플링하는 야간 작업은 콜더 클래스의 절감 효과 중 일부를 없앨 수 있습니다. 작업에 매니페스트만 필요한 경우 S3 Inventory가 버킷을 반복해서 나열하는 것보다 나을 수 있습니다. 분석가가 Athena로 로그를 쿼리하는 경우 데이터를 복원 단계가 필요한 클래스로 이동하기 전에 파티션 레이아웃과 압축을 고려하세요.

객체 크기에 주의하세요. 최소 청구 가능 객체 크기가 있는 스토리지 클래스는 엄청나게 많은 수의 작은 파일에 적합하지 않을 수 있습니다. 이러한 경우 데이터를 더 큰 객체로 압축하거나, 분석을 위해 Parquet을 사용하거나, 불필요한 객체를 만료시키는 것이 스토리지 클래스 전환보다 더 나을 수 있습니다.

마지막으로, 인시던트 중에 설명할 수 있는 방식으로 수명 주기 규칙을 작성하세요. archive-old-logs-after-90-days라는 접두사 규칙은 30일 후에 모든 것을 조용히 이동시키는 버킷 전체 규칙보다 추론하기 쉽습니다. 비용 최적화는 복구를 불투명하게 만들지 않고 시스템을 더 저렴하게 만들어야 합니다.

또 한 가지 실용적인 확인 사항은 소유권입니다. 실제 계정에서 버킷 소유자, 업로드 계정, 복제 역할 및 분석 계정이 항상 동일하지는 않습니다. 데이터를 아카이브 클래스로 이동하기 전에 누가 복원할 수 있고 누가 검색 비용을 지불하는지 확인하세요. KMS 암호화가 있는 교차 계정 버킷은 객체가 필요한 역할이 버킷을 나열할 수 있지만 키를 사용할 수 없는 경우 복원 시 실패할 수 있습니다. 이는 감사 중에 나쁜 놀라움입니다.

버전 관리도 계산을 변경합니다. 수명 주기 규칙은 현재 버전과 이전 버전을 다르게 전환하거나 만료시킬 수 있습니다. 애플리케이션이 매시간 동일한 키를 덮어쓰는 경우 이전 버전이 버킷에서 가장 큰 부분이 될 수 있습니다. 현재 객체 수가 전체 스토리를 알려준다고 가정하지 말고 별도로 검토하세요.

수명 주기 정책 구현

클래스 간에 수동으로 객체를 이동하는 것은 비효율적입니다. 이러한 계층 전반에서 비용을 관리하는 가장 효과적인 방법은 S3 수명 주기 정책을 사용하는 것입니다.

수명 주기 정책을 사용하면 정의된 일 수 후에 객체를 자동으로 콜더 스토리지 계층으로 전환하거나 영구적으로 만료시키는 규칙을 정의할 수 있습니다.

예시 수명 주기 규칙(전환):

<Rule>
    <ID>Move_to_IA_After_30_Days</ID>
    <Status>Enabled</Status>
    <Filter>
        <Prefix>logs/</Prefix>
    </Filter>
    <Transition>
        <Days>30</Days>
        <StorageClass>GLACIER_IR</StorageClass>
    </Transition>
</Rule>

이 구성은 logs/ 접두사의 모든 객체를 생성 후 30일이 지나면 Glacier Instant Retrieval로 자동 이동시켜 장기 스토리지 비용을 크게 줄이면서 필요할 때 빠른 검색 기능을 유지합니다.

사람들이 놓치는 비용 함정

스토리지 클래스 결정은 단순한 월별 GB 비교가 아닙니다. 검색 요금, 요청 요금, 최소 스토리지 기간, 최소 청구 가능 객체 크기, 복제, 수명 주기 전환 요청 및 모니터링 수수료가 결과를 바꿀 수 있습니다. 수백만 개의 키가 있는 작은 객체 아카이브는 소수의 대용량 백업 파일과 매우 다르게 동작할 수 있습니다.

예를 들어 애플리케이션 로그는 한 번 기록되고 거의 읽히지 않는 경우가 많으므로 Standard에서 Glacier Instant Retrieval 또는 Glacier Flexible Retrieval로의 수명 주기 규칙이 적합할 수 있습니다. 그러나 인시던트 프로세스에서 Athena로 오래된 로그를 자주 스캔하는 경우 공격적인 아카이빙은 느린 복원과 예상치 못한 검색 비용을 초래할 수 있습니다. 이 경우 로그를 날짜별로 분할하고, 노이즈가 많고 가치가 낮은 접두사를 만료시키며, 최근 몇 개월을 쿼리 친화적인 클래스에 유지하는 것이 30일 후에 모든 것을 맹목적으로 콜드하게 이동하는 것보다 더 많은 비용을 절약할 수 있습니다.

백업은 모양이 다릅니다. 한 달에 한 번 테스트하는 데이터베이스 덤프는 예측 가능한 복원 동작이 필요합니다. 복구 시간 목표가 분 단위로 측정되는 경우 Deep Archive는 휴식 중에는 저렴하더라도 유일하게 복원 가능한 복사본을 위한 올바른 장소가 아닐 수 있습니다. 동일한 덤프가 감사 보존을 위해서만 유지되는 세 번째 복사본인 경우 Deep Archive가 합리적일 수 있습니다.

미디어 팀은 예측할 수 없이 오래된 자산이 필요한 경우가 많습니다. Intelligent-Tiering은 특히 객체가 충분히 커서 모니터링 수수료가 결정적인 요소가 아닌 경우 알 수 없는 패턴에 대한 좋은 기본값이 될 수 있습니다. 많은 수의 작은 썸네일의 경우 수수료와 최소 객체 크기 동작을 모든 곳에서 켜기 전에 면밀히 살펴볼 가치가 있습니다.

선택하는 실용적인 방법은 하나의 버킷을 샘플링하고, S3 Inventory를 내보내고, 접두사, 객체 수, 총 바이트, 마지막 수정 날짜 및 알려진 액세스 패턴별로 그룹화한 다음 접두사별로 수명 주기 규칙을 작성하는 것입니다. 버킷에 실제로 한 가지 종류의 데이터가 포함되어 있지 않는 한 하나의 버킷 전체 규칙을 피하세요.