システムを語る上でよく登場する「可用性」や「冗長化」というワード。
本記事では、「可用性」の意味や「可用性を高めるための具体的な方法」をわかりやすく解説します。
1.可用性とは？
システムにおける可用性（アベイラビリティー）とは、「システムが停止することなく稼働し続ける能力」を意味します。「稼働率」に置き換えることもできます。
例えば、必ず80時間に一度障害が発生して停止する（そのかわり、必ず80時間連続稼働する）システムがあって、その度にシステム再稼働までに20時間を要するとします。このシステムは100時間で80時間しか稼働しませんから、可用性（稼働率）は80％です。これに対し、信頼性はどれだけシステムが連続して稼働できるかを意味し、平均故障間隔（＝平均連続稼働時間）と言い換えることができます。上記システムの場合は、80時間になります。
可用性が高められた状態を高可用性（ハイ・アベイラビリティー：HA）と呼び、さらに、高可用性を突き詰め、障害発生時も停止しないシステムのレベルを耐障害性と呼びます。耐障害性を有する環境ではシステム停止によるサービス中断が発生しないかわりに、コストがきわめて高くなります。それに対し、高可用性の環境では最小限のサービス中断が発生するものの、システム環境の整備にかかるコストを抑えることができます。
マンガでわかる可用性入門
可用性について初めて学ぶ方には『マンガでわかる可用性入門』がおすすめです。可用性を高め、システム障害に備える手法についてざっくりと解説されています。
※個人情報入力なしでPDFファイルがダウンロードできます
2.可用性を高める2つの方法
可用性を高めるには2つの方法があります。まずは単純に、より可用性の高いシステムへリプレイスする方法です。しかしながら、高可用性を求めるほど大きな投資が必要になる（耐障害性システムになると超高価）ほか、リプレイスの手間もかかり、既存資産がムダになってしまうなど非現実的と言っていいでしょう。
もう１つは、同じシステムを障害発生時の予備として別途用意しておく方法（＝冗長化）です。レプリケーションで運用系と待機系間でデータを同期しておけば、障害発生時に切り替えるだけで、ダウンタイムを最小化してのサービス再開も可能です。前段で例にあげた可用性80％のシステムであっても、運用系と待機系を交替しながら運用していけば、100％に近い高可用性を実現できます（切り替えにともなうダウンタイムを考慮しない場合）。
可用性のレベルにかかわらず、あらゆるシステムで、いつかは障害が発生する以上、冗長化で高可用性を担保するアプローチは基本中の基本と言ってよいでしょう。
冗長化に関するさらに詳しい情報は、下記の記事もご覧ください。
3.オンプレ/クラウドで可用性へのアプローチはどう変わる？
企業システムはオンプレの物理環境から仮想環境へと進化し、昨今ではクラウド（IaaS）の導入も進んでいます。物理環境から仮想環境の移行においては、リソースが集約＆抽象化され単一障害点が減る分、障害発生率も低くなりますが、システム全体を冗長化し必要に応じ切り替える…という基本的アプローチについては特に変わりません。
では、クラウド（IaaS）に移行したシステムについてはどうなるでしょう。クラウドの場合、ハードウェアを含むインフラはクラウドベンダーが一定レベルの可用性を担保し、ユーザーはそこにコミットすることができません。では、クラウドに移行した企業は、もはや可用性について心配しなくてもいいのか？というと…残念ながらそんなことはありません。まず、クラウドのインフラと言えど障害に対して万全ではなく、サービス停止のリスクはゼロではありません。
クラウドベンダーが担保する範囲を定めたものを「SLA」といいます。SLAがあることでユーザーは安心感を持ってサービスを利用することができ、また提供者側も事前にサービスの品質水準について合意が取れるため不用意なトラブルを防ぐことができます。その一方で、SLAによって定められた範囲の外については、ユーザー側で何らかの対策を施すことが必須となります。
クラウドのSLAの詳細については、下記の記事もご覧ください。
4.運用系から待機系への切り替えを自動化するHAクラスターシステム
オンプレの物理/仮想環境にせよ、クラウド環境にせよ、システムを冗長化したとして、障害発生時にいかに素早く切り替えるかが課題となります。ハードウェア/ソフトウェアが同一環境の待機系をコールドスタンバイで用意しただけのケースでは、まず電源を入れてネットワークをつなぎ変えるだけでなく、最新のバックアップからリストアする必要もあり相当な時間がかかります。また、そもそも障害発生にいつ気付くかという問題もあります。ユーザーからのクレームでようやく気付くようではビジネスへの影響が懸念され、障害発生を検知し自動で切り替えてくれる仕組みが必要です。
その1つが「HAクラスターシステム」と呼ばれる仕組み（システム構成）です。HAクラスターシステムでは、ハードウェアを含むシステム全体を運用系と待機系で冗長化し相互に監視。障害が発生すると運用系から待機系に切り替えてサービス提供を継続します。当然、運用系で利用していた最新データを用意する必要がありますが、運用系と待機系の両方のサーバーからアクセス可能な共有ディスク（外部ストレージ）を利用することで対応しています。
そして、この切り替えの自動化で用いられるのが「LifeKeeper」に代表されるHAクラスター・ソフトウェアです。同製品はAWS、Azureなどの主要なパブリッククラウド（IaaS）からプライベートクラウドまで多様なクラウド環境に対応。クラウド上にHAクラスターシステム環境を簡単に構築でき、システムの高可用性を実現します。
5.クラウド移行時の可用性対策
ここまでご覧になった方の中にも、オンプレミスからクラウド（IaaS）へのシステム移行（いわゆるクラウドリフト）を検討されている方がいらっしゃるかと思います。
クラウド移行を考える上でも、上記でお伝えした通り、冗長化などで可用性を高める仕組みを検討する必要があります。
その際に、大きな障壁となるのはクラスターノード間のデータの引き継ぎです。オンプレミスで冗長化構成をとる場合、クラスターノード間のデータは共有ストレージに格納する場合が多いのではないでしょうか。
しかしながら、クラウドでは物理的な共有ストレージを置くことができない場合が多く、別の方法でデータの引継ぎを検討する必要があります。
そのような場合に活用できるのが、「DataKeeper」のようなデータレプリケーションソフトです。DataKeeperは、クラスターノードのローカルディスク同士をブロックのレベルでリアルタイムに同期することで、「論理的な共有ストレージ」として扱えるようにします。
つまり、クラウド環境でもクラスターノード間のデータを担保できるようになります。
クラウド上でのデータの引継ぎに関する課題や対策については、下記の記事をご覧ください。
マンガでわかる可用性入門
可用性について初めて学ぶ方には『マンガでわかる可用性入門』がおすすめです。可用性を高め、システム障害に備える手法についてざっくりと解説されています。
※個人情報入力なしでPDFファイルがダウンロードできます
