クラウドオペレーション

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

2022年1月26日

Google Cloud Japan Team

※この投稿は米国時間 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 には大量のログがあるため、問題のトラブルシューティングを行うには、スケーリングと取り込みのタイミングが重要でした。このお客様の目的を達成するにあたり、私たちは以下のパターンを提案しました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Pattern_1.max-2000x2000.jpg

このパターンでは、お客様は 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 のシナリオに適しています。このお客様は、ネットワークログに関するより詳細な分析情報を求めていました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Pattern_2.max-2000x2000.jpg

このパターンは、特にネットワークログに関連した異常検出やパターン認識などのモデルを実行する必要があるお客様におすすめです。ネットワークログは大量に発生する傾向があり、これらのログは主に分析のために使用されていたため、お客様は並べ替え、フィルタリング、ダッシュボードなどの機能をあまり活用していませんでした。そこで有用なのが、低コストかつ 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 インターフェースから直接分析できます。