【ITニュース解説】Media Pricing Feature Flags: Idempotency for Retries and Duplicate Writes

フィーチャーフラグとは、ソフトウェアの特定機能をオンにしたりオフにしたりする仕組みである。この仕組みは、新しい機能の段階的なリリースやテストに非常に役立つが、価格設定のような重要なビジネスロジックを制御する場合には、細心の注意が必要となる。特に、同じ操作を何度行ってもシステムの状態が変わらない「冪等性」という性質を確保しないと、大きな問題が発生する可能性がある。信頼性の高いシステムを構築するには、この冪等性の重要性を深く理解する必要がある。

システムがネットワークの切断やタイムアウトによって、ある処理が成功したのか失敗したのか不明な状態に陥ることは珍しくない。例えば、システムが新しい価格ルールを適用するリクエストをバックエンドに送信し、バックエンドは変更をデータベースに書き込んで成功したとする。しかし、その結果を伝えるレスポンスが呼び出し元に届く前にネットワーク接続が切れてしまうと、呼び出し元は処理が失敗したと判断し、同じリクエストを再試行するだろう。このとき、もし適切に冪等性が考慮されていないと、同じ価格ルールが二重に適用されたり、同じ料金が顧客に二重に請求されたりする「重複書き込み」が発生する可能性がある。これはビジネスに直接的な損害を与え、顧客の信頼を損ねる深刻な事態に繋がりかねない。

このような重複書き込みを防ぐためには、HTTPメソッド（例：PUTは一般に冪等とされる）だけに頼るのではなく、アプリケーション自体が冪等性を保証する設計が不可欠である。重要なのは、同じ目的を持った複数のリクエストが、最終的にシステム内で一つの恒久的な結果に収束することだ。具体的には、リクエストごとに一意の「オペレーションID」を割り当て、システムはこのIDを用いて過去に同じ操作が既に実行されたかどうかを判断する。

さらに、フィーチャーフラグの評価タイミングも潜在的な問題を引き起こす。例えば、最初の試行で特定のグループ（「コホート」と呼ぶ）に対して10%の割引を適用すると決定し、それが記録されたとする。しかし、リトライが行われるまでの間にフィーチャーフラグの設定が変更され、今度は25%のコホートに適用されることになった場合、再評価すると異なる結果が適用されてしまう。これにより、本来一つの論理的な操作であるべきものが、異なる意思決定の結果として記録され、後から原因を調査する際の混乱を招き、コストの帰属（どの決定によって費用が発生したか）も曖昧になる。

これらの問題に対処するため、システムはいくつかの異なる識別子を明確に区別する必要がある。「ロールアウトID」は計画された変更全体を指し、「オペレーションID」はそのロールアウト内での個々の変異リクエストを指す。「アテンプト」はリクエストの試行回数を数えるためのものであり、その値が変わってもオペレーションIDはリトライ間で固定されなければならない。「ルールバージョン」はフィーチャーフラグによって選択された不変の価格ロジックを示す。このオペレーションIDが、同じ操作を再試行する際に常に同じであることで、システムはそれが重複したリクエストであるかを判断し、適切に処理できる。

バックエンドでは、このオペレーションIDとビジネス上の変更を一つの「トランザクション」（一連の処理をまとめて成功させるか、すべてを元に戻すかする仕組み）内で処理する。これにより、複数のシステムが同時に同じ操作を試みても、データベースのユニーク制約によって、最初の操作だけが成功し、二番目以降は既に処理済みであると判断されるか、あるいは競合として適切に拒否される。この設計では、各変更ごとに永続的な記録を残し、その結果を保存する必要があるため、オーバーヘッドは発生する。しかし、価格設定のような重要な変更においては、重複によるコストや手作業での修正といった後処理の複雑さを考えれば、この追加の作業は、システムの正確性を保証するための正しい選択である。Go言語でのコード例が示唆するように、システムは Apply という操作を通じて、同じオペレーションIDと入力が与えられた場合には以前の結果を返し、異なる入力が与えられた場合にはエラーを返すことで、冪等性を実現する。

この仕組みを支えるためには、システムの「可観測性」、つまり外部からシステムの状態をどれだけ推測できるかも非常に重要である。価格変更のような重要な操作では、その意思決定がどのように行われ、どのようなコストが発生したのかを明確に追跡できる必要がある。例えば、W3C Trace ContextやOpenTelemetryといった標準的な仕組みを使って、論理的な操作の開始から終了までを追跡する「トレーススパン」を生成し、その中にロールアウトID、コホート、ルールバージョン、結果といった情報を記録する。これにより、一つの請求がどのフィーチャーフラグの決定によって発生したのかを正確に特定できるようになる。ログには具体的なオペレーションIDを含め、メトリクスは集計的な質問に答えるために用いる。同じ操作が再度実行された場合でも、それを新たな成功としてではなく、「成功したリプレイ（適用はされなかった）」として報告することが重要だ。

フィーチャーフラグを展開する際には、段階的なアプローチが推奨される。まず、ごく一部の、影響範囲が限定的なコホートで新しい価格ルールを適用し、そのコストを注意深く監視する。展開を進める前に、過去のデータと比較して、価格ルールの適用回数、リプレイの発生回数、競合の有無、キューの滞留時間、下流システムでのエラー、そして承認されたメディアアクションごとの費用などを詳細に分析する。特に、テスト環境で意図的にネットワークエラーを発生させ、リトライが正しく機能し、重複書き込みが発生しないことを確認する作業は非常に重要である。本番環境での各ステップでは、「ビジネスのユニーク性（重複がないこと）」、「決定の一貫性（リプレイでも元の決定が維持されること）」、「コスト調整（すべての費用が正確に帰属すること）」の3つのポイントを厳しくチェックする。特に、「帰属不明な記録」をゼロにすることが目標であり、もし原因不明の費用が発生すれば、それは展開を停止する明確なシグナルとなる。

万一、問題が発生してフィーチャーフラグの変更を元に戻す「ロールバック」が必要になった場合でも、慎重な手順が求められる。ロールバックは、元のフィーチャーフラグの変更を削除するのではなく、新しいオペレーションとして「新しいルールを無効化する」という操作を実行する。元の冪等性記録は削除したり変更したりせず、そのまま残しておく。これにより、将来的にどのメディアアクションがどの価格ルールを使ったのかを追跡するための履歴が保持され、遅れて届くリトライリクエストも元の結果に正しく解決できる。価格計算によってすでに外部の請求が発生している場合は、フィーチャーフラグのロールバックでそれを消すことはできないため、既存の精算プロセスを通じて適切に処理し、ロールアウトの次元情報は保持しておく必要がある。

最終的に、この一連のプロセスから得られる重要な教訓は明確である。フィーチャーフラグはシステムがどのような「選択」をするかを制御し、冪等性記録はそれらの選択がシステムにどのような「影響」を及ぼすかを制御する。そして、トレースやログ、コスト記録といった「可観測性」の仕組みが、これら二つを結びつけ、リトライが無害であることを証明し、発生したすべての費用がどこで、どのような意思決定によって生じたのかを明確に追跡できるようにする。これらの原則を理解し、実践することで、複雑なシステムにおいても信頼性と正確性を確保し、ビジネスの成長を支えることができる。