はじめに
現在はAWSで構築されたシステムの運用保守業務に携わっており、その一環として障害調査を行うことが多々あります。
少しは経験値が上がったため、障害が発生した際に初動で確認する事項をまとめてみました。
インフラ基盤観点で障害調査を行うさいの参考になれば幸いです。
前提条件
当システムの構成は以下となっているため、それに即した調査項目となっています。
- ALB/NLB・ECS・RDSを利用している
- ECSはEC2上で実行している（Fargateでは利用していない）
- ECSクラスター（以下クラスター）の自動スケーリング設定をしている
- ECS サービス（以下サービス）の自動スケーリング設定をしている
- RDSはAuroraを利用している
また、障害は予期せぬコンテナの停止を想定しています。
NLB/ALBの調査事項
メトリクス
初めにロードバランサーのメトリクスからターゲットの状態を確認します。
扱っているシステムでは、HealthyHostCountメトリクスを利用してターゲットであるコンテナの死活監視をしています。
HealthyHostCountの閾値を下回ることによりアラートがなるので、まずは下記メトリクスを確認して異常なコンテナがあるか確認をします。
| メトリクス名 | 統計値 | 単位 | 詳細 | 確認観点 |
|---|---|---|---|---|
| HealthyHostCount | 最小 | ターゲットグループ | 正常とみなされる （ヘルスチェックに成功した） ターゲットの数。 |
正常なコンテナ数 |
| UnHealthyHostCount | 最大 | ターゲットグループ | 異常とみなされる （ヘルスチェックに失敗した） ターゲットの数。 |
異常なコンテナがあるか |
確認観点
基本的にヘルスチェックに失敗するとHealthyHostCountメトリクスが下がり、UnHealthyHostCountメトリクスが1以上になります。そして異常なコンテナは停止し、新しいコンテナが起動します。
しかし、ロードバランサーの挙動によりどちらかのメトリクスのみに変化が見られる場合や、必ずしもコンテナの入れ替わりが発生しない場合もあるので注意です。
場合分けを行い、わかる範囲で事象が発生する可能性についても記載しています。
| 項目 | 事象 | 事象発生の可能性 |
|---|---|---|
| 1 | HealthyHostCountの減少 かつ UnHealthyHostCountの上昇 |
ほぼ確でコンテナに異常が発生 かつ コンテナの入れ替わりも発生している |
| 2 | HealthyHostCount減少のみ | AWSの誤検知 または B/Gデプロイ （ターゲットの切り替えのさいに一時的に0になる） または EC2のリソース不足※ |
| 3 | UnHealthyHostCount上昇のみ | AWSの誤検知 または ロードバランサーの入れ替え（主にALB） または ロードバランサーのスケーリング |
2.3のB/Gデプロイ以外の要因はユーザ側ではわからないので、AWSに問い合わせを実施します。
アラームの設定について
アラーム設定はHealthyHostCountの個数の閾値を設定して、その閾値を下回った場合にしています。
その場合だとB/Gデプロイ時に条件に引っかかってしまうため、以前HealthyHostCountとUnHealthyHostCountをand条件でアラートとして設定する検討をしました。しかしその際は"HealthyHostCount減少のみ"に検知できるEC2のリソース不足によるコンテナの起動失敗を検知できなくなるため断念しました。
この場合EC2のリソース不足とは、土台となるEC2にコンテナが新規に起動するためのCPUやメモリが不足した状態をさします。
ECSの調査事項
次はECS関連の調査です。
サービス単位とクラスター単位でそれぞれ調査を行います。
サービス単位の調査
メトリクス
サービス単位で確認するメトリクスは以下です。
| メトリクス名 | 統計値 | 詳細 | 確認観点 |
|---|---|---|---|
| RunningTaskCount | 最大 | RUNNING 状態にある タスクの数 |
タスクの増減 |
| CpuUtilized※ | 最大 | リソースのタスクにより 使用されている CPUユニット数 |
負荷状況 |
| MemoryUtilized※ | 最大 | リソースのタスクにより 使用されているメモリ |
負荷状況 |
| CPUUtilization※ | 最大 | サービスで使用されている CPUの割合 |
負荷状況 |
| MemoryUtilization※ | 最大 | サービスで使用されている メモリの割合 |
負荷状況 |
タスク定義による予約について
タスク定義で事前に利用するタスクのCPUやメモリの予約の設定ができます。
EC2からあらかじめ最低限の利用分としてリソースを確保してくれるイメージです。
設定分しかCPUやメモリが使えないわけではなく、土台となるEC2に余力があれば予約以上のCPUやメモリを使うことができます
また設定しなければコンテナが利用できないわけではありません。
ですが、非常に大事な値なので適切に設定する方がよいです。
理由はいくつかあるのですが、今回の内容に即したものを紹介します。
予約をもとにしているメトリクスが参照できなくなる
上記に記載した CpuUtilized・MemoryUtilized メトリクス に関しては、それぞれCPU・メモリ予約をしていないとメトリクスを収集することができません。
また、CPUUtilization・MemoryUtilization メトリクス に関しては、サービスに属するタスクによって使用されている CPU ユニットの合計を、サービスに属するタスク用に予約されている CPU ユニットの合計で割った数で計算されているため、予約値によっては出鱈目な値となってしまいます。
メトリクス以外にも予約の値を参照して取得している数値が多数あるので、タスク定義の予約は適切に設定するのがよいです。
CPUUtilization・MemoryUtilizationについて
CPUUtilization・MemoryUtilization メトリクスは、スパイクが発生すると数値100％を超えることが多々あります。
しかし、"100％を超える=コンテナが処理落ちする"かというとそうではありません。
上記でも記載したように、メトリクスの値はタスク定義の予約値をもとに計算されており、実際はEC2に余裕があれば予約値以上のCPUやメモリを利用することができるため、100％以上の負荷でもある程度耐えることができます。
ログ
サービス単位で確認するログは以下です。
サービスのイベントログ
コンソールでは、[サービス] > [イベント]で確認することができ、以下情報を取集します。
- タスクの増減が発生しているか
- タスクが増減した時間
- タスクが増減した理由
クラスター単位の調査
メトリクス
クラスター単位で確認するメトリクスは以下です。
| メトリクス名 | 統計値 | 詳細 | 確認観点 |
|---|---|---|---|
| ContainerInstanceCount | 最大 | クラスターに 登録されている Amazon ECS エージェント を実行している EC2 インスタンスの数 |
オートスケールが 発生しているか |
| CPUUtilization | 最大 | クラスターで 使用されている CPUの割合 |
CPU不足に なっていないか |
| MemoryUtilization | 最大 | クラスターで 使用されている メモリの割合 |
メモリ不足に なっていないか |
| CpuReserved | 最大 | クラスターで タスクを実行することを 予約されているCPUの割合 |
CPU不足に なっていないか |
| MemoryReserved | 最大 | クラスターで タスクを実行することを 予約されているメモリの割合 |
メモリ不足に なっていないか |
Container Insights
Container Insights を有効化することで、通常提供されているメトリクスよりもさらに詳細なコンテナに関する情報を収集することができます。
追加料金はかかりますが金額以上の価値があるため絶対に有効化した方がよいです！
（上記で紹介しているメトリクスの中にもContainer Insightsによって収集しているものがあります）
EC2の調査事項
次は土台となるEC2（コンテナインスタンス）の調査です。
クラスターの調査と似た部分もありますが、インスタンス単位で調査することでわかることもあり、どちらも確認が必要です。
また特定のインスタンスに異常があった場合は、AWSの基盤の問題の可能性もあります。
メトリクス
確認するメトリクスは以下です。
| メトリクス名 | 統計値 | 詳細 | 確認観点 |
|---|---|---|---|
| CPUUtilization | 最大 | インスタンスを実行するために 使用する物理 CPU 時間の割合 |
CPU不足に なっていないか |
| NetworkIn | 最大/ 最小 |
ネットワークインターフェイスを通じ このインスタンスによって 受信されたバイトの数 |
負荷状況 |
| NetworkOut | 最大/ 最小 |
ネットワークインターフェイスを通じ このインスタンスから 送信されたバイトの数 |
負荷状況 |
CPUUtilizationの違い
クラスターとEC2ではCPUUtilizationの計算方法が異なります。
ちょっとした違いですが、知っておくことは大事です。
- クラスター：ECSクラスター内のタスクが使用したCPUユニットの合計を使用
(タスク外で使用されたCPUについては含まれない)
(Total CPU units used by tasks in cluster) x 100
Cluster CPU utilization = ---------------------------------------------------------------
(Total CPU units registered by container instances in cluster)
- EC2：インスタンス上で実施されているすべてのCPUユニットの合計を使用
（OS等のCPUも含まれる)
ログ
以下ログを確認します。
AutoScalingのアクティビティ
コンソールでは、[AutoScaling] > [アクティビティ]で確認することができ、以下情報を取集します。
- インスタンスの増減が発生しているか
- インスタンスが増減した時間
- インスタンスが増減した理由
コンテナインスタンスの数はContainerInstanceCount メトリクスでもわかりますが、
詳細な状況を把握するためにAutoScalingのアクティビティまで確認した方がよいです。
ECSログコレクター
コンテナインスタンスのさまざまなログを一括で1つのファイルに圧縮およびアーカイブできます。
ユーザ側で調査を行うときに利用するだけでなく、AWSサポートにコンテナインスタンス関連の問い合わせを行うと、高頻度で採取を求められます。（AWS基盤側で障害が発生していないかの調査にも利用されているっぽいです）
コンテナインスタンス上でスクリプトをダウンロードし実行することで簡単に利用ができます。
RDSの調査事項
最後はRDSの調査です。
メトリクス
確認するメトリクスは以下です。
クラスター・インスタンス単位（特にライターを注視）でそれぞれ確認します。
| メトリクス名 | 統計値 | 詳細 | 確認観点 |
|---|---|---|---|
| CPUUtilization | 最大 | CPU使用率 | CPU不足に なっていないか |
| DatabaseConnections | 合計 | データベースインスタンスへの クライアントネットワーク接続の数 |
上限に 到達して いないか |
| FreeableMemory | 最小 | 使用可能な RAM の容量 | メモリ不足に なっていないか |
| ReadIOPS | 最大 | 1秒あたりのディスク読み取り I/O オペレーションの平均回数 |
負荷状況 |
| WriteIOPS | 最大 | 1秒あたりのディスク書き込み I/O オペレーションの平均回数 |
負荷状況 |
| ReadThroughput | 最大 | 1秒あたりのディスクからの 平均読み取りバイト数 |
負荷状況 |
| WriteThroughput | 最大 | 1秒あたりのディスクへの 平均書き込みバイト数 |
負荷状況 |
Performance insights
データベースパフォーマンスのチューニングとモニタリングを行う機能です。
インスタンス単位でデータベースの負荷をすばやく評価することが可能で、負荷を発生させているSQLステートメントとその理由を簡単に確認することができます。
無料で7日間（最大2年）のパフォーマンス履歴を保存でき、とりあえず有効にするのがおすすめです。
最後に
いかがだったでしょうか？
今回は障害発生時に最低限確認する項目をまとめさせていただきました。
少しでも障害調査を行う助けになれば幸いです。
最後まで読んでくださりありがとうございました！