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

0

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のリソースの問題」かどうか切り分ける方法がございましたら、
お手数ですが、ご教示いただけますと幸いです。

질문됨 일 년 전354회 조회
1개 답변
0
수락된 답변

ログがないので推測ですが、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/

fumix
답변함 일 년 전
  • ご回答ありがとうございます。 EC2には、Dockerインストール・コンテナ構築のみで、 コンテナエージェントは入れておりません。 現在の構成では、切り分けするための材料が少ないようですね。。

    頂いたコメントにもあるように、EC2内のコンテナはユーザが管理すべき所ですが、 そこに手が回っていないのが問題かもしれないです。

    今後以下の対応を考えておりますが、 「これもやった方が良い」などあれば、大変お手数ですがご教示頂けると助かります。

    ・ALBヘルスチェック監視 ・ログを外部へ保存(CloudWatchLogsやS3)

    将来的には運用負担の少ないFargateなども考えてみます。 情報が少ない中、ご回答いただきありがとうございました。勉強になりました。

로그인하지 않았습니다. 로그인해야 답변을 게시할 수 있습니다.

좋은 답변은 질문에 명확하게 답하고 건설적인 피드백을 제공하며 질문자의 전문적인 성장을 장려합니다.

질문 답변하기에 대한 가이드라인

관련 콘텐츠