エラーリカバリー：大規模環境におけるグレースフル・デグラデーション

SchemaBridge Team · 2026-01-16 · Resilience, Error Handling, Fault Tolerance

大規模環境におけるリトライとバックオフの扱い方。マネージドなレジリエンスが「リトライストーム」をどう防ぐか。

「リトライストーム」：なぜ素朴なエラーハンドリングは失敗するのか

分散システムの黎明期において、「エラーハンドリング」とは通常、コードの一部をtry/catchで包み、さらに単純なwhileループを追加して3回リトライする、という程度のものでした。これは、障害が稀で局所的な、小規模かつ隔離された環境では機能します。しかし、相互接続されたマイクロサービスのメッシュの中で規模が大きくなると、素朴なリトライはリトライストーム（あるいは「サンダリングハード」）と呼ばれるシステム全体のメルトダウンへの処方箋となってしまいます。

ブラックフライデーのセール中、高負荷によってプライマリデータベースがわずかにもたつくシナリオを想像してください。クエリのレイテンシは10msから1100msへと増加します。あなたのAPIには標準の1秒タイムアウトが設定されています。突然、1,000の並行ワーカーが一斉にこのタイムアウトに達します。彼らは全員エラーをキャッチし、単純なループのロジックに従って、即座にクエリをリトライします。

すると、すでに最初の1,000リクエストの処理に苦戦していたデータベースに、今度はさらに1,000リクエストが一気に襲いかかります。負荷は瞬時に倍増します。データベースのCPUは100%に張り付き、レイテンシは5秒まで増加します。ワーカーは再び失敗し、再びリトライします。システムは失敗の正のフィードバックループに陥ります。あなたは事実上、自社のインフラに対してDDoS攻撃を仕掛けたことになります。軽微なパフォーマンス低下を、システム全体の停止へと変えてしまったのです。

失敗を受け入れる：エラーはAPIの一部である

SchemaBridgeでは、エラーは「例外的なもの」であるという発想から距離を置いています。イベント駆動の世界では、失敗は成功と同じくらいありふれたものです。ネットワークは分断され、Podは不安定に振る舞い、サードパーティのAPIにはメンテナンスウィンドウがあります。私たちはエラーリカバリーを、コード内のcatchブロックとしてではなく、インフラにおけるマネージドなライフサイクルとして扱います。

エラー分類マトリクス

効果的にリカバリーするには、まず何かが失敗した理由を理解する必要があります。すべてのエラーが等しく扱えるわけではありません。SchemaBridgeはエラーを3つの明確なカテゴリーに分類し、それぞれに固有のリカバリー戦略を割り当てています。

| :--- | :--- | :--- | :--- |

エラーをゲートウェイレベルで分類することで、エンジンが「パスワード誤り」のようなエラー（決して成功しない）を盲目的にリトライしてしまうことを防ぎつつ、「ネットワークの瞬断」（100msで成功する可能性が高い）には積極的に対処することができます。

永続的リトライの解剖学：バックオフの数学

頂点が一過性のエラーで失敗した場合、SchemaBridgeはエンジンレベルで強制される高度なバックオフ戦略を採用します。

指数バックオフ：システムを冷やす

1秒ごとにリトライする代わりに、待機時間を指数関数的に増加させます。

$$Wait = Base \times 2^{Attempt}$$

試行1回目：1秒待機
試行2回目：2秒待機
試行3回目：4秒待機
試行4回目：8秒待機

このシンプルな数学的な進行によって、失敗しているサービスへの負荷は時間とともに急速に減少していきます。サービスが1分間ダウンしていたとしても、何百ものリクエストで叩かれ続けることはなく、細く絞られたリクエストしか受け取らないようになります。

段階的ロールバック：デプロイにおける安全性

リトライが無意味な場合もあります。デプロイがバグを持ち込んだ場合、どれだけリトライしても解決しません。ロールバックが必要です。

SchemaBridgeは自動ロールバック付きの段階的なダイヤルアップをサポートしています。新しいワークフローをデプロイする際や、インフラ設定を変更する際、私たちのgradual_deployシステムが新しいインスタンスの健全性を監視します。

フェーズ1：トラフィックの1%が新バージョンへ、99%が旧バージョンへとルーティングされます。
ヘルスチェック：新バージョンのエラー率が閾値を超えた場合、システムは自動的にロールバックをトリガーし、トラフィックの100%を安定版へと戻します。

これにより、不良なコード（あるいは不良な設定）がフリート全体をダウンさせることは決してないという保証が得られます。

人間参加型のリカバリー：「マニュアルゲート」戦略

いくつかの失敗には、ループではなく脳が必要です。手動の銀行照合が請求書金額と$0.01だけ一致しなかったためにワークフローが失敗した場合、どれだけコードを書いても、あるいは書くべきでも、何をすべきかを決定することはできません。

SchemaBridgeのワークフローはホールト状態に入ることができます。

可視性：ワークフローは運用ダッシュボード上で赤くフラグ表示されます。
フォレンジック：オペレーターは正確な変数の値とエラーメッセージ（例：「不一致：100.00 vs 100.01」）を確認できます。
介入：オペレーターは手動で状態を編集し（例：承認済み金額を更新する）、「この頂点から再開」をクリックできます。

エンジンは修正された状態をリハイドレートし、ジャーニーを継続します。これにより「エラー」は、パニックやデータベースへの直接いじりの原因から、標準的な運用ワークフローへと変わります。

ケーススタディ：6時間の決済ゲートウェイ障害を乗り切る

私たちは、毎晩深夜に$10Mの更新処理を行うサブスクリプション型SaaS企業と協業しました。ある夜、彼らのプライマリ決済ゲートウェイがUS-Eastリージョンで6時間に及ぶ大規模な障害を起こしました。

従来の方法（SchemaBridge導入前）

彼らのレガシーシステムは単純なcronジョブを使用していました。ゲートウェイがダウンすると、cronジョブは3回リトライした後、サブスクリプションを「失敗／支払い拒否」としてマークしました。エンジニアが朝6時に目を覚ました頃には、システムが支払いを処理できないと誤って判断したことにより、5万件の顧客アカウントが無効化されていました。サポートキューは大惨事となり、ユーザーが「アカウント解約」のメールを受け取ったことで解約率が急上昇しました。

SchemaBridgeによる方法

彼らは最近、課金エンジンをSchemaBridgeに移行していました。

1. 自動バックオフ：ゲートウェイから503エラーが届き始めると、エンジンは自動的に指数バックオフへと移行しました。

2. グレースフルなリカバリー：6時間後にゲートウェイがオンラインに復帰すると、エンジンは自然な形で5万件のワークフローの滞留を、その後の1時間かけて「はけさせ」ました。

結果

誤って無効化された顧客は一人もいませんでした。誤ったメールも一切送信されませんでした。カスタマーサポートチームは、翌朝レポートを見るまで障害が発生していたことにすら気づきませんでした。これこそがレジリエンスのビジネス価値です。

耐障害性設計のためのエキスパートチェックリスト

真に「破壊不可能」なシステムを構築するには、次のヒューリスティクスに従ってください。

1. すべての書き込みに対する補償を定義する：レコードを作成するなら、失敗時にそれを削除またはアーカイブする計画を持ってください。対称性こそが一貫性の鍵です。

2. すべてのリトライにジッターを使う：サンダリングハードがリカバリーを台無しにするのを防いでください。ランダム性はあなたの味方です。

3. ホールト状態を受け入れる：ロジックが行き詰まったときに人間の助けを求めることを恐れないでください。「一時停止」したワークフローは「壊れた」ワークフローよりもましです。

4. エラーパスを監査する：私たちはしばしば「ハッピーパス」をテストする一方で「失敗パス」を無視しがちです。SchemaBridgeの「カオス・インジェクター」を使って、ステージング環境でサーガをビジュアルに検証してください。

結論：失敗はレジリエンスの機会である

エラーリカバリーとは、バグを防ぐことではなく、災害を防ぐことです。エラーハンドリングを、脆いコードブロックの寄せ集めから、マネージドで永続的なライフサイクルへと変えることで、あなたは「リトライストーム」を恐れることなく複雑なインテグレーションを構築する自由を手にします。「脆弱（Fragile）」から「反脆弱（Anti-Fragile）」へと移行するのです。

第11回では「インフラストラクチャ・アズ・ワークフロー」の世界を探求し、ビジュアルなロジックを用いてクラウドリソースを管理する方法を見ていきます。