アプリケーションのレジリエンス: Windowsアプリを利用可能に保つ

紹介

Windowsアプリケーションは、ホストするサーバー以上の多くの要素に依存することがよくあります。データベース、アイデンティティサービス、ストレージ、ゲートウェイ、ネットワーク、ユーザーエンドポイントはすべて、アプリケーションが中断中に使用可能であるかどうかに影響を与える可能性があります。この記事では、ITチームがこれらの依存関係を評価し、既存のWindowsアプリケーションの周りにレジリエンスを設計し、適切なレイヤーを監視し、回復計画が実際にユーザーが依存するビジネス機能を維持するかどうかをテストする方法を説明します。

アプリケーションのレジリエンスとは何ですか？

アプリケーションのレジリエンスとは、アプリケーションとその周囲のインフラストラクチャが、混乱中に重要な機能を提供し続け、障害後に予測可能に回復する能力を指します。

中断は小さいものから大きいものまであり、その原因はハードウェアやオペレーティングシステムの障害、アプリケーションのクラッシュ、更新の失敗、データベースの停止、ネットワークの中断、認証の失敗、リソースの枯渇、利用できない依存関係、またはセキュリティインシデントまでさまざまです。

堅牢なアーキテクチャは、障害が避けられないことを認識し、すべてのインシデントを防ぐことを目指すのではなく、IT組織は各インシデントの影響を制限し、サービスを維持または復元するための制御された回復手順を確立しようとします。

アプリケーションのレジリエンスはサーバーの稼働時間以上のものです

サーバーの可用性を、サーバー上で実行されるアプリケーションの可用性の代理として使用することは一般的な間違いです。

ビジネスアプリケーションが真に利用可能であるためには、いくつかのコンポーネントが同時に利用可能である必要があります。

インフラストラクチャ → オペレーティングシステム → アプリケーション → 依存関係 → アクセスパス → ユーザーセッション → ビジネスプロセス

このチェーン内のいかなる要素に問題が発生すると、アプリケーションが実質的に利用できなくなる可能性があります。

例えば、アプリケーションサーバーは正常である一方で、そのデータベースにアクセスできない場合があります。公開されたアプリケーションは正常に動作しているかもしれませんが、ゲートウェイの障害によりリモートの従業員がアクセスできなくなります。ユーザーはアプリケーションを正常に起動できるかもしれませんが、ライセンス、ファイル、またはバックエンドサービスが利用できないためにトランザクションを完了できないことがあります。

アプリケーションのレジリエンスは、サーバーが可用性や健康チェックに応答できるかどうかではなく、ユーザーが必要なビジネスタスクを実行する能力に基づいて測定されるべきです。

なぜアプリケーションのレジリエンスはWindowsアプリケーションにとって異なるのか？

現代のレジリエンスプラクティスは、クラウドネイティブアプリケーション、コンテナ、マイクロサービス、自動オーケストレーションにますます焦点を当てています。これらは貴重なアプローチですが、すべての組織に常に適用できるわけではありません。

多くの組織は、クラウドネイティブアーキテクチャが一般的になる前に開発されたレガシーなWindows業務アプリケーションを持っています。ERPソフトウェア、会計アプリケーション、製造アプリケーション、医療アプリケーション、エンジニアリングアプリケーション、内部開発されたアプリケーションは、すべて組織の運営にとって重要である可能性があります。

これらのアプリケーションをマイクロサービスとして再構築することは、非常に高額で、技術的に困難であるか、組織がソースコードを管理していない場合は完全に実行不可能である可能性があります。

そのような場合、アプリケーション自体をより堅牢にしようとするのではなく、アプリケーション周辺の操作をより堅牢にすることに大きな価値があるかもしれません。 アプリケーションの公開 このアプローチの一部として、ユーザーがアプリケーションにアクセスする方法を変更しながら、既存のWindowsアプリケーションを集中管理されたインフラストラクチャ上に保持することができます。これには、アプリケーションをホストするインフラストラクチャの制約を排除したり、冗長なアプリケーションホストを作成したり、代替アクセス方法を有効にしたり、アプリケーションホストのためのより迅速な回復手順を実装したりすることが含まれます。

Windowsアプリケーションの可用性が失敗する場合はどのようなケースですか？

アプリケーションのレジリエンスを構築することは、ホストからユーザーにアプリケーションを成功裏に配信するために必要なコンポーネントを発見することから始まります。このプロセスは、アプリケーション全体をダウンさせる可能性のある失敗のポイントを浮き彫りにします。

アプリケーションホスト

単一のWindowsサーバー上で実行されているアプリケーションには、明確な単一障害点があります。

ハードウェアの問題、Windowsの更新、オペレーティングシステムの破損、リソースの枯渇、またはアプリケーションの失敗は、そのマシンに依存するすべてのユーザーに影響を与える可能性があります。可用性のニーズに応じて、複数のアプリケーションホストを配置して、特定のマシンへの依存を減らし、サーバーが利用できなくなったときにキャパシティを提供することができます。

データベース、ストレージおよびその他の依存関係

多くのWindowsアプリケーションは、アプリケーションホストの外部サービスに依存しています。これらのサービスには以下が含まれる場合があります：

• SQLデータベース
• ファイル共有
• ライセンスサーバー
• Active Directory
• ドメインネームシステム (DNS)
• 証明書
• API
• ミドルウェア
• ネットワークストレージ
• 印刷インフラストラクチャ

第二のアプリケーションサーバーを導入することは、共通のデータベースやストレージ依存関係を共有している場合、最小限の冗長性を提供します。それにより、依存関係のマッピングは、可視のアプリケーションインフラストラクチャを超えて拡張する必要があることが明らかになります。

認証とアイデンティティ

ユーザーは、必要な認証インフラストラクチャが利用できない場合、正常なアプリケーションにアクセスできません。

ITチームは、重要なアプリケーションが依存するアイデンティティサービスを特定し、これらのリソースがアクセスできない場合に備えてフェイルオーバープランを用意していることを確認する必要があります。Active Directory、クラウドアイデンティティプラットフォーム、マルチファクター認証（MFA）サービス、および認証ゲートウェイは、アプリケーションの可用性の連鎖を提供するために信頼できます。

ネットワークとリモートアクセスパス

中央集権的なWindowsアプリケーションにおいて、ユーザーとアプリケーション環境間の接続は、別の可能な障害ドメインを表します。

完全なチェーンを想像してみましょう。

ユーザー デバイス → インターネットまたは LAN → ゲートウェイ → アプリケーション ホスト → バックエンド サービス

このチェーンのどこかでの障害は、アプリケーションが正常に動作していても、ユーザーが仕事をするのを妨げる可能性があります。特に、アプリケーションがデータセンターで稼働していても、別の場所のユーザーがアクセスできない分散型組織にとっては重要です。

エンドポイント

アプリケーションのレジリエンスは、必ずしもユーザーの通常のワークステーションが利用可能である必要はありません。

認可されたユーザーに、代替デバイスまたはブラウザを介して中央ホストされたアプリケーションにアクセスする手段を提供することで、ノートパソコンが利用できなくなった場合、オフィスがアクセスできなくなった場合、または従業員が別の場所で作業する必要がある場合でも、アクセスを確保できます。

アプリケーション配信アーキテクチャは、より広範なビジネス継続戦略の一部となる可能性があります。

Windowsアプリのアプリケーションレジリエンスを構築するプロセスとは何ですか？

単一の技術がアプリケーションを回復力のあるものにするわけではありません。ITチームは、完全な機能を停止させる可能性のある障害の数を減らし、残る障害に対して制御された回復メカニズムを準備する必要があります。

重要なアプリケーションとビジネスプロセスを特定する

すべてのアプリケーションが同じ程度の保護を必要とするわけではありません。まず、主要な操作をサポートするアプリケーション、どのユーザーがそれに依存しているか、そして彼らのダウンタイムの許容度を特定します。

二つの回復目標は、ビジネス要件を技術的仕様に変換します。 NISTの緊急時計画ガイダンス 回復時間目標（RTO）と回復ポイント目標（RPO）を回復要件を決定するための重要なパラメータとして定義します。

• 回復時間目標 (RTO): サービスが復旧する前の許容されるダウンタイムの期間。
• 回復時点目標 (RPO): 許容可能なデータ損失の間隔で、時間で測定されます。

注文処理に集中的に使用されるアプリケーションは、数分のRTOを持つ可能性がありますが、週に一度実行される財務報告アプリケーションは、数日のダウンタイムを許容できます。

RTOとRPOは、アプリケーションに必要な保護の種類を定義します：瞬時のフェイルオーバー、サービスの迅速な再確立、または単に文書化された回復手順です。

アプリケーション依存関係チェーン全体をマッピングする

アプリケーションがその機能を果たすために必要なすべてのことを文書化してください。

実行可能ファイルやWindowsサーバーで止まらないでください。データベース、ストレージ、認証、DNS、ネットワーキング、証明書、ライセンスシステム、ゲートウェイ、外部サービスを忘れないでください。

各々に尋ねてください：

アプリケーションがこれを失った場合、どうなりますか？

この演習は、隠れた単一障害点を明らかにし、回復シーケンスを確立します。アプリケーションホストを最初に復元しても、そのデータベース、アイデンティティサービス、またはストレージがまだ利用できない場合はあまり役に立ちません。

3. 重要な単一障害点を排除する

依存関係ツリーが確立されたら、ビジネスの重要性と回復目標に基づいて、冗長化するコンポーネントを決定します。

Windowsアプリケーション配信の場合、単一のホストの機能に依存するのではなく、複数のアプリケーションサーバーを展開することが含まれる可能性があります。負荷分散層を使用することで、通常の操作中にセッションをアプリケーションインスタンスに分散させることができます。ホストの障害が発生した場合、受信接続は正常なアプリケーションサーバーインスタンスにルーティングされることができます。

冗長性の計画は依存関係分析に基づくべきですが、複数のアプリケーションサーバーが単一の重要なデータベース、ネットワークゲートウェイ、またはストレージ層にアクセスすることは、依然として単一障害点を呈します。

高可用性設計は、アプリケーションサービスを統合されたエンティティとして考慮する必要があります。インフラストラクチャレベルの冗長性を必要とするWindows Server環境の場合、 マイクロソフトのフェイルオーバークラスタリングのドキュメント 高可用性および災害復旧トポロジーに関するさらなるガイダンスを提供します。

4. アプリケーションを個々のエンドポイントから分離する

従業員のワークステーションに重要なアプリケーションを直接インストールすることは、別の種類のレジリエンスの問題を引き起こす可能性があります。ユーザーが通常のコンピュータへのアクセスを失うと、作業を続けるために必要なアプリケーションへのアクセスも失う可能性があります。

管理されたWindowsホスト上でのアプリケーションの集中管理 アプリケーションインターフェースをユーザーに提示することで、このリスクを排除します。データとアプリケーションの状態は、管理されたWindowsホストに保存され、認可されたエンドポイントによってアクセスされます。

これにより、ユーザーがデバイスや場所を変更してもアプリケーションを利用できるようになります。アプリケーションを集中管理することはインフラストラクチャの問題を解決するわけではありませんが、ITによって制御できる環境に移行するのに役立ちます。

5. 複数の実用的なアクセス方法を提供する

レジリエンスは、単一のエンドポイントタイプや接続方法への不必要な依存を避けることによっても達成できます。

アプリケーション配信アーキテクチャに応じて、ユーザーは異なるものを使用できます。 リモートアクセス RDP互換クライアント、専用アプリケーションランチャー、ウェブポータル、またはHTML5ブラウザセッションを含む方法。

代替接続方法はインフラストラクチャの冗長性と混同されるべきではありません。すべてが同じ失敗したサーバーに依存している場合、アプリケーションは依然として利用できません。

ユーザーの通常のデバイス、インストールされたクライアント、または場所に影響を与える中断が発生した場合に、アクセスの回復力を提供します。

6. 劣化が障害になる前に監視する

アプリケーションのレジリエンスは回復だけでなく、早期の検出が障害への劣化を回避することができます。

Windowsアプリケーション環境で役立つ指標は、CPU使用率、メモリ圧力、ディスク容量とI/O、ネットワーク使用率、アクティブセッション、アプリケーションプロセス、応答時間、接続失敗、および依存サービスの可用性です。

トレンド監視 サーバーが限界に近づくと、ユーザーエクスペリエンスが徐々に悪化しても、オンラインのままである可能性があるため、これは重要です。

閾値アラートは、管理者がユーザーがアクセスを失う前にインシデントの前兆を調査できるようにします。

7. キャパシティスパイクとフェイルオーバーの計画

ハードウェアレベルの障害に耐えるアプリケーションであっても、要求が増加すると完全に機能できなくなる場合は、あらゆる種類の障害に対して真に回復力があるとは言えません。

容量の計画は、日常的な使用パターンだけでなく、季節的な需要、シフトの変更、成長、または他のアプリケーションのホスティング要件によるピークも考慮に入れる必要があります。

特にマルチサーバーホスティング環境では、単一のサーバーの損失は、他のホスティングノードが失敗したノードで実行されるはずのプロセスを収容するための余剰容量を持っていることを確認することによって考慮されなければなりません。

そうでなければ、フェイルオーバー手順が単に孤立したインシデントを広範なシステムパフォーマンスの問題に変えてしまう可能性があります。

8. データと設定を保護する

アプリケーションを動作させるために必要なコンポーネントをITが復元できない場合、代替のWindowsサーバーはほとんど役に立ちません。

これは、バックアップ手順にアプリケーションデータ、データベース、設定ファイル、証明書、アプリケーション設定、ユーザープロファイル、インフラストラクチャの設定、スクリプト、およびライセンス情報を含める必要があることを意味する可能性があります。

戦略は、アプリケーションの復旧時間目標（RTO）および復旧ポイント目標（RPO）に応じて異なります。

まず第一に、成功したバックアップが成功した復元と同じでないことを確認してください。ITチームは、保護されたデータと構成からアプリケーションサービス全体を復元できることをテストする必要があります。

変更の影響範囲を縮小する

予期しない災害が中断を引き起こす場合ばかりではありません。実施された改善によっても引き起こされることがあります。したがって、Windowsのパッチ、アプリケーションやドライバーのアップグレード、セキュリティポリシーや設定の変更も、アプリケーションの可用性に悪影響を及ぼす可能性があります。可能であれば、すべての本番ホストに同時に同様の変更を加えることは避けることをお勧めします。

マルチサーバー構成では、改善変更を段階的に実施することが可能であり、これにより管理者はすべてが正しく機能していることを確認できます。行った変更を元に戻す能力も重要です。

したがって、緊急手順を設計する際には、ロールバックオプションも考慮する必要があります。プロセスは適切に文書化され、スタッフは変更が失敗した場合に何をすべきかを知っているべきであり、単に彼らの裁量に任せるべきではありません。

10. 優雅な劣化のためのデザイン

レジリエンスは、常に100%の通常機能を維持することではありません。

場合によっては、主要なユーザーやアプリケーションの運用を維持することが、すべてのユーザーにすべてのサービスを利用可能にすることよりも重要である場合があります。ITチームによって、インシデントが発生する前に優先順位を設定することができます。

利用可能なキャパシティがある場合、最初に生産、カスタマーサービス、財務、またはその他の機能に割り当てることが理にかなっているかもしれません。

それは優雅な劣化です：最もビジネス価値を生み出す機能を実行する能力を保持し、重要度の低い要素の失敗によってシステム全体がクラッシュするのを防ぐことです。

ITチームはアプリケーションのレジリエンスをどのように監視すべきですか？

個々のサーバーの監視は有用かもしれませんが、レジリエンス監視はユーザーが認識する全体のアプリケーションサービスを反映するべきです。

現実的なモデルは、いくつかの層で構成されています。

レイヤー	監視する内容	例外失敗
ホスト	CPU、RAM、ディスク、OSの可用性	サーバーが過負荷またはオフラインです
アプリケーション	プロセスとサービスのステータス	アプリケーションがクラッシュする
依存関係	データベース、DNS、アイデンティティ、ストレージ	アプリケーションは起動しますが、操作できません。
アクセス	ゲートウェイ、ポータル、ネットワークパス	ユーザーは接続できません
セッション	アクティブユーザー、失敗、レイテンシ	アプリケーションはオンラインですが、使用できません
ビジネス機能	ワークフローの成功した完了	ユーザーは必要なタスクを完了できません。

ビジネス機能層は、見落としがちな最も単純な層の一つです。

インフラストラクチャダッシュボードは、すべてのサーバー、サービス、ネットワークパスが正常であると表示される場合がありますが、実際のユーザーのワークフローは損なわれています。したがって、重要なアプリケーションは、サポートするために設計された操作の観点からその健康状態を監視することが重要です。

アプリケーションのレジリエンスはどのようにテストすべきですか？

制御された失敗を経験したことのないレジリエンスアーキテクチャは、未検証の仮定を含んでいます。

システムの主要コンポーネントが利用できなくなったときの応答を評価するためにテストを使用します。テストには、アプリケーションホストをオフラインにすること、アプリケーションサービスを停止すること、ネットワークルートの喪失をシミュレートすること、ゲートウェイまたは負荷分散の動作を確認すること、バックアップからの復元、および代替エンドポイントからアプリケーションにアクセスすることが含まれるべきです。

テストプロセスは、回復の技術的側面を超えて拡張されるべきです。ITチームは、アラートが正しい管理者に送信されているか、回復手順が正しい順序で実行されているか、サービスが復元された後にユーザーが実際のビジネスタスクを実行できるかを確認する必要があります。

運用手順は、回復力のあるシステムに不可欠です。アラートエスカレーション手順：誰がアラートを受け取りますか？誰がフェイルオーバーを開始する権限を持っていますか？回復に関する文書と資格情報はどこに保存されていますか？どの依存関係が最初にオンラインになる必要がありますか？

技術的冗長性は、アクセスを回復するためのプロセスがテストされていない場合、ほとんど利益をもたらしません。

アプリケーションのレジリエンスチェックリストとは何ですか？

重要なWindowsアプリケーションのレジリエンスに着手する前に、ITチームは以下の質問に答えられる必要があります：

• アプリケーションに依存するビジネスプロセスはどれですか？
• それらのRTOとRPOは何ですか？
• どのサーバー、データベース、外部サービスが必要ですか？
• その重要な単一障害点はどこですか？
• 別のアプリケーションホストは、1つのホストが失敗した場合にユーザーを受け入れることができますか？
• ユーザーは通常のエンドポイントや場所が利用できない場合、接続できますか？
• 劣化運用のための十分な余剰容量はありますか？
• インフラストラクチャ、依存関係、セッションの問題は積極的に監視されていますか？
• 管理者は重要な閾値が障害になる前に警告を受けますか？
• アプリケーションデータと設定は保護されていますか？
• 復元は実際にテストされましたか？
• 問題のある変更を元に戻すことはできますか？
• 回復手順は文書化されていますか？
• ユーザーは回復後に必要なビジネスプロセスを完了できますか？

すべての回答が高価な高可用性インフラストラクチャを必要とするわけではありません。適切な保護レベルは、コストとダウンタイムの運用への影響に依存します。

重要なのは、可用性、冗長性、回復の決定が仮定されるのではなく、意図的に行われることです。

TSplusはどのようにしてWindowsアプリケーションを利用可能に保つことができますか？

既存のWindowsアプリケーションに依存する組織のために、管理されたWindowsサーバー上でアプリケーションを集中化し、RDP互換のクライアント、RemoteAppスタイルのアクセス、またはHTML5ウェブポータルを通じてユーザーに提供することで、可用性を向上させるお手伝いができます。これにより、個々のユーザーエンドポイントへの依存が減り、ユーザーが別のデバイスや場所から接続する必要があるときにITチームにより多くの柔軟性が与えられます。

TSplus リモートアクセス マルチサーバー展開を負荷分散およびゲートウェイベースのアクセスでサポートすることもできます。堅牢なデータベース、ストレージ、アイデンティティサービス、ネットワーキングと組み合わせることで、このアーキテクチャは単一のアプリケーションホストへの依存を減らし、インフラストラクチャの中断中に重要なWindowsアプリケーションへのアクセスを維持するのに役立ちます。

結論

アプリケーションのレジリエンスは、インフラストラクチャとビジネス利用の間の完全なパスを理解することに依存しています。冗長性、監視、バックアップ、キャパシティプランニング、回復手順は、明確に定義されたアプリケーションの依存関係と回復目標に基づいて設計されているときに最も効果的です。

既存のWindowsアプリケーションにおいて、レジリエンスはしばしばソフトウェア自体を再構築するのではなく、ソフトウェアの周囲の環境を強化することから生まれます。重要なテストはシンプルです：中断が発生した場合、ユーザーは作業を続けることができるのか、それともITは合意された回復ウィンドウ内で必要なビジネス機能を復元できるのか？