サーバーダウン調査報告書（2024/02/19）

サーバーダウン調査報告書

目次

1. 今回使う用語
2. 前提
3. 原因
4. 何故サーバーが落ちた？
5. 再発防止策

今回使う用語

• Fargate
  • サーバーレスで、dockerコンテナを簡単かつ効率的にデプロイして、管理できるもの
• タスク
  • dockerコンテナを実行するための単位
    (laravelコンテナとnginxコンテナで1タスクみたいな感じ)
• タスク定義
  • タスクを起動するための定義書
    (CPUとかメモリとかdockerイメージ、アプリ内で使う環境変数とか)
• ECR
  • dockerイメージを管理するレジストリ
    (dockeer hubと同じ)
• パラメータストア
  • 環境変数とか機密情報を管理するAWSのサービス

前提

• 環境変数は全てパラメータストアで管理
• 検証環境のソースコードと本番環境のソースコードが一致していない
• 検証環境と本番環境では参照している環境変数名が異なる
  • 検証ではAAを使ってるが本番ではBBを使ってるみたいな感じ

そうなってしまっている理由
→BTの他のサービスのインフラを構築した時に考慮を忘れていた

原因
ECRのdockerイメージを環境毎（検証用、本番用）に分割していなかった
要するに本番環境に検証用のソースコードが使われていた

何故サーバーが落ちた？
タスク更新のタイミングで検証用のdockerイメージにすり替わった

要するに本番環境に検証用のソースコードが使われていた

ということは検証用のソースコードからはAAという環境変数を参照したいが本番環境にはAAという環境変数が設定されていない
結果ビルドエラーになる

タスク起動から停止までの流れとしては
タスク起動→ビルドエラー→ヘルスチェック失敗→タスク停止→タスク起動...
なのでいつまで立ってもタスクが正常に立ち上がらずサーバーが落ちているという状況になったというのが結論

再発防止策
ECRのdockerイメージを環境毎（検証用、本番用）に分割する
そうすることで、検証環境と本番環境のdockerイメージが混同することを防ぐことができる。