べき等性は2回目のリクエストが異なるまでは簡単
原題: Idempotency is easy until the second request is different
なぜ重要か
分散システムやAPIの信頼性設計において、べき等性の適切な実装が重要な技術的課題として認識されている
開発者向けブログでべき等性の実装における課題が解説された。基本的なリクエスト重複処理は簡単だが、同じキーで異なる内容のリクエストや並行処理、部分的失敗など複雑なケースが実際の困難さを生む。単純なリプレイキャッシュでは不十分とした。
べき等性は一般的に解決済みの問題とされ、リクエストにIdempotency-Keyを付与し、レスポンスを保存して再試行時に再生する方法が知られている。しかし、この基本的なアプローチは正常系でのみ機能する。
真の困難は2回目のリクエストから始まる。完了したリプレイなら保存された結果を返せばよいが、最初のリクエストがまだ実行中の場合、べき等性レイヤーが並行制御の一部となる。最初のリクエストがローカル支払いを作成したがイベント発行前にクラッシュした場合、ローカルデータと外部副作用が不整合となる。
特に複雑なのは同じキーで異なる内容のリクエストの場合だ。例えば同じキーで10ユーロと100ユーロの支払いリクエストが来た時、これが再試行か、クライアントのバグか、新しい操作かの判断が困難になる。サーバーは古いレスポンスの再生、リクエストの拒否、新しいIDとしての扱いのいずれかを選択できるが、明確なポリシーが必要だ。
べき等性の本質は「効果」にあり、同じ操作を1回または複数回適用しても同じ意図した効果を持つことだ。単純なリプレイキャッシュでは、並行再試行、部分的ローカル成功、ダウンストリームの未知状態、キー期限切れ後の再試行などの複雑なケースに対応できない。