ネットワーク越しリトライ考 - その手の平は尻もつかめるさ

ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン

[moznion]

blogged

[uzulla]

「絶対最終的に成功させるぞ」というのを仕様からそっとはずしたい。

[ryousanngata]

冪等に処理するのが面倒で結局トランザクションIDみたいのを発行してそのIDを持つデータが存在すれば処理済みとする設計やったなぁ

[hiboma]

実戦での経験値なのかな? 「こんなケースもあるか...」まで考慮されていて ++

[rryu]

こういうリトライ系のことを考える度にNFSの「状態は全てクライアント側で保持してサーバはステートレス」という設計すごいなと思う。

[nicht-sein]

冪等を保証するのが面倒なんだよね……

[buzztaiki]

「クライアントからサーバにリトライリクエストを送る時にリクエストを殺到させるのはやめましょう」ほんこれ。

[Nnwww]

exp backoff, jitterは良い、冪等性は場合によっては...

[iww]

何か実行する系のコマンドのリトライは悩む。 応答の返信に失敗していただけの時はコマンド実行しないようにするとか

[Makots]

“Fibonacci Backoff” は初めて聞いた

[masaru_b_cl]

リトライ回数2回くらいのクライアントしか作ったことなくて、Backoffやジッタまでは入れてなかった

[lilpacy]

[

[a-know]

まとまっている

[taruhachi]

リトライにSleepもリトライ回数制限も入れてない、さらに40x系のステータスコードに対してリトライするクライアントを実装されて死んだ事がある。

[skifuyu]

ゲームエンジンのネットワーク担当なのでわかりみしか無い．ゲーム開発チームに可能な限りこの辺を意識させないように作ろうとして毎回脳が死ぬ

[MASSI]

有益な感じがする

[raimon49]

リトライのbackoff戦略　ExponentialやFibonacci

[iga_k]

学び

[Windymelt]

ハードリトライとソフトリトライ用意できたほうがいいのは本当そう

[joker1007]

これはとても大事なこと。良い記事だ。

[kyuns]

ちょうど最近話してたところ

[kotaponx]

これ、機械じゃなくて人がやるとリロード地獄に陥って死ぬ。

[nochira]

チェックシートや

[peketamin]

うんうんうなづきながら読んだ。よくまとまってて感謝！

[send]

Exponential Backoff は多用してる

[kazeburo]

“Fibonacci Backoff”

[Keisuke69]

Exponential Backoff with Jitter

[indication]

リトライするとき、間隔を1.5倍していくと良い感じだった（個人の感想です）

[hatest]

サーバ１つに対してクライアントは多数いるのを踏まえて、サーバにやさしいリクエストタイミングを考える。強いリアルタイム性が求められるものは、いつも、お高いロードバランサ頼りだなぁ

[castaneai]

“クライアントからサーバにリトライリクエストを送る時にリクエストを殺到させるのはやめましょう サーバが死にます ネットワークが死にます (特にこちらは死んでしまうとどうにもならなくなる) ”

[lesamoureuses]

気をつけます “クライアントからサーバにリトライリクエストを送る時にリクエストを殺到させるのはやめましょう サーバが死にます ネットワークが死にます 気をつけましょう。”