全2134文字
PR

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

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

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

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

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

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

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

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