フォローしました(画像引用:https://www.brianstorti.com/rabbitmq-exponential-backoff/)はじめまして。Artriggerのnooptrと申します。私はプログラマとして主にFOLLYの開発に携わっており、バックエンドとブロックチェーン開発を担当しております。noteではArtriggerやFOLLYに関するトピックだけでなく、テック系の記事やエンジニア向けの記事も発信していくので、ご覧いただけると幸いです。(記事を書くのはあまり慣れていませんが、よろしくお願いします!)さて、多くのエンジニアの方が「リトライ処理」に関するプログラムを書いた経験があると思います。エラーの発生時に、どのようにリトライすれば効率なのか。これは誰もが抱える悩みですよね。Backoff」という手法をご紹介したいと思います。......と、その前にそもそもリトライ処理って何でしょうか?リトライとは、再試行(する)という意味の英単語。した場合に、同じ処理の実行をもう一度試みることをリトライという。利用者の指示に従って実施される場合と、あらかじめ設定された回数や時間間隔の通りに自動的に行われる場合がある。e-Wordsわかりやすく言うと"再試行の処理"ですね。一般的なエラーリトライの例を見ていきましょう。MAX_RETRIES))一見、問題ないように見えますが、実は非効率的なコードです。小規模のシステムの場合は「1秒ごと」など固定値で実装して良いかもしれませんが、システムの規模が大きくなると、問題が生じてしまう可能性があるからです。次に、具体的な方法をお話していきます。Backoffとは、データ送信処理が失敗して再送信する際に、失敗回数が増えるに連れて再送信するまでの待ち時間を指数関数的に増やす仕組みです。衝突の連続を防ぐために、遅延(リトライ間隔)をランダム化します。リトライ間隔を固定値ではなく、0.5秒、1秒、2秒、4秒、8秒、16秒......というように増やしていくのです。これによって、サーバの負荷を軽減したり、無駄なリクエストを省けたり、再試行する前に問題を修正して解決できるようになるので、結果的にリトライ後の成功率が高くなります。先ほどの例に戻ってみましょう。これは、どのような問題があると考えられるでしょうか。MAX_RETRIES))例えば、ウェブサーバが2台(1号機と2号機)あるとします。クライアントからのリクエストは、ロードバランサ経由でそれぞれのサーバに振り分けますね。サーバ1号機が何かしらの原因でダウンしたとします。2号機に送信されることになるでしょう。この時に、「1秒ごと」の固定値でリトライすると、当然ながら全クライアントが「1秒ごと」にリトライすることになりますよね。DoS攻撃にも似た過剰な負荷がかかることになるのです。結果はご察しの通り、2号機も同じくダウン......。リトライ間隔を指数関数的に調整すれば、解決できます。秒待ってから、リクエストを再試行。秒待ってから、リクエストを再試行。秒待ってから、リクエストを再試行。回数まで繰り返します。64秒)ですが、適切な値はユースケースによって異なります。randomization_factor])・レスポンスのステータスは5xxの場合はリトライ。(15s)の場合はストップ。Backoffのメリットは、主に以下の2つです。・長期的な障害が発生した時に、システムの負担を軽減できる。・大規模分散システム内では常に部分障害が発生しているため、運用コストを削減できる。Backoffを試してみてください。APIのリトライ処理ダウンロード#エンジニア#1#プログラマ#私のテックメモ#ウェブサービス#Artriggerこの記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。サポートをする「スキ」を押してクリエイターを応援しよう!28Artriggerアート・テクノロジー・教育に関する最新トピックをお届けします。系記事まとめnoteに投稿されたエンジニア系の記事のまとめ。コーディングTIPSよりは、考察や意見などを中心に。02:15すいません。素人質問なのですが、指数関数的に待ち時間が大きくなるので、ランダム化はしていないとおもうのですが、界隈では指数増加をランダム化と表現することがあるのでしょうか。12:01ご質問ありがとうございます。Backoffアルゴリズムの実装例によると、ランダム化はしています。100までの間、ランダムして、random値を取っているからですね。100)そういう感じですね。完全に勘違いしてました!確かにランダムですね。クリエイターへのお問合せnoteカイゼン目安箱クリエイターの。