サーバー停止の原因について、この記事もChatGPTで作成

IT






サーバー停止原因報告書(k-stone.click)


サーバー停止原因報告書(k-stone.click)

作成日時: 2025-11-06 04:02(JST)
発生日時
2025年11月6日 02:30頃
現象
EC2は「稼働中」表示だが SSH・HTTP ともに不通
監視アラート
HTTP: 000000(無応答)
AWSチェック
2/3 合格(System/Instance OK・Application NG)

原因分析

Dockerデーモン(docker.service)が停止またはハングし、nginx / WordPress / MySQL の各コンテナが同時に停止。OSやAWSホスト異常の痕跡はなく、Docker単体の不調が原因と判断。

根本原因(直接原因)

  • Dockerデーモンの一時停止またはクラッシュ

考えられる誘因:

  • 一時的なメモリ不足(OOM)
  • アップデート時のサービス再起動失敗
  • バックグラウンドジョブや監視ツールによる干渉

再現メカニズム(推定)

  1. Dockerデーモンがクラッシュ/停止
  2. nginx / wordpress / db コンテナが停止
  3. HTTP監視が 000000(無応答)を検出
  4. EC2は稼働中に見えるがアプリ層は停止
  5. インスタンス再起動でDocker復帰 → サービス再稼働

実施した対策

  • systemctl enable docker により Docker 常時起動化
  • systemdサービス(wordpress-stack.service)を作成し、EC2起動時に Compose スタック自動起動
  • 各サービスへ restart: always を付与し、クラッシュ時に自動復旧
  • 権限整備(usermod -aG docker ubuntu)でソケットアクセス安定化
  • 再起動/killテストで自動復旧の動作を確認

現在の状態

  • Dockerデーモン: active (running)
  • WordPress / Nginx / MySQL: 稼働中(再起動後も自動起動を確認)
  • EC2再起動時: systemd によりスタック自動起動
  • 再発リスク: (安定運用中)

最終結論

原因: Dockerデーモン停止(ハングまたはOOM)
対策: systemd + restart: always により完全自動復旧構成を構築
現状: 安定稼働中

※ 本書はインシデント後のヒアリングとログ出力に基づき作成しました。必要に応じて CloudWatch Logs の追加設定や、healthcheck の導入も検討してください。