はじめに
記載内容は上記の翻訳ではなく、意訳、要約を含みます。
手順も一部省略している部分もあります。
詳細や正確な手順を知りたい場合は本家サイトを参照ください。
画面スクショは本記事作成当時のものであり、今後のアップデートにより差異が発生する可能性があることをご留意ください。
Introduction
本ハンズオンではリソースの依存関係監視について学び、メトリクス監視やアラーム設定について学ぶことができます。
DEPLOY THE INFRASTRUCTURE
多くのワークロードは外部サービス、リソースに依存しています。
そのため、依存するサービス、リソースにデグレや障害が発生し、使用できなくなるとワークロードの機能性に大きな影響が発生します。
これらの依存関係を監視するためアラートや通知を設定することで関係者が問題を迅速に認識し、対応することができ、事業継続への影響を最小化することができます。
このハンズオンではOperational Excellenceのベストプラクティスである以下3つの実装例を示します。
- 依存関係のテレメトリーの実装
- ワークロードの異常が発生した場合のアラート
- プッシュ通知の有効化
本ハンズオンで監視するワークロードのアーキテクチャを紹介します。
右側のEC2インスタンスは外部サービスをエミュレートしたものです。50秒間隔でS3バケットにデータを書き込みます。
真ん中のS3バケットはイベント通知機能を有効にしています。バケットにデータが書き込まれると、通知を受け取るよう設定しています。
左側のLambda関数はS3バケットの通知を受け取ったら実行するよう設定しています。
1.1 Log into the AWS console
AWS管理コンソールにログインしてください。
1.2 Deploy the infrastructure using AWS CloudFormation
用意されたCloudFormationテンプレートを使ってハンズオン用スタックを作成します。
必要な部分だけ説明します。
ここからCloudFormationテンプレートをダウンロードしてください。
スタック名は今回はDependency-Monitoring-Labとします。
パラメーターの値は以下の通りに入力します。
AvailabilityZoneはプルダウンからAZを1つ選択してください。
BucketNameはアーキテクチャの際に説明したS3バケットのバケット名を入力します。今回はwa-lab-<あなたの名字>-<日付><時間>とします。
LatestAmiIdはデフォルト値にしてください。
NotificationEmailは依存外部サービス関連の通知を受け取るアクセス可能なメールアドレスを入力してください。
スタックの作成中にNotificationEmailに設定したメールアドレスに確認メールが届きます。
リンクConfirm subscriptionをクリックしてください。
以下のような画面が表示されたら購読設定完了です。
購読解除する際はリンクclick here to unsubscribe.をクリックしてください。
スタックのステータスがCREATE_COMPLETEになったらプロビジョニング成功です。
UNDERSTANDING METRICS
メトリクスとは、監視対象から取得するシステムのパフォーマンスに関するデータセットを指します。
ワークロードは、リクエスト数やエラーコードなどのアプリケーションメトリクス、CPU使用率、メモリ使用率、ディスク使用率などのインフラストラクチャメトリクスなど、様々なメトリクスを出力するよう設計すべきです。
多数のメトリクスを理解することで、監視に適切なメトリクスを選択することができ、ワークロードと依存関係のある外部サービスの可用性やステータスを理解することができます。
今回のハンズオンでは、S3バケットにデータが書き込まれるとLambda関数が実行されます。
Lambda関数に関するメトリクスを理解することで、依存サービスの健全性を判断するための適切なメトリクスが何かを判断することができます。
AWS LambdaはLambda関数を自動的に監視し、Amazon CloudWatchにメトリクスを送信します。
メトリクスにはリクエスト数、リクエスト毎の実行時間、エラーになったリクエスト数などがあります。
また、これらのメトリクスを活用してCloudWatchカスタムアラームを設定し、メトリクスが変化したら自動で応答するよう設定もできます。
LambdaががCloudWatchにデフォルトで送信するメトリクスは以下3種類です。
- 呼び出しメトリクス
- パフォーマンスメトリクス
- 同時実行メトリクス
それぞれどのようなメトリクスを集計するかは公式ドキュメントを参照ください。
また、以下の記事もわかりやすかったです。
また、公式ドキュメントにも記載があったようにデフォルトではありませんが、非同期呼び出しメトリクスという種類もあるのでご留意ください。
さて、今回のハンズオンでは呼び出しメトリクスのInvocationsとErrorsに注目します。
ErrorsはLambda関数の呼び出しでエラーになった回数です。Lambdaランライムで発生した例外や設定誤りによるエラー、タイムアウトなどがあります。
外部サービスに関する問題を特定するのに重要な指標となります。
外部サービスのパフォーマンスが低下していたり、障害でS3にファイルの書き込みができない場合が考えられます。
Lambda関数の実行自体されなくなる可能性があり、Errorsの監視だけではこの状態を検出することは困難です。
InvocationsはLambda関数の呼び出し回数です。外部サービスは50秒に1回S3バケットにファイルを書き込みます。したがって、50秒に1回Lambda関数が呼ばれることになります。
Invocationsを監視することで想定した間隔で外部サービスが稼働しているのか確認することができます。
では、実際に画面の操作に移っていきましょう。
まず、Amazon CloudWatchのダッシュボードに遷移し、左メニューすべてのメトリクスを選択してください。
検索窓にWA-Lab-DataReadFunctionと入力し、エンターキーを押下してください。
検索されたもののうちLambda > リソース別リンクをクリックしてください。
利用可能なLambdaのメトリクスの一覧が表示されます。
メトリクス名Invocationsをチェックすると上のグラフでLambda関数が呼び出された時間と回数を確認することができます。
画面上部にあるCustomボタンをクリックし、Minutesの15を選択してください。
その後、画面中央のグラフ化されたメトリクスタブを選択し、期間を1分に変更してください。
これで、グラフの表示範囲が直近15分間になり、メトリクスの粒度が1分間隔になります。
先ほど説明したようにInvocationsはLambda関数の呼び出し、つまり、S3バケットへのデータの書き込みを表します。
このメトリクスの回数と頻度を監視することで外部サービスの可用性の監視にも繋がります。
CREATE AN ALARM
監視すべきメトリクスを特定したので、メトリクスを監視するアラームを作成し、定義したしきい値に基づいて通知を送信するよう設定します。
CloudWatchアラームで上記実現ができます。CloudWatchアラームは指定した期間にわたりメトリクスを監視し、指定した閾値に対するメトリクスの値に基づいて、指定したアクションを実行します。
アクションにはAmazon SNSによる通知や、EC2アクション（停止、終了、再起動など）、Auto Scaling、Systems Managerの機能実行（Run Commandなど）があります。
では、実際に画面の操作に移っていきましょう。
まず、Amazon CloudWatchのダッシュボードに遷移し、左メニューすべてのアラームを選択してください。
画面右上アラームの作成ボタンをクリックしてください。
メトリクスの選択ボタンをクリックしてください。
検索窓にWA-Lab-DataReadFunctionと入力し、エンターキーを押下してください。
検索されたもののうちLambda > リソース別リンクをクリックしてください。
利用可能なLambdaのメトリクスの一覧が表示されます。
メトリクス名Invocationsをチェックし、右下メトリクスの選択ボタンをクリックしてください。
メトリクスと条件の指定の入力を行います。
まず、メトリクスセクションの入力です。
統計を合計に変更してください。
期間を1分に変更してください。
条件セクションの入力です。
しきい値の種類は静的を選択してください。
Invocations が次の時...はより低いを選択してください。
... よりもの部分は1分毎にLambda関数が呼び出される最小回数を入力します。つまり、1を入力してください。
その他の設定をクリックし、展開してください。
アラームを実行するデータポイントはメトリクスのN個のデータポイントのうちM個がしきい値を超えた場合に、アラーム状態に遷移するための設定です。
今回はN、Mともの1を設定します。つまり、1 / 1と入力してください。
欠落データの処理は欠損データを不正(しきい値を超えている)として処理を選択します。
入力が終わったら画面最下部の次へボタンをクリックしてください。
アクションの設定の入力を行います。
通知セクションの入力です。
アラーム状態トリガーはアラーム状態を選択してください。
次の SNS トピックに通知を送信は既存の SNS トピックを選択を選択してください。
通知の送信先の入力欄をクリックすると、入力候補のSNSトピック名が表示されます。WA-Lab-Dependency-Notificationを入力してください。
E メール (エンドポイント)に表示されているメールアドレスがCloudFormationスタック作成時に入力したものと同一であることを確認してください。
入力が終わったら画面最下部の次へボタンをクリックしてください。
名前と説明を追加の入力を行います。
名前と説明セクションの入力です。
アラーム名は今回WA-Lab-Dependency-Alarmとします。
入力が終わったら画面最下部の次へボタンをクリックしてください。
プレビューと作成で入力内容を確認したら、画面最下部のアラームの作成ボタンをクリックしてください。
アラームが作成されるとCloudWatchのすべてのアラーム画面に戻ります。
一覧に先ほど作成したアラームが表示されています。
作成したばかりだとアラーム条件を判定するためのデータが足りないため状態の値がデータ不足になっているのでデータが集まるまで数分待機します。
データが収集されると状態がOKに変わります。
名前のアラーム名リンクをクリックしてください。
アラームの詳細画面に遷移します。
グラフセクションでメトリクスが条件を満たしているかどうかを視覚的に確認することができます。
グラフの赤い線はしきい値を表し、それを下回るとアラーム状態になります。
履歴タブを選択すると、アラームに関する状態の変更の履歴を確認することができます。
CloudWatchアラームでSNS通知が追加されたため、現在のアーキテクチャは以下のようになります。
TEST FAIL CONDITION
外部サービスに障害が発生し、S3バケットにデータが書き込まれなくなった場合、つまり、Lambda関数が呼ばれなくなった場合、通知を送信するアラームを作成しました。実際に通知されるか確認してみます。
外部サービスに障害を発生させる要因としては例えば以下があります。
- IAMロールが変更or削除され、外部サービスにS3バケットへの書き込み権限がなくなった
- S3バケットポリシーが変更され、外部サービスに書き込み権限がなくなった
- S3バケットの設定が変更され、S3イベント通知が削除されたため、Lambdaに通知が送信されなくなった
- 外部サービスにネットワーク関連の問題が発生し、S3バケットへ書き込みができなくなっている
今回は最後の例を再現します。
サブネットルートテーブルからデフォルトルートを削除し、EC2上で実行されている外部サービスがインターネットに到達できなくします。
では、実際に画面の操作に移っていきましょう。
まず、VPCのダッシュボードに遷移し、左メニュールートテーブルを選択してください。
ルートテーブルWA-Lab-RouteTableをチェックし、ルートタブを選択して、ルートを編集ボタンをクリックしてください。
送信先が0.0.0.0/0のルートを削除ボタンをクリックし、削除します。
そして、変更を保存ボタンをクリックしてください。
以上の操作により、EC2上で実行されている外部サービスはインターネットに到達できなくなったため、S3バケットにデータを書き込むことができなくなりました。
アラームの状態と通知が送信されるかを確認します。
Amazon CloudWatchのダッシュボードに遷移し、左メニューすべてのアラームを選択してください。
アラームWA-Lab-Dependency-Alarmのリンクをクリックしてください。
設定変更してから数分待つとアラームの状態がOKからアラーム状態に変更されます。
履歴タブを選択すると、状態の更新イベントが発生し、アクションとしてSNSの通知が送信されたことがわかります。
同時にSNSトピックの購読者に通知メールが送信されます。
通知メールには状態変更の理由など詳細な情報が記載されています。
外部サービスが障害から復旧したことを再現するため、先ほどサブネットルートテーブルから削除したインターネットゲートウェイへのデフォルトルートを復活させましょう。
数分するとグラフのステータスがアラーム状態からOKに変更されます。
履歴タブを選択すると、状態の更新イベントが発生したことがわかります。
BONUS CONTENT
CloudWatchメトリクスとCloudWatchアラームによって依存関係となっている外部サービスのモニタリングをすることができました。
通知により、関係者に問題を警告することはできるようになりましたが、このようなイベントを追跡することで問題解決をより確実なものにすることができます。
これはSystems Manager OpsCenterを活用することで実現できます。
OpsCenterは運用上の課題、問題をOpsItemという単位で管理し、追跡し、現在のステータスを迅速に把握することができます。
CloudWatchアラームで、通知と同時にOpsItemを自動作成するように設定してみます。OpsItemはLambda関数で作成します。
設定後のアーキテクチャは以下になります。
では、実際に画面の操作に移っていきましょう。
まず、Amazon SNSのダッシュボードに遷移し、左メニュートピックを選択してください。
トピックWA-Lab-Dependency-Notificationリンクをクリックしてください。
サブスクリプションタブを選択し、サブスクリプションの作成ボタンをクリックしてください。
詳細セクションの入力です。
トピックARNはデフォルト値で構いません。
プロトコルはAWS Lambdaを選択してください。
エンドポイントはCloudFormationスタックの出力に表示されているキーOpsItemFunctionの値を指定してください。
入力し終えたら、画面最下部のサブスクリプションの作成ボタンをクリックしてください。
Lambdaが自動実行されるか確認するためにCloudWatchアラームの状態をアラート状態にします。前章で実施したようにサブネットルートテーブルからインターネットゲートウェイへのデフォルトルートを削除してください。
数分すると通知メールが送信されるのと同時にSystems Manager OpsCenterにOpsItemが作成されます。
作成されたIDリンクをクリックしてください。
OpsItemの詳細画面に遷移します。
OpsItemの詳細をクリックするとタイトル、重要度、ステータスなど確認ができます。
関連リソースセクションでは、問題に関連するAWSリソースを確認することができます。
ランブックセクションでは、作成済みのRunbookを実行し、修復を自動化することができます。
TEAR DOWN THIS LAB
削除するリソースの箇条書き
- CloudWatchアラーム
- Systems Manager OpsCenterのOpsItem
- CloudFormationスタック
- S3バケット（
cf-templates-から始まるバケット） - SNSサブスクリプション
詳細は以下を参照ください。