@twitterこの広告は、90日以上更新していないブログに表示しています。リトライはいつ成功するか三度の飯よりエラー処理。好評をいただいた序章リトライと冪等性のデザインパターンの続編です。前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。パターン2:エラーを区別してDELETEを冪等にするリソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。INCREMENT)で問題ない。DeleteもCreateと同様に、クライアント側のエラーハンドリングは少し難しい。「指定されたIDは既に削除済みだ」というエラーを受け取ったとき、それが以前から存在していなかったのが原因なのか、リトライしたことが原因なのかは区別するできない。これもケースバイケースだが、やはり決定性なエラーなのでリトライしてはいけない。Foundに相当するエラーコードや例外クラスを定義しておき、クライアントが区別できるようにしてしておいた方がいい*1。パターン3:操作をまとめて冪等にする状態を持たないCreateやDeleteを冪等にする方法は簡単すぎるので、書くまでも無かったかもしれない。作ったプロジェクトにアイテムBを10個加える(Append)一般にAppendやIncrementなどの操作は冪等にするのが難しい。言い換えれば、以前の状態に依存して操作後の状態が変わる操作は、冪等にするのが難しい*2。上記の例では、ステップ2.や3.が失敗した場合にその操作をリトライすると、予定よりも多くのアイテムが入ったプロジェクトが出来上がってしまう可能性がある。いう場合は、一連の操作をまとめてリトライできないか考えてみる。アイテムAが5個とアイテムBが10個入ったプロジェクトPを作る(Create)パターン4:操作を細かくして信頼性を高める前節では操作を大きな粒度にまとめてリトライする方法を紹介したが、リトライの粒度を大きくするほど信頼性は落ちることに注意する必要がある。合計5億件加える構造的には前節と同じなので、全体をまとめることで安全にリトライできる。ここで、10,000件のAppend操作が、0.01%の確率で失敗してしまうと仮定する。一連の操作全体を毎回リトライしていたら、いつもどこかで失敗してしまう。いうプログラムはいつまで経っても終わらないプログラムと言われる。残念、使い物にならない。リトライの粒度を大きくするほどリトライのオーバーヘッドは大きく膨らみ、全体としてスループットは低下する。このような場合では、個々の操作を冪等にし、細かい粒度でリトライできるようにする必要がある。作成したSplit-1〜Split-50000含んだテーブルTを作成する(Create)しかしこのように、AppendやIncrementを冪等にする仕組みは大がかりになりがちなので、本当に細かい粒度でリトライする必要があるかどうかは熟考が必要。場合によっては最終奥義『トランザクション』に頼った方が良いケースもある。シンプルで妥当な方法を見つけ出すかは、プログラマの腕の見せ所かもしれない。https://twitter.com/frsyuki/status/476944444676001793*2:逆に言えば、以前の状態を無視して(依存せずに)新しいセットを宣言する操作は、簡単に冪等にできる。いうAPIには、操作後の状態を単純に宣言する名前を付けることができる。あらゆる操作を冪等にする方法いつも心に冪等性。論理削除はなぜ「筋が悪い」かKazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。UPDATEが...2015-02-16並列データ転送ツール『Embulk』リリース!こんにちは。データ転送ミドルウェア勉強...2014-06-09リトライと冪等性のデザインパターンリトライを肴に一晩酒が飲める古橋です。リトライはいつ成功するかリトライと冪等性のデザインパターン月別アーカイブ検索はてなブログをはじめよう!viverさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。