クラウドオペレーション

柔軟な確約利用割引 - Compute Engine インスタンスを割引するシンプルで新しい方法

Wed, 16 Nov 2022 05:00:00 +0000

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

節約は流行に左右されません。多くのお客様が Compute Engine リソースベースの確約利用割引（CUD）を利用して、特定のマシンファミリーやリージョンにおける定常状態のコンピューティング使用量を対象に、費用の削減を図っています。今回、より柔軟で簡単な支出管理方法を提供するための取り組みの一環として、Compute Engine の新しいタイプの確約利用割引であるフレキシブル CUD を提供します。

フレキシブル CUD は、予測可能かつシンプルな定額割引（1 年間で 28% 割引、3 年間で 46% 割引）で、複数の VM ファミリーとリージョンに適用される、支出ベースのコミットメントです。リソースベースの CUD と同様に、同じ請求先アカウント内のプロジェクト間や、異なるサイズやテナンシーの VM に柔軟な CUD を適用し、コストを抑えながら変化するワークロード要件に対応できます。

現在、Compute Engine のフレキシブル CUD は、すべてのリージョンにおいて、インスタンスの CPU とメモリ使用量を含む、ほとんどの汎用 VM の使用量（N1、N2、E2、N2D）およびコンピューティング最適化（C2、C2D）のための VM 使用量で利用できます（今後増える VM ファミリーの完全リストを参照してください）。

リソースベース CUD と同様に、フレキシブル CUD は使用量に対する割引であり、容量の予約ではありません。容量を確保するために、別途予約をしていただくと、その結果、対象となる使用量に対して自動的に CUD が適用されます。

CUD は、どの請求先アカウントからでも購入できます。割引は、その請求先アカウントによって支払われたプロジェクトで、対象となる使用量に適用できます。フレキシブル CUD を購入すると、使用量がこのコミットメント値を下回っても、コミットメント期間中はずっと同じコミットメント料を支払うことになります。コミットメント料金は月単位で請求されます。一度購入したコミットメントは取り消すことができません。

節約と柔軟性を両立させるためには、リソースベース CUD とフレキシブル CUD を併用することをおすすめいたします。最も安定したリソース使用量をカバーする標準的なリソースベースの CUD と、よりダイナミックなリソース使用量をカバーする柔軟な支出ベースの CUD を設定できます。1 時間ごとに、まず標準 CUD が適用され、次にフレキシブル CUD が適用されるので、CUD の使用を最適化できます。また、CUD の対象とならない使用量については、オンデマンドの料金で請求されます。

リソースベース CUD とフレキシブル CUD の違いを簡単にまとめると、以下のようになります。

フレキシブル CUD に関するお客様の声

「Media.net は動的なリソースの要件を抱えるグローバル企業です。フレキシブル CUD により、Media.net はベースラインのワークロード要件を迅速かつ容易に節約でき、同時に異なるマシンタイプやリージョンを柔軟に利用できるようになりました。Media.net は、急増するワークロードに対応するためにさまざまな選択肢を検討した結果、Spot VM を選択しました。大幅な割引が受けられるうえ、料金体系がシンプルで費用が予測可能だからです。フレキシブル CUD とスポット VM の組み合わせは、ビジネスのダイナミックな容量のニーズに対してコストを最適化するための完璧な組み合わせでした。」 - Media.net、エンジニアリング担当シニアバイスプレジデント、Amit Bhawani 氏

「Lucidworks がプロダクトの提供を拡大する中で、Google Cloud のフレキシブル CUD は、お客様の属性に基づいてワークロードを異なる地域にシフトしたり、パフォーマンス特性に基づいて異なるインスタンスファミリーにシフトする柔軟性を与えながら、コストを最適化する完璧なソリューションとなりました。」- Lucidworks、クラウドガバナンスセキュリティ担当ディレクター、Matt Roca 氏

フレキシブル CUD の理解

フレキシブル CUD は、Google Cloud コンソールまたは API 経由で購入できます。フレキシブル CUD は購入から 1 時間後に発効され、対象となる使用量に対して自動的に割引が適用されます。

フレキシブル CUD は、対象となるオンデマンドの使用料に時間単位で適用されます。ある時間帯に、コミットした金額よりも少ない金額しか使わなかった場合、コミットした金額を十分に活かすことができず、割引を十分に実感できません。

たとえば、毎時 100 ドルのオンデマンド支出をフレキシブル CUD でカバーしたい場合、3 年間は毎時 54 ドル（46% オフ）を支払い（月払い）、対象となるオンデマンド支出に自動的に適用される 100 ドルのクレジットを受け取ることができます。100 ドルのクレジットは、対象となる SKU ごとに、対象となるオンデマンド料金で消費され、未使用の場合は失効します。

フレキシブル CUD のクレジットの付与

同じ請求先アカウント内で複数のプロジェクトを実行している場合、フレキシブル CUD からのクレジットは、請求先アカウント内のプロジェクト間および同じプロジェクト内の SKU 間で、使用比率に応じて比例配分されます。

フレキシブル CUD 購入のためのプランニング

リソースベース CUD およびフレキシブル CUD の購入と使用を検討する場合、まず定常状態のリソース使用量を予測してリソースベース CUD を購入し、最も大きな割引を得ることをおすすめします。ベストプラクティスは、ワークロードがより可変的で増大する場合にはフレキシブル CUD を使用し、それ以外の用途にはオンデマンド VM、または Spot VM を使用することです。

今すぐフレキシブル CUD を始める

クラウドでのビジネス構築は複雑な場合がありますが、それに関する支払いは簡単であるべきです。フレキシブル CUD の設計により、Google Cloud のさまざまなリソースで大幅な割引を簡単に受けることができるようになりました。フレキシブル CUD の購入方法、使用方法、開始方法について詳しくは、こちらのドキュメントをご覧ください。

-プロダクトマネージャー、Yasmin Mowafy

App Engine および Cloud Functions の Java 17、Ruby 3、Python 3.10、PHP 8.1 の一般提供 / プレビュー版提供を開始

Mon, 25 Apr 2022 02:00:00 +0000

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

豆（Java）、宝石（Ruby）、ヘビ（Python）、象（PHP）をお使いのサーバーレスデベロッパーの皆様に朗報をお届けいたします。Google App Engine と Cloud Functions に最新のランタイムが追加され、これらのプログラミング言語のメジャーバージョンのリリーストレインを更新できるようになりました。

最新情報を要約すると以下のとおりです。

Java 11/17、Python 3、Go 1.12+ ランタイム向け App Engine レガシーバンドルサービスへのアクセスの一般提供を開始
Java 17、Ruby 3.0、Python 3.10、PHP 8.1 ランタイムの App Engine および Cloud Functions でのプレビュー版提供開始

では、詳しく見ていきましょう。まず、Java、Python、Go の第 2 世代ランタイム向け App Engine のレガシーバンドルサービスへのアクセスの一般提供を開始しました。これまでは、たとえば Java プラットフォームの場合、Java 8（第 1 世代ランタイム）のみが Memcache、画像検索、メール、タスクキューなどの組み込み API にアクセスできました。今後は、Java 11 ランタイム（第 2 世代ランタイム）を使用している場合、これらのサービスや Google Cloud APIs にアクセスできます。たとえば、キャッシュに保存された一時データを Memcache に保存したり、第 2 世代ランタイムにあるアプリケーションのユーザーにメールを送信したりできます。Python や Go のデベロッパーも同様にバンドルサービスを利用できます。まだ古いランタイムバージョンを使用している場合は、これにより新しいバージョンへの移行がさらに簡単になります。ぜひご確認いただき、アップグレードしてください。

次に、App Engine および Cloud Functions 両方の Java 17、Ruby 3.0、Python 3.10、PHP 8.1 ランタイムのプレビュー版について説明します。それぞれのプログラム言語ごとの最新情報は以下のとおりです。

Java

Java 11 および 17 の 2 つの長期サポートバージョンの間に新しい機能が数多く加わりました。Java デベロッパーは、複数の文字列を手動で連結することなく、複数行にまたがる文字列のテキストブロックを記述できるようになりました。switch コンストラクトが進化して式になり、break キーワードから脱却し、より高度なパターンマッチング機能が可能になります。また、instanceof キーワードでは、明らかに無駄なキャストを避けるために、いくつかのパターンマッチングが進化しました。record を使用すると、適切な hashCode()、equals()、toString() メソッドを使用して独自の JavaBeans を記述することなく、より合理的な不変データクラスを作成できます。クラス階層をより細かく制御したい場合、シールクラスを使用することでクラスの拡張をさらに制御できます。

Ruby

Ruby 3.0 の大きな注目ポイントは、パフォーマンス、静的な型チェック、同時実行でした。Ruby 3.0 は一部のベンチマークにおいて Ruby 2.0 の 3 倍高速で動作する目標を達成し、コードをより迅速に実行できるようになりました。また、Ruby プログラムは一部の型情報を使用してアノテーションを付加できるため、型チェッカーはそれらの型情報を利用して静的な型チェックを行い、コードの品質を向上させることができます。同時実行と並列処理に関しては、Ractor と呼ばれるアクターモデルに着想を得た新しい同時実行プリミティブが、要求の高いワークロードに対して複数のコアを並列で処理できるようにします。さらに、ブロッキングオペレーションをインターセプトするための Fiber Scheduler が導入されました。今回ご紹介した以外にも、さまざまな Ruby API に多くの改善が行われました。

Python

Python 3.10 では、パーサーが構文エラーに対しエラーの場所がより正確なエラーメッセージを、またインデント、属性、名前のエラーに対してもさらに明確なエラーメッセージを表示するため、デベロッパーがコード内の問題を見つけるのに非常に役立ちます。構造的パターンマッチングには、新しい match と case のステートメントコンストラクトが導入されました。PEP をさらに改善するため、静的な型チェッカー用のより堅牢な型ヒントの充実を進めています。かっこで囲まれたコンテキストマネージャーが追加され、複数の行にまたがる長いコンテキストマネージャーのコレクションをよりわかりやすくコード化できるようになりました。

PHP

PHP は、バージョン 8.1 でかなりメジャーなアップデートが行われました。まず、クラスで定数を作成する代わりに、新しい enum 構文コンストラクトですぐに検証できるようになりました。また、クラスで final クラス定数を定義できるようになりました。新しい readonly プロパティは初期化後は変更できないため、値オブジェクトや DTO に最適です。第一級 callable 構文が導入され、短い構文で任意の関数への参照を取得できるようになりました。また、イニシャライザの改良により、デベロッパーはオブジェクトをデフォルトのパラメータ値、静的変数、グローバル定数として使用し、ネストされた属性も取得できるようになりました。また、素晴らしいことに、軽量の協調同時実行を実装するためのファイバーも導入されました。

実際に試してみましょう

すべてのデベロッパーの役に立つ素晴らしい機能が、それぞれの言語の新バージョンに追加されました。その結果、Java、Ruby、Python、PHP のデベロッパーは、これらの新しいランタイムのプレビュー版で、お気に入りの言語の最新の優れたバージョンを使用して、新しい App Engine アプリや Cloud Functions を更新および開発できるようになります。App Engine（Java、Ruby、Python、PHP）および Cloud Functions（Java、Ruby、Python、PHP）のドキュメントをぜひご確認ください。これらの言語の新しいランタイムの活用方法について皆さまのご意見をお待ちしております。

- Cloud デベロッパーアドボケイト Guillaume Laforge
- App Engine Java ランタイムテックリード Ludovic Champenois

Google の Vertex AI Vizier を使用したアプリケーションの最適化

Mon, 07 Feb 2022 01:00:00 +0000

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

世界中の企業は、人工知能（AI）や機械学習（ML）のイノベーションの恩恵を受け続けています。F5 では、データセキュリティ、不正行為の検出、bot 攻撃防止などの質を向上させるために、AI / ML を有効に活用しています。このようなビジネスプロセスにおける AI / ML のメリットは明確で、さらに F5 では、ソフトウェアアプリケーションの最適化にも AI / ML を活用しています。

より良いソフトウェアエンジニアリングに向けた AI / ML の活用は、まだ始まったばかりです。AI 支援によるコード補完、ノーコード / ローコード型プラットフォームの自動コード生成といったユースケースは見られますが、ソフトウェアアプリケーションのアーキテクチャ自体の最適化に対して AI / ML の幅広い活用は行われていません。このブログでは、Google の Vertex AI Vizier を用いたブラックボックス最適化によるデータパイプラインのワークロードの最適化について説明します。

パフォーマンスの最適化

現在、ソフトウェアの最適化は、ソフトウェアコードにおけるパフォーマンスのボトルネックを特定するためにプロファイラを使用して行う、反復的なほぼ手動のプロセスです。プロファイラは、ソフトウェアのパフォーマンスを測定してレポートを生成し、デベロッパーはそれを確認してコードをさらに最適化します。この手動によるアプローチの欠点は、最適化がデベロッパーの経験に委ねられ、そのため非常に主観的であるという点です。手動によるアプローチは時間がかかり、包括的ではなく、エラーが発生しがちで、人間のバイアスに影響されやすいものです。さらに、クラウドネイティブアプリケーションの分散性により、手動による最適化プロセスはさらに複雑なものとなっています。

あまり使用されていませんが、より包括的なアプローチとして、パフォーマンステストとブラックボックス最適化のアルゴリズムを利用する別のタイプのパフォーマンスエンジニアリングがあります。具体的には、多くのパラメータを持つ複雑なシステムの運用コストを最適化することを目指しています。因果関係のプロファイリングなど、テストベースのパフォーマンスを最適化する手法は他にもありますが、この投稿では扱いません。

図 1 に示すように、パフォーマンスを最適化するためのプロセスは、反復的で自動化されています。一連の制御された試行をシステムに対して行い、最適化されるシステムを特徴づける費用関数の値を検討します。新たなパラメータの候補が生成され、改善点が少なすぎて試行を行う価値がなくなるまで行われます。このプロセスの詳細は後ほど説明します。

図 1: ブラックボックス最適化 - 費用関数として最適な出力に到達するための反復テスト

問題は何ですか？

まず、経験から得たヒントを活用し、このディスカッションを行うための架空のステージを設定しましょう。

目標は、Pub/Sub から BigQuery にデータを取得する効率的な方法を構築することです。Google Cloud は、フルマネージドのデータ処理サービスである Dataflow を提供しています。これは他の複数のリアルタイムストリーミングのニーズに使用するさまざまなデータ処理パターンを実行します。処理と変換のこのユースケースでは、簡略化されたカスタムストリームプロセッサを活用して、BQ の「列」指向（一種の「E(t)LT」モデル）のメリットを受ける選択をしました。

調査の設定を図 2 に詳しく示します。中央にあるノートブックは、「最適化の対象となるシステム」を調査するためのオーケストレーターの役割を担っています。主な目標（および関係するコンポーネント）は以下の通りです。

再現性: プロセスの自動化に加えて、Pub/Sub スナップショットを使用して、ストリームプロセッサにフィードするために特別に作成されたサブスクリプションを初期化し、各テストで同じ条件を再現します。
スケーラビリティ: Vertex AI Workbench は、最適化プロセス全体を迅速に行うため、異なる入力パラメータで複数のテストを並行して行う一連の自動化された手順を実装しています。
デバッグ可能性: すべてのテストにおいて、調査および試行の ID は、ストリームプロセッサによって生成される各ログおよび指標のラベルとして体系的に挿入されます。こうすることでテストが失敗したときや、予期しない結果が出たときに、その原因を簡単に突き止め、分析し、把握できます。

図 2: テストを行うためのアーキテクチャの概要

Pub/Sub から BigQuery へ効率的にデータを移動させるために、当社はコードを設計、開発しました。そして、可能な限り効率を高めるように改良したいと思っています。当社が所有するプログラムを実行することで簡単にキャプチャできるパフォーマンス指標に基づいて最適化したいと考えているのです。現在の課題は、最良のバリアントをどのように選択するかということです。

当然のことながら、これは最適化問題の一つです。最適化にはこの問題がつきものです。基本的にこれらの問題は、いくつかの制約下で目的関数を最適化（最小化または最大化）し、それが実現する最小値または最大値を求めるものです。これは、その広範にわたる適用範囲から、広く調査されてきた分野です。

一般的な形式は:

- これは、あるドメイン X の費用関数 f を最小化する x を求めたいという意味です。ここでは最小化の問題なので、この x を最小値と呼びます。最小値は必ず存在するとは限りませんし、存在する場合でも必ずしも一意ではありません。最適化問題はすべて同じではありません。連続および線形計画法は「簡単」で、凸最適化は比較的簡単ですが、組み合わせ最適化は難しくなります。これは、勾配を計算できる場合と同じように、部分的にでも最適化したい目的関数を記述できることが前提です。

今回のケースの目的関数は、ある実行環境におけるプログラムのパフォーマンス（この時点ではまだ未定）です。これは f(x)=x2 とはかけ離れています。プログラムのパフォーマンスの分析式もなく、導関数もなく、関数が凸である保証もなく、評価にはコストがかかり、モニタリングにはノイズが入る可能性があります。このタイプの最適化は、目的関数をシンプルな数学用語で表現できないことから、「ブラックボックス最適化」と呼ばれています。とはいえ、最良の結果をもたらすパラメータの発見に対する関心は大きなものです。

このタイプの問題を手動で解決するのではなく、自動化する方法を探しているため、ブラックボックス最適化といくつかのツールの詳細を紹介する前に、現在の状況を具体的な最適化の問題に当てはめてみましょう。ことわざにもあるように「時は金なり」です。

最適化問題のフレーミング

問題には多くの変動要素がありますが、すべてが同じ性質ではありません。

目標

まず、目標です。今回のケースでは、Pub/Sub から BigQuery にデータを移動する際の 1 バイトあたりのコストを最小にするのが目標です。システムによって対象のドメインで直線的にスケーリングされると仮定すると、バイトあたりの処理コストはインスタンス数に依存せず、定義されたスループットに到達するためのコストを正確に推定できます。

実現方法

ある特定の実行環境（特定のマシンタイプ、ロケーション、プログラムの構成を考慮する）において、重要かつ既知の大量のデータに対してプログラムを実行し、処理にかかる時間を測定して、リソースのコストを計算します（以下で「cost_dollar」と呼ばれる）。これが費用関数 f です。

前述したように、このシステムの費用関数を定義するシンプルな数式はなく、評価するには実際にプログラムを実行する必要があるため「コストがかかる」のです。

パラメータ空間

当社のシステムには数多くのノブがあります。プログラムには、調査を行う代替的な方法に対応する構成パラメータと、さまざまなキューのサイズやワーカーの数などを設定するサイズ設定パラメータがあります。実行環境では、VM 構成、マシンタイプ、OS イメージ、ロケーションなどさらに多くのパラメータを定義するので、パラメータの数が大きく変化するのは一般的なことです。今回のシナリオでは、12 個のパラメータがあります。

最終的に、パラメータ空間は表 1 によって記述され、これは各「parameter_id」について、値のタイプ（整数、個別、カテゴリ）を示します。

目標を明らかにして、特定されたパラメータのコレクションで指定した割り当ての評価方法を理解し、これらのパラメータのドメインを定義しました。これが、ブラックボックス最適化を行うために必要なことです。

アプローチ

ブラックボックス最適化に話を戻します。これは式がない関数の最小化 / 最大化を扱う問題だとすでに述べましたが、それでも評価することは可能です。必要なのはテストを行い、コストを算出することです。

問題は、テストの実施にはコストがかかること、そして、パラメータ空間を考慮すると、すべてを迅速に探索することは現実的な選択肢ではないということです。12 個ほどのパラメータにそれぞれ 3 つの値だけを選択したと仮定しても、312=531,441 とすでに大きな数字になります。個別に取得された各パラメータのサブセットから生成されたすべての組み合わせを体系的に探索するこの手法を、グリッド検索と呼びます。

その手法の代わりにサロゲート最適化の形式を使用します。目的関数に最適な表現がないこのような場合、実際の関数をモデル化した、優れたプロパティを持つサロゲート関数を導入することが有益な場合があります。「費用関数を最小化する」という問題だけではなく、「問題に関数を当てはめて、それを最小化する」という 2 つの問題があるのは確かです。しかし私たちは、測定の結果にモデルを当てはめ、このモデルを使ってテストを行う必要のある有望な候補を選択するという、次の段階に進むためのレシピを取得しました。テスト結果が出ると、改善点が少なすぎてテストを行う価値がなくなるまでモデルを改良し、新しい候補が生成されます。

Google Cloud の Vertex AI Vizier は、このようなタイプの最適化をサービスとして提供しています。さらに詳細な背景について知りたい場合は、ガウス過程（GP）最適化を利用しているため、十分な解説がされている Google Vizier: ブラックボックス最適化サービスの記事をご覧ください。

入力パラメータの組み合わせを変えて、148 通りのテストを実施しました。そこから何を学んだのでしょうか？

調査結果

この議論のポイントは、コストを最小にするために使用したパラメータの詳細を正確に述べることではありません。使用しているプログラムや設定など、ほとんどが異なるので、応用の利く知識ではないからです。しかし、この手法の可能性を考えてみると、今回のケースでは、148 回のテストを行って、最初に推測した構成での費用関数は、1 回の実施あたり $0.0780 でしたが、最適なパラメータでは、$0.0443 となり、43% のコスト削減を実現しました。当然のことながら、ここでは「machine_type」パラメータが大きな役割を果たしますが、最良の結果を示したものと同じマシンタイプであっても、費用関数の（探索）部分は 1 回の実施あたり $0.0443 と $0.0531 の間で、16% の変動があります。

図 3 は、最も有望なテストの実施内容を表しています。最後の 2 つを除くすべての軸は、パラメータに対応しています。最後の 2 つはそれぞれ、目標である「cost_dollar」と、実施が完了したかどうかを表しています。線は実施内容を表し、それらに対応する各軸の値を結んでいます。

結論として、この調査は、介入をほとんどしなくても大幅なコスト改善が実現できることを明らかにしました。次のセクションでは、その点について掘り下げてみましょう。

手法に関する学習

この手法の最大の利点の一つは、最初の作業で適切な設定を行えば自動で実行されるので、人の介入がほとんど必要ないということです。

ブラックボックス最適化では、f(x) の評価は x にのみ依存し、同時に進行している他のことには依存しないと仮定しています。

f(x) に関する異なる評価間の相互関係を望んではいません。

Vizier の主なアプリケーションの一つに、ディープラーニングモデルのハイパーパラメータの最適化があります。そのトレーニングと評価にはコストは別として基本的に副作用がありません。前述しましたが、ブラックボックス最適化の手法は評価にコストがかかることを前提に、最適なパラメータを見つけるために必要な実施回数を減らすように設計されています。今回のシナリオでは、データをある場所から別の場所に移動させるという、明確な副作用があります。

つまり、パフォーマンステストからすべての副作用を確実に取り除けば、日々の作業は楽になるはずです。ブラックボックス最適化の手法はこのニーズに適合し、特に Vizier が有効です。これは、シナリオの実行を、隔離された環境を設定、破棄するためのロジックでラップすることによって実現できます。これにより、このまったく新しいシステムは、基本的に副作用がありません。

このようなテストの実施に関するいくつかの知識は、強調する価値があると思います。

最初に単一の値があってもすべてをパラメータ化: 別の値が必要になった場合でも、簡単に追加できます。最悪の事態が起きても、値がデータと一緒に記録されるため、必要に応じて異なるテスト間で簡単に比較できます。
テストの実施とその他の要因を分離: その他の要因がパラメータ化されておらず目標に影響を与える場合、測定結果のノイズは大きくなり、最適化プロセスが次にどこを探索するか決定するのが難しくなります。
同時の実施を隔離: 複数のテストを同時に行うことができます。
堅牢な実行: パラメータのすべての組み合わせが実行可能なものとは限りません。Vizier は、そのような内容に関するレポートをサポートしています。
十分な実施回数: Vizier は、以前の実施結果を活用して、次に何を探索するかを決定します。また、測定値を指定することなく、一度に複数のテストを行うように要求できます。これは、同時にテストを開始するのに便利です。さらに私たちの経験では、特定の極値を正確に特定するための探索を始める前に、広い対象範囲やパラメータ空間があるかを最初に確認するのにも便利です。たとえば、この投稿で先ほど説明した一連のテストの実施では、「n2-highcpu-4」は 107 回目の実施まで試行されませんでした。
ツールは現在も利用可能: Vizier は、サービスとして提供されている一例です。ブラックボックス最適化を行うための Python ライブラリも多数ご用意しています。

ノブに時間をかけたくない、マシンにおまかせしたい方は、間違いなくご活用いただけると思います。

まとめと次のステップ

ML のハイパーパラメータの調整は、ブラックボックス最適化でしか行なえません。Google の Vertex AI Vizier は、より応用範囲の広いブラックボックス最適化サービスです。また、本質的に未知の、あるいは相互関係の記述が困難な多くのパラメータによって特徴付けられる複雑なシステムのエンジニアリングにも最適なツールであると確信しています。小規模なシステムであれば、手動または系統的にパラメータを探索できるかもしれませんが、この投稿でお伝えしたポイントは、それを自動化できるということです。

パフォーマンスの最適化は、すべてのものが変化し続け、新しいオプションや新しい使用パターンが登場するので継続的に発生する課題です。

この投稿で紹介した設定は、比較的シンプルで非常に静的なものです。多腕バンディットのようなソフトウェアエンジニアリングの観点から調査する価値のある継続的なオンライン最適化に適した設定の拡張機能があります。

ウィリアムギブソンの言葉を引用すると、アプリケーション最適化の「未来はすでにここにあるのに、ただ十分に行き渡っていないだけだ」としたらどうでしょう？

すごいと思いませんか？F5 の AI、データグループが採用します！

参照

- F5 シニアアーキテクト Sebastien Soudan 氏
- F5 上級エンジニア Laurent Querel 氏

Cloud Monitoring と Cloud Run を使用したカスタム通知の作成

Tue, 01 Feb 2022 02:00:00 +0000

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

エンタープライズ IT スペースに所属する各組織では、その独自性ゆえにアラートの処理方法について興味深い課題が発生します。IT サービス管理（ITSM）市場に存在する多くの商用ツールと、多くのカスタム内部ツールにより、Google はチームに柔軟で強力なツールを提供できます。

この投稿は、通知チャンネルをサポートしていないサードパーティのサービスに Cloud Monitoring のアラート通知を配信したい、Google Cloud のお客様を対象としています。

ここでは、Cloud Pub/Sub 通知チャンネルを Google Chat サービスと統合して、アラート通知を Google Chat のルームに転送する実用的な実装を提供し、それが Google Cloud にどのようにデプロイされるかを示します。それに加えて、Cloud Build、Terraform、および GitHub を使用した継続的インテグレーションの手順の概要についても説明します。このプロジェクトのすべてのソースコードは、この GitHub リポジトリにあります。

このチュートリアルでは、Google Cloud のお客様が、Webhook / Http API インターフェースを提供するサードパーティのサービスにアラート通知を配信するために適応できる汎用フレームワークが提供されていることに注目してください。

サンプルコードを変更して他のサードパーティサービスと統合する方法については、「他のサードパーティサービスへの拡張」のセクションで説明されています。

目標

Google Cloud Monitoring アラート通知を Cloud Monitoring Pub/Sub 通知チャンネルからサードパーティサービスに転送するサービスを作成します。
Cloud Build、Terraform、GitHub を使用してサービスをビルドし、Cloud Run にデプロイします。

費用

このチュートリアルでは、Google Cloud の課金対象となるコンポーネントを使用します。

Cloud Build
Cloud Compute Engine（GCE）
Cloud Container Registry
Cloud Pub/Sub
Cloud Run
Cloud Storage

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを出すことができます。

はじめに

このチュートリアルでは GCP プロジェクトが必要です。新しいプロジェクトを作成することも、すでに作成済みのプロジェクトを選択することもできます。

Google Cloud プロジェクトを選択するか、新しく作成します。
プロジェクトセレクタページに移動する
プロジェクトに対して課金を有効にします。
課金を有効にする

このチュートリアルを終了した後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、このチュートリアルの最後にある「クリーンアップ」セクションを参照してください。

Google Chat との統合

このチュートリアルでは、Google Cloud のお客様がアラート通知を Google Chat のルームに転送できるようにするための、統合のサンプルを提供します。システムアーキテクチャは次のとおりです。

この例では、Terraform を使用して 2 つのモニタリングアラートポリシーが作成されます。1 つは GCE インスタンスの CPU の usage_time 指標に基づいており、もう 1 つは GCE インスタンスのディスクの read_bytes_count 指標に基づいています。どちらのアラートポリシーも、Cloud Monitoring Pub/Sub 通知チャンネルを使用してアラート通知を送信します。Cloud Pub/Sub push サブスクリプションは、Cloud Pub/Sub 通知チャンネルごとに構成されます。Cloud Pub/Sub push サブスクリプションの push エンドポイントは、Cloud Pub/Sub 通知チャンネルに送信されるすべてのアラート通知が Cloud Run サービスに転送されるように実装する、Cloud Run サービスを指します。Cloud Run サービスは、受け取った Cloud Pub/Sub メッセージを Google Chat メッセージに変換し、受け取った Webhook URL を介して構成済みの Google Chat ルームに送信するシンプルな Http サーバーです。

すべてのインフラストラクチャコンポーネントは、Terraform を使用して自動的に作成および構成されます。これには次のものが含まれます。

Cloud Pub/Sub トピック、push サブスクリプション、サービスアカウントの設定
Cloud Pub/Sub 通知チャンネル
Cloud Monitoring のアラートポリシー
Cloud Run サービスとサービスアカウントの設定

Terraform のコードは、./tf-modules および./environments にあります。

Cloud Run のコードを見る

Cloud Run サービスは、構成された Google Chat ルームに Cloud Pub/Sub アラート通知を配信する役割を果たします。統合コードは ./notification_integration フォルダーにあります。

この例では、基本的な Flask HTTP サーバーが main.py にセットアップされ、Cloud Monitoring Pub/Sub チャンネルから受け取った Cloud Monitoring アラート通知を処理します。Cloud Pub/Sub push サブスクリプションを使用して、Pub/Sub 通知メッセージを Flask サーバーにリアルタイムで転送します。Cloud Pub/Sub サブスクリプションの詳細については、サブスクライバーの概要をご参照ください。

以下は、Pub/Sub メッセージを処理するハンドラーです。

code_block: <ListValue: [StructValue([('code', '@app.route(\'/<config_id>\', methods=[\'POST\'])\r\ndef handle_pubsub_message(config_id):\r\n try:\r\n config_param = config_params_server.GetConfig(config_id)\r\n except BaseException as e:\r\n err_msg = \'Failed to get config parameters for {}: {}\'.format(config_id, e)\r\n logging.error(err_msg)\r\n return(f\'500: {err_msg}\', 200)\r\n if \'service_name\' not in config_param:\r\n err_msg = \'"service_name" not found in the config parameters: {}\'.format(config_id)\r\n logging.error(err_msg)\r\n return(f\'500: {err_msg}\', 200)\r\n if config_param[\'service_name\'] not in service_names_to_handlers:\r\n err_msg = \'No handler found for the service {}\'.format(config_param[\'service_name\'])\r\n logging.error(err_msg)\r\n return(f\'500: {err_msg}\', 200)\r\n \r\n handler = service_names_to_handlers[config_param[\'service_name\']]\r\n \r\n # Pub/Sub raw メッセージを解析して通知を取得します\r\n pubsub_received_message = request.get_json()\r\n try:\r\n notification = pubsub.ExtractNotificationFromPubSubMsg(pubsub_received_message)\r\n response, status_code = handler.SendNotification(config_param, notification)\r\n logging.info(f\'Notification was sent with the status code = {status_code}: {response}\')\r\n return(f\'{status_code}: {response}\', 200) \r\n except pubsub.DataParseError as e:\r\n logging.error(f\'Pubsub message parse error: {e}\')\r\n return(f\'400: {e}\', 200)\r\n except BaseException as e:\r\n logging.error(f\'Unexpected error when processing Pubsub message: {e}\')\r\n return(f\'400: {e}\', 200)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae40745c10>)])]>

ハンドラーは、utilities/pubsub.py の ExtractNotificationFromPubSubMsg() 関数を呼び出して、Pub/Sub メッセージから関連する通知データを解析し、通知データをディクショナリに読み込みます。出力は、ここで定義されたスキーマを持つ json オブジェクトです。

code_block: <ListValue: [StructValue([('code', 'def ExtractNotificationFromPubSubMsg(pubsub_msg: Dict[Text, Any]) -> Dict[Text, Any]:\r\n """Parses notification messages from Pub/Sub.\r\n Args:\r\n pubsub_msg: Dictionary containing the Pub/Sub message.\r\n The message itself should be a base64-encoded string.\r\n Returns:\r\n The decoded \'data\' value of the provided Pub/Sub message, returned as a json dictory.\r\n Raises:\r\n DataParseError: If data cannot be parsed.\r\n"""\r\n try:\r\n data_base64_string = pubsub_msg[\'message\'][\'data\']\r\n except (KeyError, TypeError) as e:\r\n raise DataParseError(\'invalid Pub/Sub message format\') from e\r\n\r\n try:\r\n data_bytes = base64.b64decode(data_base64_string)\r\n except (binascii.Error, ValueError) as e:\r\n raise DataParseError(\'data should be base64-encoded\') from e\r\n except TypeError as e:\r\n raise DataParseError(\'data should be in a string format\') from e\r\n data_string = data_bytes.decode(\'utf-8\')\r\n data_string = data_string.strip()\r\n\r\n try:\r\n data_json = json.loads(data_string)\r\n except json.JSONDecodeError as e:\r\n raise DataParseError(\'data can not be loaded as a json object: {}\'.format(e), 400)\r\n\r\n return data_json'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae40745e80>)])]>

次に、この通知ディクショナリは SendNotification() に渡され、SendNotification() は config_params とともに通知を utilities/service_handler.py の _SendHttpRequest() に送信します。これにより、API クライアントを使用して、アラートがサードパーティサービスに適切に通知されます。URL パラメータ「config_id」は、Cloud Run サービスが構成データ「config_params」を取得するために使用する構成 ID です。「config_params」には、受け取った通知をサードパーティのサービスに転送するために Cloud Run サービスに必要なすべてのパラメータ（HTTP URL やユーザーの認証情報など）が含まれています。この例では、「config_id」は、ここで定義されている Pub/Sub トピックに対応しています。

このディスパッチ機能を変更して、アラートをサードパーティのサービスに転送できます。

code_block: <ListValue: [StructValue([('code', 'def _SendHttpRequest(self, config_params: Dict[str, Any], notification: Dict[Any, Any]) -> Tuple[httplib2.Response, Text]:\r\n """Sends a http request to a 3rd-party service via a http request."""\r\n http_url = self._GetHttpUrl(config_params, notification)\r\n messages_headers = self._BuildHttpRequestHeaders(config_params, notification)\r\n message_body = self._BuildHttpRequestBody(config_params, notification)\r\n http_obj = httplib2.Http()\r\n # コンテンツは bytes オブジェクトです。\r\n http_response, content = http_obj.request(\r\n uri=http_url,\r\n method=self._http_method,\r\n headers=messages_headers,\r\n body=message_body,\r\n )\r\n return http_response, content.decode(\'utf-8\')'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae40745400>)])]>

成功の HTTP ステータスコード（200 または 204）を返すことにより、Pub/Sub メッセージの成功を確認応答することを忘れないでください。push メッセージの受信をご確認ください。

Cloud Run サービスに書き込まれたすべてのログには、Cloud Logging Logs Explorer または Cloud Run UI から簡単にアクセスできます。ログは、Cloud Run サービスのデバッグに非常に役立ちます。さらにユーザーは、Cloud Pub/Sub 通知チャンネルで使用される Pub/Sub トピックの追加の pull サブスクリプションを作成して、通知配信の問題のトリアージを簡素化できます。たとえば、一部のアラート通知がユーザーの Google Chat ルームに配信されなかった場合、ユーザーは最初に、欠落しているアラート通知の Cloud Pub/Sub メッセージを pull サブスクリプションが受信したかどうかを確認できます。欠落しているアラート通知を pull サブスクリプションが正しく受信した場合、それはアラート通知が Cloud Run サービスで失われたことを意味します。それ以外の場合は、Cloud Pub/Sub 通知チャンネルの問題ということになります。

最後に、Cloud Run にデプロイされたときに Flask サーバーをホストするイメージを構築するための手順を含む、Dockerfile についてです。

code_block: <ListValue: [StructValue([('code', '# [START run_pubsub_dockerfile]\r\n \r\n# 公式の Python イメージを使用します。\r\n# https://hub.docker.com/_/python\r\nFROM python:3.8\r\n \r\n# ステートメントとログメッセージが Cloud Run のログにすぐに記録されるようにします\r\nENV PYTHONUNBUFFERED True\r\n \r\n# アプリケーションの依存関係マニフェストをコンテナイメージにコピーします。\r\n# これを別にコピーすると、コードを変更するたびに pip install を再実行する必要がなくなります。\r\nCOPY requirements.txt ./\r\n \r\n# 本番環境の依存関係をインストールします。\r\nRUN pip install -r requirements.txt\r\n \r\n# ローカルコードをコンテナイメージにコピーします。\r\nENV APP_HOME /app\r\nWORKDIR $APP_HOME\r\nCOPY . ./\r\nARG PROJECT_ID\r\nENV PROJECT_ID=$PROJECT_ID\r\n# 使用する構成サーバーのタイプ（インメモリまたは gcs）を制御するためのフラグ。\r\nARG CONFIG_SERVER_TYPE\r\nENV CONFIG_SERVER_TYPE=$CONFIG_SERVER_TYPE\r\n \r\n# コンテナの起動時にウェブサービスを実行します。\r\n# 1 つのワーカープロセスと 8 つのスレッドを含む gunicorn webserver を使用します。\r\n# 複数の CPU コアが含まれる環境では、ワーカーの数を増やし、\r\n# 利用可能なコア数と同じになるようにします。\r\nCMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app\r\n \r\n# [END run_pubsub_dockerfile]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae47c5c880>)])]>

アプリのデプロイ

このセクションでは、GitOps の方法論に従って、Cloud Build、Terraform、GitHub を使用して継続的インテグレーションをデプロイおよびセットアップする方法について説明します。この手順は、Terraform、Cloud Build、GitOps を使用したコードとしてのインフラストラクチャの管理に基づいており、GitOps の方法論とアーキテクチャについても説明しています。ガイドのセクションは、以下の手順でも参照します。重要な違いは、このドキュメントでは、dev 環境と prod 環境に別々の Google Cloud プロジェクトが使用されていることを前提としているのに対し、参照ガイドでは環境を仮想プライベートクラウド（VPC）として構成していることです。そのため、dev プロジェクトと prod プロジェクトごとに、次のデプロイ手順（「GitHub リポジトリのセットアップ」を除く）を実行する必要があります。

GitHub リポジトリを設定する

すべてのコードを取得し、アプリのデプロイに必要なリポジトリ構造を理解するには、GitHub リポジトリの設定の手順を実施します。

Google Chat 統合をデプロイする

webhook URL の設定

ハードコードされた Webhook URL

main.py 内に、webhook URL を保存するための config_map 変数を提供しています。まず、Google Chat の webhook URL を見つけて、config_map ディクショナリ内のキー「webhook_url」の値を置き換える必要があります。

code_block: <ListValue: [StructValue([('code', "config_map = {\r\n 'tf-topic-cpu': {\r\n 'service_name': 'google_chat',\r\n 'msg_format': 'card',\r\n 'webhook_url': '<YOUR_GOOGLE_CHAT_ROOM_WEBHOOK_URL>'},\r\n 'tf-topic-disk': {\r\n 'service_name': 'google_chat',\r\n 'msg_format': 'card',\r\n 'webhook_url': '<YOUR_GOOGLE_CHAT_ROOM_WEBHOOK_URL>'}\r\n}"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae47c63b20>)])]>

手動 GCS バケット Webhook URL

Webhook URL を保存するためのより安全なオプションが必要な場合は、GCS バケットを作成して Webhook URL を保存できます。

gchat ルームの Google Chat webhook URL を見つけて、config_params.json という名前の json ファイルに次の形式で保存します。

{“topic”: “webhook url”, “topic”: “webhook url”}

Cloud Storage バケットを作成し、gcs_config_bucket_{PROJECT_ID} という名前の json ファイルを格納します。

次のコマンドを Cloud Console で実行することもできます。gsutil mb gs://gcs_config_bucket_{PROJECT_ID}

読み取り権限（Storage レガシーバケット読み取りとストレージレガシーオブジェクトリーダー）を次のデフォルトの Cloud Run サービスアカウントに付与します。<PROJECT_NUMBER>-compute@developer.gserviceaccount.com

通知チャンネル統合サンプルを初めて自動的にデプロイするために、デプロイに必要なアクションの大部分を処理するスクリプト deploy.py を提供しました。上記の webhook URL の手順を完了したら、次のコマンドを実行します。

code_block: <ListValue: [StructValue([('code', 'Python3 deploy.py -p <PROJECT_ID>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae471d1070>)])]>

手動でのデプロイ

通知チャンネル統合を手動でデプロイするには、次の手順を完了する必要があります。

1. Cloud Shell で Cloud Platform プロジェクトを設定します。<PROJECT_ID> を Cloud Platform プロジェクト ID に置き換えます。

code_block: <ListValue: [StructValue([('code', 'gcloud config set project <PROJECT_ID>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae471d1e20>)])]>

2. Cloud Build サービスを有効にします。

code_block: <ListValue: [StructValue([('code', 'gcloud services enable cloudbuild.googleapis.com'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae471d1b20>)])]>

3. Cloud Resource Manager サービスを有効にします。

code_block: <ListValue: [StructValue([('code', 'gcloud services enable cloudresourcemanager.googleapis.com'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae471d1dc0>)])]>

4. Cloud Service Usage サービスを有効にします。

code_block: <ListValue: [StructValue([('code', 'gcloud services enable serviceusage.googleapis.com'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae471d1310>)])]>

5. Cloud Build サービスアカウントに必要な権限を付与します。

code_block: <ListValue: [StructValue([('code', 'CLOUDBUILD_SA="$(gcloud projects describe $PROJECT_ID --format \'value(projectNumber)\')@cloudbuild.gserviceaccount.com"\r\n\r\ngcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$CLOUDBUILD_SA --role roles/iam.securityAdmin\r\n\r\ngcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$CLOUDBUILD_SA --role roles/run.admin\r\n\r\ngcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$CLOUDBUILD_SA --role roles/editor'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae471d1d90>)])]>

6. Cloud Storage バケットを作成して、Terraform の状態をリモートで保存します。

PROJECT_ID=$(gcloud config get-value project)

code_block: <ListValue: [StructValue([('code', 'gsutil mb gs://${PROJECT_ID}-tfstate'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae471d1160>)])]>

7. （オプション）オブジェクトのバージョニングを有効にして、デプロイの履歴を保持できます。

code_block: <ListValue: [StructValue([('code', 'gsutil versioning set on gs://${PROJECT_ID}-tfstate'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae471d1460>)])]>

8. ビルドをトリガーし、Cloud Run にデプロイします。

インメモリ構成サーバーを使用した場合は、次を実行します（<BRANCH> を現在の環境ブランチに置き換える）。

code_block: <ListValue: [StructValue([('code', 'gcloud builds submit . --config cloudbuild.yaml --substitutions BRANCH_NAME=<BRANCH>,_CONFIG_SERVER_TYPE=in-memory'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae471d1490>)])]>

GCS ベースの構成サーバーを使用する場合は、次を実行します。

code_block: <ListValue: [StructValue([('code', 'gcloud builds submit . --config cloudbuild.yaml --substitutions BRANCH_NAME=<BRANCH>,_CONFIG_SERVER_TYPE=gcs'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae471d1d00>)])]>

継続的デプロイのセットアップ

これはオプションのフローであり、このセクションでは、トリガーを使用して、Cloud Build を使用した継続的デプロイを設定する方法について説明します。フローは次の図に示されています。ユーザーが新しいバージョンを Git リポジトリに push するたびに、Cloud Build トリガーがトリガーされます。Cloud Build は YAML ファイルを実行して、Cloud Run docker イメージを再構築し、インフラストラクチャセットアップを更新し、Cloud Run サービスを再デプロイします。

この手順は、Cloud Build を使用したビルドの自動化に基づいています。

コードリポジトリを設定します。GitHub、Google Cloud Source リポジトリ、または任意のプライベートリポジトリを設定できます。

GitHub からリポジトリのクローンを作成します。
新しいプロジェクトに切り替えて、クローンされたリポジトリをリモートリポジトリに push します。

code_block: <ListValue: [StructValue([('code', 'gcloud init && gconfig –global credential.https//source.developers.google.com.helper gcloud.sh \r\n\r\ngit remote add <connection name> <repo url>\r\n\r\ngit push <connection name>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae471d11c0>)])]>

次に、Cloud Build で新しいトリガーを作成します。

クリーンアップ

このチュートリアル用に新規プロジェクトを作成した場合は、そのプロジェクトを削除します。既存のプロジェクトを使用し、このチュートリアルでの変更を加えずに残す場合は、チュートリアル用に作成したリソースを削除します。

プロジェクトの削除

課金を停止する最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。

プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このチュートリアルで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。appspot.com URL など、プロジェクト ID を使用する URL を保持するには、プロジェクト全体を削除するのではなく、プロジェクト内の選択したリソースを削除します。

複数のチュートリアルとクイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにできます。

プロジェクトを削除する手順は次のとおりです。

Cloud Console で、[リソースの管理] ページに移動します。
[リソースの管理] ページに移動する
プロジェクトリストで、削除するプロジェクトを選択し、[削除] をクリックします。
ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

チュートリアルリソースの削除

Terraform によってプロビジョニングされた Cloud リソースを削除します。
terraform destroy
{PROJECT_ID}-tfstate という名前の Cloud Storage バケットを削除します。
Cloud Build サービスアカウントに付与された権限を削除します。
gcloud projects remove-iam-policy-binding $PROJECT_ID --member serviceAccount:$CLOUDBUILD_SA --role roles/iam.securityAdmin
gcloud projects remove-iam-policy-binding $PROJECT_ID --member serviceAccount:$CLOUDBUILD_SA --role roles/run.admin
gcloud projects remove-iam-policy-binding $PROJECT_ID --member serviceAccount:$CLOUDBUILD_SA --role roles/storage.admin
tf-topic に公開するサービスアカウントの権限を削除します。
gcloud pubsub topics remove-iam-policy-binding \ projects/[PROJECT_NUMBER]/topics/tf-topic --role=roles/pubsub.publisher \ --member=serviceAccount:service-[PROJECT_NUMBER]@gcp-sa-monitoring-notification.iam.gserviceaccount.com
tf-topic を使用する通知チャンネルを削除します。
フォークされた notification_integrationGitHub リポジトリを削除します。
Cloud Build トリガーを削除して、GitHub リポジトリを Cloud Build から切断します。
Google Cloud API を無効にします。

他のサードパーティサービスへの拡張

チュートリアルのサンプルコードは一般的なフレームワークを提供しており、Google Cloud のお客様向けに簡単にカスタマイズして、Webhook/Http API インターフェースを提供するサードパーティサービスにアラート通知を配信できます。

新しいサードパーティサービスと統合する場合は、./notification_channel/service_handler.py で定義された抽象クラス HttpRequestBasedHandler の新しい派生クラスを作成し、次のメンバー関数を更新します。

CheckConfigParams(): 特定の統合構成が有効かどうかをチェックする関数です。必要な API キーが与えられます。
_GetHttpUrl(): 構成データから Http URL（Http リクエストの送信先）を取得する関数です。
_BuildHttpRequestHeaders(): Http リクエストヘッダーを作成する関数です。
_BuildHttpRequestBody(): 受け取った Cloud Pub/Sub メッセージに基づいて Http リクエストメッセージ本文を構築する関数です。
SendNotification(): GchatHandler クラスで定義されたものを再利用できます。

アラートポリシーをカスタマイズする必要がある場合を除いて、Terraform コードを更新する必要はありません。追加の提案がある場合は、いつでもコミュニティからフィードバックをお寄せください。pull リクエストを送信して、一緒に GitHub リポジトリの構築を継続しましょう。

- ソフトウェアエンジニア Dong Wang

ハイブリッドクラウドのログで優れた分析情報の獲得とトラブルシューティングを行うための 2 つのパターン

Wed, 26 Jan 2022 01:00:00 +0000

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

ハイブリッド環境やマルチクラウド環境では、アプリケーションやサーバーのログをはじめ、クラウドサービス、API、オーケストレーター、ゲートウェイなど、環境内で実行しているあらゆるものに関連するログが無限に生成されています。このような大量のログが原因で、問題のトラブルシューティングを行うために早急にログが必要になった際に、ロギングシステムの動作が遅くなり制御できなくなってしまうことがあります。ログを使用して分析情報を得るのはさらに困難です。

Google Cloud のオペレーションスイートは、あらゆるアプリケーションモダナイゼーションのフレームワークにおいて重要な役割を果たし、信頼性の高い安全なアプリケーションを確保するうえで欠かせない、モニタリング、ロギング、アラートの機能を提供します。いわば、SRE や Google の運用に対する包括的なアプローチの基準となるプロダクトです。

カスタマーエンジニアである私たちは、ハイブリッドやマルチクラウドのアプリケーションを使用している組織の多くが、さまざまなソースからログや指標を単一のコンソールに統合したいと考えていることがわかりました。また、すべての重要なサービスの指標は、日々の運用のためだけでなく、最新アプリケーションの内部および外部の SLI、SLO、SLA を測定するためにも収集できます。

お客様の運用の改善

私たちは最近、大手メディア処理会社と大手通信事業者の 2 社のお客様をご支援する機会がありました。両社とも Google Cloud、他社のクラウド、オンプレミスでアプリケーションを実行していますが、それぞれのお客様が、ログに関する次のような問題を抱えていました。

お客様 1（大手メディア処理会社）: 既存のロギング環境が遅すぎて、環境全体のシステムログやアプリケーションログによるリアルタイムのトラブルシューティングを効果的に行うことができませんでした。
お客様 2（大手通信事業者）: 1 日にテラバイト単位のネットワークログを取り込んでいましたが、そこから有益な分析情報を得られていないと感じていました。これらの分析情報は、リアルタイムである必要はありませんでした。

どちらのお客様も、人気の高いセルフマネージドのオープンソース製品を使用して、ログの取り込み、保存、取得を行っていました。しかし、ログの量が増えるにつれて、ログをサポートするためのインフラストラクチャや運用のオーバーヘッドコストも増加していったのです。また、両社には他にも次のような特徴がありました。

設定において、ログの取り込みパイプライン、保存、取得のために、SSD ストレージと大規模な VM が必要だった。
ログ管理の構成要素を 1 つのリソースに依存するというリスクを抱えていた。
アプリケーションやインフラストラクチャの障害が自社製品やサービスの SLA に影響を与えていたときに、データパイプラインのキューが満杯になってしまったため必要なログを取得できなかった。

両社ともコスト削減、障害発生の低減に取り組むのはもちろん、ログから分析情報を得るために、取り込んで保存しなくてはならないログの量を決定する必要がありました。そこで私たちはさまざまなパターンを検討し、次の 2 つを提案しました。

お客様 1: ハイブリッドサービスとマルチクラウドサービスのシステムやアプリケーションのログを Cloud Logging にルートすることで、大規模なリアルタイムのトラブルシューティングを実現し、コストや運用面での負担を削減する。
お客様 2: ネットワークログを BigQuery に直接ルートすることで、コストを管理し、データから優れた分析情報を得られるようにする。

この 2 つのパターンについて、さらに詳しく見ていきましょう。

パターン 1: Cloud Logging でリソース管理とトラブルシューティングを実現

このパターンは、リアルタイムのログに基づいてトラブルシューティングを行うことを主な目的としたシナリオに適しています。ここで注目したのは重要なログと指標で、リアルタイムのトラブルシューティングに不要なログは、必要に応じてサンプリングやフィルタリングを行います。お客様 1 には大量のログがあるため、問題のトラブルシューティングを行うには、スケーリングと取り込みのタイミングが重要でした。このお客様の目的を達成するにあたり、私たちは以下のパターンを提案しました。

このパターンでは、お客様は Cloud Logging を使用して、Google Cloud、他社のクラウド、VM からログを収集します。Google Kubernetes Engine（GKE）、Ops エージェントを搭載した Compute Engine、Cloud Storage などの Google Cloud のリソースは、自動的にログを Cloud Logging に送信します。一方、fluentd や stanza などの Logging エージェントは、他社のクラウドやオンプレミスシステムなど、別のソースからアプリケーションやシステムのログを取り込みます（また、BlueMedora などのパートナーツールを使用すると、Azure Kubernetes Service を始めとした幅広い別のソースからログを取り込むことができます）。

Logging エージェントは Cloud Logging API を使用してログを収集し、ログルーターに送信します。ログルーターでは、フィルタを適用して重要なログのみを取得できます。お客様のハイブリッド環境では、毎日 20 TB のログが生成されていたため、リアルタイムのトラブルシューティングに重要ではないログ（この場合は、詳細なネットワークログとデバッグログ）を特定し、エージェントレベルとログルーターレベルの両方でフィルタを適用しました。さらに、ネットワークログを BigQuery やその他のサードパーティのツールにエクスポートし、パターンや分析情報を導き出して将来の分析に活用することを助言しました。

このパターンは、お客様のユースケースが主にトラブルシューティングに焦点を当てていて、詳細なネットワークログは分析のためにのみ必要であったことから、お客様の要件に適していました。このパターンには次のようなメリットがあります。

フルマネージドであるため、お客様はアプリの開発に注力できる
Cloud Logging と BigQuery を組み合わせることで、優れた費用対効果を発揮できる
ログベースの指標により、将来の自動修復の運用の基盤を提供できる

パターン 2: ハイブリッドクラウドやマルチクラウドでログ分析に BigQuery を使用するシナリオ

このパターンは、ログの量が多く、それを主に分析に活用しているお客様 2 のシナリオに適しています。このお客様は、ネットワークログに関するより詳細な分析情報を求めていました。

このパターンは、特にネットワークログに関連した異常検出やパターン認識などのモデルを実行する必要があるお客様におすすめです。ネットワークログは大量に発生する傾向があり、これらのログは主に分析のために使用されていたため、お客様は並べ替え、フィルタリング、ダッシュボードなどの機能をあまり活用していませんでした。そこで有用なのが、低コストかつ AI / MLが組み込まれ、グローバル規模に対応する BigQuery です。Google のフルマネージドのデータウェアハウスと分析エンジンは、テラバイト規模のログに対するクエリを数十秒で実行するため、お客様の高度な分析ニーズに最適といえます。

このパターンでは、Log Collector エージェントは、ハイブリッドクラウド、他のクラウドプロバイダ、Google Cloud から収集したログの保存先として BigQuery を設定する出力プラグインを使用します。プラグインを使用すると、お客様は多数のサーバーからほぼリアルタイムでログを直接 BigQuery に読み込むことができます。BigQuery は受信ログのスキーマを自動的に作成するため、指標のスキーマやデータ形式の定義をより細かく制御できます。ログが BigQuery に保存されると、お客様は Looker を使用して基本的な正規表現を実行し、それに基づいて機械学習モデルを構築できます。また、データポータル、Looker などの可視化ツールを使用して、頻繁に更新されるダッシュボードを作成し、ログデータを可視化することも可能です。

このパターンには、次のようなメリットがあります。

大量のネットワークログに対応できる費用対効果の高いソリューションである。
組み込みの分析エンジンでログの分析情報に対応できる。
BigQuery API を使用してデータをダッシュボードに表示し、分析情報を利用できる。

最後に

Google Cloud のオペレーションスイートは、Google Cloud のユーザーにとってすぐに使用できるプロダクトですが、Google のお客様に日々お伝えしているように、他のさまざまなユースケースにも対応しています。上記でご紹介した 2 つのパターンのように、ログのあるサブセットでトラブルシューティングが必要で、別のサブセットで分析機能が必要になった場合、Cloud Logging API を使用してログの最初の部分を Cloud Logging に送信し、他の部分を BigQuery に直接送信できます。

また、このような作業の多くを簡素化するための取り組みも継続中です。たとえば、Log Analytics のプレビュー版を最近リリースしましたが、このソリューションは Google Cloud サービスのログを自動的に BigQuery にインポートし、そのデータを Cloud Logging インターフェースから直接分析できます。

使ってみる

コストや運用のオーバーヘッドなしでログを最大限に活用したい場合は、今すぐ Google Cloud のアカウントチームとの打ち合わせを調整いただくか、こちらをクリックしてセールスチームまでお問い合わせください。

Google Cloud の Operations コミュニティでご質問やご相談を行いたい場合は、Google Cloud コミュニティサイトをご覧ください。

- カスタマーエンジニア Meenaxi Gunjati

- Google Cloud カスタマーエンジニア Tinu Anand Chandrasekar

Webhook や Pub/Sub、Slack のアラート通知チャネルを提供開始

Tue, 25 Jan 2022 12:05:00 +0000

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

アプリケーションでアラートが発生した場合、チームはできるだけ早くアラートに気付き、ユーザーが直面している問題を緩和する必要があります。運用環境が複雑なお客様はインシデント管理や関連サービスを利用することで、問題への対応を整理、調整しています。受け入れられる形式でアラート通知をプラットフォームやサービスにルーティングする柔軟性が必要になります。

このたび、Google Cloud Monitoring のアラート向け Webhook、Pub/Sub、Slack 通知チャネルが一般提供（GA）になったことをお知らせします。メール、SMS、モバイル、PagerDuty（現在ベータ版）の既存の通知チャネルに加えて、広く利用されているさまざまなサービスに Google Cloud アラートをルーティングできるようになりました。こうした新しい通知チャネルを使用すると、アラートを各種サービスと統合できます。統合の対象は、特に人気のあるコラボレーションや ITSM、インシデント管理だけでなく、Webhook や Pub/Sub 統合をサポートするほぼあらゆるサービスやソフトウェアです。

チームが使用するベンダーツールやカスタムビルドツールに送信されるように、Google Cloud アラートを構成できます。たとえば、GKE クラスタの稼働時間チェックでは、Pub/Sub 通知チャネルを通じてアラートデータをサードパーティのコミュニケーションツールに送信できます。または、予期しない IP アドレスなどのセキュリティに関する懸念を追跡する場合、ログベースのアラートをインシデント管理プロバイダに送信できます。

Webhook や Pub/Sub、Slack の通知を構成するには

カスタム統合の場合、通知をプライベートネットワークに送信する方法として Pub/Sub をおすすめします。Webhooks はパブリックエンドポイントでサポートされており、基本認証やトークン認証とともにご利用になれます。どちらの通知チャネルも、Terraform などの自動化ツールを使用してプログラムで有効にできます。

Slack を使用する場合、Slack チャネル / ワークスペースへの Cloud Monitoring アクセスを有効にしてから、通知チャネルを作成できます。Slack チャネル通知のデプロイを自動化する場合、Google Cloud Monitoring アプリを使用する代わりに、独自の Slack アプリを作成してインストールし、OAuth トークンを再利用する必要があります。

次のステップ

詳しくは、Cloud Run と Cloud Build を使用して Pub/Sub 通知を外部ベンダーに送信する方法を紹介したチュートリアルブログの例をご覧ください。Google Cloud コミュニティで、お気軽にコメントやフィードバックをお寄せください。

- プロダクトマネージャー Alisa Goldstein
- Cloud Ops プロダクトマネージャー Kyle Benson

Ansible を使用して Google Cloud Ops エージェントをデプロイする方法

Thu, 20 Jan 2022 06:00:00 +0000

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

仮想マシン（VM）の運用を担当するサイト信頼性エンジニアリング（SRE）チームと運用チームは、信頼性とスケーラビリティに優れた環境を開発パートナーに提供する方法を常に模索しています。安定したエクスペリエンスを提供する方法の一つは、システムやアプリケーションのテレメトリーデータ（指標、ログ、トレース）を使用し、効果的なモニタリングとトラブルシューティングを実施できるようにすることです。Google Compute Engine をはじめとする Google Cloud サービスの多くでは、基本的なシステムの指標がすぐに利用できます。ただし、VM やアプリケーションのテレメトリーに関する詳細な指標が必要な場合は、Google Cloud Ops エージェントをインストールしてください。

Cloud Ops では、UI を使って 1 台または数台の VM に Ops エージェントを簡単にインストールできます。しかし、VM フリートへのエージェントのインストール、構成、管理には多大な労力を要します。大規模組織で多くの VM が本番環境ワークロードをホストしている場合は、なおさらです。構成ツールとプロビジョニングツールが膨大な数に上るため、複雑になりすぎるということもよくあります。Google は、デジタルトランスフォーメーションに取り組むユーザーのニーズに Cloud Operations を通じて応えたいと考えています。だからこそ、構成およびプロビジョニングの分野で、Cloud Ops エージェントをデプロイするための最も一般的な自動化ツールのサポートを取り入れました。これにより、ユーザーは運用上の手間を減らすための手段として自動化を優先し、信頼性とパフォーマンスに優れたインフラストラクチャの構築と管理に集中できます。

今回は、VM フリート全体に Cloud Ops エージェントを自動でデプロイする方法について紹介します。この例では Ansible を使用します。Ansible は人気のオープンソース構成管理ツールであり、インフラストラクチャの自動化に着手する手軽な方法を提供します。また、テンプレートツールを使用して自動化コードを合理化する、さらに高度な例も取り上げます。それでは、まず Ansible の概要と仕組みについて説明しましょう。

Ansible の概要と仕組み

Ansible は Python で記述されたオープンソースのツールであり、マシンと接続および通信するためのエージェントレスのフレームワークを提供します。Ansible はそのために Linux および Windows 向けのネイティブ接続プロトコル、SSH、Powershell をそれぞれ活用します。既存の接続プロトコルを使用する主なメリットは、長年にわたって幅広く導入されているこれらのプロトコルのセキュリティを活かしながら、同時にシステムのオーバーヘッドを減らすうえで効果があるという点です。Ansible を使用する際の最もシンプルな作業単位の一つはハンドブックです。

code_block: <ListValue: [StructValue([('code', '---\r\n- name: Sample playbook\r\n hosts: localhost\r\n tasks:\r\n - ansible.builtin.debug:\r\n msg: "Hello World!"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae48c5f7c0>)])]>

これは、ローカルホストに対して実行されるごくシンプルなハンドブックで、「Hello World!」のエコーと本質的に同等のタスクを実行します。

Ops エージェントをデプロイして VM のモニタリングとトラブルシューティングを行う

新しい Google Cloud Ops エージェントを使うと、システムからの大まかなテレメトリーデータの収集を極めて簡単かつ即座に開始できます。エージェントをインストールするだけで、標準のシステムログに加え、実行中のプロセスなど、システムに関するデフォルト以外の他のテレメトリーをすぐに取り込むことができます。

ワークロードの詳細を構成に追加する

では、Nginx と Ops エージェントのカスタム構成をデプロイしてテレメトリーを収集するハンドブックなど、もっと複雑な例を見てみましょう。

以下は、Nginx からデフォルトの指標とログを収集するための Ops エージェントのシンプルなカスタム構成ファイルの例であり、YAML 形式でも記述されます。

code_block: <ListValue: [StructValue([('code', 'logging:\r\n receivers:\r\n nginx_default_access:\r\n type: nginx_access\r\n nginx_default_error:\r\n type: nginx_error\r\n service:\r\n pipelines:\r\n nginx:\r\n receivers:\r\n - nginx_default_access\r\n - nginx_default_error\r\nmetrics:\r\n receivers:\r\n nginx_metrics:\r\n type: nginx\r\n stub_status_url: http://127.0.0.1:80/status\r\n collection_interval: 60s\r\n service:\r\n pipelines:\r\n nginx_pipeline:\r\n receivers:\r\n - nginx_metrics\r\n下のハンドブックは、ロールのカスタム「ops_agent.yaml」構成ファイルを指定します。\r\n---\r\n- name: Deploy and configure Cloud Ops Agent\r\n hosts: all\r\n become: true\r\n roles:\r\n - role: googlecloudplatform.google_cloud_ops_agents\r\n vars:\r\n agent_type: ops-agent\r\n version: 1.0.1\r\n main_config_file: ops_agent.yaml\r\n notify:\r\n - Restart Ops Agent\r\n tasks:\r\n - name: Install nginx\r\n ansible.builtin.package: \r\n name: nginx\r\n state: present\r\n - name: Customize nginx config for telemetry\r\n ansible.builtin.template:\r\n src: ansible_templates/status.conf\r\n dest: /etc/nginx/conf.d/status.conf\r\n notify:\r\n - Restart Nginx\r\n - name: Start nginx\r\n ansible.builtin.service:\r\n name: nginx\r\n state: started\r\n enabled: yes\r\n - name: Start Ops Agent\r\n ansible.builtin.service:\r\n name: google-cloud-ops-agent\r\n state: started\r\n enabled: yes\r\n \r\n handlers:\r\n - name: Restart Nginx\r\n ansible.builtin.service:\r\n name: nginx\r\n state: restarted\r\n enabled: yes\r\n - name: Restart Ops Agent\r\n ansible.builtin.service:\r\n name: google-cloud-ops-agent\r\n state: restarted\r\n enabled: yes'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae48c5fe80>)])]>

このハンドブックを実行すると、インベントリ内のすべてのホストに NGINX が正常にインストールされ、Nginx から指標とデータの両方が送信されます。例のハンドブックをコピーするには、こちらの GitHub サンプルを確認してください。

続いて、この情報の一部を可視化します。以下の手順で、すぐに使用できる Nginx 向けダッシュボードをインポートできます。

これで完了です。これで、Cloud Ops エージェントで、Nginx から収集した指標を表示できるようになりました。

使ってみる

管理対象が少数の VM かフリート単位かを問わず、システムとアプリケーションから堅牢なオブザーバビリティデータを確実に利用できるようにすることが、効果的なモニタリングとトラブルシューティングの鍵となります。Cloud Monitoring の VM インスタンスダッシュボードや、エージェントポリシーを使う場合や、Ansible、Chef、Puppet、Terraform などのオープンソースツールを使う場合、Google Cloud VM にエージェントをインストールするための多数のオプションをご利用いただけます。Ops エージェントを使うと、インフラストラクチャとアプリケーションのパフォーマンスを最も高い状態で維持するためのデータを収集でき、デプロイの自動化によって日々の管理が非常に楽になります。

これらの手順を説明する動画の視聴をご希望の場合、本ブログ記事のデモを行っている YouTube 動画を視聴してください。また、O11y In Depth プレイリストの残りの動画もぜひご覧ください。

チュートリアルを開始する場合、Ansible 向け Cloud Ops エージェントチュートリアルを活用して、Google Cloud Shell でのシンプルなデプロイについて確認できます。

最後に、Google へのフィードバックやご質問があれば、Google Cloud コミュニティ Cloud Ops までご連絡ください。

- Cloud Ops プロダクトマネージャー Kyle Benson

- プロダクトマネージャー Rahul Harpalani

Sabre 社によるデジタルトランスフォーメーションを成功に導く SRE の活用方法

Tue, 07 Dec 2021 01:00:00 +0000

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

編集者注: 今回は、Sabre 社で SRE 担当ディレクターを務める Kenny Kon 氏にお話を伺いました。Sabre 社は、Google Cloud とのパートナーシップを活用することで、Google の SRE フレームワークの導入に成功しました。Kenny 氏にその経緯について語っていただきます。

Sabre Corporation は、旅行業界のリーダーとして世界の旅行業界の変革を進めるとともに、航空会社、ホテル、旅行代理店向けに、旅行体験を変革し、変化を続ける顧客ニーズを満たすためのソリューションを開発しています。

こうしたソリューションの開発に向け、デジタルトランスフォーメーションを加速させるために、Sabre はクラウドプロバイダである Google Cloud の協力を得ることにしました。提携先に Google を選んだのは、Google Travel のような旅行サービスの管理を通じて、Google が旅行業界を理解しているためです。また、Google は SRE（サイト信頼性エンジニアリング）を考案するとともに、大規模な自社ビジネスを SRE 原則に則って運用しています。この点に最も興味を惹かれました。

初めはマルチクラウドモデルを採用したものの、変革を加速させることができませんでした。そこで、Google Cloud に統合しました。変革のスピードアップを目指し、Google の SRE（サイト信頼性エンジニアリング）手法を導入したことで、信頼性とスピードのバランスが取れるようになりました。この変革を実現できたのは、Google Cloud の Professional Services Organization（PSO）による直接の支援と Cloud Monitoring や Cloud Logging のような Google Cloud のツールを得たこと加えて、Google Kubernetes Engine（GKE）と Cloud Spanner 上で運用したおかげです。

ここでは、Sabre での SRE 導入からわかった、主な 3 つのポイントをご紹介したいと思います。

1. 文化の刷新と SRE の導入に賛同し、熱意を注げる同僚を見つける

SRE 導入の実現に向けて意欲的に取り組むメンバーを集め、組織内にコミュニティを創りましょう。Sabre で SRE を採用した際には、文化の刷新を支持する人々の数が増えて、全員が団結するようになりました。ある程度の勢いがついたところで、全員が共通言語を獲得し、SLO、SLI、さらには Sabre での測定方法について話し合うようになり、経験を分かち合えるようになったことは、良かったと思います。

Sabre では、コミュニティ形成のための手段の一つとして、毎月ランチミーティングを開催しました。これは気軽な集まりで、さまざまなチームがそれぞれの経験や課題を話したり、SLO やトイルなどの SRE に関連する話題について解説したりするものです。また、公開の Google デベロッパーグループ（GDG）を立ち上げ、Google から SRE 分野のエキスパートを何人かお招きして、SRE 原則とベストプラクティスについて話していただいています。

2. 中間管理職のステークホルダーを巻き込む

組織内での SRE 導入を成功に導くうえで、リーダー層の賛同を得ることが非常に重要なのは言うまでもありません。リソースを確保し、全社を挙げて変革を進めるには、経営陣の賛同が非常に重要です。一方、中間層のリーダーの賛同を優先することは忘れられがちです。職位の低い実務担当者が、ボトムアップで組織に変化を起こすのは困難です。一方、経営陣のみの賛同を得てトップダウンで実行しようとしても、中間層でなし崩しになってしまう恐れがあります。ですから、組織文化の形成やチームの意思決定に直接関わる中間層のリーダーを同じように巻き込むことが欠かせないのです。また、反対意見を避けるためには、中間層のリーダー（プロダクト、オペレーション、エンジニアリングの各チームのマネージャー）、つまり部下を持つ管理職が、目指す変革の裏にある真の動機を理解し、協力してくれるよう仕向けることも重要です。中間層のリーダーがそうしたことを理解しなければ、変革を実務担当者にうまく伝えることができず、チームの目標やリソースの配分にも影響が出る可能性があります。

3. 思い切って専門家の助けを借りる

大規模な組織に SRE を導入することは簡単なことではありません。Sabre では、Google の SRE コンサルティングエキスパートの協力を得ることで、大きな変革を成し遂げることができました。PSO がもたらす価値には、トレーニングだけでなく、こちらの話を傾聴してくれることもあります。Sabre の抱える問題を把握し、かつて SRE 導入という同じ道を歩んだ経験豊富な Google の社員の皆さんが、私たちの話に耳を傾け、状況を分析し、Sabre の目標に合ったアプローチを立案してくれました。PSO のサポートにより、Sabre のエンジニアリングチームはお客様をより重視するようになり、プロダクト、運用、開発の各チームとも連携できるようになりました。しかし、なにより重要なのは、リクエストがブロックされることでせっかくの努力が無駄に終わることがなくなり、Sabre のさまざまなチームの満足度が高まったことです。

PSO と提携したとき、Sabre で鍵を握るステークホルダーが、中間層のリーダーと、部下を持つ管理職であることは、すでにわかっていました。そこで、中間層のリーダーに PSO との話し合いや意思決定の場に必ず参加してもらうようにしました。その結果、社内に支持者が増え、それまで抱えていたギャップの解消につながりました。さらに、中間層が本来の力を発揮して、変革に協力できるようになりました。

Sabre が、PSO の SRE パートナーの協力を得て行った取り組みとしては、サービスの階層化の導入、不運のルーレット（WoM）を通じたインシデント管理方法の改善、クリティカルユーザージャーニー（CUJ）の定義、エラーバジェットの導入などを挙げることができます。

こうした SRE の手法を導入してから、Sabre のビジネスはカスタマーエクスペリエンスを重視したものに近づきました。Sabre は現在、お客様のニーズに合わせてリソースを投資しており、それによりチーム間のサイロ化も軽減しました。また、リクエストをブロックすることなく業務を迅速に進められるため、オペレーションチームの満足度も高まりました。SRE は、Sabre に共通言語と共通のフレームワークをもたらしてくれました。さらに、この規範全体が、SRE により文化として有意義なものとなっています。

- Sabre 社 SRE 担当ディレクター Kenny Kon

SRE のベストプラクティスを実現: Cloud Logging における新たなコンテクストのトレース

Fri, 26 Nov 2021 01:00:00 +0000

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

企業のデジタルトランスフォーメーションが進む中、オンラインサービスをサポートするための関連性の高いコンテクストのあるテレメトリーデータの必要性がこの 10 年間で高まっています。これらのデータは、アプリケーションのパフォーマンス問題を積極的に解決するか、コストのかかるサービスダウンタイムを回避するかの分かれ目となります。分散トレースは、SRE のベストプラクティスでも指摘されているように、アプリケーションのパフォーマンスと信頼性を向上させるための重要な機能です。トレース情報を Cloud Logging で直接利用できるようにすることで、アプリケーション内で何が起こっているのかを簡単に理解できるようになりました。

トレースは、伝搬したリクエストの視点からイベントに関する関連情報を合成することで、分散アーキテクチャで動作するアプリケーションの全体的なパフォーマンスを把握するための重要な情報を提供します。これらのイベントはスパンと呼ばれ、トレースオブジェクトの構成要素となっています。

ログとトレースを使った知見と相互関係の高速化

分散トレースは、ログ情報と分散システムのソースレイテンシを関連付けることで、平均修復時間（MTTR）を短縮するユニークな機能を提供します。この機能は、ユーザーが Google Kubernetes Engine（GKE）のような分散コンピューティング環境でワークロードを実行したり、それらと相互作用する場合に特に重要となります。

アプリケーションが構造化されたログ出力を生成するようにインストルメンテーションされている場合、Google Cloud Logging ライブラリと OpenTelemetry を使ってトレースを生成すると、Cloud Logging 内のログラインにトレースファセットが自動的に表示されます。これにより、因果関係のあるイベントをすばやく理解できます。

この機能を説明するために、以下のような状況のトラブルシューティングの簡単さを考えてみましょう。これは、Cloud Run インスタンスが GKE クラスタに検索をかけ、さらに Cloud SQL で管理されるデータベースレイヤに検索をかけるものです。Cloud Run で呼び出しを行うアプリケーションは Go で、GKE の中間ティアは Python（Flask）でデプロイしています。

この例では、サポートスタッフの一人が、Google Cloud Console のアクティビティログに、マイクロサービスベースのアプリケーションが大幅にスローダウンしたという通知を確認します。この問題を解決する一般的な方法は、その時間帯のすべてのソリューションログを調べて、根本的な原因を見つけることです。しかし、オペレーションチームがすべてのワークロードをインストルメンテーションしてトレースを生成していれば、アプリケーションオーナーはその情報をもとに、問題の原因がどのサービスにあるのかを絞り込むことができます。遅れているサービスを特定した後、サービスオーナーをフォローアップしてトラブルシューティングを行うことで、MTTR を大幅に削減できます。

以下の動画キャプチャでは、Cloud Logging プロダクトのログエクスプローラにトレース情報を統合する方法を紹介します。

Google Cloud サービスでのトレースの生成方法

上記のサンプルのトレースを作成するために、Cloud Trace のバックエンドは、異なる Google Cloud サービス（Cloud Run、GKE、Cloud SQL）を介してリクエストが伝播する際に生成されたすべてのスパンを合成しました。そして、そのデータを Cloud Logging のログエクスプローラに表示しました。各サービスでのスパンの作成方法の概要は以下の通りです。

Cloud Run: 生成されたスパンはすぐに使用できる（OOTB）機能であり、先行するロードバランサと Cloud Run のコンピューティングインスタンスの内向きと外向きのアウトを代表するもの。
GKE Pod: Python の Flask アプリケーションは、デベロッパーが OpenTelemetry Flask Instrumentor をアプリケーションに実装した結果、スパンを生成する。
Cloud SQL: SQL ステートメントが Sqlcommenter で補強されている場合、クエリの実行時間に合わせてスパンが自動的に生成される。

結果として、ログラインに埋め込まれたトレース階層のサンプルを以下に示します。

使ってみる

Cloud Logging でトレースを表示するには、まず Google Cloud 上で動作するアプリケーションを計測し、構造化されたログ出力とトレースを生成する必要があります。GKE は標準出力と標準エラーに書き込まれたログを自動的にキャプチャします。または、Google Cloud Logging ライブラリを使用して、Cloud Logging API を使用できます。トレースをキャプチャするには、OpenTelemetry でアプリケーションをインストールすることをおすすめします。この Codelab では、OpenTelemetry でアプリケーションをインストールし、そのトレースを Cloud Trace に送信することを体験できます。

ご質問やフィードバックがございましたら、Google Cloud Community ページをご覧いただき、コメントをお寄せください。

- Google Cloud プロダクトマネージャー、Eyamba Ita

- Cloud Developer Relations 担当デベロッパーアドボケイト、Yoshi Yamaguchi

Managed Service for Prometheus で世界規模のモニタリングを実現

Fri, 19 Nov 2021 06:00:00 +0000

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

Kubernetes のモニタリングの事実上の標準ツールとなっている Prometheus は、多くの基本的なデプロイでうまく機能しますが、Prometheus インフラストラクチャの管理は大規模で困難になる場合があります。Kubernetes のデプロイは企業の IT において大きな役割を果たし続けているため、多くの組織は、グローバル規模で多数の指標を使用できるように Prometheus を早急にスケーリングする必要に迫られています。そこで本日、Google Cloud Managed Service for Prometheus の公開プレビュー版を発表いたします。これは、オープンソースの Prometheus のエコシステムとの互換性を維持する、スケーリングと使いやすさを考慮して設計された新しいモニタリングサービスです。

Google Cloud Managed Service for Prometheus を使用すると、Prometheus または Thanos スタックを自己管理し続ける必要がなくなります。Prometheus インターフェースによるグローバルかつグローバルにスケーラブルなモニタリングが可能になり、オープンソースエコシステムの互換性とポータビリティを維持できます。

現在プレビュー版の Google Cloud Managed Service for Prometheus に関する詳細

Managed Service for Prometheus は、Prometheus 指標の収集、保存、クエリに対応する Google Cloud のフルマネージドサービスで、Monarch 上に構築されています。Monarch は、Google のすべてのアプリケーションモニタリングに使用されているものと同じグローバルにスケーラブルなデータストアです。Managed Service for Prometheus では、Prometheus インフラストラクチャを大規模に手動で管理、運用しなくても、Prometheus を使用して Kubernetes のデプロイをモニタリングしたり、Kubernetes のデプロイに関するアラートを送信したりできます。このサービスは Prometheus の代わりとして簡単に使用できるように構築されているため、Thanos や Cortex のようなセルフマネージドソリューションは不要です。

Google Cloud Managed Service for Prometheus は、Google のすべてのアプリケーションモニタリングに使用されている Monarch 上に構築されています

オープンソースインターフェースを備えた使いやすいサービス

Managed Service for Prometheus は、Prometheus の代わりとして簡単に使用できるツールです。既存の Prometheus 構成を再利用することで、簡単に使用を開始できるよう設計されています。マネージドコレクタをデプロイして、さらに使いやすくすることもできます。ハイブリッドクラウドやマルチクラウドと互換性があるため、Prometheus を実行できるあらゆる環境をモニタリングできます。

データ収集以外にも、クエリを変更することなく、Grafana の既存のダッシュボードや、PromQL ベースのルールとアラートを保持できます。これは、独自開発のマネージドソリューションでは通常サポートされないオープンソース対応のインターフェースでポータビリティを維持できることを意味します。

Managed Service for Prometheus は、Google 独自の指標で使用されているものと同じグローバルかつグローバルにスケーラブルなバックエンド上に構築されています。このサービスは、6 京 5,000 兆のポイントを保持している 2 兆以上のアクティブな時系列を収集しているため、お客様のビジネスで生成される指標ボリュームがどれだけ多くても対応できます。このシステムは、リージョンごとに保存される元の指標データを対象とした、クエリ時のグローバルなアドホック集約をサポートしています。さらに、追加料金なしに、デフォルトでデータを 2 年間保持できます。

Managed Service for Prometheus は、Google Cloud の他のモニタリングサービスと同じバックエンド上にあるため、Cloud Monitoring と互換性があります。実際、Cloud Monitoring 内で Managed Service for Prometheus 指標とともに無料の Google Cloud プラットフォーム指標に対してクエリを実行できます。

お客様によるプレビュー版導入成功事例

Next '21 でこのプレビュー版を初めて発表した際には、OpenX の Bartosz Jakubski 氏にも参加していただき、Managed Service for Prometheus が Prometheus と Thanos の管理の負担を軽減し、同社のビジネスの成長をサポートしている様子について説明していただきました。

Horizon Blockchain Games もこのプレビュー版を利用しているお客様であり、すでにメリットを実感しています。同社の CEO 兼チーフアーキテクトの Peter Kieltyka 氏は次のように述べています。「当社は GKE 指標のために自社だけで Prometheus を運用してきましたが、継続的なメンテナンスによって非常に多くの開発時間が奪われ、拡大するビジネスに応じた指標インフラストラクチャのスケーリングに自社では対処したくないと考えていました。そこで Google Cloud Managed Service for Prometheus の使用を開始したところ、うまく機能しています。Google が使用しているものと同じバックエンド上に構築されているので、どれだけのボリュームにも対応できます。また、オープンな標準とプロトコルを確保しながらも、以前と同じ Grafana ダッシュボードを使い続けることができています。」

ご利用方法

Managed Service for Prometheus の取り込みの構成は簡単です。既存の Prometheus バイナリを Managed Service for Prometheus バイナリに置き換え、新しいデータソースを設定して、指標を読み取るよう Grafana を構成するだけです。ご利用を開始するには、Managed Service for Prometheus のドキュメントをご覧ください。

- プロダクトマネージャー Lee Yanco

Google Cloud Monitoring の基本: 指標の種類について

Fri, 29 Oct 2021 10:00:00 +0000

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

アプリケーションをクラウドに移行する場合でも、Kubernetes を使用してモダナイズする場合でも、クラウドベースのワークロードの観察は従来型のデプロイメントの観察より困難です。オンプレミスのモノリスをモニタリングするとき、運用チームはスタック全体を完全に可視化し、どのテレメトリーデータ（インフラストラクチャからプラットフォームやアプリケーションのデータまで）をどのように収集するかを完全にコントロールできました。クラウドベースのアプリケーションでは、テレメトリーを集約、統合、分析して完全な可視化を実現するのは、次の理由からより難しくなります。

データの発生するソースが多くなります。アプリケーションやワークロードのコンポーネントから得られるテレメトリーデータに加えて、クラウドインフラストラクチャ（VM、ロードバランサなど）、クラウドプラットフォーム（Kubernetes、Docker など）、およびクラウドサービス（ストレージ、データベースなど）からのテレメトリーデータを統合する必要があります。
システムによって可視性のレベルは異なります。テレメトリーデータの収集元である各種のソースは、それぞれデータ収集のためのメカニズムが異なっています。一部のソースは API でデータを公開するのに対し、別のソースではユーザーがエージェントをインストールする必要があります。一部のサービスはデータをエンドポイントに push しますが、他のサービスではユーザーがエンドポイントからデータを pull する必要があります。
データの収集、保持、集約の粒度も異なる可能性があります。一部のソースでは細かい粒度（秒単位）でデータを収集できるのに対して、他のソースではより粗い粒度（分単位）でしかデータが公開されないことも考えられます。短い期間（数日）だけ保持されるテレメトリーデータもあれば、はるかに長い期間（数年）保持されるテレメトリーデータもあります。

これらの技術的な相違に加えて、オブザーバビリティソリューションを実行するコストも問題になる可能性があります。収集可能な指標データの一部だけをコントロールできると仮定して、「どのテレメトリーデータは有料で購入する必要があり、どのテレメトリーデータは使用しているサービスの一部として無料で入手可能か？」と自問するかもしれません。

オブザーバビリティという言葉は、指標、イベント、トレース、ログなど各種のシグナルを網羅していますが、このブログでは Google Cloud での指標の収集について解説します。このブログでは、Google Cloud での指標の収集について、3 つの観点で説明します。

収集される指標の種類のバリエーション
各種の指標が収集される方法
どの指標が有料で、どの指標が無料か

ここでは、Google Compute Engine（GCE）、Google Kubernetes Engine（GKE）、Google BigQuery（BQ）の 3 つのサービスについて、これらの側面を探求します。これら 3 つの例は、ユーザーが Google Cloud サービスに対してどの程度の可視性を持てるかという点について、それぞれコントロールのレベルが異なります。

GCE: 指標を収集するエージェントのデプロイについて、ほぼ完全なコントロール
GKE: 指標を収集するエージェントのデプロイについて、多少のコントロール
BQ: 指標を収集するエージェントのデプロイをコントロール不能

指標のタイプ

これら 3 つのクラスのサービスにわたり、多くの種類の指標が収集されますが、システム指標、エージェント指標、ユーザー定義指標、ログベースの指標の 4 つに大きくグループ化できます。

1. システム指標

システム指標は Google Cloud によって計測および収集され、プラットフォームのマネージドサービスがどのように動作しているかを可視化できます。これらの指標を収集するためにエージェントをデプロイする必要はなく、これらの指標は Google Cloud Monitoring へ自動的に送信されます。

これらの指標は使用されるコンテキストによって呼び方が変わる可能性がありますが、一般的にはすべてシステム指標のグループになります。システム指標は Google Cloud 指標、GCP 指標、「組み込み」指標、システム定義指標、プラットフォーム指標、インフラストラクチャ指標とも一般的に呼ばれます。サービスの種類によって用語が異なる場合もあります。

Infrastructure as a service（IaaS）ユーザーは、これらをインフラストラクチャ指標と呼ぶことがあります。
Platform as a service（PaaS）/ Containers as a service（CaaS）ユーザーは、これらをプラットフォーム指標と呼ぶことがあります。
Software as a service（SaaS）ユーザーは、これらをサービス指標と呼ぶことがあります。

使用のコンテキストにかかわらず、これらはすべて「組み込み指標」です。特定の Google Cloud サービスの使用コンテキストでは、次のような呼び方をすることもあります。

Kubernetes 指標: GKE から収集されます。GKE の以前のバージョンでは、コンテナ指標と呼ばれていました。このタイプの指標は、名前の先頭に kubernetes.io が付いています。これらは Kubernetes クラスタ内のコンテナ、Pod、ノードのリソース指標です。
Anthos 指標: オンプレミスの Anthos と、ベアメタルの Anthos から収集されます。このタイプの指標は、名前の先頭に kubernetes.io/anthos が付いています。
Istio 指標: Google Kubernetes Engine の Istio から収集されます。このタイプの指標は、名前の先頭に istio.io が付いています。
Knative 指標: Google Kubernetes Engine の Knative から収集されます。このタイプの指標は、名前の先頭に knative.dev が付いています。

2. エージェント指標

エージェント指標には、広範なタイプの指標が含まれます。名前が示すように、エージェント指標では指標を収集するためにエージェント（Cloud Monitoring エージェントか、統一 Ops エージェント）をインストールする必要があります。エージェントベースの指標では、アプリケーション開発者が指標を設定する必要はなく、エージェントで構成が必要なパッケージ済みのレシーバー / コレクタとして使用できます。ユーザーのインストールしたエージェントは、次のタイプの指標を収集します。

リソース指標: リソースについての指標で、仮想マシン（VM）のコンピューティング、ネットワーク、ストレージを含みます。これらのリソースには、Google Cloud が管理するもの（GCE VM など）、お客様が管理するもの（オンプレミスのホストなど）、別のクラウドのリソースであるもの（AWS VM）があります。
プロセス指標: リソース指標は高レベル、たとえば VM レベルの可視性を提供します。プロセス指標はより粒度が細かく、VM 内で実行されている特定のプロセス（たとえば、データのバックアッププロセス）に関する、CPU、メモリ、I/O、スレッド数などの測定値が含まれます。
サードパーティ指標: VM（GCE や他の場所）またはコンテナ（Nginx、Kafka、MySQL など）で実行されるサードパーティソフトウェアやオープンソースのソフトウェアについての指標。これらの指標により、それらのソフトウェアコンポーネントの内部動作について、特定目的に合わせた可視性を得ることができます。

注: Ops エージェントは自分自身についての指標も収集できます。この場合、名前の先頭に agent.googleapis.com/agent が付きます。エージェントにより収集された、他のソフトウェアコンポーネントについての指標は、名前の先頭に agent.googleapis.com/<コンポーネント名> が付きます。

3. ユーザー定義指標

ユーザー定義指標は、デプロイ済みのアプリケーションやワークロードへの可視性を提供するもので、ユーザーが定義して設定します。ユーザー定義指標には次のものが含まれます。

カスタム指標: カスタム指標はクライアントライブラリか Cloud Monitoring API を使用して取り込む、または Ops エージェントをデプロイして指標を収集してから、Cloud Monitoring に取り込むことができます。これらの指標の名前は、先頭に custom.googleapis.com が付きます。
ワークロード指標: ワークロード指標には、リソースで実行されるアプリケーションで生成される広範なデータが含まれます。これらのアプリケーションがモノリス、コンテナ、データ処理 ETL ジョブのどれでも、コードを組み込んで、対象のタスクに特に関連する指標を生成する必要があります。これらの指標は、そのワークロードが使用しているリソースについての情報（例: アプリケーションオブジェクトによるメモリ消費や、SPARC ジョブにより処理されるデータレコードの数）や、場合によってはいくつかのビジネス指標（発注を行ったユーザーの数や、処理された合計金額）を捕捉します。ワークロード指標は、名前の先頭に workload.googleapis.com が付きます。ここでも、コンテキストによってはワークロード指標のことを「アプリケーション指標」や「ジョブ指標」と呼ぶことがあります。
外部指標: オープンソースまたはサードパーティのアプリケーションから収集されます。Google Cloud プロジェクトに送信される指標で、指標タイプが external.googleapis.com で始まるものは、外部指標と呼ばれます。
Prometheus 指標: 一部の Kubernetes ユーザーは、自分の Kubernetes 環境をモニタリングするために Prometheus を使用します。さらに、これらのユーザーは Prometheus 指標を Google Cloud Monitoring に伝搬し、その豊富な機能を活用します。Prometheus は、Cloud Monitoring で構成できます。この場合、Prometheus によりエクスポートされた指標は Cloud Monitoring の指標タイプに変換されます。

4. ログベースの指標

ログベースの指標は、Cloud Logging に取り込まれたログから生成されます。これらの指標は、特定のパターンに一致するログイベントをカウントする、または特定のログイベントのフィールドを抽出して集約することで作成できます。その後で、ログベースの指標は Cloud Monitoring に書き込まれ、アラート、チャート、ダッシュボードに使用できます。ログベースの指標には 2 種類あります。ユーザー定義（ユーザーが定義を作成するもの）とシステム定義（定義が最初から使用でき、ユーザーには変更できないもの）です。

指標の収集

指標は、Google サービスと、Google サービス上で実行されているアプリケーションから、いくつかの方法で収集されます。ここでは、各指標についての説明は省略しつつ、それぞれの収集メカニズムについて解説します。

1. GCE から指標を収集する

GCE の指標は、2 つの異なるメカニズムを使用して収集されます。

すでに述べたように、GCE のシステム指標（またはインフラストラクチャ指標）は、指標を収集するエージェントをインストールする必要がありません。Google はこれらの指標を自動的に収集し、プロジェクトに push します（図 1 を参照）。システム指標は一般に、Cloud Monitoring への取り込み前にバッチ処理されます。
GCE 指標を収集する 2 番目のメカニズムは、Ops エージェントや従来型のモニタリングエージェントをインストールすることです。エージェントをインストールすると、2 つの部分で利点があります。

システム指標を非常に細かい粒度（1 分以内）で収集でき、個別の Linux や Windows プロセスのプロセス指標にアクセスできます。
開発者がアプリケーションを GCE VM にデプロイする際に、アプリケーション指標も生成できます。エージェントはほぼ瞬間的に指標を収集してプロジェクトに読み込むため、分析、アラート、ダッシュボードを迅速に行えます。

図 1

2. GKE から指標を収集する（Prometheus 不使用）

Prometheus を使用しない場合も、2 種類のメカニズムで GKE 指標を収集できます。GKE クラスタでは一部のノードがユーザー管理で、コントロールプレーンノードなど他のノードは Google で管理されるため、指標収集のシナリオは多少複雑になります。GCE 環境の場合と同様に、システム指標はエージェントのデプロイなしで収集されます。

お客様が管理する GKE ノードについては、各種のリソースとワークロードについて指標を収集できます。GCE VM（Kubernetes ノードの基盤）については、Google コレクタでシステム指標がキャプチャされ、Cloud プロジェクトに送られます。プラットフォーム指標を収集するため、Kubernetes クラスタが作成される際に、GKE のお客様が管理するノードに Google コレクタが自動的にデプロイされます。これらのコレクタは Kubelet 経由で Kubernetes 指標を収集し、プロジェクトに公開します。

図 2

GKE コントロールプレーンでは、ノードは Google により管理され、これらのノードからの指標は Cloud Monitoring に公開されません。ただし、これらの指標は自動的に収集され、Kubernetes スケジューラにより、スケーリングやリソース管理の決定に使用されます。ここでも、これらの指標を収集するためにユーザーがエージェントソフトウェアをデプロイする必要はありません。これらの Google コレクタは、クラスタが作成される際に Google により展開され、管理されます。

最後に、開発者はワークロードから出力された Prometheus 互換の指標、たとえば CronJobs や Deployments などを GKE クラスタ上で、フルマネージドの構成可能なパイプラインを使用して Cloud Monitoring から収集できます。開発者がどの指標を収集するかを構成すれば、他の動作はすべて GKE が行います。

3. GKE から指標を収集する（Prometheus 使用）

Prometheus は、Kubernetes 環境をモニタリングするための一般的な選択肢です。GKE にアプリケーションをデプロイしているお客様は、モニタリングに Prometheus を引き続き使用できます。Prometheus の表示形式を使用するサービスによって生成された指標は、クラスタからエクスポートし、Cloud Monitoring で表示できます。

図 3

このユースケースでコントロールプレーンノードから指標を収集する動作は、Prometheus を使用しないユースケースとほぼ同じです。しかし、ワーカーノードからの指標収集は異なります。Prometheus は Kubernetes ワーカーノードの 1 つにデプロイされ（図 3）、Pod から、および Kubelet API 経由で指標をスクレイピングします。アダプタが Prometheus から指標を収集し、Cloud Monitoring にアップロードします。

有料の指標と無料の指標

運用チームは常に IT の経費について考えており、モニタリング、ロギング、診断、トラブルシューティングのツールのうちどれが有料で、どれが無料なのかを一般的に明確化することを必要としています。何が有料で何が無料なのか、消費量アラートのしきい値の設定、その他の情報に関する明確な最新のガイドについては、Google Cloud のオペレーションスイートの料金ページをご覧ください。ここで説明した 4 つの大きなカテゴリの中で、システム指標は無料です。他のカテゴリの指標はすべて有料です。この一般的な説明には例外が 2 つあります。エージェントが収集した指標は有料ですが、エージェント自体についての指標（agent.googleapis.com/agent 名前空間に含まれるもの）は無料です。同様に、ログベースの指標は有料ですが、システム定義のログベースの指標は無料です。

さらに詳細な情報と、最新情報については、料金ページをご覧ください。

まとめ

クラウドベースのサービスとワークロードのオブザーバビリティのためには、収集と分析を必要とする多様な指標を理解する必要があります。これらの指標はシステム指標、エージェント指標、ユーザー定義指標、ログベースの指標に分類されます。このブログでは、指標のタイプ、これらの指標を収集するため使用される一般的なアーキテクチャ、および Google Cloud Monitoring を使用するときに、どの指標が有料で、どの指標が無料かについて解説しました。

ご不明な点やフィードバックがございましたら、Google Cloud コミュニティのオペレーションスイートのセクションでお知らせください。

- アウトバウンドプロダクト管理担当ディレクター Rakesh Dhoopar

GKE ワークロード指標による Kubernetes アプリケーションのより的確なモニタリング

Fri, 15 Oct 2021 15:10:00 +0000

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

最近リリースされた 2021 年の Accelerate State of DevOps Report によると、最新の運用方式に秀でているチームは優れたソフトウェアデリバリーと運用パフォーマンスを報告する割合が 1.4 倍も高く、ビジネス上の良好な成果を報告する割合も 1.8 倍高いことが示されています。最新の運用方式の基本的な要素は、重要な指標の追跡、分析、アラートを行うためにモニタリング用のツールを設置することです。Google は本日、Google Kubernetes Engine（GKE）デプロイメントを従来よりも簡単にモニタリングできる新機能として、GKE ワークロード指標を発表します。

GKE ワークロード指標（現在プレビュー版）について

GKE で実行されるアプリケーション用に、GKE ワークロード指標のプレビュー版が公開されました。これは柔軟な構成が可能なフルマネージド型のパイプラインで、GKE 上で実行されるワークロードから出力される Prometheus 互換の指標を収集し、Cloud Monitoring に送信します。GKE ワークロード指標により、あらゆる GKE ワークロード、たとえば CronJob や Deployment などから出力される指標を簡単に収集できるため、指標収集のパイプラインの管理に時間を費やす必要がなくなります。収集する指標を構成するだけで、すべての動作は GKE によって行われます。

GKE ワークロード指標の利点は次のとおりです。

セットアップが簡単: kubectl apply コマンドを 1 回実行するだけで PodMonitor カスタムリソースをデプロイでき、指標の収集を開始できます。手動でのエージェントのインストールは必要ありません。
柔軟な構成が可能: スクレイピングエンドポイント、頻度、その他のパラメータを調整できます。
フルマネージド型: Google がパイプラインの保守を行うため、総所有コストを削減できます。
費用の管理: 指標を柔軟にフィルタリングできるため、Cloud Monitoring のコストを簡単に管理できます。
オープン標準: Prometheus Operator の PodMonitor リソースに従ってモデル化された PodMonitor カスタムリソースを使用して、ワークロード指標を構成できます。
HPA のサポート: Stackdriver Custom Metrics Adapter との互換性により、カスタム指標での水平スケーリングが可能です。
低価格設定: より直感的かつ予測可能で手頃な価格設定となっています。
Autopilot のサポート: GKE ワークロード指標は GKE Standard クラスタと GKE Autopilot クラスタの両方で利用できます。

すでに多くのお客様が、このシンプルなモデルからさまざまなメリットを得ています。

「GKE ワークロード指標を使用することで、カスタム指標のスクレイピングを行うために別の Prometheus サーバーをデプロイして管理する必要がなくなりました。管理はすべて Google により行われます。当社は面倒な作業なしに、カスタム指標がもたらす価値を有効に活用することに集中できるようになりました。」- ポルトガルの通信およびメディア企業 NOS SGPS S.A. 社のクラウドアーキテクト、Carlos Alexandre 氏

ご利用方法

GKE クラスタ内で GKE ワークロード指標パイプラインを有効にする方法は次のとおりです。

code_block: <ListValue: [StructValue([('code', 'gcloud beta container clusters update YOUR_CLUSTER_NAME \\\r\n --zone=YOUR_ZONE\r\n --project=YOUR_PROJECT\r\n --monitoring=SYSTEM,WORKLOAD'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fae4034bd90>)])]>

GKE ワークロード指標は現在プレビュー版であるため、必ず gcloud beta コマンドを使用してください。

収集する指標を設定する方法の詳細については、GKE ワークロード指標ガイドを参照してください。また、Stackdriver Prometheus サイドカーの GKE ワークロード指標への移行のガイドも参照してください。

料金

現在のところ GKE ワークロード指標を Cloud Monitoring に取り込んでも料金は発生しませんが、2021 年 12 月 1 日からは料金が発生します。詳しくは、Cloud Monitoring の料金設定をご覧ください。

Cloud Monitoring による最新の運用

GKE ワークロード指標が Cloud Monitoring に取り込まれると、グローバルなスケーラビリティ、長期間（24 か月）の保存オプション、Cloud Logging との統合、カスタムダッシュボード、アラート、SLO モニタリングなどの優れた機能をすべて使用できるようになります。これらと同じ機能はすでに GKE システム指標でも使用でき、こちらは無料で、GKE クラスタからデフォルトで収集され、GKE ダッシュボードで使用できます。

ご質問がある場合や、フィードバックをお寄せになる場合は、Google Cloud コミュニティのオペレーションスイートのページをご覧ください。

- プロダクトマネージャー、Nathan Beach

クラウドとその先へ: Google Cloud の Professional Services Organization による移行支援

Fri, 24 Sep 2021 11:00:00 +0000

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

Google Cloud の Professional Services Organization（PSO）は、オペレーション、ビジネス、技術面での課題の克服にクラウドをどのように役立てられるかを検討し始める時点から、クラウドワークロードの最適化を見据える時点まで、お客様と連携してクラウド内での効果的かつ効率的なオペレーションを実現します。

クラウドへの移行においてはすべての段階が重要ですが、どの段階も複雑化する可能性があります。このブログ投稿では、移行プロセスを確実に成功させるためのさまざまな活動に PSO がいかに関わるかを中心に見ていきたいと思います。

PSO は、信頼できるテクニカルアドバイザーチームとして、次の 3 つのフェーズで移行にアプローチします。

移行前の計画
カットオーバー作業
移行後のオペレーション

この投稿では、移行に必要なすべてのステップを詳細に取り上げるのではなく、お客様の目標の達成、リスク管理、価値実現のための具体的な活動に PSO がどのように関わるかに着目していきます。成功を確実にするために利用するアセット、プロセス、ツールについても解説します。

移行前の計画

スコープの評価

移行の前に、目指す将来像を理解して明確にする必要があります。PSO は、ロジスティックの観点からキャパシティプランニングの策定を支援し、理想の将来像に向けて十分なリソースを確保できるようにします。

クラウドに移行すると、従来のデータセンターおよびコロケーションに伴う物理、ロジスティック、財政上の懸念の多くを考慮しなくてすむようになりますが、割り当てのアクティブな管理、大規模移行の準備、予測の必要がなくなるわけではありません。PSO は、ニーズの先行予測を支援し、キャパシティチームと協力して、割り当ての調整、リソース管理、可用性の確認を行います。

将来像が固まったら、PSO はプロダクトチームと連携して、機能面における課題の割り出しも行います。PSO は、関連するプロダクトチームとともに、Google Cloud サービス全体の機能リクエストを把握し、それらが適切に理解、記録、追跡、優先順位付けされているかを確認します。その後、お客様と密接に協力して、当該機能の実現を待つとともに今後のロードマップを更新しながら、当面利用できる回避策がないか判断します。

移行アプローチおよびツールの開発

Google Cloud 内には、移行プロセス中の支援に使用できるアセットとツールのライブラリがあります。.これらのアセットは、他のお客様の効率的かつ効果的な移行を完了させるために役立っています。

スコーピングの要件および移行支援に利用できるツールに基づいて、PSO が移行アプローチの推奨を支援します。.各企業には固有のニーズがあり、複雑さや規模のレベルも異なります。また、移行に組み入れる必要のある、規制、オペレーション、組織に関する課題があります。PSO は、お客様がさまざまな移行オプションとそれらがどのように展開されていくのかについて検討できるようサポートします。

PSO は、お客様のチームと連携して、サーバーをオンプレミスから Google Cloud に移動するための最適な移行アプローチを決定します。PSO は、リファクタリング、リフト＆シフト、新規インストールなどのさまざまな移行アプローチをお客様に案内します。そこから、その移行に最適なアプローチをお客様が決定できます。PSO は、ユースケースが類似する他のお客様を参考にしたベストプラクティスとユースケースに関するガイダンスを提供します。

Google には、アセットの検出、実際の移行、移行後の最適化を支援できるさまざまなクラウドネイティブのツールが用意されています。たとえば、PSO は、プロジェクトマネージャーと連携して、お客様のサーバー移行要件に対応できる最適なツールを判断するための支援を提供します。また PSO は、Google のプロダクトチームとも連携して、各ツールの機能およびユースケースに最適な方法をお客様が十分理解できるようにします。万能のツールなどないことを Google は承知しています。そのため PSO は、お客様と協力して、さまざまな要件に合わせて最適の移行アプローチおよびツールを判断します。

カットオーバー活動

計画作業がすべて完了したら、PSO はカットオーバーの成功を確実にする支援を行います。

お客様にとって重要なイベントの最中およびそれに先立つ期間中に、PSO は、重要ワークロードのサポートと準備を強化する先行型のイベント管理サービスを提供できます。プラットフォーム上に確固としたアーキテクチャおよびインフラストラクチャを設けるだけでなく、このインフラストラクチャのサポートが不可欠です。課題が生じた場合にお客様をサポートして障害を取り除く追加リソースについては、TAM がその確保を支援します。

イベント管理活動の一環として、PSO は Google Cloud サポート組織と連携し、課題が生じた状況でも迅速な修正と高い復元力が確保されるよう努めます。重要な作業や障害発生について迅速に意思疎通しやすいように、通常は指令室が設けられます。これらの指令室は、問題のトリアージと解決を担当するサポートチームとエンジニアリングチームへの直接回線をお客様に提供できます。

移行後の活動

カットオーバー完了後、PSO は引き続き、インシデント管理、キャパシティプランニング、継続的運用サポート、最適化などの分野でサポートを提供し、最初から最後までお客様の移行が確実に成功するよう努めます。

PSO は、お客様と Google エンジニアとの間を取り持つ連絡役を担います。サポートケースのエスカレーションが必要な場合、PSO は、適切な関係者が関与してタイムリーにケース解決に取り組めるようにします。オペレーションの厳密さを追求するうえで、PSO は、お客様と協力して、ある特定の Google Cloud サービスがお客様の目標に役立つかを判断します。サービスがお客様に付加価値をもたらす場合、PSO は、お客様の目標および現在のクラウドアーキテクチャに沿ってそのサービスを実現できるよう支援します。サービスに不足部分がある場合、PSO は、お客様および Google のエンジニアリングチームと積極的に協力し、サービスに追加機能を実現することにより不足を補います。

PSO は引き続きエンジニアリングチームと協力し、お客様のクラウドアーキテクチャについて、費用対効果の最も高い最適な設計を確保するとともに Google のベストプラクティスガイドラインを遵守するための推奨策を、常に検討および提供していきます。

PSO には、移行のほか、Google Cloud の継続的トレーニングをお客様に提供する役割もあります。Google Cloud の持続的発展を確保するため、PSO は、Google Cloud でプロジェクトを成功させるために必要なスキルをお客様が確実に備えるための学習ロードマップを、お客様と共同開発します。

結論

Google の PSO は、必要なガイダンス、方法、ツールをお客様に確実に提示できるよう、お客様のクラウド移行全般に積極的に取り組みます。PSO は、キャパシティプランニングなどの重要分野において移行前計画から移行後に至る一連の作業に関与し、トラブルシューティングのための技術関連ケースへのサポート提供に対する十分なリソースが将来のワークロード向けに割り当てられるようにします。PSO は、お客様の代弁者となってお客様の Google Cloud 環境に信頼と安定を提供する、長期的な信頼できるアドバイザーの役割を果たします。

移行に関して PSO チームと連携したい方はこちらをクリックしてください。または、現在の IT 環境に関する無償の検出と評価から始めることも可能です。

- Google Cloud テクニカルアカウントマネージャー Nelson Lam

-Google Cloud テクニカルアカウントマネージャー Charlotte Wen

Lowe’s が SRE により平均復元時間（MTTR）を 80 パーセント以上削減した方法

Tue, 21 Sep 2021 09:00:00 +0000

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

編集者注: 以前のブログ投稿で、住宅リフォーム小売業者の Lowe’s が Google Cloud で Google のサイト信頼性エンジニアリング（SRE）フレームワークを採用し、サポートできるリリース数を増加させた事例をご紹介しました。Lowe’s はリリースの頻度を 2 週間に 1 回から 1 日 20 回以上に増加させ、顧客のニーズにより迅速かつ効率的に対応できるようになりました。本日は、Lowe’s の SRE チームから、SRE の原則を活用して平均復元時間（MTTR）を 80 パーセント以上も削減させた手法をご紹介いただきます。

Lowes.com の管理の重要性はかつてなく高まっています。つまり、お客様が当社のサイトで取引を続けられるように、可能な限り迅速にインシデントを特定し、トラブルシューティングを行って復元する必要があるということです。

そのためには、確固としたインシデントエンジニアリング手法を確立することが重要です。「インシデントを解決する」とは、その影響を緩和し、サービスを以前の状態に戻すことを意味します。これにかかる平均時間を「平均復元時間（MTTR）」と呼びます。この指標をトラッキングすることで、Lowe’s のシステムの全体的な信頼性を常に把握できると同時に、復元のスピードを改善できます。当社の目標は、エラーがあってもビジネスに悪影響が及ばないよう、MTTR の指標を可能な限り低く抑えることです。当社では、MTTR を全体的に改善するために、次の 4 つの領域に取り組みました。

Lowe’s のインシデント報告プロセス

MTTR を削減するために、SRE の原則に従ってシームレスなインシデント報告プロセスを定めました。当社のインシデント報告プロセスは、インシデントが発生した時点で開始し、事後調査の報告後に SRE 責任者がアクションアイテムをクローズすることで終了するというワークフローです。このアプローチにより、重大なインシデントの件数を抑えることができています。この報告プロセスを構成するのは、モニタリング、アラート、過失を責めない事後調査（ブレームレスポストモータム）という 3 つの中核的な要素です。

モニタリングとアラート

インシデント管理に関しては、適切なモニタリングとアラートを実施することが重要です。モニタリングとアラートのツールにより、問題が発生すると即座に検出でき、可能な限り短時間で最適な担当者が通知を受けて対処できます。測定の観点からは、これを平均確認応答時間（MTTA）としてトラッキングしています。これは、アラートがトリガーされてから問題への対処が開始されるまでの平均時間です。

インシデントが発生した時点で、モニタリングとアラートのツールが PagerDuty を介して電話、テキストメッセージ、メールの形式でオンコールの SRE 第一対応者に通知します。当社の SRE ソフトウェアエンジニアリングチームは、さまざまなサービスレベル指標（SLI）アラートやサービスレベル契約（SLA）通知を可能にするために多数の自動化を行ってきました。オンコールの SRE 担当者はその後、サービス / ドメインの関係者とのトリアージコールを開始してインシデントを解決します。この結果、MTTA を 2019 年の 30 分から 1 分に削減できました。削減率は 97 パーセントです。

過失を責めない事後調査: インシデントから教訓を得る

事後調査はインシデントに関する書面の記録で、インシデントの影響、解決のためにとったアクション、原因、インシデント再発防止のためのフォローアップアクションが記載されます（サンプルはこちら）。過失を責めない事後調査はこれを基盤としており、SRE の文化、そして Lowe’s の文化の中核をなしています。個人を非難の対象とすることなく、すべての事後調査の結果を教訓とプロセス改善の糧にしています。

当社にとって、事後調査のプロセスはインシデントワークフローにおいて最も大きな部分を占めます。SRE が新しい事後調査レポートを作成する場合、その最初のステップは、レポートの確認を担当するドメインの関係者と事後調査セッションを実施することです。その後、事後調査は確認段階に入り、週 1 回の事後調査会議で他の関係者による確認も行われます。プロセスの最終段階では、週 1 回の会議にて参加者全員がレポートの完成に同意した後、SRE 責任者がレポートをクローズします。

事後調査を適切に行うには、個人ではなく、システムおよび運用プロセスの不備や問題に焦点を当て続け、特定した問題に対処するための具体的なアクションを定めることが重要です。これを確実に行うために、当社はいくつかのベストプラクティスを実践しました。

まず、問題を特定した人物から情報やデータを収集し、各 SLI オーナーは不備を特定するか、影響の原因を作った 1 段階上流の SLI オーナーを特定する。
すべての SLI オーナーにそれぞれのケースを提示する機会を十分に与え、問題の特定をコミュニティの作業として行う。
アクションアイテムとプロセス変更を特定したら、それらのアクションを完了するオーナーを指名するか、立候補を募る。
簡単に参照できるように、インシデントナレッジベースに事後調査を公開および保存する。このプロセスにより、将来インシデントが発生しても、SRE は継続的な改善を実現できる。

継続的な改善

過失を責めない事後調査に必要な、透明性の高い率直かつ直接的なフィードバックの文化を促進するには、経営幹部からの支持のもと、インシデント責任者に議論や成果を全体的に取り仕切る権限を与え、繰り返し取り組みを行う必要があることがほとんどです。事後調査を成功させ、そこで決定したアクションアイテムを完了したら、SRE のパフォーマンス目標評価において、成果として認められ、考慮される必要があります。Google の SRE ブックで説明されているように、効果的な事後調査の記述を、経営陣の認知と参加を得た、報酬と称賛に値する作業とすることが推奨されます。経営陣から全面的な賛同を得られていない場合、企業文化を変革する途中の段階で効果的な事後調査を行ううえで、ここが最も達成の難しい部分となるでしょう。

しかし、そうするだけの価値は十分にあります。このプロセスは、当社が最終的に MTTR を 2019 年の 2 時間からわずか 17 分に減少し、改善させることができた主たる要因です。

当社の SRE インシデント報告プロセスにより、企業としての問題解決への取り組み方も大きく変化しました。アラートから問題解決、過失を責めない事後調査までのワークフローを合理化したことで、MTTR を 82 パーセント、MTTA を 97 パーセント削減できました。最も重要な点は、チームがあらゆるインシデントから教訓を学んでいること、またその結果エンジニアとして成長し続けていることです。クラウドにおける SRE のベストプラクティスの実践について詳しくは、Google Cloud の SRE のウェブサイトをご覧ください。

謝辞

本ブログ投稿に協力してくれた Lowe’s の Rahul Mohan Kola Kandy、Vivek Balivada、そしてデジタル SRE チームに感謝します。

-Lowe’s Companies, Inc. デジタル SRE 担当リードソフトウェアエンジニア Shyam Palani 氏

-Lowe’s Companies, Inc. デジタル SRE 担当リードソフトウェアエンジニア Nishanth Prasad 氏

一般的なサーバーレスサービス向けの手間いらずのパフォーマンス分析情報

Wed, 01 Sep 2021 10:00:00 +0000

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

デベロッパー、DevOps、SRE は、サービスまたはアプリケーションの存続期間内に、レイテンシの原因を必ず調査することになります。通常は、レイテンシを引き起こしているのがアプリケーションか、基盤となるインフラストラクチャかを判断するところから始めます。問題が発生したときに、これらのリソースのパフォーマンスを示すシグナルを探す必要があります。

レイテンシシグナルとしてトレースを使用する

一般的に、レイテンシに最も有意義な情報を提供するシグナルはトレースです。トレースは、実行中のロードバランサ、コンピューティング、データベースなどといった分散型システムのすべてのレイヤにリクエストを反映するのに要した合計時間を表します。実行の各レイヤを表すために使用されるトレースのサブセットは、スパンと呼ばれます。

トレースを生成するのは難しく、そのためにこの便利なトラブルシューティングリソースを利用できないユーザーが数多く存在します。デベロッパーがもっと簡単にトレースを利用できるようにするため、Google は、最もよく使われるサーバーレスコンピューティングオプションである AppEngine、Cloud Run、Cloud Functions のインストゥルメンテーションを開始し、トレースがデフォルトで生成されるようにしました。複雑な分散システムの状況全体は把握できませんが、トラブルシューティング時に重点を置くべき分野を決めるために必要な情報は得られます。

このメリットを今すぐ手に入れる方法

その方法とは、何もしないことです。コードが AppEngine、Cloud Run、Cloud Functions などのサーバーレスコンピューティングにデプロイされると、このコンピューティングを介する上り（内向き）と下り（外向き）トラフィックによりスパンが自動的に生成されます。こうしたスパンはキャプチャされ、Cloud Trace に 30 日間追加料金なしで保存されます。追加規約についてはこちらをご覧ください。生成されるトレースは、レイテンシの代表的な値を含むウォーターフォールグラフとして可視化されます。さらに、Google はこの機能を、PostgreSQL のクエリプランの代表的なトレースを生成し、これを Cloud Trace に送信する Cloud SQL Insights とともに、Google Cloud データベースに拡張しました。

以下のスクリーンショットは、Cloud Run にデプロイされたシンプルな “Helloworld'' アプリケーションからキャプチャされた 1 日目のトレースです。ロードバランサのスパン（ルートスパン）は、Google Cloud のインフラストラクチャを介した合計時間を示し、Cloud Run のスパンはコンピューティングがリクエストを実行して処理するために要する時間を示しています。

以下の図にあるように、ロードバランサのスパンは Cloud Run のスパンとほぼ同等です。したがって、観測されるレイテンシは Google のインフラストラクチャによって発生していないと結論付けることができます。この時点で、お客様はコードに集中できるようになります。

拡張するためのヒント

アプリケーションにコードの実行を表すより細かいスパンを生成させたい場合でも、アプリケーションをインストルメント化する必要があります。開発言語と一致するライブラリの選択とコードをインストルメント化する手順の確認を、こちらから開始できます。この手順が完了すると、トレースによりより多くのスパンが網羅されるとともに、インフラストラクチャとアプリケーション双方のパフォーマンスの情報が 1 つのウォーターフォールビューにまとめられ、トレースに含まれる情報が豊かになります。

Cloud Trace – インフラストラクチャトレース向け Google Cloud のハブ

Google Cloud のテレメトリーの未来に期待が高まっています。今後 6 か月以内に、インフラストラクチャのインストルメンテーションと、トレース分析、指標、他の Google Cloud プロダクトへの統合、サードパーティの APM プロダクトとの統合などの分野に関するリリースを予定しています。

次のステップ

インフラストラクチャからのトレースを Cloud Trace コンソールで詳しく学び、アプリケーションのインストルメンテーションに使用できるライブラリと手順を理解します。今回ご紹介した新機能について、ご不明な点やフィードバックがございましたら、Cloud Operations コミュニティページからお問い合わせください。

-Google Cloud プロダクトマネージャー Eyamba Ita

Cloud Logging のモニタリングデータによる GKE アプリのトラブルシューティング迅速化

Fri, 27 Aug 2021 01:00:00 +0000

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

Google Kubernetes Engine（GKE）上のアプリケーションのトラブルシューティングでは、問題に関するコンテキストが多ければ多いほど、問題をより迅速に解決できます。たとえば、Pod がメモリ割り当ての上限を超えたか？ストレージボリュームの予約に権限エラーがあったか？アプリ内の不正な正規表現によって CPU が過度に消費されたか？こうした問いに答えるには、開発者と運用担当者による多くのトラブルシューティングコンテキスト構築が必要です。

Cloud Logging の GKE 向け Cloud Monitoring データ

GKE アプリのトラブルシューティングを簡易化するために、Cloud Logging から直接アクセス可能なコンテキストベースの Cloud Monitoring データを追加しました。この新機能により、関連する Pod、ノード、クラスタのイベント、指標、アラート、SLO をログ行自体から簡単に確認できます。さらに、特定のログエントリに読み込まれるデータは、Kubernetes リソースをスコープとするため、アプリのエラーを調査する際の貴重な時間を節約できます。

本日の発表内容は、各 GKE リソースの詳細ページにログのタブが追加されたことや、Monitoring の GKE ダッシュボードに指標とログが統合されたことなど、最近行われた他のインテグレーションをさらに強化するものです。Monitoring、Logging、GKE のどこでトラブルシューティングを始めても、オブザーバビリティデータを手軽に入手できます。

たとえば、Cloud Logging で GKE アプリのエラーをトラブルシューティングし、アプリのログを見ている場合、ログエントリを離れることなく、コンテナの再起動、稼働時間、メモリ、CPU、ストレージの指標グラフを表示できるようになりました。アクティブなアラートはアラートタブでハイライト表示され、トラブルシューティングに役立つコンテキストを提供します。他にはない、この統合エクスペリエンスでは対象アプリを実行している特定の Kubernetes リソースの重要なログや指標データをまとめて表示できます。

ログ行から GKE の Monitoring データを表示する

k8s_container、k8s_pod、k8s_node、k8s_cluster のログから、resource.labels のリソース名を持つブルーチップを選択し、[モニタリングの詳細を表示] を選択すると、Logs Explorer から直接、統合指標パネルにアクセスできます。[GKE で表示] を選択すると、Cloud Console の GKE リソース詳細ビューが新しいタブで開きます。

指標パネルには、GKE リソースに関連するアラート、Kubernetes イベント、指標を含む多くのコンテキストデータが表示されます。

アラート

GKE リソースによってトリガーされたアラートは、[アラート] タブに表示されます。色分けされたアラートのステータスにより、進行中のインシデント、確認済みのインシデント、クローズ済みインシデントを簡単に確認できます。[インシデントを表示] を選択すると、Cloud Monitoring でインシデントの詳細が表示されます。新しいアラートを作成する場合は、リンクを使用してまったく新しいアラートポリシーを作成します。

クラスタと Pod の Kubernetes イベント

指標パネルには、クラスタと Pod のイベントが表示されます。各イベントには、名前、関連するリソース、ログメッセージを表示またはコピーするためのリンクが表示されます。Kubernetes イベントからは、問題の根本原因を特定するために重要な情報が得られます。たとえば、FailedScheduling イベントが表示された場合、トラブルシューティングの流れを Kubernetes リソースが利用可能なリソースの確認へすぐに導くことができます。

コンテナ、Pod、ノードの指標

指標タブには、GKE クラスタから収集され Cloud Monitoring で報告されるコンテナ（デフォルト）、Pod、ノードの指標の指標バンドルが含まれています。各指標バンドルには事前に組み込まれたグラフが用意されており、CPU、メモリ、ストレージ、コンテナの再起動を選択して表示できます。たとえば、CPU やメモリを見ることで、Kubernetes リソースの指標にスパイクがあったかどうかを判断できます。

今後の展開

Google は、Google Cloud のオペレーションスイートを GKE アプリのトラブルシューティングに最適なツールにするために取り組んでいます。GKE アプリのトラブルシューティングを容易にするために、ログを GKE リソースの詳細ページに直接統合し、特化された統合 GKE ダッシュボードを構築しました。さらに、GKE アプリのトラブルシューティングのために、指標パネルにより多くのコンテキストを表示する新しい機能の追加にも取り組んでいます。

使ってみる

GKE での Cloud Logging と Cloud Monitoring の使用をまだ開始していない場合は、ドキュメントとGKE 上のサービスのトラブルシューティングに関する簡単な動画をご覧になり、Google Cloud コミュニティサイトの新しい Cloud Operations ページのディスカッションにご参加ください。

-Google Cloud プロダクトマネージャー Charles Baer

トラブルシューティングやリソース帰属にプロセス指標を使用する

Thu, 26 Aug 2021 06:00:00 +0000

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

アプリケーションやサービスの問題に遭遇したときは、それらの基盤となるインフラストラクチャやソフトウェアに関する詳細な情報を得ることが不可欠です。大部分のモニタリングサービスが提供する分析情報は仮想マシン（VM）レベルのものであり、それより細かいレベルの情報が得られるサービスはほとんどありません。アプリケーションやサービスの状態の全体像を把握するには、インフラストラクチャでどのプロセスが実行されているかを知る必要があります。新しい Ops エージェントは、VM で実行されているプロセスを複雑な設定なしに可視化するもので、Cloud Monitoring でデフォルトで使用可能になっています。本日は、プロセス指標にアクセスする方法と、それらのモニタリングを開始すべき理由を取り上げます。

プロセス指標の可視性の向上

プロセス指標によって収集されるデータには、VM で実行されているすべてのプロセスやサービスの CPU、メモリ、I/O、スレッド数、その他が含まれます。Ops エージェントまたは Cloud Monitoring エージェントがインストールされている場合、これらの指標が 60 秒間隔で取得されて Cloud Monitoring に送信されるので、これらを可視化、分析、追跡し、アラートを発生させることができます。1 つの VM で実行されているプロセスの数は数十から数百程度ですが、VM フリート全体で見るとその数は数万に達する場合があります。

開発者は、メモリリークやパフォーマンスの問題が生じたとき、普通は 1 つの VM の内部だけを見てそのトラブルシューティングや原因の特定を行います。

それに対して、オペレーターや IT 管理者はリソース消費の集計値に関心を持ち、VM フリート全体のコンピューティング、ストレージ、ネットワークの使用状況に関するベースラインビューを構築します。その後、それらのベースライン消費レベルが通常の動作で見られる水準を逸脱した場合には、システムを調査する時期が来たと判断します。

スケーリングと使いやすさを念頭に置いた仕様

Cloud Monitoring は、Google 全体の指標を支えているのと同じ高度なバックエンドを基に構築されています。この実証されたスケーラビリティにより、カーディナリティがどれだけ高くても、指標の取り込みが確実にサポートされます。さらに、Google のエージェントでプロセス指標のモニタリングを有効にするために構成ファイルを変更する必要はありません。

最後に、Google の目標は、オブザーバビリティとテレメトリーに関するデータを必要なときに必要な場所でお客様に提供することです。そのため、他のオペレーションスイートのツールと同様に、インフラストラクチャのコンテキストでのプロセス指標を VM 管理コンソールで直接提供しています。

GCE で単一の VM のコンテキスト内プロセスモニタリングに移動する

ナビゲーションは簡単です。Ops エージェントまたは Cloud Monitoring エージェントを VM にインストールした後、以下の手順を行います。

Compute Engine コンソールページに移動し、[VM インスタンス] をクリックします。
調査する VM を選択します。
上部のナビゲーションメニューで [オブザーバビリティ] をクリックします。
[指標] をクリックします。
最後に [プロセス] をクリックします。

右側のウィンドウに、VM で実行されているすべてのプロセスを含むグラフと表が表示されます。データを時間枠でフィルタし、名前や値で並べ替えることもできます。プロセスを検出して表示するために必要なことは、エージェントをインストールすることだけです。

フリート全体での指標のモニタリング

Cloud Monitoring によって提供される VM フリート全体の一元的なビューにより、リソースの使用量をプロセス別に集計して割り出すことができます。このレベルの広範かつきめ細かい情報があれば、どのソフトウェアを実行するか、アプリやサービスを最適にサポートするために VM がいくつ必要かといった決断を容易に下せるようになります。管理者は、特定のプロセスが原因で多数の VM のパフォーマンスが低下しているかどうかを調べる場合、多大なコストをかけずに分析を実施できます。また、比較的性能の低い VM が多数動作している環境を、より性能の高い少数の VM に置き換えることもできます。

このフリート全体のビューを表示するには、以下の手順を行います。

[Monitoring] に移動します。
左メニューで [ダッシュボード] をクリックします。
[すべてダッシュボード] リストで [VM Instances] をクリックします。
ウィンドウの上部にある [PROCESSES] をクリックします。

これで、VM フリート全体で実行されているプロセスの詳細を示す多くのグラフが表示されます。

Cloud Monitoring の VM インスタンスダッシュボードに新しく組み込まれた VM フリート全体のプロセスビュー

使ってみる

プロセス指標の識別とモニタリングを開始するには、まず Ops エージェントをインストールするか、すでにレガシー Cloud Monitoring エージェントがインストールされている必要があります。これが完了したら、プロセス指標データが自動的に Cloud Monitoring と VM 管理コンソールに取り込まれます。

不明な点がある場合や、他の開発者、オペレーター、DevOps、SRE との会話に参加したい場合は、Google Cloud コミュニティの Cloud Operations ページをご覧ください。

-プロダクトマネージャー Rahul Harpalani

GKE のサービスの可用性を確認できる、新しい専用の稼働時間チェック

Wed, 25 Aug 2021 08:00:00 +0000

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

アプリケーションの開発においては、エンドユーザーエクスペリエンスを考慮することが重要です。オブザーバビリティツールを使用することで、稼働時間などユーザーにとって重要なパフォーマンス指標を測定できます。一般的には、稼働時間を示す指標やログを用いてサービスを内部的に測定することが推奨されていますが、利用できるのであれば外部のシグナルも非常に役立ちます。

サービスを外部から測定するための最も簡単な方法の一つに、稼働時間チェックの使用が挙げられます。稼働時間チェックは、確立された信頼性の高いテクノロジーであり、サービスの可用性を詳細にモニタリングし、問題の先行指標として役立ちます。これにより、問題がユーザーに影響を及ぼす時間の短縮または排除に効果が見込めます。

GKE サービス用の稼働時間チェック

マイクロサービスアーキテクチャの急増によって、サービスが増えれば測定対象となるエンドポイントの数も増加します。問題の追跡、特定、解決は、複雑化の一途をたどる可能性があります。そこで、このたびリリースされた Google Kubernetes Engine（GKE）LoadBalancer Service 用の新しい稼働時間チェックをご紹介します。

Google Cloud は、これまでもさまざまなタイプのリソースを対象とした稼働時間チェックを提供してきましたが、GKE に直接関連するものはありませんでした。新しく統合されたこの GKE LoadBalancer の稼働時間チェックでは、サービスロードバランサと稼働時間チェックを直接関連付け、動的に稼働時間チェックが管理されるようになっています。サービスの基盤となるネットワークの変更に合わせて稼働時間チェックも変更されるため、サービスと稼働時間の障害をすばやく相関させることができます。

また、稼働時間チェックに基づいてアラートポリシーを設定することもできるため、サービスに影響を与えている重要な問題について、SRE チームや運用チームに通知できます。通知を受けた後は、関連する GKE ダッシュボードに直接アクセスして、根本原因をより正確に特定することが可能になります。

新しい稼働時間チェックの作成

作成を開始するには、[Monitoring] > [稼働時間チェック]、続けて [+ 稼働時間チェックの作成] を選び、新しい [Kubernetes Loadbalancer Service] オプションを選択します。

詳細情報

初めて稼働時間チェックを作成するための詳細情報や設定手順を確認するには、稼働時間チェックの管理に関するドキュメントをご覧ください。

また、今回ご紹介した新機能について、ご不明な点やフィードバックがございましたら、Cloud Operations コミュニティページにアクセスしてご連絡ください。

-Cloud Ops プロダクトマネージャー Roy Nuriel
-Cloud Ops プロダクトマネージャー Kyle Benson

VM のモニタリングとトラブルシューティングを「コンテキスト内」で行い、問題を迅速に解決

Wed, 25 Aug 2021 07:00:00 +0000

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

本番環境の仮想マシン（VM）で問題が発生した場合、そのトラブルシューティングは複雑になりがちであり、多くの場合、インフラストラクチャ、アプリケーション指標、未加工のログなど、複数のデータポイントやシグナルを関連付けることが必要になります。さらに、エンドユーザーがレイテンシ、ダウンタイム、エラーなどの問題に直面し、デベロッパーがその問題の根本原因を分析する場合、さまざまなツールや UI などを切り替えなくてはならず、分析作業が遅れてしまうこともあります。必要なデータへのアクセス、修正のデプロイ、修正の検証など、各作業の時間を短縮することで、組織はコストを削減し、ユーザーからの信頼を維持できます。

本日は、Compute Engineの UI ベースのツールである「コンテキスト内」セットの一般提供を発表いたします。この強化されたセットを使用することで、Compute Engine のユーザーはトラブルシューティングをより簡単かつ直感的に行えるようになります。デベロッパーは、Google Console から任意の VM をクリックして、事前構築済みの豊富な可視化機能にアクセスできます。この機能により、CPU、ディスク、メモリ、ネットワーク、ライブプロセスに関連する一般的なシナリオや問題を分析できます。これらすべてのデータに 1 つのロケーションからアクセスできるため、一定の期間内のシグナルを簡単に関連付けることができます。

より多くの運用データを VM に取り込む

上位レベルの指標のコレクションは Compute Engine コンソールのページでいつでも利用できます。しかし、お客様のフィードバックにより、それでも各種ツール間を移動しないと根本原因を適切に分析できないことがわかりました。たとえば、CPU 使用率が特定の時間帯にピークを迎えていることを確認するのは足がかりになるかもしれませんが、使用率を押し上げている原因は何であるかをもっと深く分析しないと問題の解決には至りません。さらに、このデータをプロセスや、入出力の待機時間、ユーザー空間、カーネル空間などのシグナルと関連付ける必要があります。

このことを念頭に置いて、Google は Compute Engine ページにさまざまな指標、チャート、可視化機能を新たに追加しました。これらのほとんどは設定に時間が一切かかりません。新しく追加された一部の機能には、Google Cloud の Ops エージェント（または現在使用している従来のエージェント）から提供される詳細な指標が入力されます。Ops エージェントは、Terraform、Puppet、Ansible、インストールスクリプトを使用して簡単にインストールできます。

VM をクリックすると、オブザーバビリティデータの一部が表示される

Ops エージェントの指標を利用する新しいチャートには、OS から報告される CPU 使用率、メモリ使用率、ユーザー別のメモリ内訳、カーネル、ディスクキャッシュ、I/O レイテンシ、ディスク使用率、キューの長さ、プロセス指標などが含まれます。

VM をクリックすると、詳細なデータが表示される（指標とログを含む）

あらゆるニーズにたった一つで対応できるようなトラブルシューティングはありませんが、この強化されたオブザーバビリティツールのセットを使用することで、以下のシナリオをより迅速かつ直感的に実行できます。

指標とログでネットワークの変化を特定する。ネットワークトラフィック内の予期しない増加、ネットワークのパケットサイズ、新規ネットワーク接続の急増を重要度別にログと比較することで、デベロッパーはトラフィックの増加と重大なログエラーの関連性を特定できます。さらにツールのログのセクションに移動すると、重要なログだけをすばやくフィルタし、ログメッセージのサンプルを開いて、タイムアウトメッセージや負荷の増加によるエラーに関する詳細なログを確認できます。また、対象の VM のみにフィルタしたログエクスプローラへのディープリンクによって、Compute Engine と Cloud Logging の間を迅速かつシームレスに移動できます。
使用率に影響を与えるプロセスを特定する: CPU やメモリの使用率が高い時間と上位のプロセスを比較することで、オペレーターはどのプロセスがリソースを大幅に消費しているかを特定できます（プロセスはコマンドラインまたは PID で表示）。特定したプロセスは、完全にリファクタリングまたは停止するか、コンピューティングやメモリの要件により適したマシンで実行するという方法で対処できます。その他にも、継続時間が短いプロセスが数多く存在する場合があります。そういったプロセスは、プロセススナップショットには表示されませんが、プロセス作成レートのチャートにはレートの急増という形で示されます。そのため、プロセス作成レートのチャートを確認することで、リファクタリングを行いプロセス継続時間をより効率的に分配するという判断を行えるようになります。
ワークロードに適したディスクサイズを選択する: 「1 秒あたりの IOPS のピーク値」が横ばいになり始めていることにデベロッパーが気付くことがあります。これはディスクがパフォーマンスの上限に達しつつあるサインです。また、「I/O レイテンシの平均」が増加している場合、I/O スロットリングが発生している可能性があります。最終的に、ストレージタイプ別に IOPS のピーク値を分析すると、ほとんどの IOPS ピークが Persistent Disk SSD で発生していることがわかるかもしれません。こうした分析により、ディスクのサイズを増やし、ブロックストレージのパフォーマンス上限を引き上げるという判断を行えるようになります。
セキュリティ運用とデータ主権: オペレーターは業務の一環として、外部データアクセスに対してセキュリティプロトコルを適用したり、特定のリージョンにデータを保存してプライバシーや規制に遵守するために技術的なアーキテクチャを作成したりすることがあります。オペレーターは、ネットワークサマリーを使用して、VM で接続が確立され、主に同一のプロジェクト内の VM および Google サービスにトラフィックが送信されているか、接続および上り / 下り（内向き / 外向き）のトラフィックが外部で発生している可能性があるかどうかを一目で判断できます。同様に、新しい接続が確立されているか、もしくはトラフィックが異なるリージョンやゾーンに送信されているかも判断できます。これにより、リージョン間のデータ転送をブロックする新しいプロトコルを作成するという判断もできます。
ネットワークの変更によりコストを最適化する: デベロッパーは、VM 間のトラフィックの大部分が同じリージョン内のトラフィックではなくリージョン間で送信されていることに気がつくかもしれません。このリージョン間のトラフィックは低速で、リージョン間のレートに基づいて課金されるため、デベロッパーは VM を再構成し、代わりに同じリージョン内の必要なデータのローカルレプリカと通信する方法を選択できます。これにより、レイテンシとコストの両方を抑えられます。
メモリのパフォーマンスを測定、調整する: メモリ使用率のデータを集めるために、ほとんどの VM ファミリーで Ops エージェントが必要とされます。上位のプロセスを対象にメモリ使用量を調査することで、デベロッパーはメモリリークを検出して、問題のあるプロセスを再構成または終了できます。さらに、メモリ使用量のタイプ別の内訳を調査すると、ディスクキャッシュ使用量がアプリケーションで使用されていないメモリ領域の使用量の上限に達しており、それがディスクレイテンシの増加と関連していることに気付くことがあるかもしれません。これにより、オペレーターはメモリ最適化 VM にアップサイズすることを選択でき、アプリケーションとディスクキャッシュの両方で十分なメモリを使用できます。

ここで紹介したものは、お客様のチームが新機能を活用できるユースケースのほんの一例です。これらを活用することで、トラブルシューティングにかかる時間を短縮し、コストを最適化して、Compute Engine の全体的なエクスペリエンスを向上できます。

使ってみる

開始するには、[Compute Engine] > [VM インスタンス] の順に移動し、対象の VM をクリックしてから [オブザーバビリティ] タブに移動します。これらのツールを使用して VM パフォーマンスに関する問題のトラブルシューティングを行う方法の詳細については、デベロッパー向けドキュメントで確認できます。また、新しいツールを最大限に活用するために Compute Engine VM にOps エージェントをインストールすることをおすすめします。何かご不明な点やフィードバックがございましたら、Google Cloud コミュニティの Cloud Operations ページのディスカッションにご参加ください。

-シニアプロダクトマネージャー Haskell Garon

-ソフトウェアエンジニア Dave Raffensberger

Cloud Logging の新しいヒストグラム機能でトラブルシューティングの時間を短縮

Thu, 19 Aug 2021 04:00:00 +0000

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

アプリケーションに関する問題をトラブルシューティングする際は、ログの傾向を可視化することが重要です。[ログエクスプローラ] のヒストグラムを使用すると、ログボリュームの推移をすばやく可視化することで、異常の発見、エラー発生の検出、ログボリュームの詳細確認ができます。ただ、静的な可視化は有用ですが、調査で多くのカスタマイズオプションが使えればさらに便利です。

そこで先日、ログの重大度ごとの色分けと 3 種類の新しいクエリコントロールをヒストグラムに追加しました。こうした新機能により、期間単位のログの絞り込みと分析がさらに簡単になります。新しいヒストグラムコントロールでは、現在の期間の前後のログ検索、ヒストグラムバーに表示される特定の期間へのジャンプ、ヒストグラムの現在の表示対象期間のズームインやズームアウトが有効になります。

ヒストグラムの色分け

ヒストグラムには色分けが導入され、重大度ごとにログの詳細を簡単に表示できるようになりました。たとえば、重大度の色を利用すると、リクエストの量が比較的一定の場合でも、増加しているエラーを見つけやすくなります。以下のヒストグラムを見ると、赤と青の色分けにより、ログボリューム全体が増加していることが明らかで、そのログボリューム内のエラーの詳細が可視化されます。

ヒストグラムのログの新しい色分けのスクリーンショット

左右に移動して時間をスクロールする

トラブルシューティングの過程で、現在のログセットの直前や直後のログを確認したい場合があります。期間の開始時にエラーが予想外に急増し、現行期間の直前の期間内のログを確認する必要があるかもしれません。ヒストグラムの左側にある左矢印を押すと、期間が前にスライドし、ヒストグラムの右側にある矢印を押すと、期間が後にスライドします。いずれの場合もクエリの期間が変更され、クエリの再実行により新しい期間のログが返されます。

ヒストグラムで左右にスクロールして、表示されている期間を調整する例

ズームインとズームアウト

特定の期間からズームインやズームアウトを行うと、きめ細かい詳細や幅広い傾向を可視化する場合に便利です。ヒストグラムの右上隅にあるズームインまたはズームアウトアイコンをクリックすると、クエリの期間が絞り込まれ、クエリが再実行されて、新たに定めた期間のログが返されます。

ヒストグラムの期間を調整できるズームインおよびズームアウト機能

特定の時間までスクロールする

ヒストグラムでログボリュームに大規模な急増が見られる場合は、その急増中に生成されたログをすばやく確認すると便利です。急増が含まれるヒストグラムバーをクリックすると、その期間中に生成されたログにスクロールされます。

ヒストグラムバーをクリックして、ログ表示をフィルタリング

ヒストグラムの表示方法

ヒストグラムはログエクスプローラのパネルの一つで、[ページレイアウト] メニューのコントロールを使用して表示または非表示にできます。ヒストグラムを表示しない場合は、右上隅の「X」ボタンをクリックするとすぐに閉じられます。もう一度開くには、[ページレイアウト] メニューを使用してヒストグラム表示を有効にします。

[ログエクスプローラ] の [ページレイアウト] メニューでヒストグラムを有効にする場所

ヒストグラムを使ってみる

上記の改良により、ヒストグラムは可視化のためのユーティリティからトラブルシューティングの過程に欠かせない要素になりました。引き続き、Cloud Logging を Google Cloud ログのトラブルシューティングに最適な環境にする新機能のリリースに取り組んでまいります。Cloud Logging をまだご利用でない場合は、こちらのスタートガイドをご確認ください。また、Google Kubernetes Engine（GKE）でのサービスのトラブルシューティングに関する短い動画も併せてご覧ください。何かご不明な点やフィードバックがございましたら、Google Cloud コミュニティの Cloud Operations ページのディスカッションにご参加ください。

-Google Cloud プロダクトマネージャー Charles Baer

クラウド オペレーション

柔軟な確約利用割引 - Compute Engine インスタンスを割引するシンプルで新しい方法

フレキシブル CUD に関するお客様の声

フレキシブル CUD の理解

今すぐフレキシブル CUD を始める

App Engine および Cloud Functions の Java 17、Ruby 3、Python 3.10、PHP 8.1 の一般提供 / プレビュー版提供を開始

Java

Ruby

Python

PHP

実際に試してみましょう

新しい Cloud Functions（第 2 世代）でイベント ドリブン アーキテクチャを強化

Google の Vertex AI Vizier を使用したアプリケーションの最適化

パフォーマンスの最適化

問題は何ですか？

最適化問題のフレーミング

目標

パラメータ空間

アプローチ

調査結果

手法に関する学習

まとめと次のステップ

参照

Cloud Monitoring と Cloud Run を使用したカスタム通知の作成

目標

費用

はじめに

Google Chat との統合

Cloud Run のコードを見る

アプリのデプロイ

GitHub リポジトリを設定する

Google Chat 統合をデプロイする

webhook URL の設定

ハードコードされた Webhook URL

手動 GCS バケット Webhook URL

手動でのデプロイ

継続的デプロイのセットアップ

クリーンアップ

プロジェクトの削除

チュートリアル リソースの削除

他のサードパーティ サービスへの拡張

ハイブリッド クラウドのログで優れた分析情報の獲得とトラブルシューティングを行うための 2 つのパターン

お客様の運用の改善

パターン 1: Cloud Logging でリソース管理とトラブルシューティングを実現

パターン 2: ハイブリッド クラウドやマルチクラウドでログ分析に BigQuery を使用するシナリオ

最後に

使ってみる

Webhook や Pub/Sub、Slack のアラート通知チャネルを提供開始

Webhook や Pub/Sub、Slack の通知を構成するには

次のステップ

Ansible を使用して Google Cloud Ops エージェントをデプロイする方法

Ansible の概要と仕組み

Ops エージェントをデプロイして VM のモニタリングとトラブルシューティングを行う

ワークロードの詳細を構成に追加する

使ってみる

OpenTelemetry を基盤とする Ops エージェントの一般提供を開始

Sabre 社によるデジタル トランスフォーメーションを成功に導く SRE の活用方法

1. 文化の刷新と SRE の導入に賛同し、熱意を注げる同僚を見つける

2. 中間管理職のステークホルダーを巻き込む

3. 思い切って専門家の助けを借りる

SRE のベスト プラクティスを実現: Cloud Logging における新たなコンテクストのトレース

ログとトレースを使った知見と相互関係の高速化

Google Cloud サービスでのトレースの生成方法

使ってみる

OpenTelemetry Trace 1.0 が利用可能に

Managed Service for Prometheus で世界規模のモニタリングを実現

現在プレビュー版の Google Cloud Managed Service for Prometheus に関する詳細

オープンソース インターフェースを備えた使いやすいサービス

お客様によるプレビュー版導入成功事例

ご利用方法

Google Cloud Monitoring の基本: 指標の種類について

指標のタイプ

指標の収集

有料の指標と無料の指標

まとめ

Cloud Logging のモニタリング データによる GKE アプリのトラブルシューティング迅速化

GKE ワークロード指標による Kubernetes アプリケーションのより的確なモニタリング

GKE ワークロード指標（現在プレビュー版）について

ご利用方法

料金

クラウドオペレーション

新しい Cloud Functions（第 2 世代）でイベントドリブンアーキテクチャを強化

チュートリアルリソースの削除

他のサードパーティサービスへの拡張

ハイブリッドクラウドのログで優れた分析情報の獲得とトラブルシューティングを行うための 2 つのパターン

パターン 2: ハイブリッドクラウドやマルチクラウドでログ分析に BigQuery を使用するシナリオ

Sabre 社によるデジタルトランスフォーメーションを成功に導く SRE の活用方法

SRE のベストプラクティスを実現: Cloud Logging における新たなコンテクストのトレース

オープンソースインターフェースを備えた使いやすいサービス

Cloud Logging のモニタリングデータによる GKE アプリのトラブルシューティング迅速化

Cloud Logging のモニタリングデータによる GKE アプリのトラブルシューティング迅速化

一般的なサーバーレスサービス向けの手間いらずのパフォーマンス分析情報

レイテンシシグナルとしてトレースを使用する

Cloud Trace – インフラストラクチャトレース向け Google Cloud のハブ

Cloud Logging のモニタリングデータによる GKE アプリのトラブルシューティング迅速化