ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン
今回の記事は普段の GS2 のアップデート告知とは少し毛色が異なり、技術的なトピックを扱うエントリーです。 gs2.hatenablog.com こちらで告知した消費アクションの分岐処理を実装するにあたって、どのようなアプローチで課題に向き合ってきたのかを解説しようと思います。 非同期処理とリトライ まずは、非同期処理とリトライについて考えてみましょう。 非同期処理とは？ 「API を呼び出すと、処理の結果が返ってくる。処理の途中でエラーが発生したらエラーが返ってくる」というのが同期処理です。 この場合、エラーハンドリングは呼び出し元に委ねられますので、比較的シンプルに処理を行うことができます。 一方で、非同期処理とはどういうものか？というと 「API を呼び出すと、処理を動かし、処理IDを応答する」「処理IDを指定して完了を通知」「処理IDを指定して処理結果を取得」 というように呼び出し
『アイドルマスター スターリットシーズン』でマイクが巨大化する現象発生。リトライする度に変化し、マイクと一体化するアイドル - AUTOMATON
バンダイナムコエンターテインメントからPlayStation 4/PC（Steam）向けに発売中の『アイドルマスター スターリットシーズン』。同作においては、「アイドルマスター」シリーズの4ブランドから女性アイドルたちが登場。合同ユニット「プロジェクトルミナス」の交流や挑戦の過程が描かれていく。そうした中ではアイドルの成長も描かれるが、成長するのはアイドルだけではなかったようだ。特定の条件下でマイクが巨大化する現象が発見され、話題となっている。 マイクの巨大化現象は、ステージでリトライを繰り返すと、クライマックスアピール内で出現するマイクのサイズが徐々に巨大化すると考えられている。具体的な手順としては、まずクライマックスアピール「オーバー・ザ・トップ」を選択したユニットで、ステージを開始する。通常どおりステージを盛り上げていき、オーバー・ザ・トップの発動後にリトライを実施。リトライ後のステ
Pythonでリトライ処理を簡単に追加できる「tenacity」を使ってみる | DevelopersIO
今回はPythonで簡単にリトライ処理を追加できる「tenacity」を使ってみます。 デコレータ形式で簡単にリトライ処理を追加できるので便利です。 tenacityについて プログラムを書いていて、HTTPの通信などでリトライ処理を実装する機会は多いと思います。 今回はそんなリトライ処理を簡潔に書けるtenacityの使い方を説明します。 インストール インストールはpipで可能です。 pip install tenacity 使い方 シンプルな例 import random from tenacity import retry @retry def random_error(): num = random.randint(0, 10) if num > 4: print(f"Error: num={num}") raise Exception("Error!") else: retur
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ネットワーク越しリトライ考 - その手の平は尻もつかめるさ
非同期処理とリトライと冪等性 - GS2 Blog