フォーラム

こんにちは。今回のインシデントの根本原因が判明しましたので、各項目について回答いたします。

1. 13:52–14:01 にノードのメンテナンスやドレインはありましたか？なぜ設定時間外に再起動したのですか？ はい。当日 13:38–13:52（UTC）に ap-east-2（AWS）クラスターでノードのローテーションが行われました。複数の基盤ノードが終了（イベントログには「クラウドプロバイダー上にノードが存在しません」と記録）され、同時に新しいノードが起動して引き継ぎました。お客様のアプリと PostgreSQL Pod は、元のノードが削除されたため、新しく追加されたノードに再スケジュールされました。したがって、今回の再起動は設定されている 06:00 の定期再起動とは無関係であり、プラットフォームのノードローテーションによって引き起こされた予期せぬ再スケジュールです。

2. DB の復旧に約 68 分かかったのはなぜですか？aws-cni の IP 割り当て失敗と関係がありますか？ はい、主な原因は 2 つあり、それらは相互に関連しています。

• 新しいノードが参加した直後、aws-cni がネットワーク（ENI/IP プール）を準備しきれていない状態で、再スケジュールされた大量の Pod が同時に流入しました（クラスター内の数十のサービスで同時に「failed to assign an IP address」が発生）。これにより IP 割り当てが滞り、Pod がネットワークを確立できない状態で停止しました。
• 新しいノードは「コールドノード」であり、イメージキャッシュがなかったため、イメージを再取得する必要がありました。PostgreSQL（postgres:18）のイメージ取得には約 1 時間 7 分（待機時間を含む）、アプリのイメージ取得には約 24 分（待機時間を含む）かかりました。この 2 つの待機時間が、中断時間が約 68 分まで長引いた主な原因です。

言い換えれば、これは DB 自体の問題ではなく（ご提供いただいた CPU/メモリのデータからも OOM が発生していないことが確認できます）、「再スケジュール + ネットワーク割り当て + イメージの再取得」という復旧プロセスに時間がかかりすぎたことが原因です。

3. PostgreSQL にプラットフォーム側や誤設定による定期再起動はありますか？ ありません。今回の DB 再起動は、前述のノードローテーションによる Pod の再スケジュール（Pod 名の変更、イメージの再取得）であり、インプレースの定期再起動ではありません。お客様のサービスにはプラットフォーム側の定期再起動設定は存在しないため、無効化する必要はありません。

4. 今後、このようなメンテナンスの事前通知や購読可能なステータスページはありますか？ プラットフォームのイベントはステータスページ（https://status.zeabur.com）で確認できます。現在は RSS フィード（https://status.zeabur.com/feed、RSS リーダーや自動通知に追加可能）を提供しています。また、今回のノードローテーションによる aws-cni の IP 割り当ての滞留、およびコールドノードでのイメージ再取得による復旧遅延の問題をインフラチームに報告しました。ノードローテーション時のドレインと IP プリウォーミングのプロセスを改善し、将来的に同様の状況が発生した際の中断時間を短縮する予定です。

補足アドバイス： 今回の中断の根本原因は、「共有クラスター」のノードがプラットフォームのメンテナンスに伴ってローテーションされ、その結果、お客様の Pod が起動したばかりの新しいノードに強制的に再スケジュールされたことにあります。サービスの接続安定性が重要な場合は、専用サーバー（Dedicated Server） への移行をご検討ください。専用サーバーはシングルテナントの独立したノードであり、共有クラスターの全体的なノードローテーションには含まれないため、このような予期せぬ再スケジュールや復旧の遅延の影響を大幅に軽減できます。また、ノード上にイメージキャッシュが既に存在するため、再起動後の復旧もより高速です。ご興味があれば、適切なスペックの評価をお手伝いいたします。