【わかりやすく解説】可用性とは？

こちらの記事では、「可用性」について解説します。

可用性は、「システムが安定的に稼働し続けられる能力」のことを指します。どんなに信頼性の高いシステムにも絶対に落ちないというシステムは存在しません。安定的にシステムを稼働するためにも、万が一障害などが発生した場合のことを考慮しておかなければなりません。

2018年に日本政府が公開した政府情報システムにおけるクラウドサービスの利用に係る基本方針に可用性が取り上げられるなど、年々重要視されている「可用性」について分かりやすく説明していきます。

可用性の概要

可用性は、Availability（アベイラビリティー）の訳語です。可用性は、「可用性が高い、低い」という表現の仕方します。可用性が高い事を指して、高可用性（HA: High Availability）と表す用語も使われています。

また、可用性は稼働率（%）で表す事ができます。例えば、あるシステムが10時間稼働した時に、「実稼働が6時間・稼働停止時間が4時間」だったとしたら、稼働率は60％と表す事ができます。

システムの評価指標

可用性はシステムやソフトウェアの品質を評価する際の評価指標の1つです。システムの評価指標には可用性と似た用語も存在しており、同じような意味で捉えているケースも見受けられますので、一度整理しておきましょう。

システムの評価指標にはRAS、およびRASISと呼ばれるものがあります。上述した表の、上から3つの評価指標の頭文字を並べたものがRASで、上から5つ全てを並べたものがRASISです。特にRASの信頼性、可用性、保守性はシステムの評価指標で最重要視されていますので、この3つを混同しないようにしましょう。

初めてRASをシステムの評価指標に導入したのはIBMという世界最大規模のIT企業です。IBMは1970年6月に大型コンピュータの「System/370シリーズ」を発表し、この機種において新たなRASの考え方を採用し、商品としての新たな価値を訴えました。

その後、RASにISの要素を追加する形でシステムの評価指標が拡張されました。そのため、RASの3つの要素の重要度が一番高くなっており、RASISは日本独自で広まった用語であると考えられています。（参照: IT用語辞典 RASIS）

障害からの復旧

障害はいつ起こるか分かりません。だからこそ障害が起きた後のこと、つまり復旧に関して考える必要があります。障害復旧においてはRPO、RTOという概念があります。

• RPO（Recovery Point Objective）

RPOは「目標復旧時点」という意味で、障害が発生した際にシステムを過去のどの地点まで復元するかを定めた目標値のことです。

RPOを小さく（短く）すればするほど、障害時に喪失するデータを少なくすることができます。例えば、RPOを10秒とすると障害発生の10秒前までのデータを復旧できることを意味し、RPOを1日とすると障害発生の1日前までのデータを復旧できることを意味します。

前者は秒単位の頻度でバックアップを取得し続ける必要があるという事を意味し、これだけの高頻度でバックアップを行うことによるコストは大変大きくなってしまうでしょう。

対して後者は、バックアップの頻度は1日1回で良いことになり、バックアップにかかるコストは小さく出来ますが、障害発生時から最大で過去24時間分のデータを喪失する可能性があるということでもあります。

リアルタイムに更新され続けるデータと、1日1回しか更新されないデータとでは求められるPROは異なってきます。アプリケーションのデータ更新頻度やバックアップにかかるコストの双方を考慮してRPOを決定する必要があります。

• RTO（Recovery Time Objective）

RTOは「目標復旧時間」という意味で、システムの復旧までにかかる時間の目標値のことです。RTOを小さく（短く）すればするほど、システムを短時間で復旧できることを意味します。しかし、RTOを小さくするためには単純にデータのバックアップを取得しておくだけでなく、システム全体を冗長化して待機しておくなどのダウンタイムを短くするための別の工夫も必要となります。

RPOとRTOをどこまで小さくするべきかは、対象システムの経過時間による影響を考慮して、慎重に決定する必要があります。どちらの数値も小さいに越した事はありませんがコストを度外視して最小値を目指すのではなく、それぞれのビジネス規模に合わせた最適値を検討する必要があります。

可用性はどうやって高めるのか

システムの運用において可用性を高める方法は以下の2点です。

• より可用性の高いシステムへリプレイスすること
• 同じシステムを障害発生時の予備として別途用意しておくこと

前者の場合、耐障害性システムなどの導入を行い高可用性を求めるほどに大きな投資が必要になります。また、リプレイス自体の手間や現在使用している資産（システム）が無駄になってしまうなどの問題があります。

後者は冗長化と呼ばれ、可用性を高める方法としてよく使われます。冗長化の例としては、まず運用システムとは別に待機システムを用意し、両者を同期しておきます。もし障害が発生した場合に切り替えるだけで100％に近い高可用性を実現できます。（切り替えにともなうダウンタイムを考慮しない場合）つまり、あらゆるシステムにおいて障害が発生する可能性がある以上、冗長化で高可用性を担保するアプローチは基本中の基本と言って良いでしょう。

サーバの可用性

Webサーバはアクセス状況の変化の影響を受けやすく、複雑なプログラムが動作する事からトラブルが発生しやすいです。また、インターネットに直接接続されているため攻撃のターゲットとなりやすい、といった性質もあります。サービスの可用性を高めるためには、まずはサービス提供の土台となるサーバの冗長化が必要です。サーバの可用性を以下の3つに分けて説明していきます。

• オンプレミスの可用性
• 仮想サーバの可用性
• クラウドサービスの可用性

オンプレミスの可用性

• サーバが物理である点

まずはこの点から考えなくてはいけません。サーバがハードウェアである以上、故障は避けることができません。なので故障が発生する前提で故障時にもサービス全体に影響しないようにシステム設計をすることが物理サーバでの可用性を高くする基本となります。そのためには止まってしまうとサービスが利用できなくなる「SPoF（Single Point Of Failure: 単一障害点）」を無くす、あるいは少なくすることが重要になります。

• ハードウェアや回線などの予備を用意する

上記と同様の観点からではありますが、オンプレミスでは、物理的に存在するハードウェアや回線を冗長化して障害時に切り替えるという運用を行います。予備のハードウェアや回線を用意しておき、障害発生時に正常な回線に経路を切り替えることで障害による影響を最小限に抑えられます。

サーバを切り替える方法には、以下の3種類の方法があります。

• 障害時に運用系から待機系に自動的に切り替える「ホットスタンバイ」
• 待機系サーバは停止状態で用意しておき、障害発生時に待機系を起動してから切り替える「コールドスタンバイ」
• 常に複数台稼働させておき、ロードバランサーを用いて分散処理させる方法

ロードバランサーは、ロード（負荷）、バランサー（平衡・バランスを取るもの）といった意味があり、負荷分散装置のことを指します。主にWebシステムに対してかかる負荷を複数のサーバへ分散させて、処理バランスを調整するために用いられます。

複数のサーバを用意することで仮に1つのサーバがダウンしても残ったサーバでサービスの継続が可能です。この冗長化を実現するためには、複数のサーバそれぞれに対する負荷やサーバダウンに対応して処理を効率的にバランスよく割り振る必要があります。その役割を担えるのがロードバランサーであり、ロードバランサーを導入することで安定したサービス提供を維持することができます。

仮想サーバの可用性

仮想サーバは、1台の物理サーバ上で複数のOSを動かすことで、仮想的に複数のサーバとして運用する方法です。使用する基盤はあくまでも物理サーバなので、仮想サーバを動かす物理サーバに対しての冗長化はオンプレミスと同じです。

オンプレミスとの違いとして、仮想サーバを起動させる物理サーバ自体を遠隔地かつ複数拠点に置くことが可能という点です。そうすることで災害時や事故でひとつの地点に深刻なハードウェア障害が起きた時にも安心です。仮想サーバごと別のハードウェアに移行し、マイグレーションを行うことですぐに業務を再開することができます。ですので仮想サーバで運用することは、国の定める事業継続計画（BCP）の対策にも有効と言えます。

クラウドサービスの可用性

クラウドサービスは、導入時の初期費用を抑えられることもあり、手軽に導入することが可能です。そのため、開発者の利用や企業のシステムをオンプレミスからクラウドへ移行するなどで利用されることは少なくありません。

クラウドベンダーを利用する利点は、インフラストラクチャー（システム基盤）部分をクラウドベンダー側で管理・提供してくれるので、ユーザはそれ以外に注力できるという点です。しかし、ユーザが可用性に対して気にしなくていいという話ではありません。

• クラウドの提供する3種類のサービス形態

クラウドベンダーはサービスを利用する利用者のニーズに合わせてIaaS、PaaS、SaaSという3つのサービスモデルを提供しています。代表的なサービス（ここではAWSのサービスを取り上げる）や、可用性の確保の難易度の違いを以下に挙げます。ユーザは利用するサービスモデルによって、可用性に対する対策範囲が変わりますで注意が必要です。

まとめ

今回は「可用性」について解説しました。

可用性は普段はなかなか耳にするもの機会がないかもしれませんが、サービス提供の根幹を支える大切な概念です。どんなに素晴らしいサービスがあっても、利用者が利用したい時に使えなかったらその価値を提供することができません。

安定したサービスを提供するためにも可用性をしっかり理解し、サービスの開発を行っていきましょう。