【ITニュース解説】Reads That Survive the Kill Switch

システム開発や運用において、予期せぬ問題が発生した際にシステムを緊急停止させる「キルスイッチ」という仕組みは非常に重要である。例えば、自動で動くプログラム（cron worker）が意図せず誤動作を起こした場合、その処理を即座に停止することで、システムへの悪影響やデータの破損を防ぐことができる。しかし、このキルスイッチには盲点があり、システム全体の健全性を確保する一方で、システムの現在の状況を把握できなくしてしまうという課題がある。

具体的には、キルスイッチが発動しシステムが停止すると、本来であれば有害なデータの書き込み処理が止まる。これは良いことだが、同時に、ユーザーからのリクエストがどれだけ溜まっているか、システムがどのような状態にあるかといった情報を「読み取る」ことまでできなくなってしまうことが多い。これは、多くのシステム設計において、データの「書き込み」と「読み取り」が同じ「ゲート」（処理を許可する仕組み）を共有しているためだ。キルスイッチが有効になると、このゲートが閉じられ、データの書き込みだけでなく、システムの状態を監視する読み取り操作まで遮断されてしまうのである。

この結果、運用チームはシステムが停止している間、顧客からの新しいリクエストが溜まっているのか、それともシステムが完全に停止していて待機中のリクエストはほとんどないのか、といった判断ができない状態に陥る。システムが復旧したときに初めて、大量の未処理リクエスト（バックログ）が溜まっていることに気づく、あるいは最悪の場合、気づくことさえできないという状況が発生する。これは、システムが停止している状態を示すフラグが、データの公開（書き込み）と、処理の需要をチェックする機能の両方をブロックしてしまうためであり、停止の指示とシステムの状況を観察する必要性を誤って混同していることに起因する。

この「停止中に盲目になる」という問題を解決するためのアプローチとして、「ピークパターン」という考え方が提案されている。ピークパターンは、システムが停止している間でも、その可視性（状況を把握できる能力）を維持することを目的としている。このパターンでは、システムのキュー（未処理リクエストの列）の状態を見る操作と、キューの内容を変更する操作を明確に分離する。

ピークパターンのワークフローは、大きく三つの段階で実行される。第一に「トークン検証」で、プログラムの実行に必要な認証情報を最初に読み込み、認証が失敗した場合はすぐに処理を停止する。次に「ピーク」の段階で、読み取り専用の需要チェックを実行し、現在の未処理アイテムの数を数える。このとき、システムの内部状態は一切変更しない。最後に「ゲート評価」で、キルスイッチの状態を確認する。もしキルスイッチが有効であれば、データの書き込み処理はスキップされるが、前の段階で読み取った未処理リクエストのデータは保持される。

このピークパターンにおける読み取り操作には、厳密なルールがある。それは、決してエラーを発生させてはならず、データを書き込んではならず、外部への通知をトリガーしてはならないというものだ。たとえ基盤となるデータストレージが一時的に高負荷の状態にあったとしても、最悪の場合の返り値は「未処理リクエストがゼロ」という空のカウントであるべきで、処理の失敗を示すエラーであってはならない。これにより、どのような状況下でも、常にシステムの需要を把握できる状態が保たれる。

また、システム監視の一般的な問題点として、タスクが成功した場合にのみ需要を報告する傾向がある。キルスイッチがアクティブな場合、停止された処理はしばしば文脈のない空の応答を返し、運用担当者は、待機中のタスクが全くないのか、それとも大量のリクエストがブロックされたキューで待っているのかを区別できない。この問題を解決するためには、考えられるすべての処理結果に、現在の未処理リクエスト数（pending count）を付加することが重要である。処理が停止された場合、スキップされた場合、失敗した場合、または成功した場合のいずれであっても、ログエントリや監査記録には正確な未処理リクエスト数を記載すべきである。これにより、システムが書き込みを完全に停止している間でも、継続的な負荷の傾向を監視ログで確認できるようになる。

しかし、需要の可視性を確保することが、キルスイッチのセキュリティ境界を弱めることになってはならない。キューを監視する（ピークする）ことは、そのキュー内のリクエストを実際に処理する許可を与えるものではない。システムが外部に応答を返したり、外部サービスに呼び出しを実行したりする処理は、依然として既存のすべての保護機能（例えば、重複検知、予算制限、監査要件など）の背後に安全に置かれるべきである。

シンプルなプログラムの例で考えてみよう。ある関数が、まず安全に未処理リクエスト数を取得し、次にキルスイッチの状態を確認する。もしキルスイッチがアクティブであれば、データの書き込み処理は実行せず、現在の状態が「停止中」であることを示し、取得した未処理リクエスト数と共に結果を返す。キルスイッチがアクティブでなければ、データの書き込み処理を実行し、状態が「公開済み」であることを示し、同様に未処理リクエスト数と共に結果を返す。ここで未処理リクエスト数を取得する関数は、内部でエラーが発生しても、それを捕捉し、エラーではなく「未処理リクエストがゼロ」といった安全な値を返すように設計されるべきである。これにより、いかなる状況でも監視プロセス自体が中断されることはなくなる。

このように、読み取り操作と書き込み操作を明確に分離することで、緊急時にありがちな「盲点」を防ぐことができる。需要チェックを書き込みゲートから独立して実行し、さらにすべての処理結果に未処理リクエスト数を添付することで、エンジニアリングチームは、システムが停止状態から回復する際に、その時点で必要となる正確な復旧作業の規模を判断できるようになるのである。