アプリケーションのレジリエンスとは

アプリケーションは、顧客取引の処理やサプライチェーンの管理から、従業員の共同作業の実現やリアルタイム・データの分析まで、現代ビジネスのほぼすべての側面を支援します。

これらのアプリケーションに障害が発生すると、深刻な影響が生じる可能性があります。ダウンタイム（アプリケーションが利用できなくなったり、正しく機能しなくなったりする期間）は、評判の低下、ユーザーエクスペリエンスの低下、重大な経済的損失につながる可能性があります。

実際、98%の組織が、ダウンタイム・コストが1時間あたり10万ドルを超えていると最近報告しており、3分の1の組織は損失が100万ドルから500万ドルの間であると見積もっています。

レジリエントなアプリケーションを設計および実装することで、組織はこれらの中断を回避・軽減できます。

アプリケーションのレジリエンスは、2つの基本原則に左右されます。

• フォールト・トレランス： アプリケーションの一部に障害が発生した場合に、その動作を継続する能力。

• 高可用性：システムがほぼ100%の時間アクセス可能かつ信頼できる状態を維持する能力。

レジリエントなアプリケーションは、アプリケーション・アーキテクチャーの脆弱性を軽減し、運用効率を向上させ、予期せぬ障害に直面しても一貫したユーザー・エクスペリエンスを確保する上で役立ちます。

レジリエントなアプリケーションを作成し、デプロイするために、開発者とITチームはアプリケーションのライフサイクルを通じて、いくつかのツールとプラクティスを用いることができます。

レジリエントなアプリケーションの一般的なコンポーネントには、以下が含まれます。

• 冗長性
• ロード・バランシング
• 障害封じ込め
• 可観測性
• 自動化
• グレースフル・デグラデーション
• 拡張性

冗長性とは、重要なシステムのバックアップ・バージョンがあることを意味します。システムに障害が発生した場合、バックアップが引き継ぎ、システムの稼働を継続することができます。

たとえば、支払い処理サービスでは、多くの場合、そのサービスの複数のコピーが異なるサーバーで実行されます。あるサーバーがクラッシュしても、他のサーバー上のコピーが自動的にワークロードを引き継ぐので、顧客は問題に気づきません。

組織は多くの場合、主要領域で冗長性を構築します。

• データベース：データの複数のコピーを異なる場所に保管して、1つのシステムに障害が発生した場合に何も失われないようにします。

• データセンター：複数の物理拠点でアプリケーションをホスティングし、1つの拠点がダウンした場合でも運用を継続できるようにします。

• クラウド環境：Amazon Web Services（AWS）、Microsoft Azure、IBM® Cloudなどのリージョンまたはプロバイダー間でアプリケーションを分散して、単一障害点を排除します。

• ネットワーク接続：複数のインターネットまたは電気通信プロバイダーを活用し、停電時の接続性を維持します。

負荷分散では、ネットワーク・トラフィックを複数のサーバー間で効率的に分散し、アプリケーションの可用性を最適化します。これにより、システムは個々のコンポーネントに障害が発生したり、過負荷になったりした場合でも、パフォーマンスと可用性を維持できるため、アプリケーションのレジリエンスにとって負荷分散は重要です。

たとえば、1つのサーバーが応答しなくなった場合、ロード・バランサーはトラフィックを他の正常なサーバーに自動的にリダイレクトし、アプリケーションをオンラインに維持できます。

障害封じ込めは、分散システム内の重要コンポーネントを隔離する設計手法であり、局所的な問題がシステム全体の停止に連鎖することを防ぎます。

封じ込めはマイクロサービス・アーキテクチャーでは特に重要です。適切に封じ込められていない場合、1つのサービス内の障害が、他の多くの依存関係に急速に影響を及ぼす可能性があるからです。

サービス・メッシュは、エラーを封じ込める上で特に役立ちます。これらのインフラ・レイヤーは、分散アプリケーション内のマイクロサービス間の通信を管理できるようにサポートし、以下を提供します。

• 自動再試行：一時的な問題（短時間のネットワーク障害など）が原因でリクエストが失敗した場合、メッシュはすぐに放棄するのではなく、自動的に再試行します。

• 回路の遮断：メッシュはサービスの正常性を監視し、問題が発生しているサービスへのリクエスト送信を一時的に停止することで、システム全体のクラッシュを防ぐと同時に、サービスが回復する時間を確保します。

• 分散トレース：メッシュは、異なるサービス間を移動するリクエストを追跡することで、チームが速度低下を発見し、問題が発生した場所を正確に特定するのに役立ちます。

これらの機能を組み合わせることで、あるサービスの障害が他のサービスに広がらないようにすることができます。たとえば、電子商取引サイトで製品推奨エンジンに障害が発生した場合、サービス・メッシュはこの障害を検出し、問題のあるサービスへのリクエストの到達を停止し、状況に応じてトラフィックを再ルーティングできます。ユーザーは中断することなく閲覧や購入を継続できます。

可観測性により、チームはメトリック（応答時間などのパフォーマンス指標）、ログ（エラーやクラッシュなどのイベント記録）、トレース（リクエストがシステム内でたどる全体的な経路）という3つの主要な種類のデータを使用して、システムの正常性をリアルタイムで監視できます。

これらの信号を捕捉・分析することで、チームは異常を検知し、問題を迅速に診断し、ダウンタイムを減らすことができます。たとえば、顧客からWebページの読み込みが遅いという報告があった場合、オブザーバビリティー・ツールを使用することで、エンジニアは遅延の原因となったサービスまでリクエストを追跡し、より多くのユーザーに影響が及ぶ前に問題を修正できます。

自動化は、システムが手動による介入を必要とせずに問題に対応できるようにすることで、アプリケーション・レジリエンスにおいて重要な役割を果たします。

たとえば、オブザーバビリティー・ツールは問題を検知し、冗長性はバックアップ・リソースを提供します。自動化は、これらの機能を連携させ、復旧プロセスを調整します。効果的な自動化で、復旧時間を大幅に短縮し、何時間にも及ぶ可能性のある手動トラブルシューティングを数秒の自動応答に変えることができます。

アプリケーション・レジリエンスにおける主要な自動対応には次のようなものがあります。

• スクリプトによるフェイルオーバー：故障したシステムから、冗長計画によって指定されたバックアップ・システムに自動的にオペレーションを転送する、あらかじめ決められた一連のアクション。たとえば、プライマリ・データベースがクラッシュした場合、システムは自動的にバックアップ・データベースに切り替わり、数秒以内にすべてのトラフィックをそこにリダイレクトします。

• リソースの再プロビジョニング：コンポーネントに障害が発生したときに、人間による介入を必要とせず新たに仮想マシンを作成して問題のあるコンポーネントと入れ替えるなど、新しいインスタンスを自動的にプロビジョニングしたり、リソースを再割り当てしたりします。

• 自己修復ワークフロー：監視アラートと復旧アクションを調整し、人間の介入なしにサービスを復元します。たとえば、アプリによるメモリーの使用量が増えすぎた場合、ユーザーが速度の低下に気づく前に、システムが自動的にそのアプリを再起動します。

コンテナ化されたアプリケーションを管理するためのオープンソース・システムであるKubernetesなどのツールは、オートメーションがレジリエンス・コンポーネントをどのように結び付けるのかを示します。Kubernetesは、組み込みの正常性チェックを通じて障害を検知し、正常なノード全体でワークロードを再スケジュールし、自動化されたワークフローを通じてサービスの継続性を維持できます。

グレースフル・デグラデーションには、主要な機能を維持しながら、ストレス時に不要な機能を取り除くことが含まれます。たとえば、ブラック・フライデーのトラフィックが急増している間、小売業者はショッピング・カートとチェックアウトが機能し続けることを確実にするために、顧客レビューやウィッシュ・リストを一時的に無効にする場合があります。

スケーラブルなアプリケーションは、ワークロードの需要に応じてリソースを自動的に調整できます。この機能は、トラフィックが変動する場合でも、性能と可用性を確保する上で役立ちます。

スケーラビリティはさまざまな方法で実現できます。たとえば、クラウドベースのプラットフォームは、組み込みのロード・バランサー、自動スケーリング、マルチリージョン複製（複数の地理的場所にデータとサービスをコピーし、パフォーマンスと信頼性を向上させること）などの機能を通じて拡張性を提供します。これらの機能により、サービスはトラフィックをインテリジェントに分散し、アップタイムを維持し、状況の変化に応じて復旧時間を最小限に抑えることができます。

たとえば、クラウドホスト型ストリーミング・プラットフォームが通常、100台のサーバーで動作しているとします。しかし、ライブ・グローバル・イベント中には、自動的に複数の地域にある10,000台のサーバーに拡張できるため、何百万人もの同時視聴者にスムーズな再生を提供できます。

ソフトウェア・アプリケーションは事業オペレーションと消費者の日常生活の両方に不可欠なものとなっているため、これらのアプリケーションが予期せぬ中断に耐え、ほぼすべての状況で機能し続けることが肝要です。

特に4つの要因が、アプリケーション・レジリエンスへの関心の高まりを後押ししています。

• 消費者の高い期待
• ダウンタイムのコスト
• アーキテクチャーの複雑さ
• 規制による圧力

顧客は、デジタル・サービスが常に機能することを期待しています。Google社によると、モバイル・ページの読み込みに3秒以上かかる場合、訪問者の53%がそのページを放棄します。

銀行アプリ、eコマース・プラットフォーム、医療ポータルのいずれであっても、ダウンタイムは顧客の離脱、ソーシャル・メディアでの反発、永続的なブランドへのダメージを引き起こす可能性があります。アプリケーションの可用性は、技術的なメトリクスであるだけでなく、基本的なビジネス要件でもあります。

アプリケーションの停止は、あらゆる規模の組織にとってコストがかかる可能性があります。一般的なシナリオを考えてみましょう。ある小売ブランドがトラフィックの多いセールイベントを開始しましたが、需要が増えてチェックアウト・サービスに障害が発生するというシナリオを考えてみましょう。数分以内に何千件もの取引が停滞し、顧客が不満を感じるようになり、会社は収益を失います。

停止は、売上の損失だけでなく、修復費用やサービス・レベル契約（SLA）違反から規制上の罰金、顧客への補償、長期的なブランド毀損まで、一連の二次的コストを引き起こす可能性があります。

最近の注目度の高い事件は、その影響がどれほど大きいものになり得るのかを示しています。

• 交通：2016年、データセンターの障害により2,000便のフライトが欠航となり、大手航空会社に1億5000万米ドルの損失があったと報告されました。

• 電子商取引：2018年売上イベントのピーク時に、技術的な障害により、オンライン小売業者は推定7,200万～9,900万米ドルの収益損失を被りました。

• ソーシャル・メディア：2021年、6時間のサービス中断により、インターネット大手企業は約1億米ドルの広告収入を失いました。
  

最新のアプリケーション・アーキテクチャーには、マイクロサービス、マルチクラウド環境、コード・ライブラリーなど、多くの可動部分があります。これらのモジュール式コンポーネントは拡張性を向上させる一方で、潜在的な障害点の数も増やします。

回復力のある設計と実装がなければ、軽微な問題でもエスカレートする可能性があります。単一のマイクロサービス障害が発生すると、数十の依存関係に波及する可能性があります。たとえば、製品情報を保管するデータベース・サービスが機能を停止すると、検索、推奨、チェックアウトなどの他の機能が中断される可能性があります。

クラウド・リージョン間のネットワーク中断によって、サービスが断片化され、データの不整合が発生する可能性もあります。コンポーネントが完全に動作しなくなるマイクロサービスの障害とは異なり、こういった接続性の問題は「スプリット・ブレイン」のシナリオを生み出します。これは、アプリケーションの異なる部分は実行を続けますが、相互に通信できない状態です。

たとえば、金融取引アプリの注文システムがリアルタイムの料金体系データから切断されると、ユーザーに誤った見積もりが表示されたり、取引が失敗したりする可能性があります。

アプリケーション・プログラミング・インターフェース（API）の停止により、さらに重要な機能が損なわれる可能性があります。マイクロサービス障害は組織が管理する内部コンポーネントに影響を与えますが、API障害には、アプリケーションが依存しているものの、直接修正できないサードパーティ・サービスが関係します。たとえば、配達アプリのマッピング・サービスがダウンした場合、ユーザーはドライバーを追跡できず、ドライバーはルートを見つけることができないため、コア・アプリケーションが稼働し続けているにもかかわらず、エクスペリエンスが中断されます。

特定の分野や場所では、規制当局がデータの可用性、アプリの回復機能、データ損失の軽減、アップタイムに関して厳しい要件を設定しています。これらの要件により、アプリケーション・レジリエンスが技術的な目標からコンプライアンスの問題にまで高まります。

一部のデータ保護およびプライバシー法には、セキュリティ義務に加えて可用性の基準が含まれるようになりました。たとえば、一般データ保護規則（GDPR）では、個人データは保護され、アクセス可能であることが求められています。システム障害が発生した場合、組織は失われたデータを回復することが想定されています。

特に規制の厳しい業種・業務では、非常に厳格な基準が課せられています。

サーベンス・オクスリー法（SOX）では、災害復旧計画を明示的に義務付けてはいませんが、多くの組織では、この法律に準拠し、準拠を証明するために、バックアップ・システムと正式な復旧手順を維持しています。

金融機関はまた、事業継続性計画や復旧時間目標に関する詳細なガイドラインを提供する連邦金融機関検査協議会（FFIEC）などの団体からの、業界固有の規制や勧告にも直面しています。

医療保険の相互運用性と説明責任に関する法律（HIPAA）に基づき、対象となる事業体は、管理的、物理的、技術的な保護措置を実施して、electronic Protected Health Information（ePHI）の可用性と完全性を確保する必要があります。HIPAAでは24時間365日のアクセスを義務付けていませんが、治療のために必要な場合には、患者データへのアクセスを維持することを医療組織に義務付けています。

HIPAAセキュリティー・ルールでは、データのバックアップ・プラン、災害復旧手順および緊急モード・オペレーションが義務付けられており、多くの組織に高度なフェイルオーバーおよびデータ複製ストラテジーに投資することを促しています。

システムが現実世界の混乱に耐えられるようにするために、組織は継続的な測定と事前対応的なテストを組み合わせてアプリケーション・レジリエンスを検証します。これらのアプローチにより、チームはパフォーマンスを監視し、脆弱性を特定し、アプリケーションが迅速かつ効果的に回復できるかどうかを確認できます。

とりわけDevOpsチームは、継続的インテグレーション/継続的デリバリー・パイプライン（CI/CDパイプライン）にレジリエンス・プラクティスを頻繁に統合します。それにより、フェイルオーバー手順のテストを自動化し、構成の変更を検証し、不安定なデプロイメントをロールバックして問題を早期に発見し、中断によるユーザーへの影響を防ぐことができます。

組織は、アプリケーション・レジリエンスを評価する際に、いくつかの主要なメトリクスを参考にしています。

組織は、現実世界に近い視点を得るためにテストへとますます目を向けています。メトリクスが基盤を提供する一方で、テストは組織が理論上の備えから実証されたレジリエンスへと進むのに役立ちます。

人工知能（AI）と機械学習（ML）は、組織のレジリエンスへの取り組み方を変革しています。これらのテクノロジーは、ダウンタイムを防ぐための強力な新しいツールをもたらす一方で、独自の課題ももたらします。

最大の課題の1つは、AIワークロードがリソースを大量に消費することです。多くのモデルはグラフィックス・プロセッシング・ユニット（GPU）に依存しており、GPUは高価であるだけでなく、クラウド・リージョン間で複製するのも困難です。そのため、レジリエンスの重要な要素である冗長性の実現が難しくなります。

AIシステムは、予期せぬ形で障害を起こすこともあります。時間の経過とともに精度が低下することがあり、これはモデル・ドリフトとして知られる問題です。また、システムを欺くように設計された悪意のあるデータ、いわゆる敵対的インプットに遭遇することもあります。このような障害は、予測や封じ込めがより困難となることがあります。

さらに、AI機能が遅延したり停止したりする場合があります。これはリソース制約やレイテンシーによってクラウド環境でよく発生する問題です。そのような場合でも、アプリケーションの残りの部分は信頼性をもって稼働し続けなければならず、優雅な劣化（グレースフル・デグラデーション）戦略への負担が一層高まります。

同時に、AIにはレジリエンスを強化するための重要なユースケースがあります。

• 予測分析は、過去のパターンやトレンドを分析して将来の障害を予測します。これにより、チームは問題が発生する前にハードウェアを事前に交換したり、リソースを調整したりできます。例えば、温度やエラー率のトレンドに基づき、ディスク障害を数日前に予測することが可能になります。

• インテリジェント修復は、AIを活用してより賢明な復旧判断を行います。従来の自動化システムが単に障害の発生したサービスを再起動するだけなのに対し、AIを活用した修復ではパターンを分析し、最適な復旧戦略を選択できます。例えば、負荷の少ないリージョンへのトラフィックの迂回や、予測される需要に基づくリソースのスケーリングなどです。

• 異常検知により、AIはルールベースの監視では見逃される可能性のある微妙なリアルタイムの不規則性を特定できます。例えば、個々のメトリクスは正常に見えても、メトリクスの異常な組み合わせが新たな問題の兆候を示している場合などです。

• AI駆動型テストにより、DevOpsチームはソフトウェア開発プロセスの初期段階で、より複雑な障害シナリオをAIを使ってシミュレーションできるようになります。

要するに、AIは新たな複雑性をもたらす一方で、クラウド・ネイティブ環境やDevOpsパイプラインに統合されることで、より迅速な復旧、より高度な監視、そして全体としてよりレジリエントなアプリケーションを実現することも可能にします。