サービス障害レビュー · 27

一つの棋局エラーが連鎖したサービス回帰を露出させるまで

8月30日、未対応のコミを含む一局が最初にKataGoのパラメータエラーを起こしました。同じ調査で、肥大化したstream完了イベント、登録runtimeの不一致、Tokenの反復作成、旧clientの同期失敗も判明しました。時系列、実測した影響、復旧証拠、残作業を公開します。

1. 最初の可視エラーは20時47分に現れた

   2026年8月30日20時47分、Webの全局検討が整数でも半整数でもないコミをModalへ送りました。KataGoは拒否し、jobはGPU使用時間0ミリ秒で失敗しました。画面にはquery識別子と探索量が残りましたが、取り込んだ棋譜のコミが未対応であることを事前に説明できていませんでした。

2. 30回の失敗は二つの再試行系列だった

   20時47分から21時13分までの記録では、不正なコミが同じuser・同じ一局から5回、応答サイズ超過が別のuserから25回ありました。同じ時間帯にModalは43件を完了しています。二つの障害が自動または手動の再試行で増幅されたのであり、30人が影響を受けたわけでも、解析全体が連続停止したわけでもありません。

3. 不正なコミはprovider呼び出し前に止めるべきだった

   KataGoが受け付けるコミは-400から400までの整数または半整数です。旧経路は不正値をproviderまで運び、内部エラーを見せていました。現在はWeb、REST、streaming入口が一つのvalidation契約を共有し、課金やGPU dispatchの前に明示的なHTTP 400を返します。コミを変えれば解析対象も変わるため、無断で丸めません。

4. 完了イベントがstream全体をもう一度含んでいた

   二つ目はModal streamの障害です。中間イベントで各resultを送った後、完了イベントが全result配列を再添付していました。長い全局検討ではproviderの応答サイズ上限を超えます。現在、resultはstreamのまま、完了イベントはusageなど小さな要約だけです。配備済みproduction Appは64 visitsの検証でresult 1件と完全なusageを返しました。

5. 同じ調査で独立した互換性回帰が三つ見つかった

   登録失敗は不正なコミが原因ではありません。password導出回数がCloudflare Workerのruntime上限を超え、account行の作成前に停止していました。client同期はEdge未対応のredirect modeを使い、一部の旧clientは安定したdevice slotを持たず再接続時にAPI Tokenを増やしました。因果は別ですが、いずれもserver更新と旧clientのrelease契約不足を示します。

6. 復旧は主経路とfallbackを別々に確認した

   8月31日15時54分に互換性修正をCloudflareへ反映し、16時15分にはREST fallbackが常にRunPod streamを読み、terminal outputが無い場合もresultを再構成するようにしました。その後Modal Fastを再配備しました。16時18分、NVIDIA L4上のproduction RPCはresult 1件、70 visitsを返しました。Worker更新後には新しい登録成功行も確認できました。

7. 今後のreleaseには一枚の互換性matrixが必要になる

   release gateはWeb、新旧native client、REST、WSS、登録、自動Token rotation、Modal stream、RunPod fallbackを覆い、長い棋譜の応答サイズも試験します。登録にはdatabase書き込み前のprivacy-safe eventを追加し、「account記録なし」と「requestなし」を区別します。今回、新しいfrontend source mapは未uploadで、serviceには影響しませんがsymbolicationが遅れるため、release credential確認もfollow-upに含めます。