音声ルーティングシステムのテストを行っている開発者が、障害発生後に次のコールが300秒間別のパスを使用するように強制する、一時的なクアランティン（隔離）機能を導入しました。この調整により、ソフトウェアが同じ故障したルートを繰り返し試行することを防ぎ、連鎖的な障害（カスケード障害）が発生する可能性を低減します。

旧ロジックの問題点

元のルーターは、ワークステーションがビジー状態のとき、単に同じパスを再度試行するという硬直したルールに従っていました。そのパスが失敗し続けても、システムはエラーをログに記録するだけで、動作を変更することはありませんでした。実際には、ソフトウェアが同じ行き止まりをループし続けるため、単一障害点がコールをブロックし続ける原因となっていました。

新しいクアランティン・メカニズム

このアップデートでは、3つの制約が追加されます。

  • 永続的ではない – クアランティン・マーカーは短期間で期限切れになります。
  • グローバルではない – すべてのルートではなく、失敗した特定のパスにのみ適用されます。
  • メモリの制限 – システムは失敗をローカルファイルに記録し、新しいパスでの通信が成功するとその記録を破棄します。

音声通信の試行が失敗すると、ルーターはそのパスに対して「quarantined（隔離済み）」フラグを書き込みます。その後300秒間は、すべての着信リクエストが自動的に代替パスへとリルートされます。別のルートでリクエストが成功した瞬間にフラグはクリアされ、修正措置が必要以上に長く続くことがないようになっています。

メリットとトレードオフ

主な利点はレジリエンス（回復力）の向上です。一時的な不具合によってサービス全体がダウンすることがなくなります。クアランティンを5分間に制限することで、ネットワークに復旧の時間を与えつつ、長期的なサービス停止を回避します。

このアプローチにはリスクも伴います。一時的なネットワークの瞬断がクアランティンを誘発し、コールが最適ではないルートへ強制的に回されることで、レイテンシの増大やコストの上昇を招く可能性があります。もし代替パスも劣化している場合、システムがルート間を頻繁に行き来し、不安定な状態を生み出す恐れもあります。運用者は、リルートが意図的なものか、あるいはより深刻な問題の兆候なのかを判断するために、クアランティン・マーカーを可視化しておく必要があります。

今後の注視事項

  • メトリクス: 300秒という設定が適切かどうかを確認するため、クアランティンの発生頻度と継続時間を監視します。
  • スコープ: 静的なリトライパターンによって影響を受けている他のサービスに対しても、このロジックの適用を検討する可能性があります。
  • 自動化: ユーザーが問題に気づく前に予防保守を促せるよう、特定のパスが繰り返しクアランティン状態になる場合にアラートを送信する仕組みを追加します。

教訓はシンプルです。直近の失敗を記録しないシステムは、変化する環境に適応することができません。失敗の履歴を可視化し、それに対して「一時的に」対処することで、エンジニアは大規模な再設計を待つことなく、音声サービスを円滑に稼働させ続けることができるのです。

出典: dev.to の元の開発者による投稿

ディスカッションに参加する: https://t.me/GyaanSetuAi