「リトライ」「サーキットプレーカー」を採用すべきクラウドアプリとは？

クラウドベースアプリケーションのデザインパターンである「リトライ」「サーキットプレーカー」は、どのようなアプリケーションを構築するのに向いているのか。具体例を交えて解説する。

公開 2021年09月22日 05時03分

著者

Zachary Flower

[TechTarget]

印刷する連載新着通知を受け取る

　前編「『バルクヘッド』とは？　障害に強いクラウドアプリのデザインパターン」は、クラウドサービスで稼働するアプリケーション（以下、クラウドベースアプリケーション）の主なデザインパターン5つのうち「バルクヘッド」を取り上げた。中編は「リトライ」「サーキットプレーカー」の2つを紹介する。

併せて読みたいお薦め記事

さまざまなクラウドベースアプリケーション開発手法

アプリケーション開発に役立つツール

2．リトライ

　障害発生を想定したデザインパターンがリトライだ。リトライを採用したアプリケーションは、一度失敗した操作を安全に再試行できる。企業はリトライを採用することで、長期的な保守が最小限で済む、障害許容性のあるアプリケーションを構築可能だ。

　リトライは、外部とデータをやりとりしなければならないアプリケーションに適する。特定のイベントが発生した際に、Webアプリケーションが別のWebアプリケーションにイベントの成否を通知する「Webフック」は、しばしばリトライを採用している。

　リトライは、一度送信に失敗したデータの再送信が可能なことを、送信側と受信側の両方が知っていなければ機能しない。Webフックでは、各Webフックに識別子を与えることで、同じリクエストを何度も処理していないかどうかを受信側が検証できるようにしている。これにより重複を回避しつつ、送信側も冗長なデータを誤って再送信するエラーを把握できるようになる。

3．サーキットプレーカー

　クラウドベースアプリケーションは、特にデータのやりとりの頻度を予測できないプロセスがある場合、通信量の増加への対処が問題になる恐れがある。サーキットプレーカーは、必要以上にリソースを消費する寸前にプロセスを中断することで、プロセスの「暴走」を防ぐ。

　サーキットプレーカーの仕組みを考えるに当たって、複数のデータソースからレポートを生成するWebアプリケーションを考える。通常ならレポートを数秒で生成できるところ、サーバへの問い合わせに余計な時間がかかった場合、レポートの生成にも時間がかかることになる。このWebアプリケーションがサーキットプレーカーを採用していれば、完遂に長時間を要するクエリが、リソースを占有することを防げる。これにより、例えば生成時間が10秒を超える場合に、レポート作成を止めるといったことが可能だ。

　後編は4、5つ目のデザインパターンを紹介する。