【ITニュース解説】🔁 Idempotency in System Design

分散システムの世界では、予期せぬトラブルや失敗が当たり前のように発生する。例えば、ネットワークが一時的に切断されたり、サーバーからの応答が遅れてタイムアウトしたりすると、同じ処理が複数回実行されてしまうことがよくある。クライアント側が「あれ、応答がないな。もう一度送ってみよう」と再試行する結果、意図しない重複が発生してしまうのだ。もしシステムがこのような重複を適切に扱えないと、例えば顧客が二重に課金されたり、同じ通知メールが何度も送られたり、データベースに同じデータが複数回登録されてしまったりと、重大な問題に発展する可能性がある。このような問題を避けるための強力な設計原則が、「べき等性」である。

べき等性とは、ある操作を何度実行しても、一度だけ実行した場合と同じ最終的な結果が得られるという性質を指す。つまり、操作を複数回繰り返しても、システムの状態は常に一貫していることを保証するのだ。例えば、銀行振込の例を考えてみよう。もし「100円を送金する」という操作がべき等でなければ、ネットワークエラーで再試行された場合に、顧客は二重に100円を支払ってしまうかもしれない。しかし、この操作がべき等であれば、たとえ何度再試行されても、システムは一度だけ送金を処理し、その後の重複したリクエストは無視する。これにより、顧客が二重に課金される心配はなくなる。

なぜ分散システムにおいてべき等性がこれほど重要になるのだろうか。分散システムは、複数の独立したコンピューターやサービスが連携して動作するため、本質的に不安定な要素を多く抱えている。ネットワークの遅延や分断、メッセージキューでのメッセージの再送、APIゲートウェイでのタイムアウトなど、失敗の要因は多岐にわたる。べき等性がないと、これらの失敗がシステムの信頼性を大きく損ない、金融システムでは過剰請求、メッセージングシステムでは重複通知、データベースではデータの一貫性喪失といった問題を引き起こす可能性がある。しかし、べき等性を導入することで、システムは耐障害性を高め、安全な再試行が可能になり、最終的には一貫した状態を保つことができる。これは数学的な「f(f(x)) = f(x)」という厳密な定義とは異なり、システム設計においては「あるリクエストやメッセージが複数回繰り返されても、最終的な結果は一度きりとなる」という実用的な意味合いを持つ。例えば、ユーザーの削除操作（DELETE /user/123）は、一度実行してユーザーが削除されれば、その後何度同じ操作を繰り返しても、ユーザーがすでに削除されている状態は変わらないため、べき等な操作と言える。

べき等性は様々な実世界のシステムで活用されている。例えば、支払いゲートウェイでは、顧客が二重に課金されることを防ぐために、すべての取引にユニークな「べき等性キー」という識別子を利用している。StripeやPayPalといったサービスがその代表例だ。また、メールや通知システムでは、パスワードリセットやワンタイムパスワード（OTP）のメッセージが、イベントの再試行によって複数回送られるのを防ぐために使われる。注文処理システムでは、クライアントが「注文作成」APIを再試行しても、重複して注文が生成されないようにする。データベースの操作では、「Upsert」（レコードが存在すれば更新、存在しなければ挿入）と呼ばれる操作がべき等である。クラウドサービスAPIでは、AWS S3のPUT操作が良い例で、同じファイルを再度アップロードしても重複して保存されることはない。さらに、Kafkaのようなイベント処理システムでは、「少なくとも一度」のメッセージ配信が保証されているため、コンシューマー側で同じメッセージが複数回届く可能性がある。この場合も、コンシューマーはべき等性を考慮してメッセージを処理する必要がある。

HTTP APIにおいても、べき等性は重要な概念である。いくつかのHTTPメソッドは、もともとべき等な性質を持つ。GETメソッドはデータの取得のみを行うため、何度実行してもシステムの状態は変わらず、常にべき等である。PUTメソッドは、リソースを指定された内容で完全に置き換えるため、同じデータを何度送っても最終的な状態は同じになり、これもべき等である。DELETEメソッドも、一度リソースが削除されれば、その後何度削除操作を繰り返しても結果は変わらないため、べき等である。一方、POSTメソッドは通常、新しいリソースを作成する目的で使われるため、デフォルトではべき等ではない。しかし、先に述べたように「べき等性キー」をヘッダーに含めることで、POSTリクエストもべき等にすることができる。例えば、POST /paymentsというAPIに、Idempotency-Key: txn_001というヘッダーを付けてリクエストを送ると、サーバーはこのキーとリクエストの内容を関連付けて一度だけ処理する。もし同じキーで再度リクエストが来ても、サーバーはすでに処理済みの結果を返すか、処理中の場合は新しい処理を開始しない。

べき等性キーを実装する際の一般的なワークフローは次のようになる。まず、クライアントはUniversally Unique Identifier（UUID）やリクエストのペイロード（内容）のハッシュ値などを使って、ユニークなべき等性キーを生成し、HTTPリクエストのヘッダーに含めてサーバーに送信する。サーバーは初回のリクエストを受け取ると、そのべき等性キー、リクエストボディのハッシュ、そして処理結果を、タイムスタンプと共に保存する。これにより「べき等性ストア」が構築される。次に、同じべき等性キーを持つ重複したリクエストが届いた場合、サーバーはこのストアを参照する。もしリクエストがすでに完了していれば、保存しておいた結果をそのままクライアントに返す。もし処理がまだ進行中であれば、新しい処理を開始せずにそのリクエストを無視するか、現在の処理が完了するのを待つ。これにより、クライアントは安全に再試行でき、サーバーは重複処理を防ぐことができる。このべき等性ストアは、Redisのようなキーバリューストアや、SQLデータベースのユニーク制約、NoSQLドキュメントストアなどで実現できる。保存されたキーは、ストアの肥大化を防ぐため、一定期間（例えば24時間）経過したら自動的に削除されるようにTTL（Time To Live）を設定するのが一般的だ。

メッセージングシステムやイベント駆動システムにおけるべき等性も重要である。Kafkaのようなメッセージキューシステムでは、「少なくとも一度」の配信が保証されていることが多く、同じメッセージが複数回コンシューマーに届けられる可能性がある。このような状況で重複処理を防ぐためには、各メッセージにユニークなIDを割り当て、コンシューマー側で「重複排除ストア」を管理する必要がある。コンシューマーはメッセージを受け取ると、まずそのメッセージIDがすでに処理済みかどうかを重複排除ストアで確認する。もし処理済みであれば、そのメッセージは破棄し、まだ処理されていなければ、メッセージのデータを処理し、処理が完了したらそのメッセージIDを重複排除ストアに記録する。イベント駆動アーキテクチャでは、複数のサービスが同じイベントを消費する「ファンアウト」パターンが一般的であり、各コンシューマーサービスは独立してべき等性を確保しなければならない。イベントのペイロードには、常にイベントを一意に識別できるIDを含めるべきである。

べき等性を実現するための設計パターンや技術は多岐にわたる。クライアントが生成するユニークな識別子を用いる「べき等性キー」はAPIにおける基本的な手法である。「重複排除ストア」は、処理済みIDを記録して重複をスキップするために使われる。データベースへの書き込みとイベントの生成を原子的に行う「トランザクショナルアウトボックスパターン」も、システムの整合性を保つ上で有効だ。「少なくとも一度」の配信と組み合わせる「べき等なコンシューマー」は、メッセージングシステムで不可欠である。SQLデータベースの「Upsert」操作もべき等性を簡単に実現する手段となる。「楽観的ロック」や「バージョン管理」は、データの同時更新において重複した更新を安全に検知するために用いられる。さらに、「ステートマシン」パターンは、ある状態から次の状態への遷移を厳密に管理することで、意図しない重複遷移を防ぐことができる。

しかし、べき等性を実装する際にはいくつかの落とし穴もある。例えば、べき等性キーとして「タイムスタンプ」を使うのは避けるべきだ。再試行されるたびにタイムスタンプが異なる可能性があり、システムがそれを別のリクエストとして認識してしまうためである。また、リクエストのペイロードをハッシュ化してキーとして使う場合、ペイロード内のフィールドの順序が異なるとハッシュ値も変わってしまう可能性があるため、注意が必要である。部分的な失敗、つまりトランザクションが途中で失敗して中途半端な状態になってしまうケースを見過ごすと、システムの状態に一貫性がなくなる可能性があるため、これもしっかりと考慮する必要がある。処理中のリクエストの状態を追跡せず、完了したリクエストのみをストアに記録するのも問題だ。重複したリクエストが来た際に、すでに処理が進行中であることをサーバーが認識できず、二重に処理を開始してしまう可能性がある。べき等性キーのストアのTTLを適切に設定しないと、キーがいつまでも削除されずに残り続け、メモリリークやストレージの圧迫につながる可能性もある。

べき等性が正しく機能しているかを確認するためには、徹底したテストと監視が不可欠である。テストの際には、同じリクエストを複数回送信して、システムに一度だけ効果があることを検証する。ネットワークの再試行やタイムアウト、メッセージストリームへの重複イベントの挿入など、実際の分散システムの障害シナリオをシミュレートするテストも重要である。さらに、同じべき等性キーを使った複数の同時再試行もテストすべきだ。監視においては、システムログにべき等性キーやリクエストIDを含めることで、問題発生時の追跡を容易にする。また、duplicate_request_count（重複リクエスト数）やidempotency_cache_hits（べき等性キャッシュヒット数）といったメトリクスを収集・可視化することで、べき等性機能が期待通りに動作しているかを把握できる。

結論として、分散システムにおいてべき等性は、不安定なネットワーク環境から予測可能で信頼性の高いシステムを構築するための極めて重要な設計原則である。べき等性を導入することで、安全な再試行が可能となり、システムの一貫性が保証され、最終的にはユーザーからの信頼を保護することにつながる。常に、特に金銭取引や状態変更を伴うAPIやイベントコンシューマーは、べき等性を考慮して設計すべきである。べき等性キーや重複排除メカニズムを適切に採用し、これらを再試行、タイムアウト処理、そして入念な監視と組み合わせることで、システムの堅牢性を飛躍的に高めることができる。「正確に一度」の処理は分散システムにおいて実現が非常に難しい理想であり、現実的にはべき等性がその理想に近づくための最も実用的なアプローチであることを忘れてはならない。