비용 관리

AI 시대를 위한 FinOps: 에이전트를 위한 새로운 유연한 결제 및 비용 관리

Wed, 26 Aug 2026 03:00:00 +0000

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

편집자 주: 이 게시글은 처음 게시된 후 제품 이미지가 업데이트되었습니다.

AI가 더 복잡한 작업을 수행함에 따라 비즈니스 리더는 에이전트를 사용하여 신속한 혁신을 실현하는 동시에 마진과 예산을 보호해야 하는 새로운 과제에 직면해 있습니다. AI에서 진정한 수익을 얻으려면 기술과 함께 재무 운영 (FinOps) 및 비용 관리가 발전해야 합니다. 이를 통해 명확한 가시성, 선제적인 비용 관리, 필요에 맞는 유연한 결제 모델을 확보할 수 있습니다.

이에 따라 Google에서는 오늘 Gemini Enterprise 및 Gemini Enterprise의 Google Antigravity , Android 스튜디오와 같은 개발자 도구 전반에서 에이전트 워크로드에 대한 확장된 결제 유연성과 새로운 비용 관리 도구를 소개하고자 합니다.

유연한 결제 옵션: 기존의 예측 가능한 사용자당 라이선스 구독과 새로운 종량제 옵션을 혼합하여 사용할 수 있습니다. Gemini Enterprise 앱의 종량제 옵션을 사용하면 작업 도중에 할당량 한도에 도달하지 않고도 에이전트 워크로드를 실행할 수 있습니다.
개발자 액세스, AI를 관리할 수 있는 단일 위치: 이제 Gemini Enterprise 구독에 Google Antigravity 및 Android 스튜디오 AI 사용이 포함됩니다 (일부 고객에게 제공되며 곧 광범위하게 출시 예정). 따라서 관리 부담을 늘리지 않고도 개발자에게 더 많은 기능을 제공할 수 있습니다. 플랫폼과 앱 전반의 사용량이 별도의 라이선스 및 결제 사일로가 아닌 단일 뷰로 통합됩니다.
사용량이 늘어날수록 비용 절감: AI 워크로드가 꾸준하거나 증가하는 경우 Flexible Savings Plans를 사용하면 매달 지출할 금액을 약정하고 토큰 비용을 10~20% 절감할 수 있습니다. 최소 금액이나 최대 금액이 없으며 관리해야 할 새로운 청구 사일로도 없습니다.
통합 지출 가드레일: 이제 AI 지출 및 프로젝트에 대한 월별 상한선을 설정하고, 에이전트 런타임 비용을 추정하며, 인보이스가 발행되기 전에 갑작스러운 예산 급증을 포착할 수 있습니다.

Gemini Enterprise에서 지출을 제어하면서도 팀에 유연성을 제공하세요

조직마다 운영 방식이 다릅니다. 동일한 비즈니스 내에서도 팀마다 AI를 소비하는 방식이 다릅니다. 비즈니스 사용자는 일상적인 생산성 도구에 의존할 수 있습니다. 한편 기술팀은 AI 에이전트 워크로드를 버스트로 실행할 수 있습니다.

실제 업무 방식에 맞게 비용을 조정하려면 Gemini Enterprise 전반에서 이러한 결제 및 라이선스 선택사항과 기능을 결합할 수 있습니다.

옵션	작동 방식	지출 최적화에 도움이 되는 이유
사용자당 시트 구독 Gemini Enterprise 앱	사용자당 고정 월별 요금을 지불하며, 여기에는 전체 프로젝트에서 공유되는 일일 할당량 풀이 포함됩니다.	예측 가능한 예산 책정 일관된 일일 생산성 요구사항이 있는 팀의 경우 재무팀에 명확하고 안정적인 월별 기준을 제공합니다.
[신규] Gemini Enterprise 앱 종량제 소비 에디션 *일부 고객에게 제공되며 곧 광범위하게 출시될 예정입니다.	선불 약정이나 기본 구독료가 없으므로 팀에서 표준 모델 API 요율로 소비하는 컴퓨팅 및 토큰에 대해서만 요금을 지불하면 됩니다.	사용한 만큼만 비용을 지불하세요. 실제 사용량에 따라 지출이 자동으로 늘었다 줄었다 하므로 프로젝트 수요가 감소할 때 사용하지 않는 라이선스에 대한 비용을 지불할 필요가 없습니다.
[Gemini Enterprise의 Antigravity 신규 기능] 통합된 공유 할당량	일일 사용 허용량은 프로젝트 전반에 걸쳐 통합되므로 비즈니스 앱, 개발자 도구, 커스텀 에이전트가 동일한 공유 할당량에서 가져올 수 있습니다. 풀링된 할당량은 항상 먼저 소진되며, 관리자는 초과 사용이 허용되는지 여부를 제어할 수 있습니다. 초과 사용이 허용되면 사용한 만큼만 지불 요금이 청구됩니다.	최대화된 리소스 사용량: 비즈니스 사용자의 미사용 일일 할당량이 개발자 또는 커스텀 API 에이전트의 높은 수요를 자동으로 흡수하므로 할당량 낭비가 없습니다.
[출시 예정] 지연된 실행 가격 책정 *일부 워크로드에서 곧 사용 가능	적격 에이전트 워크로드를 연기된 것으로 표시하면 Gemini Enterprise Agent Platform의 지능형 스케줄러가 비피크 용량 기간에 이를 실행합니다.	기다릴 수 있는 작업에 대한 상당한 할인: AI 워크로드는 별도의 비피크 용량으로 실행할 수 있으며, 추론 비용의 최대 절반만 지불하고 표준 할당량 한도를 완전히 우회할 수 있으므로 동일한 예산으로 훨씬 더 많은 에이전트 볼륨을 실행할 수 있습니다.

단일 Gemini Enterprise 구독으로 개발자에게 고급 에이전트 도구 제공

자격 요건을 충족하는 고객의 Gemini Enterprise 구독에 포함된 에이전트 중심 개발자 플랫폼인 Gemini Enterprise의 Google Antigravity에 대한 액세스 권한을 출시하고 있습니다. 이 플랫폼은 기술팀에 강력한 에이전트형 코딩 및 에이전트 빌드 기능을 제공합니다. 또한 Android 개발자는 전문적인 Android 개발을 위한 에이전트 기반 IDE인 Android 스튜디오에서 Gemini Enterprise 구독에 포함된 Google Antigravity 할당량을 기본적으로 활용할 수 있습니다.

에이전트 코딩 비용을 보다 효율적으로 관리하기 위해 각 Gemini Enterprise 구독에 포함된 개발자 도구 할당량을 풀링하여 전체 Google Cloud 프로젝트에서 사용할 수 있도록 합니다. 따라서 팀은 이미 구매한 용량을 활용할 수 있습니다. 개발자는 고급 에이전트 도구에 액세스할 수 있으며, 중앙 집중식 거버넌스와 제어는 유지됩니다.

Gemini Enterprise의 Antigravity에 어떤 새로운 기능이 추가되었는지, 고객이 프로덕션 환경에서 이 기능을 어떻게 활용하고 있는지 자세히 알아보려면 심층 분석을 살펴보세요.

Gemini Enterprise 유연한 비용 절감 요금제 (FSP)로 더 스마트하게 예산 관리

조직에 꾸준히 증가하는 AI 워크로드가 있는 경우 Gemini Enterprise 유연한 비용 절감 요금제는 Gemini Enterprise 사용량 전반에 걸쳐 간단한 지출 기반 약정 모델을 제공합니다. FSP는 예산을 유연하게 유지하면서 토큰 비용을 낮추도록 설계되었습니다.

프로그래매틱 절감액: Gemini Enterprise 전반의 월별 지출에 대해 1년 약정 시 10%, 3년 약정 시 20% 할인을 받으세요.
내 페이스에 맞게: 최소 또는 최대 지출 요건이 없으므로 현재 트래픽에 맞는 월별 약정 금액을 결정하고 시간이 지남에 따라 사용량이 증가하면 조정할 수 있습니다.
엔터프라이즈 계약 (EA) 친화적: FSP 지출은 기존 Google Cloud EA에서 원활하게 차감되므로 비즈니스 부문에서 더 광범위한 클라우드 약정을 분할하지 않고도 전용 예산을 제어할 수 있습니다.

Gemini Enterprise 유연한 비용 절감 요금제는 이미 셀프서비스 고객과 기업 계약 고객에게 제공되고 있습니다.

재정적 규율을 유지하면서 팀이 자유롭게 빌드할 수 있도록 지원

리더로서의 목표는 AI의 잠재적 가치를 제한하는 것이 아니라 관리형 AI 비용 없이 직면하는 재정적 및 운영적 위험을 제거하는 것입니다. 엔지니어링팀, 마케팅팀, 운영팀이 에이전트를 사용하여 혁신할 수 있는 자유를 제공하는 동시에 에이전트가 수행하는 작업을 신뢰할 수 있는 가시성과 예산을 보호할 수 있는 안전망을 갖춰야 합니다.

이러한 격차를 해소하기 위해 Google Cloud는 세 가지 간단한 목표를 중심으로 Google Cloud Billing 콘솔에 강력한 네이티브 거버넌스 도구를 직접 빌드했습니다.

1. 확장하기 전에 계획하기: Google Cloud 가격 계산기를 사용하면 사용자당 라이선스, 개발자 도구, 백그라운드 에이전트 런타임 전반에서 Gemini Enterprise의 예상 비용을 추정할 수 있습니다. 프로젝트 작업이 시작되기 전에 명확한 비즈니스 사례를 빌드하는 데 필요한 수치를 제공합니다.

2. 지출을 세부적으로 관리하지 않고도 경계 적용: 프로젝트팀 전반의 일일 사용량 변동을 추적하는 데 시간을 들이는 대신, 이러한 도구를 사용하여 모니터링을 자동화하세요.

이상치 조기 감지: 프로젝트의 AI 지출 추세가 정상보다 높으면 시스템이 근본 원인 분석을 통해 편차를 표시하고 증가를 유발하는 상위 3개 SKU를 정확히 파악하여 변경된 내용을 정확히 확인할 수 있습니다.

주요 SKU를 강조 표시하는 근본 원인 분석 (RCA) 분석과 함께 초기 이상 알림을 보여주는 결제 콘솔

- 프로젝트 수준 지출 한도: 프로젝트에 명확한 재정적 경계가 필요한 경우 Google Cloud 결제 콘솔에서 직접 월별 지출 한도를 설정할 수 있습니다. 프로젝트가 한도에 도달하면 에이전트의 API 호출이 일시적으로 중지되어 나머지 프로덕션 인프라에 영향을 미치지 않으면서 예산을 보호할 수 있습니다. 예산의 50%, 80%, 100% 에 도달하면 자동 이메일 알림이 전송되어 지출 한도 대비 진행 상황을 알려줍니다.

- 초과 사용량 제어: 지출 한도가 트리거되면 콘솔에서 클릭 한 번으로 작업을 재개하도록 선택할 수 있습니다. 또는 연속적인 운영이 우선순위인 경우 초과 사용량을 사용 설정하여 초과 사용량이 소비 요금으로 원활하게 전환되도록 할 수 있습니다. 이렇게 하면 FSP에서 직접 차감되어 초과 사용량 단위 비용이 크게 할인된 상태로 유지됩니다.

프로젝트에 사용한 만큼만 지불하는 초과분을 사용 설정합니다.

3. 비즈니스 가치에 대한 가시성 확보: 중앙 집중식 청구 보고서를 FinOps 에이전트와 함께 사용하여 예산이 어디에 사용되었는지에 대한 자연어 비용 인사이트 요약을 생성하면 경영진에게 ROI를 간단하게 보여줄 수 있습니다.

Google Cloud 콘솔의 AI 지출 보고

AI 비용 최적화 자세히 알아보기

모델과 인프라의 비용, 지연 시간, 성능을 최적화하는 풀스택 FinOps 전략을 빌드하려면 Google Cloud의 상세한 아키텍처 사양과 프레임워크를 살펴보세요.

동적 용량 관리로 인프라 제약 극복하기: Google Kubernetes Engine과 Google Compute Engine의 기능을 활용하여 컴퓨팅 투자를 최적화하는 방법을 알아보세요. 이러한 기능은 리소스를 자동으로 예약하고 재할당하여 중단, 과도한 프로비저닝, 특정 하드웨어 구성에 대한 과도한 의존을 방지합니다.
엔터프라이즈 고객을 위한 Google Antigravity 확장: 개발자 도구 심층 분석을 읽고 기술팀이 에이전트 중심 워크플로를 통해 소프트웨어 제공을 가속화하는 방법을 알아보세요.
스포츠카가 AI 비용 최적화에 대해 알려주는 것: 토큰이 많다고 항상 더 나은 AI를 의미하는 것은 아닙니다. Gemini Enterprise Agent Platform의 제품 관리 이사인 마이크 클라크와의 대화를 통해 성능과 효율성의 균형을 맞추고 AI에 지출하는 모든 비용에서 최고의 수익을 얻는 방법을 알아보세요.
사용량 급증 시 보호: 사용량이 많은 워크로드가 피크 시간대에 급증하더라도 나머지 시간 동안 유휴 상태로 있는 값비싼 전용 인프라에 대한 비용을 지불할 필요가 없습니다. AI 사용량이 증가함에 따라 Gemini 모델은 인위적인 비율 제한에 도달하지 않고도 요청에 따라 자동으로 확장되어 분당 최대 5천만 개의 토큰을 처리할 수 있습니다. 프로비저닝된 처리량에 대해 자세히 알아보세요.

더 쉬워진 클라우드 전환: Google Cloud에서 마이그레이션 시 데이터 전송 비용 무료

Wed, 07 Feb 2024 01:00:00 +0000

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

Google Cloud는 상호 운용 가능하고 안전하며 개방적인 클라우드 생태계의 번영을 지원하기 위해 최선을 다하고 있습니다. 고객의 비즈니스 니즈가 변화하면 클라우드 또한 유연하게 이러한 변화를 수용할 수 있어야 합니다.

오늘부터 Google Cloud의 사용을 중단하고 다른 클라우드 제공업체나 온프레미스로 데이터를 마이그레이션하기를 원하는 고객은 무료 네트워크 데이터 전송을 통해 Google Cloud 외부로 데이터를 마이그레이션할 수 있습니다. 이 변경사항은 전 세계 모든 고객에게 적용됩니다. 자세한 내용은 여기를 참조하세요.

클라우드 제공업체 변경 시 데이터 전송 비용이 발생하지 않으면 고객이 클라우드 제공업체를 더 쉽게 변경할 수 있게 됩니다. 하지만 이 방법만으로는 근본적인 문제가 해결되지 않습니다. 애당초 많은 고객이 각자가 선호하는 클라우드 제공업체와 협력하지 못하도록 가로막는 것은 불공정하고 제한적인 라이선스 관행입니다.

일부 기존 제공업체는 온프레미스 소프트웨어 독점을 발판으로 클라우드를 독점하고 제한적인 라이선스 관행을 통해 고객을 궁지에 몰아넣으며 경쟁을 훼방하고 있습니다.

라이선스 제한이라는 복잡한 그물망 안에는 고객이 협력할 수 있는 대상과 방법을 선별 및 제한하고, 고객이 특정 경쟁업체의 클라우드를 사용하려 할 경우 비용의 5배를 청구하며, 경쟁업체의 클라우드 인프라 및 필수 소프트웨어의 상호 운용성을 제한하는 행위 등이 포함되어 있습니다. 하지만 이같이 제한하는 관행에는 기술적인 근거도 없을 뿐더러, 고객에게 300%의 비용 증가를 야기할 수 있습니다. 반면, 고객이 클라우드 제공업체 외부로 데이터를 마이그레이션할 때는 최소한의 비용밖에 들지 않습니다.

그러나 고객이 한 제공업체에서 다른 제공업체로 더 쉽게 이동할 수 있게 되더라도 제한적인 라이선스에 매여 있다면, 고객의 선택권을 개선하는 데는 큰 도움이 되지 않습니다. 고객은 기존 제공업체의 지나치게 제한적인 약관이나 징벌적인 라이선스 관행에 얽매이지 않고 비즈니스에 적합한 클라우드 제공업체를 선택할 수 있어야 합니다.

정부와 기업이 기술 사용을 원활하게 확장할 수 있도록 지원할 때 클라우드의 전망이 밝아집니다. 오늘의 발표는 Google Cloud에서 워크로드를 실행하는 크고 작은 조직을 위해 더 많은 가치를 제공하고 데이터 전송을 개선하기 위해 지난 몇 달 동안 취한 여러 가지 조치의 연장선 위에 있습니다.

클라우드 시장의 경쟁과 고객의 선택을 가로막는 제한적인 라이선스 관행을 종식하려면 아직도 넘어야 할 산이 많습니다. 많은 클라우드 고객이 기존 제공업체의 라이선스 제한에 대한 우려를 Google Cloud에 직접 표명해 주고 계십니다. Google Cloud는 클라우드 고객을 대변하여 목소리를 내기 위해 앞으로도 변함없는 노력을 기울이겠습니다.

현장에서 배우는 FinOps: 클라우드 비용 예측하기

Wed, 31 Jan 2024 01:00:00 +0000

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

저는 클라우드 컴퓨팅이 많은 비즈니스의 필수적인 부분으로 자리잡은 시대에 현장에서 테크니컬 어카운트 관리자로 일하면서 클라우드 컴퓨팅이 비즈니스의 비용 절감과 민첩성 개선에 어떤 도움이 되는지 직접 경험했습니다. 하지만 클라우드 비용 예측의 어려움은 클라우드로 이전할 때 비즈니스가 자주 겪는 문제 중 하나입니다. 조심하지 않으면 클라우드 비용이 걷잡을 수 없이 높아질 수 있기 때문에 클라우드 비용 예측에 대한 관심이 커지고 있습니다.

클라우드 비용 예측은 기본적으로 미래의 클라우드 사용량을 전망하는 프로세스입니다. 자금을 조달하거나, 예산을 정하거나, 새로운 클라우드 프로젝트에 대한 지지를 확보하려 할 때 예측은 중요한 역할을 합니다. 또한 클라우드 비용을 예측하면 FinOps 전략을 잘 따르고 있는지 판단하는 데에도 도움이 됩니다.

하지만 많은 기업에서 클라우드를 정확하게 예측하는 데 난항을 겪습니다. Finops의 현 상황(The State of Finops) 설문조사에서 전문성이 높은 실무자 집단은 자신의 예측에 +/- 5% 가량의 오차가 있다고 응답한 반면 전문성이 낮은 집단은 오차가 +/- 20%에 이른다고 응답했습니다.

현장에서 보는 시각

흔히 '예측'이란 단어를 들으면 가장 먼저 기상 예보를 떠올리게 되는데, 기상 예보에서는 특히 시즌에 따른 변동이 중요한 요소입니다. 예를 들어 봄 날씨가 겨울 날씨보다 훨씬 포근하고 눈보라나 무더위가 올 확률이 극히 낮다는 것은 누구나 알고 있습니다. 그리고 1년 중 가장 황사가 많이 발생하는 시즌이라는 것을 감안하면 특정 봄 시기에 어떤 날씨가 나타날지 예측할 수 있게 됩니다.

이 개념을 클라우드 워크로드에 적용하면 클라우드 사용량에 큰 영향을 미치는 시기와 이벤트를 발견할 수 있습니다. 예를 들어 세일 기간이나 연말 연시에 수요가 급증하는 것을 확인할 수 있으며, 이러한 수요 급증은 소비량에 직접적인 영향을 주어 비용 증가로 이어집니다. 결과적으로 사용량을 예측하려면 과거의 데이터 소비량을 알아야 할 뿐 아니라 향후 소비량에 영향을 미칠 수 있는 핵심 요소도 알고 있어야 합니다.

자가 진단 문항:

귀사의 비즈니스에 성수기가 있나요?
장래에 제품 사용자 또는 소비량 증가로 이어질 수 있는 새로운 프로젝트, 마케팅 이벤트, 클라우드 이전을 계획 중인가요?
향후 예측 주기에 적용하기 위한 목적의 데이터를 얼마나 자주 취합하나요?

과거 사용량

정확한 예측의 또 다른 핵심 요소는 과거 데이터입니다. 과거 사용량을 분석하면 향후의 워크로드 변화 추이를 가늠해 볼 수 있습니다. 과거의 데이터는 미래에 발생할 비용을 판단할 수 있는 핵심 자료이며, 이를 바탕으로 계획을 수립하면 예기치 않은 비용 발생을 방지하는 데 도움이 됩니다. 예를 들어 애플리케이션을 마이그레이션하는 지난 몇 개월 동안 꾸준히 사용량이 증가했다면 앞으로도 계속 증가하리라 예상할 수 있습니다. 아울러 사용량의 변동폭이 크다면 보다 강력한 비용 관리 전략을 구현해야 할 수 있습니다.

자가 진단 문항:

과거 사용량에 확인된 성수기가 반영되었나요(성수기가 있는 경우)?
과거 사용량에 예정된 비즈니스 이벤트가 반영되었나요?
예측과 실제 결과 간에 발생한 오차를 적절히 조사했나요? 오차를 분석한 결과는 어땠나요? 분석에서 얻은 교훈을 예측 모델에 적용할 수 있나요?
장기적인 추세선은 어떨 것으로 예상하나요?

과거 데이터를 이해하면 정보에 근거해 향후 발생할 비용을 판단할 수 있습니다. 팁: Google Cloud에서는 Cloud Billing 데이터를 BigQuery로 내보내 소비량을 추적할 수 있습니다.

클라우드 비용 예측을 위한 도구

과거 데이터와 앞으로 발생 가능한 이벤트를 알고 있다면 향후 클라우드 비용도 예측해 볼 수 있습니다. 실무자들이 두 가지 요소를 합치는 데 사용할 수 있는 여러 도구가 있으며 그중에는 다음과 같은 것이 있습니다.

기본적인 클라우드 비용 관리 도구(GCP의 경우 Cloud Billing 콘솔)
Cost Estimation API
스프레드시트
BQML 또는 Vertex-AI를 사용하는 머신러닝 모델
서드 파티 예측 도구

구체적인 필요와 예산에 따라 적절한 예측 방법이 달라집니다. 예산이 적고 사용이 익숙하다면 스프레드시트를 사용할 수도 있습니다. 하지만 예산이 많은 편이고 예측의 정확도를 높여야 한다면 클라우드 비용 관리 도구, 혹은 서드 파티 예측 도구를 사용하는 편이 나을 수 있습니다.

이왕이면 Google Cloud Billing 콘솔에서 바로 사용할 수 있는 예측 기능부터 사용해 보세요. 이 콘솔은 사용량을 기반으로 이번달에 예상되는 비용을 알려줍니다. 이 예측값은 지금까지 발생한 실제 비용과 예상되는 비용 추세를 결합한 것이며, 해당 결제 계정에 속한 모든 프로젝트의 과거 사용량을 바탕으로 추산된 예상 비용을 알 수 있습니다. 또한 조직의 프로젝트, 서비스, SKU, 폴더별로 보고서를 필터링하여 이 예측 결과를 조정할 수도 있습니다.

전체 조직보다는 단일 프로젝트에 한정된 클라우드 예측이 더 수월하기 때문에 각 프로젝트를 개별적으로 예측한 다음 예측을 종합해 정확성을 높이는 것이 바람직합니다. 이러한 분할 전략은 소규모로 시작해 매우 포괄적인 예측 결과를 얻을 수 있는 훌륭한 접근방식입니다.

현장에서 얻은 경험

최근에 내년도 예정 지출을 계산하려는 소매업 고객사의 예측 작업에 참여한 적이 있었습니다. 고객사에 Google Cloud 연간 약정을 예측할 만한 근거 자료가 없었기 때문에, Google Cloud 계정팀에서 향후 클라우드 비용에 대한 대략적인 예상치를 계산해서 준비했습니다.

이 고객과의 작업에서 다행이었던 점은 기존에 GCP를 사용하던 고객이었기 때문에 다음과 같은 면에서 비용 예측이 다소 수월했다는 것이었습니다.

과거 데이터에서 정보를 얻을 수 있음
Google Cloud에서 고객사의 클라우드 여정과 현재 성숙도 수준을 이미 알고 있음
고객사의 주요 워크로드를 익히 알고 있음
전반적인 내년도 계획을 고객으로부터 공유받음

이러한 몇 가지 이점이 있었지만 각 프로젝트의 세부정보는 몰랐기 때문에 프로젝트별로 예측해서 나중에 모든 예측값을 합치는 방식으로 진행하지는 못했습니다. 대신 Compute Engine, GKE, 애널리틱스, 네트워킹 등과 같은 서비스 유형별로 지출 영역을 나누었다가 나중에 합치는 방식을 사용했는데, 예측 수행 과정에서 따랐던 단계별 방법은 다음과 같습니다.

모든 지출을 서비스 카테고리(애널리틱스, 컴퓨팅, 네트워킹 등)별로 나누어 그룹화합니다.
각 서비스 카테고리의 현재 지출과 지난 2개월 지출의 평균값을 구합니다.
1년 전 같은 기간의 평균값을 구합니다.
두 평균값을 비교하여 추세를 파악하고 각 카테고리에 성장률을 할당합니다.
모든 향후 계획을 반영합니다. 이를 위해 정기적, 신규, 비정기적 워크로드에 각기 수정치를 적용합니다.
추산된 결과를 고객과 공유하고 고객의 의견을 바탕으로 조정합니다.

예측이 정확했는지는 시간이 흐른 후에야 판단할 수 있으며 언제든 예측하지 못한 요인이 이벤트의 결과에 영향을 미칠 수 있습니다. 오직 시간만이 예측의 정확도를 판가름할 것입니다.

마무리 조언

클라우드 비용을 예측할 때는 현실적인 자세를 취하는 것이 중요합니다. 비용이 같은 수준으로 유지되리라고 넘겨짚지 마세요. 클라우드 사용량의 변화, 비용 발생 요인의 변화, 클라우드 시장의 변화 그리고 가격 변동사항을 반영하세요. 고객사가 클라우드 비용을 파악하는 과정을 도우면서 깨달은 것이 있다면 일관되게 사용되는 제품도 있지만 어쩌다가 사용되는 제품도 있다는 사실입니다. 예를 들어 한 달 동안 집중적으로 사용되던 제품이 그 이후 3개월간 전혀 사용되지 않기도 합니다.

마지막으로, 클라우드 비용 예측은 정기적으로 검토하고 재계산하면서 꾸준히 유지해야 하는 프로세스입니다. 1년간 꾸준히 업데이트하는 편이 연말에 한꺼번에 업데이트하는 것보다 더 나은 결과로 이어질 수 있습니다.

지금까지 말씀드린 미래의 클라우드 비용을 예측하는 방법을 활용해 예측 값과 실제 결과를 비교해 추적하고 모니터링하며 오차 분석을 수행해 보시기 바랍니다.

개발자가 보안, 가성비, 탄소 감축을 최적화하는 데 ML 기반 추천을 활용하는 방법

Wed, 21 Jun 2023 07:00:00 +0000

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

머신러닝이 시민과 소비자의 생활에 어떤 긍정적인 영향을 미칠 수 있는지에 대한 얘기는 쉽게 접할 수 있습니다. 그런데 머신러닝이 클라우드 관리자를 위해 복잡하고 반복적인 업무를 줄여줄 수 있다는 사실을 알고 계셨나요? Google Cloud Active Assist는 데이터, 인텔리전스, ML을 사용하여 클라우드 환경의 보안, 성능 및 비용을 최적화합니다. Active Assist 포트폴리오의 도구에는 Policy Intelligence, Network Intelligence Center, Predictive Autoscaler와 다양한 Google Cloud 서비스를 위한 추천 모음이 포함되어 있습니다. Active Assist는 올해 Google Cloud Next의 주요 주제였으며, 이 기회를 빌어 지난 한 해 동안 출시된 모든 기능을 간략히 살펴보고, 자세한 내용을 알아볼 수 있는 몇 가지 리소스를 소개해 드리겠습니다.

Active Assist의 주요 신기능

더 적은 비용으로 더 많은 작업을 하고자 Google Cloud에 지원을 요청하는 고객이 증가하고 있습니다. Google은 고객의 의견을 적극 반영하여 비용을 최적화하고 비용과 성능 사이에서 적절한 균형을 맞추고 보안을 집중적으로 강화하는 데 도움이 되는 여러 핵심 영역에 초점을 맞춰 다음과 같은 기능 및 제품을 마련했습니다.

방화벽 인사이트에서 새롭게 개선된 부분 [블로그, 문서]
분석을 위해 BigQuery로 추천 및 인사이트 내보내기 [블로그]
BigQuery 슬롯 추천자 [블로그, BigQuery에서 비용과 성능 간 균형을 이루는 방법]
Cloud SQL 비용 최적화 추천자 [블로그, 유휴 및 초과 프로비저닝된 인스턴스 감지하기)
미사용 프로젝트 추천자의 맞춤설정 기능 향상 [관찰 기간 맞춤설정]
Error Reporting 추천 [문서, 오류 보고 빠르게 찾기]
Cloud Run 서비스 계정 추천자 [블로그, Cloud Run 서비스 보안 향상]
GKE 지원 중단 알림 [문서, 지원 중단에 대한 K8s 클러스터의 노출 평가하기]
빠른 액세스 기반의 Google Cloud 새 홈페이지 환경 [블로그 #1, 블로그 #2, Google Cloud 콘솔을 보다 편리하게 만들기]
Cloud Storage 버킷 수준 역할 추천 [문서, 스토리지 버킷에 최소 권한 원칙 적용]
Dataflow 진단 추천자 [블로그, 작업별 진단 정보 및 활용 가능한 분석 정보]
미사용 프로젝트 추천에 비용 영향 추가 [블로그, 문서]

Next ’22에서 Active Assist를 주제로 진행된 8개 세션

Next ’22의 여러 흥미로운 소식과 발표 중에서 Active Assist 포트폴리오에 포함된 제품을 다룬 세션을 요약했습니다.

다음을 확인하세요 :

DEVKEY1 10가지 주요 클라우드 기술 예측
이 개발자 기조연설 세션에서는 2025년 말까지 현실화될 가능성이 높은 것으로 판단되는 10가지 주요 클라우드 기술 예측을 확인할 수 있습니다. 최첨단 기술 트렌드 중에서 Active Assist는 고객이 지속 가능성 과제에 대처하는 데 도움이 되는 Google Cloud 솔루션의 핵심 요소로 손 꼽힙니다.

OPE100 DevOps, 시스템 관리자, 운영자를 위한 다음 단계
Active Assist 솔루션 포트폴리오에 포함된 Cloud SQL 보안 통계는 고객이 보안 취약점을 줄이고 보안 상황을 개선하고 운영 효율성을 높이는 데 도움이 되는 여러 보안 통계를 제공합니다. Active Assist의 미사용 프로젝트 추천을 Google Cloud 탄소 발자국과 함께 사용하면 고객이 미사용 프로젝트의 리소스를 해제하여 탄소 배출을 줄이는 데 도움이 됩니다.

MOD105 엔터프라이즈 설계자와 개발자를 위한 다음 단계
이 대담에서 다루는 Compute Engine의 예측 자동 확장 처리 기능은 Active Assist를 통해 구현되며, 고객이 비용 균형을 유지하면서도 운영 효율성을 대폭 개선하는 데 도움이 됩니다.

MOD103 Google Cloud에서 비용을 절감할 수 있는 10가지 주요 방법
이 세션에서는 Compute Engine부터 Cloud SQL에 이르기까지 폭넓은 Google Cloud 서비스를 지원하는 Active Assist의 모든 비용 최적화 추천사항을 알아보고, 실제 고객 사례를 통해 고객이 전반적인 클라우드 지출을 수백만 달러 절약하는 데 이러한 도구가 어떻게 도움이 되는지를 살펴봅니다.

OPE202 Day 2 운영작업의 복잡성 완화하기
초기 클라우드 배포 후 Day 2 운영이 어려울 수 있다는 점을 잘 알고 있습니다. 새로운 혁신을 추진하면서도 기존 사용자를 만족시켜야 하기 때문입니다. 이 세션에서는 Day 2 운영 과제를 해결하는 데 도움이 되는 도구로서 Active Assist를 다룹니다.

ANA105 관리형 데이터베이스로 앱을 마이그레이션하기에 지금이 적기인 이유
이 세션에서는 비용과 성능의 균형을 맞추는 것부터 안정성과 보안을 개선하는 데 이르기까지 관리형 MySQL 환경을 보다 편리하게 만들기 위한 핵심인 Active Assist 기반의 Cloud SQL 지능형 솔루션 모음을 소개합니다. Active Assist는 Google Cloud와 함께 하는 여정의 모든 단계에서 도움이 됩니다.

MOD107 네트워크, 데이터, 컴퓨팅과 같은 클라우드 인프라를 Google 방식으로 보호하기
Google은 세계 최대 규모의 웹 앱과 서비스를 보호하고 있습니다. 이 과정에서 Google은 컴퓨팅, 데이터, 네트워크와 같은 클라우드 인프라를 보호하는 방법에 대한 여러 노하우를 얻었습니다. 이렇게 터득한 노하우를 Google Cloud에 적용하여 고객을 위한 보안을 기본적으로 실현합니다. Active Assist 기반의 방화벽 통계는 모든 Google 보안 솔루션의 핵심 요소입니다. 이 세션에서 자세한 내용을 확인하세요.

MOD205 모든 워크로드를 위한 네트워크 간소화 및 보호
클라우드 네트워킹은 기업에서 더 쉽고 빠르게 마이그레이션, 빌드, 확장하는 데 도움이 되는 많은 기능을 제공합니다. Network Intelligence Center를 통해 제공되는 새로운 관측 가능성 기능인 네트워크 분석기는 기본 네트워크로 인해 발생하는 장애를 자동으로 감지하고 근본 원인 분석을 수행하고 서비스의 가용성, 성능, 보안을 개선할 수 있는 권장사항을 제안하여 고객의 역량을 강화합니다. 고객은 네트워크 분석기를 통해 사후 대응적 워크플로를 사전 예방적 프로세스로 전환하여 네트워크 및 서비스 다운타임을 줄일 수 있습니다.

편리하게 확인하실 수 있도록 Next ’22의 모든 Active Assist 관련 세션을 재생목록으로 준비했습니다.

What's next?

최신 Active Assist 기능, 추천자, 추천 허브 경험 또는 Next ’22 세션에 대한 의견이 있다면 언제든 전해주세요. active-assist-feedback@google.com으로 경험과 제안을 보내주시면 성심성의껏 검토하겠습니다.

Active Assist를 비롯한 Google의 모든 포트폴리오 제품과 솔루션을 자세히 알아보고 싶으신가요? 솔루션 홈페이지를 확인하세요. 제 Twitter 계정을 팔로우하셔도 됩니다. 읽어 주셔서 감사드리며 여러분의 소중한 의견을 기다리겠습니다.

Google Cloud VMware Engine 배포 비용 최적화

Fri, 18 Mar 2022 00:00:00 +0000

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

Google Cloud VMware Engine에서는 ESXi 노드를 주문형으로 추가하고 삭제할 수 있어 단 몇 분 만에 전용 하드웨어와 함께 관리형 VMware 환경을 배포할 수 있습니다. 이러한 유연성은 필요에 따라 컴퓨팅 용량을 빠르게 추가할 때 특히 편리합니다. 하지만 예상치 못한 비용 증가를 피하려면 비용 최적화 전략과 검토 프로세스를 구현해야 합니다. 늘어난 워크로드 용량을 수용하려면 하드웨어를 ESXi 클러스터에 추가해야 하므로 프라이빗 클라우드를 확장할 때는 각별한 주의가 필요합니다.

이 블로그에서는 전반적인 비용 최적화에 초점을 맞춰 Google Cloud VMware Engine 프라이빗 클라우드를 운영하기 위한 권장사항을 살펴봅니다.

Google Cloud VMware Engine 결제 원칙

고객에게는 배포된 VMware ESXi 노드 수를 기준으로 한 시간 단위 요금이 청구됩니다. Compute Engine에서 가상 머신 인스턴스에 제공하는 약정 기반 가격 책정 모델과 마찬가지로 Google Cloud VMware Engine도 1년 및 3년 약정 사용 할인을 제공합니다. 자세한 가격 책정 정보는 Google Cloud VMware Engine 제품 개요 페이지의 가격 책정 섹션을 참조하세요.

비용 최적화 전략 1: 약정 사용 할인 적용

약정 사용 할인(CUD)은 1년 또는 3년간 특정 리전에서 여러 Google Cloud VMware Engine 노드를 실행한다는 약정을 기반으로 한 할인입니다. 3년 약정의 CUD에서는 계약이 시작될 때 비용을 전액 청구할 경우 최대 50% 할인이 제공될 수 있습니다. 예상하셨겠지만 약정 기반 할인은 구매 후 취소할 수 없습니다. 따라서 프라이빗 클라우드에서 실행할 노드 수에 대한 확신이 있어야 합니다. Google Cloud VMware Engine이 데이터 센터를 마이그레이션할 대상 플랫폼이라면 1년 또는 3년간 실행할 최소한의 노드 수에 이 할인을 적용하고 정기적으로 필요한 노드 수를 수정하세요.

비용 최적화 전략 2: 스토리지 소비 최적화

워크로드에서 많은 스토리지를 소비하는 경우(예: 백업 시스템, 파일 서버 또는 대규모 데이터베이스) 클러스터를 확장해 추가 vSAN 스토리지 용량을 추가해야 할 수 있습니다. 스토리지 소비를 적게 유지하려면 다음 최적화 전략을 고려해 보세요.

동일한 수준의 FTT(허용되는 장애)를 유지하면서 RAID 1(기본 스토리지 정책)이 아닌 RAID 5 또는 RAID 6을 사용하는 커스텀 스토리지 정책을 적용하세요. FTT 수는 ESXi 클러스터의 월간 업타임 SLA와 직접적인 관련이 있어 주요 측정항목으로 간주됩니다. RAID 1 인코딩 스키마는 중복성을 위해 데이터 블록을 미러링하기 때문에 FTT=1인 RAID 1을 사용하는 스토리지 정책에서는 스토리지 오버헤드가 100% 발생하게 됩니다. 마찬가지로 FTT=2가 필요한 경우(예: 99.99% 업타임 가용성을 필요로 하는 보다 중요한 워크로드) RAID 1에서 스토리지 오버헤드가 200% 생성됩니다. RAID 5 구성은 FTT=1인 스토리지 정책을 33%에 불과한 스토리지 오버헤드로 달성할 수 있으므로 스토리지 효율성이 더 높습니다. RAID 6에서도 FTT=2를 단 50%의 스토리지 오버헤드로 제공할 수 있습니다. 즉, RAID 1 기본 스토리지 정책을 사용할 때보다 스토리지 소비를 50% 절약할 수 있습니다. 그러나 RAID 1은 스토리지 기기에 대해 필요한 I/O 작업 수가 적으며 더 나은 성능을 제공할 수 있다는 점을 참고하세요.
'씬 프로비저닝' 형식을 사용해 새 디스크를 만드세요. 씬 프로비저닝된 디스크는 소규모로 시작했다가 디스크에 기록되는 데이터가 늘어남에 따라 확장되므로 스토리지 공간을 절약할 수 있습니다.
vSAN 스토리지를 백업으로 채우지 마세요. Actifio와 같은 백업 도구는 VMware 환경 및 Cloud Storage와의 통합을 제공합니다. 이에 따라 운영자는 저렴한 스토리지 위치로 백업을 이동시킬 수 있습니다. 장기 보관해야 하는 백업 데이터는 특정 기간이 지난 후 저렴한 스토리지 클래스로 데이터를 이동시키는 수명 주기 정책을 사용해 Cloud Storage 버킷 내에 저장해야 합니다.
vSAN 클러스터의 중복 삭제 및 압축을 사용해 중복된 데이터 블록 수를 줄여 전체 스토리지 소비를 줄이세요.

비용 최적화 전략 3: ESXi 클러스터 크기 조정

CPU, 메모리, 스토리지 사용률이 높아도 워크로드 장애 없이 ESXi 노드의 중단을 지원할 수 있도록 ESXi 클러스터 크기를 조정하세요. 리소스 사용률이 최대 용량에 가깝게 클러스터를 작동시킬 경우 갑작스러운 하드웨어 장애가 발생하면 서비스 중단이 발생할 수 있습니다. 최대 리소스 사용률 측정항목(CPU, 메모리 또는 스토리지)을 약 70%로 설정하면 클러스터를 안전하게 작동하면서 클러스터의 기능을 사용할 수 있습니다.
단일 노드 클러스터로 새 프라이빗 클라우드 배포를 시작하고 필요할 때 확장하세요. Google Cloud VMware Engine에 최근 테스트 및 개념 증명을 위해 단일 노드를 포함한 프라이빗 클라우드를 만들 수 있는 기능을 추가했습니다. 단일 노드 클러스터는 최대 60일 동안만 유지되며 SLA가 적용되지 않습니다. 하지만 2일 차 도구, 구성, 테스트와 통합하는 동안 비용을 최소화할 수 있는 좋은 방법입니다. 프라이빗 클라우드 시작 영역을 완전히 구성한 후 단일 노드 클러스터를 노드가 3개인 클러스터로 확장해 SLA의 적용을 받을 수 있습니다.
가능하다면 ESXi 클러스터를 통합하세요. 여러 개의 클러스터에서 워크로드를 실행 중이라면 여러 클러스터에서 리소스가 보다 효율적으로 분산되도록 클러스터를 통합할 수 있는지 검토하세요. 예를 들어 워크로드가 OS 유형 또는 프로덕션 및 비프로덕션에 따라 구분되어 있는 경우 클러스터를 통합하면 리소스 사용률을 높일 수 있습니다. 하지만 라이선스 요구사항 등 통합을 막는 기타 제약조건이 있는지 신중하게 검토해야 합니다. 라이선스 요구사항으로 인해 VM을 특정 노드에서 실행해야 한다면 DRS 어피니티 규칙을 사용해 워크로드를 특정 노드에 고정하는 것을 고려하세요.
가능하다면 프라이빗 클라우드를 통합하세요. 프라이빗 클라우드를 여러 개 실행하는 경우 프라이빗 클라우드를 통합할 수 있는지 검토하세요. 프라이빗 클라우드마다 자체적인 관리 VM 집합이 필요하기 때문에 전체 리소스 소비에 오버헤드가 발생합니다.

비용 최적화 전략 4: 워크로드의 리소스 사용률 검토

1. 애플리케이션이 안정적으로 실행되면 이후 지속적으로 VM의 리소스 사용률을 검토하세요. vCenter 측정항목을 프로그래매틱 방식으로 또는 시각적으로 추출하여 적정 크기 권장사항을 확보하세요. 예를 들어 VM에서 CPU 및 메모리 리소스를 필요 이상으로 사용하는 경우 애플리케이션의 정기 다운타임 동안 VM 매개변수를 조정하세요(재부팅 필요).

vCenter에서 CPU 및 메모리 사용률 통계를 추출하고 데이터를 CSV 파일 등의 편리한 형식으로 저장하는 스크립트의 실행을 예약해 보세요. 예를 들어 스크립트 실행 호스트에서 PowerShell을 사용해 이를 구현할 수 있습니다.

최소 30일간의 평균 CPU 및 메모리 사용률을 합리적인 기준 값과 비교하여 워크로드를 사용률 초과 또는 미달 리소스로 분류하는 기준을 정의하세요.

예시 조건(요구사항에 맞춰 기준 조정 가능):

CPU 사용량(30일 및 1년 평균) 비율 (<) 50% 미만
CPU 사용량(30일 및 1년 최대) 비율 (<) 80% 미만

위와 같이 권장되지만 갑작스러운 변경은 피하고 워크로드 요구사항을 기준으로 항상 신중하게 데이터를 검토해야 합니다.

2. Cloud Monitoring 및 독립형 에이전트 통합을 사용해 클러스터 및 워크로드 측정항목을 검토하세요. 설치 가이드를 따라 측정항목 전달을 사용 설정해 vCenter 측정항목을 Cloud Monitoring과 통합합니다.

3. 워크로드가 CPU/메모리의 제약을 받는 경우 VMware vROps와 같은 타사 도구를 사용해 확보한 용량 및 사용률 통계를 바탕으로 적정 크기로 조정하세요(자세한 내용은 블로그 게시물 참조). vROps를 사용하려면 추가 라이선스가 필요하며 VM/호스트마다 vROps를 설치해야 합니다.

비용 최적화 관리 - 인력 및 프로세스

비용 최적화의 효율성은 운영을 지원하고 실행할 수 있는 인력 및 프로세스의 준비 여건에도 달려 있습니다.

1. 비용 최적화 부서 마련 - 클라우드 운영 모델의 비용 관리 및 최적화는 단일 팀의 책임이 아니며 오히려 여러 팀/역할의 공동의 노력이 필요합니다. 최적화를 공동의 최우선 과제로 삼고 Cloud 핵심 전략팀(CoE), 재무팀(최적화 목표 정의 및 지출 모니터링), 설계팀(최적화 옵션 검토), 운영/SRE팀(옵션 구현) 내에 비용 최적화를 위한 중앙 부서를 구축하려면 경영진의 후원과 지원이 필요합니다. 가용성 및 성능이 워크로드에 미치는 영향을 검증하기 위해 비즈니스/애플리케이션 이해관계자의 참여도 이끌어내야 합니다.

2. Crawl-Walk-Run(기어가기-걷기-달리기) 접근방식 채택 - 비용 최적화는 지속적인 작업으로서 기업의 클라우드 도입 성숙도 곡선을 따릅니다. 시작할 때 지원 프로세스 및 도구를 정의하고 확장하면서 개선해 나가세요.

3. 최적화 옵션 우선순위 지정 - 최적화는 상당한 비용 절감 효과를 가져올 수 있지만 이를 위해서는 리소스 노력과 시간이 소요됩니다. 잠재적 절감 효과와 예상되는 작업량을 토대로 옵션의 우선순위를 정하여 지출을 줄이고 즉각적 성과를 실현할 수 있는 가장 영향력 있는 방법을 찾아야 합니다.

4. 보고 및 측정 - 중요한 주요 측정항목(예: 사용자/테넌트-고객당 비용)을 식별하고 KPI를 정의하여 이를 기준으로 최적화 성과 및 성공을 지속적으로 측정해야 합니다.

재무 책임 및 비즈니스 가치 실현을 위한 전체적인 프레임워크는 Cloud FinOps 백서를 참조하세요. 클라우드 비용 최적화 원칙 블로그 게시물에서 도구 및 비용 최적화 권장사항에 대한 추가 안내도 확인하세요.

클릭 유도 문구

이 블로그 게시물에서 프라이빗 클라우드의 전반적인 비용을 절감할 수 있는 다양한 수준의 구현 전략을 살펴보았습니다. 단기간 내에 비용을 절감하기 위해 구현할 수 있는 즉각적 성과로는CUD 사용과 커스텀 스토리지 정책으로 전반적인 vSAN 스토리지 소비 최적화 등이 있습니다. 특히 VMware Engine을 1년 이상 워크로드의 플랫폼으로 사용하는 경우 CUD 사용이 유효합니다.

클러스터 및 VM 사용률 측정항목을 모니터링하는 프로세스 채택을 포함한 최적화 전략은 워크로드가 과도하게 큰지 여부를 파악하는 데 도움이 됩니다. 하지만 워크로드 크기 조정을 서둘러서는 안 되며 안정적인 상태에서 측정항목을 신중하게 검토해야 합니다. 이러한 비용 최적화는 장기적으로 효과가 나타납니다.

Google Cloud에서 개발한 아키텍처 프레임워크는 지출을 최적화하면서 Google Cloud VMware Engine을 도입할 수 있어 클라우드 여정의 수익을 극대화하는 데 도움이 됩니다. 자세한 내용은 Google Cloud 계정팀에 문의하세요.

기업 고객의 비용 최적화 프로세스 구현과 관련해 도움을 주신 웨인 추에게 감사의 말을 전합니다.

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

Tue, 11 May 2021 00:00:00 +0000

* 본 아티클의 원문은 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 및 시작 방법에 대한 자세한 내용은 안내 가이드를 참조하세요. 가져오기 패턴 및 수명 주기 관리와 관련된 객체 스토리지 비용 최적화를 다룬 추가 블로그 게시물을 기대해 주세요.