日経SYSTEMS2019.10.15コピーしましたPR全2215文字サービスを止めないためには素早い復旧作業が大切だ。分散システムでは冗長構成により完全停止を回避できる。システムの復元力を高める方法を学ぼう。止まらないシステムの構築にはレジリエンシー(復元力や再起力)を高めることが重要である。冗長化された分散システムでは1つのサーバーがダウンしても他のサーバーで処理を代替して継続できる。一部のサーバーがダウンしている間はシステム全体で処理能力が低下する。素早い復旧の仕組みは欠かせない。通信遅延時のリトライ処理を工夫マイクロサービスアーキテクチャーは小さなサービスを連携し、一連のサービスを提供する。そのためサービス間の接続が増える。サービス間の通信が多ければ、当然失敗する可能性も高くなる。この問題を解決するのにリトライ機構がある。APIの呼び出しに失敗したらリトライすればいいというわけだ。「リトライ処理を正しく行うのは意外と難しい」(NTTデータの神保良弘ITサービス・ペイメント事業本部カード&ペイメント事業部デジタルペイメント開発室長)という。通信エラーが発生した際、やみ雲にリトライする設定では無駄にリトライ処理が繰り返されてシステムに負荷をかけることになる。RESTを使ったAPIの呼び出しでは、HTTPのステータスコードが400系のエラーであればリトライは不要だ。呼び出し側のリクエストに問題があるため、同じリクエストを何度送っても同じエラーが返るだけだからだ。一方で500系のエラーは呼び出される側に問題があるためリトライによって解決できる可能性がある。Unavailable」といったエラーだ。これらのエラーをリトライ対象とすべきである。注意したいのはインフラ側で自動リトライをかける場合だ。リトライ回数を制限する、リトライ間隔を徐々に開けるといった設計にしておかないと「通信遅延が発生した際にリトライ回数が増えて負荷が高まる」(神保室長)という。現在は、HTTPのステータスコードでリトライ回数などを変更できるソフトウエアが存在する。サービス間の連携を管理する「Istio」だ。このようなソフトを利用してアプリ層でリトライ処理を最適化したい(図1)。図1●アプリケーション層でリトライを判断する[画像のクリックで拡大表示]この記事は有料会員限定です「日経SYSTEMS」定期購読者もログインしてお読みいただけます。サーキットブレーカーは慎重にみずほ銀行システム統合、苦闘の19年史Amazonランキング書籍総合1位(2/11-13)!前代未聞の労力と巨費を投じたプロジェクト、2度の大規模システム障害を乗り越えどのように全面刷新したのか、全貌を解き明かす。現場の負担軽減を!医療界でのAWS活用法500万社が導入。き》データサイエンティスト育成で定評のある大阪ガスと、データ分析の専門家が共同で開発した特別プログラ...SEのための「システム営業力」養成講座SEとして仕事をする方が、顧客や経営層に対する提案力や会話力を身につけるための講座です。情報銀行の成り立ち、事例、現状課題やその行方を網羅。経営戦略である以上、「会計」の知識やスキルが欠かせません。