SYSTEM-6-5

クライテリア

バッチ、ジョブ、プロシージャに対する冪等な設計ガイドラインが存在しており、再送によって整合性が担保できるようなシステムになっているか。

タイプ

疎結合アーキテクチャ

観点

プラクティス

用語解説

冪等(性)

同じ操作を何度繰り返しても、同じ結果が得られます。

参考資料

冪等性とは「同じ操作を何度繰り返しても、同じ結果が得られる性質」のこと - Qiita
冪等性(べきとうせい、idempotency, idempotence)とは、 同じ操作を何度繰り返しても、同じ結果が得られる という性質です。冪等性がある操作(idempotent operation)は、1回操作した場合の結果と、2回以上操作した場合の結果は同じになります。 fという関数に引数 xを与えた場合、次の式が成り立つ性質。(もちろん f は副作用がない関数であることが前提です) 冪等性がある関数の例 絶対値を求める関数は冪等性があります。 abs(-100)の結果は 100ですが、それを何度 abs()に渡しても、最初に得られた結果である 100 と同じ結果が必ず得られます。 冪等性がない関数の例 冪等性でない関数には、平方根を求める関数などがあります。 sqrt(16)の結果は 4です。 4を更に sqrt()に渡すと、結果が 2 になります。一度目の結果と二度目の結果が異なるため、冪等性が無いわけです。 冪等性はRESTfulの文脈でもよく話題になります。RESTfulでも冪等性の概念は同じで「同じ操作を何度繰り返しても、同じ結果が得られる」という意味です。もう少しRESTfulっぽく寄せた説明をするなら、「同じリクエストを何度繰り返しても、同じリソース状態になること」という感じになると思います。 得られる結果というのは リソース状態であって、レスポンスではないことに注意してください。 DELETE メソッドには冪等性がありますが、1度目のリクエストでは200レスポンスを、2度目以降のリクエストは404レスポンスを返すことが普通です。このように冪等性があるAPIでも回数に応じてレスポンスが変化することがありますが、リソースが削除されたという結果(リソース状態)が2度目のリクエストで覆ることはありません。 冪等性があるRESTful APIの例 RESTfulではGET, PUT, PATCH, DELETEは冪等性があるメソッドとされています。 GitHubのAPIにはリポジトリにスターをつけるAPIが生えていますが、これは冪等性があるAPIです。 何度上のPUTメソッドを叩いても、結果はスターがついた状態になります。スターが外れることはありません。 冪等性がないRESTful APIの例 一方、POSTは冪等性がないメソッドとされています。例えば、GitHubのAPIにはissueを立てるAPIがありますが、これは冪等性がないAPIです。 同じリクエストを二度送ると、2個issueができてしまいます。 RESTfulの冪等性に関連して、 PUT か POST か PATCH か? - Qiita もご覧ください。 ChefやAnsibleなどのようなインフラ構築をプログラムで自動化する界隈でも冪等性という言葉がよく出てきます。自動化における冪等性の考え方も、他の分野の考え方と同様に「同じ操作を何度繰り返しても、同じ結果が得られる」というものです。 冪等性がある操作の例 ファイルをコピーする操作は冪等性があります。$ cp file_a file_bのような操作は、 file_b がなければ作られ、すでに有ったとしても内容が変わったりすることはありません。これは何度やってももたらされる結果が同じであるため冪等性があると言えるわけです。 冪等性がない操作の例 逆に、 echo "some_config" >> /etc/some.conf のような、ファイル末尾に行を継ぎ足す操作には冪等性がありません。実行するたびに行数が増えていきます。つまり、操作の回数に応じてもたらされる結果が異なるわけです。こうした操作は、すでにファイル末尾に設定が書き込まれているかをチェックしてあげる必要があります。 冪等性のメリットのひとつは、関数やAPI、コマンドを実行する側が、 前提となる状態を気にしなくてよくなる という点です。RESTful ...