【ITニュース解説】Node.js Feature Flag Safety: Kill Switch Control for Marketplace Incidents

システム開発では、特定の機能をオンオフできる「フィーチャーフラグ」という仕組みがよく使われる。この仕組みを活用し、緊急時に特定の機能を停止させるのが「キルスイッチ」だ。Node.jsで構築されたマーケットプレイスの通知サービスを例に、キルスイッチがどのように安全に設計・運用されるべきかを解説する。

キルスイッチの主な目的は、システムに問題が発生した際に、被害の拡大を防ぎ、ユーザーへの影響を最小限に抑えることにある。例えば、マーケットプレイスの通知サービスで、外部のメール送信システムに障害が発生した場合、大量の通知がエラーになったり、繰り返し送信されてユーザーに迷惑をかけたりする可能性がある。このような状況でキルスイッチを発動すれば、それ以上の通知配信を一時的に停止できる。重要なのは、ただ停止するだけでなく、後で正常に回復できるよう、失敗したジョブ（処理）の記録を正確に残しておくことだ。これにより、障害が解消した後に未送信の通知を安全に再処理できる。

キルスイッチを設計する上で、その「停止のタイミング」は非常に重要となる。理想的なのは、システムが外部のサービスに対して実際に情報を送る「アウトバウンドコール」の直前で処理を停止することだ。例えば通知サービスの場合、通知の準備は進めるが、実際にメールやSMSを送信する直前で止める。もし早すぎる段階で停止してしまうと、何が起こっていたかを示す重要な情報（例えば、どの注文の、どの通知が、なぜ失敗したか）が破棄されてしまい、後で再処理する際に困る可能性がある。逆に、停止のタイミングが遅すぎると、すでに外部システムにメッセージが送られてしまい、ユーザーへの重複通知や不要なコスト発生といった「副作用」を防げなくなる。したがって、キルスイッチは、ユーザーへの影響を最小限に抑えつつ、かつ回復に必要な情報を損なわない「最後の安全な地点」で停止するように設計する必要がある。

システム内部でのデータ処理の流れは次のようになる。まず、新しい注文が発生すると、それに伴う「通知ジョブ」が生成される。このジョブは、ワーカー（通知処理を担当するプログラム）に渡される。ワーカーは処理を開始する前に、キルスイッチの状態をまず確認する。もしキルスイッチが有効（機能停止中）であれば、通知の配信を試みずに、そのジョブは「延期された」と記録する。キルスイッチが無効（機能稼働中）であれば、外部システムへの配信を試みる。配信の結果（成功、失敗、再試行など）は、システムの状態を把握するためのメトリクス（数値データ）や構造化されたログとして記録される。オペレーターがキルスイッチを操作する際は、認証された管理画面などを通じて行い、その変更はシステム全体のワーカーに瞬時に伝わる。新しいプログラムをデプロイする必要はなく、実行中のシステムでリアルタイムに機能のオンオフを切り替えられる。

ここで言う「ロールバック」は、データベースを過去の状態に戻したり、すでに発生した事象を無かったことにしたりすることではない。キルスイッチにおけるロールバックとは、将来の通知配信の試みを停止し、すでに何が起こったのかという「正直な記録」を維持することを意味する。

実際の障害発生時のシナリオを具体的に考えてみよう。例えば、午後2時2分に、最初の通知配信がタイムアウトで失敗したとする。この時点では、個別のネットワークの一時的な問題かもしれないため、すぐにアラートを出すのは早計だ。数分後、複数の通知ジョブが同様の再試行可能なエラーを返し始めるが、一方で成功する通知もまだ存在する場合、単一のエラーだけで停止するのは時期尚早かもしれない。しかし、午後2時7分頃には、一定時間内の失敗率が持続的に高くなっていることがシステム監視によって示され、ユーザーへの影響が現実のものとなっていると判断できる状況になった。ここでオペレーターはキルスイッチを有効にし、通知配信を停止する。

キルスイッチが有効になると、すでに処理中の通知は完了するかもしれないが、残りのワーカーは順次「通知延期」を記録し始める。その結果、未処理の通知が蓄積され、システムのキューの深さが増大する。このキューの増加は、サービスが通知を適切に保存しており、作業が失われていないことを示す正常な挙動だ。インシデントが「収束した」と判断されるのは、全てのワーカーがキルスイッチの有効化を認識し、外部への通知送信が完全に停止し、かつ、新たに受け付けられた通知の数と延期された通知の記録数が一致するようになったときだ。後で障害が解消した際には、再処理を開始する。この際、すでに成功したと確認されている通知は除外し、結果が不明な通知については、重複送信にならないよう慎重に検証してから再処理を検討する。単に「ロールバック完了」という漠然としたステータスだけでは不十分で、これらの具体的な状況を観察することが重要となる。

Node.jsでの実装例を見ると、キルスイッチのインターフェースは通知処理のワーカーから分離されている。これは、キルスイッチの管理と通知処理のロジックを独立させるためだ。本番環境では、複数のサーバーからアクセスできる共有ストレージにキルスイッチの状態を保存する。もしキルスイッチの状態を読み取れなかった場合（ストレージ障害など）、通知配信は安全側に倒して「停止（フェイルクローズ）」するように設計する。一時的に通知が遅れることは許容範囲だが、誤って重複した通知を送ってしまうリスクの方が大きいためだ。

システム開発者は、キルスイッチの変更履歴と、個々の通知ジョブの結果を、それぞれ異なる目的で別々に記録する必要がある。キルスイッチの変更記録は、「誰が」「いつ」「なぜ」システム全体の振る舞いを変更したかを把握するために使う。一方、ジョブの結果記録は、個々の通知が「どうなったか」を追跡するために使う。これらを混同せず、目的に応じた適切な情報を記録することが重要だ。また、キルスイッチの状態を更新する際には、他のオペレーターによる同時変更で情報が上書きされることを防ぐため、「リビジョン番号」（バージョンのようなもの）を確認し、確実に最新の状態を更新するように設計する。

このような共有型のキルスイッチには利点と欠点がある。利点は、システム全体で一貫した制御が可能で、即座に反映されることだ。しかし、キルスイッチの状態を保存するストレージが利用できなくなると、通知配信パス自体に新たな依存関係が生じてしまう。この場合も「フェイルクローズ」で配信を延期する選択は、ユーザーへの重複メッセージを防ぐ点で優れている。一方で、プログラムが動作している個々のサーバー内でのみ有効な環境変数を使う方法もある。これは共有ストレージへの依存を回避できるが、変更を反映するにはサーバーの再起動が必要で、システム全体での状態の一貫性を確認しにくいという課題がある。どちらを選ぶかは、チームが共有ストレージの可用性や認証、監査パスをどこまで管理できるかによって判断される。

キルスイッチの発動条件は、単なる「エラーが発生した」という事実だけでなく、「エラーがユーザーに影響を与えているか」という観点で判断することが大切だ。一時的なネットワークの揺らぎによる1回のタイムアウトと、一定期間にわたって多数のジョブで継続的に致命的な失敗が発生している状況は全く異なる。システムでは、通知が「試行された」「送信された」「延期された」「再試行可能な失敗」「致命的な失敗」といった結果を区別して追跡する必要がある。これにより、キルスイッチで停止したワーカーが、単に処理を止めただけで「健全」に見えるような誤解を防ぐ。主要なインシデントの信号は、エラーの発生率とボリュームを組み合わせ、さらにチャネル（メール、SMSなど）や外部サービスごとに分類して監視するべきだ。

キルスイッチの有効化がシステム全体に伝播したかを正確に把握することも重要である。コントロールパネルで「無効化された」と表示されていても、もし半数のワーカーが古い状態のまま動作しているなら、それは十分な証拠とは言えない。ワーカーが現在参照しているキルスイッチのリビジョン番号（バージョン）を、処理結果とともに記録し、システム全体のワーカーが最新のリビジョンを参照しているかを監視する必要がある。

キルスイッチで停止した機能を再開する際も、慎重な手順が求められる。まず、システムが健全な状態に戻ったことを確認する。その後、すぐに停止中に蓄積された全ての通知を一斉に解放するのではなく、少量ずつ通知の配信を再開する。そして、その間の失敗率や応答時間を注意深く監視しながら、徐々に処理量を増やしていく。通知の配信先となる外部システムが「べき等性」（複数回同じ処理を要求しても、結果が一度実行された場合と同じになる性質）に対応している場合は、それを活用し、重複送信のリスクを低減する。べき等性に対応していない場合は、どの通知が「まだ試行されていない」のか、あるいは「結果が不明」なのかを正確に区別できる仕組みを用意しておくことが重要だ。

本番環境にキルスイッチを導入する前に、その所有者を明確にし、振る舞いを詳細に文書化し、自動テストに組み込むべきだ。非本番環境で、実際のキューとダミーの外部配信サービスを使って徹底的にテストし、ダッシュボードが「試行中」「送信済み」「失敗」「延期」の各状態を明確に表示することを確認する。インシデント発生時には、キルスイッチを操作した理由、期待されるリビジョン、操作者、タイムスタンプを記録する。その後は、コントロールパネルの応答を盲信せず、実際にワーカーが新しいキルスイッチの状態に収束しているか、外部サービスへのトラフィックが減少しているかを確認する。

最後に、キルスイッチは必要なときにだけ使用し、不要になったら速やかに削除するべきだ。緊急事態のために恒久的に残されたキルスイッチは、その機能や影響範囲が曖昧になりやすく、通常のテストやデプロイのレビューから外れてしまう可能性がある。理想的なキルスイッチとは、その効果が予測でき、その状態が検証可能で、かつ緊急時にもプレッシャーの中で簡単かつ安全に使用できる、シンプルで明確なものだ。マーケットプレイスの通知サービスにおいては、副作用を停止しながらも作業記録を維持することで、障害対応者が冷静に対処する時間を与え、通知の停止がユーザーにとってのサイレントなデータ損失にならないようにする重要な役割を果たす。