二度実行しない自動化──冪等性とリトライの設計

自動化の話になると、人はまず「速さ」や「省力化」を思い浮かべる。だが実際に自動処理を運用してみると、最初に頭を悩ませるのはたいてい別の問題だ。「同じ処理が、二回走ってしまった」。たとえば請求メールが二通届く。在庫が二重に引かれる。送金が二度実行される。どれも、設計の甘い自動化が必ず通過する落とし穴である。

原因の多くは、悪意でもバグでもなく、ごく自然なネットワークの振る舞いにある。あるサーバーが別のサーバーに「処理してください」と頼む。処理は成功したのに、その返事だけが途中で消える。頼んだ側は返事が来ないので「失敗したのだろう」と判断し、もう一度頼む。こうして、成功した処理がもう一度走る。人手なら「あれ、さっきやったよな」と気づくところを、機械は律儀に二度実行してしまう。

冪等性という安全装置

この問題に対する古典的な答えが「冪等性（idempotency）」だ。数学に由来する言葉で、同じ操作を一回行っても二回行っても結果が同じになる性質を指す。照明のスイッチを「オフにする」操作は冪等だ。すでにオフなら、もう一度オフにしても何も起きない。一方「明るさを一段下げる」は冪等ではない。二回押せば二段下がる。自動化で危ないのは、後者のような「実行するたびに状態が動く」処理である。

実務でよく使われるのが「冪等キー」という仕組みだ。処理を依頼するとき、依頼ごとに一意の合言葉を付けておく。受け取った側は、その合言葉を見て「これは初めて見る依頼か、前に処理済みか」を判断する。済みであれば、もう一度依頼が来ても、前回と同じ結果をそのまま返すだけで、状態は動かさない。送金が二度実行されないのは、この合言葉が重複を吸収しているからだ。決済サービスの技術文書では、こうした冪等キーの利用が事実上の標準的な作法として案内されている。

リトライは「優しく、ほどほどに」

では再送をやめればよいのかというと、そう単純でもない。一時的な混雑や瞬断は避けられず、再送（リトライ）自体は必要な仕組みだ。問題は、その作法にある。失敗するたびに即座に、何度も繰り返し叩きにいくと、弱っている相手をさらに追い込み、障害を広げてしまう。これは「リトライ・ストーム」と呼ばれ、自動化が自動化を踏みつぶす典型例として知られている。

そこで実装では、再送の間隔を少しずつ延ばす「指数バックオフ」や、各クライアントの再送時刻をわざとばらけさせる「ジッター」といった工夫が使われる。みんなが同じ瞬間に再送すると波が揃ってしまうため、あえて足並みを乱す。グーグルの『SRE サイトリライアビリティエンジニアリング』でも、無制限の再送がいかに危険か、上限と間隔の設計がいかに重要かが繰り返し説かれている。

「速さ」より「数えられること」

冪等性もリトライ制御も、派手な機能ではない。利用者の目に触れることはまずなく、うまく働いているときほど存在に気づかれない。けれど、自動化を任せられるかどうかは、結局のところ「同じことを二度やらない」「失敗しても傷を広げない」というこの地味な土台にかかっている。本サイトで扱うイベント駆動とメッセージキューのような非同期の仕組みでも、メッセージが二度届く前提で冪等に作ることが、ほとんど作法として求められる。

もっとも、冪等に作れば何でも安全になるわけではない。重複は防げても、そもそも依頼の中身が間違っていれば、それを何度受け取っても間違ったままだ。冪等性が守るのは「実行回数」であって「内容の正しさ」ではない。自動化を信頼に足るものにするには、結果が数えられること、そして数えた結果が確かめられることの両方が要る。速く動くシステムより、何が起きたかを後から正確に数えられるシステムのほうが、長く運用に耐える。