このドキュメントでは、ハイブリッド クラウドとマルチクラウドのデプロイのモニタリングおよびロギング アーキテクチャと、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 を一括表示先として使用するすべてのアーキテクチャに適用されます。
- ログ保持に対するコンプライアンス要件を満たすには、組織のログシンクを設定します。
- ログイベントを迅速に分析するには、セキュリティとアクセス分析のための BigQuery へのログ エクスポートを設定します。
- 機密データを扱うプロジェクトの場合、データアクセス監査ログを有効にして、データにアクセスしたユーザーをトラックできるようにすることを検討してください。
- 社会保障番号、クレジット カード番号、メールアドレスなどの機密情報を除外するには、ログデータをフィルタします。カスタム Fluentd 構成を使用した収集のフィルタや、ログを除外した取り込みのフィルタが可能です。 コンプライアンス要件を満たすために、フィルタされていないログを個別にエクスポートできます。
- 費用を最適化するには、Monitoring と Logging の使用状況を分析し、費用管理を行います。Monitoring と Logging は、ログと指標に対してボリューム ベースの料金が発生するマネージド サービスです。
Monitoring と BlueMedora BindPlane を使用したハイブリッド モニタリングとロギング
Google のパートナーである Blue Medora BindPlane を使用すると、オンプレミス VM と、Amazon Web Services（AWS）、Microsoft Azure、Alibaba Cloud、IBM Cloud などの他のクラウド プロバイダのどちらからも、モニタリングとロギングのデータを Monitoring にインポートできます。次の図は、Monitoring と BindPlane によってハイブリッド クラウドの一括表示が実現される仕組みを示しています。
このアーキテクチャには、次のメリットがあります。
- Blue Medora には VM などのモニタリング リソースに加えて、150 を超える一般的なデータソースに対する緊密な統合が組み込まれています。
- BindPlane の使用にあたり、追加のライセンス費用は発生しません。BindPlane の指標は、カスタム指標として Monitoring にインポートされ、標準レートで課金されます。同様に、BindPlane ログは他の Logging ログと同じレートで課金されます。
このパターンの実装の詳細については、Blue Medora を使用したオンプレミス リソースのロギングとモニタリングをご覧ください。
Prometheus と Monitoring を使用したハイブリッド Google Kubernetes Engine モニタリング
一般的なオープンソースのモニタリング ソリューションである Prometheus と Monitoring Prometheus サイドカーを使用すると、複数の Kubernetes クラスタで実行されるアプリケーションを Monitoring でモニタリングできます。このアーキテクチャは、統合された 1 つのインターフェースを利用できるため、Google Cloud 上の Google Kubernetes Engine（GKE）とオンプレミス データセンターの VMware 上の Anthos クラスタに分散されている Kubernetes ワークロードを実行する場合に便利です。次の図は、データ収集に Prometheus と Monitoring サイドカーを使用する方法を示しています。
このアーキテクチャには、次のメリットがあります。
- クラウド環境とオンプレミス環境の両方で一貫した 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 にログを取り込むことができます。このアーキテクチャは、統合された 1 つのインターフェースを利用できるため、Google Cloud 上の GKE とオンプレミス データセンターの VMware 上の Anthos クラスタに分散されている Kubernetes ワークロードを実行する場合に便利です。次の図は、ログのフローを示しています。
このアーキテクチャには、次のメリットがあります。
- クラウド環境とオンプレミス環境の両方で一貫した Kubernetes ロギングを使用できます。
- ロギングをカスタマイズして、機密情報を除外できます。
- Fluentd の使用にあたり、追加のライセンス費用は発生しません。Logging にインポートされた Fluentd ログは、標準レートで課金されます。
このアーキテクチャには、次のデメリットがあります。
- Fluentd はロギングのみをサポートしているため、モニタリングは別途構成する必要があります。Prometheus を使用したモニタリングの一般的なオプションについては前のセクションで説明しました。
このパターンの実装の詳細については、Fluentd を使用した Google Kubernetes Engine 用の Logging のログをカスタマイズするをご覧ください。
一括表示に対応したパートナー サービス
すでに Datadog や Splunk などのサードパーティのモニタリング サービスやロギング サービスを使用している場合は、Logging への移行はおすすめしません。その場合、Google Cloud から多くの一般的モニタリングおよびロギング サービスにデータをエクスポートできます。統合されたモニタリング サービスおよびロギング サービスと、ニーズに合った個別のモニタリングおよびロギング サービスのいずれを使用するかを選択できます。
Logging からパートナー サービスへのエクスポート
このパターンでは、Datadog などのパートナーのモニタリング サービスが Cloud Monitoring API に接続することを承認します。この承認により、サービスは Logging で利用可能な指標をすべて取り込むことができるため、Datadog はモニタリング用の一括表示先として機能します。
データのロギングのために、Logging では Pub/Sub へのエクスポート（ログシンク）が利用できます。このようにエクスポートすると、パートナー ロギング サービス（Elastic、Splunk など）が Logging から大量のログをリアルタイムで取り込むためのパフォーマンスと復元性を確保できます。これらのパートナー サービスはログ用の一括表示を提供します。
次の図に、ロギングとモニタリングの複合アーキテクチャを示します。
このアーキテクチャには、次のメリットがあります。
- 使い慣れた既存のツールを引き続き使用できます。
- Google Cloud サポートは、Logging ログを使用したトラブル シューティングに引き続き対応します。
このアーキテクチャには、次のデメリットがあります。
- 通常、パートナー ソリューションは外部でホストされます。つまり、ネットワーク接続が中断された場合、パートナー ソリューションを利用できない、またはパートナー ソリューションがデータを収集できない状況が発生します。セルフホスティングによってこのリスクを回避できる場合もありますが、ソリューションのインフラストラクチャを自分で維持する必要があります。
- 外部でホストされるダッシュボードは、Google Cloud サポートでは直接利用できません。これにより、トラブルシューティングとその解決が遅れる可能性があります。
- 商用パートナー ソリューションには、高額なライセンス料が必要になる場合があります。
統合の具体例のうち、次のものがあります。
- Datadog: Compute Engine 指標のモニタリングと Logging のログの収集
- Elastic: Logging のログの Elastic Cloud へのエクスポート
- Splunk: Logging のエクスポートのシナリオ
Prometheus と Logging から Gradfana への指標のエクスポート
Grafana は、指標の収集のために、一般に Prometheus と組み合わされている人気のあるオープンソース モニタリング ツールです。このアーキテクチャでは、Prometheus をオンプレミスの収集レイヤとして使用し、Grafana を Google Cloud とオンプレミス リソースの両方を表示する一括表示先として使用します。次の図は、Google Cloud とオンプレミスから指標をエクスポートするアーキテクチャの例を示しています。
このアーキテクチャには、次のメリットがあります。
- 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 など）にもこれと同じ基本アーキテクチャを使用できます。次の図は、このパターンを示しています。
このアーキテクチャには、次のメリットがあります。
- VM とコンテナの両方があるハイブリッド環境に適しています。
- Fluentd はシステムログなどの多くのデータソースからデータを読み込むことができます。
- Fluentd は、多くの一般的なサードパーティのロギングおよびデータ分析システム用の出力プラグインを提供しています。
このアーキテクチャには、次のデメリットがあります。
- Fluentd はロギングのみをサポートしているため、モニタリングは別途構成する必要があります。前のセクションでは、Prometheus と Grafana を使用したモニタリングの一般的なオプションについて説明しました。
- Fluentd は Google のプロダクトではなく、サードパーティのツールです。Google は Fluentd をサポートしていません。
- Google Cloud サポートは、エクスポートされたログを使用したトラブルシューティングに対応していません。特に、Google はロギングが有効になっていない VMware 上の Anthos クラスタのサポートを提供していません。
Fluentd と BigQuery を統合する例については、Fluentd と BigQuery を使用したリアルタイムのログ分析をご覧ください。
アプリケーション データと運用データの分離
一括表示アーキテクチャを利用するには、アプリケーションのモニタリング データとロギングデータをクラウドにストリーミングする必要があります。ただし、規制またはコンプライアンスの要件により、顧客データをオンプレミスに保持しなければならない、あるいはパブリック クラウドに保存できるデータに厳しい制約を受ける場合があります。
これらのハイブリッド環境は機密性の高いアプリケーション データを低リスクの運用データから分離するため、次の図に示すように、有用なパターンです。
Anthos を使用したアプリケーション データとシステムデータの分離
Anthos スイートの一部である Anthos on VMware には、オンプレミス クラスタをモニタリングするための Grafana が準備されています。さらに、ロギング用に Elastic Stack や Splunk などのパートナー ソリューションをインストールすることもできます。これらのソリューションを使用すると、システムデータを Google Cloud の Logging にエクスポートし、機密性の高いアプリケーション データを完全にオンプレミスで取り込んで表示できます。次の図は、このアーキテクチャを表しています。
このアーキテクチャには、次のメリットがあります。
- 機密性の高いアプリケーション データは完全にオンプレミスで保持されます。
- オンプレミスのモニタリングとロギングにはクラウドの依存関係がなく、ネットワーク接続が中断されても引き続き使用できます。
- オンプレミスと Google Cloud の両方の GKE システムデータは、すべて Logging に一元化され、必要に応じて Google Cloud サポートも利用できます。
Elastic Stack をパートナー ソリューションとして使用した実装例については、Elastic Stack を使用した Anthos のモニタリングをご覧ください。
次のステップ
- ハイブリッドとマルチクラウドのパターンとプラクティスのシリーズで、アーキテクチャ パターンとネットワーク トポロジなどの、ハイブリッドとマルチクラウドのベスト プラクティスの詳細を確認する。
- Cloud Kebernetes のベスト プラクティス クエストに登録して、GKE でのオブザーバビリティなどに関する実践的な演習を行う。
- Google Cloud のその他の機能を試す。チュートリアルをご覧ください。