サービスを止めないためには素早い復旧作業が大切だ。分散システムでは冗長構成により完全停止を回避できる。システムの復元力を高める方法を学ぼう。

 止まらないシステムの構築にはレジリエンシー(復元力や再起力)を高めることが重要である。冗長化された分散システムでは1つのサーバーがダウンしても他のサーバーで処理を代替して継続できる。ただし一部のサーバーがダウンしている間はシステム全体で処理能力が低下する。素早い復旧の仕組みは欠かせない。

通信遅延時のリトライ処理を工夫

 マイクロサービスアーキテクチャーは小さなサービスを連携し、一連のサービスを提供する。そのためサービス間の接続が増える。サービス間の通信が多ければ、当然失敗する可能性も高くなる。この問題を解決するのにリトライ機構がある。APIの呼び出しに失敗したらリトライすればいいというわけだ。

 ただ「リトライ処理を正しく行うのは意外と難しい」(NTTデータの神保良弘ITサービス・ペイメント事業本部カード&ペイメント事業部デジタルペイメント開発室長)という。通信エラーが発生した際、やみ雲にリトライする設定では無駄にリトライ処理が繰り返されてシステムに負荷をかけることになる。

 例えばRESTを使ったAPIの呼び出しでは、HTTPのステータスコードが400系のエラーであればリトライは不要だ。呼び出し側のリクエストに問題があるため、同じリクエストを何度送っても同じエラーが返るだけだからだ。

 一方で500系のエラーは呼び出される側に問題があるためリトライによって解決できる可能性がある。例えば処理方法がサーバー側で分からない「500 Internal Server Error」やサーバー側がリクエストを処理する準備ができていない「503 Service Unavailable」といったエラーだ。これらのエラーをリトライ対象とすべきである。

 注意したいのはインフラ側で自動リトライをかける場合だ。リトライ回数を制限する、リトライ間隔を徐々に開けるといった設計にしておかないと「通信遅延が発生した際にリトライ回数が増えて負荷が高まる」(神保室長)という。現在は、HTTPのステータスコードでリトライ回数などを変更できるソフトウエアが存在する。例えばサービス間の連携を管理する「Istio」だ。このようなソフトを利用してアプリ層でリトライ処理を最適化したい(図1)。

図1●アプリケーション層でリトライを判断する
[画像のクリックで拡大表示]

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。今なら有料会員(月額プラン)が12月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら