ハイブリッド クラウドとマルチクラウドのモニタリングおよびロギング パターン

このドキュメントでは、ハイブリッド クラウドとマルチクラウドのデプロイのモニタリングおよびロギング アーキテクチャと、Google Cloud を使用してそれらを実装するためのベスト プラクティスについて説明します。このドキュメントを使用することにより、ご自身の環境に適したパターンとプロダクトを知ることができます。

ハイブリッド クラウドやマルチクラウドのアーキテクチャを設定するにあたり、要件および制約の元となるアプリケーション ワークロードは、企業ごとに異なります。これらの制約や要件を満たすようにアーキテクチャを設計し、調整する必要がありますが、適用できるパターンとして、いくつか一般的なものに整理できます。

このドキュメントで扱うパターンは、次の 2 つのカテゴリに分類されます。

  • 「一括表示」アーキテクチャでは、モニタリングとロギングがすべて一元化され、単一のアクセス ポイントと管理機能が提供されます。
  • 「アプリケーション・運用分離」アーキテクチャでは、機密データに対するコンプライアンス要件を満たすように、機密性の高いアプリケーション データは、機密性の低い運用データから分離されます。

アーキテクチャ パターンの選択

次の図のディシジョン ツリーを使用して、ユースケースに最適なアーキテクチャを決定できます。

モニタリングおよびロギング アーキテクチャを選択するためのディシジョン ツリー。

各アーキテクチャの詳細はこのドキュメントで説明しますが、大まかな選択肢として次のものがあります。

  • Monitoring からレガシー ソリューションにエクスポートする。
  • レガシー ソリューションに直接エクスポートする。
  • Monitoring を Prometheus および Floodentd と一緒に使用する。
  • Blue Medora BindPlane と Monitoring を使用する。

一括表示アーキテクチャ

ハイブリッド システムの共通目標は、複数のアプリケーションや複数の環境にある各ソースからのモニタリング情報とロギング情報を 1 か所に集めて一元的に表示することです。このような表示形式を「一括表示」といいます。

次の図は、このパターンを示しています。オンプレミスとクラウドの両方のアプリケーションからのモニタリング データとロギングデータが、クラウドでホストされる 1 つのリポジトリに一元化されています。

モニタリングとロギングのアーキテクチャの概要

このアーキテクチャには、次のメリットがあります。

  • すべてのモニタリングとロギングについて 1 つの一貫したビューが表示されます。
  • データの保存と保持を 1 つの場所で管理できます。
  • 一元化されたアクセス制御と監査を行えます。ただし、中央リポジトリに転送されるデータのセキュリティを確保する必要があります。

一括表示先としての Monitoring

Cloud Monitoring は、サービス、コンテナ、アプリケーション、インフラストラクチャ用の Google 管理のモニタリングおよび管理ソリューションです。Google Cloud オペレーション スイートは、指標、ログ、トレース、イベント用の一括表示および堅牢なストレージ ソリューションを提供します。このスイートは、ダッシュボード、レポート作成、アラート通知などのオブザーバビリティ ツールの完全なスイートも提供します。

Google Cloud プロダクトとサービスは、すべて Monitoring との統合をサポートしています。さらに、Monitoring をハイブリッド リソースとオンプレミス リソースに拡張するために使用できる統合ツールがいくつかあります。

次のベスト プラクティスは、Monitoring を一括表示先として使用するすべてのアーキテクチャに適用されます。

Monitoring と BlueMedora BindPlane を使用したハイブリッド モニタリングとロギング

Google のパートナーである Blue Medora BindPlane を使用すると、オンプレミス VM と、Amazon Web Services(AWS)、Microsoft Azure、Alibaba Cloud、IBM Cloud などの他のクラウド プロバイダのどちらからも、モニタリングとロギングのデータを Monitoring にインポートできます。次の図は、Monitoring と BindPlane によってハイブリッド クラウドの一括表示が実現される仕組みを示しています。

BindPlane と Monitoring によるモニタリングとロギングのためのアーキテクチャの概要。

このアーキテクチャには、次のメリットがあります。

このパターンの実装の詳細については、Blue Medora を使用したオンプレミス リソースのロギングとモニタリングをご覧ください。

Prometheus と Monitoring を使用したハイブリッド Google Kubernetes Engine モニタリング

一般的なオープンソースのモニタリング ソリューションである PrometheusMonitoring Prometheus サイドカーを使用すると、複数の Kubernetes クラスタで実行されるアプリケーションを Monitoring でモニタリングできます。このアーキテクチャは、オンプレミスのデータセンターで Google Cloud の Google Kubernetes Engine(GKE)と Anthos GKE On-Prem に分散した Kubernetes ワークロードを実行する場合に便利です。両方に統合された 1 つのインターフェースを利用できるためです。次の図は、データ収集に Prometheus と Monitoring サイドカーを使用する方法を示しています。

Prometheus と Monitoring を使用した GKE モニタリングのアーキテクチャの概要。

このアーキテクチャには、次のメリットがあります。

  • クラウド環境とオンプレミス環境の両方で一貫した Kubernetes 指標を利用できます。
  • Prometheus の使用にあたり、追加のライセンス費用は発生しません。Prometheus 指標は、カスタム指標として Monitoring にインポートされ、標準レートで課金されます

このアーキテクチャには、次のデメリットがあります。

  • Monitoring Prometheus サイドカーは GKE 環境でのみサポートされています。
  • Prometheus はモニタリングのみをサポートしているため、ロギングは別途構成する必要があります。次のセクションでは、ロギングの一般的なオプションである Fluentd について説明します。

次のベスト プラクティスをおすすめします。

  • Prometheus はデフォルトで公開されたすべての指標を収集します。各指標が、課金対象のカスタム指標になります。予期しない費用を回避するには、Monitoring のコスト管理を実装し、Monitoring Prometheus サイドカーにフィルタを追加して、取り込みを制限することを検討してください。

このパターンの実装の詳細については、Prometheus と Monitoring を使用した複数の GKE クラスタ上で実行されるアプリケーションのモニタリングご覧ください。

Fluentd と Logging を使用したハイブリッド GKE ロギング

人気のあるオープンソース ロギング エージェントである Fluentd と、Cloud Logging を使用すると、複数の GKE クラスタで実行されているアプリケーションから Cloud Logging にログを取り込むことができます。このアーキテクチャは、Google Cloud 上の GKE とオンプレミス データセンターの GKE On-Prem に分散した Kubernetes ワークロードを実行する場合に便利です。GKE と GKE On-Prem 間で統合された 1 つのインターフェースを利用できるためです。次の図は、ログのフローを示しています。

Floodent、Monitoring、Logging による GKE モニタリングの概要。

このアーキテクチャには、次のメリットがあります。

  • クラウド環境とオンプレミス環境の両方で一貫した Kubernetes ロギングを使用できます。
  • ロギングをカスタマイズして、機密情報を除外できます。
  • Fluentd の使用にあたり、追加のライセンス費用は発生しません。Logging にインポートされた Fluentd ログは、標準レートで課金されます

このアーキテクチャには、次のデメリットがあります。

このパターンの実装の詳細については、Fluentd を使用した Google Kubernetes Engine 用の Logging のログをカスタマイズするをご覧ください。

一括表示に対応したパートナー サービス

すでに Datadog や Splunk などのサードパーティのモニタリング サービスやロギング サービスを使用している場合は、Logging への移行はおすすめしません。その場合、Google Cloud から多くの一般的モニタリングおよびロギング サービスにデータをエクスポートできます。統合されたモニタリング サービスおよびロギング サービスと、ニーズに合った個別のモニタリングおよびロギング サービスのいずれを使用するかを選択できます。

Logging からパートナー サービスへのエクスポート

このパターンでは、Datadog などのパートナーのモニタリング サービスが Cloud Monitoring API に接続することを承認します。この承認により、サービスは Logging で利用可能な指標をすべて取り込むことができるため、Datadog はモニタリング用の一括表示先として機能します。

データのロギングのために、Logging では Pub/Sub へのエクスポート(ログシンク)が利用できます。このようにエクスポートすると、パートナー ロギング サービス(ElasticSplunk など)が Logging から大量のログをリアルタイムで取り込むためのパフォーマンスと復元性を確保できます。これらのパートナー サービスはログ用の一括表示を提供します。

次の図に、ロギングとモニタリングの複合アーキテクチャを示します。

モニタリングとロギングのデータをパートナー サービスにエクスポートするためのアーキテクチャの概要。

このアーキテクチャには、次のメリットがあります。

  • 使い慣れた既存のツールを引き続き使用できます。
  • Google Cloud サポートは、Logging ログを使用したトラブル シューティングに引き続き対応します。

このアーキテクチャには、次のデメリットがあります。

  • 通常、パートナー ソリューションは外部でホストされます。つまり、ネットワーク接続が中断された場合、パートナー ソリューションを利用できない、またはパートナー ソリューションがデータを収集できない状況が発生します。セルフホスティングによってこのリスクを回避できる場合もありますが、ソリューションのインフラストラクチャを自分で維持する必要があります。
  • 外部でホストされるダッシュボードは、Google Cloud サポートでは直接利用できません。これにより、トラブルシューティングとその解決が遅れる可能性があります。
  • 商用パートナー ソリューションには、高額なライセンス料が必要になる場合があります。

統合の具体例のうち、次のものがあります。

Prometheus と Logging から Gradfana への指標のエクスポート

Grafana は、指標の収集のために、一般に Prometheus と組み合わされている人気のあるオープンソース モニタリング ツールです。このアーキテクチャでは、Prometheus をオンプレミスの収集レイヤとして使用し、Grafana を Google Cloud とオンプレミス リソースの両方を表示する一括表示先として使用します。次の図は、Google Cloud とオンプレミスから指標をエクスポートするアーキテクチャの例を示しています。

一括表示先である Grafana を使用してモニタリングするためのアーキテクチャの概要。

このアーキテクチャには、次のメリットがあります。

  • VM とコンテナの両方があるハイブリッド環境に適しています。
  • 組織ですでに Prometheus と Grafana を使用している場合、ユーザーは引き続き Prometheus と Grafana を使用できます。

このアーキテクチャには、次のデメリットがあります。

  • Prometheus と Grafana はモニタリングのみをサポートしているため、Fluentd などを使用して、ロギングを別途構成する必要があります。
  • Prometheus はオープンソースで拡張可能ですが、サポート対象のエンタープライズ ソフトウェア統合は限られています。
  • Prometheus と Grafana はサードパーティのツールであり、Google のプロダクトではありません。Google は、Prometheus または Grafana をサポートしていません。

詳細については、Grafana のデータソースとしての Logging の概要をご覧ください。GKE と Logging を使用して Prometheus と Grafana をデプロイする詳細なチュートリアルについては、Prometheus と Grafana を使用した IoT モニタリングをご覧ください。

Fluentd を使用したログのエクスポート

Fluentd を Logging のログコレクタとして使用する方法については、前述のパターンで説明しました。Fluentd をサポートする他のロギングまたはデータ分析システム(BigQuery、Elastic、Splunk など)にもこれと同じ基本アーキテクチャを使用できます。次の図は、このパターンを示しています。

Fluentd から直接ログをエクスポートするアーキテクチャの概要。

このアーキテクチャには、次のメリットがあります。

  • VM とコンテナの両方があるハイブリッド環境に適しています。
  • Fluentd はシステムログなどの多くのデータソースからデータを読み込むことができます。
  • Fluentd は、多くの一般的なサードパーティのロギングおよびデータ分析システム用の出力プラグインを提供しています。

このアーキテクチャには、次のデメリットがあります。

  • Fluentd はロギングのみをサポートしているため、モニタリングは別途構成する必要があります。前のセクションでは、Prometheus と Grafana を使用したモニタリングの一般的なオプションについて説明しました。
  • Fluentd は Google のプロダクトではなく、サードパーティのツールです。Google は Fluentd をサポートしていません。
  • Google Cloud サポートは、エクスポートされたログを使用したトラブルシューティングに対応していません。特に、Google はロギングが有効になっていない GKE On-Prem クラスタのサポートを提供していません。

Fluentd と BigQuery を統合する例については、Fluentd と BigQuery を使用したリアルタイムのログ分析をご覧ください。

アプリケーション データと運用データの分離

一括表示アーキテクチャを利用するには、アプリケーションのモニタリング データとロギングデータをクラウドにストリーミングする必要があります。ただし、規制またはコンプライアンスの要件により、顧客データをオンプレミスに保持しなければならない、あるいはパブリック クラウドに保存できるデータに厳しい制約を受ける場合があります。

これらのハイブリッド環境は機密性の高いアプリケーション データを低リスクの運用データから分離するため、次の図に示すように、有用なパターンです。

アプリケーション データと運用データを分離するためのアーキテクチャの概要。

Anthos を使用したアプリケーション データとシステムデータの分離

Anthos スイートの一部である Anthos on VMware には、オンプレミス クラスタをモニタリングするための Grafana が準備されています。さらに、ロギング用に Elastic Stack や Splunk などのパートナー ソリューションをインストールすることもできます。これらのソリューションを使用すると、システムデータを Google Cloud の Logging にエクスポートし、機密性の高いアプリケーション データを完全にオンプレミスで取り込んで表示できます。次の図は、このアーキテクチャを表しています。

Anthos を使用したアプリケーション データとシステムデータの分離。

このアーキテクチャには、次のメリットがあります。

  • 機密性の高いアプリケーション データは完全にオンプレミスで保持されます。
  • オンプレミスのモニタリングとロギングにはクラウドの依存関係がなく、ネットワーク接続が中断されても引き続き使用できます。
  • オンプレミスと Google Cloud の両方の GKE システムデータは、すべて Logging に一元化され、必要に応じて Google Cloud サポートも利用できます。

Elastic Stack をパートナー ソリューションとして使用した実装例については、Elastic Stack を使用した Anthos のモニタリングをご覧ください。

次のステップ