管理ツール

Unified Maintenance: Google Cloud 全体のメンテナンスを管理するための新たな統合ソリューション

Wed, 11 Mar 2026 01:00:00 +0000

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

ビジネスの継続性とアプリケーションのパフォーマンスを確保するうえで、定期メンテナンスの管理は不可欠です。しかし、使用するクラウドサービスの増加に応じて、メンテナンススケジュールの把握が複雑になり、時間がかかるようになる可能性があります。現在の各種アプローチでは、通知の一貫性がなく、プロダクトごとに制御レベルが異なることがよくあります。そこで Google Cloud は、お客様がメンテナンス期間を見逃して業務の中断を発生させることがないよう、Google Cloud サービス全体のメンテナンスイベントを表示および管理できる一元化されたダッシュボード「Unified Maintenance」の一般提供を開始いたしました。

Unified Maintenance では、メンテナンスの更新情報が 1 つのビューに統合されるため、予定されているイベントを簡単に追跡できます。Unified Maintenance の機能は次のとおりです。

定期メンテナンスの表示: Compute Engine、Google Kubernetes Engine（GKE）、Cloud SQL、Memorystore、AlloyDB、Looker などのサービスのイベントを 1 つのダッシュボードで確認できます（サポート対象サービスを参照）。
アラートの標準化: Cloud Logging から一貫したメンテナンス情報を取得できるため、アラートを設定して、既存のモニタリングシステムやチケット発行システムに統合できます。
制御できるイベントの把握: ダッシュボードで、ユーザーが制御できるメンテナンスイベントを明確に把握できます。

次のステップ

Google Cloud は、より多くの Google Cloud サービス向けのサポートを追加し、プラットフォームの機能を強化できるよう尽力しています。ロードマップには、フォルダおよび組織のスコープの拡大と、アプリケーションレベルの可視化が含まれています。

Google Cloud コンソールで直接 Unified Maintenance ダッシュボードにアクセスして、サブスクリプションサービスで予定されているイベントを確認できます。これらの新機能の使用方法について詳しくは、ドキュメントとスタートガイドをご覧ください。

- プロダクトマネージャー、Erol-Valeriu Chioasca

広範な OTLP 対応に向けて: Cloud Monitoring が OpenTelemetry Protocol 指標をサポート

Wed, 18 Feb 2026 02:00:00 +0000

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

Google Cloud は、オープン標準への取り組みの一環として、OpenTelemetry をテレメトリーデータ用のユニバーサルクライアント、データ形式、標準セットとするために尽力しています。

昨年は、Cloud Observability が OpenTelemetry Protocol（OTLP）を使用したトレースの送信に対応したことを発表いたしました。そして今回、あらゆるソリューションで OpenTelemetry を活用できるようにするという目標に向けた次のステップとして、Cloud Observability における Cloud Monitoring の指標向け OTLP への対応を発表いたしました。

指標向け OTLP: 「新標準」以上の意味

OpenTelemetry と OTLP を使用すると、プロバイダに完全に依存しないパイプラインで指標データを生成して Google Cloud に送信できます。OpenTelemetry SDK を使用して OTLP 指標を作成し、OpenTelemetry コレクタを使用して収集、変換してから、そのデータを OpenTelemetry 形式で Cloud Monitoring に直接送信できます。

デフォルトでは、このデータは Managed Service for Prometheus のデータと同じ形式で保存され、費用も同様に低く抑えることができます。このデータは、Cloud Monitoring の他のデータをクエリする場合と同じインターフェースを使用してクエリできます。

OTLP を使用すると、次のような新機能も利用できます。これらは、お客様からのご要望の多かった機能です。

デルタタイプの指標: 前回のエクスポートから今回のエクスポートまでの間にモノトニックカウンタで変化した量を送信します。メモリ内のすべてのカウンタをトラッキングして、常にカウンタの最新の値を送信することはありません。これにより、クライアントはエクスポートの合間にメモリをフラッシュできるため、クライアントサイドのリソース消費が大幅に削減され、有効期間が短い、または増分が少ない時系列データをより適切に収集できるようになります。
指数（動的）ヒストグラム: 従来のヒストグラムでは、予測されるデータの分布に基づいてバケット幅を明示的に設定する必要があります。その予測が実際のデータ分布と一致しない場合、すべての観測結果が少数の低バケットにまとめられたり、注目すべき観測結果が「無限より低い」バケットに入れられて情報の精度が下がったりする可能性があります。これに対して、OpenTelemetry の指数ヒストグラムでは、実際に確認された値の範囲に基づいてバケットの境界が動的に変更されるため、ヒストグラムのバケットを推測して確認する必要がなくなります。一度設定すれば、後は自動で処理されます。
指標名のドットとスラッシュ、ラベルキーのドット: Cloud Monitoring で、PromQL を使用した URL スタイルの名前のクエリに完全対応いたしました。さらに、Cloud Monitoring のラベルキーで . 文字も使用できるようになりました。これにより、OpenTelemetry のセマンティック規約に対応できます。
SDK から Cloud Monitoring へのコレクタ不要の指標の直接送信: Pod 間および Service 間のトラフィックを報告する Envoy やお客様が実行するロードバランサプロセスなど、非常に大量でカーディナリティの高い指標ソースの場合、パイプラインに OpenTelemetry コレクタを配置すると、費用が非常に高くなる可能性があります。コレクタは、指標の量が多すぎる場合に過負荷になる傾向があり、コレクタを水平方向または垂直方向にスケールするには、デベロッパーが多くの作業を行う必要があります。OTLP を使用すると、OpenTelemetry SDK によってエクスポートされた指標を Cloud Observability の指標用 Telemetry API に直接ポイントできるため、中間プロセスを自分で実行してスケールする必要がなく、Google にボリュームの処理を任せることができます。
指標とトレースのゼロコード自動計測: OpenTelemetry を使用して互換性のあるワークロードを自動的に計測し、コードを使用せずに標準化されたトレースとゴールデンシグナル指標を生成してから、データを OTLP 形式で Cloud Observability に送信できます。ゴールデンシグナルの指標を取得するために、アプリケーションコードと計測のコードを混在させる必要はなくなりました。ただし、コード内のすべての RPC を忘れずに一貫して計測する必要があります。

Google Kubernetes Engine 向けマネージド OpenTelemetry

OpenTelemetry コレクタを自分で実行しようとすると、手動でデプロイ、構成、スケールする必要があるため、多くの手間がかかります。しかし、一般的なオブザーバビリティプロファイルの一般的なワークロードの場合、通常は、OTLP シグナルを受信して拡充するためのシンプルなクラスタ内エンドポイントがあれば十分です。

そこで、Google は GKE 用マネージド OpenTelemetry も導入することにしました。これは、Google Kubernetes Engine で OTLP トレース、指標、ログを生成および収集するためのフルマネージドの「ワンクリック」パイプラインです。Google がコレクタのライフサイクル、アップグレード、スケーリングを処理するため、デベロッパーはオブザーバビリティインフラストラクチャではなくアプリケーションコードに集中できます。

マネージド OpenTelemetry は、GKE 向けの初のフルマネージドトレースソリューションです。トレースはアプリケーションのパフォーマンスモニタリングに不可欠であり、アプリケーションの依存関係の動的かつ実用的なビューであるアプリケーショントポロジマップなどの機能の基盤となります。

また、GKE 用マネージド OpenTelemetry を使用すると、OpenTelemetry SDK を使用するワークロードを自動的に構成および計測することもできます。1 つのカスタムリソースで、Agent Development Kit（ADK）といった OpenTelemetry をサポートするフレームワークで構築された AI エージェントなど、OpenTelemetry 対応のアプリケーションすべてのゴールデンシグナルを Cloud Observability で取得できます。

ご利用方法

指標向け OTLP は現在プレビュー版で、すべてのお客様にご利用いただけます。ただし、OpenTelemetry バージョン 0.140.0 以降を使用する必要があります。OpenTelemetry SDK または OpenTelemetry コレクタを使用した OTLP 指標の利用を開始する場合は、OTLP 指標取り込みに関するドキュメントをご覧ください。独自のコレクタを実行する場合は、可能であれば Google が構築した OpenTelemetry コレクタを使用することをおすすめします。

GKE 用マネージド OpenTelemetry は現在プレビュー版で、すべてのお客様にご利用いただけます。ただし、GKE クラスタバージョン 1.34.1-gke.2178000 以降、gcloud CLI バージョン 551.0.0 以降を使用する必要があります。ご利用にあたっては、GKE 用マネージド OpenTelemetry のドキュメントをご覧ください。

最後に、セルフデプロイされた OpenTelemetry コレクタを使用して GKE 上の Java ワークロードのゼロコード自動計測を開始する場合は、ゼロコードに関するドキュメントをご覧ください。

- シニアプロダクトマネージャー、Lee Yanco

- シニアプロダクトマネージャー、James Maffey

Google の ADK を使ったエージェントアプリケーションを Datadog LLM Observability でモニタリングする

Mon, 02 Feb 2026 03:00:00 +0000

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

Google の Agent Development Kit（ADK）は、強力なエージェントシステムを構築するための基盤を提供します。こうした複数ステップのエージェントは、計画を立て、ループ処理を行い、協調し、必要に応じてツールを動的に呼び出しながら、自律的に問題を解決できます。一方で、この柔軟性は予測しにくさにもつながり、出力の欠落、想定外のコスト、セキュリティリスクといった問題を招く可能性があります。こうした複雑さを管理できるよう、Datadog LLM Observability は ADK で構築されたシステムに対する自動計測を提供するようになりました。この統合により、エージェントの挙動を可視化してモニタリングし、コストやエラーを追跡できるほか、大がかりな手動設定を行うことなく、オフライン実験とオンライン評価を通じて、応答品質と安全性の観点からエージェントを最適化できます。

これは重要な点です。エージェントシステムは複雑で、エージェント同士の相互作用に加え、LLM の非決定性によって、応答を事前に予測することが難しいためです。

こうしたエージェントを運用する際に一般的に想定されるリスクには、次のようなものがあります。

変化のスピード: 新しい基盤モデルは毎週のように登場し、「ベストプラクティス」とされるプロンプト設計のパターンも同じくらいの速さで変化します。そのため、チームは新しい組み合わせを継続的に評価する必要があります。
マルチエージェント間の受け渡し: あるエージェントが低品質な出力を生成すると、その影響がダウンストリームに連鎖し、他のエージェントが誤った判断を下す原因となる可能性があります。
ループとリトライ: プランナーが同じツール呼び出しに固執してしまい、検索クエリを無限に再試行するなど、ループに陥ることがあります。これにより、レイテンシの急増を招くおそれがあります。
見えにくいコスト: プランナーのステップが 1 つでも誤ってルーティングされるだけで、トークン使用量や API 呼び出し回数が増幅し、コストが予算を超過する可能性があります。
安全性と正確性: LLM の応答には、ハルシネーション、機密データの混入、プロンプトインジェクションの試みなどが含まれる場合があり、セキュリティインシデントや顧客からの信頼低下につながるリスクがあります。

最後に、ADK は市場に存在する数多くのエージェントフレームワークの一つにすぎません。これを手作業でインストルメンテーション（計測の仕込み）しなければならないとなると、すでに煩雑でエラーが発生しやすいプロセスに、さらに学習コストが上乗せされることになります。

エージェントの判断と予期しない挙動をトレース

Datadog LLM Observability は、ADK エージェントを自動的に計測およびトレースすることで、こうした課題に対応します。コードを変更することなく、数分でエージェントをオフラインで評価し、本番環境でモニタリングを開始できます。これにより、エージェントのオーケストレーションからツール呼び出しに至るまで、すべてのステップやプランナーの判断を単一のトレースタイムライン上で可視化できます。

たとえば、エージェントがユーザーのクエリに応答する際に誤ったツールを選択した場合、想定外のエラーや不正確な応答につながることがあります。Datadog の可視化機能を使えば、どのステップで誤ったツールが選択されたのかを正確に特定できるため、トラブルシューティングが容易になり、問題の再現や原因の特定にも役立ちます。

トークン使用量とレイテンシをモニタリング

レイテンシやコストの急激な増加は、エージェントアプリケーションに問題が生じている兆候であることが少なくありません。Datadog では、ツール、ブランチ、ワークフローごとにトークン使用量とレイテンシを可視化できるため、どこでエラーが発生し、それがダウンストリームの処理にどのような影響を及ぼしたのかを明確に把握できます。

たとえば、プランナーエージェントが要約ツールを 5 回も再試行した場合、レイテンシは大幅に増加します。Datadog はこうしたループを強調表示し、処理に要した正確な時間とそれに伴うコストへの影響を可視化します。

エージェントの応答品質とセキュリティを評価

レイテンシのような運用パフォーマンス指標は重要なモニタリングシグナルですが、エージェントアプリケーションの動作状況を包括的に把握するには、LLM やエージェントの応答が持つ意味的な品質についても評価する必要があります。Datadog には、ハルシネーション、個人を特定できる情報（PII）の漏えい、プロンプトインジェクション、不適切または危険な応答を検出するための組み込み評価機能が用意されています。

さらに、ドメイン固有のチェックを行うために、LLM-as-a-judge 型の評価ツールを含むカスタム評価ツールを追加することも可能です。たとえば、検索エージェントが無関係なドキュメントを取得し、その結果として回答が話題から逸れてしまった場合、カスタム評価ツールによって、そのトレースを「検索関連性が低い」と判定できます。

テストを通じて、迅速かつ確信を持って改善を重ねる

新しいシステムプロンプトを展開すると、レイテンシの急増や出力の一貫性の低下に気付くことがあります。Datadog では、本番環境の LLM 呼び出しを Playground 上で再生し、異なるモデル、プロンプト、パラメータを試すことで、理想とする挙動に近づく構成を見つけることができます。

さらに、実際のトラフィックから構築したデータセットを用いて、複数のバージョンを並べて比較する構造化されたテストを実行し、運用面および機能面のパフォーマンスを最適化できます。ADK のインストルメンテーションによってすべてのエージェントステップが記録されるため、デプロイ前に回帰を再現し、修正内容を検証するために必要となる完全なコンテキストを把握できます。

Datadog LLM Observability を使ってみる

Datadog LLM Observability は、Google ADK を利用したシステムのモニタリングとデバッグを簡素化し、エージェントの動作を把握しやすくします。これにより、エージェントの挙動を解析し、応答を評価し、迅速に改善を重ねながら、本番環境にデプロイする前に変更内容を検証できます。

最新バージョンの LLM Observability SDK を使って、今すぐ利用を開始できます。Datadog を初めて利用する方は、無料トライアルから始めることも可能です。

エージェントの挙動を解析し、応答を評価する方法について詳しくは、Datadog の LLM Observability ドキュメントをご覧ください。

-Google、シニア戦略的パートナーシップ担当マネージャー、Abhi Das

-Datadog、プロダクトマーケティングマネージャー、Trammell Saltzgaber 氏

VM OS エージェントの大規模な管理を簡素化: VM Extensions Manager のご紹介

Tue, 20 Jan 2026 01:00:00 +0000

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

IT 管理者であれば、大規模な VM インスタンスフリート全体でオペレーティングシステム（OS）エージェント（Google で拡張機能と呼んでいる機能）を管理するのが複雑で面倒な作業であることをご存じでしょう。実際、拡張機能によって強力なアプリケーションレベルの機能が利用可能になるにもかかわらず、VM フリートで拡張機能ベースのサービスを採用する際にこの運用オーバーヘッドが大きな障壁となる可能性があります。

この問題を解決するため、Google は VM Extensions Manager のプレビュー版を発表しました。これは、Compute Engine API に直接統合された新しい機能で、Google 提供の拡張機能のインストールと管理を簡素化するものです。

VM Extensions Manager はポリシー主導型の一元化されたフレームワークを採用しており、VM インスタンス上の Google Cloud 拡張機能のライフサイクル全体を管理できます。手動スクリプト、起動スクリプト、その他のカスタムソリューションに頼る代わりに、ポリシーを定義することで、既存か新規かにかかわらず、すべての VM インスタンスがポリシーに準拠するように管理可能になります。これにより、運用オーバーヘッドを数か月から数時間に短縮できます。

VM Extensions Manager の使用を開始する方法

VM Extensions Manager は compute.googleapis.com API に直接統合されているため、新しい API を検出したり有効にしたりする必要はなく、数分で使い始めることができます。

1. 拡張機能ポリシーを定義するまず、拡張機能の望ましい状態を指定するポリシーを定義します。

プレビュー版では、プロジェクトレベルでゾーンポリシーを作成できます。このポリシーは、単一の特定のゾーン内にある VM インスタンスを対象とします。

今後数か月以内に、グローバルポリシーと、組織レベルおよびフォルダレベルのポリシーもサポート対象に追加される予定です。これにより、優先順位を使用して柔軟なポリシー階層を構築し、単一のコントロールプレーンから企業フリートの拡張機能を管理できるようになります。

このポリシーは、Google Cloud コンソールから直接作成できます。

Cloud コンソールを使用して VM 拡張機能のポリシーを作成するデモ

2. 拡張機能を選択するポリシーで、管理する Google Cloud 拡張機能を選択します。プレビュー版の VM Extensions Manager では、次のような重要な Google Cloud 拡張機能がサポートされています。

Cloud Ops エージェント（ops-agent）: Compute Engine インスタンスからテレメトリーを収集する主要エージェントです。
SAP 用エージェント（sap-extension）: Google Cloud の SAP 用エージェントは、Compute Engine インスタンスと Bare Metal Solution サーバーで実行される SAP ワークロードのサポートとモニタリングのために Google Cloud が提供しているエージェントです。
コンピューティングワークロード用エージェント（workload-extension）: Compute Engine で実行されているワークロードをモニタリングして評価するために使用できるエージェントです。

今後数か月以内に、拡張機能ベースのサービスがさらに追加される予定です。

拡張機能の特定のバージョンを指定するか、空のまま（デフォルト）にして最新の拡張機能をインストールできます。デフォルトを選択した場合、新しいバージョンのリリースを VM Extensions Manager が自動的に処理するため、ユーザーはすぐに新機能や改善機能にアクセスできます。

3. グローバルポリシーをより細かく制御してロールアウトVM Extensions Manager では、ロールアウトの速度を設定して、グローバルポリシーの変更を複数のゾーンにわたってどのようにデプロイするかを制御することが可能です。ゾーンポリシーではロールアウト速度を設定できず、VM がオンラインになると瞬時に適用されます。

今後数週間以内に、まず gcloud を介してグローバルポリシーのサポートを拡大し、関連情報をドキュメントに反映する予定です。UI の更新は今後数か月以内に行われます。

プレビュー版では、グローバルポリシーで設定するロールアウト速度として次の 2 つから選択可能です。

SLOW（推奨）: 安全性を重視したデフォルトのオプションです。このオプションでは、Wave 間の組み込みの待ち時間を使用して、ゾーンごとのロールアウト（ポリシーの範囲内）をオーケストレートします。これにより、問題のある変更の潜在的な影響範囲を一定期間（デフォルトでは 5 日間）最小限に抑えます。このオプションは標準的なメンテナンスと更新に最適です。
FAST: このオプションでは、Wave 間の待ち時間がなくなり、ゾーンをまたぐフリート全体で変更が可能な限り迅速に行われます。これは、すべてのゾーンのすべての VM に、非常時特権アクセスを必要とする「ブレークグラス」緊急シナリオで重要なセキュリティパッチをデプロイするなど、緊急のユースケースを対象としています。

ポリシーを保存すると、VM Extensions Manager に処理が引き継がれます。基盤となるプログレッシブロールアウトエンジンによって複雑なオーケストレーションが管理され、その進行状況をモニタリングできます。

標準化と管理のための柔軟なシステム

VM Extensions Manager は、VM フリートの拡張機能を標準化し、制御できるように設計されています。今すぐプロジェクトにゾーンポリシーを適用して、拡張機能が正しいゾーンの VM インスタンスに正しくインストールされるようにしましょう。

Compute Engine VM インスタンスの拡張機能ポリシーの定義を開始するには、ドキュメントを読んで最初のポリシーを作成してください。VM フリートの管理を標準化、保護、簡素化するために VM Extension Manager をご活用いただけますと幸いです。

- プロダクトマネージャー Omkar Suram

- CE ディレクター、北米プラットフォームスペシャリスト Mike Columbus

Workload Manager を使用して FinOps の費用管理ポリシーを自動化する

Thu, 27 Nov 2025 01:02:00 +0000

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

クラウドの請求額が予想外に高くてお困りではありませんか？戦略的な財務計画よりも、タグ付けされていないリソースの追跡や開発チームの確認により多くの時間を費やしていますか？クラウドの世界は変化が速く、手動での費用管理では対応が難しくなります。このアプローチは時間がかかるうえにエラーが発生しやすく、費用の異常を特定したときには、影響が広がっている場合が多くなります。

財務管理ポリシーをコード化し、Google Cloud 組織全体でその適用を自動化できたらどうでしょうか。そこで登場するのが Workload Manager（WLM）です。これは、独自のカスタム定義の FinOps ルールを含む、セキュリティとコンプライアンスに関するベストプラクティスに照らして、クラウドワークロードの検証を自動化できる強力なツールです。さらに、最近では特定のシナリオで Workload Manager の使用料金が最大 95% 削減され、小規模な無料枠を利用して小規模なテストを実行できるほか、大規模なスキャンをより経済的に実行できるようになりました。このブログでは、Workload Manager で自動化された財務管理ポリシーを使い始める方法をご紹介します。これにより、後手に回ることなく、クラウド費用の管理をプロアクティブに行えるようになります。

手動 FinOps の課題

クラウドでビジネスクリティカルなワークロードを管理するのは複雑です。費用管理のベストプラクティスを常に把握するには、多大な時間と労力がかかります。手動によるレビューと監査には数週間、場合によっては数か月かかることもあり、その間に費用が膨らむ可能性があります。このような手動のアプローチは、システムが確立された費用管理ポリシーから逸脱する「構成のずれ」につながることが多く、支出の検出と管理が困難になります。

Workload Manager は、自動化された継続的検証のためのフレームワークを提供することで、こうした手動による制約から脱却し、FinOps チームが次のことを行えるようにします。

標準化の改善: チームの依存関係を切り離し、組織全体で費用管理ポリシーを一貫して適用できるようにします。
オーナーシップの有効化: 個々のチームが特定のユースケースに合わせて独自の検出ルールを構築、管理できるようにすることで、財務説明責任の文化を育みます。
監査の簡素化: 組織全体でインフラストラクチャのチェックを簡単に実行し、結果を単一の BigQuery データセットに統合して、レポート作成と分析を合理化します。

FinOps ポリシーをコード化することにより、ポリシーを一度定義するだけで、定期的なスケジュールでクラウド環境全体を継続的にスキャンして違反を検出できます。

Workload Manager を使用すると、セキュリティ、費用、信頼性などについて、すぐに使用可能なルールが提供されるため、この作業が簡単になります。Workload Manager で自動化できる FinOps の費用管理ポリシーの例をいくつかご紹介します。

特定の Google Cloud リソース（BigQuery データセットなど）に必要なラベルまたはタグが設定されている必要がある
すべての Cloud Storage バケットにライフサイクル管理または Autoclass 構成を適用する
ストレージ（BigQuery テーブルなど）に適切なデータ保持が設定されていることを確認する
同時マルチスレッディングを無効にしてライセンス費用を最適化する（例: SQL Server）

図 1: Google Cloud のベストプラクティスに準拠した Workload Manager のデフォルトポリシー

お探しの情報が見つからない場合は、Git リポジトリの例を使用して、独自のカスタムポリシーをいつでも構築できます。

では、詳しく見ていきましょう。

FinOps ポリシーの自動化: 手順ガイド

Workload Manager を使用して費用管理ポリシーを自動化する方法は次のとおりです。

ステップ 1: FinOps ルールを定義し、新しい評価を作成する

まず、費用管理ポリシーを Workload Manager が理解できる形式に変換する必要があります。このツールは、カスタムルールの定義に Open Policy Agent（OPA）Rego を使用します。このブログでは、FinOps の主なユースケースである、費用の割り当てとショーバックのために、リソースに適切なラベルを付ける方法について説明します。

Google Cloud のベストプラクティスに従って FinOps、信頼性、セキュリティ、運用をカバーする、Google Cloud のエキスパートが作成した数百もの事前定義ルールから選択できます。また、独自のルールを作成してカスタマイズすることもできます（Google Cloud GitHub リポジトリの例をご覧ください）。この例では、データセットの bigquery-missing-labels に対して、事前定義された「Google Cloud のベストプラクティス」ルールの一つを使用します。ここでは、Google Cloud コンソールの Workload Manager セクションに移動し、新しい評価を作成することから始めます。

評価に名前を付け、ワークロードタイプとして [カスタム] を選択します。カスタムの FinOps ルールを作成した場合は、そのルールが含まれている Cloud Storage バケットを Workload Manager に指定できます。この機能を使用すると、事前定義されたルールチェックとカスタムルールチェックの両方を 1 回の評価で実行できます。

図 2 - 新しい評価ルールの作成

ステップ 2: スキャンのスコープを定義する

次に、評価のスコープを定義します。Google Cloud 組織全体、特定のフォルダ、または個々のプロジェクトを柔軟にスキャンできます。これにより、組織全体にわたって広範な費用管理ポリシーを適用したり、特定のチームや環境向けに、より的を絞ったルールを作成したりできます。リソースラベルや名前を基にフィルタを適用して、より細かく制御することもできます。この例では、リージョンを選択することで、データの所在地要件を満たすためにデータを処理する場所を選択できます。

図 3: 評価ルールのスコープとロケーションの選択

ステップ 3: スケジューリングと通知

FinOps では、自動化が鍵となります。評価は、1 時間ごとから 1 か月ごとまで、特定の周期で実行するようにスケジューリングできます。これにより、継続的なモニタリングが行われ、ポリシーコンプライアンスの履歴レコードが提供されます。評価を構成して、すべての結果を BigQuery データセットに保存し、履歴分析とレポート作成を行います。この操作は省略できますが、FinOps では行うことを強くおすすめします。

また、問題が発見されたときに適切なチームにアラートを発するよう設定することもできます。メール、Slack、PagerDuty などのチャネルで通知を受け取れるため、ポリシー違反に迅速に対処できます。

図 4: 評価ルールのエクスポート、スケジューリング、通知

ステップ 4: 実行、確認、レポート作成

保存すると、定義されたスケジュールで評価が実行されます。また、オンデマンドでトリガーすることもできます。各スキャンの結果が保存され、コンプライアンスポスチャーの履歴を確認できます。

Workload Manager ダッシュボードでは、スキャンされたリソース、検出された問題、経時的なトレンドの概要を確認できます。さらに詳しく分析するには、先ほど構成した BigQuery データセットで違反データを直接調べます。

図 5: Workload Manager のチェックアウト評価

Looker Studio で分析結果を可視化する

すべての関係者がデータにアクセスして活用できるように、BigQuery の結果を Looker Studio に簡単に接続できます。必要なラベルが欠落しているアセットや、費用削減ルールに準拠していないリソースなど、FinOps ポリシーの違反を可視化するインタラクティブなダッシュボードを作成します。これにより、費用管理のステータスをひと目で明確に把握できます。

テンプレートギャラリーにある Looker Studio テンプレートで、データセットに簡単に接続し、必要に応じて変更できます。使用方法は次のとおりです。

Looker Studio に移動します。
[テンプレート] に移動し、[BigQuery] で [Google Cloud Workload Manager] を選択します。
[Use your own Data] をクリックして、前の手順で生成した BigQuery テーブルを接続します。
BigQuery データセットを接続したら、[編集] をクリックしてカスタマイズ可能なコピーを作成し、変更を組み込んだり、チームと共有したりします。

図 6: レポート作成用に事前構成された Looker Studio ダッシュボードを設定する

今すぐクラウド費用を管理

クラウド費用の手動管理という無限のサイクルから抜け出しましょう。Workload Manager を使用すると、FinOps ポリシーをクラウド環境に直接組み込み、適用を自動化して、予算内に収まるために必要なフィードバックをチームに提供できます。

準備ができたら GitHub のサンプルポリシーを確認し、公式ドキュメントをチェックして、今すぐ FinOps フレームワークの自動化を開始し、Workload Manager の新しい料金体系を活用しましょう。

Workload Manager の評価がセキュリティ、信頼性、FinOps 全般でどのように役立つかについての概要説明の動画をご覧ください。

次に、更新された料金を確認して詳細をご覧ください。

-Google Cloud コンサルティング、delta Cloud FinOps 担当リード Pathik Sharma
-Workload Manager、プロダクトマネージャー Omkar Suram

ログ分析クエリビルダーの導入: ログの分析がより簡単に

Wed, 12 Nov 2025 01:04:00 +0000

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

DevOps エンジニア、サイト信頼性エンジニア、またはアプリケーション開発者として、必要な分析情報を得るために複雑なクエリに苦労した経験はありませんか？SQL の専門家でなくても、トラブルシューティング、根本原因の特定、修正の検証を簡単に行える方法があればいいのにと思ったことはありませんか？Google は皆様のご意見に真摯に耳を傾けました。このたび、Google Cloud のオブザーバビリティデータへのアクセスを民主化するために設計された強力な新しいツール、ログ分析クエリビルダーの一般提供を発表できることを嬉しく思います。

課題: SQL の記述がボトルネックになる場合

ログ分析では、ログ、その他のテレメトリータイプ、さらには BigQuery のトランザクションデータセットやビジネスデータセットを 1 か所でクエリできます。しかしその一方で、多くのユーザーにとって SQL クエリの作成が大きなハードルになることもあります。これは特に、重要なログデータを扱う場合に当てはまります。貴重な情報は、さまざまなスキーマを持つ JSON ペイロードにネストされていることが多いためです。効果的な SQL の記述には時間と労力がかかるため、トラブルシューティングが遅れ、問題を効率的に診断する能力が妨げられる可能性があります。

解決策: 直感的なクエリ作成エクスペリエンス

Google は、こうした障壁を打破するために新しいクエリビルダーを設計しました。直感的な UI ベースのエクスペリエンスにより、あらゆるスキルレベルのユーザーがオブザーバビリティデータから迅速に回答を得ることができます。

目標はシンプルでした。

導入時の負担を軽減: ログ分析を使用して、急な学習曲線なしでトラブルシューティングを開始できます。
分析情報を迅速化: データをより迅速に分析して、効果的なクエリを作成するために必要な時間と労力を削減します。
JSON 解析の簡素化: ログの JSON ペイロードから貴重なデータを簡単に抽出して分析できます。
SQL の必要性を軽減: 多くのクエリで、SQL を記述する必要がなくなります。また、ビルダーを使用して SQL の作成を開始し、複雑なクエリの編集をすぐに開始できます。

クエリビルダーを使用すると、UI で数回クリックするだけで、ログの分析、グラフ化、アラート設定ができます。SQL クエリをより簡単に記述して時間と労力を節約し、インシデントをより迅速に解決できます。

図: クエリビルダーインターフェース

主な機能の概要

ログ分析のクエリビルダーには、ワークフローを効率化する機能が満載です。

すべてのフィールドを検索: エラーメッセージや文字列を貼り付けるだけで、すべてのデータを検索し、問題の原因をすばやく特定できます。
ログスキーマのプレビュー: クエリビルダーでは、ログスキーマのプレビューだけでなく、推測された JSON キーと値のプレビューも提供されます。
インテリジェントな値の選択: UI は、JSON のネストされたフィールドも含め、データセットから直接派生したフィールドとフィルタのインテリジェントな値を提供します。
JSON 処理の簡素化: クエリビルダーは JSON スキーマと値を自動的に検出して提案するため、JSON_VALUE、JSON_EXTRACT、CAST を使用して苦労することなく、簡単にデータを選択して抽出できます。
強力なフィルタリングと集計: 一般的な SQL 演算子、集計（カウント、平均、パーセンタイルなど）、グループ化句をシンプルな UI で簡単に適用できます。
ログスコープの操作: ビュー/スコープピッカーからログスコープを選択して、クエリをログスコープに適用します。
リアルタイムの SQL プレビュー: 基盤となる SQL を確認したい場合は、クエリビルダーでリアルタイムのプレビューを利用できます。このプレビューは、UI でクエリを作成するにつれて更新されます。いつでもコードエディタに切り替えて、クエリを微調整できます。
可視化ダッシュボード: クエリ結果を即座に可視化し、ワンクリックでダッシュボードに保存できます。

例: Pod 名に `event-exporter-gke-mod` が含まれる `IAM_PERMISSION_DENIED`を検索する

この例では、`event-exporter-gke-mod` を含む Kubernetes Pod 名で `IAM_PERMISSION _DENIED` メッセージを検索し、ログエントリからログ ID とテキストペイロードを表示しました。

この例から、クエリビルダーは以下の SQL を生成します。

code_block: <ListValue: [StructValue([('code', "WITH\r\n scope_query AS (\r\n SELECT\r\n *\r\n FROM\r\n `test-project.global._Default._Default` )\r\nSELECT\r\n resource.type,\r\n log_id,\r\n JSON_VALUE( resource.labels.pod_name ) AS pod_name,\r\n text_payload\r\nFROM\r\n scope_query\r\nWHERE\r\n JSON_VALUE( resource.labels.pod_name ) LIKE '%event-exporter-gke-mod%'\r\n AND SEARCH(scope_query,\r\n 'IAM_PERMISSIONS_DENIED')\r\nLIMIT\r\n 100"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ce6491fd0>)])]>

例: グループ内のログエントリをカウントする

この例では、ログエントリを重大度、リソースタイプ、ログ ID でグループ化し、各グループのログエントリ数を時間の降順でカウントしました。

クエリビルダーは、この例を表す以下の SQL を生成します。

code_block: <ListValue: [StructValue([('code', "WITH\r\n scope_query AS (\r\n SELECT\r\n *\r\n FROM\r\n `test-project.global._Default._Default` )\r\nSELECT\r\n TIMESTAMP_TRUNC( timestamp, MINUTE ) AS minute_timestamp,\r\n severity,\r\n resource.type,\r\n log_id,\r\n COUNT( * ) AS count_all\r\nFROM\r\n scope_query\r\nWHERE\r\n SEARCH(scope_query,\r\n 'k8s')\r\nGROUP BY\r\n TIMESTAMP_TRUNC( timestamp, MINUTE ),\r\n severity,\r\n resource.type,\r\n log_id\r\nORDER BY\r\n minute_timestamp DESC\r\nLIMIT\r\n 100"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ce6491400>)])]>

デモ: クエリビルダーの威力を実際に確認

この動画では、クエリビルダーを使用して、VPC フローログで国別の外部トラフィックの合計を把握する方法を示しています。

ビルダーでクエリを作成している間は、いつでも SQL エディタに切り替えて、クエリを表す生成された SQL を確認できます。

code_block: <ListValue: [StructValue([('code', "WITH\r\n scope_query AS (\r\n SELECT\r\n *\r\n FROM\r\n `test-project.global._Default._Default` )\r\nSELECT\r\n JSON_VALUE( json_payload.dest_location.country ) AS country,\r\n SUM( CAST( JSON_VALUE( json_payload.bytes_sent ) AS INT64 ) ) AS total_bytes_sent,\r\n SUM( CAST( JSON_VALUE( json_payload.packets_sent ) AS INT64 ) ) AS total_packets_sent,\r\n AVG( CAST( JSON_VALUE( json_payload.rtt_msec ) AS INT64 ) ) AS avg_rtt_msec\r\nFROM\r\n scope_query\r\nWHERE\r\n log_id = 'compute.googleapis.com/vpc_flows'\r\n AND JSON_VALUE( json_payload.reporter ) = 'SRC'\r\n AND JSON_VALUE( json_payload.dest_location.country ) IS NOT NULL\r\nGROUP BY\r\n JSON_VALUE( json_payload.dest_location.country )\r\nORDER BY\r\n total_bytes_sent DESC\r\nLIMIT\r\n 100"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9ce4592640>)])]>

クエリビルダーの操作で基盤が構築されるため、必要に応じてクエリを簡単に編集してクエリを進めることもできます。

クエリビルダーを使用したログ分析の例については、ユーザーガイドをご覧ください。

次のステップ: ログ分析におけるクエリの未来

ログ分析のクエリビルダーは、その第一歩にすぎません。以下のような魅力的な機能が予定されています。

ログスコープの追加: 複数のプロジェクトのビューを含むログスコープをまもなくサポートする予定です。
アナリティクスのトレース: トレースを導入し、ログ分析からアクセスしてクエリできるようにします。来月には、トレースデータとログデータを結合して高度なトラブルシューティングを行えるようになります。
クエリの保存と再利用: 頻繁に使用するクエリを保存し、最近のクエリ履歴にアクセスできるため、毎回最初からやり直す必要はありません。
NL2SQL: Gemini の力を活用して自然言語で質問し、クエリビルダーに SQL を生成させます。

今すぐ使用を開始する

SQL の悩みから解放され、ログ分析の新しいシンプルさとパワーを体験する準備はできましたか？クエリビルダーは現在ご利用可能です。オブザーバビリティデータから必要な答えを簡単に得られる、その使いやすさを実感してください。ご意見、ご感想を心よりお待ちしております。

-シニアプロダクトマネージャー、Joy Wang
-ソフトウェアエンジニア、Sam Birus

OpenTelemetry Protocol が Google Cloud Observability に登場

Thu, 25 Sep 2025 01:40:00 +0000

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

OpenTelemetry Protocol（OTLP）は、ベンダーに依存しない方法でテレメトリーをソースから宛先に転送するように設計されたデータ交換プロトコルです。このたび、Google Cloud Observability の一部である Cloud Trace が、telemetry.googleapis.com を介して OTLP を使用してトレースデータを送信するユーザーをサポートするようになりました。

図 1: プロセス内構成とコレクタベース構成の両方で、ネイティブ OTLP エクスポータを使用したテレメトリーデータの送信が可能に

以下に、OTLP を使用してテレメトリーデータをオブザーバビリティツールに送信するメリットを挙げます。

ベンダーに依存しないテレメトリーパイプライン: プロセス内またはコレクタからネイティブ OTLP エクスポータを使用することができます。これにより、テレメトリーパイプラインでベンダー固有のエクスポーターを使用する必要がなくなります。
テレメトリーデータの整合性が高い: テレメトリーデータが送信と保存の際に OTel データモデルを保持し、独自の形式への変換を回避できるようにします。
お好きなオブザーバビリティツールとの相互運用性: 追加の OTel エクスポーターなしで、ネイティブ OTLP をサポートする 1 つ以上のオブザーバビリティバックエンドにテレメトリーを簡単に送信できます。
クライアントサイドの複雑さとリソース使用量を削減: フィルタの適用などのテレメトリー処理ロジックをオブザーバビリティバックエンドに移動することで、カスタムルールの必要性が減り、クライアントサイドの処理オーバーヘッドが削減されます。

Cloud Trace から OTLP を使用する方法を簡単に見てみましょう。

Cloud Trace と OTLP の実例

telemetry.googleapis.com 経由で OTLP を使用してトレースデータを送信することが、新規ユーザーと既存ユーザーの両方にとって推奨されるベストプラクティスになりました。特に、大量のトレースデータを送信することが予想されるユーザーにはおすすめです。

図 2: OpenTelemetry セマンティック規約を利用するフィールドがハイライト表示された Cloud Trace のトレース探索ページ

Trace エクスプローラページでは、OpenTelemetry の規則を幅広く使用して、関心のあるトレースをフィルタリングして見つける際に豊富なユーザーエクスペリエンスを提供します。次に例を示します。

OpenTelemetry の規則である service.name は、スパンの送信元サービスを示すために使用されます。
スパンのステータスは、OpenTelemetry のスパンステータスで示されます。

Cloud Trace の内部ストレージシステムでは、トレースデータの整理と保存に OpenTelemetry データモデルがネイティブに使用されるようになりました。新しいストレージシステムにより、trace データが telemetry.googleapis.com を介して送信される際の上限が大幅に引き上げられました。主な変更点は次のとおりです。

属性のサイズ: 属性キーは最大 512 バイト（128 バイトから）、値は最大 64 KiB（256 バイトから）にできます。
スパンの詳細: スパン名は 1,024 バイト（128 バイトから増加）まで、スパンは 1,024 個（32 個から増加）までの属性を持つことができます。
イベントとリンクの数: スパンあたりのイベント数が 256（128 から増加）に、スパンあたりのリンク数が 128 になりました。

OTLP を使用してトレースデータを送信することで、上記のストレージ上限の引き上げに加えて、トレースエクスプローラ UI とオブザーバビリティ分析のユーザーエクスペリエンスが向上すると考えています。

OTLP に関する Google Cloud のビジョン

Cloud Trace での OTLP サポートの提供は、ほんの始まりにすぎません。Google のビジョンは、OpenTelemetry を活用して Google Cloud 全体でテレメトリーを生成、収集、アクセスできるようにすることです。Google の OpenTelemetry への取り組みは、トレース、指標、ログなど、あらゆる種類のテレメトリーに及びます。これは、テレメトリー管理を簡素化し、オープンなクラウド環境を促進するという Google の戦略の要です。

昨今の複雑なクラウド環境では、さまざまなシステムにまたがり、一貫性のないデータ形式で膨大な情報のテレメトリーデータを管理すると、オブザーバビリティのギャップが生じ、運用オーバーヘッドが増加する可能性があります。Google は、すべてのテレメトリータイプでネイティブ OTLP インジェストに焦点を当てることから始めて、テレメトリーパイプラインの合理化に専念しています。これにより、データを Google Cloud Observability にシームレスに送信できます。これにより、ベンダーに縛られない相互運用性が促進され、複雑な変換やベンダー固有のエージェントが不要になります。

シームレスな取り込みだけでなく、マネージドサーバーサイド処理、さまざまな宛先への柔軟なルーティング、環境全体にわたるテレメトリーの統合管理と制御の機能も構築しています。これにより、高度な処理機能とルーティング機能をすべて 1 か所で利用できるようになり、オブザーバビリティエクスペリエンスがさらに向上します。

telemetry.googleapis.com を使用した OTLP トレースの取り込みの導入は、この取り組みにおける重要な第一歩です。Google は、Google Cloud で統合された合理的なオブザーバビリティエクスペリエンスを提供するために、追加の処理機能とルーティング機能を使用して、すべてのテレメトリータイプで OpenTelemetry のサポートを拡大する取り組みを続けています。

使ってみる

移行ガイドに沿って、トレースデータに telemetry.googleapis.com を使用し始めることをおすすめします。この新しいエンドポイントは、ストレージの上限の引き上げや、Cloud Trace Explorer とオブザーバビリティ分析におけるユーザーエクスペリエンスの向上など、機能が強化されています。

ープロダクトマネージャー Sujay Solomon

ープロダクトマネージャー Keith Chen

推測にとどまらず、徹底的に調べましょう。Gemini Cloud Assist で根本原因分析が利用可能に

Thu, 04 Sep 2025 01:05:00 +0000

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

複雑な分散クラウド環境でのデバッグは、干し草の山から針を探すようなものです。膨大な量のデータ、絡み合った依存関係、一時的な問題により、従来のトラブルシューティング方法は時間がかかるうえ、多くの場合、事後対応になります。最新のソフトウェア開発で効果的なデバッグに多くのコンテキストが求められるのと同様に、クラウド運用でも同じことが言えます。

Google Cloud with Gemini ポートフォリオの主要プロダクトである Gemini Cloud Assist は、AI を活用したアシスタンス機能でアプリケーションの設計、デプロイ、最適化を支援し、アプリケーションの管理方法を簡素化します。これにより、効率、コスト、信頼性、セキュリティの目標を達成できます。

次に、インフラストラクチャとアプリケーションのトラブルシューティングを行う根本原因分析（RCA）AI エージェントである Gemini Cloud Assist Investigations が、現在プレビュー版として利用可能となっています。

問題が発生した場合は、ログエクスプローラ、Cloud Monitoring のアラート、あるいは直接 Gemini のチャットパネルからなど、さまざまな場所から調査を開始できます。Cloud Assist は、ログ、構成、指標などの複数のソースからのデータを分析し、環境の状態に関する分析情報を提供する、ランク付けおよびフィルタリング済みの「観察結果」を生成します。これらの観察結果を統合して考えられる根本原因を診断し、コンテキストを説明するとともに、問題解決に向けた次のステップや修正方法を推奨します。さらにサポートが必要な場合は、調査とそのすべてのコンテキストを Google Cloud サポートケースにシームレスに転送して、サポートエンジニアによる解決を迅速化できます。

Gemini Cloud Assist の調査の仕組み

Gemini Cloud Assist の調査は、以下の機能を組み合わせて問題の根本原因の特定を支援します。

プログラマティック、プロアクティブ、そしてインタラクティブなアクセス: API 呼び出し、チャットメニュー、UI を通じて調査をトリガーまたは利用でき、プロアクティブかつインタラクティブなトラブルシューティングを実現できます。
コンテキスト化: 調査では、環境内で最も関連性の高いリソース、データソース、API を特定し、焦点を絞ったトラブルシューティングを提供します。
包括的なシグナル分析: 調査では、Cloud Logs、Cloud Asset Inventory、App Hub、指標、エラー、ログテーマにわたって並列で詳細な分析を行い、異常、構成の変更、パフォーマンスのボトルネック、繰り返し発生する問題を明らかにします。
AI による分析情報と推奨事項: Google Cloud サポートのナレッジベースや社内ランブックなどの専門知識ソースを活用し、考えられる根本原因と実行可能な推奨事項が調査によって生成されます。
インタラクティブなコラボレーション - チーム全体で調査内容をチャットや共有で伝え、チームや Gemini Cloud Assist と連携してトラブルシューティングを行えます。
Google Cloud サポートへの引き継ぎ: 調査を直接サポートケースに変換でき、時間やコンテキストを失うことがありません。

プログラマティック、プロアクティブ、インタラクティブな調査

早期ユーザーは、Cloud Assist の調査によって難しい問題を迅速かつ効果的にトラブルシューティングして解決できることに満足しています。

「ZoomInfo では、稼働時間を維持することが非常に重要ですが、エンジニアが複雑な問題を迅速かつ効果的にトラブルシューティングできるようにすることも同様に重要です。開発プロセスの早い段階で Gemini Cloud Assist の調査を統合したことで、エンジニアリングチームのあらゆるレベルでトラブルシューティングを迅速化できました。あらゆる経験レベルのエンジニアが問題を迅速に診断して解決できるようになり、解決までの時間が数時間から数分に短縮されました。この効率性により、チームはイノベーションに注力する時間を増やし、事後対応型の問題解決に費やす時間を減らすことができます。Gemini Cloud Assist の調査は、トラブルシューティングの支援ツールであるだけでなく、生産性とイノベーションを牽引する重要な存在です。」- ZoomInfo、DevOps エンジニア Yasin Senturk 氏

「Gemini Cloud Assist 調査機能は 2 分で潜在的な根本原因に関する有効な提案をいくつか提示してくれ、最初の提案がまさにその原因だったことに本当に感銘を受けました。1 時間以内に問題全体に対処することができたのです。Gemini Cloud Assist のおかげで週末返上にならずに済みました。」 - Google Waze、SRE、Chuanzhen Wu 氏

Gemini Cloud Assist 調査機能をもう少し詳しく見ていきましょう。

プログラマティック、プロアクティブ、インタラクティブなアクセス調査は、ログエクスプローラのログメッセージ、特定のプロダクトページ（Google Kubernetes Engine や Cloud Run など）、または中央の [調査] ページなど、Google Cloud 内のさまざまな場所から直接開始できます。中央の [調査] ページでは、エラーメッセージ、影響を受けたリソース、観察時間などのコンテキストを提供できます。Gemini Cloud Assist の調査には API も用意されているため、Slack などの既存のワークフローや他のインシデント管理ツールに統合できます。問題の根本原因の特定にさらに支援が必要な場合は、調査の出力を用いて Google Cloud サポートケースをトリガーし、サポートエンジニアがその時点から対応できるようにします。

コンテキスト化調査は、自然言語の説明、エラーメッセージ、ログスニペット、または問題に関する情報の任意の組み合わせから開始できます。まず、問題に関連する初期コンテキストを収集し、関連するリソースや、根本原因の分析に役立つ可能性のある関連データソースをすべて示すトポロジを構築します。

調査では、公開・非公開のナレッジ、Google SRE および Google Cloud サポートの事例に基づくプレイブック、ユーザーのトポロジを活用し、類似の問題を基盤として、問題のトラブルシューティング計画を生成します。このコンテキストは、的を絞った包括的なシグナル分析を提供するうえで重要になります。

包括的なシグナル分析調査が実行されると、プロジェクトからの収集が開始された観察結果が表示されます。調査は表面的な観察にとどまりません。Google Cloud 環境全体にわたる重要なデータソースを自動的に分析します。

Google Cloud ログ: 膨大なログデータを精査して、異常や重大なイベントを特定する
Cloud Asset Inventory: リソース構成の変更とその潜在的な影響を把握する
指標（近日提供予定）: パフォーマンスデータを関連付けて、リソースの枯渇や予期しない動作を特定
エラー: エラーを集計して分類し、パターンと繰り返し発生する問題をハイライト表示
ログのテーマ: ログデータ内の一般的なパターンとテーマを特定し、問題のより上位レベルのビューを提供する

AI による分析情報と推奨事項Gemini Cloud Assist Investigations の根本原因に関する分析情報と推奨事項は、観察結果に基づいています。 Gemini の分析機能を活用することで、Cloud Assist はさまざまなデータソースからの観察結果を統合し、情報をランク付けしてフィルタリングすることで、最も関連性の高い詳細に焦点を当てます。重要なのは、調査で差別化された知識ソースと、広範な Google Cloud サポートのトラブルシューティングに関する知識や社内のランブックなどの一般公開されているドキュメントを利用して、非常に正確で関連性の高い分析情報と観察結果を生成することです。その後、以下が生成されます。

考えられる根本原因: 問題の根本原因について、状況説明を添えて明確な仮説を提示
実用的な推奨事項: トラブルシューティングの具体的な次のステップや、直接的な修正方法を提示し、インシデントの迅速な解決を支援

Google サポートチームへの引き継ぎ特に解決が難しい問題の場合、ボタンをクリックするだけで、調査パッケージがコンテキスト、観察結果、仮説をサポートケースにまとめ、問題の解決を迅速化します。そのため、問題について Google サポートチームに問い合わせる前に、調査を実施することをおすすめします。

Gemini Cloud Assist Investigations を今すぐ使ってみましょう

問題をより迅速に根本から解決する準備はできていますか？ログエクスプローラコンソールから任意のエラーログを調査して、今すぐお試しください。または、調査を直接作成して、発生している問題を記録してみましょう。

-GCP 基盤サービス、グループプロダクトマネージャー、Deepak Kallakuri
-Mark Church 、GCP 基盤サービス担当プロダクトマネージャー

Cloud Hub の最適化と Cost Explorer を使用してクラウド費用を最適化する

Wed, 20 Aug 2025 02:00:00 +0000

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

アプリケーションオーナーがクラウド費用の最適化を検討する際に求めているのは、次の 3 つです。

最も費用のかかるリソースはどれですか？
今週または今月、どのリソースの費用が上がっているか？
利用率が低いリソースはどれか？

これらの質問にすばやく簡単に回答できるように、Google は Google Cloud Next 2025 で、プライベートプレビュー版の Cloud Hub Optimization と Cost Explorer を発表しました。そしてこのたび、Cloud ハブの最適化と費用エクスプローラの両方が公開プレビュー版で利用可能になりました。

アプリケーションの費用と使用率

アプリのオーナーとして、主な目標はアプリケーションを常に健全な状態に保つことです。しかし、数十のプロジェクトにまたがる可能性のあるアプリケーションの個々のコンポーネントをすべてモニタリングするのは、非常に大変な作業です。AppHub アプリケーションを使用すると、アプリケーションを中心にクラウドを再編成し、必要な情報と制御をすぐに利用できます。

Cloud Hub Optimization と Cost Explorer は、Google Cloud プロジェクトをサポートするだけでなく、App Hub アプリケーションを活用して、アプリケーションのワークロードとサービスの費用対効果を即座に表示します。これは、GPU などの貴重なリソースを無駄にしている可能性のある、GKE クラスタで実行されているデプロイを特定しようとする場合などに最適です。

単なる費用ダッシュボードではありません

Cloud Hub Optimization を表示すると、最も費用がかかっているリソースと、その費用の変化率をすぐに確認できます。このきめ細かい費用情報により、費用を特定のリソースやリソース所有者に帰属させ、費用の変化について推論できるようになりました。

さらに、Cloud Billing の詳細な費用データと Cloud Monitoring のリソース使用率データを統合し、費用効率を包括的に把握できるようにしました。これには、プロジェクトの平均 vCPU 使用率が含まれます。これにより、数百の Google Cloud プロジェクトの中から、最も有望な最適化候補を見つけることができます。

Cost Explorer ダッシュボードでは、プロダクトレベルで論理的に整理された費用も表示されるため、費用の説明がさらに容易になります。Compute Engine の総額費用ではなく、Google Kubernetes Engine（GKE）クラスタ、永続ディスク、Cloud Load Balancing など、個々のプロダクトの正確な費用を確認できるようになりました。

シンプルが故の力強さ。

これらの新しいツールを試したお客様は、表示される情報とインターフェースのシンプルさを気に入っています。

「私のチームは、数十の事業部門と数百人の開発者のクラウド費用を監視する必要があります。Cloud Hub の最適化と費用エクスプローラダッシュボードは、費用削減の可能性や最適化の機会を探す場所を教えてくれるため、チームの能力を何倍にも高めてくれます。」 - メジャーリーグベースボール、プリンシパルクラウドアーキテクト、Frank Dice 氏

お客様は、追加のセットアップなしですぐに利用できる幅広いプロダクトカバレッジと、これらの機能を使用しても追加料金が発生しないことを特に高く評価しています。

次のステップ

組織がクラウド費用管理を「左シフト」するにつれて、Google はアプリケーションオーナーと開発者がクラウド費用を理解して最適化できるよう支援しています。Cloud Hub Optimize と費用エクスプローラはこちらからお試しいただけます。

Google Cloud Next 2025 の講演「Maximize Your Cloud ROI」では、Cloud Hub Optimization と Cost Explorer を使用して、使用率の低い GKE クラスタを数秒で特定する方法のライブデモもご覧いただけます。

^{メジャーリーグベースボールの商標および著作権は、メジャーリーグベースボールの許可を得て使用されています。MLB.com をご覧ください。}

ープロダクトマネージャー Gobind Johar

Google Cloud で実行される SAP ワークロードのシステム中心のモニタリングとオブザーバビリティ

Thu, 14 Aug 2025 01:20:00 +0000

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

複雑な SAP 環境の管理は、迷路を歩くようなものです。ユーザーは、パフォーマンス、データベースの健全性、インフラストラクチャの安定性などをすべて両立させながら、シームレスなビジネスアプリケーションの実現に努めています。このたび Google は、Workload Manager に新しいオブザーバビリティ機能とモニタリング機能を追加しました。これにより SAP のお客様に、データギャップを埋めクラウド環境の全レイヤにわたる SAP 環境の全体像を確認できる、専用ツールをご利用いただけます。

Workload Manager は、既存の SAP モニタリングツールを置き換えるのではなく、補完するものです。SAP システムのより広範なビューにより、アプリケーションレベルの分析情報を、インフラストラクチャのパフォーマンスやイベントと相互に関連付けることができます。

複雑な SAP 環境の可視性の拡大

従来の SAP モニタリングは、アプリケーションレベルとデータベースレベルで詳細な情報を得るうえで優れており、トランザクションのパフォーマンス、ユーザーアクティビティ、アプリケーションログに関する指標をすぐに利用できます。しかし、アプリケーションデータと基盤となるインフラストラクチャの関係を理解するには、これだけでは不十分です。たとえば、トランザクション処理の速度が低下しているとしましょう。データベースの問題、ネットワークのボトルネック、基盤となる仮想マシンの問題など、さまざまな原因が考えられます。既存のツールは貴重な情報源ですが、アプリケーションのパフォーマンスとインフラストラクチャの健全性を関連付けるには十分でなく、時間がかかりすぎたり、さまざまなモニタリングプラットフォームの切り替えや手動のステップが必要になったりする場合があります。

aside_block: <ListValue: [StructValue([('title', 'Workload Manager でシステム中心の統合ビューを作成'), ('body', <wagtail.rich_text.RichText object at 0x7f9ce4d97790>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

Workload Manager でシステム中心の統合ビューを作成

Google Cloud の SAP 用エージェントで該当の機能を有効にすると、メインのオブザーバビリティダッシュボードで、SAP システムの概要と、各システムおよびサブレイヤの総合的な健全性を確認できるようになります。健全性のステータスは、SAP Netweaver インスタンス、SAP HANA データベース、Pacemaker クラスタから得られるさまざまな指標と、それらをホストする基盤インフラストラクチャの可用性をもとに計算されます。

システムをクリックすると概要ページに移動します。ここでは、システムのコンポーネントを可視化し、含まれている各インスタンスの現在の健全性を確認できます。[Health Insights] テーブルには現在検出されている健全性の問題がまとめられ、[Maintenance Events] テーブルにはサポート対象のマシンタイプの今後のメンテナンス予定が表示されます。

[Applications] タブと [Databases] タブも同様に機能し、SAP アプリケーションの主要なパフォーマンス指標と、VM、ストレージ、ネットワーク、その他の Google Cloud サービスの指標を関連付けるのに役立ちます。たとえば、以下のようなものです。

可用性: GCE インスタンスの可用性、SAP NetWeaver および SAP HANA インスタンスのステータス、SAP NetWeaver および SAP HANA プロセスのステータス、Pacemaker クラスタのノードとリソースのステータス。
パフォーマンス: GCE インスタンスの CPU とメモリの使用率、CPU とメモリ別のオペレーティングシステムプロセス、オペレーティングシステムでのスワップ I/O オペレーションに関する情報。
ストレージ: SAP 関連のファイルシステムの使用状況、ディスク容量の使用率と使用状況、ディスクスループット、ディスク IOPS。
ネットワーキング: ネットワークトラフィックとネットワークパッケージに関する情報。
Netweaver: SAP NetWeaver プロセスによる CPU とメモリの使用率、SAP NetWeaver インスタンス内のプロセスのレスポンス時間、タイプ別の SAP NetWeaver セッションと RFC 接続、ワークプロセスタイプごとの SAP NetWeaver プロセスの使用率、システム内の各キューの SAP NetWeaver プロセスタイプごとの情報。
HANA: SAP HANA システムレプリケーションのステータス、SAP HANA システムレプリケーションのレイテンシ、タイプ別の SAP HANA データベースのメモリ使用量、SAP HANA データベースのアイドル状態の接続と実行中の接続に関する情報、SAP HANA データベースのレコード数上位のスキーマ。
バックアップ: バックアップ/復元の成功率、すべてのオペレーションのバックアップ/復元の平均 MBps、バックアップ/復元のステータスとスループットに関する履歴データなど、Backint バックアップに関連する情報。

SAP 向けに特別に設計された新しいイベントアノテーションを使用すると、システムイベントをモニタリングダッシュボードに直接表示できるため、根本原因を迅速に特定したり、イベントがシステムのパフォーマンスと健全性に与える影響を確認したりできます。これらのイベントは、Workload Manager の外部でも、Cloud Monitoring ダッシュボードで利用できるようになりました。

SAP の可用性

Pacemaker クラスタ

Pacemaker クラスタノードのステータス
Pacemaker クラスタリソースのステータス

SAP HANA データベース

SAP HANA インスタンスのステータス
SAP HANA サービスのステータス

SAP NetWeaver

SAP NetWeaver インスタンスのステータス
SAP NetWeaver サービスのステータス

SAP オペレーション

SAP HANA システムレプリケーションのステータス
SAP HANA バックアップのステータス

SAP HANA のデータのバックアップ
SAP HANA のログのバックアップ

たとえば、次のスクリーンショットでは、SAP HANA データベースのフェイルオーバーがデータベースの可用性にどのように影響したかを確認できます。また、Pacemaker クラスタがデータベースオペレーションをセカンダリノードに移動した際のイベントも確認できます。

その他の主な機能と利点

包括的な指標: このソリューションは、SAP アプリケーションと Google Cloud インフラストラクチャから幅広い指標を収集しますが、さらに多くの指標が必要な場合は、カスタムクエリを作成して Workload Manager Observability 内のカスタムダッシュボードに指標を追加できます。
カスタマイズ可能なダッシュボード: ダッシュボードに手を加えて別のビューを作成し、ビジネスにとって特に重要な要素を可視化することによって、重大な問題をすばやく特定できます。
アラートと通知: ダッシュボードは、Cloud Monitoring とアラートにネイティブに統合されています。特定の指標のアラートを設定し、しきい値を超えたときに通知を受け取ることができます。
自動システム検出: SAP 用エージェントを有効にすると、SAP インスタンスとリソースが自動的に識別および調整されるため、手動でのタグ付けやラベル付けが不要になり貴重な時間を節約できます。

ご利用の開始

Google Cloud 上の SAP のオブザーバビリティを一か所で実現するメリットを体験してみませんか？利用開始方法やサポート対象アーキテクチャに関する詳細なドキュメントと手順については、こちらをご覧ください。Workload Manager のオブザーバビリティサービスは追加料金なしで利用できますが、基盤となる指標とログには、Cloud Monitoring と Cloud Logging に関連する費用がかかります。有効にする必要がある必須機能の推定費用は、こちらでご確認いただけます。

オンボーディングのサポート、デモ、詳細情報をご希望の場合は、アカウント担当者または Google Cloud サポートまでお問い合わせください。

今後の展望

Google は、Google Cloud 上の SAP のオブザーバビリティの継続的な改善に尽力しており、新機能や、さらに充実した関連付け機能、情報の豊富な可視化機能を追加していく予定です。

-プロダクトマネージャー Brad Nixon
-SAP テクニカルソリューションコンサルタント Miguel Exposito

Datadog が Google Cloud スタック全体における新しいインテグレーションにより AI オブザーバビリティ機能を拡張

Tue, 10 Jun 2025 16:00:00 +0000

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

Datadog と Google Cloud は長年にわたり、お客様がクラウドで高性能かつスケーラブルで差別化されたアプリケーションを構築できるよう、強力な機能を提供してきました。過去 2 年間だけでも、Google Cloud Marketplace における Datadog の収益の増加率は 2 倍を超えています。Google Cloud の AI 機能を自社のテクノロジースタックに組み込むお客様にとって、エラーのトラブルシューティング、使用状況の最適化、プロダクトパフォーマンスの向上をより適切に行えるオブザーバビリティツールが不可欠です。

このたび、Datadog は新しい AI エージェントコンソールにおいて、Vertex AI Agent Engine のモニタリング機能により AI モニタリング機能を拡張したことを発表しました。この新機能は、Google Cloud の大規模かつ成長を続ける AI モニタリング機能に加わり、共通のお客様が AI スタック全体でプロダクトパフォーマンスのイノベーションと最適化をより効果的に行うことを可能にします。

フルスタックの AI オブザーバビリティ

この幅広い AI オブザーバビリティ機能により、Google Cloud 上でワークロードを実行する Datadog のお客様は、AI アプリケーションのすべてのレイヤに対する可視性を高めることができます。

アプリケーションレイヤ: 企業が主要なワークフローを強化するために自律型エージェントを採用するにつれて、可視性とガバナンスが重要になります。Datadog の新しい AI エージェントコンソールは、Google の Vertex AI Agent Engine を介してデプロイされたエージェントのモニタリングをサポートします。これにより、お客様は、エージェントエンジンによってオーケストレートされたものも含め、サードパーティエージェントのアクション、権限、ビジネスへの影響に関する統合ビューを手に入れることができます。
モデルレイヤ: Datadog LLM Observability を使用すると、ユーザーは大規模言語モデル（LLM）アプリケーションをモニタリング、トラブルシューティング、改善、保護できます。今年に入り、Datadog は Vertex AI の Gemini モデルと LLM の自動計装を導入しました。これにより、チームは迅速にモニタリングを開始し、最小限のセットアップでトラブルシューティングにすぐに着手できるようになりました。
インフラストラクチャレイヤ: Datadog は 2 月に、Cloud TPU との新しいインテグレーションを発表しました。これにより、お客様はコンテナ、ノード、ワーカーのレベルで使用率、リソース使用量、パフォーマンスをモニタリングできるようになります。これは、お客様が TPU インフラストラクチャを適切なサイズに調整し、トレーニングのパフォーマンスと費用のバランスをとるのに役立ちます。
データレイヤ: Google Cloud の多くのお客様が、BigQuery を使用してデータ分析情報を取得しています。Google Cloud Next では、Datadog の拡張 BigQuery モニタリング機能が発表されました。これは、チームが BigQuery の使用状況をユーザーごと、プロジェクトごとに表示し、特に費用がかかっている部分と遅いクエリを特定することにより、費用を最適化するのに役立ちます。さらに、直ちに対処できるように失敗したジョブにフラグを付け、データ品質の問題を特定します。

モニタリングの費用の最適化

Datadog は、Google Cloud とのインテグレーションに関連する費用の最適化に継続的に投資しています。Datadog のお客様は、Google Cloud の Active Metrics API を使用できるようになったため、Datadog が Google Cloud API を呼び出すのは新しいデータがある場合のみになります。その結果、可視性を損なうことなく、API 呼び出しと関連費用を大幅に削減できます。これは、Datadog による Google Cloud の Private Service Connect への対応に加わるものです。Google Cloud を利用する Datadog ユーザーがデータ転送費用を削減できるようになり、Google Cloud のお客様が可視性を損なうことなくモニタリング費用を最適化するためのさらなる重要なツールとなります。

今すぐ使用

Datadog のオブザーバビリティとセキュリティの統合プラットフォームは、Google Cloud の最先端の AI サービスを活用したいと考えている組織に大きなメリットをもたらします。Datadog は、幅広いテレメトリータイプにわたって Google Cloud スタック全体をモニタリングすることで、パフォーマンス、費用効率、スケーラビリティがより優れたアプリケーションを構築するのに必要なツールと分析情報を Google Cloud のお客様に提供します。

ぜひご自身でお試しください。Google Cloud Marketplace から Datadog を直接購入し、ほんの数分で環境のモニタリングを開始できます。ニューヨーク近郊の方は、6 月 10 日～11 日に開催される Datadog の年次カンファレンス DASH の Google Cloud ブースで、これらの新機能を実際にご覧いただけます。

-Google、シニア戦略的パートナーシップ担当マネージャー、Abhi Das

-Datadog、プロダクトマーケティングマネージャー、Trammell Saltzgaber 氏

aside_block: <ListValue: []>

AI を活用してデータベースフリート管理の簡素化を実現するデータベースセンターの一般提供を開始

Thu, 05 Jun 2025 01:04:00 +0000

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

Google Cloud Next 25 で、モニタリング、最適化、セキュリティなど、データベースフリート管理のあらゆる側面を簡素化する、AI を活用した統合フリート管理ソリューションであるデータベースセンターの一般提供が発表されました。

データベースセンターは、企業がデータベースフリートのモニタリングに使用する断片化されたツール、複雑なスクリプト、API、ミスが発生しやすいその他ワークフローに代わるものとして、Google の基盤 AI モデルを使用した直感的なチャットインターフェースとインテリジェントな推奨事項を提供する統合エクスペリエンスを実現します。

以前の投稿では、データベースフリートのカオスに秩序をもたらし、データの真の可能性を引き出すために、データベースセンターがどのように設計されているかを説明しました。その直感的な単一のインターフェースを使うことで、次のことが可能になります。

データベースフリート全体を包括的に把握する。これにより、情報のサイロ化が解消され、専用のツールやスプレッドシートで情報を探す必要がなくなります。
インテリジェントなパフォーマンス、信頼性、費用、コンプライアンス、セキュリティに関する推奨事項により、フリートのリスクを未然に回避します。
AI を活用したアシスタンス機能でデータベースフリートを最適化する。自然言語のチャットインターフェースを使用して質問し、フリートの問題を迅速に解決して、最適化に関する推奨事項を得ることができます。

一括表示、直近の問題、カスタムビュー

データベースセンターの最新情報

一般提供版のデータベースセンターでは、Cloud SQL、AlloyDB、Spanner、Bigtable、Memorystore、Firestore など、すべての Google Cloud データベースのパフォーマンスと健全性のモニタリングが強化されています。より多様な指標と実用的な推奨事項を提供し、データベースのパフォーマンスと信頼性を最適化します。また、エクスペリエンスのカスタマイズも可能です。データベースセンターは、Gemini を活用したアシスト機能によりパフォーマンスのトラブルシューティングを支援します。さらに、データベースインベントリと健全性の問題に関する週ごとの進捗状況を追跡できます。

データベースセンターの一般提供版リリースで新しく追加される機能の詳細を以下にご紹介します。

Gemini アシストによるパフォーマンスのトラブルシューティングでは、以下の機能が提供されます。

Cloud SQL の非効率なクエリやインデックスを改善するためのアドバイザー
Cloud SQL と AlloyDB のリソース使用率の高いオプションの分析

Bigtable、Spanner、Memorystore、Firestore、Cloud SQL で提供される推奨事項が拡充されました。新しく追加された推奨事項は以下のとおりです。

Spanner - 削除保護の無効状態、自動バックアップポリシーの未設定、前回のバックアップから 24 時間以上経過
Bigtable - ホットスポット検出、高いリソース使用率、ストレージ容量の上限到達または到達間近、削除保護の無効状態、リソースの停止
Memorystore - 高いリソース使用率、高負荷のコマンド、メンテナンスポリシーの未設定
Firestore - ポイントインタイムリカバリの無効状態、自動バックアップポリシーの未設定
Cloud SQL - ユーザーパスワードポリシーの未設定、非効率なクエリ

保存可能なビュー: 特定のペルソナ向けにデータベースセンターのカスタムビューを作成、保存、共有できます。
過去のデータ: 過去 1 週間に生成された新しいデータベースリソースと発生した問題を追跡できます。

アラート: 一元化されたインターフェース上で、すべてのデータベース変更ポリシーとインシデントを確認できます。

パフォーマンスの問題を検出して分析するアシスト機能

データベースセンターのお客様の声

データベースセンターのプレビュー版を使用したお客様は、この統合フリート管理ソリューションが提供する価値を実感しています。

「デジタルトランスフォーメーションの加速を継続するなかで、データベースは開発のペースに追随し、ビジネスアプリケーションを支えるデータベース環境の複雑性の増大に適応していく必要があります。Ford にとって重要な数百のプロジェクトにおいて、数千におよぶデータベースを管理しています。データベースセンターは、当社のデータベース環境について他のソリューションでは得られないような分析情報を提供してくれました。堅牢なモニタリングとオブザーバビリティのツールにより、潜在的な問題をプロアクティブに特定し、ユーザーに影響が及ぶ前に対処できるようになりました。現在では、フリートの健全性に関する情報を数秒で取得でき、アプリケーションに潜むリスクをこれまで以上に迅速に、先を見越して軽減できます。」 - Ford Motor Company、データベース技術担当技術エキスパート、Bogdan Capatina 氏

「データベースセンターは、データベース環境全体の状況を一元的に可視化し、社内のあらゆるデータベースにアクセスして操作するための中央ハブとして機能します。」 - Telus、情報サービス担当マネージャー、Kurt Harsft 氏

「データベースセンターは、データベースのオブザーバビリティに関する当社のビジョンに完全に合致しています。オンプレミスのデータベースをモニタリングするのと同じように、単一の統合ビューでデータベース環境全体を確認できます。管理を簡素化し、セキュリティコンプライアンスを強化し、シームレスかつ包括的なデータベースの監視方法を標準化します。」 - Home Depot、シニアプリンシパルアーキテクト、Sangeeth Talluri 氏

「フリート全体におけるインフラストラクチャの包括的な健全性、セキュリティ、コンプライアンス、アラート、データ保護の状況を簡単に確認できるデータベースセンターの機能は、まさに画期的であり、卓越した価値と安心感を提供します。」 - UKG、エンジニアリングマネージャー、Rahul Jain 氏

データベースセンターにアクセスする方法

データベースセンターは、Google Cloud のマネージドデータベースサービスのコンソール、つまり Cloud SQL、AlloyDB、Spanner、Bigtable のコンソールから利用できます。任意の階層における必要な IAM 権限を備えたユーザーに対して、データベースセンターはデフォルトで有効になります。

Google Cloud のお客様は、追加料金なしでデータベースセンターをご利用いただけます。パフォーマンスとコストの Recommender や自然言語チャットなどの Gemini 活用機能を含む一部のプレミアム機能を使用するには、Gemini Cloud Assist を有効にする必要があります。セキュリティとコンプライアンスの高度なモニタリングには、Google Security Command Center（SCC）のサブスクリプションが必要です。

ぜひデータベースセンターの利用を開始しましょう。

-Google Cloud データベース、プロダクトマネージャー、Apoorv Shrivastava
-グループプロダクトマネージャー、Niranjan Shivprasad

インシデント対応に AI を活用する: Personalized Service Health と Gemini Cloud Assist のインテグレーション

Tue, 03 Jun 2025 02:00:00 +0000

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

クラウドインシデントが発生した場合、誰もがそのクラウドプロバイダからの迅速かつ明確なコミュニケーションを望み、その情報を効果的に活用したいと考えます。Google Cloud コンソールの Personalized Service Health は、Google Cloud サービスの中断について、透明性と関連性の高い実用的な通知を迅速に提供するものであり、お客様特有のフットプリントに合わせてカスタマイズされています。これにより、問題の原因をすばやく特定し、「Google 側の問題か、それとも自社の問題か」という疑問に答えることができます。そして、この情報をインシデント対応ワークフローに統合して、インシデントをより効率的に解決できます。

このたび、Personalized Service Health を活用して、進行中のインシデントに関するリアルタイム情報を Gemini Cloud Assist に引き出してもらうことができるようになりました。これにより、検出、影響評価、復旧などのインシデント管理を効率化できます。Gemini のガイダンスと Personalized Service Health の分析情報、最新情報を組み合わせることにより、影響範囲を評価し、トラブルシューティングを開始できます。これらはすべて、AI を活用した Gemini Cloud Assist チャット内で行うことができます。さらに、この種のインシデント検出は、コンソール内の任意の場所から開始できるため、ワークフローを中断することなく、関連するインシデントをすぐに確認できます。また、プロジェクトに影響する進行中のインシデントを確認して、その範囲の詳細と最新の更新情報を Personalized Service Health から直接収集することもできます。

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

Gemini Cloud Assist で Personalized Service Health を活用する

Gemini Cloud Assist は、ユーザーフレンドリーなレイアウトと整理された情報構造を備えています。動的なタイムライン、最新情報、症状、回避策など、Personalized Service Health から直接取得された重要な詳細情報がコンソールに表示されるようになり、会話形式でのフォローアップが可能になりました。Gemini Cloud Assist は、Personalized Service Health の重要な分析情報を強調できるため、調査対象を絞り込んでインシデントの影響を把握するのに役立ちます。

このインテグレーションの利点を示すために、次のデモでは、Gemini と Personalized Service Health の機能を組み合わせて活用した、一般的なインシデント対応ワークフローをご紹介します。

インシデントの検出とトリアージインシデントの重要な最初の瞬間に、Gemini Cloud Assist が「Google 側の問題か、それとも自社の問題か」という疑問に答えます。Gemini Cloud Assist は、Personalized Service Health のデータに直接アクセスし、Google Cloud インシデントの影響を受けるプロジェクトとロケーションに関するフィードバックを提供することで、トリアージプロセスを迅速化します。

このプロセスを開始する方法を理解するために、Gemini Cloud Assist に次のような質問をしてみてください。

私のプロジェクトは Google Cloud インシデントの影響を受けている？
現在、Google Cloud に影響を与えているインシデントはある？

影響の調査と評価関連する Google Cloud インシデントを特定したら、Gemini Cloud Assist を使用して情報をさらに掘り下げ、自身の環境への影響を評価できます。さらに、フォローアップの質問をすることにより、Gemini Cloud Assist は、インシデントの進展に応じて Personalized Service Health から最新情報を取得できます。その後、報告されたインシデントの影響を受けるアプリやプロジェクトを、ロケーションも含めて正確に特定するよう Gemini にリクエストし、さらに調査を進めることができます。

Gemini Cloud Assist に質問するプロンプトの例を以下に示します。

進行中のインシデント ID [X] について教えて。（[X] はインシデント ID に置き換える）
[X] は影響を受けている？（[X] は特定のロケーションまたは Google Cloud プロダクトに置き換える）
インシデント ID [X] の最新情報を教えて。
インシデント ID [X] の詳細を教えて。
[影響を受けている Google Cloud プロダクト] のトラブルシューティング手順を教えて。

軽減と復旧最後に、Gemini Cloud Assist は復旧フェーズでインテリジェントなアシスタントとして機能し、実用的なガイダンスを提示します。Gemini Cloud Assist を使用すると、関連するログやモニタリングデータにアクセスして、より効率的に問題を解決できます。さらに、Gemini Cloud Assist は、Personalized Service Health から潜在的な回避策を浮き彫りにし、プロジェクトやアプリケーションを復元するために必要なツールや情報に誘導します。プロンプトの例は以下のとおりです。

インシデント ID [X] の回避策を教えて。（[X] はインシデント ID に置き換える）
アプリケーションを実行し続けるための一時的な解決策を提案して。
この影響を受けているプロジェクトのログを探すにはどうすればいい？

Gemini はこれらのプロンプトに従って Personalized Service Health から関連する情報を取得し、（進行中のイベントと最長で過去 1 年間のインシデントの両方について）Google Cloud 環境の正常性に関するパーソナライズされた分析情報を提示します。これは、インシデントを調査してその影響を絞り込み、復旧を支援する際に役立ちます。

次のステップ

今後は、Gemini Cloud Assist と Personalized Service Health を活用して、より詳細な分析情報と包括的なインシデント管理を提供することで、AI を活用したこれらの機能を単一のプロジェクトビュー以外にも拡張していく予定です。Gemini Cloud Assist と Personalized Service Health の利用を開始しましょう。

Personalized Service Health の詳細情報をご覧になるか、Google のアカウント担当者に依頼して、この機能を有効にしてください。
Gemini Cloud Assist の使用を開始します。プロンプトを調整して、特定のリージョンや Google Cloud プロダクトについて質問し、インシデントをプロアクティブに管理するためにどのように役立つかを試してみてください。

プロダクトマネージャー、Sam Jalali

シニアスタッフ UX デザイナー、Luca Paulina

開発者とオペレーター向けにアプリケーション中心の AI を活用したクラウドを実現

Mon, 28 Apr 2025 01:00:00 +0000

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

本日は、アプリケーションライフサイクルのあらゆる段階でクラウド開発者やオペレーターを支援する新しい AI 機能をご紹介します。具体的には以下のとおりです。

アプリケーションをクラウドエクスペリエンスの中心に据え、従来のクラウドモデルにおけるインフラストラクチャの複雑さを抽象化します。インフラストラクチャレベルではなく、アプリケーションレベルで設計、観察、保護、最適化を行えるようになります。
Gemini Code Assist と Gemini Cloud Assist の新機能により、アプリケーション開発ライフサイクルのあらゆる場面で AI アシスタンスを利用できるようになります。IDE での開発タスクをオフロードするために、複雑なワークフロー用に設計されたエージェントなど、新しいエージェントを導入します。また、管理と運用のタスクにも AI を活用し、アプリケーションのライフサイクル全体をよりスマートで生産的なものにしています。

アプリケーション中心の新しいクラウドエクスペリエンス

アプリケーションは、現代のビジネスの牽引役を担う存在です。しかし、従来のリソース中心のクラウドモデルでは、アプリケーションの設計、デプロイ、管理に膨大な複雑さが伴うため、開発者はビジネス要件をインフラストラクチャの詳細に反映せざるを得ず、アプリケーションの全体的な目的とパフォーマンス目標が見えにくくなってしまいます。また、アプリケーションコンポーネントが多くのシステムやダッシュボードに分散しているため、パフォーマンスの追跡、費用の把握、問題のトラブルシューティングが困難になっています。Google のアプリケーション中心のアプローチは、多くの新しいサービスや拡張機能により、こうした課題の解決を支援します。

App Design Center とは

現在プレビュー版が公開されている Google Cloud の新しいサービス、Application Design Center は、プラットフォーム管理者と開発者が、クラウドアプリケーションの設計、デプロイ、進化を効率化すると同時に、そのクラウドアプリケーションを安全で信頼性が高く、ベストプラクティスに沿ったものにするのをサポートするサービスです。Application Design Center では、API や gcloud コマンドラインインターフェースだけでなく、キャンバススタイルの視覚的なアプローチでアプリケーションテンプレートを設計、変更できます。また、デプロイ用のアプリケーションテンプレートの構成や、infrastructure as code のインライン表示、チームメイトとの共同設計も可能です。アプリケーションのデプロイは App Hub に自動的に登録されるため、運用やトラブルシューティングが容易です。

Cloud Hub でアプリケーションの可視性と管理を統合

新しい Cloud Hub サービスは、アプリケーション環境全体の中央コマンドセンターとして機能し、お客様がアプリケーションやワークロードにとって最も重要な作業に集中できるようにします。デプロイ、健全性とトラブルシューティング、リソースの最適化、メンテナンス、割り当てと予約、サポートケースに関する分析情報が提供されるため、アプリケーションの重要な側面を管理しやすくなります。この統合ビューにより、管理が簡素化され、問題解決が早まります。Cloud Hub は現在公開プレビュー版であり、Google Cloud コンソールのすべてのユーザーにご利用いただけます。こちらからぜひ Cloud Hub をお試しください。

Cloud Hub は、Google Cloud 上のアプリケーション環境の統合ビューを実現します。

App Hub とアプリ中心のオブザーバビリティの拡大

App Hub は、アプリケーションを相互接続されたサービスまたはワークロードとしてモデル化し、アプリケーション中心のビューを提供します。現在、Google Kubernetes Engine（GKE）、Cloud Run、Cloud SQL、AlloyDB など、20 以上の Google Cloud プロダクトとのインテグレーションが行われており、アプリケーション中心のエクスペリエンスの基盤を強化しています。今後もこの取り組みをさらに拡大していく予定です。

さらに、2 つの新機能により、アプリケーション中心のオブザーバビリティ機能を強化しています。1 つ目は、公開プレビュー版の Application Monitoring です。Application Monitoring は、アプリケーションコンテキストによるテレメトリー（ログ、指標、トレース）の自動タグ付け、アプリケーション対応アラート、すぐに使えるアプリケーションダッシュボードをサポートします。2 つ目は、Cost Explorer です。これを導入することで、アプリケーションの詳細な費用や使用率の指標を可視化し、効率化の機会を特定できるようにします。Cost Explorer は現在、限定公開プレビュー版です。こちらから登録してお試しください。

AI を活用したアプリケーションの開発と管理

Gemini Code Assist と Cloud Assist では、アプリケーション開発を迅速化し、ソフトウェア開発ライフサイクル全体にわたるクラウド運用の効率化を支援することに重点を置いています。

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

Gemini Code Assist: デベロッパーの生産性を向上

Gemini Code Assist はすでに、Android Studio、Firebase Studio、JetBrains、VS Code といったおなじみのコードエディタで AI アシスタントとして機能しています。本日は、Code Assist がソフトウェアエンジニアの皆様を支援する新しい方法を 3 つご紹介します。

自然言語リクエストによるリクエストを複数のステップとファイルで構成されるソリューションに変換できるエージェント
Code Assist を外部サービス、パートナー事業者、さらには他のエージェントに簡単に接続できる新しいツール
コーディング機能が強化され、個人向け Gemini Code Assist で利用可能になった Gemini 2.5

Gemini Code Assist エージェント

先日、Sundar Pichai 氏が、Google のコードの 25% は AI が記述していることを発表しました。Google Cloud のお客様も同様の傾向にあり、Renault Group の Ampere、Broadcom、CGI、CME Group、PayPal、Wipro は、コードの記述とアプリケーションの開発に Code Assist を使用しています。実際、シカゴマーカンタイル取引所を運営する CME Group は、Code Assist により、同社の開発者のほとんどが 1 か月あたり 10.5 時間以上の生産性向上を実現していると述べています。

アプリケーションを本番環境に移行するには、コーディング以外にもさまざまなタスクが必要です。そのため、ソフトウェア開発ライフサイクル全体のタスクへの取り組みに役立つよう設計された Gemini Code Assist エージェントを使用して、優れた新機能をすぐにご利用いただけるようにしています。

Gemini Code Assist のエージェントは、開発者がよく行うさまざまなタスクの実行を支援できるようになりました。以下に例を示します。

新しいソフトウェアの生成: Google ドキュメントの製品仕様からアプリケーションを作成します。
コードの移行: ある言語から別の言語へのコード変換と、言語 / フレームワークのバージョン間のコード変換を実行します。
新機能の実装: GitHub でユーザーに割り当てられた課題を読み、その内容に対応するコードを作成します。
コードレビューの実施: コード分析を行い、品質、ベストプラクティス、組織のスタイルに関するフィードバックを提供します。
テストの生成: テストケースの作成、テストの実行、結果のレポートの作成を行います。
AI テストの実施: モデルの入力と出力を評価し、コンテンツの安全性に関する潜在的な懸念事項を特定して対処します。
ドキュメントの生成: リポジトリ全体の wiki スタイルのドキュメントを作成し、更新します。また、コードベース全体に関する Q＆A を提供します。

エージェントがバックグラウンドで作業している場合、どのタスクが進行中で、何が完了しているかを把握できることが重要です。そこで、Google Cloud は Gemini Code Assist のカンバンボードを作成しました。このボードでは、Google のエージェントとのやり取りや、Gemini がタスク完了のために作成した作業計画の確認、さまざまなジョブやリクエストの進捗状況の追跡が可能です。

Gemini Code Assist ツール

IDE で Gemini Code Assist を使って真に効率的に作業するには、外部ソースのコンテキストに簡単にアクセスできることが必要です。そこで、現在プレビュー版として提供されている Gemini Code Assist ツールを開発しました。これらは、Gemini Code Assist のチャット内からアクセスできる、あらかじめ用意された接続機能で、Google アプリや、Atlassian、Sentry、Snyk といったパートナーの業界をリードするツールからの情報取得に役立ちます。

その他の IDE: Android Studio と Firebase Studio

Gemini Code Assist は、選択した IDE で直接コードを記述、変換、理解するのに役立ちます。そしてこのたび、この機能の対象範囲が拡大したことをお知らせいたします。Gemini Code Assist は Android Studio で、エンタープライズセキュリティとプライバシー機能を備えた AI コーディングサポートを必要とするプロの開発者にご利用いただけるようになりました。

さらに、Gemini Code Assist を活用した Firebase プラットフォーム専用のエージェントを新たに 2 つリリースしました。一つは、新しい Firebase Studio 開発環境内のアプリプロトタイピングエージェントで、アプリのアイデアを UI、バックエンドコード、AI フローを含む完全な機能を持つプロトタイプに変換します。もう一つは、Firebase App Distribution 内のアプリテストエージェントです。これは、エンドツーエンドのテストを生成、管理、実行して、モバイルアプリを本番環境向けに準備します。どちらのエージェントも現在はプレビュー版です。

Gemini Cloud Assist: アプリケーションの運用と管理を簡素化

Gemini Cloud Assist は、Google Cloud 環境におけるアプリケーションライフサイクル全体にわたって AI を活用した支援を提供し、開発者、DevOps チーム、クラウド管理者、SRE が、初期のインフラストラクチャ設計、デプロイ、モニタリング、トラブルシューティングから継続的な最適化まで、アプリケーションをより効果的かつ効率的に管理できるようにします。Gemini Cloud Assist は、チャットインターフェース、専用の AI ガイド付きワークフロー、そして Google Cloud プロダクト内から直接、AI による支援を提供します。コンソールとモバイルの両方で利用できます。Gemini Cloud Assist は現在公開プレビュー版であり、すべての Google Cloud ユーザーにお試しいただけます。

アプリケーションの設計

Gemini Cloud Assist は Application Design Center と統合されており、アプリケーションインフラストラクチャの設計とデプロイを迅速化します。Gemini Cloud Assist を使用して、望ましい成果を自然言語で記述することで、アプリケーションインフラストラクチャを設計できます。たとえば、Gemini Cloud Assist に「3 層の e コマースウェブサイトを設計」または「写真を動画に変換するモバイルアプリを設計」するよう求めると、アーキテクチャ図とアプリケーションテンプレートが自動的に生成され、Gemini で繰り返し改良できます。App Design Center に直接組み込まれたデプロイワークフローにより、これらのアプリケーションテンプレートを Google Cloud に即座にデプロイすることもできます。さらに、これらのテンプレートを限定公開で共有されたカタログを使ってチームに配布したり、Terraform としてエクスポートして他のワークフローとの相互運用性を高めたりすることも可能です。

Gemini Cloud Assist を使用して、自然言語でアプリケーションインフラストラクチャ設計をすばやく生成、改良

調査によるトラブルシューティング

Gemini Cloud Assist Investigations は、トラブルシューティングと問題解決を大幅に加速する、AI を活用した新しいワークフローです。クラウド環境と、包括的なデータセット（ログやエラーのパターン、構成の変更、トラブルシューティングのランブックなど）を活用することで、根本原因をすばやく特定し、緩和策を提示します。

この Investigations のフローには、検出されたエラー、影響を受けたリソース、ユーザーが提供した症状が含まれており、これらを基に Gemini Cloud Assist が生成した観察結果と調査結果の要約が提供されます。Investigations は、エラーやログエントリから直接起動することも、各コンソールページの右上隅にある調査アイコンから起動することもできます。起動後は、チャットで特定の調査に関する質問をしたり、修正を繰り返したりできます。さらに、Gemini Cloud Assist は、調査ケースを Google サポートに簡単に引き継ぐことが可能です。Google サポートは、お客様の同意を得たうえで、調査結果を活用して人間による継続的なサポートを提供できます。Gemini Cloud Assist Investigations は現在、限定公開プレビュー版です。お試しいただくには、こちらからご登録ください。

費用と使用率の最適化

Gemini Cloud Assist は、開発者や DevOps チームだけでなく、FinOps 担当者や財務チームにも、AI を活用した費用管理と費用最適化の機能を提供します。Cloud Hub の費用最適化ダッシュボードでは、開発者と DevOps チームがアプリケーションの費用と使用率に関する分析情報を取得できます。Gemini は、費用と vCPU やメモリなどの使用率のデータを関連付けることで、非効率性を特定し、パーソナライズされた推奨事項を提供します。さらに粒度の高い費用と使用率の分析を実現するため、Cost Explorer では、ヒートマップによる柔軟な可視化を提供し、単一または複数のリソースのコンピューティングとメモリの使用率を集計します。30 日間の履歴データに対応しており、プロジェクト、アプリケーション、Google Cloud プロダクト、リソースタイプでデータ全体をフィルタできます。

Cloud Billing では、過去 1 年間（2024 年 1 月～2025 年 1 月）で、Gemini Cloud Assist の費用レポートをご利用になったお客様が FinOps 作業時間の 100,000 時間以上の削減に成功しています。そして今回、Gemini Cloud Assist を拡張したことで、FinOps ハブ 2.0 により、無駄な費用に関する分析情報や費用最適化の提案といった機能も利用できるようになっています。

Google Cloud 全体への Gemini Cloud Assist のインテグレーション

Google は、Gemini Cloud Assist を Storage Insights、Cloud Observability、Firebase、データセンター、Flow Analyzer、FinOps Hub などのお気に入りの Google Cloud サービスや、セキュリティおよびコンプライアンス関連のサービスに統合することで、既存のワークフロー内で直接 AI による支援を提供しています。

これにより、チャット機能の利便性も向上しています。Gemini Cloud Assist は、アセットとその構成、システムの健全性、指標とログ、費用レポートなど、デプロイに関するコンテキストが豊富になったことで、さらに質の高いサポートを提供できるようになりました。また、BigQuery のコード生成、データベースやストレージの説明といったドメイン固有の専門的なタスクにも対応しています。

Google Cloud で今すぐアプリケーションの構築と管理を始めよう

AI を活用した新しいアプリケーション中心のクラウドにより、組織の未来を支えるアプリケーションの構築と管理が容易になります。

まずは、新しい Google デベロッパープログラムの Enterprise ティアを限定プレビューでお試しいただけます。この新しい特典は、開発者チームやプラットフォームチームに、Google Cloud とその AI プロダクトを安全かつ手頃な価格で試用できる機会を提供します。開発者は、1 シートあたり月額 $75 の定額料金でサンドボックス環境にアクセスして、新しいテクノロジーを試したり、概念実証を構築したり、スキルを向上させたりできます。この特典には、Gemini Code Assist Enterprise、クラウドリソースの割引、Gitlab、Harness、Jetbrains、Snyk とのインテグレーションが含まれるため、開発者はリファレンスアーキテクチャを活用して、一般的な生成 AI アプリケーションパターンを構築できます。この特典について詳しくは、こちらをご覧ください。

このブログで発表された新しいプロダクトと機能に関心のある方へ:

今すぐ Google Cloud コンソールにログインして、Gemini Cloud Assist の機能を体験してください。「Opt（Alt）+ G」を押すか、Gemini ボタンをクリックして、コンソールで Gemini Cloud Assist を起動してください。機能の詳細については、こちらのウェブサイトをご覧ください。
今すぐ Google Cloud コンソールの Cloud Hub にログインして、アプリケーション環境を完全に可視化しましょう。Cloud Hub の費用最適化ダッシュボードをお試しになりたい場合は、こちらからご登録ください。
Gemini Code Assist エージェントのプレビュー版については順番待ちリストへの登録をお願いします。
こちらから登録して、Gemini Cloud Assist Investigation をお試しください。
個人のプロジェクトで Gemini 2.5 を使用するには、お好みの IDE に個人向け Gemini Code Assist 拡張機能をインストールしてください。
Firebase Studio をご確認ください。

Google Cloud Platform、バイスプレジデント兼ゼネラルマネージャー、Brad Calder

Kubernetes クラスタ向けのログ可視化ツール、Kubernetes History Inspector のご紹介

Wed, 26 Mar 2025 01:03:00 +0000

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

コンテナオーケストレーションプラットフォームである Kubernetes は、本質的に複雑な分散システムです。レジリエンスとスケーラビリティを実現する一方で、特にトラブルシューティングの際には、運用が複雑になる場合もあります。Kubernetes には自己修復機能が備わっていますが、問題の根本原因を特定するには、多くの場合、さまざまな独立したコンポーネントのログを詳しく調べる必要があります。

Google Cloud のエンジニアは、大規模で複雑な運用をサポートするなかで、長年にわたりこの Kubernetes のトラブルシューティングの課題に直接取り組んできました。膨大な数のカスタマーサポートチケットを定期的に分析し、ユーザー環境を掘り下げ、集合的な知識を活用して問題の根本原因を特定していくにつれ、Google Cloud サポートチームは Kubernetes 環境内の問題の診断に関する深い専門知識を持つようになりました。この広範な課題に対処するために、チームは Kubernetes History Inspector（KHI）というツールを内製開発し、このたびコミュニティ向けにオープンソースとしてリリースしました。

Kubernetes のトラブルシューティングの課題

Kubernetes では、各 Pod、Deployment、Service、ノード、コントロールプレーンコンポーネントが独自のログストリームを生成します。効果的なトラブルシューティングのためには、これらの異なるログストリームを収集し、関連付けて、分析する必要があります。しかし、コンポーネントごとにログを手動で構成するには、細部に注意を払い、Kubernetes エコシステムを十分に理解する必要があり、これは大きな負担になり得ます。幸い、Google Kubernetes Engine（GKE）などのマネージド Kubernetes サービスでは、ログの収集が簡素化されています。たとえば、GKE は Cloud Logging との組み込みのインテグレーションにより、Kubernetes 環境のあらゆる部分からのログを集約します。この一元化されたリポジトリは、重要な第一歩です。

ただし、ログを収集するだけでは、問題の半分しか解決できません。本当に重要な課題は、それらを効果的に分析することです。Kubernetes の運用で発生する問題の多くは、単一の明確なエラーメッセージで明らかになるわけではありません。問題は実際には一連のイベントとして現れるため、複数のコンポーネントにわたり多数のログエントリ間の因果関係を深く理解することが必要となります。

規模を考えてみてください。中規模の Kubernetes クラスタなら、ログデータは短時間ですぐに数ギガバイトに達し、そこには数万件の個別エントリが含まれます。パフォーマンスの低下、断続的な障害、構成エラーの根本原因を特定するために、この量のデータを手作業で精査するとなると、時間がかかるのはもちろんのこと、人間のオペレーターでは事実上不可能な場合もあります。シグナル対ノイズ比がこれを非常に困難にします。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud コンテナと Kubernetes をお試しいただける $300 分の無料クレジット'), ('body', <wagtail.rich_text.RichText object at 0x7f9ce4d19340>), ('btn_text', '無料で構築を始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectpath=/marketplace/product/google/container.googleapis.com'), ('image', None)])]>

Kubernetes History Inspector のご紹介

KHI は、Cloud Logging によって収集されたログを分析し、各コンポーネントの状態情報を抽出して、時系列で可視化する強力なツールです。また、このタイムラインは元のログデータにリンクされるため、各要素が時間の経過とともにどのように変化したかを追跡できます。

多くの場合、Google Cloud サポートチームがユーザーを支援するのは、時間的制約のある重大な状況のときです。長時間のセットアップやエージェントのインストールを必要とするツールは実用的ではありません。そのため、KHI はコンテナイメージとしてパッケージ化されています。事前のセットアップは不要で、1 つのコマンドで起動できます。

わかりやすいように、画像を使って説明します。GKE クラスタで実行されているサービスで「接続タイムアウト」エラーが発生しているとエンドユーザーから報告があったとします。KHI を起動すると、次のような画面が表示されます。

まず、左側にあるカラフルな横長の長方形に注目してください。これは、ログから抽出された、個々のコンポーネントの状態が時間の経過とともに変化する様子を表した「タイムライン」です。このタイムラインは、Kubernetes 環境の全体像を示しています。一方、インターフェースの右側には、タイムラインで選択したコンポーネントに関連する詳細（元のログ、マニフェスト、その変更履歴）が表示されます。このように KHI では、マクロとミクロの両方の視点から、ログを簡単に探索できます。

それでは、前述の例に戻りましょう。タイムラインの「Ready」の行には、緑とオレンジのセクションが交互に並んでいます。

これは、readiness プローブが失敗（オレンジ）と成功（緑）の間を変動していることを示しています。これが動かぬ証拠となります。これで、トラブルシューティングの取り組みをどこに集中させるべきかが明確になりました。

KHI は、過去の任意の時点でのコンポーネント間の関係を可視化することにも優れています。Kubernetes クラスタ内の複雑な相互依存関係が、わかりやすい方法で提示されます。

KHI と Kubernetes のトラブルシューティングの今後

KHI の機能は、ここで紹介した以外にもたくさんあります。タイムラインの色の実際の仕組み、小さなひし形のマーカーの意味、トラブルシューティングを迅速に行うためのその他の機能などです。これを誰もが利用できるようにするため、KHI をオープンソース化しました。

詳細な仕様、視覚的要素の詳細な説明、独自のマネージド Kubernetes クラスタに KHI をデプロイする方法については、KHI の GitHub ページをご覧ください。現在、KHI は GKE または Google Cloud 上の Kubernetes と Cloud Logging の組み合わせでのみ機能しますが、その機能はまもなく標準のオープンソース Kubernetes の設定に拡張される予定です。

KHI は Kubernetes のログ分析を大きく前進させるものですが、既存の専門知識に取って代わるものではなく、それを補完することを目的としています。効果的なトラブルシューティングのためには、今後も Kubernetes のコンセプトとアプリケーションアーキテクチャの確固たる理解が必要です。KHI は、ログから問題をより迅速かつ効率的に診断できる優れたマップを提供することで、エンジニアの皆様が複雑な状況を乗り越えられるよう支援します。

KHI は、Kubernetes の運用の簡素化に向けた Google の継続的な取り組みの第一歩にすぎません。コンテナ化されたアプリケーションのオブザーバビリティと管理性を高めるために、コミュニティが KHI をどのように使用し、拡張していくのか、楽しみにしています。Kubernetes のトラブルシューティングを簡素化するための取り組みは今後も続きます。皆様もぜひご参加ください。

-テクニカルソリューションエンジニア Kakeru Ishii
-テクニカルソリューションエンジニア Takeie Torinomi

新しい Google Cloud Trace エクスプローラのご紹介

Fri, 28 Feb 2025 01:03:00 +0000

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

分散トレースは、オブザーバビリティスタックの重要な部分であり、アプリケーションのレイテンシやエラーをトラブルシューティングできます。Google Cloud Observability の一部である Cloud Trace は、Google Cloud のネイティブトレーシングプロダクトです。新しい分析バックエンドに加えて、Trace エクスプローラの UI に多くの改善を加えました。

新しい Trace エクスプローラページには、次の情報が表示されます。

Google Cloud プロジェクトベースのトレーススコープ、すべてのスパン / ルートスパン、カスタム属性フィルタを選択できるオプションがあるフィルタバー。
OpenTelemetry の規則に基づいてよく使用されるフィルタを表示する、ファセットスパンフィルタペイン。
一致するスパンの可視化。インタラクティブなスパン期間ヒートマップ（デフォルト）、スパンレートの折れ線グラフ、スパン期間のパーセンタイルグラフなどがあります。
一致するスパンの一覧。ヒートマップで対象のセルを選択することでさらに絞り込むことができます。

新しい Trace エクスプローラの概要

では、これらの新機能と、アプリケーションのトラブルシューティングに役立つ使い方を詳しく見ていきましょう。あなたが、小売ウェブストアアプリケーションの checkoutservice に携わっている開発者だとしましょう。進行中のインシデントがあるため、呼び出しを受けました。

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

このアプリケーションは OpenTelemetry を使用して計測され、トレースデータを Google Cloud Trace に送信します。そのため、Google Cloud コンソールの Trace エクスプローラページに移動し、コンテキストを checkoutservice をホストする Google Cloud プロジェクトに設定します。

調査を開始する前に、管理者から、ウェブショップアプリ全体の本番環境の問題を調査するときは webstore-prod トレーススコープを使用するように勧められていたことを思い出しました。このトレーススコープを使用すると、調査に関連する他の Google Cloud プロジェクトに保存されているスパンを確認できます。

トレーススコープを webstore-prod に設定すると、このトレーススコープに含まれるすべてのプロジェクトのスパンがクエリに含まれるようになります。

[スパンフィルタ] で checkoutservice（1）を選択すると、ページに次の更新が読み込まれます。

[スパンフィルタ] ペインの [スパン名] （2）などの他のセクションは、サービス名で行った選択を考慮した数と割合で更新されます。これにより、検索条件を絞り込んでより具体的にすることができます。
スパンフィルタ バー（3）が更新され、アクティブなフィルタが表示されます。
ヒートマップ可視化（4）が更新され、直近 1 時間の checkoutservice からのスパンのみが表示されます（デフォルト）。期間は、期間選択ツール（5）を使用して変更できます。ヒートマップの X 軸は時間、Y 軸はスパン期間です。色の濃淡で各セルのスパンの数が表示され、対応する範囲を示す凡例も示されます。
[スパン] テーブル（6）が更新され、一致するスパンが期間で並べ替えられます（デフォルト）。
切り替え可能な他の [グラフビュー]（7）も、適用されたフィルタで更新されます。

ヒートマップを見れば、100 を超える範囲のスパンがいくつかあることがわかります。これは異常で、問題があります。しかし、まず、checkoutservice によって処理される呼び出しのトラフィックと対応するレイテンシについて調べることにしました。

スパンレートの折れ線グラフに切り替えると、サービスで処理されるトラフィックを確認できます。X 軸は時間、Y 軸は 1 秒あたりのスパン数です。過去の経験から、1.5～2 スパン/秒がごく普通であることがわかっているため、サービスで処理されるトラフィックは正常に見えます。

スパン期間パーセンタイルグラフに切り替えると、50 / 90 / 95 / 99 パーセンタイルのスパン期間の傾向が表示されます。50 パーセンタイルは問題ないように見えますが、90 パーセンタイル台の期間がサービスに対する想定よりも長くなっています。

ヒートマップグラフに戻り、外れ値のセルを選択して詳細を確認します。このセルには、期間が 2 分を超える、2 つの一致するスパンが含まれています。これは問題です。

完全なトレースを表示してこれらのスパンの一つを調査したところ、orders publish スパンがこのリクエストの処理にかかる時間の大部分を占めていることがわかりました。そのため、checkoutservice がこのような呼び出しの処理に問題を抱えているという仮説を立てます。仮説を検証するために、rpc.method 属性が PlaceOrder であることをメモし、X ボタンを使用してこのトレースを終了します。

フィルタバーを使用して、キー: rpc.method、値: PlaceOrder の属性フィルタを追加すると、サービスで処理される PlaceOrder 呼び出しに明らかなレイテンシの問題があることがわかります。この問題を以前に経験しており、この問題に対処するランブックがあることを知っているので、インシデントを軽減するために取るべき適切なアクションを SRE チームに警告します。

[フィードバックを送信] ボタンからフィードバックをお寄せください。

舞台裏

この新しいエクスペリエンスは、ログ分析の基盤となるものと同じプラットフォームを使用して、BigQuery を活用しています。このプラットフォームを最大限に活用する新しい機能（SQL クエリ、柔軟なサンプリング、エクスポート、リージョンストレージ）をリリースする予定です。

まとめると、新しい Cloud Trace エクスプローラを使用して、トレースデータの高度なクエリと可視化を行い、サービス指向の調査を実行できます。これにより、開発者と SRE は、本番環境のインシデントを効果的にトラブルシューティングし、通常の運用を復元するための緩和策を特定できます。

新しい Cloud Trace エクスプローラはすべてのユーザーに一般提供されています。ぜひお試しいただき、[フィードバックを送信] ボタンからフィードバックをお寄せください。

-プロダクトマネージャー Sujay Solomon
-エンジニアリングマネージャー Punya Biswal

Cloud SQL Enterprise Plus エディションに搭載された Query Insights の最新機能でデータベースのボトルネックを迅速に解消

Thu, 13 Feb 2025 03:00:00 +0000

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

Cloud SQL Enterprise Plus エディションでは、読み取りと書き込みのパフォーマンスが強化されており、要件の厳しいアプリケーションの高いパフォーマンスと可用性を確保できます。ただし、多くの場合、高パフォーマンスのアプリケーションでは、基盤として利用するデータベースサービスのチューニングが必要になります。

アプリケーションデベロッパーやデータベース管理者が高パフォーマンスのアプリケーションをビルドおよびデプロイできるように、Cloud SQL Enterprise Plus エディションの Query Insights に新機能が追加されました。今回追加されたデータベースオブザーバビリティサービスは Cloud SQL Enterprise エディションの既存の Query Insights 機能を基盤に構築されています。統合された包括的なオブザーバビリティ機能により、デベロッパーやデータベースチームはこれまで以上に迅速にパフォーマンスを最適化できます。Cloud SQL Enterprise Plus エディションの Query Insights は、クエリのテレメトリと統計情報を収集し、主要なパフォーマンス指標、診断レポート、パフォーマンス向上のための推奨事項を使いやすい形式で Google Cloud コンソールに表示します。これらのシグナルと推奨事項を活用することで、アプリケーションデベロッパーやデータベースチームはデータベースの全体的なパフォーマンスの確認とチューニングをより迅速、簡単、かつ効率的に行えるようになります。

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

Cloud SQL Enterprise Plus エディションの Query Insights の新しい拡張機能を使って実現できることは、次のとおりです。

データベースのパフォーマンスに関する複雑な問題をこれまで以上に迅速に解決する。待機イベントなどの詳細なデータベース指標にアクセスし、根本原因について踏み込んだ分析を行うことができます。準リアルタイムの詳細な診断情報を使って、クエリ実行を簡単にきめ細かく分析することができます。さらに、Cloud SQL Enterprise Plus エディションの Query Insights は一意のクエリ実行すべてのプランを収集し、各クエリ実行のレート決定ステップをハイライト表示することで、クエリプランの回帰の発生を容易に検出できるようにします。
アクティブなクエリ実行を制御する。システムで現在実行中のクエリを可視化できます。また、最適な状態で実行されていないクエリを停止することで、他の重要なクエリのブロックを解除して、システムリソースをより適切に管理することも可能です。
動的なワークロード向けにカスタマイズされたインテリジェントな推奨事項を利用してデータベースのパフォーマンスを向上させる。Cloud SQL Enterprise Plus エディションの Query Insights は、自動的にワークロードを分析してパフォーマンスの問題をハイライト表示するとともに、問題を解決するための推奨事項を提供します。インデックスの欠落、フラグの欠落、フラグの誤りなどの一般的な問題を検出し、クエリの最適化とデータベースのチューニングを実現します。
AI 搭載のチャットインターフェースを使ってパフォーマンスに関する質問をする。Cloud SQL Enterprise Plus エディションの Query Insights には、AI 搭載の自然言語インターフェースが備わっています。このインターフェースから、複雑なデータベースの問題を簡単に解決するための高度なトラブルシューティングのヒントやカスタマイズされた推奨事項が得られます。

これらの機能について詳しく見ていきましょう。

30 日間のテレメトリによる詳細なクエリプラン

30 日分のテレメトリデータを使用して、長期的なトレンドを分析し、繰り返し発生しているクエリのパフォーマンスの問題を特定できます。また、詳細なクエリ実行プランを確認して時系列で比較することで、効率の悪い箇所を特定してデータドリブンな最適化を行い、持続的にデータベースを改善することが可能になります。

履歴分析と時系列の実行プランによるクエリパフォーマンスの最適化

待機イベント

Query Insights では、待機イベントを確認することで、ディスク I/O やロックなど、データベースの処理が滞っている箇所を特定できます。それにより、パフォーマンスのボトルネックをより迅速に診断し、効率的にリソースを最適化できるようになります。

待機イベントによるクエリパフォーマンスの診断と最適化

インデックスに関する推奨事項

インデックスに関する推奨事項は、インデックスの欠落を検出して、クエリのパフォーマンスを向上させるための正確かつ実行可能な推奨事項を提供します。これにより、パフォーマンスのボトルネックを容易に特定できるようになります。推奨事項は、具体的なインデックス作成 SQL コマンドを示したうえで、そのコマンドがパフォーマンスに与えうる影響を表示したり、影響を受けるクエリをハイライト表示したりすることで、データベースパフォーマンスを最適化するプロセスを効率化します。

インデックスに関する推奨事項によるクエリパフォーマンスの向上

使ってみる

Cloud SQL Enterprise Plus エディションの Query Insights は、Google Cloud のマネージドデータベース上にあるティア 1 ワークロードに対してエンタープライズクラスのオブザーバビリティを利用しやすくします。これらの高度なパフォーマンス管理機能を活用することで、複雑なワークフローの簡素化、データベースの健全性のモニタリング、より適切なクエリの記述を実現し、システムのパフォーマンスを大幅に最適化できます。これにより、データベースパフォーマンスの問題の平均解決時間が短縮し、アプリケーションデベロッパーやデータベースチームがコアとなるビジネスロジックに集中することを可能にします。

現在、Cloud SQL Enterprise Plus エディションでは Query Insights のプレビュー版が利用可能です。コンソールから Query Insights にアクセスするだけで、データベースパフォーマンスのモニタリングと管理を開始できます。Query Insights の利用を開始するには、こちらのドキュメントをご覧ください。

-プロダクトマネージャー Karan Thapar
-プロダクトマネージャー Mukesh Marodia

kro で Kubernetes のデベロッパーエクスペリエンスをシンプルに

Wed, 12 Feb 2025 01:05:00 +0000

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

このたび、Kube Resource Orchestrator（kro、発音は crow と同じ）に関する Google Cloud、AWS、Azure のコラボレーションを発表できることを嬉しく思います。kro は、クラウドに依存しない Kubernetes ネイティブな方法で Kubernetes リソースのグループ化を定義するものです。kro を使用すると、アプリケーションとその依存関係を単一のリソースとしてグループ化でき、エンドユーザーが簡単に利用できるようなります。

Kubernetes リソースのオーケストレーションにおける課題

プラットフォームチームや DevOps チームは、アプリケーションチームによるワークロードのデプロイ方法を定義することを望んでおり、こうした基準を作成し、適用するためのプラットフォームとして Kubernetes を使用したいと考えています。各サービスは、リソースの作成、セキュリティの構成、モニタリングの設定、エンドユーザーインターフェースの定義など、あらゆることを処理する必要があります。クライアントサイドのテンプレートツール（Helm、Kustomize など）を利用することもできますが、エンドユーザーが利用するリソースのカスタムグループを作成する場合、Kubernetes にはプラットフォームチームが利用できるネイティブな方法がありません。

そのため、プラットフォームチームは、Kubernetes カスタムコントローラの構築や、Helm のようなパッケージングツールを使用するカスタムソリューションに投資する必要がありましたが、いずれも Kubernetes のカスタムリソース定義（CRD）のメリットを活用できないものでした。こうしたアプローチは構築、維持、トラブルシューティングに費用がかかり、Kubernetes の専門家以外にとっては扱いが困難でした。これは多くの Kubernetes ユーザーが直面する問題です。Google Cloud は、すべての Kubernetes ユーザーが K8s API をよりシンプルに利用できるように、ベンダー固有のソリューションを開発するのではなく、Amazon および Microsoft と協力することを選択しました。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud コンテナと Kubernetes をお試しいただける $300 分の無料クレジット'), ('body', <wagtail.rich_text.RichText object at 0x7f9cd0fc1460>), ('btn_text', '無料で始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectpath=/marketplace/product/google/container.googleapis.com'), ('image', None)])]>

kro がデベロッパーエクスペリエンスを簡素化する仕組み

kro は、Kubernetes ネイティブなフレームワークであり、複数のリソースを単一のユニットとしてデプロイするための再利用可能な API を作成できます。Kubernetes Deployment とその依存関係をカプセル化し、単一の API にまとめることで、Kubernetes に詳しくないアプリケーションチームでも利用できるようになります。kro を使用すると、エンドユーザーが参照するパラメータのみを公開するカスタムのインターフェースを作成できるため、エンドユーザーは Kubernetes やクラウドプロバイダの API の複雑さを感じずに利用できます。

kro は、ResourceGraphDefinition というコンセプトを導入することでこれを実現しています。ResourceGraphDefinition は、標準的な Kubernetes のカスタムリソース定義（CRD）を Kubernetes リソースのセットに拡張する方法を指定します。エンドユーザーは単一のリソースを定義し、kro はそれを CRD で定義されたカスタムリソースに拡張します。

kro は、Kubernetes リソースのグループ化や管理のために使用できます。ACK、KCC、ASO などのツールは、Kubernetes からクラウドプロバイダのリソースを管理するための CRD を定義します（これらのツールにより、ストレージバケットなどのクラウドプロバイダのリソースを Kubernetes リソースとして作成および管理できるようになります）。kro は、これらのツールのリソースを他の Kubernetes リソースとともにグループ化でき、アプリケーションのデプロイ全体と、それに依存するクラウドプロバイダのリソースを定義するためにも使用できます。

サンプルユースケース

以下では、Google Cloud での kro の使用例をいくつか紹介します。その他の例については、kro のウェブサイトをご覧ください。

例 1: GKE クラスタの定義

この例では、プラットフォーム管理者が、組織内のエンドユーザーに GKE クラスタの作成をセルフサービスで許可するとします。プラットフォーム管理者は、必要な Kubernetes リソースを定義する GKEclusterRGD という名前の kro ResourceGraphDefinition と、エンドユーザーが構成できるオプションのみを公開する GKEcluster という名前の CRD を作成します。クラスタの作成に加えて、プラットフォームチームは、ポリシーやエージェントなどの管理ワークロードをクラスタがデプロイすることも望んでいます。ResourceGraphDefinition は以下のリソースを定義し、KCC を使用して K8s CRD から Google Cloud API へのマッピングを提供します。

GKE クラスタ、コンテナノードプール、IAM サービスアカウント、IAM ポリシーメンバー、サービス、ポリシー

次に、プラットフォーム管理者は、エンドユーザーインターフェースを定義し、CRD のインスタンスを作成することで新しいクラスタを作成できるようにします。CRD では以下のことを定義します。

クラスタ名、ノードプール名、最大ノード数、ロケーション（us-east1 など）、ネットワーク（省略可）

ポリシー、サービスアカウント、サービスアクティベーション（および、これらのリソース間の関係）に関連する情報はいずれもエンドユーザーに表示されないため、エクスペリエンスが簡素化されます。

例 2: ウェブ アプリケーションの定義

この例では、DevOps エンジニアがウェブアプリケーションとその依存関係の再利用可能な定義を作成するとします。WebAppRGD という名前の ResourceGraphDefinition を作成し、WebApp という名前の新しい Kubernetes CRD を定義します。この新しいリソースは、ウェブアプリケーション環境に必要なすべてのリソースをカプセル化します。リソースには以下のものが含まれます。

デプロイ、サービス、サービスアカウント、モニタリングエージェント、クラウドリソース（オブジェクトストレージバケットなど）

WebAppRGD ResourceGraphDefinition は、デフォルト構成を設定できるほか、デプロイ時にエンドユーザーが設定できるパラメータを定義することもできます（kro を使用することで、変更不可とするものと、エンドユーザーが構成できるものを柔軟に決定できます）。次に、開発者はユーザー向けのパラメータを入力して、WebApp CRD のインスタンスを作成します。その後、kro が必要な Kubernetes リソースをデプロイします。

kro の主なメリット

kro は、プラットフォームエンジニアリングチームにとって大きな前進であり、以下のような多くのメリットをもたらします。

Kubernetes ネイティブ: Kubernetes カスタムリソース定義（CRD）を活用して Kubernetes を拡張でき、あらゆる Kubernetes リソースと連携して、既存の Kubernetes ツールやワークフローと統合できます。
シンプルなエンドユーザー エクスペリエンスを実現: Kubernetes リソースの複雑なグループに対してエンドユーザーインターフェースを簡単に定義できるため、Kubernetes の専門家でなくても Kubernetes に構築されたサービスを利用しやすくなります。
アプリケーション チーム向けに標準化されたサービスを実現: kro のテンプレートは、さまざまなプロジェクトや環境で再利用できるため、整合性が促進され、作業の重複を軽減できます。

kro を使ってみる

kro は、GitHub のオープンソースプロジェクトとして利用できます。GitHub の組織は現在、Google、AWS、Microsoft の各チームが共同で所有しており、コミュニティからの貢献を歓迎しています。また、こちらのウェブサイトでは、kro のインストールや使用に関するドキュメント、使用例、ユースケースなどを提供しています。kro は初期段階のプロジェクトであるため、まだ本番環境での使用には適していませんが、ぜひお客様の Kubernetes 開発環境でテストしてみてください。

-シニアクラウドデベロッパーアドボケイト、Abdelfettah Sghiouar
-プロダクトマネージャー、Nic Slattery

Database Center が Bigtable、Firestore、Memorystore に対応

Fri, 24 Jan 2025 01:15:00 +0000

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

Google Cloud の Database Center は、大規模なデータベース管理に役立つ統合フリート管理ソリューションです。2024 年 10 月に、Google Cloud をご利用のすべてのお客様に提供開始され、Cloud SQL、AlloyDB、Spanner の各エンジンに対応していました。

このたび、Database Center の機能が拡張され、Bigtable、Memorystore、Firestore の各データベースへの対応がプレビュー版として公開されることになりました。この機能拡張により、単一の統合ビューで次のことができるようになります。

すべての Google Cloud マネージドデータベースにわたり、データベース フリートを包括的に把握できます。これにより、情報のサイロ化が解消され、専用のツールやスプレッドシートで情報を探す必要がなくなります。
データベース フリートのリスクを未然に回避できます。Bigtable と Firestore の各データベースの可用性やデータ保護について、インテリジェントで実用的な推奨事項が提示されます。
AI を活用したデータベース フリートの最適化が可能です。自然言語のインターフェースですべての Google Cloud データベースに関する疑問を解消し、最適化された推奨事項を通じてフリートの問題を迅速に解決できます。

Bigtable、Memorystore、Firestore 向けの Database Center の新機能について詳細を見ていきましょう。

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

データベースフリートを包括的に把握

Database Center では、Bigtable、Memorystore、Firestore を含め、すべての Google Cloud マネージドデータベースサービスを単一の統合ビューで確認できるため、データベース管理が簡素化されます。ラベルを使用して、組織全体で複数のエンジン、バージョン、リージョン、プロジェクト、そして環境やアプリケーションにわたり、データベースリソースをモニタリングできます。具体的に Database Center で可能になったことは次のとおりです。

古いデータベースバージョンを特定し、適切なサポートと信頼性を確保する
バージョンアップグレードをトラッキングする（たとえば、Memorystore Redis 6.x から Memorystore Redis 7.0 / 7.2 へのアップデートが予想どおりのペースで行われているかどうか）

データベースリソースが適切に分散されていることを確認する（たとえば、重要な本番環境のアプリケーションと、重要ではない開発環境やテスト環境で使われている Bigtable、Firestore、Memorystore の各データベースの数を特定する）

フリート全体で幅広いデータベースの問題を検出、トラブルシューティングする。

インテリジェントな推奨事項により、データベースフリートのリスクを未然に回避

Database Center のプロアクティブモニタリング機能と問題解決機能も、Bigtable と Firestore に対応するよう拡張されました。これにより、既存のデータベースフリートの可用性とデータ保護が最適化されます。Database Center の機能の例を以下に示します。

Bigtable インスタンスをプロアクティブにモニタリングします。フェイルオーバーのギャップを検出し、解決を支援することで、ダウンタイムを最小限に抑え、サービスの中断を防ぎます。
Bigtable インスタンスのバックアップ失敗や自動バックアップポリシーの欠如があった場合や、バックアップ保持期間が短い場合には、それに関する推奨事項を提示します。データを復元するには、こうした問題に迅速に対処することが重要です。
Bigtable インスタンスのシステム障害やリージョンの停止を防ぐことで、データの可用性と耐久性を高めます。
Firestore で、自動バックアップポリシーがないテーブルがないかどうか検出することで重要なデータを守り、事故や破損に起因するデータ損失を防ぎます。

簡単に言うと、Database Center は、問題が発生したときに、直感的なトラブルシューティング手順を案内することで解決を効率化し、Bigtable や Firestore のデプロイのダウンタイムを最小限に抑えます。問題を特定するだけでなく、明確で実用的な解決策も提示します。Memorystore の推奨事項も、他のエンジンの追加の推奨事項とともに、近々 Database Center に導入される予定です。

フリート全体で幅広いデータベースの問題を検出、トラブルシューティングする。

AI を活用したアシスタンス機能でデータベースフリートを最適化

Gemini を有効にすると、Database Center でのデータベースフリートの最適化が非常に直感的になります。AI 搭載インターフェースと話して、正確な回答を得たり、データベースフリート内の問題を明らかにしたり、問題をトラブルシューティングしたり、解決策を実施したりできます。Database Center の AI 搭載チャットは現在、Bigtable、Memorystore、Firestore に対応しています。たとえば、Gemini を使用して、自動バックアップポリシーがない Firestore リソースを迅速に特定できます。

Bigtable、Memorystore、Firestore のデータベースについて質問ができる自然言語インターフェース。

Database Center を早速使ってみる

今回のリリースにより、Database Center は、すべての Google Cloud マネージドデータベースにわたり、単一の統合ビューを提供するようになりました。Google Cloud コンソール内で Database Center にアクセスし、データベースフリート全体のモニタリングと管理を開始できます。Database Center の機能の詳細については、ドキュメントをご覧ください。

-Google Cloud データベース、シニアプロダクトマネージャー Kiran Shenoy

-Google Cloud データベース、プロダクトマネージャー Apoorv Shrivastava

Palo Alto Networks、Personalized Service Health でインシデントの解決を迅速化

Fri, 24 Jan 2025 01:10:00 +0000

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

クラウドインシデントの発生は避けられません。インシデントの発生時に、その内容について、影響を受けるお客様に迅速かつ効果的に伝えるのがクラウドサービスプロバイダの責任です。クラウドサービスのお客様は、その情報をインシデント管理対応の一環として効果的に使用しなければなりません。

Google Cloud Personalized Service Health は、Google Cloud のサービス障害について、透明性と関連性のある実用的な通知を迅速に提供するもので、企業ごとに詳細レベルのカスタマイズが可能です。Google Cloud のパートナーであり、お客様でもある、サイバーセキュリティ企業の Palo Alto Networks は最近、Google Cloud ベースの Prisma Access サービスのインシデントワークフローに Personalized Service Health のシグナルを統合し、サービスの利用者がインシデント発生中に貴重な時間を節約できるようにしました。

プログラムを使って Personalized Service Health のシグナルを高度なワークフローコンポーネントに取り込むことで、Palo Alto Networks はビジネスの継続性を守るために緊急時対応を発動するかどうかなどの意思決定を迅速に行うことができます。

Palo Alto Networks がどのように Personalized Service Health を運用に取り入れたのか詳しく見ていきましょう。

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

Personalized Service Health の導入

Palo Alto Networks は、Prisma Access のインシデント通知を一元管理している自社の AIOps システムに、Personalized Service Health のログを取り込んでいます。ここで高度な技術を活用して、シグナルを分類し、対象インシデントの対応担当者に配信します。

Personalized Service Health の UI のインシデントリスト表示

Personalized Service Health のユーザーは、表示する関連性レベルをフィルタできます。「部分的に関連」は、使用中のサービスにおいて世界のどこかで発生した問題を反映しています。「関連」はデータセンターリージョン内で検出された問題を反映し、「影響あり」は、特定のサービスについて、そのお客様への影響を Google が確認したことを意味します。

Google がまだ確認中のインシデントの一部は、Personalized Service Health で「PSH の新しいインシデント」としてお客様に早期に通知されます。Google が確認したインシデントは「PSH の確認済みインシデント」と統合されます。この仕組みによって、お客様は環境に影響を及ぼしている特定のインシデントに、より迅速に対応し、必要に応じて Google にエスカレーションできます。

Personalized Service Health は、インシデント発生中に、通常は 30 分ごとに最新情報を配信し、進捗があった場合はその時点で知らせます。この情報はログにも書き込まれるため、Palo Alto Networks はこれを AIOps に取り込んでいます。

プログラムを使ってインシデントを取り込み、通知を配信することで、クラウドサービスプロバイダで発生した、中断を伴う想定外のインシデントへの対応を迅速化できます。この方法は、アプリケーション、ワークロード、お客様ごとに異なるチームがインシデント対応に関わる Palo Alto Networks のような大規模な組織で特に有効です。

インシデントライフサイクルの促進

Palo Alto Networks は、取り込んだ Personalized Service Health のシグナルを自社の AIOps プラットフォームでさらに活用しています。AIOps では、ML と分析機能を使って IT 運用を自動化し、運用アプライアンスからのビッグデータを利用して問題の検出と対応を瞬時に行っています。AIOps はこれらのシグナルと、社内で生成されたアラートを照合し、複数のお客様に影響を及ぼしているインシデントを宣言します。AIOps のアラートは、通知、定期的な最新情報の配信、インシデント対応など、インシデントライフサイクルの管理を支える他のインシデント管理ツールに関連付けられています。

また、データ拡充パイプラインが、Personalized Service Health のインシデントに Palo Alto Networks の関連情報を追加し、イベントを Pub/Sub にパブリッシュします。その後、AIOps が Pub/Sub からのインシデントデータを取り込み、処理し、関連するイベントシグナルと照合して、サブスクライブしているチャンネルに通知します。

Palo Alto Networks は Google Cloud のアセットを Google Cloud コンソール内でフォルダに分けています。プロジェクトはそれぞれ Palo Alto Networks の Prisma Access のお客様を表しています。同様にエンドカスタマー固有のインシデントシグナルを受け取るために、Palo Alto Networks は各フォルダに固有のログシンクを作成し、Service Health のログをフォルダレベルで集約しています。そうすることで、それぞれのお客様に固有のインシデントシグナルを受け取り、さらなる対応をとることができます。

Palo Alto Networks は、Google Cloud から受け取るインシデント通知に基づき、以下の対応を推進しています。

ゾーン障害、リージョン間障害、外部の一斉障害を事前に検出
クラウドプロバイダのインシデントの影響を受けるワークロードを正確に特定
Google Cloud Platform 内のクラウドサービスの低下に起因するプロダクト問題の照合

Personalized Service Health の価値の認識

クラウドプロバイダ側に原因があるインシデントは、多くの場合、気づかれないまま終わるか、クラウドプロバイダ側の複数のチーム（サポート、エンジニアリング、SRE、アカウント管理）の関与なく分離するのが困難です。Personalized Service Health のアラートフレームワークと AIOps の照合エンジンを組み合わせることにより、Palo Alto Networks の SRE チームはクラウドプロバイダ側に原因がある問題をほぼ瞬時に分離できます。

Palo Alto Networks のインシデント管理ワークフローは、個別のお客様の障害よりも大規模な障害に対応するよう設計されており、インシデントが解決するまで適切なチームが関わることになっています。これには、オンコールエンジニアや Google Cloud サポートチームなどの関係者への通知も含まれます。Palo Alto Networks は、Personalized Service Health を使用することで、大規模な障害と個別のお客様の障害の両方のイベントタイプを取り込むことができます。

Palo Alto Networks にとって Personalized Service Health の価値は複数あり、特に影響を受ける Prisma Access のお客様を対象とする、インシデント対応の迅速化や、緊急時対応によるビジネスの継続性の最適化が挙げられます。Prisma Access のお客様に影響を及ぼすインシデントが発生した場合、お客様は当然、Palo Alto Networks に情報を求め、期待します。この情報を Google Cloud から Palo Alto Networks のインシデント対応システムに迅速に取り込むことで、Palo Alto Networks はこうしたエンドカスタマーに、より明確な回答を提供できます。また、Palo Alto Networks は Personalized Service Health の既存機能と将来的な機能に基づき、Palo Alto Networks の他のユースケースにも対応する計画です。

インシデント管理を新たなレベルへ

Google Cloud は、スタートアップから、ISV や SaaS プロバイダ、そして大企業まで、あらゆるお客様により深い価値を提供できるよう、Personalized Service Health を進化させ続けています。ご関心をお持ちの場合は、Personalized Service Health の詳細情報をご覧になるか、Google のアカウント担当者までお問い合わせください。

^{Palo Alto Networks と Google Cloud のコラボレーションにご協力いただいた Google の Pankhuri Kumar と Sudhanshu Jain に感謝いたします。}

-Palo Alto Networks、シニアスタッフサービス信頼性エンジニア、Sabitha Muppuri 氏

-Google Cloud、カスタマーテレメトリー担当プロダクトリーダー、Flemming Christensen

管理ツール

Unified Maintenance: Google Cloud 全体のメンテナンスを管理するための新たな統合ソリューション

次のステップ

広範な OTLP 対応に向けて: Cloud Monitoring が OpenTelemetry Protocol 指標をサポート

指標向け OTLP: 「新標準」以上の意味

Google Kubernetes Engine 向けマネージド OpenTelemetry

ご利用方法

OpenTelemetry Protocol が Google Cloud Observability に登場

Google の ADK を使ったエージェント アプリケーションを Datadog LLM Observability でモニタリングする

エージェントの判断と予期しない挙動をトレース

トークン使用量とレイテンシをモニタリング

エージェントの応答品質とセキュリティを評価

テストを通じて、迅速かつ確信を持って改善を重ねる

Datadog LLM Observability を使ってみる

VM OS エージェントの大規模な管理を簡素化: VM Extensions Manager のご紹介

VM Extensions Manager の使用を開始する方法

標準化と管理のための柔軟なシステム

Workload Manager を使用して FinOps の費用管理ポリシーを自動化する

手動 FinOps の課題

FinOps ポリシーの自動化: 手順ガイド

Looker Studio で分析結果を可視化する

今すぐクラウド費用を管理

ログ分析クエリビルダーの導入: ログの分析がより簡単に

課題: SQL の記述がボトルネックになる場合

解決策: 直感的なクエリ作成エクスペリエンス

主な機能の概要

デモ: クエリビルダーの威力を実際に確認

次のステップ: ログ分析におけるクエリの未来

今すぐ使用を開始する

OpenTelemetry Protocol が Google Cloud Observability に登場

Cloud Trace と OTLP の実例

OTLP に関する Google Cloud のビジョン

使ってみる

推測にとどまらず、徹底的に調べましょう。Gemini Cloud Assist で根本原因分析が利用可能に

Gemini Cloud Assist の調査の仕組み

Gemini Cloud Assist Investigations を今すぐ使ってみましょう

Cloud Hub の最適化と Cost Explorer を使用してクラウド費用を最適化する

アプリケーションの費用と使用率

Google Cloud で実行される SAP ワークロードのシステム中心のモニタリングとオブザーバビリティ

複雑な SAP 環境の可視性の拡大

Workload Manager でシステム中心の統合ビューを作成

その他の主な機能と利点

ご利用の開始

今後の展望

Datadog が Google Cloud スタック全体における新しいインテグレーションにより AI オブザーバビリティ機能を拡張

AI を活用してデータベース フリート管理の簡素化を実現するデータベース センターの一般提供を開始

データベース センターの最新情報

データベース センターのお客様の声

データベース センターにアクセスする方法

インシデント対応に AI を活用する: Personalized Service Health と Gemini Cloud Assist のインテグレーション

Personalized Service Health の一般提供を開始: 今すぐ始めましょう

開発者とオペレーター向けにアプリケーション中心の AI を活用したクラウドを実現

Cloud Hub は、Google Cloud 上のアプリケーション環境の統合ビューを実現します。

Gemini Cloud Assist を使用して、自然言語でアプリケーション インフラストラクチャ設計をすばやく生成、改良

Kubernetes クラスタ向けのログ可視化ツール、Kubernetes History Inspector のご紹介

Kubernetes のトラブルシューティングの課題

Kubernetes History Inspector のご紹介

KHI と Kubernetes のトラブルシューティングの今後

新しい Google Cloud Trace エクスプローラのご紹介

新しい Trace エクスプローラの概要

舞台裏

Cloud SQL Enterprise Plus エディションに搭載された Query Insights の最新機能でデータベースのボトルネックを迅速に解消

kro で Kubernetes のデベロッパー エクスペリエンスをシンプルに

Kubernetes リソースのオーケストレーションにおける課題

kro がデベロッパー エクスペリエンスを簡素化する仕組み

サンプル ユースケース

kro の主なメリット

kro を使ってみる

Database Center が Bigtable、Firestore、Memorystore に対応

データベース フリートを包括的に把握

インテリジェントな推奨事項により、データベース フリートのリスクを未然に回避

AI を活用したアシスタンス機能でデータベース フリートを最適化

Database Center を早速使ってみる

Palo Alto Networks、Personalized Service Health でインシデントの解決を迅速化

Personalized Service Health の導入

インシデント ライフサイクルの促進

Personalized Service Health の価値の認識

インシデント管理を新たなレベルへ

Google の ADK を使ったエージェントアプリケーションを Datadog LLM Observability でモニタリングする

AI を活用してデータベースフリート管理の簡素化を実現するデータベースセンターの一般提供を開始

データベースセンターの最新情報

データベースセンターのお客様の声

データベースセンターにアクセスする方法

Gemini Cloud Assist を使用して、自然言語でアプリケーションインフラストラクチャ設計をすばやく生成、改良

kro で Kubernetes のデベロッパーエクスペリエンスをシンプルに

kro がデベロッパーエクスペリエンスを簡素化する仕組み

サンプルユースケース

データベースフリートを包括的に把握

インテリジェントな推奨事項により、データベースフリートのリスクを未然に回避

AI を活用したアシスタンス機能でデータベースフリートを最適化

インシデントライフサイクルの促進