【ITニュース解説】Idempotency in System Design: Full example

冪等性（Idempotency）とは、ある操作を何度繰り返しても、システムの状態が最初に実行した一回の場合と同じになる性質のことだ。この概念は、現代の複雑なシステム設計において非常に重要な要素となる。

なぜ冪等性が重要なのか。私たちが普段利用するWebサービスやアプリケーションは、多くの場合、ネットワークを介して通信を行っている。ネットワークは常に安定しているわけではなく、途中で通信が途切れたり、遅延が発生したりすることがある。また、ユーザーが意図せずにボタンを複数回クリックしてしまったり、システム側でリクエストの再試行が行われたりするケースも考えられる。

もし、このような状況で同じ操作が複数回実行されてしまったら、どうなるだろうか。例えば、オンラインショップで商品を一つだけ注文したはずなのに、ネットワークの一時的な不具合で注文処理のリクエストがサーバーに二回届いてしまい、結果として同じ商品が二つ注文されてしまうかもしれない。あるいは、銀行の送金システムで、A口座からB口座へ1000円を送金するリクエストが誤って二回実行されてしまい、B口座に2000円が送金され、A口座から2000円が引き落とされるといった、深刻な二重処理が発生する可能性がある。これでは、システムは信頼できないものになってしまう。

冪等性はこの問題を解決するために導入される。「この処理は何度実行されても、ただ一度だけ実行されたかのように振る舞う」という保証をシステムに持たせるのだ。

具体的な例で考えてみよう。銀行の送金処理を例にとる。 ユーザーが「A口座からB口座へ1000円を送金する」という操作を実行したとする。この操作は、通常、クライアント（ユーザーのPCやスマートフォン）からサーバーへリクエストとして送信される。

冪等性がない場合、以下のようなシナリオが考えられる。

1. クライアントが送金リクエストをサーバーに送信する。
2. サーバーは送金処理を実行し、A口座から1000円を引き落とし、B口座へ1000円を入金する。
3. サーバーはクライアントに応答を返す（「送金成功」など）。
4. しかし、この応答がネットワークの不具合でクライアントに届かなかったとする。
5. クライアントは応答が来なかったため、処理が成功したか失敗したか分からず、送金リクエストを再送する。
6. サーバーは、再び送金処理を実行し、A口座からさらに1000円を引き落とし、B口座へさらに1000円を入金してしまう。 結果として、二重送金が発生し、A口座から合計2000円が引き落とされ、B口座に2000円が入金されてしまう。

これを防ぐために冪等性を導入する。どのように実現するかというと、「冪等キー」という一意の識別子を利用するのが一般的な方法だ。 冪等キーは、各リクエストに固有のIDを割り当てるものだ。これは、クライアント側で生成されることが多い。例えば、UUID（Universally Unique Identifier）のような、他のどのリクエストとも重複しないランダムな文字列を使う。

冪等性を導入した送金処理のシナリオは次のようになる。

1. クライアントは送金リクエストをサーバーに送信する際、このリクエストに固有の「冪等キー」（例: abcd-1234-efgh-5678）を付与して送信する。
2. サーバーはリクエストを受け取ると、まずこの冪等キーをチェックする。
3. サーバーは、過去にこの冪等キーを持つリクエストが処理されたかどうかを、データベースなどに保存された記録と照合する。
4. ケース1: 初めてこの冪等キーのリクエストを受け取った場合
   • サーバーは、冪等キーを「処理中」または「成功」として記録する。
   • A口座から1000円を引き落とし、B口座へ1000円を入金するという送金処理を実行する。
   • 処理が完了したら、冪等キーを「成功」として記録し、クライアントに「送金成功」の応答を返す。
5. ケース2: 過去に同じ冪等キーのリクエストが既に処理済みである場合
   • サーバーは、冪等キーが既に「成功」として記録されていることを確認する。
   • この場合、サーバーは送金処理を再度実行せず、過去に成功した際の結果（例えば、最初の「送金成功」メッセージや、トランザクションの詳細）をそのままクライアントに返す。
   • つまり、実質的な送金処理は一度しか行われないが、クライアントには正常に処理されたという応答が返される。
6. ケース3: 過去に同じ冪等キーのリクエストが「処理中」であった場合
   • この場合は、前の処理がまだ完了していない可能性があるので、サーバーは新しいリクエストを一時的に待機させるか、エラーを返すなどの対応をとる。これにより、重複処理を防ぐ。

このメカニズムにより、クライアントがネットワークエラーで応答を受け取れず、何度も同じ冪等キーでリクエストを再送したとしても、サーバー側では実際の送金処理は一度しか行われないことが保証される。クライアントから見れば、何度リクエストしても結果は「送金成功」であり、システムの状態（口座残高）も一度の送金処理と全く同じになる。

実装上のポイントとしては、サーバー側で冪等キーを管理するためのストレージが必要になる。これは多くの場合、データベースに専用のテーブルを作成し、冪等キー、そのリクエストの状態（処理中、成功、失敗など）、処理された日時、そして可能であれば処理結果自体を保存する。冪等キーにはユニーク制約を設けることで、二重登録を防ぐことができる。

また、冪等キーには有効期限を設けることも重要だ。例えば、一日や一週間といった期間が過ぎたら、その冪等キーの記録は削除しても問題ない場合が多い。これは、システムが不要なデータを蓄積し続けるのを防ぎ、データベースの負荷を軽減するためだ。もし、クライアントが非常に古い冪等キーを再送してきた場合は、そのキーが無効であることを伝え、新しいキーでのリクエストを促すなどの対応が考えられる。

冪等性は、単純な読み取り操作（GETリクエスト）では自然に満たされることが多い。「ある商品情報を取得する」というリクエストは、何度実行しても同じ商品情報が返されるだけで、システムの状態に変化はないからだ。しかし、「新しい商品情報を登録する（POST）」「既存の商品情報を更新する（PUT）」「商品を削除する（DELETE）」といった、システムの状態を変更する操作において特に重要になる。HTTPメソッドで言えば、GETは冪等、PUTは冪等、DELETEも冪等とされている。POSTは通常冪等ではないが、冪等キーを付与することで冪等性を実現できる。

システム全体で見ると、冪等性を導入することは、システムの信頼性と堅牢性を大幅に向上させる。ユーザーは安心してサービスを利用でき、開発者も予期せぬ重複処理によるバグやデータ不整合の心配を減らすことができる。ただし、冪等性を実現するための仕組みを導入するには、設計や実装に追加の工数がかかり、冪等キーを保存・管理するためのリソース（データベースのストレージやCPU処理時間）も必要となる。これらは、システムの要件や規模に応じて適切にバランスを取る必要がある。

このように、冪等性は、ネットワーク通信を前提とした現代の分散システムにおいて、データの一貫性を保ち、信頼性の高いサービスを提供するために不可欠な設計原則の一つだ。システムエンジニアを目指す上では、この概念とその具体的な実現方法をしっかりと理解しておくことが、堅牢なシステムを構築するための第一歩となるだろう。