ハイブリッドおよびマルチクラウドアーキテクチャにより、レジリエンスを左右する要因は根本的に変化しました。現在、アプリケーションは複数の地域、プロバイダー、SaaSプラットフォーム、コンテンツ配信ネットワーク（CDN）、アイデンティティサービス、エッジ環境にまたがっています。こうした広がりは俊敏性と拡張性をもたらす一方で、システム全体に及ぶリスクも生じさせます。
しかし、デジタルプレゼンスを支えるテクノロジーとインフラストラクチャを管理するチームにとって、もはや問題は障害が発生するかどうかではありません。基盤となるアーキテクチャが、障害の影響を封じ込め、障害の発生中に適応し、さらに障害を糧に改善できるよう設計されているかどうかです。ここで、反脆弱性を備えたサイバーレジリエンスが戦略的に重要になります。
“サイバーレジリエンスを考慮して設計されたアーキテクチャは、単に「復旧」するだけではありません。障害の最中にも適応し、次に備えてさらに強靭になります。”
第1部では、全2部構成の本シリーズにおいて、サイバーレジリエンスを反脆弱的なものにする実践方法を明らかにしました。ここからは、どのように各階層が、影響範囲の制御、ポリシーに基づく適応、多様化、継続的な学習を、実際のインシデント発生中および発生後に取るべき具体的な行動へとつなげるのかを見ていきます。
レジリエントからアンチフラジャイルへ
「レジリエントなアーキテクチャ」とは、従来、障害を乗り越えることを意味していました。アンチフラジャイルなレジリエンスは、この概念をさらに一歩進めたものです。
アンチフラジャイルなシステムは、障害発生時の影響範囲を限定し、障害が進行する中で適応します。こうしたレジリエンスの実践では、障害から得た教訓を将来のアーキテクチャの動作に反映し、再発の可能性と影響を低減します。
アンチフラジャイル設計では、障害を例外として扱うのではなく、混乱を通常の運用条件として捉えます。アンチフラジリティを大規模に運用へ取り入れるには、企業に体系的な枠組みが必要です。アンチフラジャイルなレジリエンスの5段階モデルが、その枠組みを提供します。
アンチフラジャイルな企業を構成する5つの階層
各階層は、レジリエンスを設計に組み込むべき「領域」を定義します。アンチフラジャイルな実践は、レジリエンスを向上させる「方法」を定義します。両者を組み合わせることで、混乱をアーキテクチャの進化へと変えます。
1. グローバル階層：システム全体の障害が拡大する前に抑制
グローバル層は、DNS、アイデンティティ、フェデレーションによる信頼、グローバルトラフィック管理など、複数のリージョンや環境にまたがる共通サービスを統制します。ここでは、依存先が不安定になると、チケットが起票される前にルーティングを自動調整する、健全性を考慮したポリシーによって、反脆弱性を備えたレジリエンスを実現します。これにより、名前、認証、ルートに関する影響範囲を設計段階から抑え、グローバルな代替経路を使用してユーザーフローを維持します。
ここでの障害は個々のワークロードより上位のレイヤーで発生するため、特に危険です。グローバルルーティングまたはアイデンティティに障害が発生すると、それらに依存するすべてのサービスが同時に影響を受けます。
この階層における反脆弱性の実践では、3つの要素に重点を置きます。影響範囲を制御するには、信頼境界と障害境界を明確に定義し、1つのリージョン、クラウド、または依存関係で発生した障害が際限なく波及しないようにします。ポリシー主導の適応では、ハードコードされた構成を、現在の状態に応じて対応するポリシーに置き換えます。トラフィックルーティング、認証、信頼に関する判断は、動的に調整する必要があります。さらに、依存関係を多様化するには、重要なサービスの代替手段を導入するとともに、単一のプロバイダーによってシステムの動作が左右されないよう、選択肢を確保して管理する必要があります。
システムに負荷がかかっている場合、Global Tierでは、プロバイダーレベルの障害が企業全体のインシデントに発展しないよう、信頼境界と障害境界を適用し、ポリシーに基づくルーティングを行う必要があります。インシデント発生時に注視すべき主な指標には、トラフィックの自動再ルーティング速度、認証成功率の変動、DNSフェイルオーバー時間、代替サービスによって処理されたリクエストの割合などがあります。
目的は、単一のプロバイダーまたはコントロールプレーンのイベントによって、企業全体の動作が左右されるのを防ぐことです。グローバルサービスは、障害を拡大させるのではなく、確実に封じ込める必要があります。
2. サイト層：制御された分離と代替実行ゾーンを提供
サイト層では、クラウドリージョン、データセンター、エッジクラスターなど、リージョン単位の実行ドメインを定義します。
従来のモデルでは、各リージョンは冗長化された複製でした。アンチフラジャイルなアーキテクチャでは、各リージョンを意図的に分離されたゾーンとして設計します。各サイトは、3つの機能領域を備えた、境界が明確な障害ドメインとなります。
独立運用では、各サイトを、より大規模な統合ネットワークの一部として機能すると同時に、独立したノードとしても機能できるように構築します。これにより、障害発生時にもユーザー向けの機能を一定程度維持できます。
制御されたフェイルオーバーにより、「ドミノ」効果や、あるサイトの停止が他のサイトに波及する可能性を低減できます。サイトがどのような場合にどこへフェイルオーバーできるかを定めることで、ネットワーク全体で障害の影響を吸収できます。
代替実行パスも重要な機能の1つです。障害が発生しているプロバイダーを避け、独立した代替パスへトラフィックを能動的に誘導することで、重要なサービスを障害の影響経路から切り離します。
システムに負荷がかかっている場合、サイト階層は、各サイトが影響範囲の限定された障害ドメインとして機能できるようにする必要があります。連鎖的な影響を生じさせることなく、トラフィックを排出するか、他のリージョンまたはプロバイダーに移行できることが求められます。この階層で追跡すべき主な指標には、サイト分離の平均解決時間、プロバイダー間のトラフィック送出時間、事前検証済みの代替経路が用意されている重要サービスの割合などがあります。
この階層では、リージョン、CDNパス、またはネットワークトランジットプロバイダーの機能が低下した場合に、実行可能な代替手段を確保する必要があるため、依存先の分散が極めて重要です。この階層により、システミックリスクを管理可能な局所的障害へと転換できます。
3. プラットフォーム層：対応を自動化し、ワークロードのポータビリティを実現
プラットフォーム層には、Kubernetesクラスター、仮想化環境、およびワークロードをホストするあらゆるコンピューティング基盤が含まれます。ハイブリッドマルチクラウド環境では、システム全体に影響する事象が発生した際、人による対応サイクルでは遅すぎるため、適応をどれだけ迅速に開始できるかは、ポータビリティと自動化によって決まります。
この階層におけるアンチフラジャイルの実践では、レジリエントな企業での対応を自動化するランタイム自動化を重視し、インシデントが深刻化する前に適応を開始できるようにします。
もう1つの重要なプラクティスは、ワークロードモビリティです。これは、継続性を確保するためにアプリケーションを複数の環境へデプロイし、冗長化および多様化されたワークロードのネットワークを構築することを意味します。
負荷がかかった状況では、Platform Tierにサーキットブレーカーポリシーを適用し、インシデントの進行中でもキャパシティや態勢を切り替えられるようにすることで、システムの自動スケーリングを支援できる必要があります。この階層では、システムが最初の自動アクションを実行するまでの時間、インシデントあたりのポリシー変更回数、2つ目の実行環境を備えたワークロードの割合を追跡することが重要です。
健全性を示すシグナルが悪化した場合、ルーティングの判断、スケーリングの動作、セキュリティ態勢を自動的に調整する必要があります。自動化により、インシデントが深刻化する前に適応を開始できます。また、ワークロードの分散により、重要なサービスを常に利用可能な状態に保ちます。この階層によって、障害発生時に段階的な機能低下にとどめられるか、連鎖的な障害に至るかが決まります。
4. アプリケーション層：ユーザー体験を損なうことなく障害の影響を吸収
アプリケーションは、ビジネスロジックを実行し、ユーザーに価値を提供します。従来型のアーキテクチャでは、インフラストラクチャの障害がアプリケーションの障害に直結することが少なくありませんでした。
アンチフラジャイル設計では、全面的な障害に陥るのではなく、グレースフルデグラデーションを含む段階的な適応を取り入れます。停止やその他の中断によってサービスの大部分がオフラインになった場合でも、機能を制限することで致命的な障害を防止できます。
ストレス発生時の機能の優先順位付けも、Application Tierの重要な要素です。これにより、完全なユーザー体験を提供できない場合でも、ユーザーの中核的なワークフローを引き続き利用できるようにするとともに、オプション機能が原因で重要なサービスが停止するのを防ぎます。
インテリジェントな再試行とサーキットブレーカーは、依存先で障害が発生した際に、負荷を増幅させて障害を加速させる無条件の再試行ループに陥ることなく、アプリケーションが状況に応じて適応的に対応できるようにする戦略です。
アプリケーション層では、コアワークフローを正常に保てるよう、非コア機能の負荷を軽減する必要があります。クライアントは、DNSやID管理などの上流側の正当な動作変更に適応し、サンダリングハードを回避する必要があります。部分的な障害発生時におけるチェックアウトとログインの成功状況、リトライバジェットの消費量、サーキットブレーカーのオープン／クローズ率を必ず監視してください。
アプリケーションは、アップストリームの正当な動作変更に対応できなければなりません。IDプロバイダー、DNSレスポンス、APIは予告なく変更される可能性があることを前提とする必要があります。この階層では、レジリエンスはインフラストラクチャの稼働時間ではなく、ユーザーエクスペリエンスの継続性によって評価されます。
5. 管理層：運用イベントをガバナンスとポリシーの改善につなげる
管理層は、オブザーバビリティ、オーケストレーション、分析、ガバナンスを網羅します。テレメトリに基づくガバナンスがなければ、レジリエンスの向上は停滞します。インシデントはアーキテクチャの改善につながらず、単にチケットがクローズされるだけになります。
この階層におけるアンチフラジャイルの実践では、複数の要素に重点を置きます。その1つが、テレメトリを意思決定に活用する、観測に基づくガバナンスです。設計上の想定を、ストレス下で捉えた実際の挙動に置き換えることで、レジリエンスが向上します。
継続的な検証を確実に行うため、定期監査時や障害発生後だけでなく、レジリエンスに関する前提、セキュリティ制御、アーキテクチャの動作を常時テストします。
運用データ（レイテンシ、エラー、フェイルオーバーイベントなど）をガバナンスおよびオーケストレーションのフレームワークにフィードバックし、ポリシーを更新・改善することで、予測や仮定ではなく実際のイベントからシステムが学習できるようにします。これにより、実際の挙動に基づいてポリシーを進化させることができます。自動化されたコンプライアンスアーティファクトは、運用イベントを、人手を最小限に抑えながら検証可能で監査に対応できる情報へと変換します。
管理層は、テレメトリがガバナンスへの入力として活用されるようにします。ITインシデントを基に、更新されたルーティング／セグメンテーションポリシーと監査対応可能な成果物を生成します。
主な指標には、インシデントのクローズからポリシー更新までの時間、制御の変更につながったインシデントの割合、自動生成された監査用アーティファクトの数が含まれます。
ここでレジリエンスが戦略的な意味を持つようになります。個々の障害をルーティングポリシーの改善に活用することで、セグメンテーションを向上させ、信頼境界を厳格化し、自動化ロジックを強化できます。
各階層の連携の仕組み
このモデルの強みは、統合にあります。
- The グローバル階層はシステム全体への拡散を抑制します
- The サイト階層では、障害を定義済みのゾーン内に封じ込めます
- The Platform Tierは自動的に適応します
- The Application Tierユーザーエクスペリエンスを維持します
- The 管理層は、障害が発生するたびにシステムを強化します。
これらの階層を一体的に設計することで、分断された運用によって生じる脆弱性を解消できます。
レジリエンスは、もはやNetOps、SecOps、クラウド運用のいずれかだけが担うものではありません。ガバナンス、アーキテクチャ、経営戦略と整合した、部門横断型の運用モデルとなります。
戦略的能力としてのレジリエンス
ハイブリッドアプリケーション環境は、皮肉にも、かつてない規模でリスクの集中をもたらしています。少数のハイパースケールプロバイダーが、世界の重要インフラを支えています。これらのテクノロジーを活用する企業は、その規模とパフォーマンスの恩恵を受けられる一方、少数のプロバイダーに過度に依存することで生じる望ましくない脆弱性も抱えることになります。外部への依存を完全に排除することは、現実的でも望ましいことでもありません。
目標は、プロバイダーが常に正常に稼働することを前提とせず、障害が抑制されないまま波及することのないアーキテクチャを実現することです。
レジリエントなアーキテクチャは、復旧をゴールとは捉えず、同じ障害パターンを繰り返しません。アンチフラジャイルなサイバーレジリエンスは、混乱を運用上の厄介事ではなく、競争上の差別化要因として捉え直します。
反脆弱性を備えたサイバーレジリエンスは、混乱を運用上の厄介事ではなく競争上の差別化要因として捉え直し、各階層で具体的な対策を講じます。グローバルポリシーで影響の拡大を抑え、サイトでは分離と経路変更を行います。プラットフォームは代替キャパシティへの切り替えを自動化します。アプリケーションは段階的に機能を縮退させ、中核となる処理フローを維持します。管理プロセスでは、インシデントから得た知見をポリシーに反映します。このように設計されたアーキテクチャは、単に「復旧」するだけではありません。稼働中にも適応し、次回にはさらに強くなります。
アンチフラジャイルの観点からサイバーレジリエンスについてさらに詳しく知りたい方は、以前のブログ記事「ハイブリッドマルチクラウドのサイバーレジリエンスに向けた新たな戦略」をお読みいただき、ソリューション概要もご覧ください。
サイバーレジリエンス戦略にアンチフラジャイルなアプローチを導入する方法について、さらに詳しく知りたい方は、こちらのアーキテクチャホワイトペーパーをご覧ください。
F5チームにレジリエンスについて相談しませんか？お問い合わせ!
著者について
Griff ShelleyはF5のプロダクトマーケティングマネージャーで、ハードウェア、ソフトウェア、SaaSのアプリケーションデリバリーソリューションを専門としています。革新的なテクノロジーをお客さまの成功につなげることに情熱を注ぎ、グローバルおよびローカルのアプリケーションデリバリー、クラウドサービス、AIデータトラフィックインフラストラクチャの市場投入プロジェクトを推進しています。テクノロジー業界に入る前は高等教育機関でアカデミックアドバイザーを務め、Eastern Washington UniversityとAuburn Universityで学位を取得しました。
Griff Shelleyのその他のブログ記事Colin ClausetはF5のシニアプロダクトマーケティングマネージャーで、SaaSベースのアプリケーションデリバリーソリューションを専門としています。分散型アプリケーションデリバリーのプロジェクトやサービスにおける市場投入戦略を主導し、テクノロジーによって複雑なプロセスを簡素化し、ITプロフェッショナルのニーズにより的確に応える方法を追求しています。F5入社前にはコンサルティングに携わっており、個別の製品にとどまらない包括的なソリューションという視点から、お客さまの課題に取り組んでいます。
Colin Clausetのその他のブログ記事Mark MengerはF5のソリューションアーキテクトで、AIおよびセキュリティ技術のパートナーシップを専門としています。F5のAIリファレンスアーキテクチャの開発を主導し、安全で拡張性の高いAIソリューションの推進に取り組んでいます。グローバルソリューションアーキテクトおよびソリューションエンジニアとしての経験を持ち、F5のセキュアクラウドアーキテクチャに貢献したほか、分散型4階層アーキテクチャを共同開発しました。『Solving IT Complexity』の共著者でもあり、IT課題への対応に関する専門知識を有しています。以前はアプリケーション開発者やエンタープライズアーキテクトを務め、モダンアプリケーション、自動化、AI投資から得られる価値の早期実現に注力していました。
Mark Mengerのその他のブログ記事関連するブログ記事
経営幹部が抱くAIに関する4つの誤解
AIに関する誤解は数多くあります。ここでは、組織が自社環境にAIを導入する際に見直す必要があるかもしれない4つの誤解を紹介します。
IT/OTコンバージェンスの現状と、セキュリティを最優先すべき理由
ITシステムとOTシステムの融合が進むにつれ、攻撃対象領域は拡大します。組織が安全に統合する方法と、F5 ADSPが大規模な運用の保護にどのように役立つかをご紹介します。
AIのレイテンシ：セキュリティを犠牲にできない理由
AIのレイテンシは、単なる速度の問題ではありません。パフォーマンス、セキュリティ、信頼性のバランスを考慮したシステム設計が重要です。
AIアプリケーションを大規模に提供する：ADCの役割
AIアプリケーションを確実に提供するには、高速なモデルや柔軟に拡張できるインフラストラクチャだけでは不十分です。AIアプリケーションの利用方法を管理するための制御レイヤーが必要です。
MCP：AI対応のアプリケーションデリバリを実現する鍵
Model Context Protocol（MCP）は、最新のアプリケーションにおける安全で低遅延なAI統合を可能にします。将来を見据えたアプリケーションデリバリ戦略にMCPが不可欠な理由をご覧ください。
AIガードレールとは？基盤モデルプロバイダーの枠を超えて進化する安全対策
急速に変化する組織の脅威領域におけるリスクをより包括的に捉えるために、AIガードレールの進化が必要な理由をご覧ください。