ストレージとデータ転送

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 0x7f7aafcadbe0>)])]>

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 0x7f7aafcad940>)])]>

これで完了です。残りの処理はストリーマーが行い、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 0x7f7ab09209d0>), ('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 0x7f7ab14b1be0>), ('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 0x7f7ab14b16a0>)])]>

ベストプラクティスである理由: 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 0x7f7ab1441700>), ('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 0x7f7ab24fce50>)])]>

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

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 0x7f7ab24fc490>)])]>

ライフサイクルポリシーと 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 0x7f7ab24fc700>)])]>

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 0x7f7ab24fca90>)])]>

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

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 0x7f7ab24fc9d0>)])]>

クリーンアップする一時オブジェクトを見つける: 多くのアプリケーションは一時ファイルを生成します。一時ファイルは、削除しないと、時間が経つにつれて蓄積されます。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 0x7f7ab24fc5b0>)])]>

特定の日付より古いすべてのオブジェクトを一覧表示して、簡単にアクションを実行する: コンプライアンスのために、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 0x7f7ab11d5790>), ('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 0x7f7ab11d5850>)])]>

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 0x7f7ab11d5d60>)])]>

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 0x7f7ab11d5df0>)])]>

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 0x7f7ab11f1640>), ('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 0x7f7ab0dec040>), ('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 0x7f7ab092f7f0>), ('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 氏

Persistent Disk、Hyperdisk、マルチリージョンへの対応により Backup Vault を強化

Wed, 02 Jul 2025 02:00:00 +0000

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

ランサムウェアや悪意のある削除といった進化し続けるデジタル脅威からの保護策として、昨年、Google Cloud の Backup and DR サービスに Backup Vault が導入され、Compute Engine VM のバックアップがサポートされるようになりました。これにより、VM メタデータとアタッチされたすべてのディスクの両方を含むミッションクリティカルな VM に対し、変更不可かつ消去不可のバックアップ機能を利用できるようになりました。

今回ご紹介するのは、より多くの種類のワークロードを保護するための Backup Vault の 2 つの機能強化です。

スタンドアロンの Persistent Disk（PD）と Hyperdisk のバックアップに対応: 現在プレビュー版で提供されているこの機能を活用すると、仮想マシン全体ではなく個々のディスク上のデータを直接バックアップできるため、きめ細かなバックアップが可能になります。
をマルチリージョンロケーションでの作成に対応: この機能は現在一般提供されており、リージョン単位のデータ復元力をサポートし、ビジネス継続性の要件を満たすのに役立ちます。

不変性と消去不能性

従来のバックアップにはよく知られた脆弱性があります。悪意のある行為者が企業の環境にアクセスしてバックアップを削除または破損しようと試みた場合、復元が妨げられ、ビジネス上の損失が発生する可能性があり、これを防ぐ手段はありません。こうした状況を根本的に変えるのが Backup Vault です。

Backup Vault は、Google が管理するプロジェクトで安全かつ隔離されたストレージ環境を提供するため、バックアップの不変性（データ変更に対する保護）と消去不能性（データ削除に対する保護）が確保され、ランサムウェアなどのサイバー攻撃から保護できます。Backup Vault の作成時に、Vault に保存されているバックアップを変更や削除から保護するよう指定できるため、通常ならばバックアップを期限切れにできるバックアップ管理者に対しても、指定された最短の強制保持期間が経過するまでは変更や削除を不可にできます。

バックアップは、Vault に保存されると、Google Cloud プロジェクトとの間に論理的なエアギャップが生まれ、ユーザーが指定した強制保持期間中は変更できません。具体的には、次のようになります。

消去不可: 強制保持期間が経過するまで、バックアップを誤ってまたは意図的に削除することはできません。
変更不可: バックアップデータは変更できず、作成時の状態が維持されます。

これにより、重要な復元ポイントが変更されることなく、必要なときに利用できる状態となっているという確信を得られます。

Backup Vault が Persistent Disk と Hyperdisk に対応

多くのアプリケーションは、Persistent Disk と Hyperdisk が提供する耐久性の高いストレージに依存しています。Compute Engine VM に加え、Persistent Disk と Hyperdisk のサポートも追加された Backup Vault なら、コンピューティング環境全体の包括的な防御戦略を立てることができます。

VM の場合: Backup Vault を使用して、Compute Engine VM（VM メタデータとすべてのアタッチされたディスクを含む）を保護できます。オペレーティングシステム、構成、アプリケーションバイナリ、関連するすべてのディスクを迅速かつ安全に復元できます。
重要なデータディスクの場合: アプリケーションデータ、データベース、ファイル共有を含む特定の Persistent Disk と Hyperdisk を保護できるようになりました。VM 全体のバックアップが不要な場合や、費用を最適化したい場合に、保護の対象をきめ細かく制御できます。

この統合アプローチにより、復元する必要があるのが VM 全体か特定のディスクであるかにかかわらず、復元ポイントが確実に Backup Vault で保護されます。

Backup Vault による統合された保護の主なメリット

Compute Engine VM、Persistent Disk、Hyperdisk のバックアップを Backup Vault 内に統合することで、データ保護戦略を事後対応型から、以下のような事前に復元力を強化する戦略に転換できるという大きなメリットが得られます。

管理しやすい統合インターフェース: 組織全体で一貫したバックアップポリシー（バックアップの頻度と保持期間を含む）を簡単に定義して適用できます。複数の Google Cloud プロジェクトにまたがっても、Compute Engine VM、Persistent Disk、Hyperdisk のバックアップを一つの統合インターフェースで簡単にまとめて管理できます。
包括的なモニタリングとレポート: 一元化されたモニタリング、詳細レポート、タイムリーなアラート機能により、日々のバックアップ管理を効率化できます。こうした可視性の向上により、バックアップ対策の明確かつ検証可能な記録を提供できるため、厳格な監査とコンプライアンスの要件を満たすうえでも大いに役立ちます。
事前対応型のセキュリティインテグレーション: Security Command Center とのインテグレーションにより、セキュリティポスチャー全体が強化され、不正なバックアップ削除の試みや不審なポリシー変更などの異常なアクティビティを事前に検出することができるため、脅威に対する迅速かつ断固とした対応が可能になります。
運用の複雑さの軽減: バックアップ管理プロセスを統合することで、ばらばらのソリューションやスクリプトベース、あるいは手動のソリューションから脱却できます。Backup and DR サービスは、運用を簡素化し、人的ミスを減らし、貴重な IT リソースを解放する合理化されたフルマネージドサービスを提供するため、ユーザーはイノベーションに集中できます。

バックアップの手順

Backup Vault を作成する: まず、安全な Backup Vault を構築します。この Vault は、すべての管理されたバックアップのための専用の隔離された安全なストレージとして機能します。
バックアッププランを定義する: 次に、包括的なバックアッププランを作成し、希望のバックアップ頻度（ディスクのバックアップ間隔）、バックアップの保持期間などのパラメータを設定し、バックアップデータの保存先となる Backup Vault を指定します。
バックアップスケジュールを設定する: これで、バックアッププランを、希望する Persistent Disk または Hyperdisk に適用する準備が整いました。Backup and DR サービスでは、ユーザーが定義したスケジュールに基づいて、クラッシュ整合性のある増分バックアップが自動的に取得されます。このとき、ユーザーによる手動操作は不要です。

これらのバックアップが作成され、指定された Vault に保存されると、Vault の強制保持期間ポリシーが自動的に適用され、指定された強制保持期間中はバックアップが変更不可および消去不可になります。

マルチリージョン Backup Vault による安全な障害復旧

さらに、Google が管理するマルチリージョンロケーションにも Backup Vault を作成できるようになりました。マルチリージョン Backup Vault を使用すると、データが複数の地理的リージョンに保存されるため、Backup Vault のセキュリティ上のメリットが得られると同時に、予期せぬ事態が発生した場合でも重要なバックアップデータを利用できるようになります。

マルチリージョン Backup Vault は、以下を可能にします。

データアクセスを維持する: 地域的なサービス停止（自然災害、停電など）が発生しても、重要なバックアップデータへのアクセスと復元性を常に確保できます。
ビジネス継続性の要件を満たす: バックアップベースの復元をオンデマンドで実施できるため、ビジネスオペレーションに対する信頼性を高められます。
データを保護する: Backup Vault が提供する、重要なセキュリティ上のメリットすべてを常に利用できます。

マルチリージョン Backup Vault ストレージは現在一般提供されており、サポートされているロケーションへの Compute Engine の VM 全体のバックアップとディスクのバックアップに対応しています。この新機能へのアクセスをリクエストするには、こちらのフォームにご記入ください。

重要な Compute Engine データをすべて保護

マルチリージョン Backup Vault とディスク単位でのバックアップ機能が追加されたことで、Backup and DR サービスによる重要な Compute Engine データの保護と復元がこれまでになく強化されました。これらの新しい機能をぜひお試しになり、VM のデータ保護戦略の最適化にお役立てください。

ディスクバックアップについて詳しくは、こちらをご覧ください。
マルチリージョン Backup Vault の詳細については、まずこちらをご覧ください。
マルチリージョン Backup Vault の使用をリクエストするには、こちらのフォームにご記入ください。
これらの新しい機能の料金に関する情報は、こちらでご確認ください。

ー Google Cloud プロダクトマネージャー、Jaswant Chajed

ー Google Cloud プロダクトマネージャー、Jerome McFarland

ワークロードに適した Hyperdisk ブロックストレージの選び方

Fri, 27 Jun 2025 01:02:00 +0000

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

Google Cloud の導入や最新の Compute Engine VM、Google Kubernetes Engine（GKE）への移行の際には、ワークロードに最適なブロックストレージの選択が重要です。Hyperdisk は Google Cloud の最新 VM ファミリー（C4、N4、M4 など）向けに設計されており、ワークロードに最適化されたブロックストレージです。高パフォーマンスかつコスト効率に優れ、大規模運用時の管理も容易な、エンタープライズ対応のストレージボリュームを提供します。この投稿では、Hyperdisk の基本知識と、環境に適した選び方をご提案します。

Hyperdisk ブロックストレージの概要

Hyperdisk を使用すると、容量とパフォーマンスを個別に調整して、ブロックストレージのリソースをワークロードに最適化できます。Hyperdisk にはいくつかの種類があります。

Hyperdisk Balanced: ほとんどのワークロードに適合するよう設計されており、価格とパフォーマンスの最適な組み合わせとバランスを実現します。これは、コンピューティングインスタンスのブートディスクとしても使用できます。Hyperdisk Balanced を使用すると、各ボリュームの容量、スループット、IOPS を個別に構成でき、高可用性モードとマルチライターモードで利用可能です。
Hyperdisk Extreme: Hyperdisk のサービスの中で最も高い IOPS を提供するため、パフォーマンスを重視するハイエンドなデータベースに最適です。Hyperdisk Extreme を使用すると、単一ボリュームで最大 35 万 IOPS を発揮できます。
Hyperdisk Throughput: ディスクのセマンティクスを持ちながら、コールドオブジェクトストレージ並みの低コストで容量を提供します。Hyperdisk Throughput は、低レイテンシを必要としない、帯域幅と容量を大量に消費するワークロードに対して、高スループットを実現します。また、コスト重視のワークロード（コールドディスクなど）向けに費用対効果の高いディスクとしても利用できます。
Hyperdisk ML: 静的データをコンピューティングクラスタに読み込むことに特化して設計されています。Hyperdisk ML では、モデルの重みやバイナリなどの固定データセットをディスクにハイドレートし、最大 2,500 のコンピューティングインスタンスを同じボリュームに接続できます。これにより、読み取り専用モードでは、競合するブロックストレージと比べて、単一ボリュームで対応できるインスタンス数が 150 倍以上になります1。すべてのノードで非常に高い総スループットを発揮するため、推論の起動を高速化し、モデルのトレーニングを迅速に進め、貴重なコンピューティングリソースを最大限に利用できます。

また、Hyperdisk ストレージプールを活用することで、容量とパフォーマンスの合計量を事前プロビジョニングできます。プール内のボリュームが動的にリソースを消費するため、TCO を削減し運用を簡素化できます。ワークロードに必要な合計容量とパフォーマンスを考慮してストレージプールを作成し、そのストレージプール内にディスクを作成します。その後、ディスクを VM にアタッチできます。ディスクの作成時には、必要以上に大きなサイズや、余裕を持たせたパフォーマンス上限でプロビジョニングすることも可能です。これにより、計画が簡素化され、ディスクのプロビジョニングされたサイズやパフォーマンスを変更することなく、将来的な拡張にも対応できます。

また、高可用性、クロスリージョンレプリケーションと復元、バックアップ、スナップショットなどの包括的なデータ保護機能を活用することで、ビジネスクリティカルなワークロードを保護することもできます。

機能、容量、マシンサポート、パフォーマンスに関する詳細については、ドキュメントをご覧ください。

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

一般的なワークロードに関する推奨事項

適切な Hyperdisk アーキテクチャを簡単に選べるように、よく見られる一般的なワークロードに対する推奨事項の概要を以下に示します。エンタープライズ環境では、Hyperdisk ポートフォリオを活用し、アプリケーションの各コンポーネントのニーズに応じて最適な Hyperdisk のタイプを組み合わせることで、3 層アプリケーション全体を最適化できます。

汎用データベースを含むエンタープライズアプリケーション:

Hyperdisk Balanced とストレージプールを組み合わせることで、一般的なデータベースワークロードをはじめとした、幅広い汎用ワークロードに優れたソリューションを提供します。Hyperdisk Balanced は、Clickhouse、MySQL、PostgreSQL など、ほとんどのデータベースの IOPS とスループットのニーズを満たし、標準的な価格帯で利用できます。Hyperdisk Balanced は、1 ボリュームあたり 16 万 IOPS を発揮し、AWS EBS gp3 ボリュームの 10 倍のパフォーマンスを実現します2。ストレージプールを使用することで、効率を高め、計画を大幅に簡素化できます。また、典型的なデータベースワークロードにおいても、Hyperdisk Balanced ボリュームや AWS EBS gp3 ボリュームと比較して、ストレージの費用を約 20～40% 削減できます3。

「Sentry.io は迅速なデバッグと問題解決を支援するプラットフォームであり、全世界で 400 万人以上の開発者と 13 万のチームに利用されています。Google Cloud の Hyperdisk を採用したことで、当社のビジネスの中核を担うイベント分析プラットフォームに、次世代に向けた柔軟なアーキテクチャを構築できました。大容量かつ高性能な Hyperdisk ストレージプールにより、数週間かかっていた計画サイクルを数分に短縮でき、永続ディスクと比較してストレージの費用を 37% 削減することにも成功しました。」- Sentry、最高技術責任者、Dave Rosenthal 氏

「Blackline にとって高可用性は不可欠です。当社では、グローバル規模でミッションクリティカルな財務決算管理システムを展開するにあたり、大規模なデータベースフェイルオーバークラスタリングを運用しています。このような重要なワークロードを Google Cloud に移行でき、大変喜ばしく思います。Hyperdisk Balanced High Availability により、お客様が求めるパフォーマンス、容量、コスト効率、レジリエンスの要件を満たし、さらにはグローバル規模での金融規制への対応にも貢献しています。」- Blackline、SVP Cloud エンジニアリング＆オペレーション、Justin Brodley 氏

Tier-0 データベース

SAP HANA、SQL Server、Oracle データベースなどのハイエンドかつパフォーマンス重視のデータベースには、Hyperdisk Extreme が妥協のないパフォーマンスを提供します。Hyperdisk Extreme を使用すると、単一ボリュームで最大 35 万 IOPS と 10 GiB/秒のスループットを実現できます。

AI、分析、スケールアウトワークロード

Hyperdisk は、最も要求の厳しい次世代の ML とハイパフォーマンスコンピューティングのワークロードに対して、優れたソリューションを提供します。

動的にスケールする AI、分析ワークロード、および高性能ファイルシステム

需要の変動が激しく、ピーク時のスループットや IOPS を必要とするワークロードには、Hyperdisk Balanced とストレージプールが効果的です。これらのワークロードには、お客様が管理する並列ファイルシステムや、アクセラレータクラスタ向けのスクラッチディスクが含まれます。ストレージプールの動的なリソース割り当てにより、ピーク時でもパフォーマンスを確保でき、手動調整の手間や非効率なオーバープロビジョニングを回避できます。さらに、ストレージプールを設定することで、ディスク単位での計画が大幅に簡素化されます。注: フルマネージドのファイルシステムをお求めの場合は、Managed Lustre をご検討ください。

「Hudson River Trading（HRT）では、定量取引に最先端の ML を活用しています。Google Cloud のアクセラレータ最適化マシン、Dynamic Workload Scheduler（DWS）、および Hyperdisk を導入したことで、最先端モデルの開発が大幅に加速しました。Hyperdisk ストレージプールにより、通常の Hyperdisk と比較してストレージ費用を約 50% 削減でき、計画にかかる手間も最小限に抑えられました。」- Hudson River Trading、システムエンジニア、Ragnar Kjørstad 氏

AI / ML と HPC のデータ読み込みの高速化

Hyperdisk ML は、推論、トレーニング、HPC ワークロードのデータ読み込み時間の高速化に特化したストレージです。一般的な代替手段と比較してモデルの読み込み時間を 3～5 倍高速化します4。Hyperdisk ML は、Google Cloud の他のストレージサービスと比べて、サービングタスクに特に優れた性能を発揮します。1 ボリュームあたり最大 1.2 TiB/秒の総スループットを実現し、多数の VM に対して同時に高い総スループットを提供します。これにより、競合製品と比較して 100 倍以上のパフォーマンスを達成します5。1 回の書き込みで最大 64 TiB のディスクを作成し、読み取り専用モードで複数の VM インスタンスを同じボリュームにアタッチできます。Hyperdisk ML を使用すると、GPU や TPU などの最も高価なコンピューティングリソースのデータ読み込み時間を短縮できます。詳細については、g.co/cloud/storage-design-ai をご覧ください。

「Resemble AI では、独自のディープラーニングモデルを活用して、テキスト読み上げや音声変換による高品質な AI 音声を生成しています。Google Cloud の A3 VM と NVIDIA H100 GPU、Hyperdisk ML を組み合わせることで、トレーニングワークフローを大幅に改善できました。Hyperdisk ML によりデータローダのパフォーマンスが劇的に向上し、類似のソリューションに比べてエポックサイクルを 2 倍の速度で実行できるようになりました。この高速化により、エンジニアリングチームは柔軟に実験を重ねながら大規模なトレーニングを実施し、プロトタイプから本番環境へと迅速に移行できるようになりました。」- Resemble AI、CEO、Zohaib Ahmed 氏

「Abridge は、生成 AI を活用して患者と医療従事者の間の会話をリアルタイムで要約することで、臨床文書に革命をもたらしています。Hyperdisk ML を採用したことで、モデルの読み込み速度が最大 76% 向上し、Pod の初期化時間が短縮されました。」- Abridge、ソフトウェアエンジニア、Taruj Goyal 氏

大容量の分析ワークロード:

Hadoop や Kafka などの大規模なデータ分析ワークロードは、ディスクレイテンシの変動にあまり影響されません。そのため、Hyperdisk Throughput は高スループットかつ費用対効果の高いソリューションとなります。スループットを自由に構成できるうえ、1 GiB あたりのコストが低いため、TCO を抑えながら大量のデータを処理するのに最適です。

Hyperdisk のサイズ設定と設定方法

ワークロードに適した Hyperdisk ボリュームタイプを選択してサイズ設定する際には、以下の事項を確認してください。

ストレージ管理。ワークロードのブロックストレージをプール単位で管理するか、個別に管理するかを決定します。ワークロードの容量が単一のプロジェクトとゾーンで 10 TiB を超える場合は、Hyperdisk ストレージプールを使用して TCO を削減し、計画を簡素化することを検討してください。ストレージプールはディスクのパフォーマンスに影響しません。ただし、レプリケーションや高可用性など、一部のデータ保護機能はストレージプールではサポートされていません。
レイテンシ。SSD 並みのミリ秒未満のレイテンシが求められるワークロードには、Hyperdisk Balanced または Hyperdisk Extreme が適しています。
IOPS またはスループット。単一ボリュームから 16 万 IOPS 未満または 2.4 GiB/秒未満のスループットが必要なアプリケーションには、Hyperdisk Balanced が最適です。それ以上の性能が必要な場合は、Hyperdisk Extreme を検討してください。
パフォーマンスと容量のサイズ設定。Hyperdisk は容量とパフォーマンスを個別に設定できるため、必要なリソース分のみのお支払いで利用できます。この機能を活用して、ディスクのピーク IOPS、スループット、およびワークロードに必要な容量を把握することで、TCO を削減できます。具体的には、そのワークロードを処理するディスクに保存されるデータ量を、GiB または TiB 単位で見積もります。ワークロードがすでに Google Cloud 上で稼働している場合は、コンソールの Metrics Explorer でこれらの指標を確認できます。

もう一つの重要な考慮事項は、ワークロードに求められるビジネスの継続性とデータ保護のレベルです。ワークロードによって、目標復旧時点（RPO）と目標復旧時間（RTO）の要件が異なるため、それにかかる費用も変わってきます。データ保護の方針を決める際には、ワークロードの重要度を考慮しましょう。重要なアプリケーションやワークロードほど、データ損失やダウンタイムに対する許容度が低くなります。ビジネスオペレーションに不可欠なアプリケーションでは、RPO はゼロ、RTO は数秒程度であることが求められます。Hyperdisk のビジネスの継続性とデータ保護は、お客様が求めるパフォーマンス、容量、コスト効率、レジリエンスの要件を満たすとともに、世界中の金融規制への対応にも貢献します。

ワークロードに適した Hyperdisk の種類を選ぶ際に、考慮すべき事項をいくつか紹介します。

攻撃や悪意のある内部者からワークロードを保護するにはどうすればよいですか？Google Cloud Backup Vault を使用すると、バックアップの不変性や消去不能性、サイバーレジリエンスを確保でき、バックアップのレポート作成やコンプライアンス対応も管理できます。バックアップを自己管理する場合は、ワークロード向けの Hyperdisk 標準スナップショットも利用できます。
ユーザーエラーや不具合のあるアップグレードによる影響から、低い RPO / RTO を保ちつつ、コスト効率よくデータを保護するにはどうすればよいですか？インスタントスナップショットによるポイントインタイムリカバリをご利用ください。この機能を使うと、非常に低い RPO と RTO で、ユーザーエラーや不具合のあるアップグレードによるデータ損失のリスクを最小限に抑えられます。チェックポイントの作成はほぼ瞬時に行えます。
複数のロケーションにわたってレジリエンスを確保しながら、重要なワークロード（MySQL など）を簡単にデプロイするにはどうすればよいですか？Hyperdisk HA をご利用ください。これは、フェイルオーバークラスタリングを活用する SQL Server など、高可用性と高速フェイルオーバーが求められるシナリオに最適です。このようなワークロードでは、マルチライターサポートを備えた Hyperdisk Balanced High Availability の新しい機能を利用することもできます。これにより、2 つのゾーンで RPO=0 の同期レプリケーションを実現し、ワークロードに最適化されたストレージを利用したクラスタ化コンピューティングを実行できます。
障害が発生した場合、ワークロードを別の場所で迅速かつ確実に復元し、その復元プロセスを確認するための訓練を行うにはどうすればよいですか？Hyperdisk 非同期レプリケーションを使用した障害復旧機能をご利用ください。これにより、リージョン間の継続的なレプリケーションやリージョン障害からの復旧が可能になります。また、クローン作成による障害復旧訓練の迅速な検証もサポートしています。さらに、リージョン間でワークロードのフェイルオーバーが必要になった際にも、整合性グループポリシーにより複数のディスクに分散されたワークロードデータを確実に復元できます。

つまり、Hyperdisk はワークロードに応じてブロックストレージを最適化できる豊富な選択肢を備えています。さらに、適切な Hyperdisk を選択してストレージプールなどの機能を活用することで、TCO を削減し、管理を簡素化できます。詳しくは、ウェブサイトをご覧ください。お客様に合わせた推奨事項については、Google Cloud アカウントチームにお問い合わせください。

^{1. 2025 年 3 月時点で公開されている Amazon EBS、Azure マネージドディスクの情報}

^{2. 2025 年 5 月時点での Amazon EBS gp3 ボリュームの最大 IOPS（ボリュームあたり）との比較}

^{3. 2025 年 3 月時点の正規価格に基づき、容量 50～150 TiB、ピーク IOPS 25K～75K、圧縮率 25% の場合の Amazon EBS gp3 ボリュームとの比較}

^{4. 2025 年 3 月時点の Google 内部ベンチマークに基づき、大規模ノードサイズにおいて Rapid Storage、Anywhere Cache を利用した GCSFuse、Parallelstore、Lustre と比較した場合}

^{5. 2025 年 3 月時点で公開されている Microsoft Azure Ultra SSD および Amazon EBS io2 BlockExpress のパフォーマンスに基づく。}

^{このブログの執筆にご協力いただいた David Seidman 氏と Ruwen Hess 氏に、著者一同から感謝を申し上げたいと思います。}

-Google、グループプロダクトマネージャー、Ben Gitenstein
-Google Cloud、プロダクト管理担当、Sai Gopalan

Google Cloud のオープンレイクハウス: AI、オープンデータ、比類のないパフォーマンスを実現する設計

Thu, 05 Jun 2025 02:00:00 +0000

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

Google のデータクラウドは、Google のグローバル規模のインフラストラクチャ上に構築された独自の統一プラットフォームで、AI が組み込まれており、マルチモーダルデータに対応したオープンレイクハウスアーキテクチャを特徴としています。すでに Snap Inc. などの組織は、Google のデータクラウドとオープンレイクハウスアーキテクチャにより、データエンジニアやデータサイエンティストがデータアセットをより有効に活用できるようになったと評価しています。

「Google Cloud とのパートナーシップは、Snap の次世代オープンレイクハウスを構築し、デベロッパーコミュニティで Spark と Iceberg の普及を推進する取り組みにおいて非常に重要な役割を果たしてきました。」- Snap Inc.、ソフトウェアエンジニアリング担当シニアマネージャー、Zhengyi Liu 氏

このたび、オープン性、インテリジェンス、パフォーマンスの新しい基準を打ち立てる、AI を活用したレイクハウスの一連のイノベーションを発表いたしました。これらのイノベーションには、次のようなものがあります。

BigLake Iceberg ネイティブストレージ: Google Cloud Storage（GCS）を活用して、企業が大規模に Iceberg データを管理し、相互運用することを実現します。これには、Apache Iceberg 向け BigLake テーブル（一般提供）と新しい REST Catalog API を備えた BigLake Metastore（プレビュー）が含まれます。
運用エンジンと分析エンジンのインテグレーション: BigLake の基盤上に構築することで、分析ワークロード向け BigQuery（一般提供）と AlloyDB for PostgreSQL（プレビュー）を使用して同じ Iceberg オープンデータ基盤でシームレスに相互運用し、運用ニーズに対応できます。
BigQuery SQL のパフォーマンス向上: BigQuery の高度なランタイム、低レイテンシのクエリ API、列のメタデータインデックス処理、きめ細かな更新 / 削除の桁違いの高速化など、自動化された SQL エンジンに関する強化された一連の機能を提供することで、データ処理を大幅に高速化してアジリティを高めます。
Apache Spark 向けの高性能 Lightning Engine: 新しい Lightning Engine（プレビュー）は、最適化されたデータコネクタ、効率的な列シャッフル操作、組み込みのキャッシュ保存、ベクトル化された実行を活かして、Apache Spark を強化するように設計されています。
Dataplex Universal Catalog: データから AI（BigLake Iceberg、BigQuery、Spanner、Vertex AI モデルなど）へのメタデータを自動的に検出して整理し、BigLake を介した一元的なポリシー適用を可能にするとともに、AI によるキュレーション、データ分析、セマンティック検索をサポートすることで、Google Cloud データ資産全体に AI を活用したインテリジェンスと統合ガバナンスを拡張します。
AI ネイティブなノートブックとツール: Gemini を活用したノートブック、PySpark コード生成、JupyterLab と Visual Studio Code のコード拡張機能により、開発作業が向上します。さらに、サードパーティ製ノートブックインターフェースによって機能の強化と統合を実現しました。

これらの新たなイノベーションを詳しく見ていきましょう。

BigLake サービスの拡張: オープン、統合型、相互運用可能

Google は Google Cloud Storage を活用し、BigLake を Google のデータクラウド向けの包括的なストレージランタイムへと積極的に再構築しています。このアプローチにより、Google ネイティブストレージとオープンフォーマットで保存されたデータにまたがる、オープンで高性能なマネージドレイクハウスを構築できます。BigLake の一部として、Apache Iceberg 向け BigLake テーブル（一般提供）を通じて Google Cloud Storage 上で Iceberg に大規模に対応する新しい Iceberg ネイティブストレージを発表いたしました。BigLake は Google の Cloud Storage 管理機能をネイティブにサポートし、それを Iceberg データにも拡張します。これにより、ストレージ Autoclass を使用して、より使用頻度の低いストレージクラスへの効率的なデータ階層化が可能になり、ストレージバケットに顧客管理の暗号鍵（CMEK）を適用できます。BigLake は Dataplex Universal Catalog でもネイティブにサポートされているため、データ資産全体で一元的なガバナンスを一貫して確実に適用できます。

BigLake の基盤となる新しい BigLake Metastore（一般提供）は、Apache Iceberg REST Catalog API（プレビュー）を備えており、管理とガバナンスを簡素化しながらデータエコシステム全体で真のオープン性と相互運用性を実現できます。BigLake Metastore は Google のグローバルインフラストラクチャ上に構築されており、サーバーレスかつスケーラブルな統合型のマネージドサービスを提供します。BigQuery、Iceberg ネイティブストレージ、セルフマネージドオープンフォーマットにまたがるエンタープライズメタデータを統合し、分析、運用クエリ、ストリーミング、AI をサポートします。BigLake ソリューションはユニバーサルエンジンの相互運用性を実現し、BigQuery、AlloyDB、Google Cloud Serverless for Apache Spark などのファーストパーティ Google Cloud サービスや、サードパーティ製およびオープンソースのエンジンを含め、BigLake で管理されている Iceberg データに対して一貫して動作するさまざまなクエリエンジンをサポートしています。

さらに、Hadoop / Cloudera からの Iceberg テーブルとメタデータの自動移行（プレビュー）サービスと、ワンクリックでの Delta から Iceberg への移行サービス（プレビュー）など、強化された移行サービスにより、Iceberg ネイティブストレージへのデータ移行がこれまで以上に簡単になっています。

aside_block: <ListValue: [StructValue([('title', '300 ドル分のクレジットで Google Cloud のデータ分析を試用'), ('body', <wagtail.rich_text.RichText object at 0x7f7ab0995d90>), ('btn_text', '無料で構築を始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectPath=/bigquery/'), ('image', None)])]>

分析エンジンと運用エンジンがオープンデータで統合

詳細な分析を行う必要がある場合、BigQuery で Apache Iceberg 向け BigLake テーブルを使用して Iceberg データの読み取りと書き込みができるようになりました。BigQuery は、従来は独自のデータウェアハウスに関連付けられていた機能により Iceberg テーブルをさらに強化します。また、BigQuery を使用するとゼロレイテンシクエリのための高スループットストリーミング、自動データ再クラスタリングによるテーブル管理の強化、マルチテーブルトランザクション（プレビュー）に対応した高度な ETL ユースケースの構築を実現できます。さらに、BigQuery の組み込み AI 機能（BQML、AI Query Engine、マルチモーダル分析）をオープンデータセットで直接活用できます。このインテグレーションにより、ネイティブの Iceberg ストレージに関連するオープン性とデータ所有権のメリットを享受しながら BigQuery の幅広い機能も利用できます。実際、BigQuery と BigLake Iceberg を併用するお客様は 18 か月で 3 倍近くに増加しており、現在では数百ペタバイトを管理しています。

統合されたデータマネジメントは、分析を超えてビジネス運用の中心にまで拡大しています。Google の高性能な運用データベースである AlloyDB for PostgreSQL では、BigLake が管理する同じ Iceberg データに対してネイティブにクエリを実行できるようになりました。これにより、運用アプリケーションで複雑な ETL なしで BigLake の豊富な機能を活用できるようになり、セマンティック検索や自然言語クエリなどの AlloyDB AI 機能を Iceberg データに適用できます。

Bayer のようなお客様は、AlloyDB と BigQuery を組み合わせてデータクラウドをモダナイズし、膨大な量の観測データを保存、分析しています。Bayer は BigQuery を使用してリアルタイムの分析と知見を生み出し、AlloyDB で運用化することで、以前のソリューションよりも回答率が 50% 増になり、スループットが 5 倍に向上しました。

オープンデータで高性能な BigQuery SQL とサーバーレス Spark を活用

また、すべてのデータを迅速かつインテリジェントに有効化できる、高性能な新しいデータ処理機能も提供します。BigQuery の SQL エンジンは、独自の自動的なパフォーマンス強化機能スイートにより革新を続けています。BigQuery の高度なランタイム（プレビュー）は、強化されたベクトル化と短いクエリ最適化モードによって、ユーザーの操作やコードの変更を必要とせずに分析ワークロードを自動的に高速化できます。これを補完するのが BigQuery API のオプションであるジョブ作成モード（一般提供）です。このモードでは、短期間のインタラクティブクエリのクエリパスが最適化され、レイテンシが短縮されます。BigQuery 列メタデータインデックス（CMETA）（一般提供）を使用すると、クエリの効率がさらに向上します。CMETA はシステム管理によるデータプルーニングをより効率的に行うことで、大規模なテーブルに対するクエリの処理を支援します。その他のアーキテクチャの改善により、BigQuery のきめ細かな更新 / 削除（プレビュー）の処理速度が桁違いに向上し、オープンフォーマットを含む大規模なデータ操作のアジリティが向上しています。

同時に、Apache Spark 向けの新しい Lightning Engine（プレビュー）により、Apache Spark の高速化を実現します。Lightning Engine は、Cloud Storage と BigQuery ストレージ向けに高度に最適化されたデータコネクタ、効率的な列シャッフル操作、インテリジェントな組み込みのキャッシュメカニズムにより、Apache Spark のパフォーマンスを高速化します。さらに、Lightning Engine はネイティブ C++ ライブラリ（Velox と Gluten）で構築されたベクトル化実行を活用し、Apache Spark 向けに最適化されています。この強力な組み合わせにより、TPC-H のようなベンチマークで 3.6 倍速い Spark パフォーマンスを達成しています。さらに、Google の Spark サービスは AI / ML に対応しており、事前にパッケージ化された AI ライブラリ、最新の ML ランタイム、簡単な GPU サポートを提供しています。これにより、Google Cloud Serverless for Apache Spark サービスまたは Dataproc クラスタデプロイを通じて利用できる Apache Spark は、Google データクラウドのレイクハウス環境における最高水準の高性能なサービスとしての地位を確立しています。

Dataplex Universal Catalog: Google Cloud 全体で AI を活用したインテリジェンスを実現

効果的な AI 主導のデータ戦略は、あらゆる規模で運用できるインテリジェントでアクティブなユニバーサルカタログの存在にかかっています。この機能は、Dataplex Universal Catalog が、Google のデータクラウド向けに提供しているものであり、分散したデータ資産全体を信頼性の高い、検出可能で実用的なリソースに変換します。

Dataplex Universal Catalog は、分析と運用の環境全体でメタデータを自動的に検出、理解、整理します。ここでは、BigLake ネイティブの Iceberg ストレージ、Cloud Storage 上の Delta や Hudi などのオープンフォーマット、BigQuery の分析データ、Spanner などのデータベースのトランザクションデータ、Vertex AI の ML モデルのメタデータなどを包括的に把握でき、Google のデータクラウド全体にわたる広範なガバナンスを示しています。

また、ユーザーがガバナンスポリシーを一元的に定義し、BigLake を通じて複数のデータエンジンで一貫して適用できるようにすることで、Dataplex Universal Catalog はレイクハウスにとっても不可欠な要素となります。このインテグレーションにより、Google のデータクラウドのすべてのエンジンできめ細かいアクセス制御とガバナンスの強化が実現します。BigLake ソリューションは、クルデンシャルベンディングをサポートしており、これにより、ユーザーは一元的に定義されたポリシーを Cloud Storage のデータに安全に拡張できます。

Dataplex Universal Catalog は AI を活用し、Gemini 拡張ナレッジグラフを使用してメタデータを動的で実用的なインテリジェンスに変換します。ここでは、AI がメタデータのキュレーションを自動化し、データ要素間の隠れた関係を推論して、複雑なクエリに基づくデータからの分析情報を事前に推奨します。そして、自然言語によるセマンティック検索を可能にします。また、AI を活用した新しいエクスペリエンスや自律型エージェントにも有効です。たとえば、Dataplex Universal Catalog を使用した Gemini 搭載のアシスタント機能では、データセットの識別精度が 50% 向上し、分析情報の取得が大幅に高速化されています。Dataplex Universal Catalog は、Collibra などのプラットフォームへのシームレスなメタデータ連携を可能にするオープンなエコシステムの基盤でもあり、Dataplex Universal Catalog API を通じて幅広い接続性を実現します。

AI ネイティブなノートブックとツールで実務担当者を支援

Google Cloud の目標は、データ実務者が好むツールやワークフローに高度な AI とレイクハウスのインテグレーションを直接埋め込むことで、データ実務者の業務に革新をもたらすことです。このオープンかつ柔軟でインテリジェントな環境に対する取り組みにより、データサイエンティスト、エンジニア、アナリストの生産性とイノベーションを新たなレベルへと引き上げます。

これを可能にするのが、SQL、Python、Apache Spark にまたがる相互運用可能な統合開発環境を提供する、次世代の AI ネイティブな BigQuery ノートブックです。このような統合開発環境は、深く組み込まれた Gemini のアシスト機能によって強化されています。Gemini はインテリジェントなコラボレーターとして機能し、高度な PySpark コード生成や複雑なコードに対する有益な説明をするほか、サーバーレス Spark のトラブルシューティング向け Cloud Assist Investigations（プレビュー）と直接統合されています。これらにより、Gemini は、開発における摩擦を大幅に軽減して、データから分析情報を得るまでのプロセスを加速します。

さらに、BigQuery、Dataproc、Google Cloud Serverless for Apache Spark（プレビュー）向けの新しい JupyterLab と Visual Studio Code の拡張機能により、開発者は最小限のセットアップで、お気に入りの IDE から直接 Google Cloud のオープンレイクハウス機能に接続できます。開発者は、開発からデプロイまでのエンドツーエンドなプロセスに対応している好みのツールでレイクハウスのすべてのデータセットとファイルにアクセスして、数分以内に開発を開始できます。サーバーレス Spark を使用したノートブックの使用量は、2024 年第 1 四半期から 2025 年第 1 四半期にかけて 4 倍以上に増加しました。

こういったインテグレーションの進歩により、レイクハウスアーキテクチャを基盤とする適応性の高いインテリジェントかつ高性能なデータクラウドを実現し、組織がすべてのデータを Google AI に接続してその可能性を最大限に引き出すことで、AI 時代のイノベーションを定義できるよう支援しています。5 月 29 日に開催されるお客様向けのオンラインイベントにぜひご参加いただき、これらのエキサイティングなイノベーションの詳細をご確認ください。こちらをクリックして詳細を確認し、これらの新機能の早期アクセスにご登録ください。皆様が構築されるソリューションを楽しみにしています。

-Google Cloud、データクラウド担当バイスプレジデント兼ゼネラルマネージャー、Andi Gutmans

-Google Cloud、データクラウド担当マネージングディレクター、Yasmeen Ahmad

新しいコンピューティングのイノベーションとサービスで企業の変革を推進

Thu, 08 May 2025 01:00:00 +0000

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

過去 12 か月間で、Google Cloud は Compute Engine プラットフォームの目覚ましい強化を実現しました。その大きな原動力となったのが、新しい第 4 世代のコンピューティングインスタンスと Hyperdisk ブロックストレージ、そしてカスタマーエクスペリエンスの大幅な向上です。Google Cloud のコンピューティングポートフォリオは、あらゆるワークロードにおけるパフォーマンスと費用を最適化する一方で、エンタープライズクラスのスケーラビリティ、信頼性、セキュリティ、ワークロードの一貫性を実現して、効率的な成長とイノベーションへの投資を促進します。このたび Google Cloud Next 2025 で発表される内容について見ていきましょう。

あらゆるワークロードに対応する、新たに進化したコンピューティング機能

C4D は vCPU あたりのスループットを 80% 向上させ、パフォーマンスを強化

Google の新しい C4D VM は、AMD の第 5 世代 EPYC プロセッサを基盤とし、Google Titanium の最新技術との組み合わせにより、コア周波数の向上（最大 4.1 GHz）を実現します。C4D は、一般的な幅広いコンピューティングワークロードにおいて、前世代と比較してパフォーマンスが大幅に向上しています（SPECrate®2017_int_base ベンチマークの推定結果で C3D と比較して最大 30% 向上）。これにより、ビジネスクリティカルなアプリケーションのニーズを、より少ないリソースで満たすことができます。

データベースの場合、C4D は C3D と比較して、MySQL での秒間クエリ数が最大 55% 増加し、Redis ワークロードのパフォーマンスが 35% 向上します。ウェブサービスワークロードでは、前世代と比較して vCPU あたりのスループットが最大 80% 向上し、ページのレンダリングが高速化するほか、エンドユーザーにとってもよりスムーズな体験が得られます。C4D は Confidential Computing を提供し、業界標準の 49 のシェイプで利用可能です。サイズは 2 vCPU～384 vCPU、メモリ構成は 3 種類で、最大 3 TB の DDR5 メモリを選択できます。また、Google 初の AMD ベースのベアメタルのプロダクトと新しい Titanium LSSD も含まれます。Compute Engine と Google Kubernetes Engine（GKE）で、プレビュー版が利用可能になった C4D を今すぐお試しください。

「AppLovin は、モバイル広告のグローバルリーダーとしてクライアントに優れたパフォーマンスを提供するため、常に最先端のインフラストラクチャのイノベーションを模索しています。Google Cloud の C4D VM はまさにその目標を達成するための鍵となり、前世代と比較して約 40% の改善を実現し、大幅な効率化とレイテンシの短縮を可能にしました。」- AppLovin、CTO、Basil Shikin 氏

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

これまでにない機能と柔軟性を実現する C4 VM

ゲーム、推論、大規模データ処理、リアルタイムワークロードなど、要求の厳しい低レイテンシのタスクに対応するため、C4 マシンシリーズが拡張され、より大きなシェイプ、ローカル SSD、ベアメタルなどの新しい機能と構成を選択できるようになりました。これらの新しい C4 シェイプは、最新の第 6 世代 Intel Granite Rapids CPU のみを基盤としており、Compute Engine VM の中で最高周波数（最大 4.2 GHz）を誇ります。

Titanium ローカル SSD を搭載した C4 シェイプは、データベースやキャッシュレイヤなどの I/O 集約型ワークロードのパフォーマンスを向上させ、ローカル SSD のレイテンシを最大 35% 短縮します。新しい C4 ベアメタルインスタンスは、前世代と比較して、一般的なコンピューティングで最大 35%、ML レコメンデーションワークロードで最大 65% のパフォーマンス向上を実現します。新しい大規模な C4 VM シェイプは、最大 288 vCPU までスケールでき、2.2 TB の高パフォーマンス DDR5 メモリを搭載し、キャッシュサイズが大きくなったことで、データベース、データ分析、メモリ制約のあるその他のワークロードのスケーラビリティを向上させます。プレビュー版へのアクセスは、こちらからリクエストできます。

HPC ワークロードでの大幅なパフォーマンス向上を実現する H4D

H4D VM を使用すると、HPC ワークロードをスケールして、これまで以上に迅速に分析情報を取得できます。これらの VM は第 5 世代 AMD EPYC CPU を基盤としており、12,000 FLOPS を超えるノード全体での VM パフォーマンス、コアあたりのパフォーマンス、950 GB/秒を超えるメモリ帯域幅は、いずれも最高水準を誇ります。H4D VM は 200 Gbps の低レイテンシの Titanium RDMA ネットワーク帯域幅を実現し、10,000 を超えるコアを持つクラスタをサポートしており、今後さらなるスケールの向上も計画されています。詳しくは、Google の科学的革新に関するブログ記事をご覧ください。または、H4D プレビューにご登録ください。

「第 5 世代 AMD EPYC を搭載した Google H4D VM が実現する世代間のパフォーマンス向上は、実に驚くべきものです。Altair Radioss は、自動車事故の分析など、コンピューティング負荷が高く、高度に非線形なシミュレーションで、驚異的な 3.6 倍の高速化を実現します。この飛躍的な進歩により、デジタルスレッドの時代においてお客様にとって不可欠なより高速かつ高精度のシミュレーションが可能になります。」- Radioss Development and Altair Solvers HPC、シニアバイスプレジデント、Eric Lequiniou 氏

要求の厳しい SAP ワークロードにおいてパフォーマンスを 2 倍に向上させる M4 VM

Compute Engine の 99.95% のメモリ最適化単一インスタンス SLA に裏打ちされた M4 VM は、従来のメモリ最適化 M3 と比較して、コストパフォーマンスが最大 65%、SAP Application Performance Standard（SAPS）が 2.25 倍向上します。第 5 世代 Intel Xeon スケーラブルプロセッサを基盤とする M4 VM は、744 GB～3 TB のビジネスクリティカルなインメモリ SAP HANA ワークロードと SAP NetWeaver アプリケーションサーバーの認定 VM です。

ストレージ使用量の多いワークロード向けの Z3

データウェアハウス、SQL、NoSQL データベースなどの I/O 集約型ワークロード向けに、Z3 ストレージ最適化ファミリーに新しい Titanium SSD が搭載され、インスタンスあたり 3 TB～18 TB の 9 種類の新しい小型シェイプが提供されるようになりました。また、新たに導入されるストレージ最適化ベアメタルインスタンスは、最大 72 TB の Titanium SSD を搭載し、物理サーバー CPU への直接アクセスが可能です。プレビュー版にご興味がございましたら、こちらからご登録ください。

Nutanix Cloud Clusters が Google Cloud で利用可能に

新しい Z3-metal インスタンスを選択した Nutanix との提携により、Nutanix Cloud Clusters（NC2）on Google Cloud がリリースされます。Nutanix NC2 は、プライベートクラウドとパブリッククラウドのアプリ、データ、AI の実行、管理、運用を簡素化するハイブリッドクラウドプラットフォームです。NC2 の共通運用モデルにより、ワークロードを一貫した方法で簡単に管理できるため、お客様の Google Cloud への移行を加速させ、アプリのモダナイゼーションを支援します。詳細をご確認のうえ、公開プレビュー版にご登録ください。

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

クラウドで VMware 環境を最適化するためのオプションがさらに充実

Google Cloud VMware Engine は、既存の VMware 資産の Google Cloud へのリフト＆変革を行うための最も迅速な手段の一つです。このたび、18 のノードシェイプが追加され、VMware Engine v1 と v2 のノードシェイプの総数は 26 に増加しました。これは競合他社の 6 倍に相当します。これにより、お客様がワークロードのニーズに合わせて容量を調整し、TCO を最適化するために、業界で最も幅広いオプションが提供されます。

スケールと効率性の向上を実現するストレージとプラットフォームの機能

Google Cloud の第 4 世代のコンピューティング、ネットワーキング、ブロックストレージのポートフォリオは、高度に差別化された複数のテクノロジーを基盤として構築されています。Titanium は、特定用途向けのカスタムシリコンと複数層のスケールアウトオフロードからなるシステムであり、CPU の負荷を軽減することでパフォーマンス、信頼性、セキュリティを強化して、ワークロードの効率を最大限に高めます。上述の複数の発表で紹介されているように、Titanium は Google Cloud のコンピューティング、ストレージ、ネットワーキングの各サービスに統合されています。

また、先日の Titanium ML アダプタの更新により、NVIDIA ConnectX-7 ネットワークインターフェースカード（NIC）を安全に統合し、GPU 間の非ブロッキング帯域幅を 3.2 Tbps に引き上げられるようになりました。さらに、Titanium オフロードプロセッサについては GPU クラスタを Jupiter データセンターファブリックと統合し、クラスタのスケールを拡大しました。

Hyperdisk による次世代のブロックストレージ

Hyperdisk は、Google Cloud のワークロードに最適化された高パフォーマンスのブロックストレージです。費用効率と使いやすさに優れ、ワークロードの包括的なデータ保護機能を提供します。Hyperdisk ストレージプールは、容量とパフォーマンスを各ワークロードで個別に調整するなど、独自の機能によって、シンプロビジョニングとデータの削減を可能にし、TCO の削減と大規模な管理の簡素化を実現します。お客様が移行するワークロードのサイズ拡大に伴い、Google Cloud はストレージプールを拡張し、1 つのプールに最大 5 PiB のデータを保存できるようにしました。これは、従来の 5 倍のデータ量です。

さらに、Hyperdisk Exapools も導入されます。これは、特に大規模で要求の厳しい AI トレーニングワークロード専用に構築されたストレージプールの新しいバリアントです。Hyperdisk Exapools を使用すると、数エクサバイトの容量と 1 秒あたり数テラバイトのスループットを実現するブロックストレージをプロビジョニングして管理できます。また、シンプロビジョニングとデータ削減を活用して TCO を削減し、管理を簡素化することもできます。Exapools は、2025 年第 2 四半期（今四半期中）にプレビュー版として提供される予定です。

Hyperdisk ML には、GKE Volume Populator を使用した Cloud Storage からのハイドレート、最新の Compute Engine インスタンスへのアタッチ、Hyperdisk ML からのデータ読み込みの高速化による最新の TPU VM ファミリーでのトレーニング / 推論の実行などの新機能も追加されています。詳しくは、こちらの AI インフラストラクチャに関するブログ記事をご覧ください。

使用パターンに合わせてリソースを割り当て

マネージドインスタンスグループ（MIG）を使用することで、要求の厳しいコンピューティングタスクの効率性、柔軟性、制御性を高めることができます。MIG は、単一のエンティティとして管理できる仮想マシンの集合です。たとえば、複数の VM タイプを使用するように MIG を構成すると、需要が大きい期間や急速に増大する期間においても、容量が自動的に検出されます。また、事前初期化済み VM を含む MIG 内の停止または一時停止された VM を使用することで、費用を削減し、アプリケーションの起動を高速化できます。さらに、Vertex AI と Autopilot での確約利用割引（CUD）と予約の共有の導入により、インフラストラクチャを一度購入するだけで複数のサービスで利用できるようになりました。

最適化されたコンピューティングでイノベーションに投資

すべてのワークロードで最高のパフォーマンスと柔軟性を実現できるインフラストラクチャを提供することは、Google の最優先事項の一つです。汎用 VM から HPC、SAP、データベース向けの専用ソリューションまで、Google Cloud はお客様のニーズに合わせて、ワークロードに最適化されたソリューションを提供し、ビジネスが必要とするイノベーションの実現を支援します。ご不明な点がございましたら、こちらまでお問い合わせください。

-プロダクト管理担当シニアディレクター、Nirav Mehta
-Compute Engine、プロダクト管理担当ディレクター、Salil Suri

Colossus: Rapid Storage の高パフォーマンスを実現する秘密の要素

Fri, 02 May 2025 01:00:00 +0000

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

Google Cloud Storage は、そのシンプルさとスケール性で人気の高いオブジェクトストレージサービスです。その大きな要素の一つは、データの読み書きに使用できるステートレス REST プロトコルです。しかし、AI の台頭と、データ集約型ワークロードの実行を検討するお客様の増加に伴い、レイテンシが高いこととファイル指向セマンティクスがないことが、オブジェクトストレージの使用を妨げる 2 つの大きな要因となっています。この問題に対処するため、Google は Google Cloud に Rapid Storage をリリースし、ステートフルな gRPC ベースのストリーミングプロトコルを追加しました。これにより、オブジェクトにデータを簡単に追加する機能が提供され、オブジェクトストレージの高い総スループットとスケーラビリティを維持しながら、ミリ秒未満の読み取り / 書き込みレイテンシを実現します。この投稿では、このアプローチを採用した理由とその方法、そしてこれによって実現可能な新しいタイプのワークロードについて、アーキテクチャの観点から説明します。

このアプローチでは、Colossus が鍵となります。Colossus は、Google のほぼすべてのプロダクトの基盤となる、Google の内部ゾーンクラスタレベルのファイルシステムです。最近のブログ投稿で説明したように、Colossus は、低レイテンシと大規模なスケーリングを実現する高度な SSD 配置手法により、Google の極めて要求の厳しいパフォーマンス重視のプロダクトをサポートしています。

Colossus のパフォーマンスを支えるもう一つの重要な要素は、そのステートフルプロトコルです。Rapid Storage は、Colossus のステートフルプロトコルの機能を Google Cloud のお客様に直接提供します。

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

Colossus クライアントは、ファイルの作成または読み取りを行う際に、まずファイルを開いてハンドルを取得します。ハンドルには、ファイルのデータが保存されているディスクなど、ファイルの保存方法に関するすべての情報が含まれます。クライアントは、読み取りまたは書き込みの実行時にこのハンドルを使用して、最適化された RDMA のようなネットワークプロトコルを介してディスクに直接アクセスできます。これについては、以前に公開された Snap ネットワーキングシステムに関する論文で概説しています。

ハンドルは、超低レイテンシの永続的な追加をサポートするためにも使用できます。これは、要求の厳しいデータベースやストリーミング分析アプリケーションで非常に有益です。たとえば、Spanner と Bigtable はどちらもログファイルにトランザクションを書き込みますが、ログファイルは永続的なストレージを必要とし、データベース変更のクリティカルパス上にあります。同様に、BigQuery はテーブルへのストリーミングをサポートし、大規模に並列化されたバッチジョブは最近取り込まれたデータに対して計算を実行します。これらのアプリケーションは Colossus ファイルを追加モードで開き、アプリケーションで実行されている Colossus クライアントはハンドルを使用して、データベースの変更とテーブルデータをネットワーク経由で直接ディスクに書き込みます。Colossus は、データの永続性を保証するため、データを複数のディスクに複製します。書き込みは並列に行われ、クォーラム手法を使用してストラグラーを待機することによるレイテンシを回避します。

図 1: Colossus でファイルにデータを追加する手順。

上の図は、ファイルにデータを追加する手順を示しています。

アプリケーションがファイルを追加モードで開きます。Colossus Curator がハンドルを生成し、それをインプロセスで実行されている Colossus クライアントに送信します。クライアントはハンドルをキャッシュに保存します。
アプリケーションが、Colossus クライアントに対して、任意のサイズのログエントリへの書き込み呼び出しを発行します。
Colossus クライアントは、ハンドル内にあるディスクアドレスを使用して、ログエントリをすべてのディスクに並列に書き込みます。

Rapid Storage は Colossus のステートフルプロトコルに基づいて構築されており、基盤となるトランスポートとして gRPC ベースのストリーミングを利用しています。Rapid Storage オブジェクトに対して低レイテンシの読み取りと書き込みを実行する際、Cloud Storage クライアントはストリームを確立し、Cloud Storage の REST プロトコルで使用されるのと同じリクエストパラメータ（バケットやオブジェクト名など）を供給します。さらに、ユーザー認証やメタデータアクセスなどの時間のかかる Cloud Storage 操作はすべて、ストリーミングの作成時に先行ロードされて実行されるため、その後の読み取りと書き込みの操作は、Colossus に対して追加のオーバーヘッドなしで直接実行され、追加可能な書き込みと範囲が限定された繰り返し読み取りをミリ秒未満のレイテンシで実行することが可能となります。

この Colossus アーキテクチャにより、Rapid Storage は 1 つのバケットで 1 秒あたり 2,000 万件のリクエストをサポートできます。これは、さまざまな AI / ML アプリケーションで非常に有用な規模です。たとえば、モデルの事前トレーニングでは、データの準備が完了すると、ランダム化されたデータサンプルのセットが GPU または TPU にフィードされます。これらは通常、それぞれ数億から数十億のトークンを含む大きなファイルです。ただし、トレーニングが進むにつれて、異なるランダムサンプルが異なる順序で読み取られるなどの要因により、データが順次に読み取られることはほとんどありません。Rapid Storage のステートフルプロトコルを使用すると、トレーニングの実行の開始時にストリームが確立されてから、ミリ秒未満の速度で範囲が限定された読み取りが並列に大規模に実行されます。これにより、ストレージのレイテンシによってアクセラレータがブロックされるのを回避します。

追加の場合も同様に、Rapid Storage は Colossus のステートフルプロトコルを利用して、ミリ秒未満のレイテンシで永続的な書き込みを実現し、オブジェクトのサイズ制限まで 1 つのオブジェクトへの追加を無制限にサポートします。ステートフル追加プロトコルの主要な課題は、クライアントまたはサーバーがハングまたはクラッシュした場合にどのように処理するかです。Rapid Storage では、ストリームを作成するときに、クライアントが Cloud Storage からハンドルを受け取ります。ストリームが中断された場合でも、このハンドルを使用して新しいストリームを再確立することで、クライアントはオブジェクトに対して読み取りや追加を継続できます。これにより、このフローが合理化され、レイテンシによる影響を最小限に抑えられます。クライアントに問題があり、アプリケーションが新しいクライアントからオブジェクトへの追加を継続しようとする場合、複雑になります。これを簡略化するために、Rapid Storage では、一度に 1 つの gRPC ストリームのみがオブジェクトに書き込めるようにしています。新しいストリームがオブジェクトのオーナー権限を引き継ぎ、以前のストリームによるトランザクションをロックアウトします。最後に、各追加操作には書き込み先のオフセットが含まれるため、ネットワークパーティションやリプレイが発生しても、データの正確性が常に維持されます。

図 2: 新しいクライアントがオブジェクトのオーナー権限を引き継ぐ。

上の図では、新しいクライアントがオブジェクトのオーナー権限を取得し、以前のオーナーをロックアウトしています。

まず、クライアント 1 が 3 つのディスクに保存されているオブジェクトにデータを追加します。
アプリケーションがクライアント 2 にフェイルオーバーし、クライアント 2 がこのオブジェクトを追加モードで開きます。Colossus Curator が、各オブジェクトデータのレプリカのバージョン番号を増加させ、クライアント 1 によるトランザクションをロックアウトします。
クライアント 1 がオブジェクトにデータを追加しようとしても、そのオーナー権限は古いバージョン番号に関連付けられているため、追加できません。

Rapid Storage をアプリケーションにできる限り簡単に統合できるようにするため、Google は SDK も更新して、gRPC ストリーミングベースの追加をサポートし、シンプルなアプリケーション指向の API を公開できるようにしました。ハンドルを使用してデータを書き込むことは、ファイルシステムの世界では馴染みのあるコンセプトです。そこで Google は、Rapid Storage を Cloud Storage FUSE に統合し、低レイテンシのファイル指向ワークロードのために、クライアントが Cloud Storage バケットにファイルのようにアクセスできるようにしました。また、Rapid Storage では、ゾーンバケットタイプの一部として階層型名前空間をネイティブに有効化しており、パフォーマンスと整合性を強化し、フォルダ指向の API を提供しています。

まとめると、Rapid Storage は、ブロック型ストレージのミリ秒未満のレイテンシ、並列ファイルシステムのスループット、オブジェクトストレージのスケーラビリティと使いやすさを兼ね備えています。これらを実現するため、Colossus が主要な役割を果たしています。プレビュー期間中にお客様が試した興味深いワークロードをいくつかご紹介します。

AI / ML のデータ準備、トレーニング、チェックポインティング
分散データベースアーキテクチャの最適化
バッチ分析とストリーミング分析処理
動画のライブストリーミングとコード変換
ロギングとモニタリング

Rapid Storage の試用にご興味がある場合は、こちらからご登録いただくか、Google Cloud の担当者までお問い合わせください。

詳しくは、Google Cloud Next のブレイクアウトセッション「What’s new with Google Cloud’s Storage（Google Cloud のストレージに関する最新情報）」（BRK2-025）、「AI Hypercomputer: Mastering your Storage Infrastructure（AI Hypercomputer: ストレージインフラストラクチャをマスターする）」（BRK2-020）、「Under the Iceberg: Simple, unified Cloud Storage for analytics data lakes（水面下の氷山: 分析データレイク向けのシンプルで統合された Cloud Storage）」（BRK2-026）にご参加ください。

-ストレージ担当上級ソフトウェアエンジニア、Denis Serenyi
-ストレージ担当グループプロダクトマネージャー、Vivek Saraswat

AI ワークロード向けの高性能ストレージイノベーション

Thu, 24 Apr 2025 03:40:00 +0000

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

AI Hypercomputer の高性能ストレージスタックには、地理的なリージョン、ゾーン、GPU / TPU アーキテクチャから得られた学習結果が組み込まれ、アジャイルで経済的な統合ストレージアーキテクチャを実現しています。Google は最近、高性能ストレージでアクセラレータの使用率を改善することで費用とリソースを最適化し、AI ワークロードを加速させるために、いくつかのイノベーションを成し遂げました。

Rapid Storage: 新しい Cloud Storage ゾーンバケット。業界トップクラスである 1 ミリ秒未満のランダム読み取り / 書き込みレイテンシ、20 倍高速のデータアクセス、6 TB/秒のスループット、他の主要なハイパースケーラーと比較して 5 分の 1 のランダム読み取り / 書き込みレイテンシを実現します。
Anywhere Cache: 既存のリージョンバケットで動作する、強整合性のある新しいキャッシュ。選択したゾーン内でデータをキャッシュに保存します。Anywhere Cache はレイテンシを最大 70% および 2.5 TB/秒削減し、AI ワークロードを高速化します。また、データを GPU または TPU の近くに保持することで、グッドプットを最大化します。
Google Cloud Managed Lustre: DDN EXAScaler Lustre ファイルシステム上に構築された、新しい高性能なフルマネージド並列ファイルシステム。このゾーンストレージソリューションは、AI ワークロード向けに、PB 規模のストレージを提供し、1 ミリ秒未満のレイテンシ、数百万の IOPS、TB/秒のスループットを実現します。
Storage Intelligence : オブジェクトメタデータを大規模にクエリし、LLM の機能を活用することで、環境に固有のストレージ分析情報を生成する、業界初のソリューション。Storage Intelligence は、膨大なデータ資産に関する分析情報だけでなく、アクションを実行する機能も提供します。たとえば、バケットの再配置を使用して、アクセラレータとデータを、混乱を招くことなく同じ場所に配置できます。

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

Rapid Storage により、ミリ秒単位のレイテンシで AI ワークロードを実現

AI モデルを最大限の効率でトレーニングし、チェックポイントを作成して、提供するには、GPU または TPU をデータで飽和状態に保ち、コンピューティングの無駄を最小限に抑える必要があります（グッドプットで測定）。しかし、従来のオブジェクトストレージには、レイテンシという重大な制限があります。Rapid Storage は、Google の Colossus クラスタレベルのファイルシステムを使用して、新しいゾーンバケットにストレージと AI アクセラレータを共存させる新しいアプローチを提供します。また、Rapid Storage は Colossus を基盤としているため、アクセラレータとデータがそれぞれ別のゾーンにあることにより発生する、通常のリージョンストレージのレイテンシを回避できます。

リージョンの Cloud Storage バケットとは異なり、Rapid Storage ゾーンバケットは、GPU と TPU が実行されているゾーン内にデータを集中させ、ミリ秒未満の読み取り / 書き込みレイテンシと高スループットを実現します。実際、Rapid Storage は、他の主要なハイパースケーラーと比較して、ランダム読み取り / 書き込みのレイテンシを 5 分の 1 に短縮します。バケットあたり最大 6 TB/秒のスループットと最大 2,000 万の秒間クエリ数（QPS）を組み合わせることで、Rapid Storage を使用して、新たなレベルのパフォーマンスで AI モデルをトレーニングできるようになりました。

高いパフォーマンスを実現するために複雑さを増やすべきではないため、Cloud Storage FUSE を利用して Rapid Storage バケットをファイルシステムとしてマウントできます。これにより、TensorFlow や PyTorch などの一般的な AI フレームワークが、コードを変更することなくオブジェクトストレージにアクセスできるようになります。

Anywhere Cache は優先ゾーンにデータを配置

Anywhere Cache は、既存のストレージバケット（リージョン、マルチリージョン、デュアルリージョン）で動作する、強整合性のゾーン読み取りキャッシュです。選択したゾーン内でデータをインテリジェントにキャッシュします。その結果、Anywhere Cache により、ストレージの読み取りレイテンシが最大 70% 改善します。データを目的のゾーンに動的にキャッシュし、GPU や TPU の近くに配置することで、最大 2.5 TB/秒のパフォーマンスを実現し、複数のエポックトレーニング時間を最小限に抑えます。アクセラレータの可用性の変更など、状況が変化した場合、Anywhere Cache はデータが AI アクセラレータに付随するようにします。バケットやアプリケーションを変更することなく、ワンクリックで他のリージョンやゾーンで Anywhere Cache を有効にできます。さらに、キャッシュされたデータの下り（外向き）料金が不要になります。マルチリージョンバケットを使用している既存の Anywhere Cache のお客様の 70% が、費用面でのメリットを得ています。

Anthropic は、Anywhere Cache を活用して、単一のゾーンに TPU とデータを配置し、最大 6 TB/秒の動的にスケーラブルな読み取りスループットを提供することで、クラウドワークロードの復元力を向上させています。また、Storage Intelligence を使用して 850 億以上のオブジェクトに関する詳細な分析情報を取得し、ストレージインフラストラクチャを最適化しています。

Google Cloud Managed Lustre で HPC と AI のワークロードを高速化

AI ワークロードは、小さなファイルやランダム I/O にアクセスできますが、並列ファイルシステムのミリ秒未満のレイテンシが必要です。新しい Google Cloud Managed Lustre は、フルマネージドの並列ファイルシステムサービスです。完全に POSIX に対応しており、テラバイトからペタバイトまでスケールする永続ゾーンストレージとして利用できます。永続的な並列ファイルシステムである Managed Lustre を使用すると、トレーニング、チェックポイント、サービングデータを確実に保存できるだけでなく、高スループット、ミリ秒未満のレイテンシ、複数のジョブにわたる数百万の IOPS を実現しながら、グッドプットを最大化できます。全二重通信ネットワークの利用により、Managed Lustre は 20 GB/秒で VM を完全に飽和させ、最大 1 TB/秒の合計スループットを実現できます。また、Cloud Storage の一括インポート / エクスポート API に対応しているため、Cloud Storage との間でのデータセットの移動が簡単です。Managed Lustre は、DDN と連携して構築され、EXAScaler をベースにしています。

Storage Intelligence でデータを分析し、データに基づいた行動を起こす

AI モデルの質は、トレーニングに使用したデータの質に必ず比例します。このたび、新サービスの Storage Intelligence を発表しました。このサービスは、AI トレーニングに使用されるすべてのバケットのメタデータをクエリして適切なデータセットを見つけられるよう支援し、AI の費用最適化の取り組みを改善します。Storage Intelligence は LLM の力を活用してオブジェクトメタデータを大規模にクエリし、環境に固有のストレージ分析情報を生成します。クラウドハイパースケーラーが提供する初のストレージインテリジェンスサービスである Storage Intelligence を使用すれば、組織全体のバケットやプロジェクト内の数百万、数十億ものオブジェクトメタデータを分析できます。この分析から得られる情報を使用して、重複するオブジェクトの削除、オブジェクトのライフサイクル管理や Autoclass によって削除または下位のストレージクラスに移動できるオブジェクトの特定、会社のセキュリティポリシーに違反するオブジェクトの特定などに関して、情報に基づいた意思決定を行うことができます。

Google の Cloud Storage の Autoclass と Storage Intelligence の機能により、Spotify はストレージ費用を把握し、最適化できました。2024 年、Spotify はこれらの機能を活用して、ストレージ費用を 37% 削減しました。

AI ワークロード向けの高性能ストレージ

Google は、可用性、高スループット、低レイテンシ、耐久性のあるアーキテクチャを実現する高性能ストレージソリューションである Rapid Storage、Anywhere Cache、Managed Lustre を構築しました。Storage Intelligence は、ストレージエステートに関する、有益で行動につながるインサイトを提供します。

これらのイノベーションの詳細を知るには、Google Cloud Next '25 のブレイクアウトセッション「What’s new with Google Cloud’s Storage（Google Cloud のストレージに関する最新情報）」（BRK2-025）と「AI Hypercomputer: Mastering your Storage Infrastructure（AI Hypercomputer: ストレージインフラストラクチャをマスターする）」（BRK2-020）にご参加ください。

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

-ストレージ担当シニアディレクター兼 PM、Asad Khan

Colossus の舞台裏: HDD の価格で SSD のパフォーマンスを実現する方法

Wed, 23 Apr 2025 01:05:00 +0000

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

YouTube、Gmail から BigQuery、Cloud Storage まで、Google のほぼすべてのプロダクトは、基盤となる分散ストレージシステム Colossus に支えられています。Google のユニバーサルストレージプラットフォームである Colossus は、最高水準の並列ファイルシステムと同等以上のスループットを実現し、オブジェクトストレージシステムの管理とスケーリング、すべての Google チームが使用している使いやすいプログラミングモデルを備えています。さらに、スケーリング、コスト、スループット、レイテンシなど、非常に多様な要件を持つプロダクトのニーズに対応しながら、これらすべてを実現しています。

アプリケーション例	I/O サイズ	予想パフォーマンス
BigQuery のスキャン	数百 KB から数十 MB まで	TB/秒
Cloud Storage - Standard	数 KB から数十 MB まで	数百ミリ秒
Gmail のメール	数百 KB 未満	数十ミリ秒
Gmail の添付ファイル	数 KB から数 MB まで	数秒
Hyperdisk の読み取り	数 KB から数百 KB まで	1 ミリ秒未満
YouTube 動画のストレージ	数 MB	数秒

Colossus の柔軟性は、一般提供されている多くの Google Cloud プロダクトに現れています。Hyperdisk ML は Colossus ソリッドステートディスク（SSD）を利用し、2,500 ノードによる 1.2 TB/秒の読み取りを可能にすることで、高いスケーラビリティを実現しています。Spanner は Colossus を活用し、同一のファイルシステム上で安価な HDD ストレージと超高速の SSD ストレージを連携させることで、階層型ストレージ機能の基盤としての役割を果たしています。Cloud Storage は Colossus の SSD キャッシュを利用することで、最も安価なストレージを提供しつつ、高負荷な AI / ML アプリケーションの集中的な I/O にも対応しています。さらに、Colossus を基盤とした BigQuery のストレージは、超大規模クエリに対して超高速な I/O を実現しています。

以前に Colossus について投稿して以来しばらく経ちましたが、今回はその機能が Google Cloud の変化の絶えないビジネスをどう支えているか、特に SSD への対応に関する新たな機能についてご紹介したいと思います。

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

Colossus の背景

まずは Colossus の背景について簡単にご紹介します。

Colossus は Google File System（GFS）を進化させたものです。
従来の Colossus ファイルシステムは、単一のデータセンター内で運用されていました。
Colossus は、GFS のプログラミングモデルを簡素化し、ファイルシステムの使い慣れたプログラミングインターフェースとオブジェクトストレージのスケーラビリティを兼ね備えた、追加専用のストレージシステムに進化させました。
Colossus のメタデータサービスは、ファイルの作成や削除などのインタラクティブな管理操作を担当する「キュレーター」と、データの耐久性と可用性、ディスク容量のバランスを維持する「カストディアン」で構成されています。
Colossus のクライアントは、メタデータについてキュレーターとやり取りし、その後、HDD または SSD をホストする「D サーバー」にデータを直接保存します。

Colossus がゾーン単位のプロダクトであることも重要なポイントです。Colossus ファイルシステムはクラスタごとに 1 つ構築しています。クラスタは Google Cloud ゾーン内の基本構成要素です。ほとんどのデータセンターには、クラスタ内で実行されるワークロード数に関係なく、1 つのクラスタ、つまり 1 つの Colossus ファイルシステムが存在します。Colossus ファイルシステムの多くは数エクサバイト規模のストレージを持ち、その中には 10 エクサバイトを超えるものが 2 つも存在します。このように大規模なスケーリングが可能であるため、最も要求の厳しいアプリケーションであっても、ゾーン内のクラスタコンピューティングリソースの近くでディスク容量が不足することはありません。

こうした高負荷のアプリケーションは、大量の IOPS とスループットも必要とします。実際、Google 最大級のファイルシステムの中には、読み取りスループットが 50 TB/秒、書き込みスループットが 25 TB/秒を超えるものもあります。これは、8K の長編映画を 1 秒間に 100 本以上送信できるほどのスループットです。

また、Colossus は大規模なストリーミング I/O だけに使われているわけではありません。多くのアプリケーションでは、小さなログの追記や小規模なランダム読み取りを行っています。最も高負荷な単一クラスタでは、読み書きを合わせて 6 億 IOPS を超える性能を発揮しています。

もちろん、こうした高パフォーマンスを実現するには、適切なデータを適切な場所に配置する必要があります。すべてのデータが低速のディスクドライブに置かれていては、50 TB/秒で読み取るのは困難です。そこで登場するのが、Colossus における 2 つの重要な新機能、SSD キャッシュと SSD データ配置です。どちらも「L4」と呼ばれるシステムによって実現されています。

Colossus SSD 配置の最新情報

以前の Colossus に関するブログ投稿では、最もホットなデータを SSD に配置し、残りのデータをクラスタ内のすべてのデバイスに分散する方法について説明しました。SSD の価格が年々下がり、データセンターでの存在感が増している現在では、この考え方はますます重要になっています。いまどき、HDD だけで構成されたシステムを設計に組み込むストレージ設計者はいないでしょう。

ただし、SSD のみのストレージは、今でも SSD と HDD が混在したストレージフリートよりも大幅に費用が高くなります。課題は、データの大部分を HDD に保持しながら、適切なデータ（I/O が特に多いデータや、特に低いレイテンシを必要とするデータ）を SSD に配置することです。

これを踏まえ、Colossus が最もホットなデータをどのように特定するかを見てみましょう。

Colossus には、SSD に配置するデータを選択する方法がいくつかあります。

データを SSD に配置するようシステムに強制する: この方法では、内部の Colossus ユーザーの操作により、データを SSD に配置するよう強制します。ユーザーは、/cns/ex/home/leg/partition=ssd/myfile というパスを使用してこれを実行できます。これは最も簡単な方法であり、ファイルが SSD に完全に保存されます。同時に、最も費用のかかるオプションでもあります。
ハイブリッド配置を活用する: より高度なユーザーは、「ハイブリッド配置」を活用して、SSD に 1 つのレプリカのみを配置するよう Colossus システムに指示できます（/cns/ex/home/leg/partition=ssd.1/myfile）。これはより手頃なアプローチですが、SSD コピーを持つ D サーバーが利用できない場合、HDD のレイテンシによってアクセスが遅くなります。
L4 を使用する: Google では、データの大半においてほとんどの開発者が新しい L4 分散 SSD キャッシュテクノロジーを使用しており、このテクノロジーが SSD に最適なデータを動的に選択しています。

L4 読み取りキャッシュ

L4 分散 SSD キャッシュは、アプリケーションのアクセスパターンを分析し、SSD に最も適したデータを自動的に配置します。

読み取りキャッシュとして機能する場合、L4 インデックスサーバーが分散型の読み取りキャッシュを管理します。

つまり、アプリケーションがデータを読み取る際には、まず L4 インデックスサーバーに問い合わせます。そのインデックスは、対象のデータがキャッシュにあるかどうかをクライアントに伝えます。キャッシュにある場合は、クライアントは 1 つ以上の SSD からデータを読み取り、なければキャッシュミスと判断して、Colossus がデータを配置しているディスクからデータを取得します。

キャッシュミスが発生した場合は、アクセスされたデータを SSD キャッシュに挿入することを L4 が決定できます。その際には、データを HDD サーバーから転送するよう SSD ストレージサーバーに伝えます。キャッシュがいっぱいになると、L4 はキャッシュから一部の項目を削除し、新たに挿入するための容量を空けます。

L4 は、SSD にどの程度データを配置するかについて、より積極的または控えめな方針を取ることができます。ワークロードごとに、書き込み時、初回読み取り後、または短時間内の 2 回目の読み取り後のいずれかのタイミングで L4 キャッシュに挿入するといったポリシーを、ML ベースのアルゴリズムで決定しています。その仕組みの詳細については、CacheSack に関する論文をご覧ください。

このアプローチは、同じデータを頻繁に読み取るアプリケーションに適しており、IOPS とスループットを大幅に向上させました。ただし、大きな弱点もあります。新しいデータは依然として HDD に書き込まれているのです。また、L4 読み取りキャッシュが思ったほどリソースの節約につながらない重要な種類のデータも存在することがわかっています。たとえば、大規模なバッチ処理ジョブの中間結果のように、書き込み、読み取り、削除が短時間で行われるデータや、データベーストランザクションログなど多数の小さな追記が発生するファイルがその例です。これらのワークロードはいずれも HDD に不向きであるため、SSD に直接書き込み、HDD を経由しないことが推奨されます。

Colossus の L4 ライトバック

ある内部の Colossus ユーザーが、データの一部を SSD に配置したいと考えているとしましょう。その場合、どのファイルを SSD に保存するか、そしてワークロードにどれだけの SSD 割り当てを購入すべきかを慎重に見極める必要があります。また、アクセスされなくなった古いファイルがある場合は、そのデータを SSD から HDD に移行したほうがよいかもしれません。しかし、実際のユーザーの使い方を見ていると、こうした判断がいかに難しいかがよくわかります。この作業を支援するために、Google は L4 サービスを強化して作業を自動化しました。

ライトバックキャッシュとして使用される場合、L4 サービスは、新しいファイルを SSD に配置するかどうか、また配置する期間はどのくらいかについて Colossus キュレーターにアドバイスします。これは、なかなか厄介な課題です。ファイルの作成時に Colossus が確認できるのは、ファイルを作成しているアプリケーションとファイル名のみです。ファイルがどのように使用されるかはわかりません。

この問題を解決するために、前述の CacheSack の論文で説明されている L4 読み取りキャッシュと同じアプローチを使用します。アプリケーションは、ファイル形式や、データが保存されているデータベース列に関するメタデータなどの特徴を L4 に渡します。L4 はこれらの特徴を使用してファイルを「カテゴリ」に分類し、各カテゴリの I/O パターンを経時的に観察します。これらの I/O パターンに基づいて、「1 時間だけ SSD に置く」、「2 時間 SSD に置く」、「SSD に置かない」といった複数の配置ポリシーをオンラインでシミュレーションします。そして L4 は、その結果に基づき、各カテゴリに最適なポリシーを選択します。

これらのオンラインシミュレーションには、もう 1 つの重要な目的があります。それは、SSD 容量が増減した場合に、L4 がどの配置を選択するかを予測することです。これにより、SSD の容量に応じて、HDD からどの程度の I/O をオフロードできるかを予測できます。こうしたシグナルは、新たな SSD ハードウェアの購入判断に役立つだけでなく、SSD 容量をアプリケーション間で柔軟に再配分し、効率を最大化するための指針としても活用されます。

指示があれば、キュレーターは新しいファイルをデフォルトの HDD ではなく SSD に転送できます。一定時間が経過してもファイルがまだ存在する場合、キュレーターはデータを SSD から HDD に移行します。

L4 システムのシミュレーションがファイルアクセスパターンを正確に予測すると、データのごく一部を SSD に配置するだけで、新規作成されたファイルに集中しがちな読み取り要求の大半を吸収できます。その後、データをより安価なストレージに移行することで、全体のコストを抑えられます。最良のシナリオでは、HDD に移行する前にファイルが削除され、HDD の I/O がすべて回避されます。

Colossus SSD と Google Cloud

Colossus は、Google および Google Cloud 全体を支える基盤であり、数十億のユーザーに信頼性の高いサービスを提供するうえで欠かせないものです。その高度な SSD 配置機能により、ワークロードの変化に自動的に適応しつつ、コストを抑えながら高いパフォーマンスを実現しています。

Google の最終的な目標は、HDD や SSD、そして Colossus の複雑な仕組みに精通していないエンドユーザーであっても、ストレージの効率性とパフォーマンスを最大限に引き出せる環境を提供することにあります。Google は、これまでに築いてきたこのシステムに誇りを持っています。そして今後も、さらなるスケーリング、洗練性、パフォーマンスの向上に取り組み続けていきます。詳しくは、Google Cloud Next ‘25 のブレイクアウトセッション「What’s new with Google Cloud’s Storage（Google Cloud のストレージに関する最新情報）」（BRK2-025）と「AI Hypercomputer: Mastering your Storage Infrastructure（AI Hypercomputer: ストレージインフラストラクチャをマスターする）」（BRK2-020）にご参加ください。

-ストレージテクニカルリーダー Larry Greenfield
-ストレージ担当ソフトウェアエンジニア Seth Pollen