全5827文字
PR

 近年、ITシステムの大規模障害によって企業が経営責任を問われるケースが増えている。システム障害が大きな話題となるのは、かつて業務効率化のためのツールだったITが、今や企業のビジネスそのものとなったためだ。分散化の傾向が強まり、複雑さを増す最近のシステム障害対策は以前より難しくなっている。システムの堅固さを追求するだけでなく、いずれ障害が起こる前提で回復性(レジリエンシー)をも重視した設計・運用が重要だ。そこでこの特集では回復性の視点から、システム障害対応のポイントを解説する。

「いずれどこかが壊れる」前提で防御的実装を考える

 今回は近年の複雑化するシステム障害に対応するための防御的実装ならびに回復性を備えた実装について見ていこう。この特集の第1回、第2回でも触れたが、最近のシステムアーキテクチャーはシンプルな一枚岩のモノリシックな構成を脱し、マイクロサービスを採用した分散型かつクラウドネーティブなものに変化しつつある。他社のサービスとネットワーク経由で連携して、エンドユーザー向けのサービスを提供するケースも珍しくない。こうしたサービスでは、ネットワークや他社提供のAPI(アプリケーション・プログラミング・インターフェース)など、自社ではコントロールできない範囲で障害が起こる可能性もある。

関連記事 企業を揺るがす大規模システム障害、「分散化」への対応が成否を分ける

 自社で制御しきれないシステム障害を織り込んだ上でサービス品質を維持するには「いずれどこかのタイミングで壊れる」前提で、1カ所の障害が他に連鎖しないような防御的実装が必要だ。ここでは防御的実装を実現する5つのポイントと、障害が起こった後の回復性の維持について解説する。

 防御的実装は、従来のモノリシックアーキテクチャーを採用したシステムの時代から存在しており、主に他システムとの連結部分で採用されてきた。マイクロサービスアーキテクチャーのような分散型システムでは、サービス間の接点が飛躍的に多くなる。一部の障害が周辺サービスに連鎖し、大きな障害へつながる可能性があるため、アーキテクチャー全体で適切に防御的実装を施す必要がある。防御的実装で考慮すべきポイントには以下の5つがある。

【防御的実装で考慮すべきポイント5つ】
  • 一時的な呼び出し失敗に対するリトライ
  • 長時間にわたる呼び出し失敗に対するサーキットブレイカー
  • 呼び出し先パフォーマンス劣化に対するタイムアウト
  • 呼び出し元からの過剰呼び出しに対するスロットリング
  • 呼び出し先の変更に対するサービスディスカバリー/サービスレジストリー
考慮すべきシステム障害のパターンと防御的実装
考慮すべきシステム障害のパターンと防御的実装
出所:野村総合研究所(以下の図も同じ)
[画像のクリックで拡大表示]

一時的な呼び出し失敗に対するリトライ

 最初に考慮すべきは、ネットワークの品質劣化や対向サービスの障害による呼び出し失敗だ。これに対しては、同じ呼び出し先に対して再度呼び出しを行い、処理の再開を試行する(リトライを試みる)ことが基本である。

 多くの場合は一時的な障害なため、数回のリトライで復旧できる。一方、長時間にわたる障害の場合は、多対多のサービス間で延々と呼び出しをリトライすることになる。リトライが続くとネットワークへの負荷が増大したり、障害復旧直後にサービスへの呼び出しが集中して、障害が広く波及したりする。

 一時的な障害に対しては、短い間隔でリトライすることで早期の復旧を目指したい。しかし、長時間にわたる障害では短時間でのリトライ試行そのものが全体的な負荷増大につながる点が悩ましい。この問題を解決するアルゴリズムに「エクスポネンシャル・バックオフ」がある。エクスポネンシャル・バックオフでは「毎回5秒でリトライする」といった固定間隔のリトライではなく、1秒、2秒、4秒、8秒、16秒と段階的に間隔を長くしながらリトライを繰り返す。一時的な障害から早く復旧できるうえ、長時間に及ぶ障害の場合も負荷を軽減できる。