Introduction
事業が継続する限り、運用されつづけるシステムが多い現IT市場において、長いシステムライフサイクルを意識したシステム開発が必要となり、可用性の高いシステム運用は、コスト・品質の両面で必須条項となっています。システム上にトラブルが発生しても、可用性などの事前対策をしておけば、システムが完全に停止してしまう事態を避けることができるでしょう。つまり、システム開発において可用性を加味することは利用者への高い満足度を提供し、システム(≒事業)の継続性を高めるものなのです。
本記事では、可用性の概要と類似の考え方との違い、可用性を高める方法について解説します。
目次
可用性とは?
可用性とは、特定のシステムが停止することなく稼働能力を割合で示したものです。アベイラビリティと呼ばれることもあり、稼働率(%)でその意味を表します。算出方法は非常にシンプルで、たとえばあるシステムが10時間稼働し、そのうち実際に稼働していた時間が7時間で、停止時間が3時間だった場合、稼働率は70%となります。
可用性は主にクラウドサービスやレンタルサーバーなどのサービス品質を示す意味で用いられ、可用性が高い=稼働時間が長い=安定的に使用できるという意味で使用されます。
したがって、可用性が高いサービスはシステムの停止時間が短いことを意味しており、それが直接的に品質の高さを表すことになります。
信頼性と耐障害性との違い
可用性とよく似た用語として、「信頼性」と「耐障害性」があります。それぞれの意味を理解していないと、完成したシステムやソフトウェアの品質が想定より低くなってしまう可能性があります。
しかし、それぞれを別々に考えていいわけではありません。可用性と信頼性・耐障害性が相互に組み合わさることで初めて、システムとして高い品質を保証できることになるためです。それぞれの意味を見ていきましょう。
信頼性とは
信頼性とは、障害に強く、障害の発生頻度が低いことを指します。可用性が稼働率を表すものであるのに対し、信頼性は平均故障間隔(平均連続稼働時間)を示しています。
例えば、あるシステムが30時間稼働しつづけ、その後障害によって30時間停止するとしましょう。この場合の可用性は50%で示すことができますが、信頼性は30時間連続して稼働することから30時間となります。このように、そもそも指している意味や単位が異なることに注意してください。
耐障害性とは
もうひとつ、可用性とよく似た用語に耐障害性があります。耐障害性とは、障害に強く、発生してもシステムを安定して稼働しつづけられる性能のことを指します。可用性は稼働時間を示す言葉ですが、耐障害性はシステムの耐久性を示すと考えるとわかりやすいでしょう。
これらの概念は互いに関連しています。耐障害性が高いということは、稼働時間が長くなります。つまり、稼働率が高いため可用性が高いという判断ができるのです。
可用性が低いことによるリスク(システム停止など)
可用性が低い状態とは、言い換えればシステムが停止するリスクが高い状態を指します。可用性が高いということは信頼性が高く、耐障害性が担保されている証拠でもあります。可用性が低いとこれらの保証ができていないと判断されてしまい、せっかくシステムをリリースしても、売り上げにつながらない可能性があります。
また、可用性が低いために利用者に迷惑をかけ、損害賠償請求に発展する可能性もあります。実際、大規模な通信障害などが発生した際には、数十億円にものぼる損害賠償を被った事例も存在しているのです。
可用性が100%に近ければ必ずこれらのリスクが回避できるわけではありませんが、低いままではあらゆる方面に迷惑や損失を生むことになってしまうかもしれません。
可用性を高める(冗長化する)方法
可用性を高めるには、次の2つの方法があります。
・可用性の高いシステムへリプレイスする
・ハードウェアを冗長化させる
多くの通信サービスやデータセンターでは可用性を「99.99%以上」としていることがスタンダードであり、お客様もそれを求めています。可用性を高めるための方法を理解しておくことで、各方面に対して、製品の品質を保証できるようになるでしょう。
可用性の高いシステムへリプレイスする
現在使用しているシステムの可用性が低い場合、より可用性が高いシステムに置き換える方法がリプレイスです。単純に置き換えるだけですが、可用性が高くなっているため、システムとしての信頼性や耐障害性がより向上するでしょう。
しかし、可用性が高いシステムは比較的高価であることが多く、リプレイスには相当な投資が必要です。手間がかかるばかりか、既存の資産が無駄になってしまう可能性も高いため、あまり現実的な手法とは言えません。
ハードウェアを冗長化する
可用性を高めるための方法で現実性が高いのは、ハードウェアを冗長化することです。冗長化とは、障害発生時に備えて別のハードウェアに予備を作っておくことで、レプリケーションによる運用系と待機系のデータを同期することでサービス再開が可能になります。
ハードウェアの冗長化には、さらに次の2種類があります。
■アクティブ・スタンバイ構成
■アクティブ・アクティブ構成
両者の違いを詳しく解説します。
アクティブ・スタンバイ構成
アクティブ・スタンバイ構成とは、同じシステムを2つ用意し、片方を稼働系、もう片方を待機系として運用する仕組みです。普段は稼働系のみが稼働している状態ですが、障害発生などで稼働系にトラブルが発生した場合に待機系に切り替えてサービス提供を継続できます。
データの同期に時間がかかるなどのデメリットはありますが、コストが低く運用も比較的容易です。そのため、多くのシステムでアクティブ・スタンバイ構成が採用されています。
アクティブ・アクティブ構成
アクティブ・アクティブ構成とは、アクティブ・スタンバイと同じように2つの同一システムを用意しますが、この2つを交互に常時運用する仕組みです。片側に障害が発生しても、もう片方のシステムが稼働することでリスク回避ができる仕組みです。さらに、平常時からシステム処理の負荷を分散できるメリットもあります。
オンプレミス型とクラウド型の違い
可用性を高めるための冗長化は、システムがオンプレミス型なのかクラウド型なのかによって方法やメリット・デメリットが異なります。それぞれのメリット・デメリットを以下の一覧にまとめました。
メリット | デメリット | |
オンプレミス型 |
■自社で自由にカスタマイズができる |
■クラウド型と比較すると運用コストがかかる |
クラウド型 |
■運用コストがリーズナブルで済む |
■カスタマイズの自由度は低い |
どちらが優れている・劣っているというわけではなく、双方に強みと弱点があることを理解しておきましょう。近年はクラウド型サービスを提供する企業が増えてきており、オンプレミス型と比較すると可用性が高まっているのは事実です。しかし、クラウド型にはオンプレミス型にはない弱点があることも知っておかなければなりません。
オンプレミス型
オンプレミス型とは、物理的にハードウェアを設置し、その中でシステムを運用するタイプのことです。コストや開発規模の問題で縮小傾向にありますが、現在でも主要な機関で多く採用されています。
オンプレミス型メリット
オンプレミス型の主なメリットは、自社で運用しているためカスタマイズ性が高く、サービスレベルを一定の水準で担保できることです。システム担当者の力量によるところもありますが、自社でカスタマイズができるため、不具合の修正などは迅速に対応ができます。
冗長化の観点では、先に紹介したアクティブ・スタンバイ構成とアクティブ・アクティブ構成のどちらにも対応可能です。クラウド型はこれらの選択ができないため、自社で可用性を担保できるのは大きなアドバンテージとなるでしょう。
オンプレミス型デメリット
一方で、オンプレミス型は導入と運用の両方で莫大なコストがかかるデメリットがあります。また、システムを保守・運営できる人材も必要になるため、人材確保にも課題が生じる場合があるでしょう。
また、オンプレミス型で冗長化に対応するためには、別途ハードウェアを設置する場所も必要となります。コスト面と物理面の両面においては、クラウド型と比較するとデメリットが大きいといえます。
クラウド型
クラウド型とは、インターネット上でサービスを利用できる仕組みのことです。オンプレミス型とは異なり利用者はサーバーを必要とせず、誰でも利用することができます。現在提供されているシステムのほとんどはクラウド型であり、今後もクラウド型のシステムが増えていくと思われます。
クラウド型メリット
クラウド型のメリットは、オンプレミス型よりも安価で導入ができる点や、物理的な問題を抱えずに済む点です。あくまでもオンプレミス型と比較した場合にリーズナブルという意味ですが、自社内に保守・管理を行う担当者が不要なのもクラウド型のメリットといえます。
また、オンプレミス型よりも障害発生率が低いのも特徴です。ベンダーによってはオプションで冗長化できる場合もあるため、検討してみるといいでしょう。
クラウド型デメリット
一方、クラウド型はカスタマイズの自由度が低いというデメリットを抱えています。冗長化するにも自社内では何もできないことが多く、基本的にはベンダーに任せなければなりません。さらに、ベンダーによって可用性やセキュリティ体制が異なるため、サービスのレベルはベンダー次第というデメリットもあります。
先述した通り、オプションでベンダーに冗長化をしてもらうことはできますが、ベンダー側が対処できない事態になると、システム全体が止まってしまうというデメリットを抱えている点はしっかりと覚えておきましょう。
可用性との向き合い方
可用性を含めた非機能要件は、お客様や利用者からの確実な要望はなく、利用者の視点に立って、システム提供側である開発部隊が考えなければならない項目です。システム知見を有している開発部隊が、定義すべき項目やその内容に関してしっかりオーナーシップをもって、推進していかなければならないことを前提に、プロジェクトを進めてください。
また、改善や向上の必要性や、施策の方法論を判断するためにも、現状を適切に知ることも非常に重要です。
弊社SHIFTでは、
・可用性を含めた非機能要件定義
・可用性を担保したインフラ構築
・現状を知るための非機能評価
・可用性向上のための改善施策
といった、可用性を担保するために必要な支援を一貫して取り揃えています。
少しでも自社システムに対する不安があれば、ぜひお近くの弊社メンバーへのお声がけや、Webからの問合せをお待ちしております。
まとめ
可用性は、システムの信頼性を保証する重要な指標です。信頼性・耐障害性とともにシステムの品質を担保するものであり、可能な限り100%になるように近づけていく必要があります。リプレイスや冗長化など、可能な選択肢はいくつも存在しているため、その中から自社システムの可用性を高められるような施策を実施していきましょう。