マルチテナント GKE ソリューションのオブザーバビリティを設定する方法
Google Cloud Japan Team
※この投稿は米国時間 2023 年 8 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。
運用を簡素化し、コストを削減する方法として、Kubernetes クラスタの「マルチテナンシー」のアイデアが広く採用されています。マルチテナンシーは、共有クラスタ上で複数のチームのアプリケーションをホストするための洗練されたソリューションを提供し、リソース使用率の最適化、セキュリティの簡素化、運用オーバーヘッドの削減を実現します。このアプローチは多くの機会をもたらしますが、考慮すべきリスクも伴います。具体的には、問題をトラブルシューティングする方法、大量のログを処理する方法、およびそれらのログの分析に必要な権限を開発者に付与する方法を慎重に検討する必要があります。
このブログ投稿は、優れたオブザーバビリティを実現するために GKE マルチテナント ソリューションを設定する方法を学ぶのに最適です。ログルーターを使用して GKE でマルチテナント ロギングを構成し、テナントのログを専用の GCP プロジェクトにルーティングするようにシンクを設定します。そうすることで、ログの保存方法と分析方法を定義し、ログの内容とログから導出された指標のグラフに基づいてアラートを設定できるようになるため、トラブルシューティングを迅速に行えます。
アーキテクチャ
複数のテナントで共有される GKE クラスタを設定し、分析のためにテナントのログを専用の GCP プロジェクトにルーティングするようにシンクを構成します。次に、受信ログエントリからアプリケーション エラーをカウントするためのログベースの指標を設定し、迅速なトラブルシューティングのためにダッシュボードとアラートを設定します。
これらの設定がどのように機能するかを示すために、ここでは GitHub 上のこちらの GCP リポジトリを使用して、複数のチームが名前空間で区切られたクラスタを共有する、一般的なマルチテナント設定をシミュレートしています。アプリは、共有 GKE クラスタにデプロイされたウェブ フロントエンドと Redis バックエンドで構成されています。フロントエンド固有のログは、ウェブ フロントエンド チームの専用の GCP プロジェクトにルーティングされます。複数のチームで共有されている GKE クラスタがすでにある場合は、ログをテナントのプロジェクトにルーティングするようにシンクを構成し、グラフとアラートを設定する部分までスキップしてください。論理アーキテクチャは以下のとおりです。
ルーティングの概要
GCP 上の受信ログエントリは、Cloud Logging API の背後にあるログルーターを通過します。ログルーターのシンクは、各ログエントリを一連の包含フィルタと除外フィルタ（存在する場合）と照合することにより、ログのルーティング方法と宛先を制御します。サポートされているシンクの宛先は以下のとおりです。
Cloud Logging ログバケット: ログバケットは、GCP Cloud Logging でログデータを保存、整理するコンテナです。ログバケットに保存されたログはインデックス登録され、ログ エクスプローラでのリアルタイム分析用と、オプションでログ分析ツールによるログ分析用に最適化されます。
他の GCP プロジェクト: これは、このブログ投稿で紹介するものです。テナントのログを GCP プロジェクトにエクスポートし、ログがどのようにルーティング、保存、分析されるかを制御できるようにします。
Pub/Sub トピック: これは、Cloud Logging のログを Splunk などのサードパーティ ソフトウェアと統合する場合に推奨されるアプローチです。
BigQuery データセット: BigQuery データセットにログエントリのストレージを提供します。
Cloud Storage バケット: 長期保持とコンプライアンスの目的でログを保存します。
Cloud Logging では、サポートされている宛先にログをルーティングするのに料金は発生しませんが、宛先の料金が適用されます。詳細については、Cloud Logging の料金をご覧ください。
前提条件
すでに以下の条件を満たしている場合は、このセクションをスキップして構いません。
共有 GKE クラスタがある
テナント固有のログを送信するためにテナント用の別のプロジェクトがある
メイン プロジェクトでの共有 GKE クラスタの設定
クラスタが正常に作成されたら、テナント用に別の名前空間を作成します。テナント固有のすべてのログは、この名前空間からテナントの専用 GCP プロジェクトにルーティングされます。
ここでは、こちらの GCP リポジトリを使用して、名前空間で区切られたマルチテナント設定をシミュレートしています。フロントエンドをテナント名前空間にデプロイし、Redis クラスタをデフォルトの名前空間にデプロイします。別のアプリをお使いいただいても構いません。
テナントの GCP プロジェクトは、こちらのガイドに沿って設定してください。
シンクの構成
まず、メイン プロジェクト（共有 GKE クラスタが存在する場所）にシンクを作成し、テナント固有のすべてのログをテナントのプロジェクトに送信します。
上記のコマンドは、テナントの名前空間のログをその独自のプロジェクトに転送するシンクをメイン プロジェクトに作成します。--log-filter に別の値またはより制限された値を使用して、エクスポートするログエントリを指定できます。これらのフィールドの詳細については、こちらの API ドキュメントをご覧ください。
必要に応じて、GKE クラスタがあるメイン プロジェクトに除外フィルタを作成して、両方のプロジェクトに冗長なログが保存されないようにすることができます。システムの全般的な運用とパフォーマンスに集中しながら、開発チームにアプリケーションのモニタリングに必要な自主性とツールを提供できるため、一部の DevOps チームにはこの設定が好まれます。除外フィルタを作成するには、次のコマンドを実行します。
上記のコマンドは、ログをメイン プロジェクトにルーティングするシンクの除外フィルタを作成し、テナント固有のログのみがテナント プロジェクトに保存されるようにします。
テナント プロジェクトにログを書き込む権限をメイン プロジェクトに付与します。
これで、テナント固有のログがテナント プロジェクトに流れ始めます。確認するには、次の手順を行います。
1. GCP コンソールのプロジェクト選択ツールからテナント プロジェクトを選択します。
2. ナビゲーション メニューから [ロギング] を選択して、[ログ エクスプローラ] ページに移動します。
3. メイン プロジェクトからルーティングされたテナント固有のログは、テナント プロジェクトの [クエリ結果] ペインに表示されます。
確認するには、シンクの作成時に渡した
--log-filter値を実行します。query-editor フィールドでresource.labels.namespace_name="$TENANT_NAMESPACE"を実行して確認します。
ログベースの指標の設定
次に、ログベースの指標を定義して、受信ログエントリから有意義な分析情報を得ることができます。たとえば、開発チームはログベースの指標を作成して、アプリケーション内の特定のタイプのエラーの数をカウントし、Cloud Monitoring のグラフとアラート ポリシーを設定して迅速にトリアージすることができます。Cloud Logging には、一般的な使用状況の情報を収集するために、すぐに使えるシステム定義の指標がいくつか用意されていますが、独自のログベースの指標を定義して、アプリケーション固有の情報を取得することもできます。
エラー メッセージが含まれる受信ログエントリの数をカウントするためのログベースのカスタム指標を作成するには、テナント プロジェクトで次のコマンドを実行します。
ログベースの指標のグラフの作成
1. GCP コンソールで [ログベースの指標] ページに移動します。
2. 表示する指標を見つけて、メニューから [Metrics Explorer で表示する] を選択します。
下のスクリーンショットは、ログエントリが記録されるとリアルタイムで更新される指標を示しています。
3. 必要に応じて、ツールバーの [グラフの保存] をクリックして、後で参照するためにこのグラフを保存できます。また、このグラフは既存または新規のダッシュボードに追加できます。これにより、開発チームはログが記録されるたびにその傾向をモニタリングし、エラーが発生した場合に問題のトリアージを迅速に行うことができます。
次に、アプリケーション チームがエラーを迅速に見つけて修正できるように、ログベースの指標のアラートを設定します。
ログベースの指標のアラート
アラート対象の指標を見つけて、メニューから [指標に基づいて通知を作成する] を選択します。
モニタリング フィルタ フィールドに値を入力します。この場合は、
metric.type="logging.googleapis.com/user/error_count"になります。[次へ] をクリックし、しきい値を入力します。
[次へ] をクリックし、アラートに使用する通知チャンネルを選択します。
このアラート ポリシーに名前を付けて、[ポリシーを作成] をクリックします。
アラートがトリガーされると、インシデントの詳細が含まれる通知が、上で選択した通知チャンネルに送信されます。開発チーム（テナント）は GCP コンソールでもアラートを表示できるため、迅速にトリアージすることができます。
まとめ
このブログ投稿では、開発チームが共有 GKE インフラストラクチャ上で Kubernetes アプリケーションを効果的にトラブルシューティングできるようにする方法の一つを見てきました。Google Cloud のオペレーション スイートは、システムのモニタリングとトラブルシューティングをリアルタイムで効果的に行うために必要なツールと構成オプションを提供し、問題の早期検出と効率的なトラブルシューティングを可能にします。詳しくは、以下のリンクをご覧ください。
