用語集
HA（High Availability）とは
情報セキュリティを構成する3要素のうち、「システムが動き続けることができる能力」をAvailability（可用性）と呼び、「高い」「低い」で表します。システムの可用性が低い状態が続くと、システムやサービスが停止・中断により利用できなくなる可能性が高くなり、結果として業務や事業の継続性における大きなリスクとなってしまいます。
つまり、重要なシステムを安定して動かし続けるためには、そのシステムの可用性を高く保つことが重要となってきます。この可用性が高い状態のことを英語で「High Availability」。略して、HAと呼んでいます。
本記事では、システムやサービスの可用性が高い状態を実現するためにはどのような方法があるのか、オンプレミスとクラウドの比較も踏まえて解説します。
本記事をご覧いただいた方向けに、おすすめの記事をまとめました。こちらもあわせてご確認ください。
ITシステムの可用性とは
ITシステムの可用性を客観的に表す指標の1つに「稼働率」があります。稼働率とは、「ある一定期間の中でそのシステムが動作している割合」のことです。具体的には、平均故障間隔（MTBF）を平均故障間隔（MTBF）と平均復旧時間（MTTR）の合計で割った数値で求められます。故障した時に復旧するまでの平均時間が長くなると、稼働率は低くなります。稼働率が低い場合、可用性もまた低いと考えられます。逆に故障したときに復旧するまでの平均時間が短ければ稼働率は高く、そのシステムの可用性は高いと言えます。
とはいえ、不慮のハードウェアの故障や自然災害など、システムが停止する要因を完全に排除することはできません。そこで、本番稼働しているシステムと同じ構成で予備のシステムをあらかじめ複数用意しておき、万が一の障害発生時には待機している予備のシステムに切り替えて運用を継続することで、サービスが停止している時間を短かく抑えるという対策が効果的です。こうした対策を「システムの冗長化」と呼びます。
この「システムを冗長化して障害に備える」という対策自体は、オンプレミスでもクラウドでも変わりありません。しかし、オンプレミスとクラウドでは、可用性向上のための考え方が一部異なります。システムを構成する「サーバー」「ストレージ」「ネットワーク」「電源」それぞれの可用性の考え方について、詳しくは「クラウドとオンプレミスの可用性の考え方の違いとは」をご確認ください。
オンプレミスにおける可用性
オンプレミスでは、「サーバー」「ストレージ」「ネットワーク」「電源」などを複数用意することで冗長化を図る「HAクラスター構成」を組むのが一般的です。本番運用中のハードウェアに障害が発生した場合、クラスターを構成しているほかの正常なハードウェアに切り替えることで、障害の影響を最小限に抑えることが可能です。この切り替えプロセスを手動で行うことを「スイッチオーバー」、自動で行うことを「フェイルオーバー」と呼びます。また、オンプレミスに何らかの仮想化ソフトウェアを導入している場合、仮想化ソフトウェアが自動フェイルオーバーの機能を持っている場合もあるため、機能を確認しておくとよいでしょう。具体的にはVMwareの「vSphere HA」などが該当します。
切り替え先となる待機系サーバーの待機のさせ方にも、いくつかの種類があります。待機系サーバーを停止した状態で用意しておき、障害時に起動して切り替える方式を「コールドスタンバイ」と呼びます。対して待機系サーバーも常に起動した状態にしておき、自動的に切り替える方式を「ホットスタンバイ」と呼びます。
また、オンプレミスではサーバーなどの機器だけでなく、必要に応じてインターネットに接続する回線そのものの冗長化も考慮する必要があるでしょう。
クラウドにおける可用性
クラウドでは、ハードウェアを直接触ることはないため忘れがちですが、クラウドといえどもサービスの裏側には、物理的なサーバーが存在しています。そのため、クラウドであってもハードウェアに起因する障害は発生する可能性があり、可用性を向上させるための基本的な考え方は、オンプレミスと変わりません。障害発生時は正常に稼働している待機サーバーに迅速に切り替えることができるかどうかがポイントとなります。自動フェイルオーバー機能を提供しているクラウドサービスであれば、仮想サーバーのホストとなっている物理サーバーが故障した場合は、ほかの正常な物理サーバー上で仮想サーバーが自動的に再起動されるのが一般的です。
障害が発生してから、ほかの物理サーバーに切り替えて再起動が完了するまでの間は、わずかですが仮想サーバーが動作不能となる時間が生じてしまいます。自動フェイルオーバーの方法により多少の差異はあるものの、切り替えにかかる時間は短時間であり、クラウドはオンプレミスと比較して、ユーザー自身でフェイルオーバーの仕組みを作り込まなくても可用性を上げられる（動作不能時間をより小さくできる）と言えるでしょう。
なお、クラウドサービスによって、提供している機能やサービスレベルの細かな点は異なるため、事前にサービスレベル目標（SLO）なども確認しておきましょう。FJcloud-V(旧ニフクラ)では、物理サーバーが故障した場合でも、約5分以内にほかの物理サーバーへ切り替わることをSLOとして定めています。
クラウドならではの可用性向上対策とは
例えば、エンタープライズ向けの基幹システムのようにクラウドベンダーがSLA/SLOに定めた稼働率では要求を満たせない、わずかな停止時間すらも許容できないといったシステムも存在します。こうしたケースでは、クラウドベンダーが提供する機能・サービスを利用して、ユーザーが独自に可用性向上対策を実施することが必要です。
クラウドベンダーのデータセンターは、リージョンやゾーンという単位に分割されて運用されているのが一般的です。そこで、待機系サーバーをあえて地理的に離れた別リージョンに配置したり、同一リージョン内であっても意図的に異なるゾーンに分離することで、データセンターの一部もしくは全体に影響するような大規模の障害に対しても可用性を向上させることが可能です。
待機系サーバーを地理的に離れたロケーションに配置するという構成は、クラウド特有のものではなく、オンプレミスでも実現可能です。ですが、可用性を向上させるためだけの目的で複数のデータセンターを自社で確保するというのは、コストや運用面でのハードルが非常に高いと言わざるをえません。しかし、クラウドであれば、こうした構成を比較的安価に実現できるのです。
システムを安定して稼動させ続けるためには、高い可用性の確保は避けては通れない問題です。そのため、課題に応じてさまざまなクラウドデザインパターンが用意されています。これらのデザインパターンを必要に応じて組み合わせて活用するのがお勧めです。詳しくは「可用性を向上させるクラウドでのデザインパターン」をご確認ください。
まとめ
日本政府がクラウド・バイ・デフォルト原則を打ち出した、2018年の「政府情報システムにおけるクラウドサービスの利用に係る基本方針」において、クラウドにおける可用性は次のように説明されています。
クラウドサービスにおいては、仮想化等の技術利活用により、複数のサーバ等のリソースを統合されたリソースとして利用でき、さらに、個別のシステムに必要なリソースは、統合されたリソースの中で柔軟に構成を変更することができる。その結果、24時間365日の稼働を目的とした場合でも過剰な投資を行うことなく、個々の物理的なリソースの障害等がもたらす情報システム全体への悪影響を極小化しつつ、大規模災害の発生時にも継続運用が可能となるなど、情報システム全体の可用性を向上させることができる。
つまり、低コストで柔軟にシステム全体の可用性を向上するためには、クラウドの利用が効果的であると政府も認識しているのです。ただし、提供されている機能・サービスは、クラウドベンダーごとに異なるため、基幹システムやミッションクリティカルなエンタープライズシステムなど、高可用性を求められるシステムにおいては、そのクラウドベンダーのサービスが自社の要求を満たせるのかを十分に検討する必要があるでしょう。
FJcloud-V(旧ニフクラ)では、ITシステムの可用性を高める秘訣をまとめた「ホワイトペーパー」を無料で提供しています。高い可用性が求められるシステムを構築する際には、ぜひ参考にしてください。
