このチュートリアルは、Google Kubernetes Engine(GKE)で実行される最新のアプリケーション環境をデプロイ、実行、管理することを目的とする IT 管理者とオペレーターを対象としています。このチュートリアルでは、Cymbal Bank サンプル マイクロサービス アプリケーションを使用して、モニタリングとアラートの構成、ワークロードのスケーリング、障害のシミュレーションの方法を学習します。
- クラスタを作成してサンプル アプリケーションをデプロイする
- Google Cloud Managed Service for Prometheus でモニタリングする(このチュートリアル)
- ワークロードをスケーリングする
- 障害をシミュレートする
概要と目的
このチュートリアルで使用する Cymbal Bank サンプル アプリケーションは、すべて GKE クラスタで実行される多数のマイクロサービスで構成されています。これらのサービスのいずれかに問題があると、銀行のアプリケーションにアクセスできないなど、銀行の顧客に悪影響が及ぶ可能性があります。サービスに関する問題をできるだけ早く把握することで、問題のトラブルシューティングと解決を迅速に開始できます。
このチュートリアルでは、Google Cloud Managed Service for Prometheus と Cloud Monitoring を使用して GKE クラスタのワークロードをモニタリングする方法を学習します。次のタスクを完了する方法を学習します。
Alertmanager 用の Slack Webhook を作成します。
サンプルのマイクロサービス ベース アプリケーションのステータスをモニタリングするように Prometheus を構成します。
サービスの停止をシミュレートし、Slack Webhook を使用して送信されたアラートを確認します。
費用
この一連のチュートリアルで GKE を有効にして Cymbal Bank サンプル アプリケーションをデプロイすると、GKE を無効にするかプロジェクトを削除するまで、料金ページに記載されているように、Google Cloud の GKE に対してクラスタごとの料金が発生します。
また、Compute Engine VM や Cloud Monitoring の費用など、Cymbal Bank サンプル アプリケーションの実行中に発生した他の Google Cloud の費用もお客様の負担となります。
始める前に
ワークロードのモニタリング方法を確認するには、最初のチュートリアルを完了して、Autopilot を使用する GKE クラスタを作成し、Cymbal Bank サンプルのマイクロサービス ベースのアプリケーションをデプロイする必要があります。
スケーラブルなアプリのチュートリアルは順番に完了することをおすすめします。チュートリアルを進めていくと、新しいスキルを習得し、追加の Google Cloud プロダクトとサービスを使用できるようになります。
このチュートリアルでは、GKE Autopilot クラスタで Google Cloud Managed Service for Prometheus を使用して通信プラットフォームにメッセージを生成する方法の例として、Slack を使用します。独自の本番環境のデプロイでは、組織で使用しているコミュニケーション ツールを使用して、GKE クラスタに問題が発生したときにメッセージを処理して配信できます。
メールアドレスで登録するか、またはワークスペース管理者から送信された招待状を利用して、Slack ワークスペースに参加します。
Slack アプリケーションを作成する
モニタリングを設定する際は、サービス停止などの対処可能なイベントが発生したときに通知を受け取れるようにすることが重要です。一般的なパターンは、Slack などのコミュニケーション ツールに通知を送信することです。このチュートリアルでは Slack を使用します。Slack には、本番環境のデプロイメントなどの外部アプリケーションでメッセージを生成できる Webhook 機能があります。GKE クラスタに問題がある場合は、組織内の他のコミュニケーション ツールを使用して、メッセージを処理して配信できます。
Autopilot を使用する GKE クラスタには、Google Cloud Managed Service for Prometheus インスタンスが含まれています。このインスタンスは、アプリケーションになんらかの問題が発生したときにアラートを生成できます。これらのアラートは、Slack Webhook を使用して Slack ワークスペースにメッセージを送信できるため、問題が発生したときに迅速に通知を受け取ることができます。
Prometheus によって生成されたアラートに基づいて Slack 通知を設定するには、Slack アプリケーションを作成し、アプリケーションの着信 Webhook を有効にして、Slack ワークスペースにアプリケーションをインストールする必要があります。
ワークスペース名と Slack アカウントの認証情報を使用して、Slack にログインします。
-
- [Create an app] ダイアログで [From scratch] をクリックします。
- [アプリ名] を指定し、Slack ワークスペースを選択します。
- [Create App] をクリックします。
- [Add Features and Features] で、[着信 Webhook] をクリックします。
- [Activate Incoming Webhooks] の切り替えボタンをクリックします。
- [Webhook URLs for Your Workspace] セクションで、[Add New Webhook to Workspace] をクリックします。
- 表示された認証ページで、通知を受け取るチャネルを選択します。
- [許可] をクリックします。
- [Webhook URLs for Your Workspace] セクションに Slack アプリケーションの Webhook が表示されます。後で使用できるように、URL を保存します。
Alertmanager を構成する
Prometheus では、Alertmanager はデプロイによって生成されるモニタリング イベントを処理します。Alertmanager は、重複するイベントのスキップ、関連するイベントのグループ化、Slack Webhook を使用した通知の送信を行えます。このセクションでは、新しい Slack Webhook を使用するように Alertmanager を構成する方法について説明します。送信するイベントを Alertmanager が処理する方法を指定するには、チュートリアルの次のセクション Prometheus を構成するをご覧ください。
Slack Webhook を使用するように Alertmanager を構成するには、次の手順を行います。
前のチュートリアルの Cymbal Bank のサンプル マニフェストがすべて含まれる Git リポジトリにディレクトリを変更します。
cd ~/bank-of-anthos/
必要に応じて、ディレクトリの場所を、以前にリポジトリのクローンを作成した場所に変更します。
Alertmanager のサンプル YAML マニフェストを更新して、Slack アプリケーションの Webhook URL を指定します。
sed -i "s@SLACK_WEBHOOK_URL@SLACK_WEBHOOK_URL@g" "extras/prometheus/gmp/alertmanager.yaml"
SLACK_WEBHOOK_URL
は、前のセクションの Webhook の URL に置き換えます。アプリケーション コードを変更せずに、一意の Slack Webhook URL を動的に使用するには、Kubernetes Secret を使用します。アプリケーション コードは、この Secret の値を読み取ります。より複雑なアプリケーションでは、この機能により、セキュリティやコンプライアンス上の理由で値を変更できます。
Slack Webhook URL を含むサンプル YAML マニフェストを使用して、Alertmanager の Kubernetes Secret を作成します。
kubectl create secret generic alertmanager \ -n gmp-public \ --from-file=extras/prometheus/gmp/alertmanager.yaml
Prometheus は、エクスポートを使用して、コードを変更することなくアプリケーションから指標を取得できます。Prometheus ブラックボックス エクスポータを使用すると、HTTP や HTTPS などのエンドポイントをプローブできます。このエクスポータは、アプリケーションの内部動作を Prometheus に公開したくない、または公開できない場合に適しています。Prometheus ブラックボックス エクスポータでは、アプリケーション コードを変更することなく、指標を Prometheus に公開できます。
Prometheus ブラックボックス エクスポータをクラスタにデプロイします。
kubectl apply -f extras/prometheus/gmp/blackbox-exporter.yaml
Prometheus を構成する
Slack Webhook を使用するように Alertmanager を構成したら、Cymbal Bank でモニタリングする内容と、Alertmanager で Slack Webhook を使用して通知するイベントの種類を Prometheus に伝える必要があります。
このチュートリアルで使用する Cymbal Bank サンプル アプリケーションには、GKE クラスタで実行されるさまざまなマイクロサービスがあります。Cymbal Bank サービスのいずれかがリクエストに正常に応答しなくなった場合、お客様はできるだけ早くその問題を把握する必要があります。お客様がアプリケーションにアクセスできなくなる可能性があるためです。組織のポリシーに基づいてイベントに対応するように Prometheus を構成できます。
プローブ
モニタリングするリソースの Prometheus プローブを構成できます。これらのプローブは、受信したレスポンスに基づいてアラートを生成できます。Cymbal Bank サンプル アプリケーションでは、Service から 200 レベルのレスポンス コードを確認する HTTP プローブを使用できます。HTTP 200 レベルのレスポンスは、サービスが正常に実行されており、リクエストに応答できることを示します。問題が発生し、プローブが想定どおりの応答を受け取らない場合は、Alertmanager が処理して追加のアクションを実行するためのアラートを生成する Prometheus ルールを定義できます。
Cymbal Bank サンプル アプリケーションのさまざまなマイクロサービスの HTTP ステータスをモニタリングする Prometheus プローブを作成します。次のサンプル マニフェストを確認します。
このマニフェスト ファイルのように、各
PodMonitoring
Prometheus liveness プローブで各 Deployment を個別にモニタリングすることをおすすめします。Prometheus liveness プローブを作成するには、マニフェストをクラスタに適用します。
kubectl apply -f extras/prometheus/gmp/probes.yaml
ルール
Prometheus は、前の手順で作成したプローブが受信するレスポンスに基づいて、何を実行する必要があるかを把握する必要があります。このレスポンスは Prometheus ルールを使用して定義します。
このチュートリアルでは、ライブネス プローブへのレスポンスに応じてアラートを生成する Prometheus ルールを作成します。Alertmanager は、これらのルールの出力を処理して、Slack Webhook を使用して通知を生成します。
ライブネス プローブへのレスポンスに基づいてイベントを生成するルールを作成します。次のサンプル マニフェストを確認します。
このマニフェストでは
PrometheusRule
を記述しています。次のフィールドを使用しています。spec.groups.[*].name
: ルールグループの名前。spec.groups.[*].interval
: グループ内のルールが評価される頻度。spec.groups.[*].rules[*].alert
: アラートの名前。spec.groups.[*].rules[*].expr
: 評価する PromQL 式。spec.groups.[*].rules[*].for
: アラートが発生したとみなされるまでにアラートが戻す必要がある時間の長さ。spec.groups.[*].rules[*].annotations
: 各アラートに追加するアノテーションのリスト。これはアラートルールでのみ有効です。spec.groups.[*].rules[*].labels
: 追加または上書きするラベル。
ルールを作成するには、マニフェストをクラスタに適用します。
kubectl apply -f extras/prometheus/gmp/rules.yaml
停止のシミュレーションを行う
Prometheus のプローブ、ルール、Alertmanager の構成が正しいことを確認するには、問題が発生したときにアラートと通知が送信されるかどうかをテストする必要があります。このフローをテストしないと、何か問題が発生したときに本番環境のサービスが停止していることに気付かない可能性があります。
いずれかのマイクロサービスの停止をシミュレートするには、
contacts
Deployment をゼロにスケーリングします。Service のインスタンスがゼロの場合、Cymbal Bank サンプル アプリケーションは顧客の連絡先情報を読み取れません。kubectl scale deployment contacts --replicas 0
GKE が Deployment をスケールダウンするまでに 5 分ほどかかることがあります。
クラスタの Deployment のステータスを確認し、
contacts
Deployment が正しくスケールダウンされていることを確認します。kubectl get deployments
次の出力例では、
contacts
Deployment が0
インスタンスにスケールダウンされています。NAME READY UP-TO-DATE AVAILABLE AGE balancereader 1/1 1 1 17m blackbox-exporter 1/1 1 1 5m7s contacts 0/0 0 0 17m frontend 1/1 1 1 17m ledgerwriter 1/1 1 1 17m loadgenerator 1/1 1 1 17m transactionhistory 1/1 1 1 17m userservice 1/1 1 1 17m
contacts
Deployment が 0 にスケールダウンされると、Prometheus プローブは HTTP エラーコードを報告します。この HTTP エラーは、Alertmanager が処理するアラートを生成します。Slack ワークスペース チャンネルで、次のようなテキストを含むサービス停止通知メッセージを確認します。
[FIRING:1] ContactsUnavailable Severity: Warning :warning: Summary: Contacts Service is unavailable Namespace: default Check Contacts pods and it's logs
実際の停止シナリオでは、Slack で通知を受け取った後、サービスのトラブルシューティングと復元を開始します。このチュートリアルでは、このプロセスをシミュレートし、レプリカの数をスケーリングして
contacts
Deployment を復元します。kubectl scale deployment contacts --replicas 1
Deployment のスケーリングと Prometheus プローブが HTTP 200 レスポンスを受信するまでに 5 分ほどかかることがあります。
kubectl get deployments
コマンドを使用して、Deployment のステータスを確認します。Prometheus プローブに対する正常なレスポンスが受信されると、Alertmanager はイベントをクリアします。Slack ワークスペース チャンネルにアラート解決通知メッセージが表示されます。次に例を示します。
[RESOLVED] ContactsUnavailable Severity: Warning :warning: Summary: Contacts Service is unavailable Namespace: default Check Contacts pods and it's logs
クリーンアップ
Cymbal Bank のチュートリアルは順番に完了することをおすすめします。チュートリアルを進めていくと、新しいスキルを習得し、追加の Google Cloud プロダクトとサービスを使用できるようになります。
次のチュートリアルに進む前に中断する場合、このチュートリアルで使用したリソースについて Google Cloud アカウントに課金されないようにするには、作成したプロジェクトを削除します。
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
次のステップ
次のチュートリアルで、GKE でデプロイをスケーリングする方法を確認する。