스토리지 및 데이터 전송

Google Cloud의 U4 컴퓨팅 소개: 초저지연 트레이딩 지원

Wed, 14 Oct 2026 17:00:00 +0000

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

자본 시장에서는 패킷 전송 타이밍의 미세한 차이가 주문 대기열의 우선순위와 거래 체결에 영향을 미치므로 성공적인 운영을 위해서는 예측 가능한 성능과 짧은 지연 시간을 확보해야 합니다. 한편 기존 온프레미스 데이터 센터 환경에서는 거래소와 시장 참여자 모두가 전력 및 물리적 랙 공간의 제약뿐 아니라 하드웨어 조달에 오랜 시간이 걸리는 등 갈수록 심해지는 제약에 직면해 있습니다. 이에 따라 글로벌 자본 시장에서는 물리적 코로케이션의 속도와 결정성을 클라우드의 동적 확장성 및 자동화 기능과 결합하려는 움직임이 늘고 있습니다.

Google Cloud Next '26에서 발표되었던 ULL(Ultra Low Latency) Solution이 이제 정식 버전으로 제공됩니다. 이 솔루션은 클라우드에서 실행되는 고빈도 트레이딩 워크플로에 초저지연 네트워크와 민첩성을 제공합니다. ULL Solution에 새롭게 포함된 U4 머신 계열도 오늘부터 정식 버전으로 제공됩니다.

ULL Solution은 다음과 같은 세 가지 인프라 핵심 요소를 기반으로 합니다.

하드웨어 수준 네트워킹: 안정적인 시장 데이터 피드를 위해 확장 가능한 하드웨어 기반 멀티캐스트 데이터 배포 제공
고급 네트워킹 모니터링 가능성: 하드웨어 수준의 정밀한 타이밍으로 네트워크 트래픽을 동적으로 캡처하여 기본적인 트래픽 성능에 영향을 주지 않고 일관된 감사, 시장 상황 재현, 확실한 거래 검증 지원
결정론적인 고성능 컴퓨팅: 지연 시간에 민감한 트레이딩 실행 계층의 작업을 매번 예측 가능하고 일관된 시간 내에 처리

ULL Solution의 컴퓨팅, 스토리지, 네트워킹, 모니터링 가능성을 종합적으로 활용할 때 금융 거래소와 시장 참여자는 다음과 같은 기술적 역량을 활용할 수 있게 됩니다.

베어메탈 성능: 전용 베어메탈 컴퓨팅을 통해 물리적 호스트 리소스에 직접 액세스할 수 있어 잡음을 최소화하고 시장 데이터 피드와 주문 라우팅에서 예측 가능한 저지연 실행이 가능해집니다.
고성능 스토리지 옵션: 로컬 티타늄 SSD가 호스트에서 실시간 트랜잭션과 틱 로깅을 처리하며, 확장 가능한 Google Cloud Hyperdisk까지 더해져 시장 데이터의 영구 보관과 분석을 지원합니다.
물리적 트래픽 격리: ULL 트레이딩 패브릭의 이중화된 A/B 멀티캐스트 시장 피드는 서로 독립적인 2개의 전용 Titanium 어댑터를 통해 액세스되는 반면, 별도의 세 번째 Titanium 어댑터는 원격 분석과 관리 작업을 오프로드하고 Google Cloud 서비스에 대한 액세스를 제공합니다.
하드웨어 가속 멀티캐스트 배포: ULL 네트워크 아키텍처는 하드웨어 수준에서 멀티캐스트 피드를 수집하는 기능을 지원합니다. 따라서 시장 참여자는 기존 하이퍼바이저 수준의 가상 스위치를 거치지 않고도 처리량이 높은 시장 데이터를 저지연 트레이딩 애플리케이션으로 직접 스트리밍할 수 있습니다.
가속화된 패킷 처리: OpenOnload 및 DPDK를 지원하므로 애플리케이션 코드 변경을 최소화하면서 Linux 사용자 공간 네트워킹을 통해 예측 가능한 유니캐스트 및 멀티캐스트 패킷 처리를 구현할 수 있습니다.
정밀한 타이밍 및 UTC 동기화: Google Cloud의 Firefly 클록 동기화 시스템을 통합하여 네트워크 수준에서 10나노초 미만의 정밀도로 타임스탬프를 일관되게 기록하고 금융 거래소의 규제 요건인 100마이크로초 미만보다 뛰어난 UTC 동기화 정확도를 제공합니다.
기본 제공 원격 분석: 연중무휴로 이루어지는 저지연 패킷 캡처와 원활한 아웃오브밴드 패킷 브로커링을 통해 규정 준수와 실시간 분석을 지원합니다. 이로써 주요 트래픽 성능에 영향을 주지 않으면서 네트워크 상태를 상세하게 파악할 수 있습니다.
연중무휴 시장 지원: 실시간 트레이딩을 위한 프로덕션 워크로드는 전용 기본 영역에 격리하고, 일상적인 클라우드 유지보수와 적격성 테스트는 업데이트 및 테스트를 위한 보조 영역에서 수행하도록 설계되었습니다. 이를 통해 24시간 중단 없는 트레이딩 준비 상태를 유지할 수 있습니다.

ULL Solution의 컴퓨팅은 새로운 U4 머신 계열을 통해 제공되며 이 계열은 예측 가능한 성능과 초저지연 컴퓨팅을 제공하는 세 가지 특화 머신 시리즈로 구성됩니다. U4P와 U4C는 각각 거래소 운영자와 시장 참여자를 위한 듀얼 소켓 베어메탈 인스턴스로, 모두 3개의 물리적 NIC가 장착되어 있습니다. U4S는 운영자, 시장 참여자, 서비스 제공업체를 위한 고성능 VM입니다.

머신 시리즈	CPU 플랫폼	CPU 코어	메모리	NIC	스토리지 옵션
U4P (베어메탈)	Intel 5세대 Xeon(Emerald Rapids)	물리적 코어 120개	512GB 또는 768GB	물리적 NIC 3개(표준 1개 + ULL 2개)	로컬 티타늄 SSD(12TiB), Hyperdisk
U4C (베어메탈)	Intel 5세대 Xeon(Emerald Rapids)	물리적 코어 120개	512GB 또는 768GB	물리적 NIC 3개(표준 1개 + ULL 2개)	로컬 티타늄 SSD(12TiB), Hyperdisk
U4S (VM)	Intel 6세대 Xeon(Granite Rapids)	vCPU 2~288개	최대 2,232GB	멀티 vNIC(최대 200Gbps)	로컬 티타늄 SSD(18TiB), Hyperdisk

Google Cloud는 전 세계에서 기술적 요구사항이 가장 까다로운 금융 시장에서도 클라우드 서비스와 확장성의 이점을 활용하며 운영할 수 있도록 U4 머신 계열을 개발했습니다. 대표적인 사례로 CME Group과의 지속적인 협업을 통해 상장된 파생상품 시장을 Google Cloud로 이전하고 있습니다. 여기서 U4C 및 U4P 베어메탈 인스턴스는 물리적 코로케이션과 동등한 수준의 지연 시간을 보장하며, 예측 가능한 저지연 클록 정밀도와 하드웨어 기반 멀티캐스트 피드의 네이티브 수집 기능을 제공합니다. 이 아키텍처는 금융 시장에서 요구하는 속도, 일관성, 제어 수준을 유지하면서 핵심 거래소 시스템과 트레이딩 전략을 클라우드에서 실행할 수 있음을 보여줍니다.

"세계 최고의 파생상품 시장을 클라우드로 이전하려면 성능, 지연 시간, 안정성 측면에서 결코 타협이 용납되지 않습니다. Google Cloud의 Ultra Low Latency Solution과 U4 인스턴스 계열은 금융 시장 인프라의 획기적인 발전을 의미합니다. 결정론적인 초저지연 네트워킹 및 전용 베어메탈 컴퓨팅에 클라우드의 이점을 결합함으로써 시장 참여자는 기존 코로케이션 환경의 속도와 클라우드의 민첩성을 동시에 활용하여 시장 데이터를 수집하고 거래를 체결할 수 있습니다." - Pearce Peck-Walden, CME Group의 시장 엔지니어링 부문 상무이사

Google Cloud 네이티브 인프라 기반

ULL Solution은 일부 비공개 Google Cloud 리전에서 제공되며, 트레이딩팀은 이러한 환경에서 신속한 자동 리소스 프로비저닝, 주문형 용량 확장, 동적 Fleet 관리와 같은 핵심 클라우드 인프라의 이점을 활용할 수 있습니다. 또한 격리된 전용 ULL 네트워크에서 초저지연 거래를 실행하고, 독립적인 네트워크 인터페이스를 통해 데이터 스트림을 BigQuery, Gemini Enterprise와 같은 Google Cloud 서비스로 오프로드할 수 있습니다.

틱 투 트레이드(tick-to-trade) 워크플로를 관리하거나 실시간 시장 데이터를 처리하는 거래소 참여자에게는 마이크로초 단위의 차이도 매우 중요합니다. U4P 및 U4C 머신 시리즈는 베어메탈 인스턴스이므로 지연 시간에 민감한 실행 계층에 가상화 오버헤드가 추가되지 않습니다. 이러한 베어메탈 인스턴스는 Google Cloud의 Titanium 오프로드 시스템 아키텍처를 활용하여 호스트 리소스에 직접 액세스할 수 있도록 합니다. 사용자는 Compute Engine 인스턴스를 통해 표준 Google Cloud API로 전용 하드웨어를 프로비저닝하고, 코드형 인프라를 사용하여 배포를 조정하고, Cloud Next Generation Firewall(NGFW) 정책을 적용하고, 다양한 원격 분석 데이터를 수집할 수 있습니다.

U4S VM 시리즈는 거래 전 위험 검증, 실시간 분석과 같은 용도로 활용되어 이러한 베어메탈 제품군을 보완합니다. U4P 및 U4C 인스턴스와 함께 이러한 VM을 배포하면 트레이딩 아키텍처 전반에서 데이터가 거치는 네트워크 홉 수를 줄이는 동시에 vCPU를 2개에서 288개까지 탄력적으로 확장하고 최대 100Gbps의 네트워킹을 지원할 수 있습니다.

“U4 인스턴스를 테스트한 결과 Google Cloud가 까다로운 거래소 트레이딩 워크로드에 필요한 짧은 지연 시간과 결정성을 제공한다는 사실을 확인했습니다. 베어메탈과 VM 옵션을 모두 사용하면 가성비를 평가할 수 있어 각 트레이딩 전략에 적합한 인프라를 선택할 수 있습니다.” - Corbin Kidd, Prime Trading의 EVP/CTO

"틱 투 트레이드 성능 테스트에서 U4C 베어메탈 인스턴스는 뛰어난 속도를 보여주었으며, 클라우드 컴퓨팅과 초저지연 네트워킹이 마이크로초 단위의 트레이딩 요구사항을 충분히 충족할 수 있음을 입증했습니다. 하지만 U4 시리즈를 차별화하는 요소는 단순한 처리 속도가 아니라 구조적 결정성입니다. Google Cloud의 U4 베어메탈 제품군에 대한 스트레스 테스트를 실시했을 때 성능 곡선이 거의 평탄하게 유지되었으며, 이는 이러한 클라우드 컴퓨팅 레이아웃이 이제 기관 시장 참여자가 요구하는 엄격한 결정성을 제공할 수 있음을 보여줍니다." - Christopher Wilson, 28Stone의 경험 현대화 부문 글로벌 책임자

향후 이러한 초저지연 아키텍처는 알고리즘 트레이딩의 기반이 되어 기업이 AI 기반 트레이딩 모델에 실시간 시장 데이터를 직접 공급할 수 있도록 지원할 것입니다.

트레이딩 워크로드를 위한 스토리지 및 배치

U4 제품군은 Google Cloud 스토리지 옵션과 배치 정책을 지원하여 트레이딩팀이 거래 내역을 빠르게 기록하고 머신 간 네트워크 지연 시간을 최소화할 수 있도록 돕습니다.

빠른 로깅을 위한 로컬 티타늄 SSD: 실행 속도 저하 없이 실시간 거래 로깅과 데이터 캐싱을 지원하도록 U4P와 U4C는 최대 12TiB의 직접 연결된 NVMe SSD를 제공하며, U4S VM은 최대 18TiB까지 수직 확장할 수 있습니다.
데이터 보관을 위한 Hyperdisk: 과거 시장 데이터, 백테스팅 모델, 규제 제출용 보관 파일을 처리할 수 있도록 모든 U4 시리즈에 Hyperdisk Balanced 및 Hyperdisk Extreme 볼륨을 연결하여 인스턴스당 최대 32개의 볼륨과 512TiB까지 확장할 수 있습니다.
배치 정책: 압축 배치 정책은 물리적 네트워크 홉을 줄이기 위해 데이터 센터에서 관련 머신을 서로 가깝게 배치합니다. 또는 분산 배치 정책은 복원력을 개선하기 위해 별도의 랙에 머신을 배치합니다.

ULL Solution 시작하기

금융 거래소 운영자, 거래소 참여자, 트레이딩 서비스 제공업체는 ULL Solution을 통해 오늘날 요구되는 속도와 안정성을 확보하는 동시에 지속적으로 발전하는 AI 및 인프라 기능을 활용해 미래의 트레이딩 환경에 대비할 수 있습니다. ULL Solution은 일부 Google Cloud 리전에서 지원됩니다. 자세한 내용은 공개 문서를 확인하고 Google팀에 연락하여 액세스를 요청하세요.

9월 AI 인프라 및 조정 기능에 관한 새로운 소식

Tue, 13 Oct 2026 11:00:00 +0000

9월은 확장성의 달입니다. 전 세계가 에이전트형 Fleet의 급증에 대비하고 있는 가운데, Google Cloud는 이러한 수요에 원활하고 신속하게 대응하기 위해 AI 인프라 및 조정 제품을 강화하는 동시에 워크로드 격리와 보안을 유지하고 비용을 관리하고 있습니다. 이러한 개선사항이 Google Cloud의 컴퓨팅, 네트워크, 스토리지, 조정 제품 전반에 어떻게 반영되는지, 고객이 Google Cloud AI 인프라를 사용하는 새로운 방법, Google 전략에 대한 서드 파티 업계 검증에 대해 자세히 알아보세요.

제품, 기술, 도구 업데이트

Google Kubernetes Engine 업데이트: GKE팀은 플랫폼의 확장성을 개선하는 데 주력하고 있으며, 9월에는 다양한 형태와 규모의 개선사항이 적용되었습니다.

새로운 기능: 에이전트 워크로드에 더 높은 밀도의 실행 런타임이 필요하신가요? Google Cloud는 표준 컨테이너 런타임보다 10배 더 높은 밀도로 수백만 개의 샌드박스를 실행할 수 있도록 새로운 오픈소스 GKE Agent Substrate를 설계했습니다. 또한 Agent Substrate는 네이티브 제로 트러스트 커널 및 네트워크 격리 기능을 바탕으로 초당 500회 이상의 일시중지/재개 활성화 요청 처리 시에도 500ms 미만의 재개 성능을 제공합니다.
제품 업데이트: 이제 GKE에 Scale-to-zero 기능이 기본 제공됩니다. 자동 확장 측정항목이 포함된 HPA와 KEP-2021 지원 덕분에 워크로드를 축소하는 데 복잡한 구성요소를 구성할 필요가 없습니다. 블로그를 읽고 자세히 알아보세요.
제품 업데이트: 또한 GKE HPA(위에서 언급한 자동 확장 측정항목 사용)를 사용하면 이제 표준 측정항목 외에도 커스텀 PromQL 측정항목을 기반으로 확장 및 축소할 수 있으므로 비즈니스에 의미 있고 고유한 조건에 따라 워크로드를 트리거할 수 있습니다. 여기에서 자세히 알아보세요.
새로운 기능: 또 다른 확장성 기능은 GKE 포드 스냅샷으로, 이를 통해 CPU 및 GPU 메모리를 포함한 워크로드의 실행 상태를 저장하고 필요에 따라 복원할 수 있습니다. 내부 테스트에 따르면 GKE 포드 스냅샷 사용 시 AI 추론 시작 시간을 최대 89% 단축할 수 있습니다. 여기에서 자세히 알아보세요.
새로운 마이그레이션 도구: 마지막으로, AWS EKS에서 GKE로 컨테이너 워크로드를 마이그레이션하고 싶었지만 까다롭고 번거로운 엔지니어링 작업이 두려웠다면, Google Cloud가 최근 출시한 GKE 에이전트형 마이그레이션을 사용해 보세요. 이 도구는 불안정하고 임시적인 프롬프팅을 결정론적 가드레일로 보호되는 AI 지원 마이그레이션 파이프라인으로 대체하는 전용 에이전트 플러그인입니다. 에이전트 스킬과 로컬 모델 컨텍스트 프로토콜(MCP) 서버의 컴파일로 설계된 이 도구는 AI를 사용하여 복잡한 AWS EKS IaC 및 Kubernetes 매니페스트를 GKE 시작 영역으로 직접 변환합니다. 온보딩 가이드를 참고하여 시작하세요.
기능 업데이트: 강화 학습(RL) 및 평가 워크로드는 매우 까다롭습니다. 표준 에이전트형 RL 루프에서 LLM 정책은 GPU에서 코드 스니펫과 같은 작업을 생성하고 이를 격리된 CPU 샌드박스 내에서 실행하여 보상 신호를 관찰합니다. 그러나 수만 개의 동시 배포를 지원하도록 이 루프를 확장하면 유휴 상태의 가속기, 이미지 카디널리티, 포화 상태의 컨트롤 플레인과 같은 인프라 병목 현상이 발생합니다. 이를 위해 RL에 최적화된 GKE Agent Sandbox와 Agent Sandbox RL 조정 SDK, 인기 있는 RL Gym 및 하네스를 위한 기본 통합을 개발했습니다. 모두 정식 버전으로 제공되고 있으며 자세한 내용은 여기에서 확인할 수 있습니다.

스토리지 업데이트: AI는 많은 데이터를 학습하고 생성하며, 이러한 데이터는 블록 스토리지 시스템, 파일 시스템, 객체 스토어, 데이터베이스 등 어딘가에 저장되어야 합니다. Google Cloud는 이 중요한 레이어가 에이전트형 워크로드의 요구사항을 충족할 수 있도록 스토리지 포트폴리오의 개선사항을 발표했습니다.

제품 업데이트: Filestore 에이전트 볼륨은 에이전트형 워크로드를 위한 고성능의 탄력적인 영구 파일 스토리지를 제공합니다. GKE Agent Substrate 및 GKE 에이전트 샌드박스와의 긴밀한 통합 덕분에 Filestore 에이전트 볼륨은 전용 격리 파일 작업공간을 GKE 에이전트 샌드박스에 밀리초 단위로 자동 할당하고 연결합니다. 여기에서 프리뷰 액세스를 요청하세요.
새로운 제품: 생성형 AI 및 RAG 데이터 레이어(예: Milvus, Pinecone, Qdrant, Vespa, Redis, 인메모리 컨텍스트 캐싱)를 실행하는 경우, 주요 하이퍼스케일러 중 코어당 가장 높은 IOPS와 처리량을 제공하는 M4N VM 제품군(현재 정식 버전 출시됨)을 살펴보세요. Google Cloud의 커스텀 Titanium 오프로드 아키텍처 및 Hyperdisk Extreme과 결합된 M4N 인스턴스는 최대 25,000MiB/s(25GiB/s)의 집계 호스트 스토리지 성능과 최대 100만 IOPS를 제공합니다.
새로운 제품: 또 다른 새로운 Compute Engine 제품인 Z4D가 정식 버전으로 출시되었으며, 이는 AI/ML 학습 및 추론 워크로드를 위한 강력한 스토리지 솔루션입니다. 베어메탈 인스턴스로 구성된 Z4D는 에이전트형 마이크로 VM에 필요한 높은 로컬 SSD(LSSD) 용량과 짧은 지연 시간을 모두 제공하므로 호스트당 수천 개의 격리된 샌드박스를 기본 성능과 효율성으로 실행할 수 있습니다. 여기에서 Z4D 머신에 대해 자세히 알아보세요.
제품 업데이트: 오늘날의 AI 학습 및 추론 파이프라인은 대부분의 스토리지 관리 시스템이 대응할 수 있는 속도보다 더 빠르게 데이터를 생성하므로 스토리지 자산을 파악하려는 팀에 어려움을 초래합니다. 새로운 버전의 Storage Intelligence Advisor를 사용하면 '버킷에 무엇이 들어 있는지'에 대한 질문에 더 쉽게 답하고 예상치 못한 변경사항을 빠르게 식별할 수 있습니다. 또한 향상된 일괄 작업을 통해 버킷 전반에서 대량 변경사항을 자동화할 수 있습니다. 예를 들어 스토리지 클래스를 이동하거나, 오래되었거나 임시 데이터를 일괄 삭제하거나, 메타데이터, 태그 지정, 보관, 암호화 변경사항을 적용할 수 있습니다. 여기에서 Storage Intelligence Advisor의 최신 소식을 알아보세요.
새로운 제품: 마지막으로, 새로운 버전의 PostgreSQL용 AlloyDB는 선구적인 Google 인프라인 Colossus 분산 파일 시스템과 Jupiter 네트워크를 결합하여 에이전트 시대를 위한 타협 없는 새로운 데이터베이스 아키텍처를 지원합니다.

실무자 가이드 및 방법

방법: 전 세계에 흩어져 있는 GPU와 TPU를 단일 진입점 뒤에서 단일 풀로 작동하게 하고 싶으신가요? 이 블로그에서 그 방법을 알려드립니다. 에지에서는 멀티 클러스터 GKE Inference Gateway가 전역, 멀티 리전 트래픽 분산 및 고가용성에 중점을 둡니다. 그 아래에서는 LLM-d 라우터가 사용률을 높게 유지하는 복잡한 메모리 인식 예약 알고리즘을 처리합니다. 이 아키텍처는 의도적으로 런타임, 모델, 가속기와 무관하게 설계되었으며, 테스트에서는 멀티 클러스터 GKE Inference Gateway를 통해 트래픽을 라우팅할 때 추가된 오버헤드가 1% 미만이었습니다.
가이드: AI 모델 학습 또는 추론을 위해 TPU에서 GKE를 사용 중이거나 사용할 계획이신가요? 대규모 언어 모델(LLM)을 학습시키거나 높은 처리량의 추론 서빙을 실행하려면 Cloud TPU 및 GPU와 같은 특화된 AI 하드웨어에 상당한 투자가 필요합니다. 지출 비용을 최대한 활용하려면 GKE의 워크로드 수명 주기 측정항목을 이해해야 합니다. 이 상세 가이드에서는 불투명한 클러스터 동작을 활용 가능한 원격 분석으로 전환하는 방법을 설명합니다.

고객 및 파트너 업데이트

GKE 고객: 게임 스타트업 SeaVerse가 멀티 테넌트 워크로드에 GKE 에이전트 샌드박스를 사용하는 이유와 이 플랫폼을 통해 인프라 비용을 60% 절감한 방법을 알아보세요.

연구, 보고서, 심층 분석

혹시 놓치셨을까 봐 알려드리자면, Google은 Gartner와 Forrester의 주요 분석 보고서 3개에서 제품 또는 전략 부문 최고 점수를 획득하는 등 리더로 선정되었습니다.

Google, The Forrester Wave™: 2026년 3분기 퍼블릭 클라우드 플랫폼 부문 리더로 선정: 모든 클라우드 제공업체 중 가장 높은 종합 점수 획득
Google, 2026년 Gartner® Magic Quadrant™의 전략적 클라우드 플랫폼 서비스 부문에서 리더로 선정: 평가 대상 공급업체 중 '비전의 완전성' 부문에서 가장 선도적인 업체로 선정되었습니다.
Google, 2026년 Gartner Magic Quadrant의 컨테이너 관리 부문에서 리더로 선정: 평가 대상 공급업체 중 '실행 능력' 면에서 가장 높은 순위를 차지했습니다.
Google Cloud는 전 세계 GPU 제공업체의 안정성, 성능, 지원, 가격, 보안을 평가하는 최신 SemiAnalysis ClusterMax 3.0 보고서에서 골드 등급을 받았습니다. 자세한 내용은 보고서 전문을 참고하세요.

2026년 8월

제품, 기술, 도구 업데이트

제품 변경사항: Google Cloud의 퍼스트 파티 보안 확장형 NFS 파일 서비스인 Filestore는 AI 및 에이전트 워크플로를 위한 인기 스토리지 플랫폼으로 부상했으며, 이제 Google의 기본 분산 스토리지 시스템인 Colossus를 기반으로 직접 빌드된 새로운 백엔드 스토리지 계층을 통해 이 작업에 더욱 최적화된 성능을 제공합니다. 이 새로운 백엔드를 사용하면 스토리지 용량과 독립적으로 IOPS를 프로비저닝할 수 있으며 GKE와 긴밀하게 통합됩니다. AI 환경에서는 공통 데이터 세트를 읽고 써야 하는 대규모 에이전트 그룹인 이른바 에이전트형 스웜을 성능 저하 없이 서비스하는 데 도움이 될 수 있습니다. 자세한 내용은 블로그 게시물을 참고하세요.
새로운 기능: 이제 GKE의 분산 Ray 클러스터에서 gVisor 샌드박스를 사용할 수 있습니다. Google은 Anyscale과의 파트너십을 통해 Google의 오픈소스 애플리케이션 커널인 gVisor를 분산 Ray 클러스터에 직접 통합할 수 있는 Ray용 실험용 라이브러리를 선보였습니다. gVisor는 일반 컨테이너보다 강력한 격리 기능을 제공하면서도, 가벼운 환경 덕분에 빠른 시작 시간과 낮은 메모리 오버헤드라는 장점까지 모두 갖추고 있습니다. GKE에서 이러한 샌드박싱 기능을 사용해 보려면 Ray 샌드박싱 사용자 가이드를 참고하세요.
제품 변경사항: 개인용 AI 에이전트를 실행할 고성능의 사용하기 쉬운 인프라를 찾고 계신가요? 하지만 비용 부담은 줄이고 싶으시다면 주목해 주세요. 새로운 Cloud Run 인스턴스는 Cloud Run의 전용 싱글톤 컴퓨팅 런타임으로, 에이전트가 유휴 상태일 때도 종료되지 않습니다. 더욱 놀라운 점은 1개의 vCPU와 1GiB 메모리 사양의 Cloud Run 인스턴스를 30일 내내 중단 없이 실행해도 비용이 단돈 $5.70에 불과하다는 것입니다.

실무자 가이드, 문서, 방법

안내 가이드: 모델 컨텍스트 프로토콜(MCP) 분야의 중요한 소식입니다. 2026년 7월 28일 사양을 기준으로 프로토콜 코어는 '완전히 스테이트리스(Stateless)입니다. 핸드셰이크는 이제 필요 없습니다. 초기화 / 초기화 완료 핸드셰이크(SEP-2575)와 논리적 Mcp-Session-Id 헤더(SEP-2567)가 완전히 사라졌습니다. 대신 이제 모든 요청이 자체 설명적이고 독립적으로 이루어집니다.' 정말 놀랍지 않은가요? Google Developers 블로그에서 최신 MCP 사양의 변경사항과 구현 방법을 자세히 알아보세요.
가이드: 실시간 AI 시스템은 기존 네트워크 부하 분산 기법을 무력화합니다. '백엔드는 고립된 요청을 처리하는 대신 지속적으로 실시간 양방향 스트림을 관리해야 합니다. 오디오 청크, 스크립트, 모델 출력, 합성 음성이 동시에 끊임없이 오가기 때문입니다.' 사용자가 개입하면 상황은 더 복잡해집니다. '서버는 현재 진행 중인 음성 생성을 즉시 중단하고, 컨텍스트를 업데이트하도록 전환하고, 새로운 도구를 트리거하고, 다른 대답을 작성하기 시작해야 합니다. 이 모든 작업은 연결을 끊지 않고 수행되어야 합니다.' AI 시대에 부하를 관리하는 새로운 접근 방식에 대해 알아보려면 세션 인식 부하 분산으로 실시간 AI 에이전트 확장하기를 읽어보세요.
방법: 다양한 GPU 가속기를 혼합하여 사용하더라도 GKE에서 탄력적이고 확장 가능한 LLM 추론 플랫폼을 빌드하는 방법을 알아봅니다. 제안된 아키텍처는 Capacity Advisor와 Compute Advisor 외에도 RunAI:model streamer나 병렬 다운로드를 지원하는 GCPFuse와 같은 고성능 스토리지를 결합합니다. 자세한 내용은 여기에서 확인하세요.
문서: GPU 또는 TPU가 있는 호스트의 경우 라이브 마이그레이션을 사용하여 업데이트할 수 없으므로 유지보수 문제가 발생합니다. 이 새로운 문서 페이지에서 학습 및 추론 워크로드의 다운타임 허용 범위에 따라 가속기가 장착된 호스트를 업데이트하는 방법을 알아보세요.
문서: Advanced Compute Images(ACI)는 AI/ML 및 HPC 인프라를 위한 표준화된 이미지 스택이므로 커스텀 이미지를 수동으로 빌드할 필요가 없습니다. 이 새로운 문서 페이지에서 Google Cloud CLI, 콘솔 또는 SchedMD의 Slurm 워크로드 관리자를 사용하여 ACI 이미지를 만드는 방법을 알아보세요.
가이드: AI 워크로드는 설계하기가 어렵고, 리소스 집약적이며, 버스트가 발생하기 쉬운 것으로 알려져 있습니다. 이로 인해 확장 병목 현상이 발생하고 활용도가 낮거나 잘못 활용되는 컴퓨팅 리소스가 대량으로 발생할 수 있습니다. 새로운 블로그에서는 Google Cloud에서 동적 용량 관리를 달성하는 세 가지 주요 방법을 간략하게 설명합니다. 1) 계획된 다운타임에 대한 용량 예약, 2) 계획되지 않은 다운타임에 대한 자동화된 대체 용량 유지, 3) GKE의 핵심 조정 기능을 활용한 리소스 할당 자동화입니다.

고객 및 파트너 업데이트

비즈니스 조정 소프트웨어 제공업체인 UiPath는 급증하는 워크로드를 처리하고 있었으며, 비용을 더 예측 가능하게 만들고 싶었습니다. 이를 위해 인프라를 재설계하여 고립된 클러스터에서 공유 Google Cloud GPU Fleet으로 전환했습니다. 여기에는 학습을 위한 A3 VM 인스턴스(NVIDIA H100 GPU)와 추론을 위한 G4 VM 인스턴스(NVIDIA RTX PRO 6000 Blackwell 서버 에디션 GPU)가 모두 포함되었습니다. 아키텍처에 대한 자세한 내용은 여기에서 확인할 수 있습니다.
AI 개발 가속화에 주력하는 첨단 AI 연구소인 Mirendil은 모델 사전 학습 및 사후 학습 애플리케이션을 지원하기 위해 TPU와 NVIDIA GPU를 모두 갖춘 AI 하이퍼컴퓨터를 사용하고 있다고 발표했습니다.
소매 CRM 제공업체인 Replenit은 BigQuery, Gemini Enterprise Agent Platform, Cloud TPU에서 실행되는 오픈소스 Gemma 모델을 사용하여 Google Cloud에서 AI 의사 결정 엔진을 빌드했습니다. Replenit의 발표에 따르면, 이 조합을 통해 이전 클라우드 제공업체 대비 파이프라인 비용을 90%나 절감할 수 있었습니다. 자세한 내용은 우수사례 전문을 읽어보세요.
Malachyte는 Bigtable, Managed Service for Apache Kafka, Pub/Sub, Compute Engine, GKE를 기반으로 AI 기반 이커머스 추천 플랫폼을 설계했습니다. 이 블로그에서 이 모든 것이 어떻게 결합되는지 확인해 보세요.

2026년 7월

제품, 기술, 도구 업데이트

제품 변경사항: Google Cloud Managed Lustre가 정식 버전(GA)으로 출시되었습니다. 이제 용량 TiB당 125MB/s부터 250MB/s, 500MB/s, 최대 1,000MB/s까지 네 가지 성능 등급의 처리량을 선택할 수 있으며, 스토리지 용량을 최대 8PB까지 확장할 수 있습니다. Managed Lustre 솔루션은 DDN의 EXAScaler를 기반으로 하며, 고성능 스토리지 분야에서 수십 년간 쌓아온 DDN의 리더십과 Google Cloud의 클라우드 인프라 전문성이 결합된 결과물입니다.
제품 변경사항: C4N 네트워크 및 스토리지 최적화 VM 정식 버전 출시. C4N은 데이터 전송 병목 현상을 제거하기 위해 빌드된 Google Cloud 최초의 네트워크 및 블록 스토리지 최적화 VM 시리즈입니다. 5세대 Intel Xeon 확장 가능 프로세서로 구동되고 Google의 Titanium 오프로딩 하드웨어를 기반으로 빌드된 이 제품은 Hyperdisk Extreme과 함께 사용할 때 400Gbps의 네트워크 대역폭, 초당 9,500만 패킷(MPPS), 최대 25GiB/s의 블록 스토리지 처리량을 구현합니다.
새로운 기능: 네트워크 정책이 적용된 최대 15,000개 노드 규모의 GKE Dataplane V2(GA). 이 기능을 사용하면 표준 GKE 클러스터를 최대 15,000개 노드까지 확장하면서도 전체 활성 네트워크 정책 적용을 유지할 수 있어 대기업 및 AI/ML 고객의 대규모 인프라 요구사항을 지원할 수 있습니다.
새로운 기능: llm-d의 협력적 타임 슬라이싱. 강화 학습(RL) 워크로드를 실행하는 경우, 이제 독립적인 RL 작업을 공유 물리적 하드웨어에 인터리브 처리할 수 있어 모델 수렴이나 정확도에 영향을 주지 않으면서 가속기의 총 가동 주기를 기준치인 약 40%에서 최대 70%까지 늘릴 수 있습니다.
새로운 AI 보안 도구: GKE에서 AI 공급망을 보호하고, AI 워크로드를 안전하게 배포하고, 섀도 AI를 줄이고 싶으신가요? Google은 컨테이너 클러스터를 지속적으로 모니터링하여 실행 중인 AI 런타임(예: vLLM 및 Triton)을 자동으로 감지하고 표준 CycloneDX 머신러닝 자재 명세서(ML-BOM)를 생성하는 가볍고 권한이 없는 Kubernetes 컨트롤러인 k8s-aibom을 오픈소스로 공개했습니다. k8s-aibom 프로젝트를 확인하고 참여해 보세요.

실무자 가이드 및 방법

안내 가이드: 7월 27일, Google은 2.8조 파라미터를 가진 개방형 가중치 모델인 Moonshot AI의 Kimi K3에 대해 가중치가 공개된 당일부터 즉각적인 지원을 시작한다고 발표했습니다. Model Garden, 커스텀 조정, llm-d 레시피가 포함된 GKE 등 선호하는 배포 경로에 관계없이 이 가이드에서는 Google Cloud에서 Kimi K3를 평가하고 파일럿하는 데 도움이 되는 자세한 단계별 안내를 제공합니다.
안내 가이드: Google Kubernetes Engine(GKE) 관리형 DRANET은 GPU와 TPU를 모두 지원합니다. 이 구현을 활용하는 방법은 여러 가지가 있습니다. 사용자가 모든 권한을 갖는 표준 클러스터 방식과 Google이 복잡한 설정을 대신 처리해 주는 Autopilot 클러스터 방식 중에서 선택할 수 있습니다. 실무형 실습인 TPU, GKE 관리형 DRANET, Gemma 4를 사용하는 GKE Autopilot 클러스터에서 자세히 알아보세요.
안내 가이드: GPU가 아닌 TPU에서 Ray를 실행하는 방법을 알아봅니다. 이 2부작 시리즈의 1부에서는 TPU 슬라이스에 대해 설명하고(힌트: Ray는 이를 일정 예약이 가능한 또 다른 가속기로 간주함), Ray의 다양한 AI 라이브러리를 살펴봅니다 (2부).
안내 가이드: 기기가 이론적인 성능 사양을 달성하는지 정확하게 평가하고 특정 성능 격차 또는 아키텍처별 병목 현상을 식별하는 데 도움이 되는 새로운 마이크로벤치마크 제품군을 사용하여 샘플 워크로드에 대한 TPU를 평가합니다. 여기에서 자세히 알아보세요.
안내 가이드: 예산에 부담을 주지 않고 에이전트를 확장하세요. GKE 에이전트 샌드박스와 포드 스냅샷을 통해 GKE 조정을 사용하여 고정된 컴퓨팅 공간에 더 많은 에이전트를 안전하게 패킹하는 방법을 알아보세요. 성능 최적화와 비용 최적화 중 무엇을 목표로 하든, 에이전트 효율성을 극대화하기 위해 어떤 설정을 어떻게 조정해야 하는지 알려드립니다.
기술적 청사진: Ironwood 기반 Mistral 3 Large 추론 최적화 자세히 알아보기. 이 블로그에서는 Google의 한 팀이 Google Ironwood(TPU v7x)에서 Mistral 3 대규모 MoE 모델의 추론을 최적화하여, 1.5배의 성능 향상을 이끌어낸 과정을 개략적으로 소개합니다. 이 팀은 하이브리드 샤딩을 적용하고, 선형 VPU 합산을 트리 축소 방식으로 대체했으며, GMM/MLA 커널 최적화와 비동기 스케줄링 도입을 통해 이를 실현했습니다. 그 결과, 벤치마크 정확도에는 영향을 주지 않으면서도 처리량을 최대 48%까지 끌어올리는 성과를 거두었습니다. 블로그 전체 내용은 여기에서 확인하세요.

연구, 보고서, 심층 분석

보고서: Google은 최초로 발표된 GartnerⓇ Magic Quadrant™ AI 인프라 부문에서 리더로 선정되었으며, '실행 능력'에서 가장 높은 평가를 받고 '비전의 완전성'에서 가장 앞선 위치를 차지했습니다. Gartner는 Google의 독점적인 확장형 컴퓨팅, 통합 AI 하이퍼컴퓨터 아키텍처, AI 컴퓨팅 용량의 규모를 주요 강점으로 꼽았습니다. 여기에서 사본을 다운로드하세요.
보고서: Google Cloud는 최근 1,400명 이상의 수석 IT 리더를 대상으로 AI 인프라 현황 보고서를 위한 설문조사를 실시했으며, 그 결과 AI 활용 포부와 인프라 현실 간의 격차가 점점 더 벌어지고 있다는 분명한 패턴이 나타났습니다. 실제로 조직의 83%는 프로덕션급 에이전트 AI를 지원하려면 인프라를 업그레이드해야 한다고 답했습니다. 함께 제공되는 블로그를 읽고 에이전트형 애플리케이션이 시스템에 요구하는 사항을 충족하도록 인프라를 조정하면 파일럿 단계에서 프로덕션으로 전환하는 데 어떤 도움이 되는지 알아보세요.

2026년 6월

제품, 기술, 도구 업데이트

제품 변경사항: AI에 사용되는 민감한 정보를 보호하는 것은 안전한 고급 클라우드 인프라의 핵심입니다. 컨피덴셜 컴퓨팅은 하드웨어 기반의 신뢰할 수 있는 실행 환경(TEE) 내에서 사용 중인 데이터를 암호화하여 보호하고 검증 가능한 데이터 무결성을 제공합니다. 이 기능은 이제 NVIDIA RTX PRO 6000 Blackwell 서버 에디션 GPU가 탑재된 가속기 최적화 G4 머신 시리즈에서 이용 가능합니다. 컨피덴셜 G4 VM 및 컨피덴셜 G4 GKE 노드를 지금 바로 이용해 보세요.
개발자 리소스: 새로운 TPU 개발자 허브는 모델 빌더, 최적화 전문가, 개발자가 Google Cloud TPU의 성능을 최대한 활용하는 방법을 배울 수 있는 공간입니다. 자세한 내용은 이 블로그를 참고하세요.
새로운 제품: 새로운 OpenTelemetry 기반 TPU AI 원격 분석 수집기 에이전트를 사용하여 AI 워크로드를 확장하세요. 이제 사상 처음으로 정밀한 TPU 하드웨어 원격 분석 데이터를 Google Cloud Monitoring, Google Managed Prometheus 또는 자체 호스팅 Grafana 스택으로 바로 전송할 수 있습니다.

실무자 가이드 및 방법

안내 가이드: TPU, Cloud Storage FUSE, 동적 리소스 할당(DRA)을 사용하여 GKE Inference Gateway에서 실행되는 AI 추론 워크로드에 고가용성을 빌드하는 방법을 알아봅니다. 이 블로그에서 전반적인 내용을 살펴보거나, 실습 Codelab을 통해 모든 기술적 세부정보를 직접 익혀볼 수 있습니다.
안내 가이드: 모델 컨텍스트 프로토콜(MCP)을 통해 AI 에이전트를 Cloud Storage의 비정형 데이터에 연결할 수 있다는 사실을 알고 계셨나요? 이 블로그에서는 세 가지 고객 사례를 통해 왜 이러한 연결이 필요한지 살펴보고, 완전 관리형 서비스나 제어 및 맞춤설정의 폭이 넓은 자체 관리형 로컬 서버 중 나에게 맞는 방식을 선택해 구현하는 방법을 알아봅니다.

연구, 보고서, 심층 분석

보고서: 독립적인 벤치마크 보고서에 따르면, GKE Inference Gateway는 업계 선두의 다른 관리형 Kubernetes 서비스와 비교해 처리량은 15.7% 더 높고, 대기 시간은 92.8% 더 짧으며, 토큰 간 지연 시간은 62.6% 더 낮은 압도적인 성능을 기록했습니다. 이러한 압도적인 성능은 프리픽스 캐싱 기술 덕분입니다. 이 기술은 길고 반복되는 프롬프트 프리픽스의 KV 캐시(활성화 상태)를 저장함으로써 LLM 성능을 획기적으로 최적화합니다. 블로그에서 자세히 알아보세요.
아키텍처 심층 분석: TPU 및 GKE의 콜드 스타트 문제를 자세히 살펴보고 Run:ai Model Streamer가 어떻게 상황을 바꿀 수 있는지 알아봅니다.

고객 및 파트너 업데이트

고객 성공사례: Pager Health는 GKE, BigQuery, Cloud SQL, Gemini Enterprise Agent Platform을 활용하여 운영 단편화를 제거하고 간소화된 맞춤형 미국 의료 경험을 제공하여 삶을 변화시키고 있습니다.
고객 성공사례: 고객 리뷰 플랫폼인 Trustpilot은 Dataflow와 Gemini Enterprise Agent Platform을 통해 파인 튜닝된 Gemma 모델을 사용하여 대용량 스트리밍 파이프라인을 구축했습니다. 이 파이프라인은 비용 최적화된 A2 VM에서 A100 GPU를 사용해 실행되며, Gemini Enterprise Agent Platform에서 유지관리하는 최적화된 버전의 vLLM도 활용합니다.

2026년 5월

제품, 기술, 도구 업데이트

제품 변경사항: 이제 GKE Agent Sandbox가 정식 버전으로 제공됩니다.
새로운 오픈소스 프로젝트: Agent Substrate는 에이전트 인프라 밀도의 한계를 뛰어넘기 위해 새롭게 공개된 오픈소스 프로젝트입니다.
새로운 기능: 온디바이스 머신러닝(ML)을 대규모로 테스트하고 벤치마킹할 수 있는 솔루션인 Google AI Edge Portal이 이제 온디바이스 LLM의 벤치마킹과 디버깅을 지원합니다. 자세한 내용은 여기를 참고하세요.
제품 심층 분석: AI 워크로드를 위한 새로운 고성능 스토리지 제품군인 Cloud Storage Rapid를 심층적으로 살펴보았습니다. 출시 시점에는 고성능 영역 객체 스토리지 제품인 Rapid Bucket(이전 명칭: Rapid Storage)과 주문형 읽기를 가속화하고 기존 버킷의 워크로드를 위해 컴퓨팅과 데이터를 함께 배치하는 Rapid Cache(이전 명칭: Anywhere Cache)가 제공됩니다.

연구, 보고서, 심층 분석

아키텍처 심층 분석: Google 글로벌 인프라 부문 부사장 비카시 콜리와 엔지니어링 연구원 아르준 싱이 AI 워크로드가 네트워크 인프라에 미치는 영향을 개괄적으로 설명하고, 이를 더 효과적으로 지원하기 위해 데이터 센터 패브릭, WAN, 글로벌 네트워크에 적용한 심층적인 개선사항을 논의합니다.
아키텍처 심층 분석: 인스턴스 수준의 안정성 방식에서 벗어나, TPU 기반 프런티어 AI 모델 개발을 위한 새로운 클러스터 수준 안정성 모델을 공개했습니다.

고객 및 파트너 업데이트

고객 성공사례: 시각 미디어 제공업체인 Imgix는 NVIDIA RTX PRO 6000 Blackwell GPU 기반 G4 VM이 탑재된 AI 하이퍼컴퓨터에서 80억 개 이상의 이미지와 동영상을 제공합니다.

데이터 무결성 및 내구성 향상을 위해 Cloud Storage 엔드 투 엔드 체크섬 사용 설정

Sun, 11 Oct 2026 10:00:00 +0000

Google Cloud는 저장 데이터와 전송 중인 데이터 모두의 내구성과 무결성을 항상 유지하는 것을 고객이 기대한다는 점을 잘 알고 있습니다. 이제 Google Cloud는 모든 Cloud Storage SDK에서 엔드 투 엔드 체크섬을 기본적으로 사용 설정하여 개발자가 Cloud Storage의 네이티브 데이터 무결성 기능을 더 쉽게 활용할 수 있도록 지원합니다.

다른 디스크 기반 스토리지 시스템과 마찬가지로 애플리케이션에서 디스크에 이르는 모든 전송 과정에서 비트 플립이 발생할 수 있습니다. Cloud Storage는 항상 클라이언트가 업로드 중인 객체 데이터의 체크섬을 제공하고 다운로드 중인 데이터의 체크섬을 수신할 수 있도록 지원해 왔습니다. 또한 Cloud Storage는 출시 초기부터 객체가 Cloud Storage에 업로드된 방식과 관계없이 메타데이터에 있는 모든 객체의 체크섬을 저장합니다.

하지만 최근까지 엔드 투 엔드 데이터 무결성을 보장하려면 개발자가 직접 체크섬을 계산하여 Cloud Storage에 제공하는 추가 작업을 수행해야 했습니다. Cloud Storage는 수신하는 데이터의 crc32(32비트 순환 중복 검사)를 항상 계산하고 디스크에 저장된 데이터가 이 체크섬과 일치하는지 확인합니다. 클라이언트 요청에 객체의 체크섬이 포함된 경우 Cloud Storage는 이 체크섬도 일치하는지 확인합니다. 그러나 업로드 요청에 체크섬이 포함되지 않은 경우, 서버 측 체크섬 계산 전 데이터가 전송되는 동안 업로드가 비트 플립 위험에 노출됩니다. 모든 고객과 클라이언트가 기본적으로 클라이언트 측 체크섬을 사용 설정하는 것은 아니므로 이 단계의 데이터는 보호되지 않은 상태로 남게 됩니다.

이러한 격차를 해소하기 위해 모든 Cloud Storage SDK의 최신 버전은 이제 업로드되는 데이터의 체크섬을 내부적으로 생성하고, 애플리케이션에서 제공하지 않는 경우 이 체크섬을 Cloud Storage에 전달합니다. 또한 SDK는 객체를 다운로드할 때 해당 객체의 체크섬 확인을 지원합니다.

마지막으로, 애플리케이션이 전체 객체가 아닌 선택한 범위의 객체를 다운로드하는 사용 사례가 많습니다. Cloud Storage SDK를 gRPC API와 함께 사용하여 범위 읽기를 수행하면 SDK는 gRPC의 기본 제공 엔드 투 엔드 범위 체크섬을 활용하여 수신하는 데이터를 확인합니다.

이러한 중요한 무결성 기능을 활용하려면 최신 SDK 버전으로 업데이트하는 것이 좋습니다.

좀 더 자세히 살펴보겠습니다

데이터와 애플리케이션에서 디스크 플래터에 이르는 관련 체크섬 간에 지속적인 '관리 연속성'을 보장하고 간극으로 인해 비트 플립을 감지하지 못하는 일이 없도록 하는 것은 매우 까다로운 일입니다. 이 문제를 올바르게 해결하는 것이 중요합니다. 수십만 개의 Cloud Storage 프런트엔드가 있는 현재 규모에서 비트 플립은 이론적인 것이 아니며 때때로 실제 발생합니다.

예를 들어 Cloud Storage가 프런트엔드에서 데이터를 수신하면 이 데이터는 객체별 암호화 키로 암호화됩니다. 여기에는 데이터 복사가 포함됩니다. 일반 텍스트 데이터는 암호화 도구를 거쳐 암호문이 포함된 새 메모리 버퍼로 전달됩니다. 이 프로세스 중에 소스 또는 대상 메모리 버퍼의 비트가 플립되는 경우는 매우 드뭅니다. 하지만 Google의 규모에서는 매우 드문 일도 일상적으로 발생합니다.

이러한 상황에서 Google Cloud는 전체 프로세스를 역순으로 진행하여 관리 연속성 체계를 유지합니다. 데이터를 암호화한 후(1) 암호문을 보호하는 체크섬을 계산합니다. 그런 다음 암호문(2)을 복호화하고, 결과로 생성된 일반 텍스트가 원본(3)과 일치하지 않으면 모든 것을 버리고 처음부터 다시 시작합니다. 이로 인해 암호화와 체크섬에 많은 CPU 시간이 추가로 소요되지만, 데이터 무결성을 보장하기 위해 필수적인 단계입니다.

또 다른 과제는 데이터가 스택의 레이어를 통과하면서 어떻게 분할되고 집계되는지입니다. 데이터가 Cloud Storage에 업로드되면 청크로 분할되며, 각 청크에는 자체 체크섬이 있습니다. Cloud Storage는 대규모 데이터를 효율적으로 관리하기 위해 수천 개의 청크를 샤드 파일이라는 스토리지 단위로 그룹화합니다. 이러한 기가바이트 크기의 파일은 Cloud Storage가 궁극적으로 클러스터 수준 스토리지 시스템인 Colossus에 데이터를 전송하는 방식입니다. 내부적으로 Colossus는 Reed Solomon 인코딩을 사용하여 데이터를 여러 디스크에 분산하고 개별 디스크, 머신, 랙의 장애로부터 보호합니다. 이를 위해서는 샤드 파일 데이터를 블록으로 분할해야 하며, 각 블록은 체크섬으로 다시 보호됩니다.

이러한 모든 변환을 거치는 동안 데이터의 관리 연속성을 유지하기 위해 연결과 같이 순환 중복 검사(CRC)의 몇 가지 유용한 속성을 활용합니다. 각각 자체 CRC가 있는 두 개의 데이터 버퍼가 있는 경우 데이터를 다시 체크섬할 필요 없이 연결된 두 버퍼의 CRC를 저렴하게 계산할 수 있습니다. 이는 청크를 샤드 파일로 연결할 때와 같은 많은 상황에서 유용합니다. Colossus는 구성 청크에서 전체 샤드 파일의 CRC를 저렴하게 확인하고 이를 메타데이터에 저장할 수 있습니다.

궁극적으로 데이터는 Google의 'D' 파일 서버(Google의 네트워크 연결 디스크)에서 관리하는 디스크에 저장됩니다. D는 Colossus 블록 내의 각 데이터 범위에 대한 인라인 체크섬을 저장합니다. 디스크에서 데이터를 읽을 때마다 여러 레이어에서 검증이 이루어집니다. Colossus 클라이언트는 읽은 데이터를 D의 인라인 체크섬과 비교하여 검증하고, Cloud Storage 프런트엔드는 데이터를 청크 단위로 읽고 각 청크를 체크섬과 비교하여 검증한 후 클라이언트에 전송합니다. 이러한 청크 수준 체크섬을 통해 gRPC 프로토콜은 SDK에서 확인할 수 있는 범위 읽기에 대한 체크섬을 제공할 수 있으며, 이 모든 과정에서 관리 연속성이 유지됩니다.

관리 연속성: 데이터 변환 과정 전반에서 데이터 무결성 유지

위 이미지는 Google Cloud Storage 내부의 여러 레이어에 걸쳐 이루어지는 데이터 무결성 핸드오프를 보여줍니다. 읽기 시 체크섬은 여러 레이어에서 인라인으로 확인되어 무음 손상을 방지합니다.

클라이언트가 전체 객체 체크섬을 Cloud Storage 프런트엔드에 전달합니다.
데이터가 청크로 분할되고 개별 청크 수준 체크섬이 계산됩니다.
샤드 수준 체크섬은 연결된 청크 수준 CRC를 기반으로 계산됩니다.
샤드는 다른 수준의 블록 수준 인라인 체크섬과 함께 디스크 블록에 저장됩니다.

Cloud Storage팀은 고객을 위해 최고 수준의 데이터 무결성을 유지하기 위해 최선을 다하고 있습니다. Google은 SDK에서 엔드 투 엔드 체크섬을 기본값으로 설정하고 내부 스토리지 스택 전반에서 관리 연속성을 유지함으로써 업로드 순간부터 최종 다운로드까지 데이터가 의도한 대로 정확하게 유지되도록 합니다. 이러한 지속적인 경계는 규모에 관계없이 데이터를 보호하겠다는 Google의 약속을 반영합니다. 이러한 보호 기능을 최대한 활용하려면 최신 버전의 SDK로 업데이트하는 것이 좋습니다.

스토리지 최적화 Z4D 머신 계열 정식 버전 출시, IO 집약적 워크로드를 위해 설계

Thu, 08 Oct 2026 02:00:00 +0000

오늘 Google Cloud는 가상 머신(VM) 및 베어메탈 인스턴스를 모두 지원하는 Google Compute Engine의 차세대 스토리지 최적화 Z4D 머신 시리즈를 정식 버전으로 출시합니다.

Z4D는 SQL, NoSQL, KVrocks, 벡터 데이터베이스, 데이터 분석, 데이터 검색 등 대규모 로컬 스토리지 용량과 높은 스토리지 성능이 필요한 IO 집약적이고 비즈니스 크리티컬한 워크로드를 위해 빌드되었습니다. 5세대 AMD EPYC 프로세서(Turin)를 기반으로 하며 Titanium의 최신 개선사항과 결합된 Z4D는 최대 84,000GiB의 로컬 SSD(LSSD) 스토리지를 제공합니다. 이전 세대 Z3 인스턴스에 비해 까다로운 워크로드의 성능을 최대 40% 향상하므로 클라우드 투자를 적절한 규모로 조정하면서 애플리케이션 처리량을 늘릴 수 있습니다. 또한 Z4D의 대규모 LSSD 용량은 AI/ML 학습 및 추론 워크로드와 대규모 분산 병렬 파일 시스템 실행을 위한 강력한 스토리지 솔루션입니다.

Z4D VM 및 베어메탈 인스턴스

Z4D VM 포트폴리오는 대규모 총 로컬 SSD 용량과 vCPU당 높은 로컬 SSD 용량을 제공하여 인프라를 적절한 규모로 조정하고 워크로드 요구사항에 맞게 클러스터를 확장할 수 있도록 지원합니다. Z4D는 두 가지 VM 유형을 제공합니다. Z4D-highmem-standardlssd VM 유형은 7가지 VM 형태를 포함하며 vCPU당 219GiB의 LSSD를 제공합니다. 이러한 VM은 데이터 분석(OLAP)과 MySQL 및 Postgres와 같은 SQL 데이터베이스에 최적화되어 있습니다. Z4D-highmem-highlssd VM 유형에는 7가지 VM 형태가 포함되며, vCPU당 438GiB의 LSSD를 제공하고 분산 데이터베이스, 데이터 스트리밍, 대규모 병렬 파일 시스템, 데이터 검색에 최적화되어 있습니다. 또한 Z4D 클러스터로 확장하여 기존 Z3 기반 워크로드를 쉽게 확장할 수 있습니다.

Z4D 베어메탈 인스턴스를 사용하면 가상화 레이어 없이 물리적 하드웨어에 직접 액세스할 수 있습니다. 이를 통해 지연 시간에 민감한 워크로드, 커스텀 하이퍼바이저, 특정 라이선스 요구사항이 있는 워크로드의 지연 시간을 줄일 수 있습니다. 또한 Z4D 베어메탈은 여러 클라우드 제공업체에서 작동하는 하이브리드 멀티 클라우드 플랫폼인 Nutanix Cloud Clusters(NC2)를 지원하는 최초의 AMD 기반 인스턴스가 될 것입니다. Z4D 베어메탈 인스턴스는 마이크로 VM을 사용하는 에이전트 AI 아키텍처에 필요한 LSSD 용량과 짧은 지연 시간을 제공하므로 개발자는 호스트당 수천 개의 격리된 샌드박스를 네이티브 성능과 효율성으로 실행할 수 있습니다.

Z4D VM 및 베어메탈 인스턴스는 84,000GiB의 로컬 SSD 스토리지 외에도 최대 384개의 vCPU와 최대 3,072GiB의 메모리를 제공합니다. Z4D 인스턴스는 Titanium SSD를 기반으로 하며, CPU 리소스에서 로컬 스토리지 처리 작업을 오프로드하여 실시간 데이터 처리, 짧은 지연 시간, 높은 처리량의 스토리지 성능, 향상된 스토리지 보안을 제공합니다. Z4D는 최대 15,600K의 무작위 읽기 IOPS와 최대 75,600MiB/s의 순차 읽기 처리량을 제공하여 LSSD 스토리지 성능을 Z3 대비 최대 70% 향상합니다. 또한 Z4D는 Z3에 비해 IO 지연 시간을 늘리지 않고도 쓰기 지연 시간을 최대 25% 줄이고 혼합 읽기-쓰기 IOPS를 최대 30% 개선합니다. 동시에 Z4D 인스턴스는 Z3에 비해 네트워킹 처리량을 두 배로 늘리고 최대 400Gbps의 표준 네트워킹 대역폭을 제공하여 엔터프라이즈 및 AI/ML 워크로드에 필요한 연결 및 스토리지 성능을 제공합니다.

고객 및 파트너 반응

"Elastic은 관측 가능성, 보안, 검색, AI 솔루션을 지원하는 Elasticsearch Platform을 통해 동급 최고의 성능을 제공하기 위해 최선을 다하고 있습니다. 이러한 워크로드를 대규모로 실행하는 팀에는 성능과 비용 효율성이 매우 중요합니다. 새로운 Z4D 가상 머신에 대한 초기 테스트 결과, 이전 세대 Z3 VM에 비해 색인 생성 처리량이 최대 50% 향상된 것으로 나타났습니다. Google Cloud에 배포하는 Elasticsearch 사용자에게 이러한 이점을 제공할 수 있기를 기대합니다." - 유브라지 굽타, Elastic 수석 제품 관리자

"Z4D 인스턴스로 마이그레이션한 후 처리 런타임이 약 70% 단축되었고 전체 비용도 절감되었습니다. 이러한 개선을 통해 Immunai는 대규모 면역 데이터를 훨씬 더 빠르게 처리하고 이를 생물학적 인사이트로 전환하여 제약 회사가 신약 발견 및 개발 전 과정에서 더 많은 정보에 입각한 결정을 내릴 수 있도록 지원합니다." - 가이 야크다브, Immunai 소프트웨어 엔지니어링 부문 전무이사

"Google Cloud와의 기술 협력을 확대하고 AMD와의 전략적 파트너십을 강화하여 새로운 Z4D 베어메탈 인스턴스에 Nutanix Cloud Clusters(NC2)를 도입하게 되어 기쁩니다. Z4D 기반 NC2는 NC2가 지원되는 최초의 AMD 메탈 인스턴스로서, 고객에게 중요한 이정표가 될 것입니다. AMD의 최첨단 컴퓨팅 성능과 Google Cloud의 강력한 인프라, Nutanix 하이브리드 클라우드 플랫폼을 결합하여 전례 없는 유연성, 확장성, 선택권을 제공함으로써 엔터프라이즈 워크로드를 지원하고 있습니다." - 사빈 파칼라, Nutanix 제품 관리 부문 부사장

"Redis는 전 세계 수천 개 조직에서 실시간 데이터 인프라와 AI 워크로드를 지원합니다. Flex는 이를 더 큰 데이터 세트로 확장하여 RAM만 사용하는 경제성을 제공합니다. 로컬 SSD는 규모를 처리하고 메모리는 속도를 제공합니다. Google Cloud의 새로운 Z4D 스토리지 최적화 VM을 동일한 플래시 집약적 워크로드에서 Flex 벤치마크 제품군을 사용하여 현재 세대 C3D 인스턴스와 비교했습니다. 결과는 인상적이었습니다. 소규모 형태에서 처리량이 최대 4.3배 더 높고 지연 시간은 최대 77% 더 낮았습니다. Z4D는 또한 전체 RAM 적중률에서 초당 약 180만 건의 작업을 유지했습니다. 플래시에서 제공하는 데이터가 많을수록 이점이 더 커졌으며, 이는 Flex가 설계된 목적과 정확히 일치합니다. Z4D는 더 작은 리소스 사용량으로 동일한 성능 등급을 제공할 수 있는 명확한 길을 열어주며, Z4D가 정식 버전으로 출시됨에 따라 테스트를 확장할 수 있기를 기대합니다." - 벤자민 르노, Redis CTO

"Shopify는 자사 Fleet에 가장 적합한 솔루션을 모색하고 있으며, Z4D는 빠른 로컬 연결 스토리지 및 빠른 네트워킹과 함께 높은 CPU 밀도를 제공합니다. Shopify의 사용자 경험은 데이터 제공 속도에 달려 있으며, AI 쇼핑 에이전트는 사람보다 훨씬 더 적극적으로 스토어프론트를 쿼리합니다. 이러한 인스턴스 형태는 이를 따라잡을 수 있는 처리량을 제공합니다. Z4D는 Z3보다 처리량이 약 20% 더 향상된 것을 확인했습니다." - 브래드 디트리히, Shopify 수석 엔지니어

"Google의 Z4D VM은 상당한 도약을 이뤄냈습니다. 테스트 결과, 이전 Gen 2 VM보다 최대 60% 더 우수한 성능을 보였으며 Z3 VM보다 최대 36% 더 우수한 성능을 보였습니다. Z4D는 높은 로컬 SSD 밀도와 강력한 비용 효율성, 향상된 시스템 안정성을 통해 Silk 고객에게 가장 까다로운 워크로드에 대해 더 빠르고 예측 가능한 성능을 제공합니다." - 아딕 소콜로브스키, Silk 최고 R&D 책임자

"AI를 페타바이트 규모의 최신 데이터와 연결하면 그 어느 때보다 더 많은 검색을 수행할 수 있습니다. 새로운 Z4D 인스턴스 유형을 도입하게 되어 기쁩니다. Z3와 비교했을 때 실제 쿼리 및 색인 생성 워크로드에서 처리량이 40% 개선되었으며, 이는 고객에게 더 빠르고 저렴한 웹 규모 검색을 제공하는 것으로 직접 이어집니다." - 벤 린세이, turbopuffer 엔지니어

향상된 유지보수 경험

Z4D VM과 베어메탈 인스턴스 모두 필요한 유지보수 며칠 전에 시스템에서 알림을 제공하므로 사용자가 미리 계획을 세우고 원하는 시간에 유지보수 작업을 예약하기가 더 쉽습니다. Z4D VM은 42,000GiB 이하의 로컬 SSD 스토리지를 사용하는 VM의 유지보수 이벤트 중에 인스턴스를 라이브 마이그레이션할 수 있도록 지원하여 유지보수 경험을 한층 더 개선합니다. 84,000GiB의 로컬 SSD가 있는 Z4D VM과 Z4D 베어메탈 인스턴스는 계획된 유지보수 이벤트 중에 데이터를 보존한 상태로 종료되고 다시 시작됩니다.

Hyperdisk 지원

Z4D VM 및 베어메탈은 각 인스턴스의 스토리지 성능과 용량을 독립적으로 조정하여 각 워크로드의 성능을 최적화할 수 있는 Google Cloud의 워크로드 최적화 블록 스토리지인 Hyperdisk를 지원합니다.

특히 확장 가능한 고성능 네트워크 연결 스토리지를 위한 Hyperdisk Balanced, Hyperdisk Throughput, Extreme Hyperdisk 스토리지와 호환되며 인스턴스당 최대 512TiB의 용량을 지원합니다. 범용 워크로드의 경우 인스턴스당 최대 320K IOPS를 제공하는 Hyperdisk Balanced가 성능과 비용 효율성을 모두 충족합니다. Hyperdisk Extreme은 매우 짧은 지연 시간을 제공하며 Z4D VM 및 베어메탈 인스턴스당 최대 500K IOPS 및 12,500MiB/s 처리량을 지원하므로 까다로운 데이터베이스 워크로드에 적합합니다.

지금 바로 Z4D를 사용해 보세요

Z4D VM은 현재 전 세계 일부 리전에서 사용할 수 있으며 Z4D 베어메탈 인스턴스는 프리뷰 버전으로 제공됩니다. 자세한 정보와 액세스 권한은 담당 계정팀에 문의하세요. Z4D 인스턴스 사용을 시작하려면 Google Cloud 콘솔에서 새로운 VM 또는 GKE 노드 풀을 생성할 때 스토리지 최적화 머신 계열에서 Z4D를 선택하세요. Z4D 머신 시리즈 페이지에서 자세히 알아보세요. 리전별 사용 가능 여부에 대한 자세한 내용은 Google Cloud 영업 담당자에게 문의하세요.

Storage Intelligence 어드바이저: 스토리지 자산의 변경사항을 파악하고 조치하기

Tue, 06 Oct 2026 19:00:00 +0000

오늘날 끊임없이 생성되는 방대한 데이터는 새로운 기회를 제공하는 동시에 막대한 운영상의 복잡성을 초래합니다. 대규모로 운영되는 대부분의 팀은 문제가 인보이스에 표시되고 나서야 이를 발견합니다. 비정상적인 액세스 패턴이 인보이스의 항목으로 표시될 때쯤에는 이미 몇 주째 실행된 경우가 많습니다. 무슨 일이 일어났는지 이해하려면 인벤토리를 내보내고, 액세스 로그와 대조하고, 어떤 서비스 계정이 어떤 작업에 속하는지 누군가 기억하고 있기를 바라야 합니다.

과거에는 이러한 워크플로로도 관리할 수 있었지만, 오늘날의 AI 학습 및 추론 파이프라인은 거버넌스 시스템이 분류할 수 있는 것보다 더 빠르게 데이터를 생성하고, 매주 달라지는 패턴으로 데이터를 읽습니다.

오늘 Google Cloud Storage의 두 가지 새로운 기능을 소개합니다. Storage Intelligence 어드바이저의 정식 버전을 선보이며, 스토리지 일괄 작업의 기능도 한층 확장됐습니다. 어드바이저는 스토리지 자산의 변화와 그에 따라 취해야 할 조치를 알려줍니다. 일괄 작업을 사용하면 이러한 결정을 수백만 개의 객체에 대해 실행할 수 있습니다. 이제 모든 Storage Intelligence 고객이 이러한 기능을 이용할 수 있습니다.

Cloud 콘솔의 Storage Intelligence 어드바이저

Storage Intelligence 어드바이저로 간편해지는 리포팅

지난 10년 동안 버킷에 어떤 데이터가 저장되어 있는지 파악하는 일은 데이터 엔지니어링 프로젝트나 다름없었습니다. 인벤토리를 내보내고, 쿼리 가능한 위치에 로드하고, 사용량과 대조하고, 대시보드를 빌드한 다음 지속적으로 관리해야 합니다. Storage Intelligence는 엔지니어링 오버헤드 없이 한눈에 파악할 수 있도록 합니다. 여러 팀에서 워크로드로 이를 입증하고 있습니다. Storage Intelligence를 사용하여 10억 개 이상의 객체로 구성된 데이터 세트를 분석하는 고객 수가 올해 두 배 이상 증가했습니다.

대규모 스토리지 자산을 운영하는 방법에는 두 가지가 있습니다. 팀은 일일 활동 데이터와 메타데이터 스냅샷을 활용하여 필요한 파이프라인을 정확하게 빌드할 수 있습니다. Storage Intelligence도 이러한 옵션을 제공하지만, 대부분의 팀은 꼭 필요한 경우가 아니라면 파이프라인을 빌드하지 않는 것을 선호합니다. 이들은 스토리지 환경에 어떤 변화가 있었는지, 그리고 이에 어떻게 대응해야 하는지를 알고 싶어 합니다. Storage Intelligence 어드바이저는 바로 이러한 팀을 위한 기능입니다.

어드바이저를 사용하는 첫날부터 확인 가능한 부분

Storage Intelligence 어드바이저를 사용하면 별도의 설정 없이도 스토리지 환경을 한눈에 파악할 수 있습니다. 어드바이저는 선별된 발견 사항을 바탕으로 시작합니다. 설계해야 할 스키마도, 관리해야 할 파이프라인도, 구축해야 할 대시보드도 없습니다. 조직, 폴더 또는 프로젝트에서 Storage Intelligence를 사용 설정하면 해당 범위에 포함된 버킷에 대한 차트와 발견 사항이 표시됩니다.

이제 Storage Intelligence Advisor를 통해 Shipt에서 이상치를 더 빠르게 감지할 수 있습니다.

"Storage Intelligence Advisor를 사용하기 전에는 [Google Cloud Storage에서] 주요 사용량 측정항목을 추적하고 이상치를 포착하려면 상당한 엔지니어링 작업과 복잡한 데이터 파이프라인이 필요했습니다. 이제 기본 제공되고 즉시 사용 가능한 대시보드를 통해 사용량 급증을 즉시 파악하고 세부정보를 드릴다운할 수 있습니다. 별도의 구성 없이도 의도하지 않은 사용을 즉시 파악하고 조치할 수 있어, 이전에는 많은 노력이 필요했던 작업을 간단한 셀프서비스 작업으로 전환할 수 있었습니다." - Charley King, Shipt(Target.com 자회사) DataOps-DevOps 엔지니어

설치가 완료되면 어드바이저는 즉시 Cloud Storage 자산을 분석하여 다음과 같은 이상치와 최적화 기회를 탐색합니다.

Coldline 또는 Archive 데이터에 대한 클래스 A 또는 B 작업 급증. 콜드 스토리지는 사용 비용은 저렴하지만 액세스 비용은 높습니다.
429 오류 급증. 요청 패턴이 한도를 초과하면 타임아웃이 발생합니다.
리전 간 이그레스 급증
총 사용량이 장기 추세를 상회

각 발견 사항은 프로젝트 자체의 활동 및 메타데이터를 기준으로 하며 스토리지 사용량의 일일 스냅샷을 기반으로 작동하므로, 특정 날짜의 사용량 급증은 월말 인보이스 항목에서 발견하는 것이 아니라 24시간 이내에 확인할 수 있습니다. 지난 30일 동안 수백 명의 고객에게서 6,000개 이상의 발견 사항이 생성되었습니다.

Archive Storage에 매일 수백만 건의 읽기 작업을 발생시키는 과도한 분석 작업을 예로 들어 보겠습니다. Storage Intelligence 어드바이저가 없다면, 이러한 문제를 몇 주 후 청구서에 검색 수수료가 부과된 후에야 알게 됩니다.

어드바이저는 프로젝트의 기준과 비교하여 이상치를 식별하고, 이를 해당 버킷, 프리픽스, 서비스 계정에 할당하고, 적용할 수 있는 방안을 제시합니다. 즉, 영향을 받은 객체를 Cloud Storage Standard로 일괄 전환하여 검색 요금 발생을 막거나, 실제 액세스 패턴에 따라 스토리지 등급이 자동으로 조정되도록 Autoclass를 사용 설정하거나, 관리형 폴더로 액세스를 제한해 해당 작업이 액세스해서는 안 되는 데이터에 도달할 수 없도록 합니다.

스토리지 일괄 작업으로 발견 사항에 조치 적용

대부분의 스토리지 권장 사항은 실행에 옮기려면 많은 작업이 필요하기 때문에 실제로 적용되지 않습니다. 수십억 개의 객체의 보관 정책이나 스토리지 클래스를 업데이트하려면 제한, 부분 실패, 재시도 등을 처리해야 합니다. 스토리지 일괄 작업을 사용하면 이러한 작업이 필요하지 않습니다. 실행은 완전 관리형 서버리스 방식으로 진행되며 진행 상황 추적 및 자동 재시도 기능이 기본 제공됩니다. 따라서 권장 사항을 별도의 프로젝트가 아닌 정책 기반 작업으로 전환할 수 있습니다.

Palo Alto Networks는 일괄 작업에 대해 다음과 같이 말했습니다.

"객체 보관 잠금은 보안 가드레일에 필수적이지만, 수십억 개의 객체에 걸쳐 이를 관리하는 것은 불가능한 일이었습니다. Storage Intelligence는 이러한 상황을 바꿨습니다. 이제 저희 팀은 스토리지 일괄 작업을 사용하여 필요할 때마다 전체 Fleet의 보관 정책을 원활하게 업데이트할 수 있습니다." - Kurtis Nusbaum, Palo Alto Networks 선임 수석 소프트웨어 엔지니어

Storage Intelligence Advisor와 일괄 작업은 동일한 Storage Intelligence 구독에 포함되어 있으므로 고객은 이제 어드바이저를 통해 문제를 신속하게 파악하고 일괄 작업을 통해 해당 문제를 쉽게 해결할 수 있습니다.

일괄 작업을 사용하면 다음을 수행할 수 있습니다.

운영 급증 해결: 패턴이 감지되는 즉시 트래픽이 많은 Archive 또는 Coldline 객체를 Standard로 일괄 전환하여 검색 및 운영 수수료의 발생을 즉시 억제합니다.
급격한 증가 억제. 어드바이저가 추세를 상회하는 스토리지 증가를 감지하면 특정 프리픽스에서 오래된 데이터나 임시 데이터를 일괄 삭제합니다.
Fleet 전반의 일관성 적용. 대규모 객체 세트에 메타데이터, 태그 지정, 보관 또는 암호화 변경사항을 일괄 적용하고, 별도의 컴퓨팅을 프로비저닝할 필요도 없습니다.

또한 일괄 작업의 기존 기능을 확장하고 개선하여 대규모 작업을 더 쉽게 실행할 수 있도록 했습니다.

다중 버킷 처리: 버킷별로 작업을 실행하는 대신, 프로젝트당 최대 1,000개의 버킷에서 단일 작업을 실행합니다.
드라이 런 검증. 실시간 데이터를 수정하기 전에 테스트 실행 모드를 사용하여 변환을 시뮬레이션합니다. 드라이 런을 사용하면 영구적인 변경사항을 커밋하기 전에 작업의 영향(영향을 받는 객체 수, 총 크기, 잠재적 오류 등)을 미리 안전하게 확인할 수 있습니다.
Storage Insights 데이터 세트를 기반으로 하는 고급 필터: Common Expression Language(CEL) 표현식을 사용하여 Insights 데이터 세트의 필드와 일치하는 조건을 지정하여 객체를 직접 선택할 수 있습니다. 예를 들어 버킷 전체의 객체를 스토리지 클래스, 객체 크기, 생성 날짜 또는 맞춤 속성을 기준으로 필터링할 수 있습니다.

다음은 고급 필터를 사용하여 일괄 작업 작업을 생성하는 방법을 보여주는 CLI 예시입니다. 이 작업은 사용자의 'analytics' 버킷에 있는 Standard Storage 클래스에 속하는 모든 임시 객체를 삭제합니다.

code_block: <ListValue: [StructValue([('code', 'gcloud storage batch-operations jobs create bulk-delete-temp-objects \\\r\n --description="Bulk delete temporary objects in analytics buckets" \\\r\n --target-project="my-project-id" \\\r\n--insights-dataset-config="projects/my-project-id/locations/us-central1/datasetConfigs/my-dataset" \\\r\n --bucket-filters="name.startsWith(\'analytics-\')" \\\r\n --object-filters="storageClass == \'STANDARD\' && name.endsWith(\'.temp\')" \\\r\n --delete-object'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd8a8169250>)])]>

스토리지 관리의 진화

스토리지 관리는 분기별 검토나 사고 발생 후 긴급 대응을 위해서만 하는 사후 대응적인 노력이 되어서는 안 됩니다. 지속적이고 선제적이며 상황에 맞게 이루어져야 합니다.

Storage Intelligence 어드바이저와 일괄 작업을 사용하면 변경사항을 파악하고, 대규모 환경에서 인사이트를 확인하고 조치를 취할 수 있습니다. Storage Intelligence가 어떤 발견 사항이 중요한지 더 잘 인식하게 됨에 따라, Cloud Storage는 대규모로 스토리지를 관리해야 하는 팀의 운영 부담을 많이 덜어줄 수 있습니다.

Storage Intelligence 어드바이저와 향상된 스토리지 일괄 작업을 이제 정식 버전으로 이용할 수 있습니다.

시작하려면 프로젝트 또는 조직에서 Storage Intelligence를 사용 설정하세요. 이전에 Storage Intelligence를 사용한 적이 없다면 30일 무료 체험을 이용할 수 있습니다.

Filestore 에이전트 볼륨 소개: 에이전트 작업공간을 위한 완전 관리형 스토리지

Wed, 23 Sep 2026 07:00:00 +0000

빌드 도구 실행부터 데이터 분석 파이프라인, 공동 연구에 이르기까지 데이터 기반 작업을 실행하는 것은 모든 엔터프라이즈 에이전트에게 필수적입니다.

오늘날 플랫폼팀은 에이전트 스토리지 요구사항을 해결하기 위해 커스텀 해결 방법을 조합하는 경우가 많습니다. 여기에는 에이전트 샌드박스와 중앙 집중식 스토리지 간에 상태를 주고받거나 로컬 디스크 또는 자체 호스팅 파일 시스템을 수동으로 관리하는 작업이 포함될 수 있습니다. 그러나 에이전트 Fleet 규모가 커지면 이러한 접근 방식은 콜드 스타트 지연 시간, 운영 복잡성, 사전 할당된 유휴 스토리지 비용 사이에서 어려운 절충을 강요합니다.

조직이 에이전트 샌드박스를 수천 또는 수백만 개의 동시 세션으로 확장함에 따라 스토리지 역시 이러한 절충 문제를 극복하고 동적 워크로드의 요구사항을 충족할 수 있도록 발전해야 합니다. 이러한 워크로드에는 엄격한 작업공간 격리, 즉각적인 세션 재개, 탄력적인 종량제 가격 체계, 유연한 멀티 에이전트 협업이 필요합니다.

이러한 새로운 요구사항을 충족하기 위해 Google Cloud는 AI 스토리지 포트폴리오를 확장하고 Filestore 에이전트 볼륨을 출시합니다. 이 새로운 완전 관리형 기능은 Google Cloud에서 에이전트 워크로드를 확장하기 위한 고성능의 탄력적인 파일 스토리지를 제공하도록 특별히 설계되었습니다.

AI 에이전트 작업공간을 위해 특화된 스토리지

자율 에이전트가 호스트 인프라나 테넌트 데이터를 위험에 빠뜨리지 않으면서 동적 코드를 안전하게 실행하고, 서드 파티 패키지를 설치하고, 도구를 실행하기 위해서는 격리된 런타임 환경이 필요합니다. GKE의 Agent Substrate와 GKE 에이전트 샌드박스는 고밀도 에이전트 Fleet를 실행하는 데 필요한 전용 컴퓨팅 환경을 제공하지만, 이러한 샌드박스에는 작동을 위한 전용 영구 작업공간도 필요합니다.

Google Cloud Filestore 내의 Filestore 에이전트 볼륨은 AI 에이전트 Fleet의 규모와 탄력성을 위해 특별히 설계된 동적 프로비저닝 아키텍처를 통해 에이전트 컴퓨팅을 보완하는 전용 에이전트 스토리지를 제공합니다. 에이전트 기반 Fleet을 대규모로 지원하기 위해 Agent Substrate와 함께 설계된 Filestore 에이전트 볼륨을 사용하면 GKE 샌드박스에서 격리된 영구 파일 스토리지에 즉각적으로 액세스할 수 있습니다. Filestore를 활용하도록 구성하면 GKE 스토리지 관리가 백그라운드에서 이루어집니다. GKE가 새로운 에이전트 작업을 위해 샌드박스를 실행할 때마다 Filestore는 밀리초 단위로 전용 격리 파일 작업공간을 해당 환경에 자동으로 할당하고 연결합니다. 플랫폼팀은 개별 에이전트 실행을 위해 스토리지 볼륨을 수동으로 생성, 연결, 해제할 필요가 없습니다. 대신 에이전트 Fleet이 확장 및 축소됨에 따라 시스템이 전체 볼륨 수명 주기를 자동으로 처리합니다. 그 결과 비용 효율적인 에이전트 관리를 위한 효율적인 엔드 투 엔드 인프라 솔루션이 탄생했으며, 이 솔루션은 다음과 같은 이점을 제공합니다.

세분화된 격리 및 엔터프라이즈 가드레일: 에이전트 플랫폼은 신뢰할 수 없는 자율 코드를 실행할 때 보안 및 데이터 유출 위험에 직면합니다. Filestore 에이전트 볼륨은 작업공간별로 엄격한 경계 제어와 세분화된 액세스 권한을 적용하여 에이전트가 지정된 디렉터리 내에서만 작동하도록 보장하고 동적 도구 모음을 테넌트 간에 엄격하게 격리합니다.
1초 미만의 세션 재개: 기존의 스토리지 프로비저닝 접근 방식은 콜드 스타트 지연 시간을 유발하여 대화형 에이전트 세션을 지연시킬 수 있습니다. 에이전트 볼륨은 밀리초 단위로 연결 및 분리되므로 조정자가 유휴 샌드박스를 적극적으로 정지하여 컴퓨팅 비용을 절감하고 새로운 작업이나 사용자 입력이 들어오면 즉시 재개할 수 있습니다.
스마트 수명 주기 경제 및 종량제 가격 책정: 수명이 짧거나 간헐적인 수천 개의 에이전트 태스크를 위해 고정된 크기의 고성능 스토리지를 사전 할당하면 막대한 스토리지 낭비가 발생할 수 있습니다. 에이전트 볼륨을 사용하면 플랫폼은 사용한 스토리지 용량에 대해서만 비용을 지불하고 자동 수명 주기 계층화의 이점도 누릴 수 있습니다. 따라서 불필요한 비용 지출 없이 높은 성능을 얻을 수 있습니다. 에이전트가 코드를 적극적으로 읽지 않거나 수정하지 않거나 데이터 세트를 분석하지 않는 경우 유휴 작업공간 상태를 저비용 스토리지로 자동 전환할 수 있습니다.
멀티 에이전트 협업: 멀티 에이전트 스웜을 조정할 때는 데이터 전달 파이프라인이 불안정해지고 파일 충돌 위험이 발생할 수 있습니다. 기본 Read-Write-Many(RWX) 지원 및 POSIX 파일 잠금 기능을 갖춘 에이전트 볼륨을 사용하면 조정자가 하나의 공유 작업공간을 여러 에이전트에 연결할 수 있습니다. 협업 에이전트는 파일 수준의 일관성과 쓰기 충돌 방지 기능을 통해 프로젝트 파일을 동시에 안전하게 공동 작성, 테스트, 검토할 수 있습니다.

차세대 에이전트형 워크로드 지원

Filestore 에이전트 볼륨은 고성능의 탄력적이고 격리된 파일 계층을 제공하여 프로덕션에서 다양한 에이전트형 워크로드와 사용 사례를 지원합니다.

소프트웨어 엔지니어링 및 코딩 샌드박스: 에이전트형 코딩 플랫폼은 수천 개의 격리된 작업공간을 가동할 수 있으며, 에이전트는 이러한 작업공간에서 라이브러리를 안전하게 설치하고, 멀티 파일 패치를 작성하고, 빌드 도구를 실행하고, 단위 테스트를 실행할 수 있습니다. 이 모든 작업은 스토리지별 맞춤설정 없이 표준 POSIX 파일 시맨틱스를 활용하여 수행됩니다.
협업형 멀티 에이전트 스웜: 리드 조정자가 조사, 코드 생성, 검증을 담당하는 하위 에이전트에 작업을 위임하는 등의 복잡한 워크플로에서 하나의 통합된 파일 트리를 직접 공유할 수 있습니다. RWX 지원을 통해 에이전트는 쓰기 충돌 없이 프로젝트 파일을 동시에 공동 작성하고 검토할 수 있습니다.
상호작용형 장기 워크플로: 사용자 참여형 애플리케이션(예: 비동기 사용자 승인이 필요하거나 몇 시간 동안 데이터 분석 파이프라인을 실행하는 에이전트)의 경우 플랫폼에서 유휴 에이전트 샌드박스를 정지하여 컴퓨팅 낭비를 최소화한 다음 필요에 따라 1초 미만의 응답 속도로 실행을 재개할 수 있습니다.

지금 시작하기

서비스형 에이전트 플랫폼을 빌드하거나, 코딩 어시스턴트를 확장하거나, 엔터프라이즈 에이전트 Fleet을 배포하고 있다면 스토리지 계층은 혁신을 방해하는 것이 아니라 가속화해야 합니다.

이제 모든 Google Cloud 고객이 비프로덕션 워크로드에 Filestore 에이전트 볼륨을 사용할 수 있습니다. 프로덕션 워크로드에 대한 정식 버전 지원은 허용 목록을 통해 제공됩니다. 이 새로운 제품은 GKE의 Agent Substrate 및 GKE 에이전트 샌드박스와의 즉시 사용 가능한 통합 기능을 제공하여 반응성이 뛰어나고 확장 가능하며 비용 효율적인 에이전트 플랫폼을 바로 빌드할 수 있도록 지원합니다.

Filestore 에이전트 볼륨에 대한 액세스를 요청하려면 이 양식을 제출하고 Filestore 문서 및 GKE 문서에서 자세한 내용을 알아보세요.

Google의 미디어 무결화에 대한 미래

Mon, 13 Oct 2025 16:00:00 +0000

해당 블로그의 원문은 2025년 10월 14일 Google Cloud 블로그(영문)에 게재되었습니다.

Google에서 데이터 보호는 가장 중요한 책임이며, 저희는 고객님의 데이터를 안전하게 지키기 위해 최선을 다하고 있습니다. 이러한 약속을 더욱 강화하기 위해, 2025년 11월부터 미디어 완전 삭제에 대한 접근 방식을 전환하여, 강력하고 계층화된 암호화 전략에 전적으로 의존하기 시작할 것임을 알려드리게 되어 기쁩니다.

이는 저희가 약 20년 동안 사용해 온 '무차별적인 디스크 삭제(brute force disk erase)' 프로세스에서 벗어나는 것을 의미합니다. 데이터를 덮어쓰는 방식은 효과적인 방법이었지만, 저장 기술 환경이 급격하게 변화했습니다. 오늘날 현대 미디어의 크기와 기술적 복잡성으로 인해 이 프로세스는 더 이상 지속 가능하지 않습니다.

더 스마트한 접근 방식: 암호화 삭제 (Cryptographic Erasure)

이러한 문제를 해결하기 위해, 저희는 미디어 완전 삭제의 더욱 현대적이고 효율적인 방법인 암호화 삭제(cryptographic erasure)를 도입합니다.

기본적으로 Google 서비스의 모든 사용자 데이터는 다중 암호화 계층으로 보호됩니다. 암호화 삭제는 이러한 암호화를 활용하여 미디어를 완전 삭제합니다. 드라이브 전체를 덮어쓰는 대신, 데이터 암호화에 사용되는 암호화 키를 안전하게 삭제합니다. 키가 사라지면 데이터는 읽을 수 없고 복구할 수 없는 상태가 됩니다.

이 방법은 더 빠를 뿐만 아니라 업계 모범 사례와도 일치합니다. 미국 국립표준기술연구소(NIST)는 특별 간행물 800-88에서 암호화 삭제를 유효한 완전 삭제 기술로 인정하고 있습니다. 저희는 고객님의 데이터 보안을 보장하기 위해 이러한 표준을 충족하고 능가하기 위해 최선을 다하고 있습니다.

혁신을 통한 보안 강화

저희는 심층 방어(defense in depth) 전략을 사용하여 암호화 삭제를 다중 보안 계층으로 구현합니다. 저희의 신뢰하되 검증하는(trust-but-verify) 모델은 독립적인 검증 메커니즘을 사용하여 미디어 암호화 키의 영구 삭제를 보장합니다.

또한, 저장 장치 키와 같은 이 프로세스에 관련된 비밀 정보를 업계 최고의 조치로 보호합니다. 다중 키 순환(key rotations)은 독립적인 신뢰할 수 있는 암호화 계층을 통해 고객 데이터의 보안을 강화합니다.

지속 가능성 및 순환 경제

이전의 미디어 삭제 방법은 환경적 비용을 수반했습니다. 저희의 엄격한 검증 프로세스에 실패한 모든 저장 장치는 물리적으로 파괴되어 매년 상당수의 장치가 폐기되었습니다.

암호화 삭제는 저희가 더 지속 가능한 순환 경제로 나아갈 수 있도록 합니다. 드라이브를 물리적으로 파괴할 필요성을 제거함으로써, 저희는 더 많은 하드웨어를 재사용할 수 있습니다. 또한, 수명이 다한 미디어에서 네오디뮴 자석과 같은 귀중한 희토류 재료를 회수할 수 있게 됩니다. 이 혁신적인 자석 회수 프로세스는 지속 가능한 제조 분야의 주요 성과이며, 책임 있는 성장에 대한 저희의 약속을 보여줍니다.

Google의 앞으로의 방향

저희는 사용자, 더 넓은 산업, 그리고 전 세계를 위해 진정으로 올바른 일을 하는 것에 대해 지속적으로 강력하게 주장해 왔습니다. 이러한 암호화 삭제로의 전환은 그러한 약속을 직접적으로 반영합니다. 이를 통해 저희는 보안을 강화하고, 최고의 산업 표준에 부합하며, 저희 인프라를 위해 더 지속 가능한 미래를 구축할 수 있습니다. 저희는 이것이 사용자, 산업, 그리고 환경을 위한 올바른 길이라고 믿습니다.

암호화 키 관리를 포함한 미사용 데이터 암호화에 대한 자세한 내용은, 저희의 미사용 데이터 기본 암호화 보안 백서(default encryption at rest)를 참조해 주십시오.

Google Kubernetes Engine의 Managed Lustre 관련 5가지 권장사항

Fri, 19 Sep 2025 16:00:00 +0000

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

Google Kubernetes Engine(GKE)은 확장 가능한 AI 및 고성능 컴퓨팅(HPC) 워크로드를 조정하기 위한 강력한 플랫폼입니다. 하지만 클러스터가 커지고 작업이 더 데이터 집약적으로 변할수록 스토리지 I/O가 병목 현상이 될 수 있습니다. 이로 인해 강력한 GPU와 TPU가 데이터를 기다리느라 유휴 상태가 되어 비용이 증가하고 혁신이 둔화될 수 있습니다.

Google Cloud Managed Lustre는 이러한 문제를 해결하기 위해 설계되었습니다. 많은 온프레미스 HPC 환경에서 이미 병렬 파일 시스템을 사용하고 있으며, Managed Lustre를 사용하면 이러한 워크로드를 클라우드로 더 쉽게 가져올 수 있습니다. 관리형 컨테이너 스토리지 인터페이스(CSI) 드라이버를 통해 Managed Lustre는 GKE 운영과 완전히 통합됩니다.

고성능 병렬 파일 시스템으로의 이전을 최적화하면 첫날부터 투자 효과를 극대화할 수 있습니다.

배포에 앞서 Managed Lustre를 사용해야 하는 경우와 Google Cloud Storage와 같은 다른 옵션을 사용해야 하는 경우를 알아두는 것이 좋습니다. 대부분의 AI 및 ML 워크로드에는 Managed Lustre가 권장되는 솔루션입니다. 학습 및 체크포인팅처럼 지연 시간이 1밀리초 미만으로 매우 짧고 작은 파일에 대해 높은 처리량을 요구하는 시나리오에서 탁월한 성능을 발휘하므로 고가의 가속기를 최대한 활용할 수 있습니다. 반면, 데이터 보관처리 또는 대용량 파일(50MB 초과)을 다루고 지연 시간에 민감하지 않은 워크로드의 경우 Cloud Storage FUSE와 Anywhere Cache 조합이 또 다른 선택지로 고려할 수 있습니다.

초기 고객들과의 협업과 Google Cloud팀의 경험을 바탕으로 GKE에서 Managed Lustre를 최대한 활용하기 위한 5가지 권장사항을 소개합니다.

aside_block: <ListValue: [StructValue([('title', 'Google Cloud 컨테이너 및 Kubernetes를 체험할 수 있는 $300 무료 크레딧 제공'), ('body', <wagtail.rich_text.RichText object at 0x7fd89b7c6350>), ('btn_text', ''), ('href', ''), ('image', None)])]>

1. 데이터 지역성을 고려한 설계

성능에 민감한 애플리케이션의 경우 컴퓨팅 리소스와 스토리지가 가능한 한 가까이 있어야 하며, 특정 리전 내 동일한 영역에 있는 것이 이상적입니다. 볼륨을 동적으로 프로비저닝할 때는 StorageClass의 volumeBindingMode 파라미터가 가장 중요한 도구입니다. 이를 WaitForFirstConsumer로 설정하는 것이 좋습니다. GKE는 기본적으로 WaitForFirstConsumer 바인딩 모드를 사용하는 Managed Lustre용 내장 StorageClass를 제공합니다.

생성된 YAML:

code_block: <ListValue: [StructValue([('code', 'apiVersion: storage.k8s.io/v1\r\nkind: StorageClass\r\nmetadata:\r\n name: lustre-regional-wait\r\nprovisioner: lustre.csi.storage.gke.io\r\nvolumeBindingMode: WaitForFirstConsumer\r\n...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd8a85f2090>)])]>

권장하는 이유: WaitForFirstConsumer를 사용하면 이를 필요로 하는 포드가 예약될 때까지 GKE가 Lustre 인스턴스의 프로비저닝을 지연하도록 지시합니다. 그러면 스케줄러는 포드의 토폴로지 제약 조건(즉, 예약된 영역)을 사용하여 정확히 동일한 영역에 Lustre 인스턴스를 만듭니다. 이렇게 하면 스토리지와 컴퓨팅이 동일한 위치에 배치되어 네트워크 지연 시간이 최소화됩니다.

2. 성능에 맞는 등급 선택

모든 고성능 워크로드가 동일한 것은 아닙니다. Managed Lustre는 여러 성능 등급(스토리지 1TiB당 읽기 및 쓰기 처리량(Mbps))을 제공하므로 성능 요구사항에 맞춰 비용을 제어할 수 있습니다.

1,000 및 500Mbps/TiB: I/O 대역폭이 주된 병목 현상인 파운데이션 모델 학습 또는 대규모 물리 시뮬레이션과 같이 처리량이 중요한 워크로드에 적합합니다.
250Mbps/TiB: 균형 잡힌 비용 효율적인 등급으로, 많은 일반적인 HPC 워크로드와 AI 추론 서빙, 데이터 집약적인 분석 파이프라인에 적합합니다.
125Mbps/TiB: 최대 처리량을 달성하는 것보다 대규모의 POSIX 규격 파일 시스템을 갖추는 것이 더 중요한 대용량 사용 사례에 가장 적합합니다. 또한 컨테이너화된 온프레미스 애플리케이션을 별도의 수정 없이 마이그레이션하는 데도 유용하므로 온프레미스 워크로드를 클라우드 스토리지로 더 쉽게 마이그레이션할 수 있습니다.

권장하는 이유: 무조건 최고 등급을 선택하는 것이 항상 비용 효율적인 전략은 아닙니다. 워크로드의 I/O 프로필을 분석하면 총소유비용을 크게 최적화할 수 있습니다.

3. 네트워킹 기반 구축

병렬 파일 시스템은 네트워크로 연결되는 리소스입니다. 네트워킹을 처음부터 올바르게 설정하면 문제 해결에 드는 시간을 줄일 수 있습니다. 프로비저닝하기 전에 문서의 설정 단계를 따라 VPC가 올바르게 구성되었는지 확인하세요. 이 과정은 문서에 자세히 설명된 아래 세 가지 주요 단계로 이루어져 있습니다.

서비스 네트워킹을 사용 설정합니다.
VPC 피어링의 IP 범위를 만듭니다.
Lustre 네트워크 포트(TCP 988 또는 6988)에서 해당 범위의 트래픽을 허용하도록 방화벽 규칙을 만듭니다.

권장하는 이유: VPC당 한 번만 설정하면 되는 작업으로, GKE 노드가 Managed Lustre 서비스와 통신할 수 있도록 안전한 피어링 연결이 설정됩니다.

4. 단순성을 원한다면 동적 프로비저닝을, 장기 공유 데이터에는 정적 프로비저닝을 사용

Managed Lustre CSI 드라이버는 스토리지와 GKE 워크로드를 연결하는 두 가지 모드를 지원합니다.

동적 프로비저닝: 스토리지가 특정 워크로드나 애플리케이션의 수명 주기가 긴밀하게 연결되어 있는 경우 사용합니다. StorageClass와 PersistentVolumeClaim(PVC)을 정의하면 GKE가 자동으로 Lustre 인스턴스 수명 주기를 관리해 줍니다. 가장 간단하고 자동화된 접근방식입니다.
정적 프로비저닝: 장기 Lustre 인스턴스를 여러 GKE 클러스터와 작업 간에 공유해야 하는 경우에 사용합니다. Lustre 인스턴스를 한 번 만든 후 클러스터에서 마운트하기 위해 PersistentVolume(PV)과 PVC를 만듭니다. 이렇게 하면 스토리지 수명 주기가 단일 워크로드에서 분리됩니다.

권장하는 이유: 데이터 수명 주기를 고려하면 적절한 패턴을 선택하는 데 도움이 됩니다. 단순성을 위해 기본적으로 동적 프로비저닝을 사용하고, 파일 시스템을 조직 전체에서 지속적으로 공유되는 리소스로 취급해야 하는 경우에는 정적 프로비저닝을 선택하세요.

5. Kubernetes 작업으로 병렬 처리 설계

데이터 전처리 또는 일괄 추론과 같은 많은 AI 및 HPC 작업은 병렬 실행에 적합합니다. 하나의 대규모 포드를 실행하는 대신 Kubernetes 작업 리소스를 사용하여 작업을 여러 개의 작은 포드로 나누세요.

다음 패턴을 고려하세요.

Managed Lustre 인스턴스에 대해 단일 PersistentVolumeClaim을 만들어 클러스터에서 사용할 수 있도록 합니다.
병렬 처리 수를 높게 설정한 Kubernetes 작업을 정의합니다(예: 100).
작업에서 생성된 각 포드는 동일한 Lustre PVC를 마운트합니다.
애플리케이션을 설계할 때 각 포드가 데이터의 서로 다른 하위 집합(예: 서로 다른 범위의 파일 또는 데이터 청크 처리)에서 작동하도록 만듭니다.

권장하는 이유: 이 패턴에서는 Lustre 인스턴스에 대해 단일 PVC를 만들고, 작업에서 생성된 각 포드가 동일한 PVC를 마운트하도록 합니다. 각 포드가 데이터의 서로 다른 하위 집합에서 작동하도록 애플리케이션을 설계하면 GKE 클러스터를 강력한 분산 데이터 처리 엔진으로 전환할 수 있습니다. GKE 작업 컨트롤러는 병렬 작업을 조정하는 역할을 하고 Managed Lustre는 고속 데이터 백본 역할을 함으로써, 대규모 집계 처리량을 달성할 수 있습니다.

지금 시작하기

GKE의 조정 기능과 Managed Lustre의 성능을 결합하면 진정으로 확장 가능하고 효율적인 AI 및 HPC 플랫폼을 빌드할 수 있습니다. 이 권장사항을 따르면 강력하면서도 효율적이고 비용 효과적이며 관리하기 쉬운 솔루션을 만들 수 있습니다.

시작할 준비가 되셨나요? Managed Lustre 문서를 살펴보고 지금 바로 첫 번째 인스턴스를 프로비저닝하세요.

인스턴트 스냅샷: Compute Engine 워크로드의 오류와 손상 방지

Mon, 17 Mar 2025 10:57:00 +0000

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

여러분이 애플리케이션 관리자이고 1시간의 유지보수 동안 애플리케이션 업그레이드를 수행해야 하는데 갑자기 업그레이드에 실패했다고 생각해 보세요. 이런 상황에서는 롤백 절차를 시작하게 됩니다. 일반적인 롤백 과정에서는 정기적인 스냅샷을 바탕으로 몇 분간 복구를 진행하게 되는데, 작업 완료에 필요한 시간은 복원할 데이터양에 따라 달라집니다. 애플리케이션의 사전 업그레이드 복제본을 바탕으로 복원하는 방법도 있지만 이는 유지 비용이 많이 든다는 단점이 있습니다.

유지보수 기간을 더 여유롭게 확보하고 롤백 시간도 예측할 수 있으며 비용 효율적이면서도 디스크 크기에 구애받지 않는 아주 빠른 복구 솔루션이 있다면 어떨까요?

오늘 소개해 드릴 Compute Engine의 인스턴트 스냅샷은 필요에 따라 신속하게 복원 가능하도록 거의 즉각적인 고빈도 특정 시점 디스크 체크포인트를 제공합니다.

인스턴트 스냅샷은 몇 초 단위의 목표 복구 시간(RPO)과 수십 초 단위의 복구 시간 목표(RTO)를 제공합니다. Google Cloud는 단 몇 초면 복구가 가능한 고성능 체크포인트를 제공하는 유일한 하이퍼스케일러입니다. 타사 하이퍼스케일러를 사용할 경우 워크로드가 최대 성능으로 복구되기까지 수십 분 또는 몇 시간이 걸릴 수 있지만 인스턴트 스냅샷으로 복구를 진행하면 Compute Engine 워크로드가 최대 디스크 성능으로 즉시 실행됩니다.

Compute Engine의 인스턴트 스냅샷을 사용해 복구를 진행하려면 핵심 인프라에 아무 문제가 없어야 하며 데이터를 이전 상태로 롤백해야 합니다. 일반적인 사용 사례는 다음과 같습니다.

사용자 오류, 애플리케이션 소프트웨어 장애, 파일 시스템 손상을 신속하게 복구합니다.
데이터베이스 워크로드 등을 위한 백업 인증 워크플로에서 주기적인 스냅샷을 생성한 뒤 즉시 복원하여 데이터 일관성 검사를 실행합니다.
예정된 유지보수에 실패한 경우 신속한 롤백이 가능하도록 애플리케이션 업그레이드 전에 복원 지점을 설정합니다.

위 사용 사례 외에도 인스턴트 스냅샷을 사용하면 다음과 같은 이점이 있습니다.

개발자 생산성 개선: 빠른 개발 주기에서 빌드 시간이 길거나 코드가 복잡한 경우 실수로 인한 오류가 발생하거나 빌드에 실패하면 작업을 완료하는 데 걸리는 시간이 늘어납니다. 인스턴트 스냅샷을 사용하면 외부 백업에 의존하지 않아도 빠른 복원이 가능합니다.
백업 전 상태 확인: 수행한 백업이 사용 가능하고 원하는 상태인지 확인할 수 있습니다. 장기 백업을 시작하기 전에 인스턴트 스냅샷을 사용해 디스크를 검사하고 클론하여 예비 머신에서 확인할 수 있습니다.
백업 빈도 증가: 인스턴트 스냅샷을 사용하면 긴 백업 시간을 기다릴 여유가 없는 대용량의 비즈니스 크리티컬 데이터베이스를 더 자주 백업할 수 있습니다.

인스턴트 스냅샷의 주요 특징

Compute Engine 인스턴트 스냅샷은 기존 스냅샷에 비해 더 많은 이점을 가지고 있습니다.

인플레이스 백업: 인스턴트 스냅샷은 영역 디스크 또는 리전 디스크에 생성되며 소스 디스크 및 미디어 유형과 동일한 위치에 저장됩니다. 다시 말해 SDD 또는 HDD 유형의 디스크에서 생성된 인스턴트 스냅샷은 동일한 디스크에 저장됩니다. 인스턴트 스냅샷은 생성 시 고정 요금이 부과되며 사용하는 스토리지가 늘어남에 따라 추가 요금이 책정됩니다.
신속성 및 증분성: 인스턴트 스냅샷은 몇 초면 생성되며 각 인스턴트 스냅샷에는 이전 인스턴트 스냅샷이 생성된 이후 변경된 증분 데이터 블록만 저장됩니다. 스냅샷 생성 빈도가 훨씬 높기 때문에 백업 스냅샷보다 더 자주 스냅샷을 생성할 수 있습니다.
빠른 디스크 복원: 단 몇 초면 각 인스턴트 스냅샷을 새 디스크에 복원할 수 있습니다. 이러한 새 디스크는 스냅샷과 동일한 영역에 위치하며 해당 디스크 유형을 상속합니다.
백업 또는 보관 파일로 변환 가능: 장기 지리적 중복 스토리지를 위한 보조 접속 지점으로 인스턴트 스냅샷을 옮길 수 있습니다.

인스턴트 스냅샷의 실행 방식

인스턴트 스냅샷은 초기 체크포인트와 비교하여 변경된 데이터만 저장하기 때문에 몇 초면 생성이 가능합니다.

따라서 위 예시에서도 인스턴트 스냅샷 생성 시 체크포인트가 만들어지지만 이 디스크의 세 번째 블록에 새 데이터를 덮어쓸 때만 데이터가 저장됩니다. 여기에서 블록 6 및 7에 데이터를 쓴 것처럼 데이터를 추가한 경우에도 체크포인트에 추가 스토리지가 필요하지 않습니다.

스토리지를 아주 효율적으로 사용할 수 있을 뿐 아니라 성능 효율성 또한 탁월한 셈입니다. 인스턴트 스냅샷 생성 시 기본 디스크의 성능에 아무 영향을 미치지 않으며, 앞서 언급했듯이 단 몇 초면 인스턴트 스냅샷을 만들고 복원할 수 있습니다.

표준 변경 관리 및 유지보수 과정에서 이와 같은 스토리지와 성능, 비용 효율성을 갖춘 인스턴트 스냅샷을 사용하면 워크로드를 더욱 쉽고 효율적으로 보호할 수 있습니다.

스냅샷 유형 비교

다음과 같은 인스턴트 스냅샷의 여러 가지 성능 특성 개요에서 표준 백업 스냅샷과의 차이점을 살펴보세요.

사용 사례

애플리케이션 관리자인 Maya는 영구 디스크 볼륨에 호스팅된 소프트웨어를 업그레이드해야 합니다. 이 작업에 주어진 유지보수 기간은 단 1시간입니다. 유지보수 기간이 끝난 후 볼륨에 새 소프트웨어가 포함되어 있으면 업그레이드에 성공한 것이며, 업그레이드에 실패할 경우 유지보수 기간이 시작되기 직전과 정확히 동일한 상태, 즉 롤백 상태가 됩니다.

정기적인 스냅샷과 인스턴트 스냅샷 사용 시 Maya의 워크플로가 어떻게 달라지는지 비교해 보세요.

지금 바로 사용하기

인스턴트 스냅샷은 거의 즉각적인 온디바이스 특정 시점 백업을 제공하여 신속한 복원과 고빈도 백업을 지원합니다. 또한 애플리케이션 업그레이드 기간을 최적화하고 외부 백업에 드는 시간을 절약하는 데 도움이 되며 업그레이드 실패 또는 사용자 오류 발생 시 빠른 복원을 가능하게 합니다.

Persistent Disk 인스턴트 스냅샷을 활용하는 방법은 인스턴트 스냅샷 문서 페이지를 참조하세요.

AI 기반 쿼리 및 인사이트를 통해 Cloud Storage 사용 현황 파악하기

Mon, 17 Mar 2025 08:31:00 +0000

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

Google Cloud Storage는 단순성과 경제성, 무한대에 가까운 확장성 덕분에 클라우드 배포를 위한 핵심 솔루션으로 많은 고객의 선택을 받고 있습니다. 그러나 수많은 프로젝트에서 수백 명의 개발자가 협업하여 수백만에서 수십억 개의 객체를 관리하는 작업은 상당히 복잡할 수 있으며, 분석팀이 데이터를 수동으로 분석하여 인사이트를 얻어야 하는 경우도 많습니다. 2024년 초 Google Cloud는 Cloud Storage를 위한 강력하고 새로운 스토리지 인사이트 생성 기능의 실험 버전을 소개한 바 있습니다. 가장 규모가 크고 성능이 뛰어난 AI 모델인 Gemini를 활용한 스토리지 인사이트 생성 기능을 사용하면 질문을 통해 Cloud Storage 환경에 대한 유용한 인사이트를 발견할 수 있습니다.

스토리지 인사이트 생성 기능의 이점

수동 데이터 분석 과정을 없애고 신속하게 답을 얻을 수 있습니다.
잠재적인 보안 및 규정 준수 위험을 사전에 발견할 수 있습니다.
비용 절감 기회를 파악하여 스토리지 비용을 최적화할 수 있습니다.

Google Cloud는 객체 메타데이터를 쿼리하고 대규모 언어 모델(LLM)을 사용하여 특정 환경에 맞는 스토리지 인사이트를 생성하는 최초의 하이퍼스케일 클라우드 제공업체입니다. Cloud Storage 객체 메타데이터에서 직접 생성된 이러한 AI 기반 인사이트는 수십억 개에 달하는 객체 규모에서도 새로운 차원의 제어와 이해를 가능하게 합니다. 이 블로그 게시물은 스토리지 인사이트 생성을 시작하는 방법을 제시하고, AI 어시스턴스가 스토리지 운영에 어떤 도움이 되는지 안내합니다.

Gemini로 스토리지 인사이트 생성

먼저 여러 Google Cloud 프로젝트와 BigQuery 연결 데이터 세트의 리전에 걸쳐 모든 객체 및 버킷 메타데이터를 수집하고 중앙화하는 새로운 기능인 Storage Insights 데이터 세트를 설정해야 합니다. 각 데이터 세트는 24시간마다 새로고침되며 최대 90일의 과거 데이터를 보관할 수 있습니다. 데이터 세트를 설정하는 동안 Gemini 옵션으로 인사이트 생성을 선택해야 합니다.

초기 설정이 끝나면 데이터 세트에 대한 간단한 요약이 포함된 고급 사용자 환경에 액세스할 수 있게 됩니다.

시작할 때 활용할 수 있도록 미리 선별하여 검증된 응답이 있는 프롬프트 조합이 제공됩니다. 이 프롬프트는 고객들이 가장 자주 묻는 질문을 바탕으로 선별되었습니다. 맞춤 프롬프트를 작성하기 위한 출발점으로 삼기에도 아주 좋습니다.

Google Cloud 콘솔 UI의 Storage Insights 시작 페이지

선별된 프롬프트 중 하나를 선택하면 검증된 응답이 표시됩니다. 응답은 차트로도 제공되어 복잡한 데이터를 명확한 시각적 표현으로 변환할 수 있으며, 이를 통해 주요 정보를 쉽게 이해하고 분석하며 팀끼리 공유할 수 있습니다.

Google Cloud 콘솔 UI의 Storage Insights 응답 페이지

또한 멀티턴 채팅을 사용하여 인사이트를 더 자세히 살펴보고 나만의 대화형 분석을 실행할 수 있습니다. 아래 예시는 수백만 개의 객체에 대한 메타데이터를 조합하여 자연어 프롬프트에 응답하는 것을 보여줍니다. 모든 응답에는 기본 쿼리가 함께 표시되며 클릭 한 번으로 BigQuery로 이동하여 쿼리를 편집하거나 수정할 수 있습니다.

Google Cloud 콘솔 UI의 Storage Insights 응답 페이지

신뢰성, 정확성, 안전성

생성형 AI의 강력한 기능에도 불구하고 가끔 할루시네이션이 발생할 수 있습니다. 따라서 Google Cloud는 생성된 답변을 평가하는 데 도움이 되는 여러 가지 정보 지표를 함께 제공해 드립니다. 모든 응답에는 간편한 검증을 위해 SQL 쿼리가 포함되며, 선별된 프롬프트에는 '높은 정확성' 태그가 표시되고, 데이터 최신 상태에 대한 유용한 정보가 제공됩니다. 좋아요/싫어요 아이콘을 사용하여 응답에 대한 의견을 공유할 수도 있습니다.

Google Cloud는 자연어를 적절한 SQL 쿼리로 변환하고, 데이터 세트를 쿼리하고, 응답을 요약하는 데 AI 모델을 사용합니다. 고객의 객체와 버킷 메타데이터는 전적으로 고객에게 귀속되며 Google Cloud의 AI 모델 학습에 사용되지 않습니다. 고객이 의견 옵션을 통해 공유하도록 선택하지 않는 한 고객의 프롬프트는 저장되지 않습니다. 데이터 세트에는 선택한 프로젝트를 기반으로 한 객체 및 버킷 메타데이터만 포함되며 객체 콘텐츠에는 액세스할 수 없습니다. 아울러 Google Cloud는 Google의 책임감 있는 AI 접근 방식을 통해 모델의 답변을 검증하고 콘텐츠의 안전성을 높입니다.

더 단순하고 쉬운 스토리지 관리

새로운 기능과 더불어 Cloud Storage는 규모에 맞게 스토리지를 더욱 쉽고 효율적으로 관리할 수 있는 종합적인 관리 기능을 제공합니다. Cloud Storage 고객이라면 지금 바로 Google Cloud 계정팀에 문의하여 Gemini를 통해 인사이트 생성을 시작해 보세요. 자세한 내용은 Google Cloud Next 2024의 ‘Managing Google Cloud Storage at Scale with Gemini(Gemini로 규모에 맞게 Cloud Storage 관리하기)’ 세션 녹화 동영상을 참조하세요.

블록 스토리지 성능을 훨씬 간단하게 계획하고 관리하는 방법

Mon, 17 Mar 2025 05:20:00 +0000

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

2024년 초 Google Cloud는 블록 스토리지 용량을 간편하게 관리하고 총소유비용(TCO)을 절감하는 데 도움이 되는 Hyperdisk Storage Pool의 고급 용량 정식 버전을 발표했습니다. 이제, 이와 동일한 수준의 혁신을 블록 스토리지 성능에 제공할 Hyperdisk Storage Pool의 고급 성능 유형을 소개합니다. 이제 애플리케이션이 데이터를 읽고 씀에 따라 Hyperdisk Storage Pool이 동적으로 할당하는 IOPS와 처리량을 종합적으로 프로비저닝하여 리소스 사용률을 높이고 성능 계획 및 관리를 대폭 간소화할 수 있습니다.

Google Cloud 콘솔에서 지금 바로 고급 성능 스토리지 풀을 시작할 수 있습니다. 고급 성능 스토리지 풀은 Google Cloud에서 제공하는 Hyperdisk 블록 스토리지 제품군의 일부로, 여기에서 자세히 알아보실 수 있습니다.

난제: 적절한 양의 성능 리소스 프로비저닝하기

많은 고객이 모든 블록 스토리지 성능 리소스를 활용하는 일과 워크로드를 성공적으로 처리하기 위해 필요한 리소스를 확보하는 일 사이에서 균형을 이루는 데 어려움을 느끼고 있습니다. 이러한 상황의 근본 원인은 '피크의 합'이라고도 하는 문제에서 찾을 수 있습니다. 고객은 워크로드의 성능이 저하되지 않게 하기 위해 그동안의 관찰을 바탕으로 블록 스토리지를 최대 성능으로 프로비저닝하는 경우가 많지만, 대부분의 경우 디스크가 소비하는 성능은 이보다 훨씬 적습니다. 이는 디스크의 성능 사용률이 만성적으로 낮다는 의미입니다. 이러한 현상은 아래와 같이 시각화할 수 있습니다.

고급 성능 스토리지 풀을 통해 40~50% 더 낮은 TCO 달성하기

Google Cloud는 이 문제를 해결하기 위해 Hyperdisk Storage Pool의 고급 성능 유형을 마련했습니다. 고급 성능 스토리지 풀을 사용하면 워크로드의 성공적인 처리와 높은 성능 사용률 사이에서 고민할 필요가 없습니다. Hyperdisk Storage Pool의 고급 성능 유형에서는 사용자가 성능을 종합적으로 프로비저닝하고, 스토리지 풀이 필요에 따라 풀 내 디스크 전반에 리소스를 지능적으로 배포합니다. 이때 디스크의 작동 방식을 변경하지 않아도 되므로 애플리케이션이 정상적으로 실행됩니다. 애플리케이션의 성공적인 실행이나 리소스 효율성을 타협하는 일 없이 간편하게 성능 니즈를 계획하고 TCO를 절감할 수 있습니다.

몇 가지 워크로드 예시를 통해 Hyperdisk Storage Pool의 고급 성능 유형으로 어떻게 TCO를 낮출 수 있는지 알아보겠습니다. 최대 25,000IOPS(예: 모든 사용자가 동시에 로그인할 경우)가 필요하지만 안정적인 상태에서는 10,000IOPS가 필요한 엔터프라이즈 애플리케이션 제품군과 최대 75,000IOPS(예: 분기 보고서 제출 마감일인 경우)가 필요하지만 안정적인 상태에서는 35,000IOPS가 필요한 데이터베이스 워크로드가 있다고 가정해 보겠습니다. 풀 외부에서 이러한 워크로드의 성능 사용률은 40~45%일 겁니다. 안정적인 상태에서의 성능은 프로비저닝된 성능의 절반 수준이기 때문입니다. 하지만 Hyperdisk Storage Pool 고급 성능 유형의 동적 리소스 할당을 사용하면 이러한 워크로드를 약 80%의 사용률로 실행할 수 있으며, 고객은 워크로드를 변경할 필요 없이 프로비저닝해야 하는 성능 리소스를 대폭 줄이고 TCO를 40~55% 절감할 수 있습니다.

블록 스토리지 성능 간소화 및 계획

고급 성능 스토리지 풀은 성능 리소스를 프로비저닝하는 방법을 근본적으로 혁신합니다. 지금까지 인프라 관리자는 낮은 사용률을 감수하고 성능을 최적화하는 방안과 애플리케이션 오류의 리스크를 감수하고 효율성을 최적화하는 방안 중 하나를 선택해야 했습니다. 즉, 각 볼륨의 성능을 적극적으로 관리하고 반복적인 관리 업무를 감당해야 했습니다.

Hyperdisk 고급 성능 스토리지 풀은 블록 스토리지 성능 관리를 간단하게 만들어 줍니다. 고급 성능 스토리지 풀의 디스크 IOPS와 처리량은 '씬 프로비저닝'됩니다. 다시 말해, 디스크 수준에서 성능을 프로비저닝할 때 리소스를 소비하지 않으며 풀에 풀 내 디스크의 최대 5배에 달하는 IOPS 및 처리량을 프로비저닝할 수 있습니다. 그러면 더 이상 각 디스크의 성능 니즈를 정확하게 예측할 필요가 없으므로 배포를 계획하기가 쉬워지며, 각 디스크에 할당된 IOPS와 처리량을 적극적으로 관리하지 않아도 되기 때문에 높은 효율성을 달성하게 됩니다. 필요한 만큼 높은 성능을 갖춘 디스크를 간단히 만들고, 필요할 때 고급 성능 스토리지 풀이 리소스를 할당하도록 할 수 있습니다.

고급 성능 스토리지 풀을 초기에 이용한 REWE 같은 고객은 그 가치를 직접 경험했습니다.

"REWE에서는 배포를 계획할 때 애플리케이션의 성능 급증을 예측해야 한다는 고충이 있었습니다. 스토리지 리소스의 성능 사용률을 적극적으로 관리하는 일은 더 어려웠죠. 고급 성능 스토리지 풀 덕분에 이 두 문제를 모두 해결할 수 있었습니다. 인프라에 고급 성능 풀을 도입하여 TCO와 반복 업무를 줄일 수 있게 되어 정말 후련합니다." – Jan Rundshagen, REWE 인프라 관리자

시작하기

Hyperdisk Storage Pool을 만드는 것과 동일한 워크플로를 통해 Hyperdisk 고급 성능 스토리지 풀을 시작할 수 있습니다. Google Cloud 콘솔에 로그인하고 Compute Engine으로 이동해 스토리지를 찾으세요. 그런 다음 스토리지 풀을 만들고 볼륨 유형(균형 또는 처리량)과 고급 성능을 선택하고 풀에 필요한 전체 용량과 성능을 설정합니다. 풀에 새 Hyperdisk 볼륨을 만드는 데에서 시작하면 기존 스토리지 풀처럼 풀의 용량을 공유하는 것은 물론 리소스 전반에 동적으로 성능을 공유할 수 있다는 또 다른 이점이 있습니다.

고급 성능 스토리지 풀을 통해 애플리케이션의 성능 효율성을 달성하고 관리하는 방식을 근본적으로 개선할 수 있기를 바랍니다. Hyperdisk 고급 성능 스토리지 풀은 현재 여러 리전과 영역에 출시되고 있습니다. 지금 바로 Google Cloud 콘솔에서 고급 성능 스토리지 풀 사용을 시작하거나 관련 문서에서 고급 성능 스토리지 풀을 만들고, 사용하고, 관리하는 방법을 자세히 알아보세요.

새로운 데이터 저장 리전 보장을 통한 전 세계 생성형 AI 혁신 가속화

Wed, 13 Dec 2023 01:00:00 +0000

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

엔터프라이즈 생성형 AI 서비스에 대한 수요가 전 세계적으로 증가하고 있습니다. 생성형 AI를 최대한 활용할 방법이 모색되는 한편, 데이터 주권과 글로벌 규제 요건이 강조되는 환경 속에서 많은 기업이 데이터가 저장되는 리전을 설정할 수 있기를 바라고 있습니다.

이러한 요청에 부응하여, Google Cloud의 생성형 AI 서비스를 사용하는 고객은 북미, 유럽, 아시아의 10개 국가 중 어느 곳이든 저장 데이터를 보관할 수 있게 되었습니다. 이번 발표는 고객을 위한 데이터 저장 리전을 확대하고 업계의 요구를 충족하기 위한 지속적인 노력의 일환입니다.

새로운 Vertex AI 데이터 저장 리전

Google Cloud는 Vertex AI 생성 기능에 대한 새로운 데이터 저장 리전 약정과 더불어 일반 서비스 약관에 따라 고객이 선택한 리전을 고객 데이터를 보관할 것을 약속합니다. 여기에는 구체적으로 다음 사항이 포함됩니다.

Text Embeddings API 및 Multimodal Embeddings API뿐만 아니라 PaLM2, Codey, Imagen 모델을 포함하는 Vertex AI의 생성형 AI는 고객에게 다음과 같은 데이터 저장 옵션을 제공합니다.
- 북미: 미국 및 캐나다
- 유럽: 네덜란드, 독일, 벨기에, 영국, 프랑스
- 아시아: 대한민국, 싱가포르, 일본
Vertex AI Search는 고객에게 다음과 같은 데이터 저장 옵션을 제공합니다.
- 북미: 미국(멀티 리전)
- 유럽: EU(멀티 리전)
Vertex AI Conversation은 고객에게 다음과 같은 데이터 저장 옵션을 제공합니다.
- 북미: 미국(멀티 리전)
- 유럽: EU(멀티 리전)

"Minna Bank는 Vertex AI에서 생성형 AI 서비스를 사용할 예정인데, 이는 PaLM2와 같은 생성형 AI 서비스와 관련해 Google Cloud가 제공하는 일본 내 데이터 저장 리전 약정 때문입니다. 이는 높은 수준의 개인 정보 보호, 보안, 거버넌스를 요구하는 금융 업계 및 기타 업종에 매우 중요한 변화였습니다. 이제 데이터 저장 리전을 제어할 수 있기 때문입니다." - Masaaki Miyamoto, Executive Officer & CIO, Minna Bank

앞으로 전 세계 더 많은 지역에서 Google Cloud 고객에게 데이터 리전 제어가 가능한 생성형 AI 기능을 제공할 수 있게 되길 기대합니다.

엔터프라이즈급 생성형 AI

새로운 데이터 리전 보장을 통해 엔터프라이즈급 규모, 안전, 보안, 개인 정보 보호를 갖춘 AI 서비스를 제공하기 위해 계속 노력할 것입니다. Google Cloud는 전 세계의 조직이 AI의 잠재력을 활용할 수 있도록 Google의 연구 성과를 제품에 적용하는 데 중요한 역할을 수행하고 있습니다.

고객 데이터 및 개인 정보 보호는 언제나 Google Cloud의 사명에서 핵심 역할을 해왔으며, AI가 계속 발전하고 점차 대규모로 채택되면서 이러한 노력은 그 어느 때보다 중요해졌습니다. 새로운 데이터 저장 리전 외에 고객 데이터 및 개인 정보 보호 처리 방식에 관한 주요 사실 몇 가지도 함께 알려드립니다.

고객은 자체 데이터와 모델을 제어하며 그에 대한 액세스도 제어합니다. 조직은 데이터와 모델에 액세스할 수 있는 사용자와 이러한 애셋을 사용할 수 있는 방식을 결정합니다.
고객은 데이터와 모델을 저장하는 리전과 방법을 제어합니다. 조직은 원하는 리전에 데이터를 저장하도록 선택하여 지정된 지리적 경계를 벗어난 배포를 방지할 수 있습니다.
Google은 고객 데이터를 절대 사용하지 않습니다. Google의 모델, 또는 다른 기업이 사용하는 모델을 훈련하는 데 고객 데이터를 무단으로 사용하지 않습니다.
고객 데이터는 필요할 때 언제든 사용할 수 있습니다. Google의 데이터 센터와 네트워크 아키텍처는 안정성과 복원력을 최대화하도록 설계되었으며, Google의 AI 제품은 다른 Google Cloud 서비스와 동일한 고가용성 표준을 따릅니다.
고객은 기본적으로 엔터프라이즈급 보안과 개인 정보 보호를 누릴 수 있습니다. Google Cloud의 AI 서비스를 사용하면 보안 관련 특정 요구 사항이나 규제 요건을 충족하기 위해 조직에서 데이터와 모델 전반에 걸쳐 개인 정보 보호와 세분화된 보안 제어를 적용할 수 있습니다.

또한 Google Cloud는 기술적 제어와 계약 약관, 업계에서 인정하는 인증과 감사를 통해 이러한 보장을 뒷받침합니다. 즉 조직이 Google의 AI 플랫폼에서 모델을 빌드하거나 조정할 때 Google은 위험 관리를 위한 공동의 운명 접근 방식을 채택하여 첫날부터 조직과 협력하며 데이터와 모델을 보호합니다. 이러한 노력에는 사이버 보안에 대한 협력적인 접근법과 함께 기업이 AI 관련 위험을 완화하기 위한 실질적인 고려 사항을 제공하는 보안 AI 프레임워크(SAIF) 개발이 포함됩니다.

Google Cloud는 데이터 저장 리전 약정을 계속 확대할 것으로 기대하며 더 많은 소식을 공유할 예정입니다. Google Cloud가 AI 서비스를 개발하는 방식에 대한 자세한 내용은 책임감 있는 AI 페이지를 참조하세요. Google의 AI 플랫폼에 대해 알아보려면 여기를 클릭하세요.

맞춤설정 가능한 모니터링 대시보드로 시스템 관측 가능성을 향상시키는 Cloud Storage

Mon, 02 Jan 2023 00:00:00 +0000

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

Google Cloud Storage는 비정형 데이터를 저장하고 사용자가 원하는 만큼 데이터를 가져올 수 있는 관리형 서비스입니다. Cloud Storage는 활용도가 높은 기본 서비스이기 때문에 스토리지 관측 가능성이 스토리지 엔지니어와 관리자의 일상적인 운영 업무에 매우 중요하며 비즈니스의 확장성과 지속 가능성을 위해서도 중요합니다.

스토리지 관측 가능성과 관련해 Cloud Storage 사용자들은 다음과 같은 질문을 합니다.

스토리지 프로젝트 및 버킷 관측을 시작하기 위한 권장사항은 무엇인가요?
문제를 사전에 식별하고 해결하기 위해 모니터링해야 할 가장 중요한 운영 측정항목/로그는 무엇인가요?
내가 관심을 두고 있는 스토리지 측정항목에 대한 알림을 만들려면 어떻게 하면 되나요? 스토리지 프로젝트 안에서 알림을 확인하거나 버킷에 대한 알림을 볼 수 있나요?

또한 사용자들은 여러 관측 가능성 도구를 오가야 하기 때문에 다양한 모니터링 플랫폼 간에 이동하는 동안 컨텍스트를 놓치는 경우가 많다고 말합니다.

오늘 Google에서는 프로젝트 수준과 버킷 수준 모두에서 사용할 수 있는 새로운 Cloud Storage용 모니터링 대시보드를 공개 미리보기 버전으로 출시한다는 기쁜 소식을 전해드립니다.

이제 모든 Cloud Storage 사용자가 왼쪽 탐색 메뉴에서 모니터링 탭을 통해 새 대시보드를 이용할 수 있습니다.

니즈에 따른 고도의 맞춤설정

Google은 모든 사용자의 니즈를 충족할 수 있는 단일 관측 가능성 도구란 없다는 사실을 잘 알고 있습니다. 사용자가 자신만의 대시보드 버전을 만들고 기본 뷰로 설정할 수 있도록 대시보드를 컨텍스트에 따라 맞춤설정할 수 있게 만든 이유가 바로 여기에 있습니다. 모니터링 편집자 또는 소유자 액세스 권한이나 프로젝트 편집자 또는 소유자 액세스 권한이 있다면 전에 만든 알림 정책에서 알림 차트를 추가하거나 즉시 사용 가능한 대시보드를 맞춤설정하여 알림을 만들 수 있습니다. 맞춤설정된 대시보드에 알림 차트를 추가하면 Cloud Storage 모니터링 페이지에서 컨텍스트별로 알림을 직접 확인할 수 있습니다. 또한 Google Cloud 콘솔의 스토리지 페이지를 벗어나지 않고도 대시보드에 여러 서비스의 측정항목을 추가하여 상관관계를 관측할 수 있습니다.

로그 패널에서는 관심을 두고 있는 가장 중요한 로그를 반영하도록 로그 뷰어 쿼리를 수정하고 해당 쿼리를 스토리지 프로젝트 맞춤설정 대시보드에서 유지할 수 있습니다. 동일한 대시보드에서 측정항목과 로그를 살펴볼 수 있어 컨텍스트 전환이 줄어들고 보다 효과적으로 문제를 해결할 수 있습니다.

맞춤설정 가능한 대시보드를 사용하면 플랫폼의 스토리지 페이지 내에서 문제 해결 과정을 수행할 수 있으므로 여러 모니터링 도구나 모니터링 플랫폼 간에 이동할 필요성이 줄어듭니다.

즉시 사용 가능한 운영 측정항목

스토리지 관측 가능성에는 여러 가지 측면이 있는데 새 모니터링 대시보드는 문제 해결에 초점을 맞추고 있습니다. 여기에는 모든 스토리지 사용자가 Google Cloud에서 스토리지 서비스를 시작할 때 자동으로 받게 되는 즉시 사용 가능한 스토리지 시스템 측정항목과 스토리지 시스템 로그가 포함됩니다.

Cloud Monitoring UI에서 차트 위로 마우스를 가져가 값을 읽거나 범례를 펼치고, 기간을 확대 또는 축소하여 데이터를 보다 상세하게 또는 간략하게 살펴보고, MQL 또는 PromQL 같은 고급 쿼리를 사용할 수 있습니다. 실제로 Google Cloud 콘솔의 스토리지 페이지 내에서 Cloud Monitoring 대시보드의 모든 기능을 사용할 수 있습니다.

대시보드에서 사용할 수 있는 차트와 로그 패널에 대해 자세히 살펴보도록 하겠습니다.

차트

Storage API 요청 수의 서버 오류율: 모든 서버 측 5xx 오류를 표시하도록 필터링합니다.

Storage API 요청 수의 클라이언트 오류율: 응답 코드를 포함해 모든 클라이언트 측 4xx 오류를 표시하도록 필터링합니다.

읽기 오류가 가장 많이 발생한 상위 5개 버킷: 응답 코드가 INTERNAL 및 UNAVAILABLE 오류인 List 및 Read 메서드로 필터링되며 상위 5개 버킷에서 측정됩니다. 이러한 오류가 발생한 버킷을 더 많이 표시하도록 차트를 손쉽게 맞춤설정할 수 있습니다.

쓰기 오류가 가장 많이 발생한 상위 5개 버킷: 읽기 오류가 가장 많이 발생하는 경우와 마찬가지로 이 차트는 응답 코드가 INTERNAL 및 UNAVAILABLE 오류인 WriteObject 메서드로 필터링됩니다.

총 Read/List/Get 요청 수: Read, List, Get 메서드의 API 요청 수로 필터링됩니다. 특정 시간 동안 이 3가지 메서드에 대해 발생한 총 요청 수와 API 메서드의 위치별로 분류한 총개수가 표시됩니다.

총 쓰기 요청 수: 모든 API 요청의 Write 메서드로 필터링되며 쓰기 요청의 총개수가 위치별로 분류되어 표시됩니다.

네트워크의 데이터 인그레스 속도: 수신 바이트 속도를 표시하여 프로젝트당 또는 버킷당 인그레스 속도를 쉽게 파악할 수 있습니다.

프로젝트의 총 수신 바이트 볼륨을 표시하도록 이 차트를 맞춤설정할 수 있습니다.
버킷 수준 대시보드에서는 프로젝트의 버킷당 인그레스 속도를 표시하도록 차트가 필터링됩니다.

네트워크의 데이터 이그레스 속도: 전송 바이트 속도를 표시하여 프로젝트당 또는 버킷당 이그레스 속도를 쉽게 파악할 수 있습니다.

로그 패널

GCS 로그 및 감사 로그 위젯

이 2가지 로그 위젯은 심각도가 오류와 같거나 큰 GCS 로그 및 GCS 감사 로그로 필터링됩니다. 심각도가 오류, 심각, 알림, 긴급에 해당하는 로그가 로그 패널에 표시됩니다.
위젯에서 로그 항목을 펼쳐 '로그 탐색기에서 보기' 버튼을 클릭하면 로그 탐색기 뷰로 쉽게 이동할 수 있습니다.

프로젝트 수준에서 사용할 수 있는 모든 차트가 버킷 수준에서도 제공되며 특정 버킷으로 대시보드가 필터링됩니다. 버킷 수준 대시보드의 맞춤설정이 생성되면 프로젝트 내의 모든 버킷 수준 대시보드에 맞춤설정된 버킷 수준 대시보드가 자동으로 표시됩니다. 간편하게 다른 버킷으로 이동하고 드롭다운 메뉴에서 맞춤설정된 대시보드를 선택해 확인할 수 있습니다.

지금 미리보기로 시작하기

Cloud Storage UI의 왼쪽 탐색 메뉴에서 모니터링 탭을 클릭하면 지금 바로 미리보기를 시작할 수 있습니다. 모든 Cloud Storage 사용자에게 미리보기가 제공됩니다.

이 대시보드를 모든 사용자에게 공개적으로 제공하게 된 것을 기쁘게 생각하며 여러분의 소중한 제안과 의견을 기다리겠습니다.

각 대시보드에서 '의견 보내기' 버튼을 사용하면 의견을 제출할 수 있습니다. 보내주신 모든 제안을 신중하게 검토하고 모든 사용자가 Cloud Storage 내에서 일상적인 운영을 분석하는 데 도움이 되도록 대시보드를 지속적으로 개선해 나가겠습니다.

정식 버전으로 제공되는 Cloud Spanner의 변경 내역

Wed, 17 Aug 2022 01:19:00 +0000

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

올해 Google Data Cloud Summit에서 Google은 Cloud Spanner 변경 내역을 발표했습니다. 오늘 변경 내역의 정식 버전이 출시된다는 반가운 소식을 전해드립니다. Spanner 사용자는 변경 내역을 사용하여 Cloud Spanner 데이터베이스의 변경사항(삽입, 업데이트, 삭제)을 거의 실시간으로 캡처하고 스트리밍할 수 있습니다.

변경 내역은 변경 데이터를 다른 Google Cloud 서비스와 통합할 수 있는 다양한 옵션을 제공합니다. 일반적인 사용 사례는 다음과 같습니다.

분석: 분석에 사용할 수 있는 최신 데이터가 BigQuery에 있도록 BigQuery에 변경 이벤트를 보냅니다.
이벤트 트리거링: 다운스트림 시스템에서 추가 처리를 위해 Pub/Sub에 데이터 변경 이벤트를 보냅니다.
규정 준수: 보관 목적으로 Google Cloud Storage에 변경 이벤트를 저장합니다.

변경 내역 시작하기

이 섹션에서는 변경 내역을 만들고, 변경 내역 데이터를 읽고, 분석을 위해 BigQuery로 데이터를 보내는 간단한 예시를 살펴봅니다.

아직 숙지하지 않은 경우 Spanner Qwiklab을 통해 Cloud Spanner에 대한 기본사항을 숙지하세요.

변경 내역 만들기

Spanner 변경 내역은 테이블 및 색인 생성 작업과 유사하게 DDL을 사용하여 생성됩니다. 변경 내역 DDL에는 다른 스키마 변경(spanner.databases.updateDdl)과 동일한 IAM 권한이 필요합니다.

변경 내역을 사용하면 열 집합, 테이블 집합 또는 전체 데이터베이스의 변경사항을 추적할 수 있습니다 각 변경 내역의 보관 기간은 1~7일이며, 여러 변경 내역을 설정하여 특정 목표에 필요한 변경사항을 정확하게 추적할 수 있습니다. 변경 내역 만들기 및 관리를 자세히 알아보세요.

다음과 같은 Orders라는 테이블이 있다고 가정해 보겠습니다.

code_block: <ListValue: [StructValue([('code', 'CREATE TABLE Orders (\r\nOrderID INT64 NOT NULL,\r\nCustomerID INT64 NOT NULL,\r\nProductId INT64 NOT NULL,\r\nOrderDate DATE,\r\nPrice INT64,\r\n) PRIMARY KEY(OrderID);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd89b07d890>)])]>

기본(암시적) 보관 기간이 1일인 전체 Orders 테이블을 추적하는 변경 내역을 만들기 위한 DDL은 다음과 같이 정의됩니다.

code_block: <ListValue: [StructValue([('code', 'CREATE CHANGE STREAM OrdersStream FOR Orders;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd8a86aead0>)])]>

변경 내역 만들기는 장기 실행 작업입니다. Cloud 콘솔의 변경 내역 페이지에서 진행 상황을 확인할 수 있습니다.

생성된 변경 내역의 이름을 클릭하면 추가 세부정보가 표시됩니다.

데이터베이스 DDL은 다음과 같이 나타납니다.

이제 변경 내역이 생성되었으므로 변경 내역 데이터를 처리할 수 있습니다.

데이터를 BigQuery로 스트리밍하기

여러 가지 방법으로 변경 내역 데이터를 처리할 수 있습니다. 가장 쉬운 방법은 Apache Beam용 Spanner 커넥터를 사용하는 것으로 이 방법을 통해 Google Cloud Dataflow를 위한 확장 가능한 데이터 처리 파이프라인을 빌드할 수 있습니다. 변경 데이터를 처리하고 BigQuery 또는 Google Cloud Storage에 각각 변경 데이터를 쓸 수 있는 Dataflow 템플릿이 제공됩니다. Cloud Spanner 변경 내역과 Dataflow의 작동 방식을 자세히 알아보세요.

이 예시에서는 BigQuery에 Spanner 변경 내역 작성 템플릿을 사용하여 변경 내역 데이터를 BigQuery에 씁니다.

먼저 Google Cloud 콘솔에서 Dataflow 작업 페이지로 이동합니다. '템플릿에서 작업 만들기'를 클릭하고 'BigQuery에 변경 내역 작성' 템플릿을 선택한 다음 필수 입력란을 작성합니다.

'작업 실행'을 클릭한 다음 Dataflow에서 파이프라인을 빌드하고 작업이 시작될 때까지 기다립니다. Dataflow 파이프라인이 실행되면 Dataflow 작업 페이지에서 작업 그래프, 실행 세부정보, 측정항목을 볼 수 있습니다.

이제 추적 대상인 Orders 테이블에 데이터를 작성해 보겠습니다.

Spanner가 변경 내역에서 추적하는 데이터 세트의 데이터 변경을 감지하면 동일한 트랜잭션 내에서 해당 데이터 변경과 동기화하는 방식으로 데이터 변경 레코드를 씁니다. Spanner는 이러한 쓰기를 모두 같은 위치에 배치하기 때문에 동일한 서버에서 처리되어 쓰기 처리가 최소화됩니다. Spanner가 변경 내역을 쓰고 저장하는 방법을 자세히 알아보세요.

마지막으로 BigQuery 데이터 세트를 보면 변경 내역 레코드에 대한 몇 가지 추가 정보와 함께 방금 삽입한 행이 표시됩니다.

준비가 완료되었습니다. Dataflow 파이프라인이 실행되는 한 추적 대상 테이블의 데이터 변경사항이 BigQuery 데이터 세트로 원활하게 스트리밍됩니다. 파이프라인 모니터링을 자세히 알아보세요.

변경 내역 데이터를 처리하는 다양한 방법

BigQuery 및 Google Cloud Storage용으로 Google에서 제공하는 Dataflow 템플릿을 사용하는 대신 커스텀 Dataflow 파이프라인을 빌드하여 Apache Beam으로 변경 데이터를 처리할 수 있습니다. 이 경우 DataChangeRecord 객체의 Apache Beam PCollection으로 변경 데이터를 출력하는 SpannerIO Dataflow 커넥터가 제공됩니다. 자체 데이터 변환을 정의하거나 BigQuery 또는 Google Cloud Storage와 다른 싱크가 필요한 경우에 적합합니다. 변경 내역 데이터를 소비 및 전달하는 커스텀 Dataflow 파이프라인을 만드는 방법을 자세히 알아보세요.

또는 Spanner API를 사용하여 변경 내역을 처리할 수 있습니다. 이 접근 방식은 특히 지연 시간에 민감한 애플리케이션에 적합하며 Dataflow에 의존하지 않습니다. Spanner API는 변경 내역에서 직접 읽고 자체 커넥터를 구현하며 선택한 파이프라인으로 변경사항을 스트리밍할 수 있는 강력한 인터페이스입니다. Spanner API를 사용하면 변경 내역이 여러 파티션으로 나뉘며, 각 파티션을 사용하여 변경 내역의 쿼리를 병렬로 실행해 처리량을 높일 수 있습니다. Spanner는 부하 및 크기를 기반으로 이러한 파티션을 동적으로 생성합니다. 각 파티션은 Spanner 데이터베이스 분할과 연결되어 변경 내역이 Spanner의 다른 부분처럼 간편하게 확장될 수 있습니다. 변경 내역 쿼리 API 사용 방법을 자세히 알아보세요.

다음 단계

이제 모든 고객이 추가 비용 없이 Spanner 변경 내역을 사용할 수 있습니다. 일반 Spanner 요율에 따라 변경 스트림 데이터의 추가 컴퓨팅 및 저장에 대해서만 비용을 지불하면 됩니다. 변경 내역이 Spanner에 내장되어 있기 때문에 소프트웨어를 설치할 필요가 없으며, 외부 일관성 및 업계 최고의 가용성을 누릴 수 있을 뿐만 아니라 데이터베이스의 다른 부분과도 쉽게 확장할 수 있습니다.

지금 변경 내역 개요에서 변경 내역에 대해 살펴보세요.

Open Saves 소개: 게임용 오픈소스 클라우드 기반 스토리지

Mon, 02 Aug 2021 02:52:00 +0000

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

오늘날 게이머가 지속적인 스토리라인의 일부가 되는 방식으로 참여할 수 있는 풍부한 몰입형 환경을 제공하는 게임이 많습니다. 이러한 지속적인 경험을 선사하기 위해서는 게임 데이터가 게이머의 요구에 맞게 확장될 수 있도록 수많은 스토리지 기술이 필요합니다. 게임 개발자는 저장, 인벤토리, 패치, 다시보기와 같은 다양한 유형의 데이터를 저장해야 할 뿐만 아니라 스토리지 시스템의 고성능, 가용성, 확장성, 비용 효율성을 유지해야 합니다.

Google이 2K와 협력하여 개발한 Google Cloud 기반의 Open Saves는 여러 스토리지 백엔드에서 사용할 수 있도록 특별히 제작된 새로운 단일 인터페이스입니다. 이제 개발팀은 Cloud Storage, Memorystore 또는 Firestore 등 사용할 스토리지 솔루션에 대한 기술적 결정을 내리지 않고도 게임 데이터를 저장할 수 있습니다.

“Open Saves는 심층적인 업계 지식과 Google의 규모가 모두 필요한 게임 솔루션 분야에서 최고의 개발자와 협업하려는 당사의 의지를 잘 보여주는 결과물입니다."라고 2K IT 및 보안 부문의 조 가르폴라 부사장은 말했으며 "Google Cloud와의 지속적인 협업을 기대합니다.”라고 덧붙였습니다.

게임 개발팀은 최적의 백엔드 스토리지 솔루션에 대한 걱정 없이 Open Saves에서 게임 데이터를 저장할 수 있으며 운영팀 역시 필요한 확장성과 스토리지 옵션에 집중할 수 있습니다. 실제 작동 방식은 다음과 같습니다.

게임 개발자는 Open Saves를 사용하여 다음과 같은 특성의 클라우드 기반 게임 스토리지 시스템을 실행할 수 있습니다.

단순성: Open Saves는 메타데이터, 구조화된 객체, 구조화되지 않은 객체의 모든 작업에 사용할 수 있는 적절하게 정의된 통합 gRPC 엔드포인트를 제공합니다.
속도: Open Saves는 기본 제공되는 캐싱 시스템을 통해 데이터 배치를 빈도 및 데이터 크기에 따라 최적화하여 소형 바이너리 객체에 대해서는 지연 시간을 단축하고 대형 객체에 대해서는 높은 처리량을 달성합니다.
확장성: Open Saves API 서버는 Google Kubernetes Engine 또는 Cloud Run에서 실행할 수 있습니다. 두 플랫폼 모두 초당 수십만 개의 요청을 처리하도록 확장할 수 있습니다. 또한 Open Saves는 Firestore 및 Cloud Storage에 데이터를 저장하며 수백 기가바이트의 데이터와 초당 최대 수백만 개의 요청을 처리할 수 있습니다.

Open Saves는 확장성을 염두에 두고 설계되었으며 온프레미스부터 클라우드 또는 하이브리드에 이르는 모든 인프라에서 실행되어 모바일, 콘솔, 멀티플레이어, 싱글플레이어 등 어떤 게임과도 통합될 수 있습니다. 이 서버는 Go로 작성되었지만 API를 gRPC로 정의하기 때문에 다양한 프로그래밍 언어를 사용해 클라이언트나 서버에서 연결할 수 있습니다.

다음 코드에서 볼 수 있듯이 Open Saves에 쓰기 및 읽기가 매우 간단합니다.

code_block: <ListValue: [StructValue([('code', '// To write\r\n record := &pb.Record{\r\n Key: uuid.New().String(),\r\n Tags: []string{"tag1", "tag2"},\r\n OwnerId: "owner",\r\n }\r\n createReq := &pb.CreateRecordRequest{\r\n StoreKey: storeKey,\r\n Record: record,\r\n }\r\n _, err := client.CreateRecord(ctx, createReq)\r\n if err != nil {\r\n t.Fatalf("CreateRecord failed: %v", err)\r\n }\r\n \r\n // To read\r\n getReq := &pb.GetRecordRequest{StoreKey: storeKey, Key: recordKey}\r\n response, err := client.GetRecord(ctx, getReq)\r\n if err != nil {\r\n t.Errorf("GetRecord failed: %v", err)\r\n }'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd8a9d00d90>)])]>

Google은 2K Games와 협업하여 Open Saves를 활발하게 개발 중이며 GitHub에서 여러분의 참여를 기다리고 있습니다. 참여하는 방법에는 몇 가지가 있습니다.

Open Saves 서비스 설치 및 배포
API 참조 확인
개발 가이드를 읽고 참여
open-saves-discuss 메일링 리스트 가입

Colossus 심층 분석: Google의 확장 가능한 스토리지 시스템 간단히 알아보기

Mon, 28 Jun 2021 01:33:00 +0000

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

Google Cloud를 믿고 중요한 데이터를 맡기는 고객은 많지만 Google의 다른 비즈니스도 동일한 스토리지 인프라를 기반으로 운영된다는 사실을 아는 고객은 많지 않습니다. 사실은 Google Cloud를 구동하는 스토리지 시스템이 YouTube, Drive, Gmail처럼 전 세계에 서비스되는 Google의 가장 유명한 제품도 동일하게 지원하고 있습니다.

바로 그 기반이 되는 스토리지 시스템인 Colossus는 Cloud Storage 및 Firestore 같은 Google의 광범위한 스토리지 서비스 생태계를 뒷받침하고 트랜잭션 처리, 데이터 제공, 분석 및 보관처리, 부팅 디스크, 홈 디렉터리 같은 다양한 워크로드를 지원하는 역할을 합니다.

이 게시물에서는 Colossus 파일 시스템을 중심으로 VM 이면의 스토리지 인프라는 어떤 모습이고 고객 애플리케이션과 Google 서비스에 높은 확장성과 데이터 내구성을 더하는 데 어떤 도움이 되는지 보다 심도 있게 살펴봅니다.

Google 규모의 확장성을 그대로 발휘하는 Google Cloud

스토리지 서비스 운영 방식을 자세히 살펴보기에 앞서 Cloud와 Google 제품을 둘 다 지원하는 하나의 인프라를 이해하는 것이 중요합니다. 우수한 설계를 갖춘 소프트웨어 시스템이 보통 그렇듯 모든 Google 서비스에는 확장 가능한 서비스 집합이 공통적으로 계층화되어 있습니다. Google의 각 스토리지 서비스에는 다음과 같은 3가지 주요 구성 요소가 사용됩니다.

Colossus: Google File System(GFS)의 뒤를 잇는 Google의 클러스터 수준 파일 시스템입니다.
Spanner: 전역 일관성 및 확장성을 갖춘 관계형 데이터베이스입니다.
Borg: 컴퓨팅부터 스토리지 서비스에 이르는 모든 것을 실행하는 확장 가능한 작업 스케줄러입니다. 지금까지는 물론 앞으로도 Kubernetes의 설계 및 개발에 큰 영향을 미칠 것입니다.

이러한 3가지 핵심 구성 요소가 Firestore부터 Cloud SQL, Filestore, Cloud Storage에 이르는 모든 Google Cloud 스토리지 서비스의 기반 인프라를 구성합니다. 즐겨 찾는 스토리지 서비스에 액세스할 때마다 이와 같은 3가지 구성 요소가 함께 작동하여 필요한 모든 것을 제공해 줍니다. Borg는 필요한 리소스를 프로비저닝하고, Spanner는 액세스 권한과 데이터 위치에 대한 모든 메타데이터를 저장하며, Colossus는 모든 데이터를 관리 및 저장하고 그에 대한 액세스를 제공합니다.

Google Cloud에서도 이러한 구성 요소가 동일하게 사용되며 스토리지 서비스에 요구되는 가용성, 성능, 내구성 수준을 제공하는 데 필요한 모든 것을 계층화합니다. 다시 말해 이러한 3가지 서비스를 기반으로 고객의 니즈에 맞게 확장되는 동일한 핵심 인프라를 활용하기 때문에 고객의 애플리케이션 역시 Google 제품과 동일한 확장성을 갖추게 됩니다.

Colossus 요약 정보

이제 Colossus의 작동 방식을 보다 자세히 살펴보겠습니다.

먼저 Colossus에 관한 간략한 배경 정보는 다음과 같습니다.

차세대 GFS입니다.
스토리지 확장성을 개선하고 가용성을 높여 점점 많아지는 애플리케이션에서 폭발적으로 증가하는 데이터 니즈를 처리하도록 설계되었습니다.
Colossus는 분산형 메타데이터 모델을 도입하여 확장성 및 가용성이 높은 메타데이터 하위 시스템을 제공했습니다.

그렇다면 이 시스템은 어떻게 작동하는 걸까요? 어떻게 이 하나의 파일 시스템이 광범위한 워크로드를 지원할 수 있을까요? 아래는 Colossus 제어 영역의 핵심 구성요소를 나타낸 다이어그램입니다.

클라이언트 라이브러리

클라이언트 라이브러리는 애플리케이션이나 서비스가 Colossus와 상호작용하는 수단이 됩니다. 클라이언트는 아마도 전체 파일 시스템에서 가장 복잡한 부분일 것입니다. 소프트웨어 RAID를 비롯한 많은 기능이 애플리케이션의 요구사항을 바탕으로 클라이언트를 구성합니다. Colossus를 기반으로 설계된 애플리케이션은 다양한 인코딩으로 서로 다른 워크로드의 성능과 비용을 미세 조정하여 절충점을 찾습니다.

Colossus 제어 영역

Colossus는 수많은 큐레이터로 구성된 확장 가능한 메타데이터 서비스를 기반으로 합니다. 클라이언트는 파일 생성과 같은 제어 작업을 큐레이터에 직접 전달하고 수평으로 확장할 수 있습니다.

메타데이터 데이터베이스

큐레이터는 Google의 고성능 NoSQL 데이터베이스인 BigTable에 파일 시스템 메타데이터를 저장합니다. 처음에 Colossus를 구축하게 된 계기는 Google File System(GFS)에서 검색과 관련된 메타데이터를 수용하려고 할 때 확장 한도가 발생하는 문제를 해결하기 위해서였습니다. BigTable에 파일 메타데이터를 저장한 덕분에 Colossus는 최대 규모의 GFS 클러스터에서 100배 넘게 수직 확장할 수 있게 되었습니다.

D 파일 서버

Colossus는 네트워크에 있는 데이터 홉 수를 최소화합니다. 데이터는 클라이언트와 'D' 파일 서버(Google의 네트워크 연결 디스크) 사이를 바로 통과합니다.

Custodians

Colossus에는 Custodians라는 백그라운드 스토리지 관리자도 포함됩니다. 이 도구는 전반적인 효율성은 물론 데이터의 내구성과 가용성을 유지하는 데 핵심적인 역할을 하며 디스크 공간 균형과 RAID 재구성 같은 작업을 처리합니다.

Colossus에서 안정적이고 확장 가능한 스토리지를 제공하는 방식

이 모든 요소가 실제로 작동하는 방식을 살펴보기 위해 Cloud Storage에서 Colossus가 사용되는 방식을 생각해 보겠습니다. 아카이브 스토리지부터 처리량이 높은 분석에 이르기까지 Cloud Storage의 광범위한 사용 사례는 익히 들어 잘 알고 있지만 그 기반이 되는 시스템에 대해서는 알려진 이야기가 많지 않습니다.

Colossus를 사용하면 하나의 클러스터를 엑사바이트 규모의 스토리지와 수만 개의 머신으로 확장할 수 있습니다. 예를 들어 위의 예시에서는 Compute Engine VM, YouTube 제공 노드, Ads 맵리듀스 노드에서 Cloud Storage에 액세스하고 이 모든 노드가 동일한 기반 파일 시스템을 공유하여 요청을 완료하고 있습니다. 이를 위해서는 반드시 공유 스토리지 풀을 Colossus 제어 영역으로 관리해 분리된 자체 파일 시스템을 갖춘 것 같은 효과를 내야 합니다.

리소스를 분할하면 소중한 리소스를 보다 효율적으로 사용하고 모든 워크로드의 비용을 낮출 수 있습니다. 예를 들어 YouTube 동영상처럼 지연 시간이 짧은 워크로드의 최대 수요에 맞춰 프로비저닝한 다음 유휴 시간으로 낭비될 수 있는 공간을 채워 보다 저렴한 비용으로 일괄 분석 워크로드를 실행하는 것이 가능합니다.

Colossus를 통해 얻을 수 있는 몇 가지 다른 이점도 살펴보겠습니다.

하드웨어 복잡성 간소화

쉽게 예상할 수 있듯이, Google 서비스를 지원하는 파일 시스템은 수 테라바이트에 달하는 파일과 방대한 데이터 세트를 처리해야 하기 때문에 버거울 정도로 높은 처리량과 확장성을 갖춰야 합니다. Colossus는 많은 물리적 하드웨어 복잡성을 추상화하여 스토리지를 많이 소모하는 애플리케이션의 과부하 가능성을 방지합니다.

Google 데이터 센터는 기본 스토리지 하드웨어를 매우 다양하게 갖추고 있어 여러 규모와 유형의 회전 디스크와 플래시 스토리지 조합을 제공합니다. 그뿐만 아니라 애플리케이션별로 내구성, 가용성, 지연 시간에 대한 요구사항이 극단적으로 다르기 때문에 Colossus는 각 애플리케이션이 필요한 스토리지를 갖출 수 있도록 다양한 서비스 등급을 제공합니다. 애플리케이션은 I/O, 가용성, 내구성 요구사항을 지정한 후 추상화되어 통일된 단위로 리소스(바이트 및 I/O)를 프로비저닝하는 방법으로 이러한 다양한 등급을 사용합니다.

또한 Google 규모에서는 하드웨어 장애가 사실상 늘 발생합니다. 안정성이 부족해서가 아니라 하드웨어 수가 많기 때문입니다. 이처럼 거대한 운영 환경에서는 장애가 자연스러운 현상이기 때문에 파일 시스템에서 필수적으로 내결함성과 투명한 복구를 제공해야 합니다. Colossus는 이러한 장애를 중심으로 I/O를 조정하고 신속하게 백그라운드 복구를 진행하여 내구성과 가용성이 높은 스토리지를 제공합니다.

결과적으로 하드웨어 리소스를 처리해야 하는 복잡한 문제가 발생할 가능성이 크게 줄어 모든 애플리케이션이 쉽게 필요한 스토리지를 확보하고 사용할 수 있게 됩니다.

스토리지 효율성 극대화

알다시피 오늘날 오버프로비저닝 없이 애플리케이션에서 필요로 하는 스토리지 리소스를 제때 제공할 수 있으려면 마법과 같은 관리 기술이 필요합니다. Colossus는 액세스 패턴과 빈도(예: 자주 액세스되는 핫 데이터)가 데이터마다 다르다는 사실을 활용하여 필요에 따라 플래시와 디스크 스토리지를 조합해 사용합니다.

사용률이 가장 높은 데이터는 제공 효율성 향상 및 지연 시간 단축을 위해 플래시에 저장합니다. 기가바이트당 I/O 밀도를 디스크에서 일반적으로 제공 가능한 수준에 맞출 수 있을 정도로만 플래시를 구매하고 충분한 용량을 확보할 정도로만 디스크를 구매합니다. 적절한 조합을 통해 스토리지 효율성을 극대화하고 불필요한 오버프로비저닝을 피할 수 있습니다.

디스크 기반 스토리지의 경우에는 인벤토리 초과 및 디스크 IOPS 낭비를 피하기 위해 디스크를 채워진 상태로 상시 사용하려고 합니다. 이를 위해 Colossus는 가용 디스크 IOPS에서 최대한의 가치를 얻기 위해 지능형 디스크 관리를 사용합니다. 새로 작성된 데이터(예: 사용률이 높은 데이터)는 클러스터의 모든 드라이브에 균등하게 분산됩니다. 데이터의 분포는 재조정되며 시간이 지나고 사용률이 낮아지면 더 큰 용량의 드라이브로 이동합니다. 이 방식은 일반적으로 시간 경과에 따라 데이터의 사용률이 떨어지는 분석 워크로드에 적합합니다.

철저한 현장 검증을 거친 높은 확장성

이처럼 Colossus는 Google의 스토리지 인프라를 비밀스럽게 떠받치고 있는 뛰어난 확장 기능입니다. Colossus는 Google Cloud 서비스의 스토리지 니즈를 처리할 뿐 아니라 Google 내부 스토리지 니즈에 따른 스토리지 용량을 제공하며 매일 검색, 지도, YouTube 등을 이용하는 수십억 명의 사용자에게 콘텐츠를 전달하는 과정을 돕고 있습니다. Google Cloud를 기반으로 비즈니스를 구축하면 Google 서비스를 지원하는 것과 동일한 최고급 인프라를 이용하게 됩니다. 물론 지속적인 인프라 개선 작업도 Google이 담당하므로 걱정할 필요가 없습니다.

Google Cloud의 스토리지 아키텍처에 대해 보다 자세히 알아보려면 이 게시물의 기반이 된 'VM 이면의 Google Storage 인프라 간단히 살펴보기'라는 Next ‘20 세션을 확인해 보시기 바랍니다. 또한 Google의 모든 스토리지 제품군을 자세히 알아보려면 클라우드 스토리지 웹사이트를 방문하세요.

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

선택의 자유: Compute Engine VM에서 9TB SSD로 얻는 최고의 비용당 IOPS

Wed, 24 Mar 2021 00:00:00 +0000

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

지연 시간이 짧은 I/O 집약적 작업을 수행하는 애플리케이션은 컴퓨팅과 긴밀하게 결합된 고성능 스토리지를 갖춘 가상 머신에서 실행해야 합니다. 실시간 분석, 전자상거래, 게임, 소셜 미디어, 광고 플랫폼을 기반으로 한 애플리케이션이라면 더욱더 그러합니다. Compute Engine의 커스텀 머신 유형을 사용하면 고성능 로컬 SSD에 연결할 수 있을 뿐 아니라, 워크로드의 정확한 요구사항에 맞게 VM을 맞춤설정할 수 있는 유연성이 확보됩니다.

오늘 Google Cloud는 6TB 및 9TB 로컬 SSD를 2세대 범용 N2 Compute Engine VM에 연결하여 비용당 우수한 IOPS를 달성할 수 있다는 소식을 발표하게 되어 기쁩니다. 9TB 로컬 SSD는 24개 이상의 vCPU를 사용하는 모든 N2 VM에서 직접 연결 지연 시간으로 최대 240만 개의 IOPS와 9.4GB/초의 처리량을 제공합니다. 이 SSD는 모든 N2 VM 형태(커스텀 형태 포함)에 연결할 수 있기 때문에 애플리케이션에 필요한 CPU, RAM, SSD를 정확히 갖춘 VM을 정의할 수 있습니다. I/O 집약적 또는 스토리지 집약적인 워크로드에서 요구하는 것 이상으로 CPU와 메모리를 연결할 필요가 없어 특히 비용당 IOPS나 비용당 밀도 또는 둘의 조합을 최적화할 수 있습니다.

면책조항: Google Cloud 내부 벤치마킹을 기반으로 한 결과입니다.

더 적은 vCPU로 스토리지 성능 극대화

지금까지는 6TB 및 9TB 로컬 SSD를 N1 VM에 사용하여 32개 이상의 vCPU로 최대 240만 개의 IOPS를 달성할 수 있었습니다. N2 VM을 사용하면 24개의 vCPU만으로 동일한 성능을 얻을 수 있습니다. 즉, N2 VM을 사용하면 N1 VM에 비해 총 소유 비용이 7% 개선되는 것입니다.

다양한 I/O 큐 깊이 또는 블록 크기에서 성능을 최적화할 수 있는 유연성을 제공하는 애플리케이션도 있습니다. FIO와 같은 성능 벤치마킹 도구를 사용하면 최선의 선택을 하는 데 도움이 될 수 있습니다. 아래에서 볼 수 있듯이 내부 테스트 결과 로컬 SSD는 워크로드에 요구될 수 있는 광범위한 구성에서 일관된 성능을 제공합니다.

면책조항: Google Cloud 내부 벤치마킹을 기반으로 한 결과입니다.

최대 처리량

로컬 SSD를 VM에 연결하는 것은 높은 스토리지 처리량을 요하는 워크로드에도 좋은 전략입니다. 아래 차트에서 보다시피 로컬 SSD는 데이터베이스 및 애플리케이션 요구사항에 따라 다양한 블록 크기(4K, 16K, 128K)와 I/O 깊이에서 거의 최대치에 가까운 처리량을 제공할 수 있습니다.

면책조항: Google Cloud 내부 벤치마킹을 기반으로 한 결과입니다.

지금 시작하기

로컬 SSD 가격은 연결되는 VM과 상관없이 GB 단위로 책정됩니다. 리전별 가격을 확인하려면 가격 책정 페이지를 방문하세요. 6TB 및 9TB 로컬 SSD가 이제 N2 및 N2D VM 모두에서 정식 버전으로 제공됩니다. 자세한 내용은 로컬 SSD 문서를 참조하세요. 질문이나 의견이 있다면 지원 받기 페이지를 확인하세요.

Cloud Storage에서 99.999999999% 내구성을 제공하는 방법과 도움이 되는 권장사항

Wed, 10 Mar 2021 00:00:00 +0000

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

스토리지 솔루션의 가장 기본은 내구성으로 데이터가 손실이나 손상으로부터 얼마나 잘 보호되는지를 나타냅니다. 클라우드 환경에서는 이 내구성이 특히 중요하게 느껴질 수 있습니다. Cloud Storage는 최소 99.999999999%의 연간 내구성(9가 11개)을 갖추도록 설계되었으므로 100년의 시간이 지난다고 해도 10억 개의 객체 중 하나라도 손실되는 일이 없을 것입니다.

Google은 내구성 목표 달성을 매우 중요하게 생각합니다. 이 게시물에서는 Cloud Storage 데이터를 보호하는 주요 방법을 살펴봅니다. 이와 동시에 데이터 보호는 궁극적으로 모두의 책임이므로(데이터 손실의 가장 일반적인 원인은 사용자 또는 스토리지 관리자가 실수로 삭제하는 경우임) 자연재해, 사용자 오류와 같은 위험으로부터 데이터를 보호하는 데 도움이 되는 권장사항을 소개합니다.

물리적 내구성

대부분의 사람은 내구성이라고 하면 네트워크, 서버, 스토리지 하드웨어 장애로부터 데이터를 보호하는 상황을 떠올립니다.

궁극적으로 하드웨어 장애로부터 데이터를 보호하는 가장 좋은 방법은 소프트웨어라는 Google의 철학에 따라 생소한 하드웨어 솔루션에 의존하지 않고 경제적인 비용으로 더 높은 안정성을 확보할 수 있습니다. 하드웨어 장애는 언제든지 일어날 수 있다고 가정하고 있고 실제로도 그렇지만 이로 인해 내구성이 저하되어서는 안 됩니다.

객체를 Cloud Storage에 저장하기 위해 수많은 ‘데이터 청크’로 나눈 다음 각기 다른 전원을 사용하는 여러 서버에 저장합니다. 또한, 중복성을 위해 많은 ‘코드 청크’도 만듭니다. 하드웨어(예: 서버, 디스크) 장애가 발생하면 이 데이터 청크와 코드 청크를 사용하여 전체 객체를 재구성하는데, 이러한 기법을 이레이저 코드(Erasure Code)이라고 합니다. 게다가 객체를 찾고 읽는 데 필요한 메타데이터 사본을 여러 개 저장하므로 하나 이상의 메타데이터 서버에서 장애가 발생해도 해당 객체에 계속 액세스할 수 있습니다.

이때 중요한 점은 데이터를 항상 여러 가용성 영역에 중복 저장해야만 쓰기 작업이 성공한 것으로 확인된다는 것입니다. Google에서 사용하는 인코딩은 하드웨어 장애 시 99.999999999% 이상의 내구성 목표를 지원하기에 충분한 중복성을 제공합니다. 데이터가 저장되면 정기적으로 체크섬을 검증하여 저장 데이터를 특정 유형의 데이터 오류로부터 보호하고 체크섬이 일치하지 않는 경우에는 인코딩의 중복성을 이용하여 데이터가 자동으로 복구됩니다.

권장사항: 이중 리전 또는 멀티 리전 위치 사용

물리적 내구성 위험 요소에 대비한 이러한 보호 레이어가 잘 구현되어 있지만 이것으로 리전의 상당한 물리적 파괴(예: 전쟁이나 소행성 충돌, 기타 대형 재해)에 대해 데이터를 보호할 수는 없습니다.

Cloud Storage의 99.999999999% 내구성 목표는 리전 하나하나에 적용됩니다. 전체 리전을 완전히 파괴할 수 있는 자연재해로부터 보호하려면 가장 중요한 데이터를 이중 리전 또는 멀티 리전 버킷에 저장하는 것이 좋습니다. 이러한 버킷은 여러 지리적 리전에 저장되어 있으므로 데이터 중복성이 저절로 보장됩니다. 이 위치 유형에서는 버킷을 사용하기 위해 애플리케이션을 추가 구성하거나 API를 변경할 필요가 없으며 매우 드물지만 치명적인 결과를 초래할 수 있는 이벤트 발생 시 더욱 향상된 내구성을 제공합니다. 뿐만 아니라 이 위치 유형은 일시적으로 리전에 액세스할 수 없는 경우에도 둘 이상의 위치에서 객체를 투명하게 제공할 수 있기 때문에 높은 수준의 가용성 SLA를 지원합니다.

전송 중 내구성

또 다른 내구성 위험 요소로 전송 중 데이터의 손상이 있습니다. Cloud Storage 자체 서비스 내의 네트워크를 통해 전송되거나 Cloud Storage에 객체를 업로드하거나 다운로드할 때 전송되는 데이터가 여기에 해당할 수 있습니다.

이러한 손상을 원천적으로 방지하기 위해 Cloud Storage 내에서 전송 중 데이터는 예외 없이 항상 체크섬으로 보호되도록 설계되었습니다. 체크섬 검증 오류가 발생하면 상황에 따라 요청을 자동으로 재시도하거나 오류가 반환됩니다.
권장사항: 업로드 및 다운로드에 체크섬 사용
Google Cloud에서는 Google 서비스 내에서 이동하는 모든 Cloud Storage 객체에 체크섬이 적용되지만 엔드 투 엔드 보호를 실현하기 위해 데이터를 Cloud Storage에 업로드할 때는 체크섬을 제공하고 객체를 다운로드할 때는 클라이언트에서 이 체크섬을 검증하는 것이 좋습니다.

사람으로 인한 내구성 리스크

서비스 개발자와 운영자 또는 Cloud Storage 사용자의 실수 등 사람이 저지르는 실수가 데이터 손실을 유발하는 가장 큰 위험 요소로 알려져 있습니다.

데이터 내구성을 위협하는 가장 큰 단일 위험 요소는 소프트웨어 버그일 수 있습니다. 소프트웨어 버그로 인한 내구성 손실을 방지하기 위해 Google은 처음부터 데이터를 손상시키거나 데이터를 지울 수 있는 버그를 피하는 조치를 취합니다. 그런 다음 이러한 유형의 버그를 신속하게 감지하는 보호 장치를 유지하여 내구성 저하가 내구성 손실로 이어지기 전에 이를 포착하려고 합니다.

버그를 사전에 포착하기 위해 대규모 통합 테스트를 통과한 후에만 새로운 Cloud Storage 버전을 프로덕션 환경에 배포됩니다. 가용성 영역의 작동 중지와 같이 다양하고 극단적인 장애 시나리오를 연습하고 데이터 인코딩 및 배치 API의 동작을 이전 버전과 비교하여 회귀를 검사하는 등의 테스트를 거치게 됩니다.

새 소프트웨어 출시가 승인되면 가용성 영역에 따라 매우 제한적으로 영향을 받는 초기 영역을 시작으로 보편화될 때까지 서서히 대상을 확대해 가는 단계별 업그레이드를 수행합니다. 이렇게 하면 버그가 큰 영향을 미치기 전에, 필요할 경우 복구에 사용할 데이터 사본(또는 충분한 수의 이레이저 코드 청크)이 있는 상태에서 문제를 포착할 수 있습니다. 이러한 방식의 소프트웨어 출시는 필요한 경우 빠르게 롤백할 수 있도록 마련된 계획에 따라 면밀히 모니터링됩니다.

이 외에도 데이터가 손실되지 않도록 보호하기 위한 다음과 같은 다양한 권장사항이 있습니다.

권장사항: 객체 버전 관리 사용 설정

데이터 손실을 유발하는 가장 일반적인 원인 중 하나는 스토리지 관리자 또는 최종 사용자가 실수로 데이터를 삭제하는 것입니다. 객체 버전 관리를 사용 설정하면 나중에 복원해야 하는 경우에 대비해 삭제된 객체가 Cloud Storage에 보관됩니다. 객체 수명 주기 관리 정책을 구성하면 버전 관리된 객체가 영구 삭제되기 전까지 보존되는 기간을 제한하여 스토리지 비용을 효과적으로 제어할 수 있습니다.

권장사항: 데이터 백업

Cloud Storage에서 99.999999999%의 내구성 목표가 실현된다고 해서 데이터를 백업할 필요가 없는 것은 아닙니다. 예를 들어 악성 해커가 내 Cloud Storage 계정의 액세스 권한을 손에 넣는다면 어떤 일들이 일어날 수 있는지 생각해 보세요. 목표에 따라 예비 데이터 사본을 다른 리전이나 클라우드 또는 온프레미스에 백업해 두거나 에어 갭을 통해 테이프 또는 디스크에 물리적으로 분리하여 백업해 둘 수 있습니다.

권장사항: 데이터 액세스 보관 정책 및 감사 로그 사용

데이터를 장기간 보관하려면 Cloud Storage 버킷 잠금 기능을 사용하여 데이터 보관 정책을 설정하고 일정 기간 동안 데이터가 잠겨 있도록 하세요. 이렇게 하면 실수로 수정 또는 삭제하는 상황을 방지하고, 데이터 액세스 감사 로깅과 함께 사용할 경우 FINRA, SEC, CFTC와 특정 의료 산업 보존 규정 등의 관련 규제 및 규정 준수 요건을 충족할 수 있습니다.

권장사항: 역할 기반 액세스 제어 정책 사용

업무 분리와 최소 권한의 원칙을 따르는 IAM 데이터 액세스 제어 정책을 마련한다면 악성 해커의 영향 범위와 실수로 인한 삭제를 제한할 수 있습니다. 예를 들어 프로젝트 삭제 권한이 있는 사람과 버킷 생성 권한이 있는 사용자를 분리하는 것이 좋습니다.

암호화 키와 내구성

모든 Cloud Storage 데이터는 클라우드 내에서 저장 상태이든 전송 중이든 항상 암호화되도록 설계되었습니다. 암호화 키가 없으면 객체를 읽을 수 없기 때문에 암호화 키 분실은 내구성에 심각한 위험을 초래합니다. 내구성이 아무리 좋은 데이터라고 하더라도 읽을 수 없다면 결국 아무 소용이 없기 때문입니다. Cloud Storage에서는 1) 신뢰를 바탕으로 Google에서 암호화 키를 대신 관리하도록 하거나 2) 고객 관리 암호화 키(CMEK)와 Cloud KMS를 사용하거나 3) 고객 제공 암호화 키(CSEK)와 외부 키 서버를 사용하는 세 가지 키 관리 옵션이 제공됩니다.

Google은 이레이저 코드, 일관성 확인과 같이 앞의 설명과 유사한 조치를 통해 관리하는 암호화 키의 내구성을 보호합니다.

권장사항: 암호화 키 보호

키 관리를 위해 CMEK 또는 CSEK를 선택하면 자신의 키를 직접 관리할 수 있습니다. 이 경우에도 99.999999999% 이상의 내구성을 제공하는 방식으로 키를 보호하는 것이 중요합니다. CSEK의 경우 키의 외부 백업을 유지하므로 키가 어떤 식으로든 분실되거나 손상되더라도 복구할 방법이 있습니다. 이러한 예방 조치를 취하지 않는다면 데이터의 내구성이 암호화 키의 내구성에 의해 결정됩니다.

99.999999999%를 넘어서

Google Cloud는 데이터 보호 책임을 매우 중요하게 생각합니다. 실제로 여기에 소개된 많은 기술 덕분에 Cloud Storage는 지금까지 99.999999999%가 넘는 연간 내구성을 달성할 수 있었습니다. 이에 더해 이 게시글에 소개된 권장사항을 적용한다면 현재 혹은 향후 수십 년 후에도 언제든지 필요할 때 데이터를 이용할 수 있는 내구성을 확보할 수 있습니다. 시작하려면 Cloud Storage 안내 가이드 전체 문서를 확인해 보세요.

^{이 게시글의 참고 자료가 된 문서의 공동 저자이며 Office of the CTO 테크니컬 디렉터인 딘 힐데브랜드에게 감사의 인사를 전합니다.}

Microsoft 기반 워크로드를 지원하는 Google Cloud의 파일 스토리지 옵션

Sat, 30 Jan 2021 00:00:00 +0000

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

기업은 라이선스 비용을 절감하고 클라우드 기반 아키텍처 역량을 완전히 활용하는 현대화 전략에 착수하기 위해 앞다퉈 Microsoft 및 Windows 기반 워크로드를 클라우드로 이전하고 있습니다. 데이터 센터의 운영 방식으로는 오늘날 비즈니스 환경에서 요구하는 민첩성, 탄력성, 확장성, 비용 최적화를 달성하기가 훨씬 어려워졌기 때문입니다. Google Cloud는 Microsoft 기반 서비스 및 도구를 위한 최고의 엔터프라이즈급 환경을 제공합니다.

Windows 기반 워크로드에 서버 메시지 블록(SMB) 파일 서비스 구성요소가 필요한 경우가 많습니다. 예를 들어 Windows Server 클러스터에서 실행되는 가용성 높은 SAP 애플리케이션 서버는 SMB 파일 서버가 있어야 구성 파일과 로그를 중앙에 저장할 수 있습니다. 코로나19 팬데믹의 영향으로 갑작스럽게 원격 근무 환경에 적응해야 하는 작업자를 지원해주는 가상 데스크톱 솔루션의 수요가 증가했습니다. 이러한 가상 데스크톱 사용자가 문서를 저장하고 동료와 협업하기 위해 SMB 파일 서버에 액세스해야 하는 경우가 많습니다.

다행히 Google Cloud에는 Microsoft 시스템 사용 환경의 다양한 요구사항을 충족하는 SMB 파일 서비스 옵션이 많이 준비되어 있습니다. 이러한 서비스는 완전 관리형, 준관리형, 자체 관리형 서비스라는 세 가지 카테고리로 나눌 수 있습니다. 이 게시물에서는 세 가지 카테고리에 속하는 몇 가지 옵션을 살펴봅니다. 참고: 여기서는 Google Cloud의 SMB 파일 서비스 제공업체를 전부 다루지 않고 널리 사용되는 옵션 위주로 간단히 소개합니다.

완전 관리형 SMB 파일 서비스

많은 기업에서 운영 오버헤드 감소를 클라우드 혁신의 핵심 목표로 삼고 있습니다. 완전 관리형 서비스는 IT 담당 직원이 개입해 소프트웨어 설치 및 구성, 애플리케이션 패치, 백업과 같은 일상적인 업무에 신경쓰지 않더라도 기능과 성과를 제공합니다. 이러한 관리형 SMB 파일 서비스 옵션을 사용하는 고객은 Windows 애플리케이션과 사용자의 작업 속도를 높이고 수고와 위험도를 줄일 수 있습니다. 단, 관리형 서비스는 파트너에서 제공하므로 사용하게 될 리전을 확인하여 서비스 제공 여부를 알아보세요.

NetApp Cloud Volumes Service

IT 관련 부서에서 근무하면서 스토리지를 관리 혹은 사용했거나 고려한 경험이 있다면 NetApp이 낯설지 않을 것입니다. NetApp은 1992년부터 엔터프라이즈급 솔루션을 제공해 왔습니다. NetApp Cloud Volumes Service(CVS)를 선택하면 Google Cloud와 원활하게 통합되는 가용성 높은 클라우드 기반 관리형 SMB 서비스를 이용할 수 있습니다. 스토리지 용량은 대규모 애플리케이션 환경 수요에 맞게 1~100TB 범위로 조정할 수 있으며 자동 스냅샷 및 신속한 볼륨 프로비저닝 같은 검증된 NetApp 기능이 서비스에 포함됩니다. 이 서비스는 Google Cloud Marketplace에서 직접 배포한 후 Google에서 지원하는 Google Cloud Console에서 관리할 수 있으며 사용 요금은 Google Cloud 청구서에 포함됩니다.

Dell Technologies PowerScale

Dell Technologies는 엔터프라이즈급 스토리지 시장의 또 다른 선두 기업으로, Google Cloud에서 PowerScale을 제공하기로 Google과 파트너십을 맺었습니다. PowerScale은 올플래시 아키텍처를 활용하여 매우 빠른 스토리지 작업 속도를 제공합니다. 하지만 이전 버전과의 호환도 가능하므로 올플래시, 하이브리드, 아카이브 구성의 Isilon 노드와 PowerScale 올플래시 노드 중에 선택할 수 있습니다. OneFS 파일 시스템은 네임스페이스당 최대 50PB의 용량을 자랑하며 확장성을 갖추고 있습니다. NetApp과 마찬가지로 Google Cloud의 PowerScale에는 스냅샷, 복제, 온프레미스 스토리지와의 하이브리드 통합과 같은 엔터프라이즈급 기능이 포함됩니다. Google Cloud와 긴밀하게 통합되는 이 시스템은 Google Cloud Marketplace에서 제공되며 Google Cloud Console과 통합됩니다. 또한 Google로부터 직접 비용 청구 및 지원 서비스를 받게 됩니다.

이 두 가지 관리형 파일 스토리지 제품은 SMBv3까지 지원하므로 많은 관리 오버헤드 없이 Windows 워크로드를 지원하는 뛰어난 옵션입니다.

준관리형 SMB 파일 서비스

모든 고객이 완전 관리형 SMB 서비스를 원하는 것은 아닙니다. 관리형 서비스는 업무 부담을 많이 덜어주지만 특정 요구사항에 맞춰 솔루션을 맞춤설정할 수 있는 방법도 줄어들 가능성이 높습니다. 따라서 일부 고객은 자체 Windows 워크로드에 필요한 정확한 사양에 맞춰 구성하기 위해 아래에 소개된 스토리지 서비스와 같은 자체 관리형(또는 준관리형) 서비스를 사용하는 편을 선호합니다.

NetApp Cloud Volumes ONTAP

NetApp Cloud Volumes ONTAP(CVO)는 완전 관리형 NetApp Cloud Volumes Service와 마찬가지로 SnapMirror를 비롯해 데이터 센터의 NetApp 시스템에 사용하던 친숙한 기능과 장점을 제공합니다. 하지만 준관리형 서비스이기 때문에 Google Cloud의 데이터를 보다 강력하게 통제하고 보호해야 하는 고객에게 적합합니다. CVO는 Google Cloud 프로젝트 안에서 Google Compute Engine 인스턴스의 Google Cloud Virtual Private Cloud(VPC)에 배포되므로 내부 또는 외부 규정 준수 요구사항을 충족하는 데 필요한 방식대로 정책, 방화벽 규칙, 사용자 액세스 권한을 적용할 수 있습니다. CVO는 NetApp의 단계별 지침을 따라 직접 배포해야 합니다. Marketplace에서 CVO 요금제별로 다양한 SMB 스토리지 용량(2TB~368TB)과 서비스 제공 여부를 확인하고 선택할 수 있습니다. NetApp Cloud Volumes ONTAP는 모든 Google Cloud 리전에서 제공됩니다.

Panzura Freedom 하이브리드 클라우드 스토리지

Panzura Freedom은 글로벌 기업의 파일 저장, 공동작업, 백업을 지원하는 클라우드 전용 하이브리드 파일 서비스입니다. Panzura Freedom은 Google Cloud VPC, 기업 사무실, 온프레미스 데이터 센터, 기타 클라우드에서 동시에 액세스할 수 있도록 지리적으로 분산된 Panzura CloudFS라는 단일 파일 시스템을 제공합니다. 권한 데이터가 Google Cloud Storage 버킷에 저장되고 로컬에 배포된 Panzura Freedom Filers에 캐시 처리되므로 Windows 애플리케이션 및 사용자의 파일 시스템 액세스 성능이 향상됩니다. Google Cloud의 글로벌 광섬유 네트워크와 100개 이상의 접속 지점(PoP)은 전역 지연 시간을 낮춰 어디서나 빠른 액세스를 제공합니다. Panzura도 Google Cloud Marketplace에서 확인할 수 있습니다.

자체 관리형 SMB 파일 서비스

경우에 따라 관리형 서비스가 일부 요구사항을 충족하지 않을 수도 있습니다. 기술 요구사항뿐만이 아닙니다. 예를 들어 규정 준수 요건이 적용되는 업종이라면 인증된 관리형 서비스가 없을 수도 있습니다. 완전 관리형 및 준관리형 SMB 파일 서비스 옵션을 모두 살펴봤지만 예산과 요구사항에 맞는 서비스가 없더라도 염려하지 마세요. Google Cloud에는 자체적으로 Windows SMB 파일 서비스를 운영할 수 있는 옵션도 있습니다. 이 접근방식을 사용하면 서비스 배포, 구성, 보호, 관리의 책임과 함께 최대한의 유연성을 확보할 수 있습니다. Microsoft 시스템을 담당하던 직원에겐 매우 익숙한 옵션일 것이므로 미리 겁낼 필요는 없습니다.

Google Compute Engine 인스턴스상의 Windows SMB 파일 서버

이 옵션은 매우 단순합니다. 원하는 버전의 Windows Server를 실행하는 Compute Engine 인스턴스를 배포하고 파일 서버 역할을 설치하면 모든 준비가 완료됩니다. 이제 Windows에 내장된 모든 기능을 원하는 대로 사용할 수 있습니다. 온프레미스 Active Directory를 Google Cloud에 확장 또는 통합했거나 Active Directory용 관리형 서비스를 사용하는 경우 온프렘에서와 마찬가지로 사용 권한을 적용할 수 있습니다. Persistent Disk는 Windows 파일 서버의 유연성을 크게 높여줍니다. Persistent Disk를 추가하거나 확장하는 방법으로 다운타임 없이 SMB 파일 서버의 스토리지 용량과 디스크 성능을 추가할 수 있습니다. SMB 파일 서버가 하나면 단일 장애점이 되지만 Compute Engine에 내장된 보호 조치와 중복성 덕분에 장애가 장시간의 다운타임으로 이어질 가능성이 낮아집니다. 리전 영구 디스크를 활용하기로 선택하면 디스크가 지속적으로 다른 Google Cloud 영역에 복제되므로 VM 또는 영역의 장애 발생에 대비해 보호 조치가 강화되고 신속한 복구가 가능해집니다.

Windows 클러스터링

Windows 파일 서비스에 다운타임이 용납되지 않는 요구사항이 있는 경우 하나의 Windows 파일 서버로는 대응이 어렵습니다. 다행히 Windows 장애 조치 클러스터링이 이런 경우의 해결책이 됩니다. Windows Compute Engine 인스턴스 및 Persistent Disk를 두 개 이상 유지하면 Persistent Disk, VM, OS는 물론 전체 Google Cloud 영역에 장애가 발생했을 때도 다운타임을 제로에 가깝게 유지할 수 있는 가용성 높은 SMB 파일 클러스터를 빌드할 수 있습니다. 파일 서버 클러스터와 수평 확장 파일 서버(SOFS)라는 두 가지 서로 다른 방식의 Windows 파일 클러스터가 있습니다.

Windows 파일 서버 클러스터는 개발된 지 20년 가까이 되었습니다. 기본 아키텍처는 Windows 장애 조치 클러스터의 Windows 서버 두 개가 스토리지 영역 네트워크(SAN)와 같은 공유 스토리지에 연결되어 있는 구조입니다. 이러한 클러스터는 기본적으로 활성-수동 구성이므로 언제든 클러스터의 서버 중 하나만 공유 스토리지에 액세스하고 SMB 클라이언트에 파일 서비스를 제공할 수 있습니다. 클라이언트는 내부 부하 분산기 프런트엔드의 유동 IP 주소를 통해 서비스에 액세스합니다. 활성 노드에 장애가 발생하면 수동 노드가 공유 스토리지에 대한 읽기/쓰기 액세스를 설정하고 유동 IP 주소를 바인딩한 후 파일 서비스를 실행합니다. 클라우드 환경에서는 실제 공유 스토리지 기기를 클러스터 스토리지 용도로 사용할 수 없습니다. 대신 Storage Spaces Direct(S2D)를 사용할 수 있습니다. S2D는 여러 VM의 영구 디스크를 하나의 가용성 높은 가상 스토리지 풀에 결합하는 클러스터된 스토리지 시스템입니다. 분산형 가상 SAN이라고 볼 수 있습니다.

수평 확장 파일 서버(SOFS) 역시 Windows 장애 조치 클러스터에서 실행되지만 보다 최근에 개발된 향상된 기능의 클러스터 파일 서비스 역할입니다. Windows 파일 서버 클러스터와 마찬가지로 SOFS도 S2D를 클러스터 스토리지로 활용합니다. 하지만 Windows 파일 서버 클러스터와 달리 SOFS는 활성-활성 구성의 파일 서버입니다. SOFS는 클라이언트에 유동 IP 주소를 제시하는 대신 SOFS 역할의 노드마다 DNS에 A 레코드를 별도로 생성합니다. 각 노드는 공유 데이터 세트의 완전한 복제본을 소유하며 Windows 클라이언트에 파일을 제공하여 SOFS를 수평과 수직으로 확장 가능하게 만들 수 있습니다. 그뿐만 아니라 SOFS는 애플리케이션 서버의 복원력을 강화하는 최신 기능도 갖추고 있습니다.

앞서 언급한 것처럼 Windows 파일 서버 클러스터와 SOFS는 공유 스토리지로 S2D를 사용합니다. Google Cloud 가상 머신에 S2D를 설치하는 절차는 여기에 설명되어 있습니다. 선택한 SMB 파일 서비스 역할은 그 후에 설치할 수 있습니다. 파일 서버 클러스터 역할을 배포하는 절차와 SOFS 역할 설치 절차도 확인하세요.

수평 확장 파일 서버와 파일 서버 클러스터의 비교

파일 서버 클러스터와 SOFS는 S2D를 통해 가용성 높은 SMB 파일 공유를 제공한다는 점에서 유사합니다. SOFS는 보다 최근에 개발된 기술로, 파일 서버 클러스터에 비해 처리량이 많고 확장성이 큽니다. 하지만 SOFS는 최종 사용자 파일 사용 작업(열기, 이름 변경, 수정, 복사 등)에 공통적으로 수반되는 메타데이터 위주의 작업에는 최적화되어 있지 않습니다. 따라서 최종 사용자 파일 서비스로는 파일 서버 클러스터를, 애플리케이션에 SMB 파일 서비스가 필요할 때는 SOFS를 선택하는 것이 일반적입니다. 이 페이지에서 파일 서버 클러스터(해당 문서에서는 '일반 용도 파일 서버 클러스터'로 표기)와 SOFS의 기능을 자세히 비교한 내용을 확인해 보시기 바랍니다.

어떤 옵션을 선택해야 하나요?

지금까지 Microsoft 시스템 사용 환경에서 안전성, 성능, 확장성이 우수한 SMB 파일 서비스에 대한 사용자 액세스와 Windows 워크로드를 제공하는 데 적합한 여러 옵션을 알아봤습니다. 그렇다면 나만의 니즈에 가장 적합한 옵션을 선택하려면 어떻게 해야 할까요? 이때 고려해야 할 몇 가지 결정 기준을 소개합니다.

IT 작업을 간소화하고 운영상의 부담을 덜 수 있는 방법을 찾고 있나요? 그렇다면 완전 관리형과 준관리형 옵션을 살펴보세요.
관리형 서비스로는 충족되지 않는 특별한 기술 측면의 구성 요구사항이 있나요? 그렇다면 자체적인 SMB 파일 서비스 솔루션을 단일 Windows 인스턴스 또는 Windows 클러스터 옵션 중 하나로 운영해 보세요.
여러 영역에 걸쳐 완전 자동화된 고가용성 서비스가 필요한가요? 그렇다면 NetApp Cloud Volumes ONTAP와 단일 인스턴스 Windows 파일 서버를 고려해 보세요. 이러한 서버는 하나의 Google Cloud 영역에서 실행됩니다.
특정 Google Cloud 리전에 대한 요구사항이 있나요? 그렇다면 해당 리전에서 NetApp Cloud Volumes Service와 NetApp Cloud Volumes ONTAP가 제공되는지 여부를 확인해야 합니다. 이 두 가지 서비스는 특화된 하드웨어가 필요한 파트너 서비스이며 현재 많은 Google Cloud 리전에서 사용할 수 있지만 제공되지 않는 리전도 있습니다.
온프레미스와 클라우드를 아우르는 하이브리드 스토리지 기능이 필요한가요? 그렇다면 모든 관리형 옵션에 하이브리드 옵션이 있습니다.
예산이 빠듯한가요? 예산이 충분하지 않고 단일 장애점일 경우 우려되는 다운타임을 최소화하기 위해 약간의 수작업 계획 수립과 작업을 감내할 용의가 있다면 단일 Windows Compute Engine 인스턴스 파일 서버가 적합합니다.
여러 지역을 포괄하는 재해 복구가 필요한가요? 여기에 설명된 모든 옵션이 재해 복구 서비스를 제공하므로 염려하지 않아도 됩니다.

아래 표에는 완전 관리형 및 준관리형 옵션이 요약되어 있습니다. 이러한 옵션 중 어느 것도 요구 사항을 충족하지 않는 경우 자체 관리형 옵션 중 하나를 선택하는 것이 좋습니다.

GCP의 관리형 파일 스토리지 옵션

다음 단계

이 게시글에서는 Google Cloud에서 사용할 수 있는 Windows 파일 서비스의 여러 옵션을 간략하게 살펴봤습니다. 이 중에 관심이 가는 옵션이 있다면 자세한 정보를 살펴보세요. 선택의 폭이 좁아졌다면 Marketplace 페이지에서(관리형 서비스의 경우) 자세한 정보를 확인하거나 서비스 실행 프로세스를 시작하세요. 위의 자체 관리형 옵션에는 시작하는 데 참고할 수 있는 Google Cloud 관련 지침 링크와 선택한 클러스터 옵션 배포에 관한 일반 Microsoft 문서 링크가 포함되어 있습니다.