メンテナンス
システムを安定運用させるためには、現状のシステム状態を素早く正しく把握し、適切なアクションにつなげるための監視プロセスが必要不可欠です。Google Cloud では安定したシステム運用をサポートするための監視ソリューションがいくつか提供されています。これらを適切に選択し、各ワークロードに適したサービスレベルを維持することが重要となります。
最初に、システムを安定運用させるために、監視対象を何にすべきか特定することが重要です。
近年、監視対象の整理にあたって、 SLO ( Service Level Objective ) を用いた監視設計が注目されています。ここで SLO の詳細については述べませんが、SLO を重視する理由は、サービスレベルを定義しないと、お客様がサービスを快適に利用できているかを測定することが困難であるためです。サービスを改善できることがわかっていても、サービスレベルを定義していないと、改善のために何にいくら投資するかを決定することは難しくなります。 ( SLO についての詳細は参考資料や、SRE ブックをご覧ください)
また、SLO を満たすか否かを決めるために指標が必要となりますが、それを SLI ( Service Level Indicator ) と呼びます。SLI はワークロードのサービス特性等によって測定すべき指標が異なることが多いですが、代表的なパターンを以下記載します。
デザイン パターン詳細
監視 パターン
解決する課題・使い所
単に監視といっても、ドメインデータを基にビジネス部門で行う監視、システム稼働データを基にシステム部門で行う監視など、その主体によって意味合いが異なりますが、今回はシステム部門の方向けの監視について述べます。
また、システム部門の方が行う監視についても、システムインフラの状態を把握するためのリソース監視やログ監視、アプリケーションの状態を把握するためのエラー監視やパフォーマンス監視など様々な対応要素が含まれます。本項では、 Google Cloud の監視ソリューションとして、これらインフラ、アプリケーションの監視をサポートする Google Cloud のオペレーション スイート (旧称 Stackdriver )について述べます。これらのソリューションで以下のポイントを解決することができます。
インフラの監視
リソース使用率 / サーバ死活状態などの監視
インフラの状態を正しく把握するために、リソース使用率、サーバ死活監視などを行う必要があります。稼働状況を自動的にモニタリングし、状況に応じた通知などアクションを行うことを可能とします。ログ監視
ログ監視もシステム監視において欠かせない要素です。システムから取得されるログデータとイベントを保存、検索、分析、モニタリング、通知することを可能とします。
アプリケーションの監視
エラー モニタリング
アプリケーションで発生しているエラーを集計、可視化し、効率的な分析を可能とします。デバッグ
アプリケーションの停止や実行速度の低下を招くことなく、実行中のアプリケーションの状態を調査、分析してデバッグすることを可能とします。トレーシング
アプリケーション内でやり取りされるリクエストをトラックし、ほぼリアルタイムでパフォーマンスの分析情報を提供することを可能とします。プロファイリング
アプリケーション全体で実行される CPU 集約型またはメモリ集約型の関数のパフォーマンスを継続的に分析して、パフォーマンス劣化の原因を特定することを可能とします。
アーキテクチャ
ここでは、インフラ、アプリケーションを監視するための Google Cloud のオペレーションを用いたアーキテクチャについて述べます。Google Cloud のオペレーション スイートには高度な監視機能、複数環境の統合的な管理機能および、 PagerDuty など他のサービスとの連携機能を持つ、といった特徴があります。
以下、インフラの監視、アプリケーションの監視それぞれのリファレンスアーキテクチャを示します。
※監視パターンは、監視対象や監視が必要な指標など、どのような監視シナリオを実現したいかによって、ほぼ無限にパターンを表現できるため、ここでは様々なシナリオを実現するにあたり役立つ、各ソリューションの機能の説明にフォーカスします。 サンプルシナリオに沿った各機能の利用イメージは、後述する Sample Config セクションにて、いくつかの例を紹介させて頂きます。
インフラの監視
全体的なイメージ
監視対象の仮想マシンに対する、リソース使用量 / カスタム指標値の監視を Cloud Monitoring で行い、ログ監視を Cloud Logging で行います。Cloud Loggingについては、外部ストレージサービス ( BigQuery や Cloud Storage )にログをエスクポートし、ログを長期的に保存したり、 BI ツール ( データポータル など ) を用いたログ分析を行うこともできます。Cloud Monitoring
Cloud Monitoring を利用することで、各種インフラ指標値の収集、可視化 / 分析、通知設定が行えます。エージェントをデプロイすることで、一部サードパーティ プロダクトの監視等も可能となります。
可視化 / 分析のための UI や、フィルタリング / 集計機能を利用できます。また、グループ監視機能を使用して個々のリソースではなく、特定の条件に一致する、一連のリソースの動作を監視できます。
監視した内容が特定の条件を満たしている場合の通知機能も利用可能です。
複数の Google Cloud プロジェクトの時系列データを 1 か所で表示および管理する場合、ワークスペースを新しい空の監視用 Google Cloud プロジェクトでホストすることをおすすめします。
Cloud Logging
Cloud Logging を利用することで、各種システムのログの収集、可視化 / 分析、通知設定が行えます。Logging エージェントを利用してログを収集します。また、監査ログを含むすべてのログが Cloud Logging API に送信され、ログルーターという要素を通過しますが、ログルーターは、各ログエントリをルールと照合して、破棄するログエントリ、 Cloud Logging で取り込むログエントリ、ログシンクを使用して所定の宛先にルーティングするログエントリを決定します。コスト削減目的など要件に応じてログの除外設定をすることも可能です。
可視化 / 分析のための UI ( 2020 年 10 月現在、 コンソール上でのログの表示方法には ログビューア( 従来版 )とログビューア ( プレビュー版 )が存在します ) や、クエリ言語が用意されています。
監査ログ機能
Google Cloud のプロジェクト、フォルダ、組織ごとに管理アクティビティ、データアクセス、システム イベントの 3 つの監査ログを取得し「誰がどこでいつ何をしたか」を把握できます。システム イベント監査ログ、管理アクティビティ監査ログは常に有効化されますが、データアクセス監査ログは、サイズが非常に大きくなる可能性があり、多くのプロダクトでデフォルトで無効化されているため、必要な場合ユーザが有効化する必要があります。
監査ログを永続的に管理する必要がある場合、 Cloud Storage へエクスポートし、 Cloud Storage の保持ポリシー、保持ポリシーのロック機能を利用して長期間安全にログを管理することもできます。
また、法的 / 規制上の義務等の都合上、ユーザの組織内のメンバーが行ったアクションのみでなく、 Google のサポートエンジニアがメンテナンス等で行ったアクションに関する証跡を残す必要がある場合は、アクセスの透明性ログを利用します。 その他、監査ログに関するベストプラクティスはこちらをご覧ください。
アプリケーションの監視
全体的なイメージ
監視対象の仮想マシンに対する、 CPU やメモリの使用状況といったプロファイル情報の監視を Cloud Profiler で、パフォーマンスに関連するトレース情報の監視を Cloud Trace で、システムエラー情報の監視を Error Reporting で、必要に応じたアプリケーションのデバッグを Cloud デバッガで行います。アプリケーションの動作状況を深く把握できるため、これらソリューションで得た情報をもとに問題分析を効率的に進めることができます。Error Reporting
Error Reporting を利用することで、システムエラー発生状況の把握、可視化、解析が行えます。データを Error Reporting に取り込む手順は、アプリケーションのプラットフォームによって異なります。
可視化/分析のための UI を利用して、発生期間、発生回数、テキスト マッチングにて発生したエラーのフィルタリングが可能です。また、既知のエラーや頻発する重要度の低いエラーをミュート設定して、エラー解析効率をあげることもできます。( なお、根本原因が同じであると考えられるエラーがグループ化されるため、効率的にエラーを確認できます )
新しいエラーの発生時や、解決済みのエラーが再発した場合に通知するように Error Reporting を設定できます。 また、Error Reporting では 1,000 回分の発生情報のみがサンプルとして保持されるため、あるエラーを発生するたびに保持するには、ログを BigQuery にエクスポートを検討ください。
Cloud Trace
Cloud Trace を利用することで、システムパフォーマンスの把握、可視化、解析が行えます。データを Cloud Trace に取り込む手順は、アプリケーションのプラットフォームによって異なります。
可視化 / 分析のための UI を利用して、エージェントが収集したトレースデータを、 Cloud Trace インターフェースに表示して分析できます。
Cloud Monitoring との統合により、1 か月あたりの Cloud Trace 取り込みスパン数、割り当て使用量、スパン取り込み率などに基づくアラートポリシーを作成できます。
その他、複数の Google Cloud プロジェクトでホストされているアプリケーションが生成したトレース情報を、1 つの Google Cloud プロジェクトで表示することもできます。
Cloud デバッガ
Cloud デバッガを利用することで、アプリケーションの停止や実行速度の低下を招くことなく、実行中のアプリケーションの状態をリアルタイムで調査できます。利用する言語ごとにクライアント ライブラリ等を利用してデバッガの設定を行います。
スナップショット機能を利用して、アプリのソースコード内の特定の行位置でローカル変数とコールスタックを収集します。また、スナップショットの URL をコピーし、プロジェクトにアクセスできる他のユーザーに送ることで、プロジェクトの他のメンバーとスナップショットを共有することもできます。
ログポイント機能を利用して、サービスを再起動したりサービスの通常の機能を妨げたりせずに、実行中のサービスにロギングを挿入することもできます。
センシティブ データの非表示機能を利用して、デバッガによる、メールアドレス、アカウント番号など、アプリケーション内のセンシティブ データの露出を制御できます。 ( 本機能は 2020 年 10 月現在アルファ版として提供しています)
Cloud Profiler
Cloud Profiler を利用することで、アプリケーションの詳細なパフォーマンス解析を行えます。プロファイラ エージェントを利用してパフォーマンス データを収集します。
可視化 / 分析のための UI を利用して、各種フィルタ機能を用いた分析や、解析結果のダウンロードを行いメンバ間で共有することも可能です。
プロファイルの比較機能を利用して、プロジェクト内の同じサービスから取得した 2 つのプロファイルを視覚的に比較し、時期、サービスのバージョン、デプロイしているゾーンの違いなどによるパフォーマンス差分を確認できます。
利点
ここまでに記載した Google Cloud のオペレーションの機能を利用することで、システムのインフラ面、アプリケーション面の監視を効率化できます。Google Cloud のオペレーションはオンプレにて従来利用されてきた、運用監視ツールの単純代替ではなく、クラウドネイティブなシステム設計を前提とする監視ツールですが、従来の監視設計を基軸としつつ、Google Cloud のオペレーションを利用して、冒頭記載した SLO をベースとした監視設計の考え方を新たに取り入れることで、開発チーム / 運用チーム間の連携をよりスムーズにすることができます。
注意事項
Google Cloud のオペレーション各機能で収集した監視情報は、デフォルト設定の場合、保存期限があります。恒久的に監視情報を保存する必要がある場合は、各サービスに用意されているログエクスポート機能を利用する必要があります。また、Google Cloud のオペレーションの SLA の適用範囲は、 2020 年 10 月時点で限定されていため、利用の際にはご留意ください。
サンプル コンフィグ
オペレーション スイートの利用シーンは多岐にわたり、その全てを記載することが難しいため、ここでは最も基本的な使用ケースの一つである、 ( 1 ) 死活監視設定および、( 2 ) Cloud Monitoring 指標を用いたワーカーインスタンスのオートスケール設定、を例に Sample Config を記載します。その他、利用ケースごとの設定については、 ウェブ上に多数ある Google Cloud 公式ドキュメントを参照ください。
タイトル: チェックの意味を把握できる名称を指定
プロトコル: 死活監視に利用するプロトコルを指定
リソースタイプ: リソースの種類を指定
チェックの頻度: 要件に応じてチェック頻度を指定
レスポンスのタイムアウト:1 〜 60 秒の範囲から任意の値を指定
チェックの失敗をログする: オン (稼働時間チェック内容を Cloud Logging に送付するかしないかの指定)
通知チャネル: 死活監視失敗時の通知先チャネルを指定
Cloud Monitoring 指標を用いたワーカー インスタンスのオートスケール設定
この設定は主に、Dynamic site hosting パターンで説明したマネージド インスタンスグループにて設定を行います。指標タイプ:Stackdriver Monitoring の指標
指標 ID:使用する Cloud Monitoring 指標の ID (インスタンスの CPU 使用率、メモリ使用率など)
使用率のターゲットのタイプ:インスタンスから収集したデータをオートスケーラーがどのように計算するか ( 要件に応じて GAUGE 、 DELTA_PER_MINUTE 、 DELTA_PER_SECOND から選択)
その他オペレーションのユースケースが記載されたページのリンクを参考文献に記載するので、ぜひご確認頂きイメージを深めてください。
このパターンで作成された事例
株式会社エウレカの導入事例:Stackdriver Logging でのログ監視や、BigQuery を駆使した分析・活用などにより、SLO 99.95% を達成
株式会社マイナビ:大学生向けキャリア支援メディアを Google Cloud でリプレイス。拡張性・可用性・利便性の向上実現
フォスター電機株式会社:SAP ERP を 4 か月で Google Cloud に移行、業務アプリのレスポンスとランニングコスト大幅改善
関係するデザインパターン
参照ドキュメント