寄稿：米国サイオス カスタマーエクスペリエンス担当バイスプレジデント Cassius Rhue
※この記事は翻訳されたものです。本記事の原文はこちら
生活の多くの側面がテクノロジー主導になっているこの現代、私たちは非常に瞬間的な世界に生きていると言ってもよいでしょう。たとえば、ボタンをクリックするだけで毎週注文している食料品が玄関先に届きます。イベントや旅行のチケットも即座に購入できます。また最近では、ショールームに行く必要もなく、強引なセールスマンに対応されることもなく、新車を注文することもできます。私たちは、この便利な世の中に甘やかされているのです。
ここで、このようなレベルのサービスを支えなければならないベンダーやサービスプロバイダーのことも考えてみてください。彼らは、基盤となるインフラ（特にITインフラ）が、この「常時接続」をサポートできるように構築・運用されるよう、高いレベルの投資を維持しなければなりません。またアプリケーションとデータベースは、顧客の要求を満たし、企業の生産性と収益を最大化するために、常に稼働していなければなりません。IT事業継続の重要性は、かつてないほど重要になっているのです。
巷には、フォールトトレランス（FT）、高可用性（HA）、ディザスターリカバリー（DR）など、多くのIT可用性のコンセプトが溢れていますが、「これらの可用性のコンセプトの違いは何か？」「自社のインフラにはどれが適しているのか？」「これらを組み合わせたり、入れ替えたりすることはできるのか？」といった新たな疑問も湧いてくるでしょう。
可用性を高めるための最初のステップは、アプリケーションやデータベースの可用性に関するサービスレベル合意（SLA）を明確に設定することです。これにより、高可用性実現に向けた最適なアプローチを定義することができます。
SLAとは
私たちは皆、SLAとは何かということをある程度は分かっていますが、ここでは全員が同じ認識を持っているかどうかを確認しましょう。
可用性SLAは、サービスプロバイダーとエンドユーザーとの間の契約であり、ベンダーが確保すべきアプリケーション/データベースのアップタイムとアクセス性の期待レベルを定義し、合意されたサービスレベルが満たされない場合の罰則（通常は金銭）の概要を説明するものです。ITの世界では、SLAはビジネスにとって重要な2つの指標、目標復旧時間（RTO）と目標復旧時点（RPO）に基づいて作成されます。
簡単に言うと、RTOは、障害が発生した場合に、どれだけ早くアプリケーションの動作を回復させる必要があるかを定義するものです。RPOは、復旧が必要になった場合に、データがどの程度最新でなければならないかを定義するものです。アプリケーションとデータベースのこれらの指標を特定できれば、それがSLAを定義することになります。
SLAはパーセンテージで測定されるため、たとえば99.9%や99.99%利用可能といった用語に出会うことがあります。これは、IT部門が1年間に何分の稼働率と可用性をアプリケーションに保証するかを示す指標です。一般に、保護が強化されればされるほど、コストは高くなります。したがって、アプリケーションやデータベースが1時間ダウンした場合のコストを見積もり、このSLAを、ビジネスに適したソリューションを選択するためのツールとして使用することが非常に重要です。SLAが決まれば、どのタイプのソリューション（FT、HA、DR、またはそれらの組み合わせ）が可用性のニーズに最も適したアプローチであるかをビジネス的に判断することができます。
フォールトトレランス（FT）とは
FTでは、99.999%という非常に高い可用性SLAを提供しています。現実的な例で言えば、FTソリューションでは1年間に5.25分を超えるダウンタイムが発生しないことが保証されます。基本的に、2台の同一のサーバーが互いに並行して稼働し、「ロックステップ」プロセスと呼ばれるアクティブ-アクティブ構成で、両方のサーバーのトランザクションを同時に処理します。プライマリーサーバーに障害が発生しても、セカンダリーサーバーが処理を続行し、アプリケーションの中断やデータの損失は一切ありません。エンドユーザーは、サーバーに障害が発生したことを意識することなく、安心して利用することができます。
ここまで見ると、FTの可用性SLAは非常に高く、これ以上は何も必要ないように思えます。しかしながら、99.999％の可用性SLAを提供するFTにも、考慮すべき点があります。それは、「ロックステップ」プロセスが非常に変わり者で、実行可能なサーバーハードウェアの種類、特にプロセッサーの種類に制約が多くあるという点です。このようにハードウェアの互換性が限られているため、FTソリューションは高価格にならざるを得ず、2つ以上のFTクラスターと関連するサポートやサービスを考慮すると、数千万円にもなる可能性があります。
ソフトウェアエラーの脆弱性
また、FT ソリューションはハードウェアのフォールトトレランスを念頭に置いて設計されているため、潜在的なアプリケーションエラーにはあまり注意を払っていません。FTソリューションは同じトランザクションとプロセスを同時に実行しているため、プライマリサーバーでアプリケーションエラーが発生すると、セカンダリサーバーでもそれが複製されることを覚えておく必要があります。
高可用性（HA）とは
ほとんどのSLAでは、FTはコストがかかりすぎて、平均的なユースケースでは購入して管理することができません。その点、HAソリューションは、ほぼ同じレベルの保護をわずかなコストで提供するため、多くの場合HAソリューションの方が適しています。
HAソリューションは、アクティブ-スタンバイ方式で展開することにより、1年間で約52分のダウンタイムに相当する99.99％のSLAを実現します。SLAの値が下がるのは、稼働系サーバーが待機系サーバーに切り替わるまで若干のダウンタイムがあるためです。これはFTソリューションほど優れているものではありませんが、CRMやERPのような超重要アプリケーションであっても、ほとんどのIT要件において、HAはSLAを満たします。
同様に重要なのは、HAソリューションはアプリケーションへの依存度が低く、ハードウェアやOSの障害だけでなく、アプリケーション障害が発生した場合のサーバーのフェイルオーバーも管理できることです。また、構成の柔軟性も大幅に向上します。ほとんどの場合、基盤となるOSがサポートされているプラットフォームで実行されるため、FTのようにハードウェアに互換性があるかどうかを確認する必要はありません。
ディザスタリカバリー（DR）をどう取り入れるか
FTやHAと同様に、DRも重要なビジネス機能をサポートするためのシステムです。ただし、DRはFTおよびHAと組み合わせて使用することができます。FTとHAは、データセンター（またはクラウドのアベイラビリティーゾーン）内など、ローカルレベルでのアップタイムの維持に重点を置いています。一方DRは、災害がプライマリーデータセンターで発生した場合にフェイルオーバーする冗長サイトまたはデータセンターを提供するものです。
結論
結局のところ、可用性のアプローチに間違いも正解もないのです。要は、保護しようとするビジネスプロセスの重要性と、ソリューョンの基本的な経済性に要約されます。あるシナリオでは、可用性の確保は当然のことです。たとえば、原子力発電所を運営しているのであれば、重要なオペレーションがFTシステムによって保護されている方が安心できます。現実的に、サービスの中断は避けたいでしょう。しかし、ほとんどのIT環境では、クリティカルなアップタイムはHAで提供することができ、価格ももっと手頃です。
FT、HA、DRをどう選ぶか
- 何よりもまず、自社の業務を細かく理解し、ダウンタイムのコストを明確にする。
- SLAが確立されたら、選択した可用性ソリューションのコストと、潜在的なダウンタイムのコストを比較検討する。
- 可用性ソリューションを選択する際には、導入のしやすさと使いやすさを考慮する必要がある。これらは、可用性ソリューションの全体的なTCOにも影響を与えるためである。
ITシステムは堅牢ですが、最も都合の悪い時に不具合が生じることもあります。何もかもがインスタントで便利な世の中において、FT、HA、DRはお客様にSLAを提供する際に、お客様を守る保険となるのです。
