“フォールトトレラント”なソフトウェアプラットフォーム

　クラスタは、複数台の重複するサーバ間でアプリケーションのトラフィックの負荷を分散するという発想に基づいている。あるサーバで障害が発生した場合、そのサーバの負荷を他のサーバが引き受けることで、ワークロードの運用に影響が及ばないようにしている。従来のサーバクラスタの代替案の1つに、サーバのフォールトトレランスまたは高可用性を実現する方法がある。通常、このモデルでは、複数の物理サーバ間で仮想マシン（VM）の複製と同期を行う。

　フォールトトレラントとは、ITシステムに障害が発生しても予備システムを利用して動作を継続できるシステム設計の考え方を指す。フォールトトレラントモードでは、従来のハードウェアベースのクラスタと同様に、複製されたVMがホットスタンバイ構成で負荷を共有する。一方のVMで障害が発生しても、サービスが中断されることなく、もう一方のVMが処理を継続する。ただし、ハードウェアベースのクラスタほど包括的な負荷分散は行われていないため、トラフィックが多少低下する場合がある。これにより、アプリケーションは、まだ影響が及んでいない障害に対する耐性がある。

　高可用性モードでは、複製されたVMがウォームスタンバイ構成（アイドル状態）で稼働中のVMとの同期が保たれる。稼働中のVMで障害が発生すると、スタンバイしていたVMがアクティブになり、トラフィックの負荷を引き受ける。VMの切り替え時には、少量のトラフィックが途絶する可能性はあるが、途絶は短時間で済むのが一般的だ。

　フォールトトレラントと高可用性の展開では、Stratus Technologiesの「everRun Enterprise」やVision Solutionsの「Double-Take」シリーズなど、冗長なワークロードインスタンスの作成、同期、フェイルオーバー機能を備えたソフトウェアツールを使用する。高可用性やより厳格なフォールトレランス構成がITの回復力を確保するクラスタ化の選択肢として適切かどうかは、ビジネスにおけるワークロードの重要性によって決まる。

冗長化したクラウドアーキテクチャ

　エンタープライズアプリケーションの中には、Amazonの「Amazon Web Services」（AWS）にGoogleの「Google Cloud Platform」、そして、Microsoftの「Microsoft Azure」などのパブリッククラウドで開発および導入されているものもある。パブリッククラウドでは、高速でスケーラブルなVMやストレージのプロビジョニングができる。さらに現在では、ソフトウェア開発者、運用スタッフ、クラウド管理者向けの回復力機能も提供されている。

　例えば、AWSは「Auto Scaling」サービスによるクラスタ機能を提供している。この機能を使用すると、管理者はAWSのコンピューティングインスタンスである「Elastic Compute Cloud」（EC2）のグループを作成できる。EC2インスタンスは自動、手動ワークロードトラフィックの変化によって増減する。また、AWSの「Elastic Load Balancing」サービスは、クラウドインスタンスのトラフィックを分散する。

　パブリッククラウドでワークロードの回復力を実現するために、企業がハードウェアやソフトウェアプラットフォームに先行投資する必要はない。パブリッククラウドプロバイダーが全てのハードウェアと管理について責任を持ち、企業は実際に使用したコンピューティングリソースに対して料金を支払う。ただし、EC2インスタンスとその関連クラウドサービスは、特定の支払請求サイクル中に規模の増減があるため、支払額は異なる。地域的な障害に対する回復力を向上する場合は、世界各地に設備を持っているクラウドベンダーのサービスの利用を検討することをお勧めする。

スナップショットの取得

　ほぼ全ての企業のワークロードには、運用時にある程度の保護が必要になる。ただし、その全てで、リアルタイムのクラスタ保護、フォールトトレランス、高可用性プラットフォームが必要とは限らない。予備のアプリケーションまたはテストや開発段階のアプリケーションは、ある程度のダウンタイムやデータ損失を許容できる。このようなアプリケーションは、標準的なVMのスナップショットによって適切なレベルの回復力が得られる可能性がある。

　基本的に、VMは、OS、ドライバ、アプリケーション、データインスタンスを備えており、サーバのメモリ空間で動作する完全な環境といえる。実質的に、スナップショットは、メモリ空間の現状や前回のスナップショットからメモリ空間で発生した変化をキャプチャーし、その内容を「.vmdk」や「-delta.vmdk」などのファイルに保存したものだ。VMで障害が発生した場合、管理者はスナップショットを復元して、数分程度でVMを再起動できる。通常、この手順によってアプリケーションはキャプチャーしたスナップショットを前回キャプチャーした時点の状態まで回復する。復元時にはデータと時間を多少失う可能性がある。そのため、スナップショットベースの復元という選択肢を選ぶ前に、目標復元ポイントと目標復元時間による影響を検討しておきたい。アプリケーションが潜在的なダウンタイムを許容できる場合、この選択肢では、VM用にサーバを1台使用すれば済むため、ハードウェアへの投資を最小限に抑えられる。

　なお、VMwareの「VMware vSphere」といった主要な仮想化プラットフォームは、VMのスナップショットをキャプチャー、整理、統合、管理、復元できる強力なスナップショットツールを備えている。

アプリケーション設計における回復力

　ITシステムの回復力は、展開や運用だけに関わる問題ではない。回復力は開発でも重要な懸念事項だ。ワークロードの回復力はアプリケーションの設計と実装の妥当性の影響を大きく受ける。アプリケーションの回復力とは、アプリケーションのコンポーネントにおける問題やエラーに対して、無意味な反応やクラッシュを引き起こすことなく、可能な限り適切な対応をすることだ。

　特定のハードウェアに依存するアプリケーションは、フェイルオーバーや復元時に深刻な問題を引き起こす場合がある。また、ワークロードが、特定のOS、ドライバ、データベース構造、その他のソフトウェアコンポーネントに依存している場合にも同様の問題が起こる。複雑なソフトウェアでセキュリティが不十分で脆弱（ぜいじゃく）性テストが十分に行われていない場合、そのソフトウェアは多くのサイバー攻撃にさらされる。そして、アプリケーションの回復力にも悪影響が及ぶことになる。

　適切な設計手法を使用して、包括的なテストでも、全ての問題を防ぐことはできない。だが、テストによって運用環境に導入したバージョンでバグなどのエラーが発生してもサービスを継続して致命的な状態を引き起こさないようにできる。また、アプリケーションにログとデータの収集機能を統合すれば、エラーの状態を記録して、パフォーマンスの問題を特定するのに役立つ。

アプリケーション設計のコンテナとマイクロサービス

　スケーラビリティは、ワークロードの回復力に大きく影響する。トラフィックの需要がワークロードインスタンスで使用可能なコンピューティングリソースを上回ると、ワークロードはパフォーマンスが低下するか、完全にクラッシュする。仮想マシンのクラスタと負荷分散は、アプリケーションをスケーリングするための安定した手段だ。最新のアプリケーション設計では、仮想コンテナに展開されたマイクロサービスアーキテクチャを利用できる。VMとして展開されたモノリシックなワークロード設計ではなく、機能を持つコンポーネントがAPIを通じて連係し、アプリケーションの機能を有効にしている。

　コンテナベースのマイクロサービスがもたらすメリットは、コンテナが共通のOSを共有しているため、コンピューティングのオーバーヘッドを圧倒的に少なくしながら高速にスケーリングできることだ。コンテナ化されたワークロードは独立してスケーリングできる。そのため、アプリケーション全体を完全に統合するのではなく、機能領域ごとにクラスタ化と負荷分散を行うコンテナを使用できる。機能を持つコンポーネントは、モノリシックなアプリケーションよりも高速に更新やアップグレード可能だ。そのため、必要な回帰テストが少なく、予期しない結果を引き起こすリスクも少ない。

　ここまで紹介した方法は、展開スキームとしては複雑かもしれない。だが、手間を掛けた見返りとして、使用するコンピューティングハードウェアを削減し、従来の物理PCやVMよりも高いアプリケーションのスケーリングを実現する回復力を享受できる。