ストレージとデータ転送

C4N の一般提供を開始: クラウドで最高レベルの vCPU あたりのネットワークとブロックストレージの I/O を x86 ワークロードで実現

Fri, 24 Jul 2026 00:00:00 +0000

※この投稿は米国時間 2026 年 7 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

組織が、高スループットのデータベースやネットワーク / セキュリティアプライアンスから、リアルタイム分析や AI / ML 推論に至るまで、最新のワークロードをスケールすると、ネットワークとブロックストレージのパフォーマンスがすぐにボトルネックになる可能性があります。標準の仮想マシンでは、コンピューティングの効率と、これらのアプリケーションの大量のデータ転送の需要とのバランスを取るのが難しいことがよくあります。

Google Cloud Next ‘26 で、Google は、要求の厳しいエンタープライズアプリケーションの I/O ボトルネックを解消するために特別に構築された、ネットワークとブロックストレージ向けに最適化された Google Compute Engine インスタンスである C4N のプレビュー版を発表しました。そしてこのたび、その一般提供が開始されました。Google のカスタム設計の Titanium オフロードアーキテクチャ上に構築された C4N インスタンスは、ネットワークとストレージのタスクを専用のハードウェアにオフロードし、驚異的なパフォーマンスとコンピューティング効率を実現します。C4N は、最大 400 Gbps のネットワーク帯域幅と、業界トップクラスのスループットである 95 MPPS（百万パケット/秒）を誇ります。これは、他のハイパースケーラーの同等の Intel ベースのサービスと比較して、vCPU あたりのネットワーク帯域幅が約 33% 高く、パケット処理のパフォーマンスが 224% 高速である数値です。このパフォーマンスにより、C4N は、仮想アプライアンス（次世代ファイアウォール、仮想ルーター、ロードバランサ、DDoS 軽減など）、大規模なデータ分析、通信アプリケーション（5G UPF）、分散コンピューティング、CPU ベースの AI / ML ワークロードなど、大量のデータのネットワーク伝送が必要となるアプリケーションに最適です。

C4N は、Google の高パフォーマンスブロックストレージである Hyperdisk Extreme と組み合わせることで、Compute Engine の最高レベルのブロックストレージパフォーマンスを実現し、ストレージ帯域幅を最大 25 GiB/秒、IOPS を 100 万までスケールアップすることもできます。これは、同等の Intel ベースのサービスと比較して、ストレージ帯域幅が約 33% 高く、vCPU あたりの IOPS が 39% 多い数値です。そのため、大規模データベース、高パフォーマンスファイルシステム、インメモリデータベース、その他、高ブロックストレージパフォーマンスのメリットを享受できるワークロードに最適です。

C4N は、ネットワーキング、1 秒あたりのパケット数に制約があるアプリケーション、ストレージ向けに最適化されたアプリケーションで、予測可能な高スループットの I/O パフォーマンスを実現するように特別に設計されています。お客様は C4N を使用することで、特定のワークロード要件を満たすためにネットワーク、ストレージ、コンピューティングリソースをより正確にスケールできます。また、I/O 需要を満たすためだけにリソースを過剰にプロビジョニングする必要がなくなるため、TCO を大幅に削減できます。

C4N は、第 5 世代の Intel® Xeon® スケーラブルプロセッサ（コード名: Emerald Rapids）を備えています。

「Google Cloud による C4N の導入は、データ量がますます多くなっているワークロードに対処するうえで、インフラストラクチャのイノベーションと強力なシリコン基盤がいかに役立つかを示しています。Intel Xeon とカスタム Infrastructure Processing Unit（IPU）を備えた C4N は、要求の厳しいネットワーク最適化環境に必要なパフォーマンスと効率を実現します。」 – Intel、データセンタープロダクト、Intel フェロー、Srini Krishna 氏

新機能: C4N で大規模なデータレイヤをスケール

ネットワーク最適化 C4N インスタンスは、予測可能な高パフォーマンスの I/O を大規模に実現するように設計されています。C4N は、すべての VM のシェイプとサイズで一貫した帯域幅、パケット処理パフォーマンス（PPS）、IOPS スケーリングを提供することで、最も要求の厳しいデータワークロードを確実に実行できるようにします。これを実現するために、Google はホストレイヤとファブリックレイヤから冗長なトップオブラック（ToR）スイッチまで、インフラストラクチャのあらゆるレイヤに優れた復元力を組み込み、アプリケーションが継続的に高いパフォーマンスを発揮できるようにしています。

ネットワーク最適化 C4N は、汎用 C4 VM と比較して、ネットワークとブロックストレージの両方のベクトルでパフォーマンスが大幅に高くなっています。

次世代のネットワークパフォーマンス

優れた VM 間ネットワーク帯域幅: 最大 400 Gbps の VM 間ネットワーク帯域幅（標準の C4 と比較して vCPU あたりの帯域幅がほぼ 4 倍）を実現し、同じ VPC ネットワーク内でルーティングされる C4N インスタンス間で最大 50 Gbps の単一フロー帯域幅をサポートします。これにより、高スループットのシングルストリームアプリケーションとマルチストリームアプリケーションで、ノンブロッキングのデータ配信が可能になります。
VM からインターネットへのパフォーマンスの向上: インターネットの外向きネットワーク帯域幅が 8 倍、最大 200 Gbps に達します。また、インターネットの外向きパケット処理パフォーマンスが約 32 倍向上し、最大 48 MPPS までスケールされます。
小規模なシェイプ向けに最適化された I/O: 2～16 個の vCPU のシェイプ専用に最大 25～50 Gbps のネットワーク帯域幅を提供することで、クラウド料金を抑えます。コンピューティングを過剰にプロビジョニングする必要がなく、I/O に制約があるタスクを高速化するのに最適です。さらに、これらの小規模なシェイプでは、予測可能な安定状態のベースライン帯域幅制限が導入されているため、低コストで一貫したパフォーマンスが提供されます。
すぐに使える強化されたネットワーク構成: C4N の gVNIC インターフェースは、デフォルトで適用される標準の Tx / Rx キューが多くなっており、vCPU 数に応じて最大 64 個のキューまでスケールされます（C4 / C4D では 16 個のキュー）。
Google Cloud Storage の転送時間の短縮: C4N VM では、Cloud Storage から大量のデータを取得して保存するための帯域幅が最大 2 倍に増加しているため、分析、AI / ML、バックアップのワークロードのパフォーマンスが向上します。

さらに、このパフォーマンスはアドオンなしで、すぐに利用できます。最初から高いパフォーマンスを発揮するように設計された C4N は、Tier_1 ネットワーキングなどのプレミアムアドオンを購入または構成しなくても、最大限のパフォーマンスを実現します。

Hyperdisk による動的なストレージパフォーマンス

C4N インスタンスファミリーと Hyperdisk を組み合わせることで、コンピューティングインスタンスのサイズ設定とは関係なく、ストレージのパフォーマンス、レイテンシ、スループットを動的に調整し、アプリケーションで高いブロックストレージパフォーマンスを実現できます。C4N は、Hyperdisk Balanced、Balanced High Availability、Extreme、Throughput、ML ブロックストレージオプションを含む、Hyperdisk のポートフォリオ全体をサポートしています。

Hyperdisk Extreme: Hyperdisk Extreme と組み合わせた C4N は、最新のデータベースやエンタープライズ AI アプリケーションに必要な低レイテンシかつ高速のデータアクセスを実現します。ブロックストレージのスループットは最大 25 GiB/秒、IOPS は約 100 万で、C4 と比較してストレージパフォーマンスが 2 倍向上しています。また、C4N など、ネットワーク最適化マシンシリーズ限定で、最小の 2 vCPU サイズを含むすべてのマシンサイズで Hyperdisk Extreme を提供しています。
Hyperdisk Balanced: Compute Engine ポートフォリオの汎用ブロックストレージで最高レベルのスループットと IOPS を実現する、C4N の Hyperdisk Balanced は、ブロックストレージのスループットを最大 20 GiB/秒、IOPS を約 64 万までスケールアップできます。そのため、ストレージを多用するアプリケーションを大規模に実行する場合に、費用対効果の高いオプションとなります。

C4N のネットワークとストレージの最適化を組み合わせることで、実際のアプリケーションで大きな効果が得られます。

ウェブサービス: 一般的なウェブリクエストサイズ（100～300 KB）の場合、C4 と比較して 1 秒あたりの Nginx リクエスト数が最大 1.5 倍増加し、ネットワークに制約があるウェブアプリケーションの処理能力が大幅に向上します。
データベース: データが主にディスクに保存されている場合、同等の C4 VM と比較して、MySQL の秒間クエリ数（QPS）が最大 45% 増加します。

お客様の声

業界のリーダーはすでに、ワークロード向けに最適化されたインフラストラクチャが変革のエンジンとなっていることを証明しています。お客様がネットワーク最適化 C4N のパワーをどのように活用しているかをご紹介します。

「5G コアのワークロードは本質的にネットワーク負荷が高く、高スループットのパケット処理と決定論的なレイテンシが求められます。標準的なパブリッククラウドインスタンスでは、大規模環境でこれらを維持するのは容易ではありません。Google Cloud C4N コンピューティングファミリーを活用することで、Ericsson On-Demand の理想的なエンジンを見つけました。ネットワーク向けに最適化されたコンピューティングに重点を置いた C4N のアーキテクチャにより、当社の 5G Core-as-a-Service は、お客様が求めるキャリアグレードの信頼性を維持しながらも、最近達成した 1 Tbps など、前例のないスループットレベルを実現しています。C4N を使用することで、クラウドネイティブという枠を超えて、パブリッククラウド環境でネットワークネイティブなパフォーマンスを実現しています。」- Ericsson、Ericsson On-Demand 責任者、バイスプレジデント、Eric Parsons 氏

「Teradata の Autonomous Knowledge Platform は、本番環境グレードの AI、分析、データを一つの統合システムに統合し、自律型 AI が大規模に必要とするコンテキスト、ガバナンス、パフォーマンスのバックボーンを提供します。お客様は Teradata を活用し、パフォーマンスと費用管理が価値を直接左右する、ミッションクリティカルかつ I/O 集約型のワークロードを実行しています。

Google Cloud C4N インスタンスは、このような要求の厳しいワークロードに適しており、優れたコストパフォーマンスを実現するとともに、より効率的で最適化されたデプロイをサポートします。Google Cloud 上の C4N を活用することで、Teradata Cloud は、お客様が分析情報を得てから行動に移すまでの時間を短縮して、エンタープライズインテリジェンスを自信を持ってスケールし、データと AI への投資からより大きな成果を出せるよう支援します。」- Teradata、コアプラットフォーム、プロダクトマネジメント担当シニアディレクター、Kevin Dougherty 氏

「C4N VM の次世代のネットワークとストレージ帯域幅により、Google Cloud NetApp Volumes は、お客様の最も要求の厳しい AI ワークロードをサポートする新たなレベルのパフォーマンスを実現します。Google と NetApp は、Google Cloud NetApp Volumes による C4N VM ファミリーのサポートを拡張するために連携することで、お客様の実際の課題に対処するためのパートナーシップを深めています。両社は、アーキテクチャを簡素化し、パフォーマンスを最大化し、データを成果に変える、データ移動が不要な AI および分析ソリューションを提供しています。」- NetApp、クラウドストレージおよびサービス担当シニアバイスプレジデント兼ゼネラルマネージャー、Pravjit Tiwana 氏

「ほとんどの Compute Engine インスタンスは、1 つの高速ネットワークインターフェースを備えています。新しい C4N は、2 つの 200 GbE インターフェースで帯域幅の可能性を 2 倍にしています。このアーキテクチャの移行は大きなものです。つまり、両方のネットワークをストレージトラフィック専用にできるため、前世代と比べて、データ量が多いワークロードで利用可能な帯域幅が 2 倍になり、ストレージパフォーマンスが 2 倍になります。C4N は数週間前に発表されたばかりですが、すでに Sycomp のテスト環境でアクティブになっており、お客様が最新の GCP 機能を遅滞なく評価できるようになっています。Google Cloud が公開している C4N の Hyperdisk Balanced の最大パフォーマンスは 20 GiB/秒です。3 台のストレージサーバーを使用したテストでは、読み取りで 58.5 GiB/秒、書き込みで 58.6 GiB/秒を達成し、10 台の C4N ストレージサーバーを使用したテストでは、読み取りと書き込みで 195 GiB/秒を達成しました。これは、プラットフォーム固有の調整を一切行わずに理論上の上限の 97% に達したことになります。出発点としては優れた結果であり、微調整できる構成作業を通じて残りのギャップを埋める余地は十分にあります。C4N は高速であるだけでなく、Google Cloud 上のストレージワークロードの費用対効果のバランスを変えます。」- Sycomp、シニア HPC ソリューションアーキテクト、Scott Fadden 氏

「ClipperDB Technologies の使命は、大規模な Spark 分析の費用を削減し、パフォーマンスを向上させることです。Google Cloud の C4N インスタンスは、完全にネイティブなアーキテクチャに最適なコンピューティングエンジンです。C4N の vCPU あたりのネットワーク帯域幅の大幅な増加と、大容量メモリ構成、第 5 世代 Intel Xeon プロセッサにより、ClipperDB の正確なクラウドストアの並列プリフェッチおよびキャッシュ保存、同時データフローのネイティブバッチパイプライン、ストリーミングのコピーなし交換、クラウドストアのチェックポイントのフォールトトレランスが実現し、分離された Cloud Storage データレイクを使用して Spark ワークロードを大幅に高速化し、コストを削減しています。

結果は一目瞭然です。業界標準の TPC-DS ベンチマーク全体で、ClipperDB+C4N は、Spark との互換性を 100% 維持しながらも、クエリあたりのコストを 3 分の 1 以下に削減し、分析を最大 11 倍高速化しました。C4N と Clipper DB Accelerator を組み合わせることで、お客様が Spark ワークロードの費用対効果を大幅に改善できるようになることを期待しています。」- ClipperDB Technologies、CEO、John Busch 氏

C4N のシェイプと仕様の詳細

C4N インスタンスには、2～192 個の vCPU と最大 1.5 TB の DDR5 メモリを備えた 9 つの異なるサイズがあり、事前定義されたシェイプを高 CPU、標準、高メモリの構成で利用できます。

キャッシュ保存と高速かつ低レイテンシのローカルストレージのメリットを活かせるアプリケーション向けに、C4N VM インスタンスは最大 12 TiB の最新の Titanium SSD を備えています（近日提供予定。C4N ローカル SSD プレビュー版へのアクセスをリクエストするには、こちらからご登録ください）。マシンのリソースに直接アクセスする必要があるワークロード（ハイパーバイザ、コンテナプラットフォームなど）、ネストされた仮想化ではパフォーマンス要件を満たせないワークロード、パフォーマンスのモニタリングまたはライセンスに関する特別なニーズがあるワークロード向けに、C4N ベアメタルシェイプを導入します。これらのネイティブベアメタルシェイプのネットワークとストレージの I/O パフォーマンスは、まもなく仮想マシンのシェイプと同等になります。Google Cloud のお客様は、Compute Engine と Google Kubernetes Engine（GKE）で C4N インスタンスを使用できます。その他のサービスも近日中にサポートされる予定です。

名前	vCPU	メモリ（GB）	ローカルストレージ（GiB）	ネットワーク帯域幅		Hyperdisk Extreme の帯域幅（MiB/秒）	Hyperdisk Extreme の IOPS
名前	vCPU	メモリ（GB）	ローカルストレージ（GiB）	VM 間（Gbps）	VM からインターネット（Gbps）	Hyperdisk Extreme の帯域幅（MiB/秒）	Hyperdisk Extreme の IOPS
C4n-highcpu	2～192	4～384	該当なし	25～400	7～200	1.000～25,000	8 万～100 万
C4n-standard	2～192	7～720	該当なし	25～400	7～200	1.000～25,000	8 万～100 万
C4n-standard-lssd	4～192	15～720	375～12,000	30～400	7～200	1.000～25,000	10 万～100 万
C4n-highmem	2～192	15～1,488	該当なし	25～400	7～200	1.000～25,000	8 万～100 万
C4n-highmem-lssd	4～192	31～1,488	375～12,000	30～400	7～200	1.000～25,000	10 万～100 万

C4N マシンシリーズのパフォーマンスと仕様

ご利用方法

C4N は、高負荷の分散データベースのホスティング、ネットワーク仮想化アプライアンスの実行、AI 向けの大規模データパイプラインのオーケストレーションなどで、ビジネスに求められるスループット、スケール、効率性を実現するように設計されています。C4N インスタンスは現在、オンデマンド、Spot VM、予約を通じて一般提供されています。また、us-central1（アイオワ）、us-east1（サウスカロライナ）、us-east5（オハイオ）、us-west1（オレゴン）、europe-west2（ロンドン）で 1 年間または 3 年間の確約利用割引（CUD）または FlexCUD を購入することで、さらなるコスト削減を実現できます。詳細については、ネットワーク最適化マシンタイプをご覧ください。

イノベーションのための高パフォーマンスの基盤を築く準備はできていますか？Google Cloud コンソールにアクセスして、「ネットワーク最適化」マシンファミリーで C4N VM をスピンアップしましょう。利用可能なリージョンの最新情報については、リージョンとゾーンのページをご覧になるか、Google Cloud の営業担当者にお問い合わせください。

- シニアプロダクトマネージャー、Parinda Gandhi

- シニアプロダクトマネージャー、Sajal Agarwal

Backup and DR サービスのクロスリージョンバックアップでデータレジリエンスを強化

Tue, 30 Jun 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 6 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。

ビジネス継続性を維持するには、堅牢なデータバックアップ戦略が必要です。マルチリージョンバックアップは最高レベルの可用性を提供しますが、多くの組織は、リージョンの停止からデータを保護しながらも、データ所在地の要件を満たすための、より費用対効果の高い方法を求めています。

このたび Google は、マルチリージョンバックアップ保護を基盤とした、Backup and DR サービスのクロスリージョンバックアップの一般提供（GA）を開始しました。この更新により、バックアップ先がソースによって制限されなくなります。バックアップリージョンは、プライマリワークロードが配置されているリージョンとは完全に異なるリージョンにすることができます。この分離は、データの保存場所をきめ細かく制御しながら、局所的なリージョンの停止から保護するために不可欠です。

この機能は現在、Compute Engine インスタンス、ディスク、Filestore で完全に利用可能で、今後 Cloud SQL と AlloyDB にも対応する予定です。

クロスリージョンバックアップのメリット

マルチリージョンバックアップはダウンタイムをほぼゼロにできますが、すべてのアプリケーションで必ずしも必要となるわけではない高額なインフラストラクチャ費用が発生する可能性があります。クロスリージョンバックアップは、次の機能を提供することでこのギャップを埋めます。

費用の最適化: 復元リージョンを選択的に指定できるため、標準的なマルチリージョンデプロイに代わるきめ細かい制御が可能になり、価値を最大化できます。
コンプライアンスの簡素化: バックアップを保存する地政学的な境界を正確に選択することで、データ所在地に関する複雑な法律（GDPR など）に対応できます。
リージョンのレジリエンスの向上: 完全に異なる地理的リージョンに復元可能なデータのコピーを配置することで、局所的な災害から保護できます。

仕組みの概要

クロスリージョンバックアップ戦略の実装は、直感的で既存のワークフローに統合されるように設計されています。

1. Backup Vault を作成する: ソースリソースとは異なるリージョンに Backup Vault を設定します。

2. バックアッププランを構成する: リソースのリージョンにバックアッププランを作成しますが、セカンダリリージョンにある Vault を選択します。

3. アタッチして自動化: プランをリソースにアタッチします。残りの処理は Backup and DR によって行われ、データはソースリージョン外のリージョン Backup Vault に直接移動されます。

つまり、クロスリージョンバックアップは、複雑なコンプライアンスとデータ所在地の基準に違反することなく、組織に必要なレジリエンスと費用効率を実現します。セカンダリリージョンへの直接バックアップを許可することで、局所的な災害に対する堅牢な保護レイヤが実現します。また、マルチリージョンデプロイの事前定義された境界と比較して、セカンダリロケーションをより自由に選択できます。ぜひこれらの新機能をお試しいただき、Backup and DR がデータレジリエンス戦略をどのように強化できるかをご確認ください。

リソース

- Google、プロダクトマネージャー、Rushikesh Kure

- Google、プロダクトマネージャー、Vaibhav Namdeo

Storage Insights データセット: アクティビティインサイトで組織全体のオペレーションを把握

Wed, 24 Jun 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 6 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

エンタープライズストレージのフットプリントは、オブジェクト件数数十億規模にまで拡大してきています。また、ストレージの役割も、AI アプリケーションとエージェント型ワークロードにより、これまでの受動的なリポジトリからデータプラットフォームの基盤へと根本的な進化を遂げつつあります。非構造化モデルデータの急増と、セッションログや監査証跡を含むこのようなオブジェクトに実行される数十億ものアクションが、この進化を加速させています。これを管理し、費用、運用、セキュリティの問題を解決するために、ストレージとプラットフォームの管理者は、データの中身だけでなく、データがどのようにアクセス、移動、変更されているかを正確に把握する必要があります。

この課題の解決を支援するために、このたび一般提供を開始したのが、Storage Insights データセットのアクティビティインサイトです。これは、Google Cloud Storage アセットの運用に関する詳細を可視化する新しいビューを提供し、データドリブンな費用最適化と迅速なトラブルシューティングを可能にするものです。たとえば、アクティビティインサイトで次のような疑問を解決することができます。

オブジェクトはバケット内の適切なストレージクラスに配置されているか？
バケットが最も頻繁にやり取りしているリージョンはどこか？（バケットの最適な配置を評価するための情報確認）
ストレージ資産の運用全般において、どこでどのような理由でエラーが発生しているか？

これらの質問に自信を持って答えられることが、費用最適化を実現し、エンジニアリングのための時間を節約する鍵となります。Cloud Storage の Storage Intelligence 機能である Storage Insights データセットは、日々のメタデータと頻繁な（通常はアクティビティから 4 時間以内の）アクティビティ分析情報を提供し、ストレージ資産の可視性を高めます。Storage Intelligence は、バケットの再配置、バッチオペレーション、Gemini Cloud Assist などの機能を備えた統合管理プロダクトですが、このブログ記事では、運用最適化のために Storage Insights データセットを活用する方法に焦点を当てます。

Storage Insights データセットとは

Storage Insights データセットは、ストレージ資産全体に対する自動化されたクエリ対応の BigQuery インデックスを、実際のメタデータとアクティビティに関する分析情報とともに提供します。これにより、これまでエラーが起きやすかった手動のデータ収集作業が不要になります。Storage Insights データセットのスコープはカスタマイズできます。たとえば、組織全体、特定のフォルダ、プロジェクト、一連のプロジェクト、さらには特定のバケットを対象にデータセットを作成できます。このデータセットは定期的なアップデートによって更新され、ストレージの包括的なビューを提供します。

静的なメタデータからライブインテリジェンスへ進化

Storage Insights データセットは、ストレージのメタデータを把握するのに最適なツールです。インベントリ管理ツールとして機能し、オブジェクトのメタデータ（ストレージクラス、ロケーション、経過時間、カスタムメタデータ）をスキャンして、BigQuery にリンクされた、クエリ可能で有用性の高いデータセットに整理します。これはデータの実態を把握するためには不可欠な情報です（Storage Insights データセットを使用してストレージ費用を最適化する方法について詳しくは、こちらをご覧ください）。

さらに、そのデータがいつ、どのように使用されているかも把握できたらどうでしょうか。

Storage Insights データセットでは、新たに次の情報も確認できるようになりました。

オブジェクトレベルのアクティビティ（書き込み、更新、削除、エラーなど）
バケットレベルの集計アクティビティ（オブジェクトオペレーションの合計数、オペレーションのタイプ別の内訳、エラーの合計数、最頻の接頭辞など）
バケットレベルのリージョントラフィックアクティビティ（バケットとやり取りするリージョンごとの上り / 下り（内向き / 外向き）両方のバイト数など）
プロジェクトレベルの集計アクティビティ（オブジェクトオペレーションの合計数、オペレーションのタイプ別の内訳、エラーの合計数など）

これらのデータは、データセット内の新しい BigQuery ビューに直接取り込まれるため、分析クエリを実行して特定の分析情報を得たり、Gemini を介してデータとやり取りしたり、単に Looker の高機能ダッシュボードに接続して可視化したりすることができます。

これにより、データ分析が静的なスナップショットから、データのライフサイクル全般にわたるクエリ可能な動的分析へと進化します。これは、言うなれば、ウェアハウスに何があるかを知ることから、何がいつ、どのように使用されたかを知ることへの進化です。

アクティビティインサイトを直ちに活用する 3 つの方法

Storage Intelligence データセットのアクティビティインサイトを使用すれば、直ちに以下のことを実現できます。

1. ストレージ資産のサイズを適正化する

課題: Standard クラスまたは Nearline クラスのストレージにテラバイト規模のデータがあり、しかもコールドデータであると考えられます。しかし、確証がないまま Coldline クラスや Archive クラスに移行するのは危険です。重要なプロセスによる読み取りが四半期に 1 回は必要な場合はどうすればよいでしょうか？
解決策: アクティビティに関する分析情報を表示する新しい Storage Intelligence ビューでは、過去 30 日、60 日、90 日間に読み取り / 書き込みアクティビティが最小限だったバケットを特定できます。
対応: ライフサイクルポリシーを適用し、必要に応じて微調整して、このデータを費用対効果の高いストレージクラスに移行します。

たとえば、過去 6 か月間にアクティビティがほとんど、またはまったくなかったバケットをすべて並べ替える SQL クエリは次のようになります。

code_block: <ListValue: [StructValue([('code', 'SELECT name, location, project, totalRequests\r\nFROM\r\n `[project]`.`[dataset]`.`bucket_activity_view`\r\nWHERE\r\n snapshotEndTime >= TIMESTAMP(DATE_SUB(DATE_TRUNC(CURRENT_DATE(), MONTH), INTERVAL 5 MONTH))\r\n AND snapshotEndTime < CURRENT_TIMESTAMP()\r\nORDER BY totalRequests ASC\r\n\r\n//データセットでクエリを実行すると、BQ クエリ費用が発生します。詳細については、料金ページをご覧ください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f338af97f40>)])]>

2. データドリブンなバケット配置でグローバルパフォーマンスを向上させる

課題: グローバルアプリケーションをサポートするためにマルチリージョンのバケットをセットアップしました。しかし、それは 1 年後も適切なアーキテクチャでしょうか？トラフィックの 99% が単一リージョンから発生している場合はどうでしょうか？
解決策: 新しい bucket_region_activity_view テーブルでアクセスパターンを分析します。どのリージョンがバケットの読み取り / 書き込みアクティビティを促進しているかを、簡単に特定できます。
対応: データドリブンな意思決定により、バケットとコンピューティングを同一リージョンに配置します。マルチリージョンバケットをシングルリージョンバケットに（またはその逆に）変更することで、大幅な費用削減とパフォーマンスの向上を実現できる場合があります。

たとえば、リージョン間のバケットの下り（外向き）と上り（内向き）のトラフィックパターンを分析する SQL クエリは次のようになります。

code_block: <ListValue: [StructValue([('code', "SELECT\r\n requestLocation,\r\n bucketLocation,\r\n SUM(requestBytes) AS total_request_bytes,\r\n SUM(responseBytes) AS total_response_bytes\r\nFROM\r\n `[project]`.`[dataset]`.`bucket_region_activity_view` \r\nWHERE\r\n name = '[bucket name]'\r\nGROUP BY\r\n requestLocation,\r\n bucketLocation;\r\n\r\n\r\n//データセットでクエリを実行すると、BQ クエリ費用が発生します。詳細については、料金ページをご覧ください。"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f338af97970>)])]>

当日配達サービスを提供する小売テクノロジープラットフォームの Shipt は、Storage Intelligence の機能を活用して、データの配置に関する意思決定に役立てています。

「Storage Intelligence を使用することで、20 億個を超えるオブジェクトを効率的に管理し、費用とパフォーマンスを最適化できるようになりました。Storage Insights データセットで、マルチリージョンバケットからの下り（外向き）料金を検出、分析でき、コンピューティングとストレージの共存による効率性向上の機会を特定できます。バケット再配置機能を利用して、1.3 ペタバイトのデータをマルチリージョンから特定リージョンのストレージにシームレスに移行し、アプリケーションのパフォーマンスとデータパイプラインの継続性を維持しながら、大幅な費用削減を実現しました。」 - Shipt、エンジニアリング担当ディレクター - クラウドプラットフォーム、Ron Cuirle 氏

3. 運用上のホットスポットを解明して解決する

課題: チームで 429（リクエスト過多）エラーが急増しています。大規模な環境では、これは単にパフォーマンスを低下させるだけではなく、費用を増加させます。これらのエラーは自動再試行をトリガーし、多くの場合、高頻度の課金対象オペレーションサイクルにつながり、クラス A の費用を押し上げるためです。どのオブジェクトまたは接頭辞が原因かを正確に特定するには、トラブルシューティングが難しく時間がかかります。
解決策: 新しい Storage Insights データセットビューでは、これらのエラーに関する詳細を BigQuery で直接確認できます。429 エラーをクエリすることで、どのオブジェクトと接頭辞に負荷がかかっているかを正確に特定できます。
対応: 429 エラーの原因をさらにピンポイントで特定できるので、トラブルシューティングから即、解決へと導かれます。

たとえば、次の SQL クエリは、環境全体で発生している 429 エラーを分析し、発生場所と原因を特定します。

code_block: <ListValue: [StructValue([('code', 'SELECT\r\n requestOperation,\r\n errorReason,\r\n objectName,\r\n bucketName,\r\n requestCompletionTimestamp,\r\n project\r\nFROM\r\n `[project]`.`[dataset]`.`object_events_view` \r\nWHERE\r\n responseStatus = 429\r\nORDER BY\r\n requestCompletionTimestamp DESC;\r\n\r\n\r\n//データセットでクエリを実行すると、BQ クエリ費用が発生します。詳細については、料金ページをご覧ください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f338af97490>)])]>

ご利用にあたって

Google Cloud を利用しながら成長し続ける組織では、データの規模も拡大する一方です。もうアーカイブデータに依存するのはやめて、組織のストレージ資産の最適化に着手しましょう。Cloud Storage の Storage Insights データセットは、新しいアクティビティインサイトにより、大規模なデータ資産を、高度に最適化された完全に把握可能なアセットへと生まれ変わらせます。

まず手始めに、こちらの事前構成済み Looker Studio テンプレートを使用してデータセットに接続し、迅速な分析で価値を引き出してみましょう。

たとえば、バケットの合計読み取り数の経時的な傾向を確認します。

あるいは、バケットの上り（内向き）と下り（外向き）の両方のトラフィックパターンを分析してみましょう。

Storage Insight データセットで分析情報を活用する準備はできましたか。ご利用を開始するには:

Google Cloud コンソールで早速 Storage Intelligence を有効にしましょう。
データセットを今すぐ構成してみましょう。BigQuery で直接データをクエリするか、Looker テンプレートに接続して、迅速かつ簡単に可視化できるようになります。
Storage Intelligence とご利用を開始する方法の詳細は、動画でご確認いただけます。
Storage Insights データセットを使用して Cloud Storage のフットプリントを最適化する方法について詳しくは、こちらをご覧ください。

- Cloud Storage、プロダクトマネージャー、Misha Sheth

- Cloud Storage、APAC テクノロジープラクティスリード、Kumar Nachiketa

Cloud Storage Rapid: AI と分析のための超高速化されたオブジェクトストレージ

Fri, 22 May 2026 03:00:00 +0000

※この投稿は米国時間 2026 年 5 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud Next ’26 において、Google は AI や分析などのデータ集約型ワークロード向けのオブジェクトストレージ機能ファミリーである Cloud Storage Rapid を発表しました。Cloud Storage Rapid は登場時点で、高パフォーマンスのゾーンオブジェクトストレージサービスである Rapid Bucket（旧称: Rapid Storage）と、オンデマンドで読み取りを高速化し、既存のバケットのワークロードのコンピューティングとデータをコロケーションする Rapid Cache（旧称: Anywhere Cache）で構成されています。

Cloud Storage Rapid: AI と分析のための超高速化されたオブジェクトストレージ

組織が AI を中核に据えて構築を進めるなか、Google は次世代の要請に応えるために Cloud Storage Rapid を開発しました。チームは、数兆個のパラメータを持つモデルをトレーニングし、グローバル規模で推論をデプロイし、膨大な量のエンタープライズデータについて推論する自律エージェントを構築しています。GPU や TPU といったアクセラレータが注目を浴びがちですが、それらには極めて重要な依存関係があります。それがストレージです。

ストレージは、トレーニング中にアクセラレータにデータを供給するエンジンであり、リアルタイム推論を応答性の高いものにする高速アクセスレイヤです。しかし、モデルの規模が大きくなるにつれて、ストレージのパフォーマンスがボトルネックになる可能性があります。AI / ML クラスタがデータの読み取りを待機したり、チェックポイントの書き込みを停止したりするたびに、有用な作業を行っていない高価なコンピューティングサイクルに対して料金を支払うことになります。

これまで、AI / ML の実務担当者は、ニッチなゾーンストレージシステムの専門的なパフォーマンスと、Google Cloud Storage のようなグローバルオブジェクトストアの信頼性とスケーラビリティのどちらかを選択する必要がありました。多くのデベロッパーは、Cloud Storage のシンプルさ、スケーラビリティ、信頼性、費用対効果を高く評価していますが、AI 時代の進展に伴い、より負荷の高いワークロードを Cloud Storage に投入し、何千もの GPU や TPU を使用してトレーニングや推論のワークロードを実行しています。従来のオブジェクトストレージでは対応できないパフォーマンスの転換点に達しているのです。Rapid ファミリーは、コンピューティングワークロードを高パフォーマンスのゾーンストレージと直接コロケーションするための複数のオプションを提供します。これにより、アクセラレータをブロックする可能性のある I/O ボトルネックを最小限に抑え、GPU と TPU をフル稼働させて生産性を維持できます。このブログ投稿では、Cloud Storage Rapid の機能について詳しく見ていきましょう。

Rapid Bucket

Rapid Bucket（一般提供）は、Cloud Storage が大規模な生成 AI、分析、その他の高パフォーマンスワークロードの進化する需要に対応できるよう支援します。これは、Gemini や YouTube を支える Google の分散ストレージシステムである Colossus を活用することで可能になっており、専用のオブジェクトストレージゾーンバケットにおいて、膨大な読み取り / 書き込みパフォーマンスと超低レイテンシを実現します。

超高速パフォーマンスブロック型ストレージのミリ秒未満のレイテンシ、並列ファイルシステムのスループット、オブジェクトストレージのスケーラビリティと使いやすさを兼ね備えた Rapid Bucket は、お客様がよくご存じの Cloud Storage と同じ環境で高パフォーマンスを提供します。

主な機能は次のとおりです。

超低レイテンシ: 最大 2,000 万の秒間クエリ数とミリ秒未満のレイテンシを実現します。
優れたスケーラビリティ: Rapid Bucket は、単一の Rapid ゾーンバケットから 15 TB/秒以上の合計読み取りスループットを実現します。
新しいセマンティクス: ネイティブな追加、無制限のリーダー（書き込み中も可能）、ベクトル化された読み取りなどの新機能により、パフォーマンスを向上できます。

AI と分析向けに最適化Rapid Bucket は、AI / ML データ準備、トレーニング、チェックポイント処理、バッチおよびストリーミング分析処理、分散データベースアーキテクチャの最適化など、さまざまな要求の厳しいシナリオで使用できます。

主な利点は次のとおりです。

アクセラレータ使用率の最適化: Rapid Bucket を使用すると、マルチモーダルトレーニング実行で GPU ブロック時間が 50% 削減され、データ読み込みが最大 2.5 倍高速化されることが確認されました。
高速なチェックポイント処理: Rapid Bucket を使用すると、従来のオブジェクトストレージと比較して、最大でチェックポイントの復元が 5 倍、書き込みが 3.2 倍高速化されます。これにより、ワークロードの中断からの復旧が迅速になり、アクセラレータ時間の無駄が最小限に抑えられ、全体的な効率が向上します。

Rapid Bucket によりチェックポイントの復元が最大 5 倍高速化

Rapid Bucket により、チェックポイントの書き込みが最大 3.2 倍高速化

Rapid Bucket の使用を開始するには、こちらをご覧ください。

Rapid Cache

Cloud Next ‘25 で最初に発表された Rapid Cache は、データ準備、トレーニング、推論用のバースト性の高いモデルの読み込みなど、AI / ML ワークロードの帯域幅を高速化し、コードを変更することなく、既存のバケットに対して 2.5 TB/秒の合計読み取りスループットを実現します。推論ワークロードの場合、Rapid Cache を使用すると、モデルの読み込みが最大 2.1 倍（114%）高速化され、TCO が 47% 削減されることが確認されています。

マルチリージョンバケットと組み合わせることで、単一のバケット名前空間を維持しながら、地理的なリージョン間に分散された GPU と TPU に柔軟にアクセスできます。これにより、バケット間のデータ移動を手動でオーケストレートする必要がなくなり、ゾーン内にコロケーションされた高パフォーマンスのメリットを享受できます。

新機能: 書き込み時の Rapid Cache 取り込み世界最大規模の最先端 AI / ML ラボのお客様から、チェックポイントの復元ワークロードや、トレーニングにフィードするデータ準備パイプラインなど、書き込み直後の読み取りを高速化する方法を探しているという声が寄せられました。以前は、データをキャッシュに保存するには、まず読み取りを行って取り込みをトリガーする必要があり、その際は、標準のパフォーマンスでバケットから直接提供されていました。

Rapid Cache の新しい書き込み時の取り込み機能は、Cloud Storage バケットへの書き込みと同時に Rapid Cache にデータを書き込むことで、この問題を解決します。このプロアクティブなアプローチにより、最初のキャッシュミスのペナルティが排除され、ワークロードは最初の読み取りで即座にキャッシュヒットの恩恵を受けることができます。これにより、チェックポイントの復元時間が最大 2.2 倍高速化され、トレーニングクラスタが中断からより迅速に復元できるようになります。

書き込み時の取り込みを有効にするには、既存の Rapid Cache の取り込み基準を変更するだけです。

Rapid Cache のシンプルさとパフォーマンスは、爆発的な導入につながっています。一般提供開始からわずか 1 年で、お客様は数千の Rapid Cache をデプロイし、デプロイされたキャッシュは 20 倍に増加しました。実際、Rapid Cache は Cloud Storage のグローバル外向きトラフィックの最大 20% を処理しています。最先端の AI / ML を利用するお客様は、ワークロードを Rapid Cache にデプロイしています。その一例が Anthropic です。同社は Rapid Cache を使用して、単一のゾーンに TPU とデータを配置し、最大 2.5 TB/秒の動的にスケーラブルな読み取りスループットを提供することで、クラウドワークロードの復元力を向上させています。

事例紹介: Thinking Machines LabThinking Machines Lab は、AI の研究とプロダクト開発を行う企業です。その使命は、適応性とカスタマイズ性に優れた AI システムを構築し、誰もが独自のニーズや目標に合わせて AI を活用できる知識やツールにアクセスできる未来を築くことです。

Next ‘26 では、Thinking Machines Lab のテクニカルスタッフである James Sun 氏が、セッション「Cloud Storage Rapid: AI と分析のための高速オブジェクトストレージ」に登壇し、Thinking Machines Lab が大規模な高パフォーマンスストレージのために実行する、データを大量に消費する AI / ML ワークロードのニーズについて発表しました。

Thinking Machines Lab は、Dataflow、Kafka、Spark でのデータ処理、マルチモデルトレーニング、オープンソースモデルのファインチューニング用の柔軟な API である Tinker のサービングなど、さまざまなワークフローを実行しています。Sun 氏の説明によると、Thinking Machines Lab のワークロードは Google Cloud Storage で実行されています。このようなデータ集約型の AI / ML ワークロードを大規模に実行すると、インフラストラクチャに大きな課題が生じます。

1 つ目の課題は、ハブアンドスポーク型のデータアーキテクチャの管理です。このアーキテクチャでは、データ処理ハブは 1 つのプライマリリージョンに配置され、トレーニング GPU は複数のリージョンに分散されます。これまで、手動によるデータの移動とライフサイクル管理は、運用上の大きな懸念点となっていました。さらに、Thinking Machines Lab のワークロード（データ準備や事前トレーニングのワークフローなど）は、マルチモーダルデータセットを準備するために大規模な Spark ワークロードに依存しており、コールドからホットに瞬時に急増することがよくあります。以前は、このような急増により、データ処理と読み込みが停滞し、重要なトレーニングサイクルが中断されるという、破壊的な 429 エラーが発生していました。

これらのボトルネックを最小限に抑えるため、Thinking Machines Lab は AI / ML パイプライン全体に Rapid Cache を統合し、良好な結果を得ました。

「Rapid Cacheは、当社の AI / ML データインフラストラクチャの中核的な基盤となっており、データの準備から、事前トレーニング、実際のトレーニング、モデルの読み込みに至るまで、重要なワークフローを支えています。重要な帯域幅のシールドおよびブースターとして機能し、迅速なイノベーションに必要なオンデマンドの高帯域幅と一貫した安定性を提供してくれるため、当社はフリート全体でデータ集約型のワークロードを妥協することなくスケールできます。」- Thinking Machines Lab、テクニカルスタッフ、James Sun 氏

要約すると、Cloud Storage と Rapid Cache によって、Thinking Machines Lab は次のメリットを得ています。

簡単、即時、スケーラブル、オンデマンドの帯域幅: チームは現在、1.8 TB/秒を超える安定した読み取りスループットのピークを達成しています。
安定性の向上: Rapid Cache により、テールエンドのレイテンシと 429 エラーが大幅に削減され、マルチモーダルトレーニングに必要な一貫したパフォーマンスが提供されます。
フリート全体のスケーラビリティ: マルチリージョンバケットと組み合わせることで、データ集約型ワークロードをフリート全体にわたってスケールできるようになりました。手動でデータを移動する手間をかけずに、急速に拡大するコンピューティング規模の需要に対応しながら、ゾーンでコロケーションされたストレージによる高パフォーマンスのメリットを享受できます。
運用効率: 階層型名前空間（HNS）の使用により、ディレクトリ名の高速変更をサポートし、クラスタをスケールアウトする際に QPS をより迅速にランプアップできるようになり、データ準備のための大規模な Spark ワークロードが最適化されました。Rapid Cache の「書き込み時の取り込み」機能により、チェックポイントの復元時にキャッシュヒットが即座に発生します。

ビジネスを加速させる最適なプロダクトをお選びください

データ準備、大規模なトレーニング、低レイテンシの推論のいずれを実行する場合でも、Cloud Storage Rapid は、Cloud Storage の特徴である信頼性とスケーラビリティとともに、高いパフォーマンスを提供します。

Rapid Bucket は、Cloud Storage のスループットと秒間クエリ数が最も高く、分析、AI トレーニング、チェックポイント処理、モデル提供などの読み取り / 書き込みのユースケースでレイテンシが最も低くなります。これにより、ストレージのボトルネックを減らし、コンピューティングの利用率を高めることができます。
Rapid Cache は、コードを変更することなく、既存のバケットで読み取り帯域幅の向上とテールレイテンシの安定化を実現します。主なユースケースには、AI トレーニング、チェックポイントの復元、サービング、マルチリージョンバケットによるアクセラレータのオプションなどがあります。

Cloud Storage Rapid ファミリーの利用を今すぐ開始しましょう。

- シニアプロダクトマネージャー、Marco Abela

- シニアプロダクトマネージャー、Luigi Pontes

Next ‘26 で発表した AI ワークロードを加速するストレージイノベーション

Mon, 18 May 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 4 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud Next では、ストレージスタックのあらゆるレイヤ（パフォーマンス、インテリジェンス、管理など）にわたるイノベーションを発表しました。これらは、構築する AI モデル、アプリ、エージェントと同様に、データも高速かつ有用なものにすることを見据えたものです。

利点: ストレージはもはや、単にデータを保管する場所ではありません。AI モデルのトレーニングにおいて、ストレージはデータを大量に消費するアクセラレータにデータを供給するエンジンとなります。AI 推論の際には、AI エージェントが効果的に機能するために必要なコンテキストのソースとして機能し、応答性を高めるアクセスレイヤとなります。ストレージのパフォーマンスが不足すると、アクセラレータはアイドル状態になり、エージェントの応答は遅くなり、データは AI モデルから見えない状態のままになります。

しかし、ストレージのパフォーマンスを上げるだけでは不十分であり、スマートに機能させる必要もあります。ストレージレイヤに直接統合された Google AI モデルを活用することで、単にビットを保存するのではなく、コンテンツに関する完全なコンテキストを持つデータを保存できるようになります。このスマートストレージの新時代において、元データは、さまざまなダウンストリーム AI やエンタープライズアプリケーションですぐに利用できる貴重な資産となります。

最新情報:

高性能ストレージインフラストラクチャ: 高性能オブジェクトストレージを実現する Cloud Storage の新しい Rapid ファミリーは、パフォーマンスを 10 倍向上させるとともに、Google Cloud Managed Lustre 向けに費用対効果の高い新しい Dynamic ティアを提供します。
Smart Storage: 自動化されたメタデータアノテーションと MCP を介した AI エージェントとの連携により、非構造化データの価値を引き出します。
Storage Intelligence: 構成不要のダッシュボード、集約されたアクティビティビュー、強化されたバッチオペレーションにより、データマネジメントを効率化します。
エコシステムの強化: Google Cloud NetApp Volumes、Filestore for GKE、および Google のバックアップとデータ保護のポートフォリオ全体で機能を拡張しました。

今週発表されたストレージの機能強化について詳しく見ていきましょう。

AI の進化に対応するストレージインフラストラクチャ

AI モデルのスケーリングに伴い、ストレージからコンピューティングレイヤに十分な速度でデータを転送することがボトルネックになる可能性があります。新しいストレージ機能により、パフォーマンスがストレージレイヤに直接組み込まれるため、総所有コスト（TCO）が削減され、アクセラレータを最大限に活用し続けることができるようになります。

Cloud Storage RapidCloud Storage のようなクラウドベースのオブジェクトストレージは、スケーラブルで費用対効果に優れていますが、ボトルネックが発生すると AI ジョブが停止し、高価なコンピューティングサイクルが無駄になる可能性があります。トレーニングクラスタが読み取りを待機したり、チェックポイントの書き込みが停止したりするたびに、有用な作業を行っていないアクセラレータに対して料金を支払うことになります。

Cloud Storage Rapid は、AI インフラストラクチャの設計において抜本的な転換をもたらします。オブジェクトストレージの信頼性を優先するか、AI 専用ストレージシステムの高い性能を優先するかといった取捨選択をする必要がなくなるからです。Cloud Storage Rapid を使用すると、業界をリードする耐久性、大規模な分散型スケール、費用対効果の高いオブジェクトストレージの自動階層化を活用しながら、極めて高いスループット、頻繁な I/O、超低レイテンシを実現できます。PyTorch と JAX にネイティブに統合された Cloud Storage Rapid は、人気のある AI / ML エコシステムフレームワークですぐに使用できるよう最適化されているため、データ準備、トレーニング、推論のワークロードを高性能かつ信頼性の高い基盤上で実行できます。

Cloud Storage Rapid ファミリーには、Rapid Bucket と Rapid Cache の 2 つのサービスがあります。

Rapid Bucket はすでに一般提供を開始しています。Gemini や YouTube を支える Google の分散ストレージシステムである Colossus を活用することで、単一のゾーンバケットにおいて 15 TB/秒を超える帯域幅、1 秒あたり 2,000 万件のリクエスト、1 ミリ秒未満のレイテンシを実現します。高性能な gRPC と S3 互換 API を介してアクセスできる Rapid Bucket は、マルチモーダル学習におけるアクセラレータ使用率の向上により、GPU ブロック時間を 50% 削減し、データ読み込みを 2.5 倍高速化します。従来のオブジェクトストレージと比較して、チェックポイントの復元は 5 倍、チェックポイントの書き込みは 3.2 倍高速化され、ワークロードの中断や GPU の無駄な時間を削減します。

Rapid Bucket により、チェックポイントの書き込みが 3.2 倍、復元が 5 倍高速化

Rapid Cache（旧称 Anywhere Cache）は、推論用のモデルの読み込みなど、バースト性の高いワークロードの帯域幅を高速化し、コードを変更することなく、既存のバケットに対して 2.5 TB/秒の合計読み取りスループットを実現します。新しい書き込み時取り込み機能により、チェックポイントの復元が最大 2.2 倍高速化され、トレーニングクラスタが中断からより迅速に復元できるようになります。Rapid Cache は、そのシンプルさとパフォーマンスの組み合わせにより、最先端の AI / ML を利用する Thinking Machines Lab のようなお客様に広く採用されています。「Rapid Cacheは、当社の AI / ML データインフラストラクチャの中核的な基盤となっており、データの準備から、事前トレーニング、実際のトレーニング、モデルの読み込みに至るまで、重要なワークフローを支えています。重要な帯域幅のシールドおよびブースターとして機能し、迅速なイノベーションに必要なオンデマンドの高帯域幅と一貫した安定性を提供してくれるため、当社はフリート全体でデータ集約型のワークロードを妥協することなくスケールできます。」- Thinking Machines Lab、テクニカルスタッフ、James Sun 氏

Google Cloud Managed LustreLustre 並列ファイルシステムは、AI のトレーニングと推論のワークロードで高スループットとミリ秒未満のレイテンシを必要とする組織にとっての業界標準となっています。世界中の AI ラボや HPC センターから信頼を得ており、数千のアクセラレータに同時にフィードでき、高負荷状態でも飽和状態を維持できることが評価されています。Google Cloud Managed Lustre は、その機能をフルマネージドサービスとして提供します。Next ‘26 では、クラウドで利用できるマネージド Lustre サービスの中で最も高いパフォーマンスを発揮できることを紹介しました。

Managed Lustre は現在、最大 10 TB/秒のスループットを実現しています。これは昨年比で 10 倍の向上であり、単一インスタンスにおける他のハイパースケーラーのマネージド Lustre サービスと比較して 4～20 倍高い数値です。C4NX VM と Hyperdisk Exapools を活用した Managed Lustre は、他の Google Cloud ストレージソリューションと比較して、チェックポイントの書き込みと復元が 2.6 倍高速です。

新しい Dynamic ティア（$0.06/GB-月）は、トレーニングやチェックポイント処理といった負荷の高い AI ワークロードに必要な低レイテンシのパフォーマンスを提供します。オブジェクトベースのキャッシュに依存するのではなく、永続ディスクからデータをサービングすることで、パフォーマンスの急激な低下をなくし、データの応答性を維持し、アクセラレータの生産性を確保します。単一の SKU により、従来のデータ階層化に見られる複雑な要素を排除し、シンプルで予測可能な料金体系を実現します。

「Managed Lustre を統合することで、典型的なオンボーディングのボトルネックが解消され、推論ワークロードを迅速に実行できるようになりました。この高スループット、低レイテンシのストレージにより、B200 GPU では完全に飽和状態が維持され、H200 と比較して LLM の推論で大幅なパフォーマンスの向上を実現できています。当社のお客様にとって、このパフォーマンスは、従来よりもはるかに低いレイテンシで複雑な推論を処理できる、より高速で応答性の高い AI エージェントの実現へと直結します。」 - Salesforce、ソフトウェアエンジニアリング PMTS、Lavnaya Karanam 氏

Smart Storage: AI 時代のコンテキスト

Cloud Storage のようなオブジェクトストレージシステムの魅力は、長らくそのシンプルさにありました。システムはオブジェクトの名前、サイズ、作成日時を把握しています。しかし、オブジェクトの内容（参照しているエンティティ、機密性の高い個人情報（PII）が含まれているかどうか、保留中のクエリに関連しているかどうかなど）を把握するには、カスタムパイプライン、個別のデータベース、カスタムメイドの拡充システムを使用する必要がありました。

AI はこの状況を一変させました。モデルをファインチューニングするには、数百万ものコーパスの中から適切なオブジェクトを最初から選択する必要があります。エージェントを構築するには、それぞれの意思決定において適切なコンテキストを取得することが必要です。コンプライアンスの義務を果たすには、法的責任が発生する前に、すべてのファイルの内容をあらかじめ把握しなければなりません。いずれの場合も、ボトルネックとなるのは計算能力やモデルの品質ではなく、オブジェクトを大規模に記述、検索、処理できない点にあります。

昨年発表した Smart Storage は、保存されているデータと利用可能なデータのギャップを埋めることを目的としています。Cloud Storage に直接組み込まれており、すべてのオブジェクトを自己記述型にします。このたび、Smart Storage に以下の機能を追加しました。

自動アノテーション: カスタムアノテーションパイプラインの構築や維持管理が不要になります。Smart Storage を有効にすると、Cloud Storage は画像アノテーションなどのコンテキストを自動的に生成できるようになり、データが保存された瞬間から検出と利用が可能になります。アノテーションにかかる費用の発生は書き込み時の一度だけで、オブジェクトの存続期間中、すべてのダウンストリームシステムがそれらのアノテーションを即座に利用できます。
Cloud Storage MCP サーバー: 標準の MCP プロトコルを使用して Cloud Storage データの読み取り、書き込み、分析を行うことができます。

Smart Storage は、このたび一般提供を開始したオブジェクトコンテキストを活用して、これらの機能をはじめとするさまざまな機能を実現します。このメタデータ基盤により、すべてのオブジェクトに対して、構造化された変更可能な IAM 管理のコンテキストが追加されます。ユーザーは独自のタグや分類を作成できます。ラベル、抽出されたエンティティ、コンプライアンスシグナルは、Google のアノテーションパイプラインで自動的に付加されます。

Smart Storage を利用すれば、ML チームは、検索パイプラインを構築することなく、セマンティックな基準に基づいてトレーニング用データセットを選択できます。AI エージェントは、別の検索レイヤを必要とせずに、エンタープライズデータに基づいて推論をグラウンディングできます。

Storage Intelligence: AI に対応したデータマネジメント

データ資産が数百ペタバイト規模にまで拡大すると、ストレージ費用が想定外に急増し、数十億のオブジェクトにわたってセキュリティの盲点が増える可能性があります。これを管理するには、自社のデータに関する基本的な課題に対処するためだけでも、複数のツールを組み合わせる必要があります。

Google は昨年、統合管理エクスペリエンスを Cloud Storage に直接組み込んで提供する Storage Intelligence をリリースしました。現在、Google の最大規模のお客様の 70% に利用されており、それぞれ 500 億個以上のオブジェクトが管理されています。

Storage Intelligence では、プロジェクトや組織全体を単一のビューで把握できるほか、リージョンをまたいだバケットの再配置といった独自の機能を利用できます。こうした機能に加えて、このたび、Storage Intelligence の機能を大幅に強化しました。

新しい構成不要のダッシュボード: 費用の異常を即座に把握できるほか、Security Command Center のデータセキュリティポスチャー管理（DSPM）データガバナンス機能が統合されているため、Cloud Storage 全体にわたって重大なセキュリティの脆弱性を検出できます。設定作業は一切不要です。
分析情報データセットの新しいオブジェクトイベントおよびバケットアクティビティテーブル: より詳細な費用分析が可能になり、運用タスクを加速できます。これらの分析情報を使用することで幅広い分析を行えます。たとえば、下り（外向き）パターンに基づいてバケット配置を最適化したり、影響を受けるオブジェクトを特定して 429 エラーを迅速にトラブルシューティングしたりできます。
バッチオペレーションの強化: 新しい ACL 変更やストレージクラスオペレーション、マルチバケットオペレーションのサポートにより、数十億のオブジェクトに対してますます容易にアクションを実行できるようになりました。

ストレージエコシステムの強化

中核となるストレージサービスに加え、データをクラウドに移行する方法や保護する方法を効率化しました。

Google Cloud NetApp Volumes: Flex Unified のリリースに伴い、NetApp Volumes ではデータセンターとクラウドを橋渡しする統合エンタープライズストレージプラットフォームが提供されるようになりました。これによって、同一のストレージプール上でブロック（iSCSI、NVMe/TCP）とファイル（NFS / SMB）の両方をプロビジョニングできます。新しい ONTAP モードでは、既存の自動化ツール（Terraform、Ansible）や ONTAP API を NetApp Volumes に直接取り込むことができます。
Filestore for GKE: Google Kubernetes Engine（GKE）で AI ワークロードを構築する際、100 GiB 程度の小規模な共有から始めることができます。容量と IOPS は個別にスケールできます。また、Colossus 分散ファイルシステムとの緊密な統合により、スケーリング機能とエンタープライズ機能が強化されています。
データ保護: Google Cloud Backup and DR に、バックアップアセットを自律的に監査し、カバレッジのギャップを修復できるエージェント型 AI 機能を追加しました。すでに一般提供されている AlloyDB と Filestore の新しいインテグレーションも利用できます。

導入の第一歩

AI の新時代を迎えるなか、ストレージ基盤には、より大規模でインテリジェントかつ自律的なモデルをサポートできることが求められています。Google Cloud のストレージプラットフォームは、高性能でインテリジェントな最新のストレージレイヤ、強化されたストレージ管理ツール、より堅牢なデータ保護基盤を備えており、これまで不可能だった方法でエンタープライズデータを理解できます。これにより、以下のようなことが可能になります。

AI データのボトルネックの解消: コンピューティングリソースを最大限に活用し、費用対効果を加速させます。卓越したパフォーマンスを提供する高スループットストレージによって大規模なトレーニングや推論に対応できるほか、高価な GPU や TPU を常に最大限に活用できます。
エージェント対応のデータ基盤の構築: カスタムパイプラインの構築から、アクティブなナレッジベースへと移行します。自己記述型オブジェクトによって、AI エージェントが手動での準備なしにデータを即座に推論できるようになります。
エクサバイト規模のデータにおける盲点の最小化: 断片化された管理ツールを、構成不要のダッシュボードとデータセットに置き換え、数十億のオブジェクトにわたる費用の異常やセキュリティリスクを即座に明らかにします。
ストレージエコシステムの活用: 移行と保護を効率化します。データセンターとクラウドを連携させ、コンテナ化されたアプリケーションをスケールし、エージェント型 AI でデータレジリエンスを自動化しましょう。

Google Cloud Storage コンソールにアクセスしてこれらの新機能をお試しください。Cloud Storage Rapid の詳細と、Next '26 のストレージのセッションもご覧ください。

- Google Cloud、ストレージ担当 VP 兼 GM、Sameet Agarwal

- Google Cloud、プロダクト管理担当シニアディレクター、Asad Khan

エージェント型エンタープライズのためのクロスクラウドインフラストラクチャのイノベーション

Fri, 08 May 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 4 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

エージェント型 AI の時代が人間の速度から機械の速度へと運用を加速させていますが、それと同時に、以前のテクノロジーインフラストラクチャに深刻なストレスを与えています。数千もの内部メッセージと複雑なクエリを生成するエージェントが、しかもさらに多くのエージェントを生み出すという新たな現実は、基盤となるシステムを限界に追い込んでいるのです。この状況の中、従来のネットワークやデータベースでは瞬く間に手に負えなくなり、新たなセキュリティ脆弱性が顕在化する可能性があります。

エージェントの時代に AI の可能性を最大限に引き出すには、安全で適応性の高い基盤が必要です。Google ではこれを、エージェント型エンタープライズ向けクロスクラウドインフラストラクチャと呼んでいます。Google は Google Cloud Next ‘26 で、このインフラストラクチャの 4 つの分野における一連の新しいイノベーションを発表します。

最新情報:

Fluid Compute: Google Compute Engine サービスと Kubernetes サービスの連携により、新しいコンピューティング機能とオーケストレーション機能が追加されます。これらの機能は、費用対効果と速度に優れた AI エージェントとエンタープライズワークロードを実現するものです。
安全なクロスクラウド接続: Agent Gateway、Cloud Armor などのツールで、AI エージェント向けの安全で管理されたネットワーキング基盤を簡素化します。この基盤には、クラウド間のエージェントトラフィックのオブザーバビリティも組み込まれています。
統合データレイヤ: スマートストレージ、Knowledge Catalog などのイノベーションで、受動的なデータアーカイブを動的な推論エンジンへと変換します。この推論エンジンが、実行に必要となるコンテキストを AI エージェントに渡します。
デジタル主権: Confidential External Key Management と、Google Distributed Cloud の新機能により、データの保存場所を問わずに Google の最先端のモデルと AI イネーブラーを利用できるようになります。

これら 4 つの分野それぞれの最新ニュースを詳しくご紹介します。

Fluid Compute

エージェントワークロードは動的であり、予測することはできません。このことは、従来のエンタープライズアプリケーションにも AI エージェント自体にも影響を与えます。そこで、Fluid Compute を実現するために、Google Compute Engine サービスと Google Kubernetes サービスが連携して動的にワークロードに適応し、リアルタイムで重みをシフトします。これにより、すべてのお客様にとって、費用対効果と速度に優れた AI エージェントとエンタープライズ向け運用ワークロードの実現が可能になります。

AI Hypercomputer が大規模な AI モデルトレーニング向けの素の処理能力を提供する一方で、Fluid Compute によって運用ワークロードとエージェントのニーズに対応します。エージェントが推論と強化学習へと移行する中、CPU は中心的な役割を取り戻しつつあります。CPU は、エージェントワークフローに必要な「分岐」ロジック、複雑な制御フロー、安全なコード実行サンドボックス（エージェントオーケストレーション、RL、SLM 推論、RAG 向けのサンドボックスなど）において優れた能力を発揮するためです。さらに、CPU はエージェントを安全に実行するために重要となるエージェントの隔離を可能にし、トレーニングで使用される GPU と TPU の並列処理能力を補完します。

Google は、従来のワークロードと AI エージェントを安全かつ大規模に実行できるようにするための新しい CPU ファミリー、GKE 機能、Hyperdisk ブロックストレージ機能を導入しています。

Google C4N シリーズ: このシリーズの VM は、エージェント型 AI の需要によってエンタープライズワークロードの速度が低下しないように、1 秒あたり最大 9,500 万パケットを処理します。これは、他の主要なハイパースケーラーと比べて最大 40% 高速なパフォーマンスです。これにより、セキュリティアプライアンス、ストリーミングメディア、オープンソースデータベースなどの要求の厳しいワークロードで、より小さいインスタンスサイズを使用するとしても、I/O ボトルネックが解消されます。
Hyperdisk Extreme を使用した Google M4N シリーズ: M4N は、エージェント、分析、ミッションクリティカルなデータベースからの膨大なデータ I/O の処理のニーズに対処するために、データパイプラインのボトルネックを解消してオーバープロビジョニングの必要をなくし、業界トップクラスのコアあたりの IOPS とスループットを実現しています。vCPU あたり 26.57 GB の RAM を提供する M4N を使用すれば、ミッションクリティカルなワークロードをより少ないコアでスケールして、優れた費用対効果を実現できます。たとえば、Hyperdisk Extreme を使用した M4N は、主要なハイパースケールクラウドと比較して、Oracle ワークロードの総所有コストを 20% 以上削減します。
GKE Agent Sandbox: このソリューションは、信頼できる gVisor でエージェントを隔離して保護し、クラスタごとに 1 秒あたり最大 300 個のサンドボックスを起動して需要の急増に対応します。GKE Agent Sandbox は、主要なハイパースケールクラウドの間で唯一利用可能なマネージドサンドボックステクノロジーを基盤としています。GKE Agent Sandbox で Google Axion N4A を使用して AI エージェントを実行する場合、競合他社よりも最大 30% 優れたコストパフォーマンスを実現します。

「Wayfair の AI 戦略は、Google Cloud での長年にわたる体系的なインフラストラクチャモダナイゼーションに基づいて構築されています。この戦略には、コアの e コマースエンジンとデータベースをレガシーシステムから移行すること、モノリシックなサービスをクラウドネイティブアーキテクチャに分解すること、データと分析プラットフォームを統合することが含まれています。Gemini Enterprise Agent Platform という基盤があるからこそ、他のすべてが可能になります。現在、カタログの拡充から、お客様が自分にぴったりの家を建てられるよう生成 AI が支援するショッピングエクスペリエンスまで、あらゆるものを Gemini Enterprise Agent Platform によって強化しています。また、私たちはこの同じ基盤を頼りに、AI が単に支援するだけでなく、あらゆる顧客タッチポイントとビジネス全体で積極的に発見、パーソナライズ、コマースを推進するエージェントとなる時代に向けて準備を整えています。」- Wayfair、最高技術責任者、Fiona Tan 氏

最新のコンピューティングイノベーションについては、こちらのブログ記事をご覧ください。

安全なクロスクラウド接続

エージェント型 AI は、予測可能な人間のリクエストを自律的な「推論ループ」に置き換えます。このループでは、エージェントが他のエージェントを呼び出し、そのエージェントが LLM を呼び出すため、コンピューティングとマシン間のトラフィックが急増することになります。こうしたエージェント型へのシフトは、ネットワークの予測可能性と人間以外の ID のセキュリティに関して他には見られない課題をもたらします。エージェント型 AI 向けに最適化されたクロスクラウドネットワークは、さまざまな環境間でデータを移動して、可視性とセキュリティによって従業員、顧客、エージェントをつなげます。クロスクラウドネットワークの新機能は次のとおりです。

Agent Gateway: Gemini Enterprise Agent Platform の「航空管制官」として、企業のエージェントトラフィックを管理およびオーケストレートします。MCP や A2A などのエージェントプロトコルをネイティブに理解し、すべてのエージェントのやり取りを検査して管理します。Google とサードパーティの ID および AI の安全性に関するサービスと連携して、アクセスの検証、攻撃のブロック、機密データの保護を目的とした詳細な検査を可能にし、コアビジネス全体でコンプライアンスを維持します。
Cloud Network Insights: ハイブリッドクラウドとマルチクラウドのインフラストラクチャ全体にわたる幅広い可視性を提供し、トラブルシューティングとネットワーク解決を迅速化します。Google Cloud、AWS、Azure、データセンター、インターネットアプリケーション、エージェントワークロード全体で、エージェント、ネットワーク、ウェブのエンドツーエンドのパフォーマンスを継続的にモニタリングします。Cloud Network Insights は、合成トラフィック分析を使用して、ホップごとのネットワークパスを可視化し、パフォーマンス低下の原因を特定できるよう支援します。また、オペレーションの自律性を高めるために、Cloud Network Insights には Gemini Cloud Assist の AI を活用した分析情報が結合されます。
強化された Cloud Next Generation Firewall（NGFW）と Cloud Armor: AI が生成するポリモーフィックマルウェアやゼロデイエクスプロイトの急増に対処するために、AI を活用した機械の速度での保護を提供します。Cloud NGFW の高度なマルウェアサンドボックスは、AI によって生成された脅威をリアルタイムでその場で防止します。一方、Cloud Armor のマネージドルールは、既知および未知の共通脆弱性識別子（CVE）の両方に対する自動保護を提供します。これらのサービスは Model Armor と連携して、AI エージェントのコミュニケーションのインテントと内容を分析します。

Google がデータセンター内外で AI 向けにネットワーキングを最適化した方法について詳しくは、こちらをご覧ください。

統合データレイヤ

AI エージェントの能力は、アクセスできるデータと与えられたコンテキストによって決まります。構造化データと非構造化データを使用するアプリケーションやプラットフォームが増えていますが、それらのデータを大規模にカタログ化、検索、活用するのは容易なことではなく、それが原因でエージェントの対応が非効率になる可能性があります。このギャップを埋めるためにエージェントに必要となるのは、すべてのデータがまとめられたクエリ可能なナレッジエンジン、つまり統合データレイヤです。これにより、エージェントは正確な情報源を特定してアクセスできるようになります。Next ‘26 では、統合データレイヤを強化する次の機能を取り上げます。

スマートストレージ: このソリューションは、新しいセマンティックインテリジェンスをデータオブジェクトに直接埋め込むことで、ダークデータを AI エージェントとトレーニングのための強力な知識アセットに変換します。自動アノテーション、エンティティ抽出、セマンティック検索などの新しい Google Cloud Storage 機能により、エージェントは必要とする特定のデータが組織全体にわたって存在するスプレッドシート、PDF、その他の非構造化形式のどれに隠されているかどうかにかかわらず、そのデータを瞬時に検出して使用できます。これにより、AI ソリューションの開発とデプロイが大幅にスピードアップします。AI ワークロードを加速するストレージイノベーションについて詳しくは、こちらをご覧ください。
Knowledge Catalog: Knowledge Catalog は、エージェントが最も正確な結果を提供できるように、データエステート全体にわたってビジネスの意味をマッピングし、グラウンディングされた信頼できる情報源を提供します。この基盤により、AI のトレーニングと推論が可能になり、データの移行が不要になります。エージェントは、データがどこにあっても、完全なコンテキストとガバナンスに沿って直接データとやり取りするため、モダナイゼーションが容易になります。

Google の Agentic Data Cloud の一部となっているスマートストレージと Knowledge Catalog により、データを受動的なアーカイブから動的な推論エンジンに変換できます。

「お客様のスマートホームとセキュリティソリューションをよりインテリジェントで便利なものにするためには、AI が不可欠です。Google Cloud のスマートストレージを活用すれば、BigQuery で配信される豊富なメタデータに自動的にアノテーションを付けることができます。データ検出とキュレーションの取り組みを拡大し、加速させたことで、AI 開発プロセスを数か月から数週間に短縮できたと同時に、信頼を築き、全体的な家庭環境を向上させるイノベーションを継続的に提供できるようになりました。」- Vivint、プロダクトおよび AI 担当バイスプレジデント、Brandon Bunker 氏

デジタル主権

エージェントの時代において、管理を犠牲にすることなくイノベーションを加速させようと目指す公共部門や企業のお客様にとって、デジタル主権は基本的な要件です。万能なソリューションというものは存在しません。そのため、Google ではパブリッククラウド、オンプレミス、ハイブリッドなど、あらゆる場所でさまざまなソブリン AI のニーズに対応できるよう、包括的な一連のサービスを設計しました。Google のソブリン AI ポートフォリオの新機能には、次のようなものがあります。

Confidential External Key Management: 組織は Confidential External Key Management を使用して、暗号鍵の完全な未編入領域、管理権、制御権と、暗号鍵を管理するポリシーを維持できます。Confidential External Key Management は、Confidential Compute を活用して、Google Cloud 内の改ざん防止環境で鍵管理エンドポイントをホストします。鍵の保存場所、鍵へのアクセスを許可するユーザー、アクセスを許可する状況は、お客様が管理できます。特権を持つ Google 管理者であっても、承認なしに鍵にアクセスすることはできません。また、承認はいつでも取り消すことができます。自社のデータを自社で管理できるというわけです。
Google Distributed Cloud 上の Gemini: GDC 上の Gemini を使用すると、企業はデータ主権のニーズを満たしながら、機密性の高い環境に Gemini を安全にデプロイできます。デプロイモデルの選択肢には、接続されたハードウェア上のマネージドソフトウェアや、エアギャップのある完全に切断されたソリューションなどがあります。最も制限の厳しい高度なセキュリティ環境であっても、強力な Gemini モデルから高度なコーディング、検索、その他のエージェント機能に至るまでの Google の最先端の AI 機能によるスケーリングが可能になりました。

さらに、すべてのソブリン AI ワークロードを加速および強化できるよう、Google Distributed Cloud では最新世代の AI インフラストラクチャと Gemini モデルを組み合わせたエンドツーエンドの AI スタックをサポートしています。このスタックには以下が含まれます。

NVIDIA Blackwell GPU: NVIDIA Blackwell（NVIDIA HGX B200）および NVIDIA Blackwell Ultra プラットフォーム（NVIDIA HGX B300）GPU は、第 5 世代 NVIDIA NVLink を活用して AI パフォーマンスを加速し、データセンター規模の帯域幅を環境に直接提供します。
新しい VM ファミリー: 新しい A4 ファミリーパッケージは、最も要求の厳しい推論タスクを処理する能力を提供し、ピーク時のコンピューティングを 2.25 倍に向上させます。メモリ最適化 M2 および M3 は、オンプレミスで大規模な ERP とデータ分析のワークロードに必要となる高いメモリ対 vCPU 比を実現します。
ストレージの強化: ゾーンあたりのストレージ容量が 6 倍に増え、パフォーマンスは 10 倍に向上しています。これによりストレージのボトルネックが解消されるため、オンプレミスで AI 推論を実行できます。今や、データインフラストラクチャは AI 推論のスピードで進化しています。

「弊社のお客様は、マルチテナントのリスクを伴わない、高性能なプライベート AI 推論を求めています。Google Distributed Cloud を使用すれば、機密データに関する厳格な要件を満たす、専用の低レイテンシ環境を提供できます。B200 と B300 で Gemini を実行できるため、推論速度を大幅に向上させ、スケーリングに必要となるトークンスループットをお客様に提供できます。」- Cirrascale Cloud Services、CEO / 共同創設者、Dave Driggers 氏

ビジョンを現実にする

以上の製品分野が収束した時点で、インフラストラクチャはエージェント時代に対応する高性能で安全かつ適応性のある基盤へと進化します。Google は単にツールを提供するだけでなく、企業や公共部門が AI とエージェントの力を最大限に活用できるようにするためのアーキテクチャブループリントを提供しています。

AI インフラストラクチャの主要な業界トレンドについて詳しくは、エージェント型 AI 時代のインフラストラクチャの現状に関するレポートをご覧ください。

- コンピューティングプラットフォーム部門プロダクト管理担当バイスプレジデント、Nirav Mehta

- Google Distributed Cloud 担当バイスプレジデント、Muninder Sambi

新しい GKE Cloud Storage FUSE プロファイルにより、AI ストレージの構成における当て推量が不要に

Thu, 16 Apr 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 4 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

AI / ML の世界では、データはトレーニングと推論のワークロードに欠かせない要素です。Google Kubernetes Engine（GKE）ユーザーは、Cloud Storage FUSE を使用して Google Cloud Storage に保存されているデータに高いパフォーマンスでスケーラブルにアクセスできます。しかし、Cloud Storage FUSE のパフォーマンスを最大限に引き出すのは複雑な場合がある、というお客様の声が寄せられていました。

このたび、GKE Cloud Storage FUSE プロファイルが導入されました。この新機能は、運用オーバーヘッドを最小限に抑えながら、パフォーマンス調整を自動化し、AI / ML ワークロード（トレーニング、チェックポイント、推論）のデータアクセスを高速化するように設計されています。特定のワークロードのニーズに合わせて調整されたこれらのプロファイルを使用すると、Cloud Storage FUSE の高いパフォーマンスをすぐに活用できます。

導入前（手動調整）

code_block: <ListValue: [StructValue([('code', 'apiVersion: v1\r\nkind: PersistentVolume\r\nmetadata:\r\n name: serving-bucket-pv\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n capacity:\r\n storage: 64Gi\r\n persistentVolumeReclaimPolicy: Retain\r\n storageClassName: ""\r\n claimRef:\r\n name: serving-bucket-pvc\r\n mountOptions:\r\n - implicit-dirs\r\n - metadata-cache:ttl-secs:-1\r\n - metadata-cache:stat-cache-max-size-mb:-1\r\n - metadata-cache:type-cache-max-size-mb:-1\r\n - file-cache:max-size-mb:-1\r\n - file-cache:cache-file-for-range-read:true\r\n - file-system:kernel-list-cache-ttl-secs:-1\r\n - file-cache:enable-parallel-downloads:true\r\n - read_ahead_kb=1024\r\n csi:\r\n driver: gcsfuse.csi.storage.gke.io\r\n volumeHandle: BUCKET_NAME\r\n volumeAttributes:\r\n skipCSIBucketAccessCheck: "true"\r\n gcsfuseMetadataPrefetchOnMount: "true"\r\n---\r\napiVersion: v1\r\nkind: PersistentVolumeClaim\r\nmetadata:\r\n name: serving-bucket-pvc\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n resources:\r\n requests:\r\n storage: 64Gi\r\n volumeName: serving-bucket-pv\r\n storageClassName: ""\r\n–--\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n name: gcs-fuse-csi-example-pod\r\n annotations:\r\n gke-gcsfuse/volumes: "true"\r\nspec:\r\n containers:\r\n # Your workload container spec\r\n ...\r\n volumeMounts:\r\n - name: serving-bucket-vol\r\n mountPath: /serving-data\r\n readOnly: true\r\n serviceAccountName: KSA_NAME \r\n volumes:\r\n - name: gke-gcsfuse-cache # gcsfuse file cache backed by RAM Disk\r\n emptyDir:\r\n medium: Memory \r\n - name: serving-bucket-vol\r\n persistentVolumeClaim:\r\n claimName: serving-bucket-pvc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f339cece100>)])]>

導入後（Cloud Storage FUSE のマウントオプション、CSI 構成、ファイルキャッシュメディアが自動的に構成されます）

code_block: <ListValue: [StructValue([('code', 'apiVersion: v1\r\nkind: PersistentVolume\r\nmetadata:\r\n name: serving-bucket-pv\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n capacity:\r\n storage: 64Gi\r\n persistentVolumeReclaimPolicy: Retain\r\n storageClassName: gcsfusecsi-serving\r\n claimRef:\r\n name: serving-bucket-pvc\r\n csi:\r\n driver: gcsfuse.csi.storage.gke.io\r\n volumeHandle: BUCKET_NAME\r\n---\r\napiVersion: v1\r\nkind: PersistentVolumeClaim\r\nmetadata:\r\n name: serving-bucket-pvc\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n resources:\r\n requests:\r\n storage: 64Gi\r\n volumeName: serving-bucket-pv\r\n storageClassName: gcsfusecsi-serving\r\n–--\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n name: gcs-fuse-csi-example-pod\r\n annotations:\r\n gke-gcsfuse/volumes: "true"\r\nspec:\r\n containers:\r\n # Your workload container spec\r\n ...\r\n volumeMounts:\r\n - name: serving-bucket-vol\r\n mountPath: /serving-data\r\n readOnly: true\r\n serviceAccountName: KSA_NAME \r\n volumes: \r\n - name: serving-bucket-vol\r\n persistentVolumeClaim:\r\n claimName: serving-bucket-pvc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f339cece9a0>)])]>

Cloud Storage FUSE の最適化に伴う課題

高パフォーマンスのワークロード向けに Cloud Storage FUSE を最適化することは、多次元的な問題です。従来、ユーザーは数十ページに及ぶ手動構成ガイドを読み解く必要がありました。AI / ML の進化に伴い、Cloud Storage FUSE の機能も強化され、ワークロードを高速化するための新しいマウントオプションが利用できるようになりました。設定が「適切」かどうかは静的なものではなく、さまざまな動的要因に大きく左右されるものでした。

バケットの特性: データセットの合計サイズとオブジェクトの数は、メタデータとファイルキャッシュの要件に大きく影響します。
インフラストラクチャの多様性: GPU、TPU、汎用コンピューティングのいずれを使用するかによって、最適な構成は異なります。
ノードリソース: Cloud Storage への費用のかかるラウンドトリップを最小限に抑えるためにローカルにキャッシュ保存できるデータの量は、利用可能な RAM とローカル SSD の容量によって決まります。
ワークロードパターン: トレーニングワークロード（大規模データセットの高スループット読み取り）では、チェックポイントワークロード（バースト性が高い、高スループット書き込み）やサービングワークロード（レイテンシの影響を受けやすいモデルの読み込み）とは異なる調整が必要です。

実際、多くのお客様は、Cloud Storage FUSE の設定が最適化されていないか、誤って構成されているために、利用可能なパフォーマンスを十分に活用できていないか、信頼性の問題（Pod のメモリ不足による強制終了など）に直面しています。

GKE 向け Cloud Storage FUSE プロファイルの概要

GKE Cloud Storage FUSE プロファイルは、特定の AI / ML パターンに合わせてカスタマイズされた、事前定義された動的管理の StorageClass を使用して、この複雑さを簡素化します。数十ものマウントオプションを手動で調整する必要はなく、ワークロードのタイプに一致するプロファイルを選択するだけでかまいません。

これらのプロファイルは、階層化されたモデルで機能します。Cloud Storage FUSE の基本的なベストプラクティスをベースに、GKE 固有のインテリジェンスレイヤを追加します。プロファイルを使用して Pod をデプロイすると、GKE は自動的に次の処理を行います。

バケット（または特定のディレクトリ）をスキャンして、そのサイズとオブジェクト数を把握します。
ターゲットノードを分析して、利用可能な RAM、ローカル SSD、アクセラレータタイプを確認します。
最適なキャッシュサイズを計算し、最適なバッキングメディア（RAM またはローカル SSD）を自動的に選択します。

リリース時には、次の 3 つの主要なプロファイルが用意されています。

gcsfusecsi-training: GPU と TPU にデータを供給し続ける高スループットの読み取りに最適化されています。
gcsfusecsi-serving: モデルの読み込みと推論に最適化され、自動化された Rapid Cache 統合が可能です。
gcsfusecsi-checkpointing: 数ギガバイトの大きなチェックポイントファイルを高速かつ確実に書き込むように最適化されています。

GKE Cloud Storage FUSE プロファイルを使用すると、次のようなメリットがあります。

調整の簡素化: 複雑でエラーが発生しやすい手動構成が、3 つのシンプルな専用 StorageClass に置き換えられます。
リソースを認識した動的な最適化: CSI ドライバは、リアルタイムの環境シグナルに基づいてキャッシュサイズを自動的に調整するため、ノードの安定性を損なうことなくパフォーマンスを最大化できます。
読み取りパフォーマンスの向上: サービングプロファイルは Rapid Cache を自動的にトリガーし、データをコンピューティングの近くに配置して、コールドスタートモデルの読み込みを高速化します。
きめ細かなパフォーマンス分析情報: 構造化されたログを通じて自動調整の決定を可視化し、特定のキャッシュサイズとメディアが Pod に対して選択された理由を正確に把握できます。

GKE Cloud Storage FUSE プロファイルの推論プロファイルを使用することで、TPU（480 GB）上の Qwen3-235B-A22B ワークロードのモデル読み込み時間を 39 時間からわずか 14 分に短縮できました。これにより、お客様は Cloud Storage FUSE GCSFuse をすぐに使用して最大限のメリットを得ることができます。

GKE で Cloud Storage FUSE プロファイルを使用する方法

まず、Cloud Storage FUSE CSI ドライバが有効になっている GKE バージョン 1.35.1-gke.1616000 以降がクラスタで実行されていることを確認します。

1. StorageClass を特定する

GKE には、プロファイルベースの StorageClass がプリインストールされています。次のコマンドで確認できます。

code_block: <ListValue: [StructValue([('code', 'kubectl get sc -l gke-gcsfuse/profile=true'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f339cecec70>)])]>

2. PV と PVC を作成する

PersistentVolume を作成する際、Cloud Storage バケットを参照するようにします。GKE は、最適な構成を判断するためにバケットスキャンを自動的に開始します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: v1\r\nkind: PersistentVolume\r\nmetadata:\r\n name: gcs-pv\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n capacity:\r\n storage: 5Gi\r\n persistentVolumeReclaimPolicy: Retain \r\n storageClassName: gcsfusecsi-training\r\n mountOptions:\r\n - only-dir=my-ml-dataset-subdirectory # Optional\r\n csi:\r\n driver: gcsfuse.csi.storage.gke.io\r\n volumeHandle: my-ml-dataset-bucket\r\n---\r\napiVersion: v1\r\nkind: PersistentVolumeClaim\r\nmetadata:\r\n name: gcs-pvc\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n resources:\r\n requests:\r\n storage: 5Gi\r\n storageClassName: gcsfusecsi-training\r\n volumeName: gcs-pv'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f338ac62070>)])]>

3. デプロイを作成する

PersistentVolumeClaim（PVC）がバインドされたら、他のボリュームと同様に Deployment で使用するだけです。GKE は、ハードウェアとデータセットに必要となる正確な設定でボリュームをマウントします。

code_block: <ListValue: [StructValue([('code', 'apiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: my-deployment\r\nspec:\r\n replicas: 3\r\n selector:\r\n matchLabels:\r\n app: my-app\r\n template:\r\n metadata:\r\n labels:\r\n app: my-app\r\n annotations:\r\n gke-gcsfuse/volumes: "true"\r\n spec:\r\n serviceAccountName: my-ksa\r\n containers:\r\n - name: my-container\r\n image: busybox\r\n volumeMounts:\r\n - name: my-gcs-volume\r\n mountPath: "/data"\r\n volumes:\r\n - name: my-gcs-volume\r\n persistentVolumeClaim:\r\n claimName: gcs-pvc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f338ac62ac0>)])]>

デプロイ後、CSI ドライバは、GPU や TPU、メモリ、ローカル SSD、バケットまたはサブディレクトリのサイズ、サイドカーのリソース上限など、ノードのリソースに基づいて最適なキャッシュサイズとマウントオプションを自動的に計算します。

使ってみる

GKE Cloud Storage FUSE プロファイルを使用すると、高パフォーマンスなクラウドストレージを構成する際に当て推量が不要になります。手動の「ノブ調整」からワークロードを認識する自動プロファイルに移行することで、ストレージスループットのデバッグに費やす時間を減らし、次世代の AI の構築に多くの時間を費やすことができます。

ぜひご利用ください。GKE Cloud Storage FUSE プロファイルは、バージョン 1.35.1-gke.1616000 で一般提供されています。AI / ML ワークロード向けに GKE で Cloud Storage FUSE プロファイルを構成する方法については、公式ドキュメントをご覧ください。

- エンジニアリングマネージャー、Nishtha Jain

- ソフトウェアエンジニア、Uriel Guzmán-Mendoza

NVIDIA Run:ai Model Streamer を使用して GKE 上のモデルのダウンロードを高速化

Mon, 15 Dec 2025 02:30:00 +0000

※この投稿は米国時間 2025 年 12 月 5 日に、Google Cloud blog に投稿されたものの抄訳です。

大規模言語モデル（LLM）のサイズと複雑さが増大し続けるのに伴って、推論のためにストレージからアクセラレータメモリを読み込む時間が重大なボトルネックになる可能性があります。この「コールドスタート」の問題は、単なる軽微な遅延ではありません。レジリエントかつスケーラブルな費用対効果の高い AI サービスを構築するうえで、大きな障壁となります。モデルの読み込みに費やされる 1 分 1 分は、GPU のアイドル状態、需要に応じたサービスのスケーリングの遅延、ユーザーのリクエストの待機がそれぞれ生じている 1 分です。

Google Cloud と NVIDIA は、こうした障壁を取り除くことに取り組んでいます。AI デベロッパーがまさにそれを実現するのに役立つ、強力なオープンソースのコラボレーションをご紹介できることをうれしく思います。NVIDIA Run:ai Model Streamer にネイティブの Google Cloud Storage サポートが追加され、Google Kubernetes Engine（GKE）上の vLLM 推論ワークロードが大幅に強化されました。GKE 上の Cloud Storage から AI/ML のデータにアクセスする速度がこれまで以上に高速になりました。

上のグラフは、デフォルトの vLLM モデルローダと比較して、モデルストリーマーが 141 GB の Llama 3.3-7 70B モデルを Cloud Storage から取得できる速度を示しています（値が小さいほど高速）。

コールドスタートを減らしてレジリエンスとスケーラビリティを向上

Kubernetes 上で実行される推論サーバーの場合、「コールドスタート」には、コンテナイメージの pull、プロセスの開始、そして最も時間がかかるモデルの重みの GPU メモリへの読み込みといういくつかのステップが含まれます。大規模モデルの場合、この読み込みフェーズには数分かかることがあり、ワークロードの起動を待機する間に自動スケーリングが遅延したり、GPU のアイドル状態になったりするなど、深刻な影響が生じます。

モデルストリーマーは、モデルを GPU メモリにストリーミングすることで、起動プロセスで最も時間がかかる可能性のある部分を大幅に短縮します。ストリーマーは、モデル全体がダウンロードされてから読み込まれるのを待つのではなく、オブジェクトストレージからモデルテンソルを直接取得し、GPU メモリに同時にストリーミングします。これにより、モデルの読み込み時間が数分から数秒に大幅に短縮されます。

単一のモデルを分割して複数の GPU で実行するモデル並列処理に依存するワークロードの場合、モデルストリーマーはさらに一歩進んだ機能を提供します。その分散ストリーミング機能は、NVIDIA NVLink を最大限に活用するよう最適化されており、高帯域幅の GPU 間通信を使用して、複数のプロセス間での読み込みを調整します。ストレージからの重みの読み込みは、参加するすべてのプロセスに効率的かつ均等に分割されます。各プロセスは、モデルの重みの一部をストレージから取得し、そのセグメントを NVLink 経由で他のプロセスと共有します。これにより、マルチ GPU デプロイでも、起動時間の短縮とコールドスタートのボトルネックの低減というメリットが得られます。

パフォーマンスとシンプルさ

Model Streamer の最新のアップデートでは、Cloud Storage のファーストクラスのサポートが導入され、Google Cloud ユーザー向けに統合された高性能なエクスペリエンスが実現します。この統合は、特に GKE 上で実行されるワークロード向けに、シンプルで高速かつ安全になるように設計されています。

vLLM などの一般的な推論サーバーのユーザーは、vLLM コマンドラインに 1 つのフラグを追加するだけでストリーマーを有効化できます。

--load-format=runai_streamer

Cloud Storage バケットに保存されたモデルを vLLM で起動する手順は以下のとおりです。

code_block: <ListValue: [StructValue([('code', 'vllm serve gs://your-gcs-bucket/path/to/your/model \r\n--load-format=runai_streamer'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f338ac62d60>)])]>

NVIDIA Run:ai Model Streamer は、Vertex AI Model Garden の大規模モデルのデプロイに不可欠なコンポーネントです。コンテナイメージストリーミングとモデルウェイトストリーミングにより、ユーザーの初回デプロイと自動スケーリングのエクスペリエンスと、NVIDIA GPU の効率を大幅に向上させることができました。

GKE 上で実行する場合、Model Streamer は自動的にクラスタの Workload Identity を使用できます。つまり、サービスアカウントキーを手動で管理してマウントする必要がなくなり、デプロイマニフェストが簡素化され、セキュリティポスチャーが強化されます。以下のデプロイマニフェストは、GKE 上で Llama3 70B を提供するコンテナを起動する方法を示しています。モデルの並列処理が 1 より大きい場合に読み込みを高速化するモデルローダの分散オプションを追加しました。

code_block: <ListValue: [StructValue([('code', 'apiVersion: apps/v1\r\nkind: Deployment\r\n…\r\n spec:\r\n serviceAccountName: gcs-access\r\n containers:\r\n - args:\r\n - --model=gs://your-gcs-bucket/path/to/your/model \r\n - --load-format=runai_streamer\r\n \t\t- --model-loader-extra-config={"distributed":true}\r\n\t\t…\r\n command:\r\n - python3\r\n - -m\r\n - vllm.entrypoints.openai.api_server\r\n image: vllm/vllm-openai:latest\r\n ….'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f338ac62b20>)])]>

これで完了です。残りの処理はストリーマーが行い、VM のパフォーマンスに合わせてストリーミングの同時実行数を自動調整します。詳しくは、GKE 上での vLLM モデルの読み込みの最適化に関するドキュメントをご覧ください。

NVIDIA Run:ai Model Streamer と Cloud Storage Anywhere Cache の組み合わせ

Anywhere Cache は、リージョンまたはマルチリージョンの Cloud Storage バケットに保存されたデータに対して、ゾーン内にコロケーションされた SSD ベースのキャッシュを提供します。レイテンシを最大 70% 短縮し、最大 2.5 TB/ 秒の読み込みスループットを提供する Anywhere Cache は、同じモデルが複数のノードにわたって何度もダウンロードされるスケールアウト推論ワークロードに最適なソリューションです。Anywhere Cache のサーバーサイドアクセラレーションと、NVIDIA Run:ai Model Streamer のクライアントサイドアクセラレーションを組み合わせることで、管理が容易で非常にパフォーマンスの高いモデル読み込みシステムが実現します。

今すぐ使ってみる

NVIDIA Run:ai Model Streamer は、AI インフラストラクチャのパズルの重要なピースへと進化しています。これにより、チームは GKE 上でより高速かつ復元力がある、より柔軟な MLOps パイプラインを構築できるようになります。

GKE で Model Streamer を使用する方法の詳細については、GKE NVIDIA Run:ai ガイドをご覧ください。
vLLM でストリーマーを使用する詳しい手順については、vLLM の公式ドキュメントをご覧ください。
モデルストリーマーの詳細と、継続的な開発への貢献については、GitHub の NVIDIA Run:ai Model Streamer プロジェクトをご覧ください。

-Google、ソフトウェアエンジニア Peter Schuurman

-Google、シニアプロダクトマネージャー Brian Kaufman

Managed Lustre の外部 KV キャッシュで AI 推論を迅速化

Wed, 26 Nov 2025 00:00:00 +0000

※この投稿は米国時間 2025 年 11 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

AI 推論インフラストラクチャの需要は増加の一途をたどっており、市場における AI 推論インフラストラクチャへの支出額は、間もなくモデル自体のトレーニングへの投資額を上回ると予想されています。この成長は、より豊かなエクスペリエンスに対する需要、特により大きなコンテキストウィンドウのサポートとエージェント AI の台頭によって促進されています。組織がコストを最適化しながらユーザーエクスペリエンスの向上を目指すには、推論リソースを効率的に管理することが最重要です。

大規模モデルの推論に関する実験研究によると、Google Cloud Managed Lustre などの高性能ストレージ上の外部 Key-Value キャッシュ（KV キャッシュまたは「アテンションキャッシュ」）を使用すると、総所有コスト（TCO）を最大 35% 削減できます。これにより、組織はプリフィルコンピューティングを I/O にオフロードすることで、43% 少ない GPU で同じワークロードを処理できます。このブログでは、長いコンテキストの AI 推論の管理における主な課題について説明するとともに、このような大幅なコスト削減と効率化を実現するために必要な高性能外部ストレージソリューションを Google Cloud Managed Lustre がどのように提供するについて、詳しく説明します。

KV キャッシュについて

推論フェーズにおいて、KV キャッシュは、Transformer ベースの大規模言語モデル（LLM）を効率的に運用するための重要な最適化手法です。

Transformer の重要なイノベーションは、シーケンシャル処理（繰り返し処理）を完全に排除したことであり、これはセルフアテンションメカニズムを導入することで実現されました。このメカニズムにより、シーケンス内のすべての要素が、自要素を他のすべての要素と瞬時に動的に比較し、関連性を評価できるようになりました（グローバルな一括評価）。このセルフアテンションメカニズムでは、モデルはシーケンス内の先行するすべてのトークンのキー（K）ベクトルと値（V）ベクトルを計算します。推論フェーズで次のトークンを生成するために、モデルには先行するすべてのトークンの K ベクトルと V ベクトルが必要であるためです。

ここで KV キャッシュが役立ちます。KV キャッシュは、（「プリフィル」ステージと呼ばれる）最初のコンテキスト処理後にこれらの K ベクトルと V ベクトルを保存します。これにより、後続のトークンを生成する際に、冗長でコストのかかるコンテキストシーケンスの再計算を回避できます。この再計算を排除することで、KV キャッシュは推論プロセス全体を大幅に高速化します。小規模なキャッシュであれば、高帯域幅メモリ（HBM）またはホスト DRAM に収まる可能性があります。単一のマルチアクセラレータサーバーで数 TB までのメモリを利用できる場合もありますが、メモリ容量を超える複数の同時ユーザーのコンテキストの KV キャッシュを管理するには、外部ストレージソリューションまたは階層型ストレージソリューションが必要になることがよくあります。

ただし、このような大規模なコンテキストにより、AI モデルが大きなコンテキストウィンドウを処理する際に実行する「プリフィル」計算が非常に高価になる可能性があります。

また、10 万トークン以上の大規模なコンテキストの場合、プリフィル計算により、最初のトークンまでの時間（TTFT）が数十秒に増加する可能性があります。
プリフィル計算には、多数の浮動小数点演算（FLOP）が必要です。KV キャッシュを再利用することで、これらのコストを節約し、アクセラレータで追加のリソースを利用できるようになります。

エージェント AI の成長により、長いコンテキストを管理するという課題はさらに深刻化する可能性があります。単純な chatbot とは異なり、エージェント AI はなんらかのアクションを取ることを目的として構築されています。会話を行うだけでなく、問題を積極的に解決し、ユーザーに代わってタスクを完了します。これを行うために、幅広いデジタルソースからコンテキストを積極的に収集します。たとえば、エージェント AI は、フライトのリアルタイムのデータを確認したり、データベースから顧客の履歴を取得したり、ウェブでトピックを調査したり、独自のファイルに整理されたメモを保存したりする場合があります。そのため、エージェント AI は環境を深く理解できますが、多くの場合、コンテキストの長さとそれに関連する KV キャッシュのサイズが増加します。

パフォーマンスコストを大規模に管理する鍵は、アクセラレータを可能な限り最大限に活用することにあります。高性能なスケールアウトストレージでは、アクセラレータあたりのスループットを向上させるため、リソース要件が軽減されます。

Google Cloud Managed Lustre 上の外部 KV キャッシュ

Google は、外部 KV キャッシュの主要なストレージソリューションとして Google Cloud Managed Lustre を推奨しています。GPU に関しては、Lustre はローカルに接続された SSD を利用します。ローカル SSD を利用できない TPU に関しては、Lustre の役割はさらに重要になります。

Google の Danna Wang による最近の LMCache ブログ投稿「LMCache on Google Kubernetes Engine: Boosting LLM Inference Performance with KV Cache on Tiered Storage」では、ホストレベルでのオフロードの基本的な価値が示されています。Google の Managed Lustre 戦略は、このホストオフロードのコンセプトを次のレベルにまで進化させたものです。ローカル SSD と CPU RAM はノードローカルの階層として効果的ですが、サイズが固定されており、共有できません。Managed Lustre は、大規模な高スループット外部ストレージとして機能する並列ファイルシステムを提供します。そのため、キャッシュがホストマシンの容量を超える、大規模なマルチノードかつマルチテナントの AI 推論ワークロードに最適なソリューションです。

Managed Lustre のパフォーマンス向上によって TCO を削減できる例を以下に示します。

50,000 トークンのコンテキストと高いキャッシュヒット率（約 75%）での実験では、Managed Lustre を使用すると、ホストメモリのみで KV キャッシュを使用した場合と比較して、合計推論スループットが 75% 向上し、最初のトークンまでの平均時間が 44% 短縮されました（詳細は以下を参照）。
TCO 分析の結果、外部ストレージを利用しないワークロードと比較して、A3-Ultra VM と Managed Lustre を活用し、1 秒あたり 100 万トークン（TPS）を処理するワークロードに外部アテンション/KV キャッシュを使用すると、35% のコスト削減が実現することがわかりました。
Google の実験では、構成のチューニングと、より多くの I/O 並列処理を実行できるようにする KV キャッシュソフトウェアの改善により、Managed Lustre で推論パフォーマンスを大幅に向上させることができることが実証されました。

総所有コスト: 分析

KV キャッシュソリューションを評価する際は、コンピューティングとストレージの費用だけでなく、運用にかかる費用と見込まれる節約額を含む TCO を考慮することが重要です。Google の分析によると、Managed Lustre 上に構築されたような、高パフォーマンスストレージを基盤とする KV キャッシュは、純粋なメモリベースのソリューションと比較して、TCO の面で大きなメリットがあります。

コストの節約

増分ストレージ費用を考慮すると、100 万 TPS を処理するファイルシステムを基盤とする KV キャッシュソリューションの TCO は、メモリのみのソリューションと比較して 35% 低くなると予測されます。そのため、大規模な AI 推論の導入において、よりスケーラブルかつ経済的に実行可能なオプションとなります。

TCO の主なメリットは、高価なコンピューティングリソースをより効率的に利用できることにより実現されます。KV キャッシュを高性能ストレージソリューションにオフロードすることで、アクセラレータあたりの推論スループットを向上させることができます。つまり、同じワークロードに必要なアクセラレータの数が減ります。特定の秒間クエリ数を 43% 少ないアクセラレータで処理できるため、直接的なコスト削減につながります。

TCO モデルの前提条件

TCO の計算には、いくつかの主要なコンポーネントが含まれています。

ストレージ費用（正規価格）: これは、Managed Lustre の費用です。テストでは、TiB あたり 1,000 MB/秒のパフォーマンス階層を使用しました。TCO モデルには、100 万 TPS の目標レートを達成するのに十分な Lustre 容量（73 台の A3-Ultra マシン、マシンあたり 18 TiB の Lustre 容量）が含まれます。
コンピューティング費用（正規料金）: A3-Ultra VM はそれぞれ 8 個の H200 GPU と 8 個の 141 GB HBM を搭載します（スポット料金はさらに低くなります）。

パフォーマンスのベンチマーク

Google Cloud Managed Lustre は、最先端の LLM に必要な高性能 I/O を提供できることが実験で実証されました。これらの実験では、Google Cloud A3-Ultra マシン（8x H200、8x 141GB HBM）で Deepseek-R1 を使用しました。また、50,000 トークンのコンテキストと高いキャッシュヒット率（約 75%）で、合計 KV キャッシュサイズが約 3.4 TiB の合成サービングワークロードを実行し、メモリのみのベースラインでは、KV キャッシュに 1 TiB のホストメモリを使用しました。さらに、I/O 並列処理を多くした場合と少なくした場合の 2 つのバリエーションで Managed Lustre をテストしました。I/O の並列処理をより多く行うため、32 個の I/O ワーカースレッドを利用して、Lustre から KV キャッシュデータを並列で読み取りました。

Lustre を使用すると、ホストメモリのみで KV キャッシュを使用した場合と比較して、合計推論スループットが 75% 向上し、最初のトークンまでの平均時間が 44% 短縮されました。

推論ワークロードを最適化するには

長いコンテキストウィンドウの容量制限の問題を解決し、大規模な LLM で大幅なパフォーマンス向上を実現する外部 KV キャッシュソリューションを使い始めるには、次の手順を実行します。

1. インフラストラクチャをプロビジョニングし、Managed Lustre インスタンスを作成する

最適な低レイテンシアクセスを実現するため、Lustre ファイルシステムを利用するアクセラレータ（GPU または TPU）と同じリージョンとゾーンにプロビジョニングします。
推論エンジンをデプロイする: 外部 KV キャッシュまたは Paged Attention アーキテクチャをサポートする vLLM などの高パフォーマンスの推論サーバーまたは同様のフレームワークを使用して、LLM をデプロイします。

2. パフォーマンスを重視して構成する

Managed Lustre をマウントしたら、高性能ストレージを活用するように推論エンジンソフトウェアを構成する必要があります。

ダイレクト I/O を実装する: o_direct フラグを使用して Managed Lustre にアクセスするようにアプリケーションを構成します。これにより、汎用ファイルシステムキャッシュがバイパスされ、推論エンジンが重要なホストメモリをより効果的に管理できるようになります。
I/O 並列処理を調整する: 推論 KV キャッシュソフトウェアによっては、デフォルトのストレージ I/O 並列処理の設定が最適ではない場合があります。パフォーマンスを最大化するには、KV キャッシュソフトウェアをチューニングして、並列処理を強化した状態で KV チャンクファイルを読み取る必要がある場合があります。

次のステップに進むには、Managed Lustre の使用を開始する方法に関するドキュメントをご覧ください。

-上級ソフトウェアエンジニア、Kai Shen

-シニアプロダクトマネージャー、Barak Epstein

ブロックストレージとファイルストレージを統合して、クラウドでの貴社のエンタープライズアプリケーションを強化

Fri, 24 Oct 2025 03:00:00 +0000

※この投稿は米国時間 2025 年 10 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

エンタープライズアプリケーションをクラウドに移行するには、高性能なブロックワークロードからグローバルに分散されたファイルアクセスまで、あらゆるものを処理できるストレージ基盤が必要です。これらの課題を解決するため、Google Cloud NetApp Volumes に次の 2 つの新機能が発表されます。1 つは、ストレージエリアネットワーク（SAN）の移行を可能にする iSCSI ブロックストレージとファイルストレージの統合、もう 1 つは、ハイブリッドクラウドワークロードを高速化する NetApp FlexCache です。これらの機能と、Gemini Enterprise で構築されたエージェントの新しい統合により、最も要求の厳しいアプリケーションでもモダナイズできます。

最も要求の厳しい SAN ワークロードを Google Cloud で実行

各企業は数十年にわたり、オンプレミスのネットワーク接続ストレージ（NAS）と SAN ワークロードの両方で NetApp を利用してきました。この信頼できるテクノロジーをフルマネージドクラウドサービスとして提供することで、基盤となるアーキテクチャを変更することなく、レイテンシの影響を受けやすいアプリケーションを Google Cloud に移行できるようになりました。

Google の統合サービスは、エンタープライズグレードのパフォーマンスを実現するように設計されており、次のような機能が備わっています。

最も要求の厳しいアプリケーション向けに設計された低レイテンシ
ボリュームあたり最大 160,000 ランダム IOPS で最大 5 GiB/秒までバースト可能なスループット
容量、スループット、IOPS を個別にスケーリングして費用を管理
NetApp Snapshots による統合されたデータ保護で迅速な復旧とランサムウェア防御を実現

iSCSI ブロックプロトコルのサポートは、ご希望のお客様に限定公開のプレビュー版でご利用いただけます。

NetApp FlexCache でハイブリッドクラウドを加速

各地に従業員が分散し、ハイブリッドクラウド戦略を持つ組織にとって、共有データセットへの迅速なアクセスを提供することは重要です。Google Cloud NetApp Volumes の新機能である NetApp FlexCache は、リモートボリュームの高性能なローカル読み取りキャッシュを提供します。これにより、分散したチームが共有データセットにあたかもローカルであるかのようにアクセスできるようになり、また低レイテンシのデータアクセスを必要とするワークロードのコンピューティングバーストがサポートされるため、組織全体の生産性とコラボレーションが向上します。FlexCache は現在、許可リストによるプレビュー版で利用できます。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7f339d011160>), ('btn_text', ''), ('href', ''), ('image', None)])]>

エンタープライズデータを Gemini Enterprise に取り込む

また、Google Cloud NetApp Volumes が Gemini Enterprise のデータストアとして機能することも発表します。この統合により、検索拡張生成（RAG）の新たな可能性が広がり、安全で事実に基づいたエンタープライズグレードの自社データで AI モデルをグラウンディングできるようになります。データは NetApp Volumes で安全に管理され、複雑な ETL や手動による統合を必要とせずに、検索や推論のワークフローですぐに利用できます。

クラウド環境のその他の強化

Google Cloud NetApp Volumes には、データ資産のモダナイゼーションに役立つその他の新機能がいくつかあります。

NetApp SnapMirror: これにより、オンプレミスの NetApp システムと Google Cloud 間でミッションクリティカルなデータを迅速にレプリケートできるようになり、目標復旧時点（RPO）はゼロ、目標復旧時間（RTO）はほぼゼロになります。
大容量で高パフォーマンス: HPC、AI、EDA などの大規模なデータセットを使用するアプリケーション向けに、15 TiB から 3 PiB までスケーリング可能な大容量ボリュームを提供します。ボリュームあたりのスループットは 21 GiB/秒を超えます。
自動階層化: 費用管理を支援する組み込みの自動階層化が、アクセス頻度の低いデータが低コストのストレージに動的に移動します。Flex サービスレベルでは、コールドデータの料金はわずか 0.03 ドル/GiB です。自動階層化は、Google Cloud NetApp Volumes 上に構築されたあらゆるアプリケーションに対して透過的で、ターンキーの統合機能として、2 ～ 183 日の階層化しきい値をサポートし、ポリシーを動的に調整できます。

始める

エンタープライズ SAN データの移行、Gemini Enterprise による AI の強化、高スループットの EDA ワークロードの実行など、Google Cloud NetApp Volumes はデータ資産のモダナイズに役立ちます。詳細とご利用開始方法は次のとおりです。

プロダクトドキュメントを読む。

-Google ストレージ、プロダクト管理担当シニアディレクター、Asad Khan

-Google ストレージ、グループプロダクトマネージャー Brendan Power

ダークデータを有用なインサイトへ: スマートストレージの幕開け

Thu, 23 Oct 2025 02:00:00 +0000

※この投稿は米国時間 2025 年 10 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

今日 AI に関心を持つ組織は、Tensor Processing Unit（TPU）と画像処理装置（GPU）による驚異的なコンピューティング能力を利用できます。また、Gemini などの基盤モデルは、AI の可能性を再定義しています。しかし、多くの企業にとって、AI の大きな障害となるのはデータそのもの、特に非構造化データです。Enterprise Strategy Group によると、ほとんどの組織では、全データの 61% が非構造化データであり、その大部分はアーカイブに分析もラベル付けもされずに保存されている、いわゆる「ダークデータ」です。しかし、この未活用のリソースは、AI の力を借りることにより、真の宝の山のようなインサイトを引き出すことができます。

同時に、非構造化データに関しては、従来のツールでは表面的な処理しか行えず、分野の専門家が大規模な手動の前処理パイプラインを構築し、データの意味論的意味を定義する必要があります。そのため、大規模なリアルタイム分析は不可能で、企業は保存したデータのほんの一部しか利用できません。

非構造化データが保存されるだけでなく、理解される世界を想像してみてください。画像、動画、ドキュメントなどのデータに対して複雑な質問をすると、興味深い回答が得られる世界です。これは単なる未来のビジョンではありません。スマートストレージの時代はすでに到来しています。本日、AI を使用してデータのメタデータとインサイトを生成する新しい自動アノテーション機能とオブジェクトコンテキスト機能を発表します。これにより、ダークデータを大規模な検出、キュレーション、ガバナンスに使用できるようになります。さらに、新機能により、オブジェクト分析データパイプラインを独自に構築して管理する必要がなくなります。

AI を活用してダークデータを変革

非構造化データが Google Cloud に取り込まれると、もはや受動的なオブジェクトとして扱われることはありません。その代わりに、データパイプラインは AI を活用してデータを自動的に処理および理解し、重要な分析情報とつながりを浮かび上がらせます。このビジョンに不可欠な 2 つの新機能があります。1 つは 自動アノテーションです。これは、Google の事前トレーニング済み AI モデルを使用してメタデータを自動生成することで、データを拡充する機能です。もう 1 つはオブジェクトコンテキストです。これは、カスタムの、実用的なタグをデータに添付できる機能です。この 2 つの機能を組み合わせることで、受動的なデータを能動的なアセットに変換し、AI モデルのトレーニングのための迅速なデータ検出、モデルのバイアスを低減するためのデータキュレーションの合理化、機密情報を保護するためのデータガバナンスの強化、ストレージ上で直接強力なステートフルワークフローを構築する機能などのユースケースを実現できます。

データをスマート化する

自動アノテーションは、現在限定的な試験運用版としてリリースされており、Google の高度な AI モデルを適用することで、Cloud Storage バケットに保存されたオブジェクトに関する豊富なメタデータ（「アノテーション」）を自動的に生成します。まずは画像オブジェクトから開始します。始めるのは簡単です。選択したバケットまたはプロジェクト全体で自動アノテーションを有効にし、利用可能なモデルを 1 つ以上選択するだけで、画像ライブラリ全体にアノテーションが付けられます。さらに、新しい画像がアップロードされると、自動的にアノテーションが付けられます。アノテーションのライフサイクルは常にそのオブジェクトのライフサイクルに関連付けられるため、管理が簡素化され、整合性が確保されます。重要な点として、自動アノテーションはユーザーの管理下で動作し、ユーザーが明示的に権限を付与したオブジェクトコンテンツにのみアクセスします。その後、Cloud Storage API 呼び出しと Storage Insights データセットを通じて、オブジェクトコンテキストとして利用できるアノテーションをクエリできます。最初のリリースでは、アノテーションの生成に事前トレーニング済みモデルを使用します。具体的には、信頼スコア付きのオブジェクト検出、画像ラベリング、不適切なコンテンツの検出です。

オブジェクトに対して生成されたアノテーションのサンプル

オブジェクトコンテキストを使用すると、新しい自動アノテーション機能で生成された情報を含め、カスタムの Key-Value ペアのメタデータを Cloud Storage のオブジェクトに直接アタッチできます。現在プレビュー版のオブジェクトコンテキストは、リスト表示とバッチ処理のための Cloud Storage API、および BigQuery での分析のための Storage Insights データセットとネイティブに統合されています。各コンテキストには、オブジェクトの作成と変更のタイムスタンプが含まれており、貴重なリネージ情報が提供されます。Identity and Access Management（IAM）権限を使用して、オブジェクトコンテキストを追加、変更、削除できるユーザーを管理できます。Cloud Storage API を使用して Amazon S3 からデータを移行すると、既存の S3 オブジェクトタグが自動的にコンテキストに変換されます。

つまり、オブジェクトコンテキストは、データを拡充するためにコンテキストを追加する柔軟なネイティブの方法を提供します。自動アノテーションなどのスマートストレージ機能と組み合わせることで、オブジェクトコンテキストはデータを情報に変換し、Cloud Storage 内で高度なデータマネジメントワークフローを直接構築できます。

では、これらのスマートストレージ機能によって実現される新しいユースケースをいくつか詳しく見ていきましょう。

1. データの検出

新しい AI アプリケーションを構築するうえで最も大きな課題の一つは、データ検出です。多くの場合サイロ化された企業の大規模なデータストア全体から、最も関連性の高いデータを見つけなければいけません。ペタバイト規模の非構造化データから特定の画像や情報を見つけ出すのは、不可能に思えるかもしれません。自動アノテーションは、Cloud Storage 内のデータに対して、豊富でわかりやすいアノテーションを自動的に生成します。ラベルや検出されたオブジェクトなどのアノテーションは、オブジェクトコンテキスト内で利用でき、BigQuery で完全にインデックス化されます。これらのアノテーションのエンベディングを生成したら、BigQuery を使用してこれらのアノテーションのセマンティック検索を実行し、「干し草の山から針を探す」問題を効果的に解決できます。たとえば、数百万点の商品画像を持つ大手小売業者は、自動アノテーションと BigQuery を使用して「赤いドレス」や「革製のソファ」をすばやく見つけ、カタログ管理とマーケティング活動を推進できます。

2. AI のためのデータキュレーション

効果的な AI モデルを構築するには、慎重にキュレートされたデータセットが必要です。データが広範にわたって代表性を有していることを確認するためにデータを精査（例: 「このデータセットにはさまざまな色の車が含まれていますか？」）することでモデルのバイアスを減らしたり、特定のトレーニング例（「赤い車が写っている画像を探して」など）を選択したりすることは、時間がかかるうえにエラーが発生しやすくなります。自動アノテーションでは、色やオブジェクトの種類などの属性を特定して、バランスの取れたデータセットの選択を自動化できます。

たとえば、モデルをトレーニングする自動運転車企業は、ペタバイト単位の道路カメラデータを使用して交通標識を認識できます。自動アノテーションを使用して、「止まれ」や「横断歩道」という単語を含む画像を特定して抽出します。

スマートホームとセキュリティの会社である Vivint は、自動アノテーションを使用してデータを見つけて理解しています。

「お客様は、自宅や生活をより安全、スマート、便利にするために当社を信頼してくださっています。AI は、当社のプロダクトとカスタマーエクスペリエンスのイノベーションの中核をなすものです。Cloud Storage の自動アノテーション機能によって BigQuery に配信される豊富なメタデータは、データ検出とキュレーションの取り組みをスケーリングするのに役立ちます。モデルの改善に不可欠な、干し草の山の中の針のようなデータを見つけることで、AI 開発プロセスを 6 か月からわずか 1 か月に短縮できます」 - Vivint、プロダクトおよび AI 担当バイスプレジデント、Brandon Bunker 氏

3. 非構造化データを大規模に管理

非構造化データは常に増え続けており、機密情報の特定、ポリシー違反の検出、ライフサイクル管理のための分類など、手動で管理およびガバナンスを行うことは困難です。自動アノテーションとオブジェクトコンテキストは、データガバナンスとコンプライアンスの課題を解決するのに役立ちます。たとえば、小売業のお客様は、自動アノテーションを使用して、配送ラベルや注文書など、お客様の個人情報（PII）が目に見える形で含まれている画像を特定してフラグを立てることができます。オブジェクトコンテキストに保存されたこの情報は、フラグが付けられたオブジェクトを制限付きバケットに移動したり、レビュープロセスを開始したりするなど、自動化されたガバナンスアクションをトリガーできます。

Cloud Storage 上にソリューションを構築しているパートナーの BigID は、オブジェクトコンテキストを使用することで、顧客のリスク管理に役立っていると報告しています。

「オブジェクトコンテキストを使用すると、BigID の業界をリードするデータ分類ソリューションの出力内容を取得し、Cloud Storage オブジェクトにラベルを適用できます。オブジェクトコンテキストにより、BigID のラベルで Cloud Storage のデータを把握できるようになります。機密情報を含むオブジェクトを特定し、AI、セキュリティ、プライバシー全体のリスクを理解して管理するのに役立ちます」 - BigID、プリンシパルテクニカルアーキテクト、Marc Hebrard 氏

明るいデータの未来

Google Cloud は、お客様のデータが単なる受動的な資産ではなく、イノベーションの積極的な触媒となる未来を築くことに尽力しています。貴重なデータを放置しないでください。データを Cloud Storage に取り込み、自動アノテーションとオブジェクトコンテキストを有効にすることで、Gemini、Vertex AI、BigQuery を使用してデータの可能性を最大限に引き出せます。

オブジェクトコンテキストは今すぐ使用できます。自動アノテーションの早期アクセスについては、Google までお問い合わせください。アクセス権を取得したら、選択したバケットまたはプロジェクト全体で自動アノテーションを有効にし、利用可能なモデルを 1 つ以上選択するだけで、画像ライブラリ全体にアノテーションが付けられます。その後、Cloud Storage API 呼び出しと Storage Insights データセットを通じてオブジェクトコンテキストとして利用できるアノテーションに対してクエリを実行できます。

詳しくは、Enterprise Strategy Group とのショーケースペーパー『Illuminating Dark Data With Smart Storage from Google Cloud』で、Google のエンドツーエンドのビジョンをご覧ください。

ー Google ストレージ、プロダクト管理担当シニアディレクター、Asad Khan

ー Google Cloud Storage、グループプロダクトマネージャー Manjul Sahay

Google におけるメディアのサニタイズの未来

Wed, 22 Oct 2025 03:00:00 +0000

※この投稿は米国時間 2025 年 10 月 14 日に、Google Cloud blog に投稿されたものの抄訳です。

Google では、お客様のデータを保護することを最重要事項としており、お客様のデータを安全に保つことに尽力しています。この取り組みをさらに進めるため、2025 年 11 月より、メディアのサニタイズに対するアプローチを、堅牢で多層的な暗号化戦略に完全に依存する形に移行することを発表いたします。

これは、20 年近く使用してきた「ブルートフォースディスク消去」プロセスからの脱却を意味します。データの上書きは効果的な方法でしたが、ストレージ技術の状況は劇的に変化しました。今日のメディアはサイズが大きく、技術的にも複雑であるため、このプロセスはもはや持続可能ではありません。

よりスマートなアプローチ: 暗号化消去

こうした課題に対処するため、Google はより新しく、効率的なメディアのサニタイズ方法である暗号化消去を採用します。

Google のサービスでは、すべてのユーザーデータが複数の暗号化レイヤによってデフォルトで保護されます。暗号化消去では、この暗号化を利用してメディアをサニタイズします。ドライブ全体を上書きする代わりに、データを暗号化するために使用される暗号鍵を安全に削除します。鍵がなくなると、データは読み取り不能、復元不能になります。

この方法は、より高速であるだけでなく、業界のベストプラクティスにも沿っています。米国国立標準技術研究所（NIST）は、特別出版物 800-88 で暗号化消去を有効なサニタイズ手法として認めています。Google は、お客様のデータのセキュリティを確保するために、これらの基準を満たし、さらに上回るよう努めています。

イノベーションによるセキュリティの強化

Google は、多層防御戦略を採用し、複数のセキュリティレイヤで暗号化消去を実装しています。Google の「信頼するが検証はする」モデルでは、独立した検証メカニズムを使用して、メディア暗号鍵が完全に削除されるようにしています。

また、ストレージデバイスの鍵など、このプロセスに関わるシークレットも業界最先端の対策で保護しています。複数の鍵のローテーションにより、信頼できる暗号化の独立したレイヤを通じて顧客データのセキュリティが強化されます。

サステナビリティと循環経済

以前のメディア消去方法には環境への負荷もありました。厳格な検証プロセスに合格しなかったストレージデバイスは、物理的に破壊されていました。その結果、毎年相当数のデバイスが破壊されていました。

暗号化消去により、よりサステナブルな循環型経済への移行が可能になります。ドライブを物理的に破壊する必要がなくなったことで、ハードウェアをより多く再利用できるようになりました。また、寿命の切れたメディアからネオジム磁石などの貴重な希土類材料を回収することもできます。この画期的な磁石回収プロセスはサステナブルな製造における大きな成果であり、責任ある成長に対する Google のコミットメントを示すものです。

今後の取り組み

Google は、ユーザー、業界全体、そして世界全体にとって真に正しいことを行うことを一貫して強く主張してきました。暗号化消去への移行は、その取り組みを直接反映したものです。これにより、セキュリティを強化し、最高水準の業界標準に準拠し、インフラストラクチャのより持続可能な未来を構築できます。Google は、これがユーザー、業界、環境にとって正しい道だと考えています。

暗号鍵の管理など、保存データの暗号化の詳細については、セキュリティに関するホワイトペーパー「デフォルトの保存データの暗号化」をご覧ください。

-Paul B. Pescitelli、データセンター情報セキュリティ担当ディレクター

Google Cloud のコンピューティング費用を今すぐ削減する 11 の方法

Mon, 20 Oct 2025 01:05:00 +0000

※この投稿は米国時間 2025 年 10 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

「節約は美徳」という言葉がありますが、クラウドインフラストラクチャに関してはまさにこれが当てはまります。競争の激しい今日のビジネス環境では、ビジネスニーズを満たすためにパフォーマンスを維持する必要があります。幸いなことに、Google Cloud の Compute Engine とブロックストレージサービスは、特に移行とモダナイゼーションの取り組みにおいて、パフォーマンスを犠牲にすることなく費用を削減する多くの機会を提供します。

この記事では、Google Cloud でインフラストラクチャの費用を最適化するための 11 の重要な方法をご紹介します。簡単な調整から、長期的に大幅な費用削減につながる戦略的な意思決定まで、さまざまな方法があります。

1. 適切な VM インスタンスを選択する

Compute Engine のコストを削減する最も効果的な方法の一つは、移行とモダナイゼーションの取り組みに対して、そのワークロードに適した仮想マシン（VM）を適切に選択し、適切なサイズに設定することです。Google Cloud を初めて使用する場合でも、すでに Compute Engine を使用している場合でも、N4、C4、C4D、C4A などの最新世代の VM を採用することで、大幅な費用削減と費用対効果の向上を実現できます。

Google Cloud の Titanium アーキテクチャを搭載した最新世代の VM は、前世代よりも高速な CPU、より大きいメモリ帯域幅、より効率的な仮想化を実現するため、より少ないリソースで同じワークロードを処理できます。既存のお客様は、古い世代の VM から最新の VM に移行することで、総費用を大幅に削減できるだけでなく、現在のパフォーマンスレベルを上回ることもできます。切り替えを行った組織は、クラウドコンピューティング費用を大幅に削減しながら、パフォーマンスが 20 ～ 40% 向上したと報告しています。たとえば、Elastic は、Google Cloud の Arm ベースの Axion CPU をベースにした汎用 C4A マシンシリーズを活用して、ワークロードの効率とパフォーマンスを大幅に向上させました。

汎用 VM に加えて、お客様固有の要件に対応する特殊なマシンタイプも提供しています。H4D などのコンピューティング最適化 HPC VM は、ハイパフォーマンスコンピューティングとデータ分析向けに設計されており、要求の厳しいワークロードに優れたパフォーマンスを提供します。M4 インスタンスと X4 インスタンスはメモリ使用量の多いアプリケーションに対応し、Z3 インスタンスはストレージ使用量の多いワークロードに最適です。さらに、ハードウェア環境を完全に制御し、パフォーマンスを最大限に分離する必要がある場合は、ベアメタルインスタンスをご利用いただけます。

これらのオプションにより、最も特殊でパフォーマンスが重要なワークロードでも、Compute Engine ポートフォリオ内で最適で費用対効果の高い環境を見つけることができます。

2. ブロックストレージの選択を最適化する

ワークロードの動作を確保しながらブロックストレージの TCO を削減する最善の方法は、リソース効率を高めることです。Hyperdisk を使用すると高性能と高効率の実現が容易になり、これはブロックストレージをワークロードに合わせた最適化と、ストレージプールの活用によって行います。これらの各機能と、それらを使用してブロックストレージの TCO を削減する方法について、以下で説明します。

ワークロードの最適化: Hyperdisk を使用すると、容量とパフォーマンスのそれぞれを個別に調整して、ブロックストレージのリソースをワークロードに最適化できます。Hyperdisk では、ボリュームレベルでパフォーマンスと容量を個別にプロビジョニングできます。この機能を利用すると、容量とパフォーマンスを必要なだけ過不足なく購入できます。また、Hyperdisk Balanced の「ベースライン」パフォーマンス（すべてのボリュームに無料で含まれるパフォーマンス）を利用すれば、追加のパフォーマンスを購入しなくても、ほとんどの VM に対応できます。

ストレージプール: Hyperdisk は、シンプロビジョニングされたパフォーマンスと容量を提供する唯一のハイパースケールクラウドブロックストレージです。Hyperdisk ストレージプールを使用すると、ワークロードに必要な集約されたパフォーマンスと容量をプロビジョニングしながら、ワークロードが必要とするボリュームレベルの容量パフォーマンス（シンプロビジョニングとも呼ばれる）をプロビジョニングできます。これにより、プロビジョニングしたボリュームの総量ではなく、必要なリソースに対して料金を支払うことができます。その結果、ブロックストレージの全体的な TCO を最大で 50% も削減できます。

ワークロードに適したブロックストレージの選び方や、Hyperdisk からどのようなメリットが得られるかについて詳しくは、こちらのブログをご覧ください。

3. カスタムコンピューティングクラスを検討する

最新世代の VM を最大限に活用するために、Google Kubernetes Engine（GKE）のカスタムコンピューティングクラス（CCC）は、コンピューティングの選択を最適化し、高可用性を実現する高度な方法を提供します。ワークロードに単一のマシンタイプを使用するのではなく、VM インスタンスタイプの優先順位付きリストを定義できます。これにより、最新世代の VM を含む、最新で最も費用対効果の高い VM を最優先に設定できます。GKE カスタムコンピューティングクラスは、指定した優先順位リストに基づいてインスタンスを自動的に、かつシームレスにスピンアップする機能を提供します。この機能は、最も費用対効果の高いオプションを目指しながら、コンピューティング容量の可用性を最大化するのに役立ちます。これにより、ワークロードは手作業を経ずに確実にスケーリングできます。

カスタムコンピューティングクラスが費用の最適化にどのように役立つか、具体的なユースケースをいくつかご紹介します。

費用対効果の高いフォールバックの自動スケーリング: 需要がピークに達すると、高可用性ではあるものの費用対効果の低い VM タイプを使用して自動スケーリングしたくなるかもしれません。CCC では、段階的なアプローチを採用できます。費用対効果の高いフォールバックの代替案を複数設定することによって、需要が増加した場合に GKE はまず最も費用対効果の高いオプションを使用しようとし、需要を満たすための必要に応じて、リスト内の他の選択肢に徐々に移行します。
AI/ML 推論: AI/ML 推論ワークロードの実行には、多くの場合、相当なコンピューティングリソースが必要です。CCC を使用すると、オフピーク時にアイドル状態になる可能性のある大規模な静的予約を維持する代わりに、最小限のベース予約をプロビジョニングし、Spot VM などの費用対効果の高い容量タイプを活用して、ピーク時の推論需要を処理できます。これらはすべて、CCC 構成を通じてオーケストレーションされます。
新しい VM 世代の導入: GKE カスタムコンピューティングクラスの機能とコンピューティングフレキシブル確約利用割引（Flex CUD）を組み合わせて、N4 や C4 などの費用対効果の高い新しい VM シリーズの導入に伴うリスクを軽減します。CCC では、フォールバックオプションを定義してワークロードの復元力を確保できます。一方、フレキシブル CUD では、使用する具体的な VM シリーズに関係なく、対象となるコンピューティングの総費用に割引が適用されるため、財務上の適応性が得られます。この二重のアプローチは、中断することなく最新のハードウェアを活用するための安全で費用対効果の高い戦略です。詳細については、こちらのブログをご覧ください。
柔軟な Spot VM の使用: Spot VM は大幅なコスト削減を実現しますが、プリエンプトされる可能性があります。単一の Spot VM の構成に限定すると、容量が利用できなくなるリスクが高まります。CCC では、複数のフォールバック Spot VM タイプを定義できます。この「スポットサーフィン」機能により、アプリケーションは費用対効果の高いスポット容量を維持できます。プライマリの選択肢が利用できない場合は、代替のスポットインスタンスタイプに自動的にピボットします。

つまり、GKE CCC を活用することで、オンデマンド、スポット、DWS FlexStart、CUD でカバーされるインスタンスなど、さまざまな VM タイプと使用量モデルを巧みに組み合わせて、ワークロードの固有のニーズとパターンに適応する、復元力が高く、費用対効果に優れたインフラストラクチャを構築できます。

4. カスタムマシンタイプ（CMT）を活用する

カスタムマシンタイプは N4 VM で利用でき、仮想マシンをぴったりと仕様に合わせて構成できます。過剰な容量が含まれている可能性のある事前定義されたマシンタイプから選択するのではなく、ワークロードに合わせて CPU とメモリの比率を調整できるため、実際に使用したリソースに対してのみ料金を支払うことができます。この的を絞ったアプローチにより、無駄を最小限に抑え、クラウド支出を大幅に削減できます。特に、オンプレミスから Google Cloud に移行する場合や、他のクラウドプロバイダから移行する場合に効果的です。

この柔軟性は、アプリケーションに標準のサービスとあまり一致しない独自のリソースプロファイルがある場合に特に役立ちます。カスタムマシンタイプを使用すると、ニーズに最適な環境を構築できます。特定のコンピューティングリソースを過剰にプロビジョニングして他のリソースを制約するような妥協を避けることで、Compute Engine デプロイメント全体でパフォーマンスの向上と費用の効率化の両方を実現できます。

たとえば、16 個の vCPU と 70 GB のメモリで最適に動作するメモリ集約型のワークロードがあるとします。通常、標準シェイプでは 128 GB のメモリを搭載した VM を選択する必要があるか、他のクラウドコンテキストでは、プロビジョニングされたリソースが余分になるため、ワークロードの実行コストが高くなります。カスタムマシンタイプを使用すると、16 個の vCPU と 70 GB のメモリを搭載した VM を簡単に起動でき、標準の N4-highmem-16 VM と比較して 18% の費用削減を実現できます。

5. 確約利用割引を最大限に活用する

CUD は、コンピューティングのニーズが安定していて予測可能な組織にとって、費用を削減する戦略的な機会となります。1 年間または 3 年間のリソース使用量を確約することで、オンデマンド料金と比較してクラウド費用を最大 70% 削減できます。このアプローチは、予算を予測可能なもにするだけでなく、固定インフラストラクチャの支出を財務上の利点に変えるため、コアビジネス機能をサポートする安定したワークロードに最適です。

Google Cloud は、さまざまな運用モデルに対応できるよう、柔軟な CUD 構造を提供しています。リソースベースのコミットメントは特定のマシンタイプとリージョンを対象とし、フレキシブルコミットメントはプロジェクト、リージョン、マシンシリーズ全体に割引を適用します。これは動的な環境に最適です。過去の使用状況を分析し、将来のニーズを予測することで、これらの割引に適したワークロードを特定し、節約した費用をイノベーションやスケーリングの取り組みに再投資できます。

6. 未使用のディスク容量を管理する

実際に使用した量に関係なく、プロビジョニングされたディスク容量の合計に対して料金が発生します。多くの組織は「念のため」にストレージを過剰にプロビジョニングする傾向があり、その結果、不要で高額な無駄が発生することがよくあります。たとえば、100 GB のディスクをプロビジョニングしても、実際に使用するのは 20 GB のみの場合、100 GB 全体の料金を支払うことになります。ストレージの割り当てを一般的なサイズに切り上げるのではなく、意図的で正確に行うことで、大幅な費用削減につながります。

費用を最適化するには、いくつかのベストプラクティスを採用することが重要です。Ops エージェントを使用して、インフラストラクチャ全体のディスク使用量を定期的に監査し、非効率な部分を特定して排除します。実際の使用量に合わせてディスクのサイズを変更し、成長のための合理的なバッファを確保します。Google Cloud で自動アラートを実装する Cloud Monitoring を使用して、使用率の低いディスクを検出して是正措置を講じる。ステートレスアプリケーションの場合は、より小さいブートディスクイメージを使用してオーバーヘッドを最小限に抑え、費用をさらに削減することを検討してください。

さらに、費用を削減して効率を向上させるために、次の最適化戦略を検討してください。

Google Cloud のモニタリングツールを使用して、CPU、メモリ、ディスクの使用状況を時系列で追跡する。
定期的なレビューサイクルを確立して、過剰にプロビジョニングされたリソースを特定し、適切なサイズに調整する。
さまざまな VM 構成でワークロードをテストし、費用とパフォーマンスの最適なバランスを見つけます。

7. Spot VM を使用する

Spot VM は、標準の仮想マシンと同じマシンタイプと構成オプションを提供しますが、費用は大幅に削減されます。通常は 60% ～ 91% の割引が適用されます。費用対効果が高い一方で、短時間でプリエンプションされる可能性があるため、フォールトトレラントで、予期しない中断から迅速に復旧できるワークロードに最適です。Spot VM は、未使用のコンピューティング容量を活用するように設計されており、高性能リソースへのアクセスを損なうことなくクラウド費用を最適化できます。

Spot VM が有望なユースケースには、バッチ処理ジョブ、ビッグデータと分析のワークロード、継続的インテグレーションとデプロイ（CI/CD）パイプライン、自動スケーリンググループで実行されるステートレスウェブサーバー、コンピューティング負荷の高いタスクなどがあります。中断に対処するように適切に設計されている場合（たとえば、ジョブのチェックポイント、ロードバランシング、タスクキューを使用するか、GKE カスタムコンピューティングクラスを使用する場合（詳細は上記を参照））、Spot VM は、高い可用性とシステム復元力を維持しながらインフラストラクチャの費用を最小限に抑えるうえで重要な役割を果たすことができます。このようなシナリオで Spot VM を活用すると、特にコンピューティング需要が変動する場合や、時間に柔軟性がある場合に、費用対効果の高いスケーリングが可能になります。

8. 最適化案を適用する

Google Cloud の Recommender は、クラウドリソースを効率的に最適化できるように設計された強力なツールです。Google Cloud コンソールを閲覧していると、特定のリソースの横に電球アイコンが表示されることがあります。これは、Google の推奨エンジンによって特定された改善の可能性を示しています。Recommender は、リアルタイムの使用パターンと現在のリソース構成を分析することで、各ユーザーの固有の環境に合わせた、実用的な情報を提供します。このインテリジェントシステムは、費用の削減だけでなく、セキュリティ、パフォーマンス、信頼性、管理効率、環境サステナビリティの向上につながる機会に注意を促してくれます。

たとえば、過去 1 ～ 14 日間に使用されていない VM インスタンスを特定するのに役立つアイドル状態の VM の推奨事項があります。一般的な推奨事項としては、より適切なマシンタイプへの切り替え、使用率の低いコンピューティングインスタンスの適正サイズ設定、費用対効果の高いストレージソリューションの採用などがあります。このツールを使用すると、これらの変更の多くを直接適用できるため、最適化プロセスを効率化できます。ワークロードを継続的に評価し、データドリブンな自動提案を行うことで、おすすめハブは、組織がクラウドのパフォーマンスを維持しながら、より効果的に費用を管理するお役に立ちます。

9. 自動スケーリングとスケジューリングを活用する

コンピューティングリソースを実際の需要パターンに合わせることは、クラウドの無駄を削減し、全体的な費用対効果を高める最も効果的な方法の一つです。多くの組織は、ピーク時のワークロードに対応するためにリソースを過剰にプロビジョニングしており、オフピーク時にはマシンが十分に活用されていません。コンピューティング容量を、営業時間や季節のトレンドなど、リアルタイムまたは予測可能な使用パターンに緊密に合わせることで、パフォーマンスを犠牲にすることなく、不要な支出を大幅に削減できます。

この効率性を実現する鍵となるのが自動スケーリングです。実際、Google Compute Engine の仮想マシンの自動スケーリングを活用しているお客様は、インフラストラクチャの費用を平均 40% 以上削減しています。

自動スケーリング戦略を実装して、CPU 使用率、ロードバランシング容量、またはカスタムアプリケーション指標に基づいてリソースを動的に調整できます。これにより、ワークロードは必要なときに必要なコンピューティング能力を受け取ることができ、需要が低い期間は自動的にスケールダウンされます。

営業時間や季節のイベントの予定に合わせて変動するワークロードなど、パターンが予測可能なワークロードの場合、スケジュールベースのスケーリングは特に強力なツールです。このアプローチでは、需要の増加を見越してリソースを事前に増やし、需要が落ち着いたときにスケールダウンできるため、常にオーバープロビジョニングすることなく必要なパフォーマンスを確保できます。

自動スケーリングに加えて、いくつかの実用的な実装手法を使用することで、リソースの使用をさらに最適化できます。インスタンススケジュールを設定すると、営業時間に応じて開発環境とテスト環境を自動的に起動および停止できます。これは、シンプルながら非常に効果的なアプローチであり、最大 70% の費用削減につながります。また、メンテナンスの時間枠を利用して、使用量が少ない期間にアップデートとシステム変更を集中させることで、中断とリソース消費を削減できます。これらの戦術を組み合わせることで、インフラストラクチャの費用を抑えながら、高可用性とパフォーマンスを維持できます。

10. 詳細な請求金額の分析で費用を把握する

Google Cloud で費用削減戦略を実装する前に、現在の支出を詳細に把握することが不可欠です。Google Cloud の請求パネルでは、個々の SKU ごとの費用など、費用の詳細な可視性が提供されます。このレベルの透明性により、費用の流れを追跡し、潜在的な非効率性を特定できます。まず、請求ダッシュボードを定期的に確認して、使用量の傾向をモニタリングし、異常を検出します。リソースにラベルとタグを適用すると、特に複数のプロジェクトや部門がある複雑な環境で、費用を正確に分類して割り当てることができます。

さらに、予算アラートを設定すると、費用が事前定義されたしきい値に近づいた場合や超えた場合に通知されるため、費用超過を未然に防ぐことができます。また、アクティブに使用されなくなった仮想マシンや永続ディスクなど、未使用またはアイドル状態のリソースを特定して排除することも重要です。これらはシャットダウンまたは削除することで、費用をすぐに削減できます。費用構造を徹底的に分析することで、「低く垂れ下がった果実」である価値がほとんど、あるいはまったくないリソースを特定し、データドリブンな意思決定を行ってクラウドの使用を効率的に最適化できます。

11. サーバーレスの代替手段を検討する

最後に、Google Cloud のサーバーレスコンピューティングサービスは、従来の仮想マシンに代わる魅力的な選択肢であり、費用対効果の向上、運用の簡素化、スケーラビリティの向上を実現できます。インフラストラクチャ管理を抽象化することで、サーバーレスプラットフォームでは、チームがサーバーのプロビジョニング、スケーリング、メンテナンスを心配することなく、コードの作成とデプロイに集中できます。この移行により、運用オーバーヘッドを削減できるだけでなく、コンピューティング費用をアプリケーションの使用量に直接合わせることで費用を削減できます。

さまざまなサーバーレスオプションが用意されており、それぞれが異なるワークロードに合うように作られています。

Cloud Run は、迅速なスケーリングと柔軟なデプロイが必要なコンテナ化されたアプリケーションを実行するために設計されています。Cloud Run Functions は、マイクロサービスや自動化タスク向けの軽量なイベントドリブンコード実行をサポートします。GKE（Autopilot モード）は、ノードの管理とスケーリングを自動化することで Kubernetes の運用を簡素化し、基盤となるインフラストラクチャを処理することなく Kubernetes ワークロードを実行できるようにします。これらのオプションはすべて、割り当てではなく使用量に基づいて課金されるため、アイドル状態のリソースやオーバープロビジョニングに関連する費用を大幅に削減できます。そのため、変動するワークロードや予測不可能なワークロードに特に役立ちます。Cloud Run と GKE はどちらも GPU をサポートしており、両者間の移行も柔軟に行えます。Cloud Run から始めて GKE に移行することも、その逆も可能です。一部のお客様は、ワークロードに両方のサービスを利用されています。Kubernetes API にアクセスする必要がある場合は、GKE から始めるのが良いでしょう。それ以外の場合は、Cloud Run から始めます。

今すぐ費用削減を始めましょう

Google Cloud に移行して、自社のワークロードに必要なものを妥協することなく、インフラストラクチャの費用を最適化できます。Google Cloud を初めて使用する場合は、まず移行評価から始めます。Google Cloud の Migration Center を使用すると、Google Cloud への移行によって得られる潜在的な費用削減額を明確に把握できます。また、ワークロードの推奨パスの詳細や TCO レポートも確認できます。この記事の戦略を適用して、大幅なコスト削減を実現しましょう。

-グループプロダクトマネージャー、Alex Bestavros

-Google Cloud、プロダクト管理担当、Sai Gopalan

Google Kubernetes Engine で Managed Lustre を使用するときのベストプラクティス 5 つ

Wed, 08 Oct 2025 01:00:00 +0000

※この投稿は米国時間 2025 年 9 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Kubernetes Engine（GKE）は、スケーラブルな AI とハイパフォーマンスコンピューティング（HPC）のワークロードをオーケストレートするための強力なプラットフォームです。しかし、クラスタが拡大し、ジョブのデータ集約度が高まるにつれて、ストレージの I/O がボトルネックになる可能性があります。また、強力な GPU と TPU がデータの到着を待つ間、アイドル状態になり、コストが増加してイノベーションが遅れる可能性があります。

Google Cloud Managed Lustre は、この問題を解決するために設計されています。多くのオンプレミス型 HPC 環境はすでに並列なファイルシステムを使用しており、Managed Lustre を使うと、これらのワークロードをクラウドに移行するのがより簡単になります。また、マネージド Container Storage Interface（CSI）ドライバにより、Managed Lustre と GKE のオペレーションが完全に統合されます。

そして、高性能かつ並列なファイルシステムへの移行を最適化することで、初日から投資を最大限に活用できます。

デプロイする前に、Managed Lustre を使用するタイミングと、Google Cloud Storage などの他のプロダクトを使用するタイミングを把握しておくと便利です。ほとんどの AI / ML ワークロードでは、Managed Lustre が推奨ソリューションであり、非常に低いレイテンシ（1 ミリ秒未満）と小さなファイルに対する高いスループットが求められるトレーニングとチェックポイントのシナリオで優れた力を発揮します。ただし、それゆえに高価なアクセラレータは引き続き完全に活用することになります。データアーカイブや、レイテンシが高くなっても問題がない大きなファイル（50 MB 超）を使用するワークロードには、Anywhere Cache を使用する Cloud Storage FUSE も別の選択肢となりえます。

初期のお客様との取り組みとチームからの学びに基づいて、GKE で Managed Lustre を確実に最大限に活用するためのベストプラクティスを 5 つご紹介します。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud のコンテナと Kubernetes をお試しいただける $300 分の無料クレジット'), ('body', <wagtail.rich_text.RichText object at 0x7f338ab43820>), ('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 0x7f338af599a0>)])]>

ベストプラクティスである理由: WaitForFirstConsumer を使用すると、Lustre インスタンスを必要とする Pod がスケジュールされるまで、その Lustre インスタンスのプロビジョニングを遅らせることを求める指示が GKE に届きます。その後、スケジューラは Pod のトポロジ制約（つまり、Pod がスケジュールされているゾーン）を使用して、そのゾーンに Lustre インスタンスを作成します。これにより、ストレージとコンピューティングのコロケーションが保証され、ネットワークレイテンシが最小限に抑えられます。

2. ティアでパフォーマンスを適正化

すべての高パフォーマンスワークロードが同一なわけではありません。Managed Lustre には複数のパフォーマンスティア（ストレージ 1 TiB あたりの読み取り / 書き込みスループット（MB/秒））があるため、コストをパフォーマンス要件に直接整合させることができます。

1,000 & 500 MB/秒/TiB: I/O 帯域幅が主なボトルネックとなる、基盤モデルのトレーニングや大規模な物理シミュレーションなど、スループットが重要なワークロードに最適です。
250 MB/秒/TiB: バランスの取れた費用対効果が高いティアであり、一般的な HPC ワークロードや AI 推論サービング、データ量が多い分析パイプラインに最適です。
125 MB/秒/TiB: ピーク時のスループット達成よりも、POSIX 準拠の大規模なファイルシステムがあることが重要な大型のユースケースに最適です。これは、オンプレミスのコンテナ化されたアプリケーションを修正せずに移行する場合にも役立ち、オンプレミスのワークロードをクラウドストレージに移行するのがより簡単になります。

ベストプラクティスである理由: デフォルトで最上位のティアを選択することが、必ずしも費用対効果の高い戦略とは限りません。ワークロードの I/O プロファイルを分析することで、総所有コストを大幅に最適化できます。

3. ネットワーキングの基礎を習得

並列なファイルシステムは、ネットワークに接続しているリソースです。ネットワーキングを最初から適切に設定することで、トラブルシューティングに費やす時間を大幅に節約できます。プロビジョニングする前に、ドキュメントに記載されているセットアップ手順に沿って VPC を確実に正しく構成してください。これには、ドキュメントで詳しく説明されている 3 つの主要な手順が含まれます。

サービスネットワーキングを有効にする。

VPC ピアリングのIP 範囲を作成する。
Lustre のネットワークポート（TCP 988 または 6988）でその範囲からのトラフィックを許可するファイアウォールルールを作成する。

ベストプラクティスである理由: これは、GKE ノードが Managed Lustre サービスと通信できるようにするセキュリティが確保されたピアリング接続を確立する、VPC ごとの 1 回限りの設定です。

4. シンプルな場合は動的プロビジョニングを、長期的に共有するデータには静的プロビジョニングを

Managed Lustre CSI ドライバには、ストレージを GKE ワークロードに接続するための 2 つのモードがあります。

動的プロビジョニング: ストレージが特定のワークロードまたはアプリケーションのライフサイクルに密接に結び付いている場合に使用します。StorageClass と PersistentVolumeClaim（PVC）を定義すると、GKE が Lustre インスタンスのライフサイクルを自動的に管理します。これは最もシンプルで自動化されたアプローチです。
静的プロビジョニング: 複数の GKE クラスタと Job で共有する必要がある、存続期間の長い Lustre インスタンスがある場合に使用します。Lustre インスタンスを一度作成したら、クラスタ内に PersistentVolume（PV）と PVC を作成して、そのインスタンスにマウントします。これにより、ストレージのライフサイクルが単一のワークロードから切り離されます。

ベストプラクティスである理由: データのライフサイクルを考慮することは、適切なパターンを選択するのに役立ちます。シンプルさを重視してデフォルトとして動的プロビジョニングを使用し、ファイルシステムを組織全体で永続的な共有リソースとして扱う必要がある場合は静的プロビジョニングを選択します。

5. Kubernetes Job を使用した並列処理のアーキテクチャ設計

データの前処理やバッチ推論など、多くの AI および HPC に関するタスクは並列実行に適しています。1 つの大きな Pod を実行する代わりに、Kubernetes Job リソースを使用して、作業を多くのより小さな Pod に分割します。

次のパターンを考えてみましょう。

Managed Lustre インスタンスの PersistentVolumeClaim を 1 つ作成し、クラスタで利用できるようにします。
Kubernetes Job の並行処理を高い数値（例: 100）に設定して、定義します。
Job によって作成された各 Pod は、同じ Lustre PVC をマウントします。
各 Pod がデータの異なるサブセットで動作するようにアプリケーションを設計します（例: 異なる範囲のファイルやデータチャンクを処理する）。

ベストプラクティスである理由: このパターンでは、Lustre インスタンス用に 1 つの PVC を作成し、Job によって作成された各 Pod が同じ PVC をマウントします。各 Pod がデータの異なるサブセットで動作するようにアプリケーションを設計することで、GKE クラスタを強力な分散データ処理エンジンに変えることができます。GKE Job コントローラは並列なタスクオーケストレーターとして機能し、Managed Lustre は高速なデータバックボーンとして機能するため、大規模な集計スループットを実現できます。

使ってみる

GKE のオーケストレーション機能と Managed Lustre のパフォーマンスを組み合わせることで、AI と HPC 向けの真にスケーラブルで効率的なプラットフォームを構築できます。これらのベストプラクティスに従うことで、強力であるだけでなく、効率的で費用対効果が高く、管理しやすいソリューションを作成できます。

準備ができたら Managed Lustre のドキュメントを確認して、今すぐ最初のインスタンスをプロビジョニングしましょう。

ーエンジニアリングマネージャー、Nishtha Jain

ーシニアプロダクトマネージャー、Dan Eawaz

Storage Insights データセット: 詳細な可視性でストレージ費用を最適化する方法

Thu, 11 Sep 2025 01:20:00 +0000

※この投稿は米国時間 2025 年 8 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。

クラウドストレージで大量のデータを管理するのは難しい場合があります。Google Cloud Storage は優れたスケーラビリティと耐久性を備えていますが、ストレージ管理者は次のような疑問に悩まされることがあります。

ストレージ費用を押し上げている要因は何か？
Cloud Storage のすべてのデータがどこにあり、どのように分散されているか？
年齢やサイズなどの特定のメタデータをデータ全体で検索するにはどうすればよいか？

実際、費用最適化、セキュリティ、コンプライアンスを実現するには、何がどこにあり、どのように使用されているかを把握する必要があります。そこで役立つのが、Cloud Storage 向けの Storage Intelligence の機能である Storage Insights データセットです。Storage Intelligence は、大規模なストレージエステートを分析し、簡単に対策を講じるための複数の優れた機能を備えた統合管理プロダクトです。データの探索、費用の最適化、セキュリティの適用、ガバナンスポリシーの実装に役立ちます。Storage Insights データセットを使用すると、ストレージフットプリントを詳細に分析できます。また、Gemini Cloud Assist を使用して、自然言語で迅速に分析できます。これらの分析に基づいて、バケットの再配置や大規模なバッチオペレーションの実行などのアクションを実行できます。

このブログでは、Insights データセットを使用して費用管理と可視化を行う方法に焦点を当て、さまざまな一般的なユースケースを確認します。これは、クラウドの費用配賦、モニタリング、予測を行うクラウド管理者や FinOps チームにとって特に便利です。

Storage Insights データセットとは

Storage Insights データセットは、Cloud Storage データを詳細に可視化する強力な自動化された方法を提供します。Storage Insights データセットは、手動スクリプト、バケットのカスタムの単発レポート、独自のコレクションパイプラインの管理の代わりに、Cloud Storage オブジェクトとそのアクティビティに関する包括的なレポートを生成し、BigQuery のリンクされたデータセットに直接配置します。

Cloud Storage バケットのレントゲン写真のようなものです。自動データ更新は 24 時間ごとに行われ（初回読み込みには最大 48 時間かかる場合があります）、未加工のストレージメタデータを構造化されたクエリ可能なデータに変換します。このデータは、使い慣れた BigQuery ツールで分析して重要な分析情報を得ることができます。

主な機能

カスタマイズ可能なスコープ: データセットのスコープを、組織、プロジェクトを含むフォルダ、プロジェクト / プロジェクトのセット、または特定のバケットのレベルに設定します。
メタデータデータセット: バケットとオブジェクトのメタデータが BigQuery に直接含まれる、クエリ可能なデータセットを提供します。
定期的な更新と保持: 最初の読み込み後、データセットは 24 時間ごとにメタデータで更新され、最大 90 日間データを保持できます。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7f338ac74430>), ('btn_text', ''), ('href', ''), ('image', None)])]>

ユースケース

ルーチンショーバックの計算

誰が / どのアプリケーションがどのストレージを消費しているかを把握することは、特に大規模な組織の場合、効果的な費用管理の第一歩となることがよくあります。Storage Insights データセットを使用すると、オブジェクトとバケットのメタデータを BigQuery で利用できます。SQL クエリを実行して、特定のチーム、プロジェクト、アプリケーションによるストレージ使用量を集計できます。これにより、バケットまたはプレフィックスごとにストレージ使用量を帰属させ、社内チャージバックや費用のアトリビューションに利用できます。たとえば、「先月、X 部門は gs://my-app-data/department-x/ で 50 TB のストレージを使用しました」といった情報を得られます。この透明性により、説明責任が促進され、正確な社内ショーバックが可能になります。

データセット内のバケットとプレフィックスごとの合計ストレージを特定する SQL クエリの例を次に示します。

code_block: <ListValue: [StructValue([('code', "SELECT\r\n bucket,\r\n SPLIT(name, '/')[\r\nOFFSET\r\n (0)] AS top_level_prefix,\r\n SUM(size) AS total_size_bytes\r\nFROM\r\n object_attributes_view\r\nGROUP BY\r\n bucket, top_level_prefix\r\nORDER BY\r\n total_size_bytes DESC;\r\n//データセットでクエリを実行すると、BQ クエリ費用が発生します。詳細については、料金の詳細ページをご覧ください。"), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7f338ac74820>)])]>

ストレージクラス全体でどのくらいのデータがあるかを把握する

Storage Insights データセットは、バケット内のすべてのオブジェクトのストレージクラスを特定します。BigQuery のオブジェクトメタデータビューで storageClass, timeCreated, updated をクエリすることで、一定期間経過したオブジェクトのさまざまなクラス（Standard、Nearline、Coldline、Archive）にわたるデータ分布と、最後に更新された日時をすばやく可視化できます。これにより、誤分類された可能性のあるデータを特定できます。また、timeStorageClassUpdated オブジェクトメタデータを使用して、Coldline ストレージまたは Archive ストレージのデータを含むバケット全体があるかどうかや、オブジェクトがストレージクラス間で予期せず移動したかどうか（たとえば、Archive ストレージにあるはずのファイルが Standard ストレージクラスにあるなど）に関する貴重な分析情報も提供します。

2 年前に作成され、それ以降更新されておらず、Standard クラスにあるすべてのオブジェクトを確認する SQL クエリの例を次に示します。

code_block: <ListValue: [StructValue([('code', "SELECT\r\n bucket,\r\n name,\r\n size,\r\n storageClass,\r\n timeCreated,\r\n updated\r\nFROM object_attributes_latest_snapshot_view\r\nWHERE\r\n EXTRACT(YEAR\r\n FROM\r\n timeCreated) = EXTRACT(YEAR\r\n FROM\r\n DATE_SUB(CURRENT_DATE(), INTERVAL 24 MONTH))\r\n AND (updated IS NULL\r\n OR updated = timeCreated)\r\n AND storageClass = 'STANDARD'\r\nORDER BY\r\n timeCreated;\r\n//データセットでクエリを実行すると、BQ クエリ費用が発生します。詳細については、料金の詳細ページをご覧ください。"), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7f338ac74ac0>)])]>

ライフサイクルポリシーと Autoclass ポリシーの設定: 費用の自動削減

手動でのデータ管理は時間がかかり、エラーが発生しやすいものです。Storage Insights データセットは、オブジェクトのライフサイクル管理（OLM）または Autoclass を使用することで費用を削減できる場所を特定するのに役立ちます。

OLM または Autoclass が構成されていないバケットを特定する: Storage Insights データセットを使用して、バケットのメタデータをクエリし、lifecycle, autoclass.enabled フィールドを使用して、ライフサイクルポリシーが定義されていないバケットを確認できます。バケットに、一定期間後により使用頻度の低いストレージに移行するか削除する必要があるデータが含まれているにもかかわらず、ポリシーが設定されていない場合、さらに調査する必要があるエステートの部分を把握することで、適切なアクションを実行できます。Storage Insights データセットは、これらの「管理されていない」バケットにフラグを立てるためのデータを提供し、ベストプラクティスの適用を支援します。

ライフサイクル構成または AutoClass 構成が有効になっているすべてのバケットと、アクティブな構成がないすべてのバケットを確認する SQL クエリの例を次に示します。

code_block: <ListValue: [StructValue([('code', "SELECT\r\n name AS bucket_name,\r\n storageClass AS default_class,\r\n CASE\r\n WHEN lifecycle = TRUE OR autoclass.enabled = TRUE THEN 'Managed'\r\n ELSE 'Unmanaged'\r\nEND\r\n AS lifecycle_autoclass_status\r\nFROM bucket_attributes_latest_snapshot_view\r\n//データセットでクエリを実行すると、BQ クエリ費用が発生します。詳細については、料金の詳細ページをご覧ください。"), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7f338ac74490>)])]>

Autoclass の影響を評価する: Autoclass は、固定のアクセスタイムラインに基づいて、ストレージクラス間でオブジェクトを自動的に移行します。しかし、期待どおりに機能しているかどうか、さらなる最適化が必要かどうかをどのように判断すればよいのでしょうか。Storage Insights データセットを使用すると、autoclass.enabled フィールドを使用して Autoclass が有効になっているバケットを見つけ、storageClass, timeStorageClassUpdated フィールドを時間の経過とともに追跡して、Autoclass が有効になっているバケット内の特定のオブジェクトのオブジェクトメタデータを分析できます。これにより、Autoclass の有効性を評価し、指定したオブジェクトが実際に最適なクラスに移動しているかどうかを確認し、費用に対する実際の影響を把握できます。たとえば、バケットで Autoclass を構成すると、31 日目のストレージクラス間のデータの移動を 1 日目と比較して可視化し、Autoclass ポリシーがバケットにどのように影響するかを把握できます。
Autoclass の適合性を評価する: バケットのデータを分析して、Autoclass を使用することが適切かどうかを判断します。たとえば、バケットに保存されているデータの有効期間が短い場合（30 日未満）（timeCreated と timeDeleted を使用して、バケット内のオブジェクトの平均有効期間を判断するために、日次スナップショットでオブジェクトを評価できます）、Autoclass を有効にしない方がよい場合があります。

以下は、bucketA と bucketB で、経過時間が 30 日を超えるオブジェクトと 30 日未満のオブジェクトの数を調べる SQL クエリの例です。

code_block: <ListValue: [StructValue([('code', "SELECT\r\n SUM(\r\n CASE\r\n WHEN TIMESTAMP_DIFF(t1.timeDeleted, t1.timeCreated, DAY) < 30 THEN 1\r\n ELSE 0\r\n END\r\n ) AS age_less_than_30_days,\r\n SUM(\r\n CASE\r\n WHEN TIMESTAMP_DIFF(t1.timeDeleted, t1.timeCreated, DAY) > 30 THEN 1\r\n ELSE 0\r\n END\r\n ) AS age_more_than_30_days\r\nFROM\r\n `object_attributes_view` AS t1\r\nWHERE\r\n t1.bucket IN ( 'bucketA', 'bucketB')\r\n AND t1.timeCreated IS NOT NULL\r\n AND t1.timeDeleted IS NOT NULL;\r\n//データセットでクエリを実行すると、BQ クエリ費用が発生します。詳細については、料金の詳細ページをご覧ください。"), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7f338ac740d0>)])]>

プロアクティブなクリーンアップと最適化

Storage Insights データセットは、日常的な管理だけでなく、無駄なストレージを事前に見つけて排除するのにも役立ちます。

重複オブジェクトをすばやく検出: ストレージの無駄となる一般的な原因の一つに、誤って作成された重複があります。BigQuery クエリでオブジェクトメタデータ（サイズ、名前、crc32c チェックサムなど）を使用して、重複の可能性を特定できます。たとえば、サイズとチェックサムがまったく同じで、類似する名前の複数のオブジェクトが見つかった場合、冗長性があることを示している可能性があるため、さらに調査する必要があります。

サイズ、crc32c チェックサムフィールド、名前が同じ値である（重複の可能性を示します）すべてのオブジェクトを一覧表示する SQL クエリの例を次に示します。

code_block: <ListValue: [StructValue([('code', 'SELECT\r\n name,\r\n bucket,\r\n timeCreated,\r\n crc32c,\r\n size\r\nFROM (\r\n SELECT\r\n name,\r\n bucket,\r\n timeCreated,\r\n crc32c,\r\n size,\r\n COUNT(*) OVER (PARTITION BY name, size, crc32c) AS duplicate_count\r\n FROM\r\n `object_attributes_latest_snapshot_view` )\r\nWHERE\r\n duplicate_count > 1\r\nORDER BY\r\nsize DESC;\r\n//データセットでクエリを実行すると、BQ クエリ費用が発生します。詳細については、料金の詳細ページをご覧ください。'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7f338ac749d0>)])]>

クリーンアップする一時オブジェクトを見つける: 多くのアプリケーションは一時ファイルを生成します。一時ファイルは、削除しないと、時間が経つにつれて蓄積されます。Storage Insights データセットを使用すると、特定の命名規則に一致するオブジェクト（例: *_temp、*.tmp）または「temp」プレフィックスに保存されているオブジェクトと、それらの作成日を一覧表示します。これにより、孤立した一時データを体系的に特定してクリーンアップし、貴重なストレージ容量を解放できます。

1 か月前に作成されたすべてのログファイルを検索する SQL クエリの例を次に示します。

code_block: <ListValue: [StructValue([('code', 'SELECT\r\n name, bucket, timeCreated, size\r\n FROM\r\n \'object_attributes_latest_snapshot_view\'\r\n WHERE\r\n name LIKE "%.log"\r\nAND DATE(timeCreated) <= DATE_SUB(CURRENT_DATE(), INTERVAL 1 MONTH)\r\nORDER BY\r\nsize DESC;\r\n//データセットでクエリを実行すると、BQ クエリ費用が発生します。詳細については、料金の詳細ページをご覧ください。'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7f338ac74460>)])]>

特定の日付より古いすべてのオブジェクトを一覧表示して、簡単にアクションを実行する: コンプライアンスのために、5 年以上前のすべての画像をアーカイブまたは削除する必要がある、または 90 日以上前のログをクリーンアップする必要がある場合があるかもしれません。Storage Insights データセットは、すべてのオブジェクトの timeCreated と contentType を提供します。簡単な BigQuery クエリで、指定した日付より古いすべてのオブジェクトを一覧表示できるため、さらに調査するためのオブジェクトの明確で実用的なリストが得られます。Storage Intelligence のバッチオペレーションを使用すると、数十億のオブジェクトに対してサーバーレスでアクションを実行できます。
削除（復元可能）の適合性を確認する: オブジェクトメタデータテーブルで softDeleteTime と size の存在をクエリして、削除（復元可能）されたデータのストレージサイズが大きいバケットを見つけます。このような場合、データは一時的なものと見なされ、削除（復元可能）の費用の最適化の機会を調査する必要があるかもしれません。

分析をさらに深める

Storage Intelligence Insights データセットの真の力は、提供される元データだけでなく、そこから得られる分析情報と、その後に実行できるアクションにあります。Cloud Storage のメタデータが BigQuery に取り込まれると、高度な分析と統合の可能性が大きく広がります。

たとえば、Google Cloud の無料のデータ可視化およびダッシュボードツールである Looker Studio を使用して、BigQuery Insights データセットに直接接続し、複雑なクエリを直感的でインタラクティブなダッシュボードに変換できます。次のことを行えるようになりました。

費用の傾向を可視化: プロジェクト、部門、ストレージクラスごとのストレージ使用量を経時的に示すダッシュボードを作成します。これにより、チームは支出を簡単に追跡し、急増を特定して、将来の費用を予測できます。
急成長しているバケットを追跡する: 過去 1 週間または 1 か月で最も成長したバケットを分析し、既知のプロジェクトと比較して、正確な費用のアトリビューションを実現します。Looker のアラート機能を使用して、バケット内のデータの合計サイズが急増するなど、特定のしきい値に達したときに通知を受け取ります。
一般的な分析用のカスタムグラフを設定する: 日常的な FinOps ユースケース（OLM ポリシーが構成されていないバケットや、保持期限が切れたオブジェクトの追跡など）では、関連するチーム向けに週次レポートを生成して、簡単にアクションを実行できるようにします。

また、こちらのテンプレートを使用してデータセットに接続し、迅速に分析することも、独自のカスタムダッシュボードを作成することもできます。

始める

Storage Intelligence を構成してデータセットを作成し、30 日間のトライアルでストレージエステートの分析を今すぐ開始しましょう。費用の詳細については、料金に関するドキュメントをご覧ください。

データセットを任意のスコープに設定して、データの分析を開始します。

中央の FinOps チームが毎月分析するために、チームまたは部門の使用状況に基づいて Looker Studio ダッシュボードのセットを構成します。
BigQuery を使用してアドホック分析を行い、特定の分析情報を取得します。
費用を全体的に把握するには、Storage Insights データセットを Google Cloud の BigQuery への請求データのエクスポートと統合できます。請求データのエクスポートでは、Cloud Storage を含むすべての Google Cloud サービスの費用に関する詳細な情報が提供されます。

ーストレージ担当プロダクトマネージャー、Misha Sheth

ーストレージ担当 EMEA ソリューションリード、Chris Madden

Cloud Storage バケットの再配置: 業界初の中断を伴わないバケット移行

Wed, 30 Jul 2025 01:10:00 +0000

※この投稿は米国時間 2025 年 7 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

運用ニーズの変化に伴い、レジリエンスの向上、パフォーマンスの最適化、コンプライアンスニーズへの対応、または単にインフラストラクチャの再編成を目的として、Google の Cloud Storage に保存されているデータを新しいロケーションに移動する必要が生じる場合があります。しかし、バケットの移動は、手動スクリプト、入念な調整、データ損失のリスク、さらにはダウンタイムの延長を伴う、困難で複雑かつ危険な作業となる可能性があります。このため、組織がストレージ環境に必要な変更を加えることを躊躇する可能性があります。

Google は最近、Cloud Storage バケットの再配置を導入しました。これは、主要なハイパースケーラーの中でも独自の機能で、バケットのロケーションを簡単に変更できます。バケットの再配置により、複雑な手動での計画が不要になり、ダウンタイムの長期化を防ぐことができます。アプリケーションの中断を最小限に抑え、データの完全性を確保しながら、簡単に移行できます。バケットの名前と、その中のすべてのオブジェクトメタデータは、再配置後も同一のままです。そのため、パスは変更されず、基盤となるストレージが移動している間も、アプリケーションのダウンタイムは最小限に抑えられます。さらに、オブジェクトは元のストレージクラス（例: Standard、Nearline、Coldline、Archive）と、新しいロケーションでのクラス内時間を保持します。これは、多くの費用効率戦略の鍵となります。Autoclass などの機能が引き続きインテリジェントに動作し、移行後のストレージ費用を最適化できるようにします。

バケットの再配置は、Storage Intelligence スイートの重要な機能です。Storage Insights などのツールと併用することで、ストレージ環境を詳細に可視化し、最適化の機会を特定できます。バケットの再配置により、こうした分析情報を活用して、さまざまな Cloud Storage のロケーション（低レイテンシのリージョン、高可用性と障害復旧のデュアルリージョン、グローバルアクセスのマルチリージョン）間でデータを移動し、ビジネス、パフォーマンス、コンプライアンスの目標を達成できます。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7f339d1bea00>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

バケットの再配置の仕組み

バケットの再配置は、2 つの重要な手法に依存しています。

非同期データコピー: バケットの再配置では、独自の最適化された非同期データ転送メカニズムを利用して、バックグラウンドでデータをコピーし、進行中のオペレーションへの影響を最小限に抑えます。データセット全体のコピー中も、オブジェクトの書き込み、読み取り、更新などの既存のオペレーションは継続されます。
メタデータの保持: 従来、Google Cloud のお客様はデータの移動に Storage Transfer Service を使用していました。ここでは、オブジェクトを新しいバケットにコピーし、既存のオブジェクトを削除していました。一方、バケットの再配置では、バケットとオブジェクトに関連付けられたすべてのメタデータが自動的かつ綿密に移動されるため、状態が保持されます。これには、次のような情報が含まれます。

ストレージクラス: オブジェクトは元のストレージクラス（例: Standard、Nearline、Coldline、Archive）を新しいロケーションで保持します。
バケット名とオブジェクト名: バケットとオブジェクトの命名構造は同じままです。
作成と更新のタイムスタンプ: これらのマーカーは保持されるため、オブジェクトのライフサイクル管理（OLM）ルールなどの機能は引き続き動作します。
アクセス制御リスト（ACL）と IAM ポリシー: バケットレベルとオブジェクトレベルの権限が移行され、セキュリティポスチャーの維持に役立ちます。
カスタムメタデータ: オブジェクトに関連付けられたユーザー定義のメタデータも移行されます。

バケットの再配置は、非同期データ転送とメタデータの自動移行の複雑さを処理することで、手動によるバケット移行に伴うリスクとオーバーヘッドを最小限に抑えます。重要な点として、バケット名は再配置プロセス全体で保持されるため、バケットにアクセスするアプリケーションを変更する必要はありません。

簡単な手順でバケットを再配置

バケットの再配置では、3 つの簡単なステップで Cloud Storage バケットを移動できます。詳細は次のとおりです。

1. ドライランを開始する:

再配置を実際に開始する前に、ドライランを行うことを強くおすすめします。データは移動せずにプロセスをシミュレートするため、互換性のない構成など、潜在的な問題を早期に特定できます。
ドライランでは、顧客管理の暗号鍵（CMEK）、ロックされた保持ポリシー、一時的な保持が設定されたオブジェクト、バケットタグなどの非互換性がチェックされます。これらの項目を個別に手動で検証する必要はありません。
--dry-run フラグを追加してください。

code_block: <ListValue: [StructValue([('code', 'gcloud storage buckets relocate gs://BUCKET_NAME --location=LOCATION --dry-run'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f338b1cb610>)])]>

BUCKET_NAME をバケットの名前に、LOCATION を目的の宛先に置き換えます。

2. 再配置プロセスを開始する:

このステップでは、ソースバケットから宛先バケットへの実際のデータ転送が開始されます。このフェーズでは、バケット内のオブジェクトの読み取り、変更、削除は可能です。ただし、バケットのメタデータ（バケットレベルのパラメータと構成）は書き込みロックされ、再配置に影響する可能性のある変更を防ぎます。注: ドライランコマンドから --dry-run フラグを削除すると、再配置が開始されます。

code_block: <ListValue: [StructValue([('code', 'gcloud storage buckets relocate gs://BUCKET_NAME --location=LOCATION'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f338b1cb040>)])]>

3. 再配置プロセスを完了する:

増分データのコピーが完了したら、最終的な同期ステップを開始できます（マルチリージョンと構成可能なデュアルリージョン間の移動を除く）。このステップでは、データの完全性を確保するためにバケットへの書き込みが短時間無効になります。増分コピーの進行中にバケット内のオブジェクトに加えられた直前の変更は、転送先にコピーされます。データの完全性が検証されると、バケットのロケーションが更新され、すべてのリクエストが新しいロケーションに自動的にリダイレクトされます。最終的な同期ステップで、バケット内のオブジェクトを更新しようとすると、HTTP 412 エラーが発生します。
再配置プロセスの進行状況が 99% 程度に達するまで、最終的な同期プロセスを開始しないでください。これにより、ほとんどのデータがバックグラウンドで同期済みとなるため、ダウンタイムを最小限に抑えることができます。

注: 同じマルチリージョンコード内でマルチリージョンと構成可能なデュアルリージョン間を移動する場合は、バケットの再配置によってバックグラウンドで移行が処理されるため、最終処理やダウンタイムは発生しません。

code_block: <ListValue: [StructValue([('code', 'gcloud storage buckets relocate --finalize --operation=projects/_/buckets/BUCKET_NAME/operations/OPERATION_ID'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f338b1cb400>)])]>

OPERATION_ID はステップ 2 の出力として提供されます。OPERATION_ID はキーワード名とともに表示されます。次に例を示します。

name: projects/_/buckets/my-bucket/operations/AbCJYd8jKT1n-Ciw1LCNXIcubwvij_TdqO-ZFjuF2YntK0r74

これで完了です。わずか 3 ステップで、バケット全体とそのデータとメタデータを新しいロケーションに移動できました。

バケットの再配置を早期に利用したユーザーは、この新機能で大きな成果を上げています。

「Storage Intelligence とバケットの再配置により、デュアルリージョンバケットへの移行を簡単に実現できました。バケットの再配置によって実現したシームレスなプロセスにより、ダウンタイムを最小限に抑え、データの完全性を確保しました。手動で苦労することなく、安心してバケットを移行できたのです」- Spotify、プロダクトマネージャー Adam Steele 氏

「最近、Storage Intelligence のバケットの再配置機能を利用して、ネットワークデータ転送コストを最適化するために、マルチリージョンからリージョンストレージへの約 300 個のバケットとペタバイト単位のデータプロジェクトの移行を成功させました。バケットの再配置がなければ、このプロセスには広範な自動化とスクリプト化が必要となり、ダウンタイムと労力が増加していました」 - Groupon、データプラットフォームインフラストラクチャマネージャー、Deepak Mahato 氏

Storage Intelligence のバケットの再配置で、Cloud Storage バケットを簡単かつ効率的に管理できます。詳しくは、バケットの再配置に関するドキュメントとStorage Intelligence の概要をご覧ください。

ー Google Cloud、シニアプロダクトマネージャー、Vaibhav Khunger

プロジェクト間のバックアップと復元により GKE のデータ保護を強化

Tue, 29 Jul 2025 00:10:00 +0000

※この投稿は米国時間 2025 年 7 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Kubernetes Engine（GKE）のデプロイの拡大とスケーリングに伴い、Google Cloud でマルチプロジェクト戦略を採用することが、セキュリティと環境を重視する組織にとってのベストプラクティスになります。開発環境、テスト環境、本番環境に個別のプロジェクトを使用することで明確な境界が生まれ、システムの分離性が高まり、アクセス制御がしやすくなります。

しかし、分離によってデータ保護の課題が生じます。これらのプロジェクト境界を越えてバックアップを効果的に管理するにはどうすればよいでしょうか。ネイティブソリューションがない場合、バックアップの一元化、IAM による職務分掌の明確化、確実な障害復旧体制の構築はすべて複雑なタスクとなり、多くの場合、チームはカスタムスクリプトや非効率的な手動プロセスに頼らざるを得なくなります。

プロジェクト間のバックアップと復元の概要

この問題を解決するために、現在プレビュー版の Backup for GKE では、プロジェクト間のバックアップと復元がサポートされています。この新機能により、1 つの Google Cloud プロジェクトの GKE クラスタからワークロードをバックアップし、2 つ目のプロジェクトに安全に保存して、3 つ目のプロジェクトのクラスタに復元できます。これは、データ保護の効率化、セキュリティポスチャーの強化、運用ワークフローの柔軟性向上につながります。バックアップを別の分離されたプロジェクトとリージョンに保存することは、最新の障害復旧に不可欠であり、リージョンの停止や Google Cloud プライマリプロジェクトでの侵害が発生した場合でも復旧機能を保護し、レジリエントなインフラストラクチャの基盤となります。この分離により、規制遵守が簡素化されるとともに、潜在的なインシデントの影響拡大を防いでセキュリティが強化され、RTO/RPO の目標達成にも役立ちます。

プロジェクト間のバックアップと復元の主なメリット

バックアップの一元管理: 各クラスタのバックアッププランを、選択したバックアッププロジェクトに指定することで、複数の Google Cloud プロジェクトの GKE バックアップを 1 つのプロジェクトに統合します。このシンプルな構成により、チームは 1 つのコントロールプレーンでモニタリングを監視し、バックアップポリシーを管理できます。
強化された障害復旧: GKE バックアップを別のプロジェクトとリージョンに保存することで、重要な分離レイヤが提供され、リージョン停止などのイベントに対する復元力が向上します。ソースリージョンが利用できなくなった場合は、バックアッププロジェクトから復元プランを作成して、別のプロジェクトのクラスタにワークロードを復元できます。
オペレーションの効率化: シード、クローン、コラボレーション環境間でのデータのコピーが簡略化されるため、プロジェクトをまたぐ機能によって開発ライフサイクルにアジリティがもたらされます。本番環境のバックアップデータをテストに活用したり、アプリケーション環境全体を迅速に複製したりすることが可能です。

環境のシードとクローン: 以前のバックアップからデータをステージング環境に投入したり、サンドボックスを作成したりできます。バックアッププロジェクトにある既存のバックアッププランを使用して復元プランを作成し、シード用の本番環境からのバックアップや、クローン作成用の開発環境からのバックアップなど、バックアップを選択して、任意の他のプロジェクトのクラスタを宛先として指定します。これにより、テスト環境と分離されたサンドボックスを作成できます。
チーム間のコラボレーションの効率化: すべてのバックアップは一元化されたバックアッププロジェクトに保存されるため、別のチームの開発者に対して委任された復元管理者などのロールを割り当て、特定のバックアッププランとそれに関連するすべてのバックアップに対する読み取り権限を付与できます。権限を付与された開発者は、他のチームのライブソースプロジェクトにアクセスすることなく、そのバックアップを使用してクラスタを復元することが可能です。

セキュリティとコンプライアンスの職務分掌を実現バックアップを専用のプロジェクトに分離することで、責任を明確に割り当て、最小権限の原則を適用できます。アプリケーションチームに、中央のバックアップリポジトリを制御する権限を与えることなく、自分たちのプロジェクト内でアプリケーションをバックアップおよび復元するセルフサービス権限を付与することが可能です。中央のプラットフォームチームまたは運用チームにバックアッププロジェクトの管理制御を付与すれば、不変性を持つ保持ポリシーの設定から監査の実施まで、データライフサイクル全体を管理することができます。本番環境にアクセスする必要はありません。こうした分離は、リスクを軽減し、監査を簡素化するうえで重要です。Backup for GKE の IAM ロールと権限に関する詳細なガイダンスについては、ドキュメントをご覧ください。

GKE のプロジェクト間のバックアップと復元により、複数の Google Cloud プロジェクトにわたってコンテナ化されたワークロードを保護できます。この機能は、障害復旧機能の強化、セキュリティポスチャーの改善、運用ワークフローの効率化に役立ちます。

使ってみる

この機能をぜひお試しください。プロジェクトでこの機能を有効にするには、こちらのフォームにご記入ください。

プロジェクト間のバックアップを行う方法
プロジェクト間の復元を行う方法

-プロダクトマネージャー、Ranjith Kumar Palthi

aside_block: <ListValue: [StructValue([('title', 'Try Google Cloud for free'), ('body', <wagtail.rich_text.RichText object at 0x7f339ce355e0>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

ストレージと I/O 集約型ワークロード向けに 9 つの新しい VM と 1 つのベアメタルインスタンスで Z3 ファミリーを拡大

Wed, 23 Jul 2025 01:00:00 +0000

※この投稿は米国時間 2025 年 7 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

このたび、Z3 ストレージ最適化 VM ファミリーの拡大として、9 つの新しい Z3 仮想マシンの一般提供を開始しました。これらの VM は、VM あたり 3 TiB から 18 TiB のローカル SSD 容量を提供し、VM あたり 36 TiB のローカル SSD を提供する既存の Z3 VM を補完するものです。また、最大 72 TiB のローカル SSD を搭載した Z3 ベアメタルインスタンスもリリースしました。Z3 VM を使用すれば、Shopify、Tenderly、ScyllaDB などのお客様は、前世代のローカル SSD を使用する VM インスタンスと比較して IO アクセスレイテンシを最大 35% 削減し、高パフォーマンスストレージワークロードのパフォーマンスを大幅に向上させることができます。

Z3 VM は、SQL、NoSQL、ベクトルデータベース、データ分析、セマンティックデータ検索と取得、分散ファイルシステムなど、大容量のローカルストレージと高いストレージパフォーマンスを必要とする I/O 集約型ワークロードを実行できるよう構築されています。Z3 ベアメタルインスタンスは、物理サーバーの CPU に直接アクセスできるため、プライベートクラウドやハイブリッドクラウドプラットフォーム、カスタムハイパーバイザ、コンテナプラットフォーム、特殊なパフォーマンスやライセンス要件を持つアプリケーションなど、低レベルのシステムアクセスを必要とするワークロードに非常に適しています。

Z3 VM とベアメタルインスタンスはどちらも Titanium SSD をベースとしており、ローカルストレージの処理を CPU リソースからオフロードすることで、リアルタイムのデータ処理、低レイテンシ、スループットの高いストレージパフォーマンス、ストレージセキュリティの強化を実現します。Titanium SSD を搭載した Z3 VM は、最大 36 GiB/秒の読み取りスループットと最大 900 万 IOPS を実現し、前世代のローカル SSD と比較して書き込みストレージのパフォーマンスが最大 25% 向上しています¹。

aside_block: <ListValue: [StructValue([('title', '300 ドル分の無料クレジットで Google Cloud インフラストラクチャを試用'), ('body', <wagtail.rich_text.RichText object at 0x7f339d243cd0>), ('btn_text', '無料で構築を始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectPath=/compute'), ('image', None)])]>

第 4 世代 Intel Xeon スケーラブルプロセッサをベースとする Z3 VM は、11 種類の仮想マシン形状で、最大 176 個の vCPU、1,408 GiB のメモリ、36 TiB のローカルストレージを備えています。Z3 ベアメタルインスタンスは、192 個の vCPU、1,536 GiB のメモリ、72 TiB のローカルストレージを備えます。Z3 VM とベアメタルインスタンスは、標準帯域幅で最大 100 Gbps、高トラフィックアプリケーション向けの Tier1 ネットワーキングで最大 200 Gbps の帯域幅を提供し、エンタープライズワークロードに必要な接続性とストレージパフォーマンスを提供します。

Z3 仮想マシンポートフォリオが拡大されたことで、インフラストラクチャを適切にサイジングし、クラスタをスケーリングしてワークロードの要件を満たすことができるようになりました。これは、ローカル SSD の総容量の増加と、vCPU あたりのローカル SSD 容量の増加によって実現されます。Z3 には 2 種類の VM タイプがあります。standardlssd VM タイプには、vCPU あたり約 200 GiB のローカル SSD を提供する 5 つの VM シェイプが含まれています。それらは、データ分析（OLAP）や、MySQL や Postgres などの SQL データベースのワークロード向けに最適化されています。highlssd VM タイプ には、 6 種類の VM シェイプと Z3 ベアメタルインスタンスが含まれます。それらは vCPU あたり約 400 GiB のローカル SSD を提供するもので、分散データベース、データストリーミング、大規模な並列ファイルシステム、データ検索に最適化されています。

お客様とパートナー様の声

「Nutanix は、柔軟なハイブリッドクラウドソリューションを提供するという取り組みの一環として、2025 年末に Nutanix Cloud Clusters を Google Cloud で提供することをここに発表でき、嬉しく思います。Google Cloud の Z3 インスタンスタイプは、Nutanix がエンタープライズアプリケーションのパフォーマンスと復元力を高めるうえで最適な基盤です。Google Cloud とのパートナーシップにより、共通のお客様の選択肢が広がり、クラウドへの移行がよりシンプルになることを期待しています。」- Nutanix、プロダクト管理担当バイスプレジデント、Saveen Pakala 氏

「OP Labs は、イーサリアムのパフォーマンスとスケーラビリティを大幅に向上させる Optimism プロトコルに貢献しています。Z3 は、最も I/O 需要の高いブロックチェーンノードで、N2 と比較して p99 ブロック挿入テールレイテンシを 30 ～ 50% 削減しています。ソリューションを Z3 に移行することで、L2 状態の増加をよりパフォーマンスが高く費用対効果の高い方法で処理できるよう、ブロックチェーンノードをスケーリングできると考えています。」- OP Labs、シニアスタッフエンジニア Zach Howard 氏

「Google Cloud の Z3 ストレージ最適化インスタンスの小型 VM シェイプのリリースは、トラフィックの多い NoSQL 環境のパフォーマンスを飛躍的に向上させます。社内テストとお客様のプロジェクトにおいて、ScyllaDB は Z3 の次のようなメリットを効果的に活用しています。読み取りと書き込みの負荷が高い状況でもレイテンシが非常に低いこと、大量のデータを処理できる高い IOPS 容量を備えていること、大規模な本番環境システムにおいて優れた費用対効果を実現できることなどです。ScyllaDB Cloud で Z3 ファミリーサーバーを提供できることを嬉しく思います。お客様所有アカウント（BYOA）もご利用いただけます。」- ScyllaDB、共同創業者 / CTO、Avi Kivity 氏

「Shopify は、Z3 がパフォーマンスに最も敏感なストレージシステムを構築するうえで最適なプラットフォームであると考えています。ストレージ側でレイテンシとスループットに配慮しながら、大量のデータを処理する必要性が非常に高まっていました。Google には多くの選択肢がありますが、ローカル SSD が最適でした。Z3 を使用することで、真実のソースのストレージワークロードに適した安定性の向上と、最適な費用対効果を実現できました。現時点では、ストレージ最適化 VM が将来のプラットフォームとして最適であると考えています。」- Shopify、インフラストラクチャ担当バイスプレジデント、Mattie Toia 氏

「Tenderly は、Web3 の本番環境と開発に欠かせないツールとして構築されており、必要なインフラストラクチャがすべて 1 か所に集約されています。そのためチームは迅速かつ確実に運用でき、ブロックチェーン技術を簡単に利用することができます。Z3 インスタンスでブロックチェーンワークロードを実行したところ、N2 および N2D インスタンスと比較して読み取りレイテンシが 40% 向上するという素晴らしい結果が得られました。」- Tenderly、SRE リード、Ilija Petrovic 氏

「VAST AI オペレーティングシステムは、組織に統合プラットフォームを提供し、クラウド環境とオンプレミス環境にまたがるグローバル名前空間を通じて、構造化データ、非構造化データ、ストリーミングデータなど、すべてのデータを推論できるようにします。これにより、インテリジェントエージェントとアプリケーションは、完全なコンテキストとリアルタイムの速度で動作できます。Google Cloud で実行しているお客様にとって、Z3 VM は、これらのワークロードを加速するための理想的なストレージインフラストラクチャを提供することで、このビジョンを補完してくれます。これにより、AI パイプラインがクラウドで高速に実行され、簡単にスケーリングできるようになります。」 - VAST Data、創業者兼 CEO、Renen Hallak 氏

Z3 VM は、Google の主力 PostgreSQL 互換データベースサービスである AlloyDB の物理基盤でもあり、高度なマルチレベルキャッシュを提供します。AlloyDB は、Z3 の広大なローカル SSD を超高速キャッシュとして使用し、メモリに保存できるデータの最大 25 倍のデータセットを保持します。データベースクエリは、これらのキャッシュされた大規模なデータセットに、特にアプリケーションのエンドツーエンドの全体的な応答時間を考慮すると、インメモリパフォーマンスにほぼ近いレイテンシでアクセスできます。AlloyDB の高性能な列指向エンジンはこの巨大なキャッシュ内で完全に動作するため、リアルタイム分析ワークロードを含む非常に大規模なデータベースにとって大きなメリットとなります。Z3 VM 上の AlloyDB は、まもなくプレビュー版が提供される予定です。トランザクションワークロード、特に大規模なデータセットの場合、N シリーズ VM と比べて最大 3 倍のパフォーマンスを実現するものです。

メンテナンスの利便性の向上

Z3 インスタンスでは、必要なメンテナンスの数日前にシステムから通知が届くため、事前に計画を立てて、任意のタイミングでメンテナンス作業をスケジュールすることができます。新しい Z3 VM では、ローカル SSD ストレージが 18 TiB 以下の VM のメンテナンスイベント中にインスタンスをライブマイグレーションできるため、メンテナンス体験の質がさらに向上します。36 TiB のローカル SSD を備えた Z3 VM と Z3 ベアメタルインスタンスでは、計画的なメンテナンスイベント中にデータを保持するインプレースアップグレードも利用できます。

Hyperdisk のサポート

Z3 VM は、Google Cloud のワークロード最適化ブロックストレージである Hyperdisk をサポートしています。Hyperdisk では、インスタンスごとにストレージのパフォーマンスと容量を個別に調整できるため、ワークロードごとにパフォーマンスを最適化できます。

Z3 VM は、スケーラブルで高パフォーマンスのネットワーク接続ストレージである Hyperdisk Balanced、Hyperdisk Throughput、Extreme Hyperdisk ストレージに対応しており、インスタンスあたり最大 512 TiB の容量をサポートしています。汎用ワークロードの場合、インスタンスあたり最大 160,000 IOPS の Hyperdisk Balanced は、パフォーマンスと費用対効果のバランスが取れています。Hyperdisk Extreme は超低レイテンシを実現し、Z3 VM インスタンスあたり最大 35 万 IOPS と 5,000 MiB/秒のスループット、Z3 ベアメタルインスタンスあたり最大 50 万 IOPS と 10,000 MiB/秒のスループットをサポートしています。そのため、データベースなどの要求の厳しいワークロードに最適です。永続ストレージに Hyperdisk を使用し、キャッシュに Z3 ローカル SSD を使用することで、ハイエンドデータベースとミッションクリティカルなワークロードに最適なストレージアーキテクチャが実現

Z3 を今すぐ利用開始

Z3 VM とベアメタルインスタンスは、現在、世界中の大半のリージョンでご利用いただけます。Z3 インスタンスの使用を開始するには、Google Cloud コンソールで新しい VM または GKE ノードプールを作成するときに、新しいストレージ最適化マシンファミリーに属する Z3 を選択します。詳しくは、Z3 マシンシリーズのページをご確認ください。ご利用いただけるリージョンについて詳しくは、Google Cloud の営業担当者までお問い合わせください。

^{1. 結果は Google Cloud の内部ベンチマークに基づく}

ーグループプロダクトマネージャー、Garv Sawhney

ー プリンシパルプロダクトマネージャー、Bob Napaa

Google Cloud Managed Lustre で AI ワークロードを加速

Fri, 11 Jul 2025 02:00:00 +0000

※この投稿は米国時間 2025 年 7 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

このたび、AI / ML ワークロードで画期的なパフォーマンスをより簡単に実現できるようになりました。Google Cloud Managed Lustre が一般提供され、4 つの異なるパフォーマンスティアで利用できるようになりました。各ティアでは容量 1 TiB あたり 125 MB/秒、250 MB/秒、500 MB/秒、1,000 MB/秒のスループットが提供され、ストレージ容量は最大 8 PB にスケールアップできます。Managed Lustre ソリューションは DDN の EXAScaler を活用しており、DDN が数十年にわたって培ってきた高パフォーマンスストレージ界をリードする技術と、Google Cloud のクラウドインフラストラクチャに関する専門知識を組み合わせています。

Managed Lustre は、高スループットと低レイテンシを実現する POSIX 準拠の並列ファイルシステムです。こうした特性は以下の用途に不可欠です。

高スループットの推論: 大規模なデータセットで準リアルタイムの推論を必要とするアプリケーションの場合、Lustre は高い並列スループットとミリ秒未満の読み取りレイテンシを実現します。
大規模なモデルのトレーニング: ペタバイト規模のデータセットに迅速にアクセスできるようにすることで、ディープラーニングモデルのトレーニングサイクルを加速します。Lustre の並列アーキテクチャにより、GPU と TPU にデータが十分に供給され、アイドル時間が最小限に抑えられます。
大規模モデルのチェックポイント設定と再開: トレーニング中に大規模モデルの状態をより迅速に保存および復元し、グッドプットを向上させて、より効率的なテストを可能にします。
データの前処理と特徴量エンジニアリング: 元データを処理し、特徴を抽出して、トレーニング用データセットの準備作業を行うことで、データパイプラインに費やす時間を短縮します。
科学シミュレーションと研究: AI / ML 以外にも、Lustre は、膨大なデータセットと高並行アクセスが重要な、計算流体力学、ゲノム配列決定、気候モデリングなど従来からある HPC の用途で優れた性能を発揮します。

Lustre は、多くの AI / ML トレーニングおよび推論タスクに特有の、高度に並列化されたランダム I/O に対応するように設計されています。複数クライアント間の並列処理機能により、コンピューティングリソースがデータ不足になることはありません。

パフォーマンスティアと料金

Managed Lustre は、容量を重視する場合でも、最高のスループット密度を重視する場合でも、ワークロードの多様なニーズを満たすように設計された柔軟な料金とパフォーマンスのティアを提供します。

スループット（MB/秒、ストレージ容量 1 TiB あたり）	ストレージ料金（GiB/月）
125	$0.145
250	$0.21
500	$0.34
1,000	$0.60

詳しくは、Managed Lustre の料金ページをご覧ください。

総スループットに関係なく、すべてのティアでミリ秒未満の読み取りレイテンシと高い単一ストリームスループットが実現され、多数の小さなファイルへの並列アクセスに最適です。

共同でイノベーションを推進: DDN とのパートナーシップ

Google Cloud の Managed Lustre は DDN の EXAScaler を活用しており、高性能コンピューティングと弾力性に優れたクラウドインフラストラクチャの業界リーダー 2 社の提携のもとに生まれました。このパートナーシップは、クラウドでの大規模な AI および HPC ワークロードのデプロイと管理を簡素化するという共通の取り組みの現れであり、以下の要素によって実現されたものです。

信頼できるリーダー: DDN の数十年にわたる高性能な Lustre に関する専門知識と、Google Cloud のグローバルインフラストラクチャおよび AI エコシステムを組み合わせることで、ストレージのボトルネックを解消し、お客様が AI と HPC における最も複雑な課題を解決するのに役立つ基盤機能を提供しています。
フルマネージドのサポート対象ソリューション: Google のフルマネージドサービスのメリットを享受できます。Google と DDN の両方から包括的なサポートを受けられるため、シームレスな運用と安心感が得られます。
グローバルな可用性とエコシステム統合: Managed Lustre は、複数の Google Cloud リージョンでグローバルにアクセス可能になり、Google Kubernetes Engine（GKE）や TPU を含む、より広範な Google Cloud エコシステムと統合されます。

これらのメリットは、Google の最大規模のパートナーである NVIDIA の関心を引き、NVIDIA はこれを NVIDIA AI プラットフォームの一部として組み込むことを楽しみにしています。

「今日の企業は、妥協のないスピード、シームレスなスケーラビリティ、大規模での高い費用対効果を実現するために、高速コンピューティングと高性能ストレージソリューションを組み合わせた AI インフラストラクチャを求めています。Google と DDN が Google Cloud Managed Lustre で提携することで、これらのニーズを満たすのに最適なソリューションが実現します。DDN のエンタープライズグレードのデータプラットフォームと Google のグローバルクラウド機能を統合することで、さまざまな組織が大量のデータに簡単にアクセスし、Google Cloud 上の NVIDIA AI プラットフォーム（または NVIDIA アクセラレーテッドコンピューティングプラットフォーム）で AI の可能性を最大限に引き出すことができます。これにより、インサイトを得るまでの時間を短縮し、GPU の使用率を最大化して、総所有コストを削減できます。」 - NVIDIA アクセラレーテッドコンピューティングプロダクト担当ディレクター、Dave Salvator 氏

今すぐ使用を開始する

AI / ML と HPC のワークロードを強化しませんか？Managed Lustre の使用を開始するのは簡単です。

Google Cloud コンソールで Managed Lustre に移動します。
ニーズに最適なパフォーマンスティアとサイズを選択して、Managed Lustre インスタンスをプロビジョニングします。
コンピューティングインスタンスと GKE クラスタを新しい高パフォーマンスファイルシステムに接続します。

詳しい手順とドキュメントについては、Managed Lustre のドキュメントをご覧ください。必要に応じて、Google Cloud セールススペシャリストにお問い合わせください。

対談を見る

Google Cloud と DDN の戦略的パートナーシップ、および Managed Lustre の独自の機能について詳しく知る機会をお見逃しなく。DDN の公式プレスリリースはこちらでご覧いただけます。

ストレージ担当 VP 兼 GM の Sameet Agarwal と DDN の CTO である Sven Oehme 氏の対談は、こちらからご覧いただけます。

-プロダクト管理担当シニアディレクター、Asad Khan

-グループプロダクトマネージャー、Kirill Tropin

Eon と Google Cloud のバックアップを使用して自動化された大規模なデータレジリエンスを実現

Tue, 08 Jul 2025 02:00:00 +0000

※この投稿は米国時間 2025 年 6 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

かつて、クラウドのバックアップは保険のようなものと考えられていました。しかし今では、バックアップの役割はデータの復元だけにとどまりません。デフォルトで自律性があり、コスト効率に優れ、分析に対応している必要があります。

そこで、Eon は Google Cloud と連携するプラットフォームを構築し、チームがポリシーの専門家やインフラストラクチャの管理者にならずとも、バックアップの盲点をなくし、復元を簡素化し、バックアップデータの価値を引き出せるようにしました。

とはいえ、どのプラットフォームを使用していても、復元力のあるクラウドバックアップとはどのようなものかを理解し、Google Cloud のネイティブ機能を使用してそれを実現する方法を知ることは重要です。

クラウドバックアップの復元力を高める要素とは？

ツールの詳細に入る前に、クラウドにおける復元力のあるバックアップ戦略とはどのようなものかを考えてみましょう。私たちは、さまざまな業界の Google Cloud ユーザーとの協業の中で、共通する 5 つの基準を発見しました。

バックアップポスチャーが適切ではない可能性を示す 5 つの兆候

何がバックアップされているか（またはバックアップされていないか）を簡単に確認できない
保持ポリシーがプロジェクトやチームによって異なる
データが重複していたり、非効率的に保存されていたりするため、費用が増大している
クラウドランサムウェア対策がポリシードリブンではなく、事後対応型である
復元する場合、必要なオブジェクトが 1 つだけの場合でも、完全な復元が必要である

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7f339cfb6460>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

データ保護のベストプラクティス

Google Cloud は、一貫性を持って設定し使用することで、データを保護するための基本的な機能を提供します。ネイティブの保護機能を最大限に活用する方法は次のとおりです。

1. バージョニングと保持: 最初の防御策

Cloud Storage でオブジェクトのバージョニングを有効にすると、複数のオブジェクトバージョンが保持されるため、オブジェクトを誤って削除した場合でも簡単に復元できます。これを保持ポリシーと組み合わせることで、規制対象のデータセットや重要なデータセットに対して最小保存期間を適用できます。

ヒント: コンプライアンスが最も重要な分野では、バケットロックを使用して WORM（1 回限りの書き込みと複数回の読み取り）保護を行います。

2. 対応範囲のギャップのモニタリング

Cloud SQL バックアップ、GKE スナップショット、Persistent Disk イメージなどのネイティブサービスを使用します。ただし、バックアップの責任が複数のチームに分かれる可能性があることに注意してください。一元的な可視性がないと、バックアップの対応範囲に整合性がなくなります。

ヒント: Cloud Asset Inventory またはスケジュールされた BigQuery クエリを使用して、対応範囲を監査します。

3. きめ細かな復元の設計

完全なロールバックは必要がない場合もあるため、部分的な復元を計画します。単一の BigQuery テーブルでも、特定の Cloud Storage オブジェクトでも、必要なものだけを復元することで、時間とコストを節約できます。

ヒント: オブジェクトのライフサイクル管理を使用すると、Cloud Storage オブジェクトのうち古いものや重要度の低いものを、アクセス頻度の低い（コールドな）ストレージクラスに自動的に移動できます。

Eon の CTO で共同創業者でもある Ron Kimchi 氏へのインタビュー「新しい方法：Eon がクラウドバックアップを AI 対応データレイクに変換」をご覧ください。

自動化で複雑さを解消

大規模なクラウドバックアップの管理を手動で行うのは困難です。新しいワークロードのオンボーディングから一貫したポリシーの適用まで、人間主導のアプローチでは効果的にスケールすることができません。

そのため、Eon のような自律性のある Cloud Backup Posture Management（CBPM）ソリューションを検討するチームが増えています。このソリューションは、新しいアセットをリアルタイムで検出し、スマートなバックアップルールを自動的に適用し、全環境にわたって一貫した保護を適用します。

Eon を使用すれば、リソースにタグを付ける必要も、カスタムスクリプトを作成する必要もありません。GKE、Cloud SQL、BigQuery など使用しているソリューションを問わず、Eon のプラットフォームなら Google Cloud のアセットをすぐに分類して保護します。

バックアップからビジネス分析情報まで

従来、バックアップデータはサイロ化され、十分に活用されず、緊急時にのみ取り出されるものでした。今は、そのデータを次のように活用することが増えています。

BigQuery と Dataproc を使用してバックアップを直接分析する
Vertex AI を介してトレーニングパイプラインとモニタリングパイプラインにフィードする
Looker でバックアップスナップショットを活用して、監査対応のダッシュボードを提供する

Eon には、これらの機能が組み込まれています。バックアップをゼロ ETL のデータレイクに変換することで、パイプラインのコストを削減し、再処理を行わずに即座に構造化データにアクセスできるようにします。

「成熟した」バックアップポスチャーとは

多くのクラウドネイティブチームにとって、最終目標は単に「バックアップを持つこと」ではなく、規模とリスクに適応する、復元力のあるインテリジェントなバックアップ戦略を策定することです。

その具体的な内容は以下のとおりです。

新しいリソースの自動検出
データの種類と重要度に合わせたポリシードリブンな保護
保持期限が固定された変更不可のバックアップ
完全なスナップショット復元ではなく、検索優先の復元
コストを意識した階層化とストレージの重複除去

Google Cloud ユーザーが Eon を使用すると、カスタムツールの使用やポリシーの継続的な更新という負担なしに、より迅速にこの成熟度レベルに到達できます。

バックアップを簡素化する準備はできましたか？

お客様のチームがクラウド環境全体にわたってスクリプト、ストレージ階層、バックアップタグの管理に何時間も費やしているなら、アプローチを見直す時期かもしれません。

Eon は、クラウドバックアップを、復元力と自律性を備え、実際に役立つものにするために構築されました。ランサムウェア対策から、オブジェクトレベルでの即時の復元、そして今ではゼロ ETL による分析へのアクセスまで、バックアップデータの可能性を最大限に引き出すお手伝いをします。

デモを予約して、Eon が Google Cloud データの保護戦略をモダナイズする方法をご確認ください。

Google Cloud がスタートアップをどのようにサポートできるかについては、プログラムページをご覧ください。また、ニュースレターに登録して、コミュニティ活動、デジタルイベント、スペシャルオファーなどの最新情報を入手することもできます。

-Eon、ソリューションアーキテクト、Liore Shai 氏

ストレージとデータ転送

C4N の一般提供を開始: クラウドで最高レベルの vCPU あたりのネットワークとブロック ストレージの I/O を x86 ワークロードで実現

新機能: C4N で大規模なデータレイヤをスケール

次世代のネットワーク パフォーマンス

Hyperdisk による動的なストレージ パフォーマンス

お客様の声

C4N のシェイプと仕様の詳細

ご利用方法

Backup and DR サービスのクロスリージョン バックアップでデータ レジリエンスを強化

クロスリージョン バックアップのメリット

仕組みの概要

リソース

Storage Insights データセット: アクティビティ インサイトで組織全体のオペレーションを把握

Storage Insights データセットとは

静的なメタデータからライブ インテリジェンスへ進化

アクティビティ インサイトを直ちに活用する 3 つの方法

ご利用にあたって

Cloud Storage Rapid: AI と分析のための超高速化されたオブジェクト ストレージ

Rapid Bucket

Rapid Cache

ビジネスを加速させる最適なプロダクトをお選びください

Next ‘26 で発表した AI ワークロードを加速するストレージ イノベーション

Smart Storage: AI 時代のコンテキスト

Storage Intelligence: AI に対応したデータ マネジメント

ストレージ エコシステムの強化

導入の第一歩

エージェント型エンタープライズのためのクロスクラウド インフラストラクチャのイノベーション

Fluid Compute

安全なクロスクラウド接続

統合データレイヤ

デジタル主権

新しい GKE Cloud Storage FUSE プロファイルにより、AI ストレージの構成における当て推量が不要に

Cloud Storage FUSE の最適化に伴う課題

GKE 向け Cloud Storage FUSE プロファイルの概要

GKE で Cloud Storage FUSE プロファイルを使用する方法

使ってみる

NVIDIA Run:ai Model Streamer を使用して GKE 上のモデルのダウンロードを高速化

コールド スタートを減らしてレジリエンスとスケーラビリティを向上

パフォーマンスとシンプルさ

NVIDIA Run:ai Model Streamer と Cloud Storage Anywhere Cache の組み合わせ

今すぐ使ってみる

Managed Lustre の外部 KV キャッシュで AI 推論を迅速化

KV キャッシュについて

Google Cloud Managed Lustre 上の外部 KV キャッシュ

総所有コスト: 分析

パフォーマンスのベンチマーク

推論ワークロードを最適化するには

ブロック ストレージとファイル ストレージを統合して、クラウドでの貴社のエンタープライズ アプリケーションを強化

最も要求の厳しい SAN ワークロードを Google Cloud で実行

NetApp FlexCache でハイブリッド クラウドを加速

エンタープライズ データを Gemini Enterprise に取り込む

クラウド環境のその他の強化

始める

ダークデータを有用なインサイトへ: スマート ストレージの幕開け

AI を活用してダークデータを変革

データをスマート化する

1. データの検出

2. AI のためのデータ キュレーション

3. 非構造化データを大規模に管理

明るいデータの未来

Google におけるメディアのサニタイズの未来

よりスマートなアプローチ: 暗号化消去

イノベーションによるセキュリティの強化

サステナビリティと循環経済

今後の取り組み

Google Cloud のコンピューティング費用を今すぐ削減する 11 の方法

1. 適切な VM インスタンスを選択する

2. ブロック ストレージの選択を最適化する

3. カスタム コンピューティング クラスを検討する

4. カスタム マシンタイプ（CMT）を活用する

5. 確約利用割引を最大限に活用する

6. 未使用のディスク容量を管理する

7. Spot VM を使用する

8. 最適化案を適用する

9. 自動スケーリングとスケジューリングを活用する

10. 詳細な請求金額の分析で費用を把握する

11. サーバーレスの代替手段を検討する

今すぐ費用削減を始めましょう

Google Kubernetes Engine で Managed Lustre を使用するときのベスト プラクティス 5 つ

1. データのロケーションを考慮した設計

C4N の一般提供を開始: クラウドで最高レベルの vCPU あたりのネットワークとブロックストレージの I/O を x86 ワークロードで実現

次世代のネットワークパフォーマンス

Hyperdisk による動的なストレージパフォーマンス

Backup and DR サービスのクロスリージョンバックアップでデータレジリエンスを強化

クロスリージョンバックアップのメリット

Storage Insights データセット: アクティビティインサイトで組織全体のオペレーションを把握

静的なメタデータからライブインテリジェンスへ進化

アクティビティインサイトを直ちに活用する 3 つの方法

Cloud Storage Rapid: AI と分析のための超高速化されたオブジェクトストレージ

Next ‘26 で発表した AI ワークロードを加速するストレージイノベーション

Storage Intelligence: AI に対応したデータマネジメント

ストレージエコシステムの強化

エージェント型エンタープライズのためのクロスクラウドインフラストラクチャのイノベーション

コールドスタートを減らしてレジリエンスとスケーラビリティを向上

ブロックストレージとファイルストレージを統合して、クラウドでの貴社のエンタープライズアプリケーションを強化

NetApp FlexCache でハイブリッドクラウドを加速

エンタープライズデータを Gemini Enterprise に取り込む

ダークデータを有用なインサイトへ: スマートストレージの幕開け

2. AI のためのデータキュレーション

2. ブロックストレージの選択を最適化する

3. カスタムコンピューティングクラスを検討する

4. カスタムマシンタイプ（CMT）を活用する

Google Kubernetes Engine で Managed Lustre を使用するときのベストプラクティス 5 つ

ストレージと I/O 集約型ワークロード向けに 9 つの新しい VM と 1 つのベアメタルインスタンスで Z3 ファミリーを拡大

Eon と Google Cloud のバックアップを使用して自動化された大規模なデータレジリエンスを実現

Eon の CTO で共同創業者でもある Ron Kimchi 氏へのインタビュー「新しい方法：Eon がクラウドバックアップを AI 対応データレイクに変換」をご覧ください。