Circuit Breaker・Dead Letter Queue：障害の連鎖を防ぐ2つの仕組み
約12分developer-tools
#サーキットブレーカー#デッドレターキュー#シンボリックリンク#デーモン#ソケット#AIコーディングツール#用語辞典
※ 編集方針：以下の業務状況および登場人物は、用語の理解を助けるための架空のシナリオです。実際の著者の経験や特定の企業で起きた事象を再現したものではありません。
1つのレコメンドサービスが遅延したことで、他のサービスのレスポンスまで引きずられて遅くなる障害状況を想定してみましょう。
ログ全体を改めて見直していると、不思議なことに、レコメンドサービスを呼び出していた他のサービスが、ある時点からレコメンドサービスを一切呼び出さなくなっていることに気づきました。
遅延していたサービスを、突然誰も呼び出さなくなったとき：サーキットブレーカー
text
1[circuit-breaker] recommend-service: OPEN2Calls to recommend-service are now short-circuited
ログに出力された
OPEN という状態値をもう一度見直したことで、理由が分かりました。失敗率が一定の水準を超えたため、他のサービスがレコメンドサービスを呼び出すのを止め、即座に失敗として処理するように自ら遮断していたのです。故障した回路に電流を流し続けると火災につながるためブレーカーを落とすように、失敗が繰り返される場所には最初からリクエストを送らないよう、回路自体を遮断する装置でした。おかげで、1つのレコメンドサービスの事例における担当者が、全体へ広がることは防げました。
回路が遮断されている間に処理されなかったメッセージがどこへ行くのか気になり、ちょうど隣の席にいた同僚に尋ねてみました。
処理できなかったメッセージが消えずに残るとき：デッドレターキュー
同僚が画面を見せながら説明してくれました。「それ、消えたわけじゃないよ。ここに別に溜まってるんだ。」
text
1dead-letter-queue: recommend-events2 pending: 1,204 messages
正常に処理できなかったメッセージをそのまま破棄する代わりに、後で再確認できるように別途集めておく待機列（キュー）でした。名前だけを見ると完全に機能しなくなったメールボックスのようですが、実際には後から人が開いて再処理したり、原因を調査したりできる保管箱に近いものでした。ここに1,204件が溜まっており、サーキット（回路）が閉じたら再処理することにしました。
メッセージの問題を整理した後、デプロイ設定ドキュメントを読み返していると、以前から気になっていた表示を目にしました。
1つのファイルが別の場所を指し示しているだけであるとき：シンボリックリンク
bash
1$ ls -l /app/current2current -> /app/releases/v482
公式文書を調べてみると、
-> マークが付いているファイルは実担当者のファイルではなく、別の場所を指し示す名札のようなものであることがわかりました。実担当者の中身は別の場所にあり、このファイルは単にその場所を指すショートカットでした。デプロイのたびに新しいバージョンのフォルダを丸ごと作成し、
current という名札だけを新しいフォルダ側に付け替える方法で、デプロイを瞬時に切り替えていました。
デプロイ方式を理解したところで、今度はサーバー上で常に起動しているプロセスが何をしているのか気になりました。
ログインしたこともないのに動き続けているプロセス：デーモン
同僚が以前サーバーに設置しておいたスクリプトを調べてみると、このプロセスがシステム起動時に自動で実行されるよう設定されているのを発見しました。
誰かがログインして実行したものではなく、バックグラウンドで静かに動き続け、決められたタスクを処理する常駐プロセスでした。ログの整理、ヘルスチェックへの応答、キューの処理といった仕事が、すべてこの方式で目立たないように実行されていました。
ほぼすべて片付いたと思った矢先、深夜3時を過ぎた頃に、全く異なる種類のエラーがもう一つ発生しました。
接続が突然途絶えたとき：枯渇していたソケット
text
1Error: EMFILE, too many open sockets
エラーメッセージ自体が原因を物語っていました。サーバー間でデータをやり取りする一つひとつの通信経路がソケットですが、先ほど回路が遮断と接続を繰り返していた間に、この経路が適切に閉じられないまま溜まり続けていたのです。
電話が終わったら受話器を置かないと次の電話を受けられないように、接続を使い終わっても適切に閉じなければ、新しい接続を確立するための経路自体が枯渇してしまいます。残った接続を整理するスクリプトを実行してようやく、サーバーは再び安定を取り戻しました。
ドミノ倒しのように続いていた遅延は、残った接続を整理してようやく収まりました。1つのサービスが停止した際に隣のサービスまで引きずられたのは、密接につながっていたからではなく、倒れかかる方を支える装置が途中に存在しなかったからでした。
よくある質問
サーキットブレーカーが「オープン」になると、ユーザーはどうなりますか？
該当する機能のみ一時的に利用できなくなりますが、サービス全体が停止するよりははるかにマシです。レコメンドリストの代わりにデフォルトのリストを表示するなど、代替レスポンスを用意しておくことで、ユーザーの受ける不便を軽減できます.
デッドレターキューに溜まったメッセージは自動的に再処理されますか？
設定によって異なります。自動で数回再試行するように設定することもあれば、人間が直接確認して再処理するかどうかを判断できるように残しておくケースも多いです。
ソケットの枯渇はなぜ突然深夜に発生したのですか？
普段は接続がすぐにクローズされるため目立ちませんが、障害によって再試行が繰り返されたことで、クローズされなかった接続が短時間に集中して蓄積されたためです。通常よりも何倍もの接続が同時に開かれた状態になっていたことになります。
前回の記事 · 第7話：障害対応の夜、アラートが鳴る前に裏で起きていたこと
AIコーディングツール用語辞典シリーズの第8話です。次回予告 · 第9話：セキュリティチームからAI機能の点検を要請された日（ガードレール・プロンプトインジェクション・サンドボックス脱出・ポート/ローカルホスト・スタッシュ）
参考・根拠
関連記事
サブエージェント・フック・スラッシュコマンド：AIコーディングツールでよく使われる拡張概念
AIコーディングツールの使用中に出会う「サブエージェント」「フック」「スラッシュコマンド」を、架空の業務シナリオを交えて分かりやすく解説します。
パーミッションプロンプト・Sandbox・Checkpoint：AIエージェントの実行境界を理解する
AIコーディングツールを使う中で直面するパーミッションプロンプト、サンドボックス、チェックポイントなど5つの用語を、仮想の業務シナリオを通じてわかりやすく解説します。
Kill Switch・Backoff・Runtime：実行を停止し復旧するための基本機能
AIコーディングツールを使っていると遭遇する、キルスイッチ、バックオフ、リポジトリなどの5つの用語を、仮想の業務シナリオを通じてわかりやすく解説します。