要約

  • 10月9日のネットワーク障害と10日のデータベース接続プール障害は別々の事故だが、いずれも共有依存関係を通じて実行を止めた。
  • 内部エラーで失敗した一部の実行はRunningに残り、失敗ハンドラーや結果を待つ親関数に通知されなかった。利用者が取り消すか、再実行する必要があった。

永続実行の価値は、処理が待機したり失敗したりしても、完了済みの進捗を残して再開できる点にある。しかしチェックポイントだけでは運用上の約束は成立しない。実行状態はどこに置かれるのか。どのアカウントが同じ処理キューを共有するのか。内部依存先が故障したとき、状態機械は何を記録するのか。実行が自力で進まなくなったと、誰が知るのか。Inngestが公表した10月9日から11日の障害報告は、こうした境界を具体的に示した。

Inngestの説明では、数日続いた単一の停止ではなく、2つの事故が起きた。10月9日21:05 UTC、あるデータセンター事業者の施設とInngestの他の施設との接続が失われ、外向きのインターネット接続も途絶えた。事業者の暫定説明は、DDoS防御設定の変更時の誤りだった。Inngestは完全な報告書をまだ受け取っていないと記しており、この原因は確定ではない。接続は21:49に復旧した。翌10日には、主データベースの前段にある2つのPgBouncerプールが14:00 UTC、さらに15:30に全接続を失った。大半のアカウントで実行のスケジュールとキュー処理が停滞した。回避策で処理は戻ったものの、特にcron関数で間欠的な遅延が続き、10月11日04:17 UTCに元のプールへスケジュールを戻すまで解消しなかった。ゲートウェイ経路は12日に改善された。障害の仕組みと復旧経路はそれぞれ異なる。

最初の障害は、局所的なネットワーク境界から影響が広がる経路を明らかにした。Inngestによれば、サービスは3つのデータセンターにまたがっている。処理される場所と実行状態が保存される場所は別になることがあり、中央のアカウント・設定データベースと接続プールはさらに別の事業者に置かれていた。拠点間の接続が失われると、そこで処理されるアカウントは設定を取得できず、状態も保存できない。他の拠点で動くアカウントでも、必要な状態が切り離された拠点にあれば進行できない。さらに、失敗した処理が共有イベントパイプラインに大きな滞留を作り、その拠点に直接依存しないアカウントまで遅らせた。専用パイプラインを使うアカウントは影響を受けなかった。直接依存の有無だけでなく、後段の処理経路を共有しているかが障害範囲を決めた。

10日の仕組みは別だった。Inngestは、短いクエリ期限とクライアントによるキャンセルがPgBouncerと相互作用したと説明する。クエリが接続を待っている間に期限が切れると、ドライバーはクライアント接続を閉じる。その後PgBouncerは放棄されたクエリを実行し、接続をプールに戻さず、データベース接続そのものを閉じていた。新しい接続は1つずつしか確立できないため、破棄される方が補充より速くなった。毎時の始まりと終わりにはcron負荷でクエリが約3倍になり、週末前に投入した新しい検索処理も大量に失敗していた。プールを再起動しても安定せず、上限を増やしても接続確立の遅さは変わらなかった。

迂回策は新しい依存経路を加えた。データベース事業者が同じ場所で運用するプールへサービスを移すと、16:10から16:25 UTCに処理は回復した。ただし新経路にはNATゲートウェイがあり、一部接続を無言で破棄した。クエリは失敗するまで最大16分停止し、とくにcronの遅延として見えた。Inngestは11日04:17 UTCにcronスケジュールを元のプールへ戻し、12日にゲートウェイ経路を改善した。回避策はトポロジー変更でもある。ひとつの詰まりを除く一方、別の見えにくいタイムアウト境界を作ることがある。

より深刻な管理上の穴は実行状態にあった。Inngestによると、内部エラーは設定済みの再試行回数を消費した。内部エラーでステップが最終的に失敗しても、一部の実行はFailedにならずRunningに残った。そのためonFailureは起動せず、step.invokeで結果を待つ親関数にも失敗が届かなかった。報告では、その状態の実行は自動では続かず、利用者が取り消すか再実行しなければならなかった。ワーカー群の復旧は、中断された業務処理がすべて終端状態に到達したことを意味しない。

これは通常の再開と、利用者が行う再実行を分けて考える必要がある。Inngestのドキュメントでは、再開時に完了済みステップの結果を再利用し、各ステップを個別に再試行すると説明している。一方、事故報告にある顧客側の再実行はrunの先頭から始まる。完了していたステップも再度動く可能性がある。支払い、メッセージ、書き込みが実際に重複したという証拠はない。しかし再実行前にトレースを調べ、繰り返しが安全か確認する責任は残る。外部サービスが操作を受け付けた後、結果が記録される前に通信が切れれば、再試行は同じ呼び出しを繰り返す可能性がある。Inngestの冪等性ガイドも安定したキーを勧める。チェックポイントはオーケストレーター内部の進捗を保つが、外部作用が必ず一度だけ起きるとは限らない。

Inngestは、接続を待つクエリをクライアントとともにキャンセルしない、内部エラーによる恒久的失敗をFailedとして記録する、状態を読めない間は作業をキューに残し読み取り可能になれば再開する、といった修正を展開済みと説明した。ゲートウェイ経路とステータス更新も改善した。より大きな対策である単一データセンターへの集約は、まだ進行中だった。最終構成や独立した災害復旧策は報告に記載されていない。

出典