Google Cloud의 객체 스토리지 비용 최적화: 위치 및 클래스

* 본 아티클의 원문은 2021년 4월 14일 Google Cloud 블로그(영문)에 게재되었습니다.   

스토리지는 클라우드 기반 인프라의 중요한 구성요소입니다. 데이터를 저장하고 제공하는 공간이 없으면 데이터베이스가 작동하지 않고 컴퓨팅이 실행될 수 없으며 네트워크를 통해 전달되는 데이터를 저장할 곳이 없습니다. 스토리지는 많은 고객에게 3대 클라우드 비용 중 하나를 차지하며 대부분의 기업에서는 스토리지 니즈가 증가하고만 있습니다. 따라서 스토리지 비용 최적화 방법을 문의하는 고객이 많은 것은 당연한 일입니다. 

대부분의 온프레미스 환경에서는 파일 또는 블록 스토리지를 사용하지만 클라우드 스토리지 환경에서는 주로 객체 스토리지를 사용합니다. Google Cloud의 객체 스토리지 서비스인 Cloud Storage는 많은 양의 데이터를 저장하는 대량 스토리지에 적합합니다. 객체 스토리지는 본질적으로 매우 큰 값을 포함하는 '구조화되지 않은' 키-값 쌍이지만 안에 저장되는 파일은 바이너리 데이터, 텍스트 데이터 또는 Apache Parquet, Avro 같은 특수한 데이터 형식일 수 있습니다. 

1GB당 $0.01 이하의 객체 스토리지는 대부분의 데이터에 대해 가장 저렴하고 확장성이 뛰어난 솔루션입니다. 하지만 객체 스토리지 가격이 낮게 책정되어 있더라도 비용이 추가될 수 있습니다. 실행되는 워크로드가 많고 시간이 지나면서 니즈가 달라지는 조직의 경우 애플리케이션을 새로 만들거나 마이그레이션할 때마다 클라우드 스토리지 니즈(및 비용)를 최적화하기 어려울 수 있습니다.

클라우드 스토리지 비용을 절감하는 방법에는 여러 가지가 있으며 데이터 수명 주기 니즈, 가져오기 패턴, 거버넌스 요구사항 등 다양한 요인에 따라 사용해야 할 방법이 달라집니다. 이 블로그는 Google Cloud에서 객체 스토리지 비용을 절감하는 방법을 다루는 시리즈의 첫 번째 게시물입니다. 먼저 가장 중요한 결정사항인 데이터를 저장하는 Google Cloud 리전과 선택 가능한 스토리지 클래스 옵션부터 살펴보겠습니다.

올바른 구성으로 시작하기

처음으로 버킷을 설정할 때가 바로 객체 스토리지 비용을 절감할 수 있는 첫 번째 기회입니다. 스토리지 설정은 쉽지만 이때 몇 가지 중요한 결정을 내립니다. 스토리지 위치와 같은 선택사항은 저장하는 데이터 양이 늘어나면 변경하기가 어렵고 시간도 많이 듭니다. 따라서 니즈에 맞는 결정을 내리는 것이 중요합니다.

위치

스토리지 위치 선택은 비용, 성능, 가용성 사이에서 균형을 맞추는 작업이며 Regional Storage가 가장 적은 비용이 들고 이중 리전 또는 멀티 리전 구성에서는 비용이 늘어납니다.

Regional Storage는 이름에서 알 수 있듯이 단일 리전으로 제한되어 있기 때문에 일반적으로 가용성이 가장 낮으나 데이터의 가용성은 여전히 높습니다. 단일 리전 스토리지를 사용하면 데이터가 해당 리전의 여러 영역에 중복 저장됩니다(자세한 내용은 Google Cloud 리전 및 영역 페이지 참조). Google Cloud 시스템은 한 영역 내에서 장애를 격리하도록 설계되었습니다. 

이중 리전 및 멀티 리전 스토리지는 요청을 제공할 수 있는 리전이 여러 개(각각 다수의 영역 포함)이므로 드문 일이지만 리전 전체에 정전이 발생하더라도 데이터 액세스를 제공할 수 있다는 점에서 더 나은 가용성을 제공합니다.

성능을 고려한 스토리지 위치 선택은 복잡한 주제입니다. 일반적으로 리전 위치 또는 이중 리전 위치를 선택하여 데이터를 한 리전에 고정하면 리더와 작성자가 동일 리전에 위치해 있을 때 중요한 성능상의 이점을 얻을 수 있습니다. 예를 들어 워크로드를 단일 Google Cloud 리전에서 호스팅하는 경우 객체 스토리지가 동일 리전에 위치해야 네트워크 홉 수를 최소화할 수 있습니다. 또는 읽기와 쓰기에 Cloud Storage를 사용하는 온프레미스 워크로드가 있다면 전용 리전 상호 연결을 사용해 전체 대역폭 소비를 줄이고 성능을 개선할 수 있습니다. 

반대로 멀티 리전 스토리지는 Cloud CDN 사용 여부와 관계없이 일반적으로 유럽 또는 북미와 같이 큰 지리적 영역에 직접 트래픽을 제공할 때 우수한 성능을 제공합니다. 많은 애플리케이션, 특히 소비자용 애플리케이션에서는 클라우드 리전과 최종 사용자 사이의 '라스트 마일' 지연 시간을 고려해야 합니다. 이러한 상황에서는 이중 리전 스토리지보다 고가용성과 비용 절감을 제공하는 멀티 리전 스토리지에서 설계자가 더 많은 가치를 찾을 수 있습니다. 

비용에 있어서는 Regional Storage가 가장 저렴한 옵션입니다. 이중 리전은 메타데이터가 공유되는 두 리전 버킷이며 관련 위치 고정, 높은 성능이 지원되어 가장 비쌉니다. 멀티 리전은 중간 가격대입니다. Google에서 데이터를 저장할 위치를 유연하게 선택할 수 있어서 데이터를 더 경제적으로 저장할 수 있기 때문입니다. 클래스에 상관없이 Regional Storage 비용이 대략 $1일 때 멀티 리전은 최대 $1.30, 이중 리전 스토리지는 최대 $2를 지불한다고 예상하면 됩니다. 

이렇게 비용 차이가 크므로 Cloud Storage 버킷의 위치를 전략적으로 고려하는 것이 중요합니다. 일부 서비스에서는 기본적으로 미국 멀티 리전에 버킷을 만들지만 무조건적으로 기본값을 적용하지 마세요. 성능 및 가용성 요구사항을 고려하고 지리적 중복성과 가용성을 위해 필요 이상으로 비용을 지불하지 마세요.

스토리지 클래스

Cloud Storage 버킷 위치를 선택한 후에는 기본 스토리지 클래스를 선택해야 합니다. Google Cloud에서는 Standard, Nearline, Coldline, Archive와 같은 4가지 클래스를 제공합니다. 클래스마다 적합한 데이터 가져오기 프로필은 각기 다르며 클래스를 지정하지 않으면 기본 클래스가 모든 쓰기에 자동으로 적용됩니다. 정밀도를 높이기 위해 버킷의 개별 객체별로 스토리지 클래스를 정의할 수 있습니다. 객체 수준에서 객체를 다시 쓰거나 객체 수명 주기 관리를 사용하여 스토리지 클래스를 변경할 수 있습니다. (수명 주기 관리에 대해서는 이 시리즈의 이후 블로그에서 자세히 다룰 예정입니다.)

스토리지 가격은 주문형 사용량을 기준으로 책정되지만 가격에는 암묵적인 '계약'이 존재하여 사용 사례에 가장 적합한 스토리지를 확보할 수 있습니다. 이를테면 '핫' 또는 '표준' 스토리지의 경우 1GB당 월 스토리지 가격이 더 높지만 가져오기 또는 조기 삭제에 1GB당 수수료가 추가로 청구되지 않는 암묵적인 계약이 존재합니다. '쿨' 스토리지 클래스에서는 1GB당 월 스토리지 비용이 훨씬 낮은 대신 가져오기 및 조기 삭제의 1GB당 수수료를 고려해야 합니다. 일반적으로 사용 사례의 총비용이 가장 적게 발생하는 기본 스토리지 클래스를 선택하는 것을 목표로 하며 장기적인 관점(예측)이 필요합니다.

시작하려면 문서에 제공된 가이드라인을 따르는 것이 좋습니다.

• Standard: 정기적 액세스, 최소 보관 기간 없음, '핫' 데이터
• Nearline: 한 달에 한 번 미만 액세스, 한 달 이상 보관
• Coldline: 한 분기에 한 번 미만 액세스, 한 분기 이상 보관
• Archive: 일 년에 한 번 미만 액세스, 일 년 이상 보관

데이터 액세스 가져오기가 일관되지 않을 경우에는 어떻게 해야 할까요? 많은 Cloud Storage 사용자가 무기한까지는 아니더라도 데이터를 1년 이상 보관합니다. 따라서 분석이 복잡해지지 않도록 여기서는 조기 삭제 비용을 제외할 것입니다. 즉, 이 분석에서는 모든 데이터를 1년 이상 보관한다고 가정합니다. 하지만 가져오기 비용과 관련해 쉽게 예측할 수 없거나 높은 정확성을 원하는 사용 사례들이 섞인 애매한 경우에는 다음 공식을 사용해 두 스토리지 클래스 간 액세스 빈도에 대한 손익분기점을 찾으면 됩니다.

각 변수의 의미는 다음과 같습니다. 

              hs = '핫' 클래스의 1GB당 월 스토리지 비용

              cs = '콜드' 클래스의 1GB당 월 스토리지 비용

              cr = '콜드' 클래스의 1GB당 가져오기 비용

(hs - cs) / cr = 손익분기점의 월별 데이터 읽기 비중

예를 들어 us-central1에서 표준 Regional Storage와 Nearline Regional Storage를 사용할 경우를 비교해 보겠습니다(2021년 1월 기준 가격).

(0.02GB/월 - 0.01GB/월) / 0.01GB = 1.0/월 = 월별 100%

즉, Nearline에 저장하는 데이터의 100%를 매달 한 번 읽어도 손익분기점에 도달한다는 의미입니다. 하지만 이 계산에는 주의사항이 두 가지 있습니다.

• 반복 읽기도 집계됩니다. 데이터의 1%를 한 달에 100번 읽으면 데이터 100%를 정확히 한 번 읽은 것과 같습니다. 
• 이 계산에서는 가정하는 평균 객체 크기가 큽니다(수십 MB 이상). 파일이 매우 작은 경우 운영 비용이 계산에 영향을 미치게 됩니다. 

그렇지만 저장한 데이터의 100% 미만을 읽고 작은 객체가 없다면(아래에서 자세히 설명) Nearline Storage를 사용할 경우 비용을 절감할 수 있습니다.

us-central1(아이오와) Regional Storage 클래스의 스토리지 및 보관 비용을 다룬 다음 차트로 모든 스토리지 클래스에서 보이는 이러한 추세를 시각화했습니다. 이 추세는 모든 위치에서 유사하지만 '최고 비율' 변곡점이 다릅니다.

다시 데이터를 1년 이상 보관할 계획이라고 가정한다면 위에 표시된 '최고 비율' 점선을 따라 스토리지 클래스를 선택하면 됩니다. 이 경우 한 달에 정확히 한 번 발생하는 데이터 읽기의 변곡점은 Archive, Coldline, Nearline에서 각각 약 10%, 60%, 100%입니다. 

한 달에 한 번 미만 데이터의 10%에 액세스하는 경우 Archive가 가장 비용 효율적인 옵션이라는 사실에도 주목해야 합니다. 정확히 한 달에 한 번 데이터의 10~60%에 액세스하는 경우에는 Coldline이 비용 최적화된 옵션이며 정확히 한 달에 한 번 데이터의 60~100%에 액세스한다면 Nearline이 가장 저렴한 스토리지 클래스입니다. 표준 스토리지는 데이터 100%에 액세스하거나 한 달에 한 번 이상 액세스할 때 가장 적합한 옵션입니다. 다수의 반복 읽기로 자주 액세스하는 데이터가 있는 경우에 이상적입니다.

결론

객체 스토리지는 클라우드 애플리케이션에서 중요한 역할을 차지합니다. 클라우드 스토리지 사용 비중이 큰 기업은 객체 스토리지 비용을 예의주시해야 합니다. Google의 객체 스토리지 서비스인 Cloud Storage는 고객이 스토리지 비용을 최적화할 수 있도록 다양한 방법을 제공합니다. 

시리즈의 첫 번째 게시물인 이 블로그에서는 가장 중요한 2가지 요소인 스토리지 위치와 스토리지 클래스에 대한 몇 가지 안내를 다루었습니다. 스토리지 위치와 스토리지 클래스는 버킷을 만들 때 정의하며 옵션마다 장단점이 다릅니다. 위의 안내는 스토리지 요구사항에 맞게 선택하는 데 도움이 되도록 작성되었습니다.

Cloud Storage 및 시작 방법에 대한 자세한 내용은 안내 가이드를 참조하세요. 가져오기 패턴 및 수명 주기 관리와 관련된 객체 스토리지 비용 최적화를 다룬 추가 블로그 게시물을 기대해 주세요.