障害時の一般的な切り分け方法について（EC2上のDockerコンテナ＋RDS）

Question

Webアプリケーションを、EC2上のDockerコンテナ＋RDSで動かしておりますが、  
障害時の一般的な切り分け方法を教えていただけないでしょうか。

先日、Webアプリにアクセスすると「504」エラーとなる障害が発生しました。  
復旧作業を優先し、EC2再起動にて復旧しておりますが、  
「AWSリソースの問題」か「Docker環境の問題」か切り分けができておりません。  
  
原因調査ではALBログやEC2の状況を一通り確認いたしました。  
    
**①AWSリソースの確認**  
＜Service Health Dashboard＞  
・使用しているリソースの障害情報はなかった  
  
＜ALBのアクセスログ＞  
・ALBとEC2間の接続を確認  
　⇒ALBからのリクエストに対して、EC2から応答を返さなかったことが分かった  
  
＜EC2ステータスチェック＞  
ステータスチェックのメトリクスはどちらも「0」で異常はなし  
・StatusCheckFailed_System  
・StatusCheckFailed_Instance  
   
**②EC2 Docker環境の確認**  
＜Dockerコンテナのログ＞    
・PHPやNginx、postgresログはEC2再起動により削除されたため未確認

※補足※  
構成について  
・ALBで受信したHTTPリクエストを、ターゲットグループ(EC2)へ振り分ける  
・EC2に構築済みのDocker環境でWebサーバ(Nginx)／アプリサーバ(Laravel)／DBサーバ（postgresql）が動いている  
・コンテナからRDS for postgresqlに接続している

コンテナのログが確認できればもう少し手掛かりが掴めていたと考えますが、現状それができない状態です。  
もし上記以外で、「AWSのリソースの問題」かどうか切り分ける方法がございましたら、  
お手数ですが、ご教示いただけますと幸いです。

fumix · Accepted Answer

ログがないので推測ですが、EC2上で動作しているコンテナエージェント周りのエラーが原因の可能性があります。（私も以前ECSを利用していた際に、リソースを枯渇させてエラーになったことがあります）
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ECS_agent.html

このエージェントは、EC2のOSより上位階層は責任共有モデルで利用者の責任範囲ですので、メンテナンス、セキュリティアップデートなどは自分たちで管理する必要があります。

もし上記が原因であれば、Fargateを利用することで、エージェント管理責任がAWSになるため、簡単に問題を解決出来ます。

それから、EC2内にログを保存するのはよくありません。ログをCloudWatch Logsに転送することを強くオススメします。タスク定義の設定で簡単に転送できますので、下記ブログを参考にお試しください。
https://dev.classmethod.jp/articles/ecs-cloudwatch-logs/

障害時の一般的な切り分け方法について（EC2上のDockerコンテナ＋RDS）

Relevanter Inhalt