このドキュメントでは、ハイブリッド クラウドとマルチクラウドのデプロイのモニタリングおよびロギング アーキテクチャと、Google Cloud を使用してそれらを実装するためのベスト プラクティスについて説明します。このドキュメントを使用することにより、ご自身の環境に適したパターンとプロダクトを知ることができます。
ハイブリッドやマルチクラウドのアーキテクチャを設定するにあたり、要件および制約条件の元となるアプリケーション ワークロードは、企業ごとにそれぞれ異なります。これらの制約や要件を満たすようにアーキテクチャを設計し、調整する必要がありますが、適用できるパターンとして、いくつか一般的なものに整理できます。
このドキュメントで扱うパターンは、次の 2 つのカテゴリに分類されます。
- 「一括表示」アーキテクチャでは、モニタリングとロギングがすべて一元化され、単一のアクセス ポイントと管理機能が提供されます。
- 「アプリケーションと運用の分離」アーキテクチャでは、機密データに対するコンプライアンス要件を満たすように、機密性の高いアプリケーション データは、機密性の低い運用データから分離されます。
アーキテクチャ パターンの選択
次の図のディシジョン ツリーを使用して、ユースケースに最適なアーキテクチャを決定できます。
各アーキテクチャの詳細はこのドキュメントで説明しますが、大まかな選択肢として次のものがあります。
- Monitoring からレガシー ソリューションにエクスポートする。
- レガシー ソリューションに直接エクスポートする。
- Prometheus と Fluentd または Fluent Bit で Monitoring を使用する。
- observIQ BindPlane で Monitoring を使用する。
一括表示アーキテクチャ
ハイブリッド システムの共通目標は、複数のアプリケーションや複数の環境にある各ソースからのモニタリング情報とロギング情報を 1 か所に集めて一元的に表示することです。このような表示形式を「一括表示」といいます。
次の図は、このパターンを示しています。オンプレミスとクラウドの両方のアプリケーションからのモニタリング データとロギングデータが、クラウドでホストされる 1 つのリポジトリに一元化されています。
このアーキテクチャには、次のメリットがあります。
- すべてのモニタリングとロギングについて 1 つの一貫したビューが表示されます。
- データの保存と保持を 1 つの場所で管理できます。
- 一元化されたアクセス制御と監査を行えます。ただし、中央リポジトリに転送されるデータのセキュリティを確保する必要があります。
一括表示先としての Monitoring
Cloud Monitoring は、サービス、コンテナ、アプリケーション、インフラストラクチャ用の Google 管理のモニタリングおよび管理ソリューションです。Google Cloud Observability を使用すると、指標、ログ、トレース、イベントを一元管理し、堅牢なストレージ ソリューションを実現できます。このスイートは、ダッシュボード、レポート作成、アラート通知などのオブザーバビリティ ツールの完全なスイートも提供します。
Google Cloud プロダクトとサービスは、すべて Monitoring との統合をサポートしています。さらに、Monitoring をハイブリッド リソースとオンプレミス リソースに拡張するために使用できる統合ツールがいくつかあります。
次のベスト プラクティスは、Monitoring を一括表示先として使用するすべてのアーキテクチャに適用されます。
- ログ保持に対するコンプライアンス要件を満たすには、組織のログシンクを設定します。
- ログイベントを迅速に分析するには、セキュリティとアクセス分析のための BigQuery へのログ エクスポートを設定します。
- ログバケットに保存されているログを分析するには、Log Analytics で SQL クエリを実行します。
- センシティブ データを扱うプロジェクトの場合、データアクセス監査ログを有効にして、データにアクセスしたユーザーをトラックできるようにすることを検討してください。
- 社会保障番号、クレジット カード番号、メールアドレスなどの機密情報を除外するには、ログデータをフィルタします。カスタム Fluentd の構成またはカスタム Fluent Bit 構成、またはログの除外を使用した取り込みを使用することによってフィルタできます。また、コンプライアンス要件を満たすために、フィルタされていないログも個別にエクスポートできます。
- 費用を最適化するには、Monitoring と Logging の使用状況を分析し、費用管理を行います。Monitoring と Logging は、ログと指標に対してボリューム ベースの料金が発生するマネージド サービスです。
observIQ による Monitoring と BindPlane を使用したハイブリッド モニタリングとロギング
Google のパートナーである observIQ の BindPlane を使用すると、オンプレミス VM とアマゾン ウェブ サービス（AWS）、Microsoft Azure、Alibaba Cloud、IBM Cloud を Google Cloud などの他のクラウド プロバイダの両方からモニタリング データとロギングデータをインポートできます。次の図は、Monitoring と BindPlane によってハイブリッド クラウドの一括表示が実現される仕組みを示しています。
このアーキテクチャには、次のメリットがあります。
- VM などのリソースのモニタリングに加えて、BindPlane には 50 を超える一般的なデータソース向けの緊密な組み込みのインテグレーションが用意されています。
- BindPlane の使用にあたり、追加のライセンス費用は発生しません。BindPlane の指標は、カスタム指標として Monitoring にインポートされ、課金対象となります。同様に、BindPlane ログは他の Logging ログと同じレートで課金されます。
このパターンの実装の詳細については、BindPlane を使用したオンプレミス リソースのロギングとモニタリングをご覧ください。
Prometheus と Monitoring を使用したハイブリッド Google Kubernetes Engine モニタリング
Google Cloud によって完全に管理されている一般的なオープンソース モニタリング ソリューションである Google Cloud Managed Service for Prometheus を使用して、複数の Kubernetes クラスタで実行されるアプリケーションを Monitoring でモニタリングできます。このアーキテクチャは、統合された 1 つのインターフェースを利用できるため、Google Cloud 上の Google Kubernetes Engine（GKE）とオンプレミス データセンターの VMware 上の GKE に分散されている Kubernetes ワークロードを実行する場合に便利です。次の図は、データ収集に Prometheus と Monitoring のコレクタを使用する方法を示しています。
このアーキテクチャには、次のメリットがあります。
- クラウド環境とオンプレミス環境の両方で一貫した Kubernetes 指標を利用できます。
- Prometheus を大規模に手動で管理、運用することなく、Prometheus を使用することでワークロードをモニタリングし、アラートを送信できるようになります。
- Prometheus の使用にあたり、追加のライセンス費用は発生しません。Prometheus の指標が Monitoring にインポートされます。インポートは課金対象であり、取り込まれたサンプル数に応じて課金されます。
このアーキテクチャには、次のデメリットがあります。
- Prometheus はモニタリングのみをサポートしているため、ロギングは別途構成する必要があります。次のセクションでは、Fluentd または Fluent Bit を使用したロギングの一般的なオプションについて説明します。
次のベスト プラクティスをおすすめします。
- Prometheus はデフォルトで公開されたすべての指標を収集します。各指標が、課金対象の指標になります。予期しない費用を回避するには、Monitoring の費用管理の実装を検討してください。
Fluentd または Fluent Bit と Cloud Logging を使用したハイブリッド GKE のロギング
Fluentd または一般的なオープンソース ロギング エージェントである Fluent ビットと Cloud Logging を使用すると、複数の GKE クラスタで実行されているアプリケーションから Cloud Logging にログを取り込むことができます。このアーキテクチャは、統合された 1 つのインターフェースを利用できるため、Google Cloud 上の GKE とオンプレミス データセンターの VMware 上の GKE に分散されている Kubernetes ワークロードを実行する場合に便利です。次の図は、ログのフローを示しています。
このアーキテクチャには、次のメリットがあります。
- クラウド環境とオンプレミス環境の両方で一貫した Kubernetes ロギングを使用できます。
- Logging をカスタマイズして、機密情報を除外できます。
- Fluentd または Fluent Bit の使用にあたり、追加のライセンス費用は発生しません。Fluentd または Fluent Bit を使用して Logging にインポートされたログは、課金対象です。
このアーキテクチャには、次のデメリットがあります。
- Fluentd と Fluent Bit はロギングのみをサポートしているため、モニタリングは別途構成する必要があります。Prometheus を使用したモニタリングの一般的なオプションについては前のセクションで説明しました。
このパターンの実装の詳細については、Fluentd を使用した Google Kubernetes Engine 用の Logging ログのカスタマイズまたは Fluent Bit を使用した 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 のエクスポートのシナリオ
Grafana を使用して Prometheus と Logging の指標を分析する
Grafana は、指標の収集のために、一般に Prometheus と組み合わされている人気のあるオープンソース モニタリング ツールです。このアーキテクチャでは、Prometheus をオンプレミスの収集レイヤとして使用し、Grafana を Google Cloud とオンプレミス リソースの両方を表示する一括表示先として使用します。次の図は、Google Cloud とオンプレミスの指標を分析するサンプル アーキテクチャを示しています。
このアーキテクチャには、次のメリットがあります。
- VM とコンテナの両方があるハイブリッド環境に適しています。
- 組織ですでに Prometheus と Grafana を使用している場合、ユーザーは引き続き Prometheus と Grafana を使用できます。
このアーキテクチャには、次のデメリットがあります。
- Prometheus はモニタリングのみをサポートしているため、Fluentd や Grafana 用 Cloud Logging プラグインなどを使用して、ロギングを個別に構成する必要があります。
- Prometheus はオープンソースで拡張可能ですが、サポート対象のエンタープライズ ソフトウェア統合は限られています。
- Prometheus と Grafana はサードパーティのツールであり、Google のプロダクトではありません。Google は、Prometheus または Grafana をサポートしていません。
詳細については、Grafana 用 Cloud Logging プラグインを使用したトラブルシューティングの改善をご覧ください。
Fluentd を使用したログのエクスポート
Fluentd または Fluent Bit を Logging のログコレクタとして使用する方法については、前述のパターンで説明しました。Fluentd または Fluent Bit をサポートする他のロギング システムまたはデータ分析システム（BigQuery、Elastic、Splunk など）にもこれと同じ基本アーキテクチャを使用できます。次の図は、このパターンを示しています。
このアーキテクチャには、次のメリットがあります。
- VM とコンテナの両方があるハイブリッド環境に適しています。
- Fluentd はシステムログなどの多くのデータソースからデータを読み込むことができます。
- Fluentd は、多くの一般的なサードパーティのロギングおよびデータ分析システム用の出力プラグインを提供しています。
- Fluent Bit は、システムログなどのさまざまな入力を読み取ることもできます。
- Fluent Bit は、多くの一般的なサードパーティのロギング システムおよびデータ分析システムの出力を提供しています。
このアーキテクチャには、次のデメリットがあります。
- Fluentd と Fluent Bit はログのみをサポートしているため、モニタリングは別途構成する必要があります。前のセクションでは、Prometheus と Grafana を使用したモニタリングの一般的なオプションについて説明しました。
- Fluentd と Fluent Bit はサードパーティのツールであり、Google の公式プロダクトではありません。Google はこれらをサポートしていません。
- Google Cloud サポートは、エクスポートされたログを使用したトラブルシューティングに対応していません。特に、Google はロギングが有効になっていない GKE on VMware クラスタのサポートを提供していません。
アプリケーション データと運用データの分離
一括表示アーキテクチャを利用するには、アプリケーションのモニタリング データとロギングデータをクラウドにストリーミングする必要があります。ただし、規制またはコンプライアンスの要件により、顧客データをオンプレミスに保持しなければならない、あるいはパブリック クラウドに保存できるデータに厳しい制約を受ける場合があります。
これらのハイブリッド環境は機密性の高いアプリケーション データを低リスクの運用データから分離するため、次の図に示すように、有用なパターンです。
GKE Enterprise を使用したアプリケーション データとシステムデータの分離
GKE Enterprise スイートの一部である GKE Enterprise on VMware には、オンプレミス クラスタをモニタリングするための Grafana が含まれています。さらに、ロギング用に Elastic Stack や Splunk などのパートナー ソリューションをインストールすることもできます。これらのソリューションを使用すると、システムデータを Google Cloud の Logging にエクスポートし、機密性の高いアプリケーション データを完全にオンプレミスで取り込んで表示できます。次の図は、このアーキテクチャを表しています。
このアーキテクチャには、次のメリットがあります。
- 機密性の高いアプリケーション データは完全にオンプレミスで保持されます。
- オンプレミスのモニタリングとロギングにはクラウドの依存関係がなく、ネットワーク接続が中断されても引き続き使用できます。
- オンプレミスと Google Cloud の両方の GKE システムデータは、すべて Logging に一元化され、必要に応じて Google Cloud サポートも利用できます。
パートナー ソリューションとして Elastic Stack を使用した実装例については、Elastic Stack を使用した GKE Enterprise のモニタリングをご覧ください。
次のステップ
- ハイブリッドとマルチクラウドのパターンとプラクティスのシリーズで、アーキテクチャ パターンと安全なネットワーキング アーキテクチャ パターンなどの、ハイブリッドとマルチクラウドのベスト プラクティスの詳細を確認する。
- Cloud Kebernetes のベスト プラクティス クエストに登録して、GKE でのオブザーバビリティなどに関する実践的な演習を行う。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。