可用性

可用性は、システムの稼働時間を特定する基準で、通常はユーザーがシステムにアクセス可能な時間の割合で測定されます。システムにアクセスできなくなる時間 (停止時間) は、ハードウェア、ソフトウェア、ネットワークの障害、またはシステムをダウンさせるその他の要因 (停電など) によって生じます。サービスの予定された停止時間 (保守およびアップグレード) は、停止時間とみなしません。稼働時間の割合でシステムの可用性を計算する基本的な方程式は、次のとおりです。

可用性 = 稼働時間 / (稼働時間 + 停止時間) * 100%

一般に、可用性は達成できる「ナイン」の数で表現されます。たとえば、99% の可用性であれば、2 ナインとなります。ナインの追加は、配備設計に大きく影響します。次の表では、24 時間 365 日、つまり合計 8,760 時間稼働するシステムに、可用性のナインを追加した場合の予定外の停止時間を数値化しています。

表 3–3 1 年間無休で (8,760 時間) 稼働するシステムの予定外の停止時間

ナインの数	使用可能割合	予定外の停止時間
2	99%	88 時間
3	99.9%	9 時間
4	99.99%	45 分
5	99.999%	5 分

耐障害システム

4 つまたは 5 つのナインが要求される可用性を実現するには、通常は耐障害のシステムが必要となります。耐障害システムは、ハードウェアまたはソフトウェアに障害が発生した場合にも、継続してサービスを提供できる必要があります。一般に、耐障害性は、主要サービスを提供するハードウェア (CPU、メモリ、ネットワークデバイスなど) とソフトウェアの両方に冗長性を持たせることで実現されます。

シングルポイント障害は、クリティカルパスの一部でありながら冗長コンポーネントによってバックアップされていないハードウェアまたはソフトウェアコンポーネントです。このコンポーネントで障害が発生した場合、システムはサービスを提供できなくなります。耐障害システムを設計するときは、潜在的なシングルポイント障害を特定し、それを取り除きます。

耐障害システムの実装と維持は、高額になる可能性があります。可用性に関するビジネス要件の本質を理解し、それらの要件に見合った可用性ソリューションの戦略とコストを考慮する必要があります。

サービスの可用性の優先順位付け

ユーザー側から見ると、多くの場合、システム全体の可用性よりも、サービス単位の可用性のほうが重要です。たとえば、インスタントメッセージングサービスが利用できなくなっても、通常、その他のサービスの可用性には影響がまったくないか、あってもごく軽微なものです。しかし、その他のサービスの多くが依存するサービス (Directory Server など) が利用できなくなると、はるかに広範な影響をもたらします。高い可用性の仕様には、可用性の向上を必要とするユースケースと使用パターン分析が明確に参照されている必要があります。

可用性の必要性を優先度の順にリストしておくと便利です。次の表は、各種サービスの可用性の優先順位を示しています。

表 3–4 優先度順のサービスの可用性

優先順位	サービスの種類	説明
1	ミッションクリティカル	常時使用可能である必要のあるサービス。たとえば、アプリケーションに対するデータベースサービス (LDAP ディレクトリなど) です。
2	使用可能である必要あり	使用可能である必要はあるが、パフォーマンスが低下しても問題はないサービス。たとえば、ビジネス環境によっては、メッセージングサービスの可用性は重要視されない場合があります。
3	延期可能	特定期間内に使用可能であることが必要となるサービス。たとえば、ビジネス環境によっては、カレンダサービスの可用性は重要視されない場合があります。
4	省略可能	恒久的に延期しても問題のないサービス。たとえば、ビジネス環境によっては、インスタントメッセージングサービスは有用ではあっても必要ではないと考えられる場合があります。

サービスの損失

可用性設計では、可用性が低下した場合や、コンポーネントが失われた場合の状況も考慮します。これには、接続していたユーザーがセッションを再起動する必要があるかどうか、また 1 つの領域で発生した障害がシステムのほかの領域にどのような影響を与えるかについて考慮することも含まれます。QoS 要件には、これらのシナリオが考慮されていて、配備によるこれらの状況への対処が示されている必要があります。