高可用性

高可用性（HA ）は、合意されたレベルの運用パフォーマンス（通常は稼働時間）を通常よりも長い期間にわたって確保することを目的としたシステムの特性です。 ^[1]

近代化の結果、現在ではこれらのシステムへの依存度が高まっています。たとえば、病院やデータセンターでは、日常業務を遂行するために、システムの可用性を高める必要があります。可用性とは、ユーザーコミュニティがサービスや商品を入手したり、システムにアクセスしたり、新しい作業を送信したり、既存の作業を更新または変更したり、以前の作業の結果を収集したりする能力を指します。ユーザーがシステムにアクセスできない場合、ユーザーの観点からは、システムは利用できません。^{[2]一般に、}ダウンタイムという用語は、システムが利用できない期間を指すために使用されます。

高可用性はネットワークの 復元力の特性であり、「障害や通常運用への課題に直面しても、許容できるレベルのサービスを提供し、維持する」能力です。^[3]サービスに対する脅威と課題は、単純な構成ミスから大規模な自然災害、標的型攻撃まで多岐にわたります。^[4]そのため、ネットワークの復元力は非常に幅広いトピックに関係します。特定の通信ネットワークの復元力を高めるには、起こりうる課題とリスクを特定し、保護するサービスに対して適切な復元力の指標を定義する必要があります。^[5]

通信ネットワークが重要なインフラの運用における基本的な構成要素になりつつあるため、ネットワークの回復力の重要性は継続的に高まっています。[ ^{6]そのため、最近の取り組みでは、重要なインフラへの応用によるネットワークとコンピューティングの回復力の解釈と改善に重点が置かれています。 [7]}一例として、回復力の目標として、ネットワーク自体のサービスではなく、ネットワークを介したサービスのプロビジョニングを検討することができます。これには、ネットワークとネットワーク上で実行されるサービスの両方からの調整された応答が必要になる場合があります。^[8]

これらのサービスには以下が含まれます。

• 分散処理をサポートする
• ネットワークストレージをサポート
• 通信サービスの維持など
  • ビデオ会議
  • インスタントメッセージ
  • オンラインコラボレーション
• 必要に応じてアプリケーションやデータにアクセス

レジリエンスと生存可能性は、特定の研究の文脈に応じて互換的に使用されます。^[9]

信頼性エンジニアリングには、高可用性の実現に役立つ システム設計の原則が 3 つあります。

1. 単一障害点の排除。これは、コンポーネントの障害がシステム全体の障害を意味しないように、システムに冗長性を追加または構築することを意味します。
2. 信頼性の高いクロスオーバー。冗長システムでは、クロスオーバー ポイント自体が単一障害点になる傾向があります。信頼性の高いシステムでは、信頼性の高いクロスオーバーを提供する必要があります。
3. 障害が発生したらすぐに検出します。上記の 2 つの原則が守られていれば、ユーザーは障害に気付かないかもしれませんが、保守作業では必ず気付くはずです。

スケジュールされたダウンタイムとスケジュールされていないダウンタイムを区別することができます。通常、スケジュールされたダウンタイムは、システムの動作を中断させるメンテナンスの結果であり、通常、現在インストールされているシステム設計では回避できません。スケジュールされたダウンタイム イベントには、再起動を必要とするシステム ソフトウェアのパッチや、再起動時にのみ有効になるシステム構成の変更が含まれる場合があります。一般に、スケジュールされたダウンタイムは、通常、何らかの論理的な管理者によって開始されたイベントの結果です。スケジュールされていないダウンタイム イベントは、通常、ハードウェアまたはソフトウェアの障害や環境異常などの何らかの物理的なイベントによって発生します。スケジュールされていないダウンタイム イベントの例には、停電、CPUまたはRAMコンポーネントの障害 (またはその他のハードウェア コンポーネントの障害の可能性あり)、過熱に関連するシャットダウン、論理的または物理的なネットワーク接続の切断、セキュリティ侵害、またはさまざまなアプリケーション、ミドルウェア、およびオペレーティング システムの障害などがあります。

スケジュールされたダウンタイムを回避するためにユーザーに警告できる場合、この区別は有用です。ただし、真の高可用性が求められる場合、スケジュールされているかどうかに関係なく、ダウンタイムはダウンタイムです。

多くのコンピューティング サイトでは、計画停止時間はコンピューティング ユーザー コミュニティにほとんど影響を及ぼさないか、まったく影響を及ぼさないと想定して、可用性の計算から除外しています。こうすることで、非常に高い可用性を主張でき、継続的な可用性があるかのように見せかけることができます。真に継続的な可用性を示すシステムは比較的まれで高価であり、そのほとんどは、単一障害点を排除し、ハードウェア、ネットワーク、オペレーティング システム、ミドルウェア、およびアプリケーションのアップグレード、パッチ、交換をオンラインで行えるように、慎重に実装された特別な設計になっています。特定のシステムでは、計画停止時間は重要ではありません。たとえば、全員が帰宅した後のオフィス ビルでのシステム停止時間などです。

可用性は通常、特定の年間の稼働率として表されます。次の表は、システムが継続的に動作する必要があると仮定して、特定の可用性率に対して許容されるダウンタイムを示しています。サービス レベル契約では、月次請求サイクルに合わせてサービス クレジットを計算するために、月次ダウンタイムまたは可用性を参照することがよくあります。次の表は、特定の可用性率から、システムが使用できなくなる対応する時間数への変換を示しています。

稼働時間と可用性という用語は、しばしば互換的に使用されますが、常に同じものを指すわけではありません。たとえば、ネットワークが停止した場合、システムは「稼働」していても、そのサービスは「利用不可」になることがあります。または、ソフトウェア メンテナンス中のシステムは、システム管理者が作業するために「利用可能」である可能性がありますが、そのサービスはエンド ユーザーや顧客には「稼働中」として表示されません。したがって、ここでは用語の主題が重要です。議論の焦点がサーバー ハードウェア、サーバー OS、機能サービス、ソフトウェア サービス/プロセス、または同様のものであるかどうかに関係なく、議論の主題が 1 つで一貫している場合にのみ、稼働時間と可用性という単語を同義語として使用できます。

簡単な記憶法則では、5 つの 9 は年間約 5 分のダウンタイムを許容するとされています。10 で乗算または除算することで派生値を得ることができます。4 つの 9 は 50 分、3 つの 9 は 500 分です。反対に、6 つの 9 は 0.5 分 (30 秒)、7 つの 9 は 3 秒です。

「-9」の可用性パーセンテージに対して許容されるダウンタイム期間を計算するもう 1 つの記憶トリックは、1 日あたりの秒数という式を使用することです。 ${\displaystyle n}$${\displaystyle 8.64\times 10^{4-n}}$

たとえば、90% (「9」) の場合、指数は となり、許容されるダウンタイムは1 日あたり秒数になります。 ${\displaystyle 4-1=3}$${\displaystyle 8.64\times 10^{3}}$

また、99.999% (「ファイブナイン」) は指数 を与えるため、許容されるダウンタイムは1 日あたり秒になります。 ${\displaystyle 4-5=-1}$${\displaystyle 8.64\times 10^{-1}}$

特定の桁のパーセンテージは、数字の9の数または「9のクラス」で表すことがあります。たとえば、 99.999%の時間中断（停電、電圧低下、サージ）なしで供給される電気は、5つの9の信頼性、つまりクラス5になります。 ^{[10]特に、この用語は}メインフレーム^{[11] [12]}またはエンタープライズコンピューティングに関連して使用され、多くの場合、サービスレベル契約の一部として使用されます。

同様に、5で終わるパーセンテージには慣例的な名前があり、伝統的には9の数、そして「5」なので、99.95%は「3つの9と5」で、3N5と略されます。^{[13] [14]}これは「3つ半の9」と気軽に呼ばれていますが、^[15]これは誤りです。5は2の因数にすぎませんが、9は10の因数なので、5は0.3つの9です（以下の式による：）：^{[注 2]} 99.95%の可用性は3.5つの9ではなく3.3つの9です。^[16]もっと簡単に言えば、可用性99.9%から99.95%への上昇は2倍（非可用性0.1%から0.05%）ですが、可用性99.95%から99.99%への上昇は5倍（非可用性0.05%から0.01%）となり、2倍以上になります。^[注3]${\displaystyle \log _{10}2\approx 0.3}$

システムの非可用性に基づく9のクラス の定式化は次のようになる。 ${\displaystyle c}$ ${\displaystyle x}$

${\displaystyle c:=\lfloor -\log _{10}x\rfloor }$

（床関数と天井関数を参照）。

同様の測定が物質の純度を表すために使用されることもあります。

一般的に、ネットワーク エンジニアが可用性をモデル化および測定するときに 9 の数はそれほど使用されません。これは、数式に適用するのが難しいためです。多くの場合、非可用性は確率( 0.00001 など) として表現されるか、年間のダウンタイムが引用されます。9 の数で指定された可用性は、マーケティングドキュメントでよく見られます。^[要出典]「9」の使用は、非可用性の影響が発生時間によって異なることを適切に反映していないため、疑問視されてきました。^{[17] 9 が大量にある場合は、「非可用性」インデックス (アップタイムではなくダウンタイムの測定) の方が扱いやすくなります。たとえば、ハード ディスクまたはデータ リンクの}ビット エラー レートでは、可用性メトリックではなく「非可用性」メトリックが使用されるのはこのためです。

時には「9つの5」（55.5555555%）というユーモラスな用語が「5つの9」（99.999%）と対比して使われるが^{[18] [19] [20]}、これは実際の目標ではなく、むしろ合理的な目標を完全に達成できなかったことに対する皮肉な言及である。

可用性の測定には、ある程度の解釈が必要です。うるう年以外の年に 365 日間稼働していたシステムは、ピーク使用期間中に 9 時間続いたネットワーク障害によってその状態が覆された可能性があります。ユーザー コミュニティはシステムが利用できないと見なしますが、システム管理者は 100% の稼働率を主張します。ただし、可用性の真の定義では、システムの可用性は約 99.9%、つまり 3 つの 9 (うるう年以外の年では 8760 時間のうち 8751 時間の利用可能時間) になります。また、パフォーマンスの問題が発生しているシステムは、システムが機能し続けている場合でも、ユーザーからは部分的にまたは完全に利用できないとみなされることがよくあります。同様に、特定のアプリケーション機能が利用できないことは、管理者には気付かれないかもしれませんが、ユーザーにとっては壊滅的です。真の可用性の測定は総合的です。

可用性は、理想的には、それ自体が高可用性である包括的な監視ツール (「計測」) を使用して測定して決定する必要があります。計測が不足している場合、クレジットカード処理システムや電話交換機など、昼夜を問わず大量のトランザクション処理をサポートするシステムは、需要が定期的に低下するシステムよりも、少なくともユーザー自身によって本質的に適切に監視されることがよくあります。

代替の指標は平均故障間隔(MTBF) です。

復旧時間 (または推定修復時間 (ETR)、別名復旧時間目標(RTO)) は、可用性、つまり計画停止に必要な合計時間または計画外の停止から完全に復旧するために必要な時間、と密接に関係しています。もう 1 つのメトリックは平均復旧時間(MTTR) です。復旧時間は、特定のシステム設計と障害によって無限になる可能性があり、つまり完全な復旧は不可能です。このような例の 1 つは、二次的な災害復旧データ センター がない場合に、火災や洪水によってデータ センターとそのシステムが破壊されることです。

関連するもう 1 つの概念は、データ可用性です。これは、データベースやその他の情報ストレージ システムがシステム トランザクションを忠実に記録および報告する度合いです。情報管理では、さまざまな障害イベントで許容できる (または実際の)データ損失を判断するために、データ可用性、つまりリカバリ ポイント目標に個別に焦点を当てることがよくあります。ユーザーによっては、アプリケーション サービスの中断は許容できますが、データ損失は許容できません。

サービス レベル契約( SLA) は、組織の可用性の目標と要件を正式に定義します。

高可用性は、無人車両や自律型海洋船舶の制御システムの主要な要件の 1 つです。制御システムが利用できなくなると、地上戦闘車両(GCV) またはASW 連続航跡無人船舶(ACTUV) が失われます。

一方、システム全体の設計にコンポーネントを追加すると、複雑なシステムには潜在的な障害点が多く、正しく実装するのが難しいため、高可用性を実現するための取り組みが台無しになる可能性があります。一部のアナリストは、最も可用性の高いシステムはシンプルなアーキテクチャ（包括的な内部ハードウェア冗長性を備えた単一の高品質の多目的物理システム）に準拠しているという理論を提唱していますが、このアーキテクチャでは、パッチ適用やオペレーティングシステムのアップグレードのためにシステム全体を停止する必要があります。より高度なシステム設計では、サービスの可用性を損なうことなく、システムにパッチを適用してアップグレードすることができます（負荷分散とフェイルオーバーを参照）。高可用性では、複雑なシステムで操作を回復するために人間の介入が少なくて済みます。その理由は、停止の最も一般的な原因が人為的ミスであるためです。^[21]

一方、冗長性は、高レベルの可用性を備えたシステム (人気のある電子商取引 Web サイトなど) を作成するために使用されます。この場合、高レベルの障害検出可能性と共通原因障害の回避が求められます。

冗長部品が並列で使用され、独立して障害が発生した場合（たとえば、同じデータセンター内にない場合）、可用性が飛躍的に向上し、システム全体の可用性が向上します。N個の並列コンポーネントがあり、それぞれがX個の可用性を持っている場合、次の式を使用できます。^{[22] [23]}

並列コンポーネントの可用性 = 1 - (1 - X)^ N

たとえば、各コンポーネントの可用性が 50% しかない場合、10 個のコンポーネントを並列に使用すると、99.9023% の可用性を実現できます。

冗長性には、パッシブ冗長性とアクティブ冗長性の 2 種類があります。

パッシブ冗長性は、パフォーマンスの低下に対応できる十分な余剰容量を設計に組み込むことで、高可用性を実現するために使用されます。最も単純な例は、2 つの独立したエンジンが 2 つの独立したプロペラを駆動するボートです。1 つのエンジンまたはプロペラが故障しても、ボートは目的地に向かって進み続けます。より複雑な例は、電力伝送を含む大規模システム内の複数の冗長発電施設です。単一のコンポーネントの誤動作は、結果として生じるパフォーマンスの低下がシステム全体の仕様制限を超えない限り、障害とは見なされません。

アクティブ冗長性は、複雑なシステムで、パフォーマンスを低下させることなく高可用性を実現するために使用されます。同じ種類の複数のアイテムが、障害を検出し、投票方式を使用して障害のあるアイテムをバイパスするようにシステムを自動的に再構成する方法を含む設計に組み込まれます。これは、リンクされた複雑なコンピューティング システムで使用されます。インターネットルーティングは、この分野における Birman と Joseph の初期の研究から派生したものです。^{[24] [非一次ソースが必要]}アクティブ冗長性により、システムに複雑な障害モードが発生する可能性があります。たとえば、障害のある投票ロジックによる継続的なシステム再構成などです。

ゼロ ダウンタイム システム設計とは、モデリングとシミュレーションによって、平均故障間隔が、計画されたメンテナンス、アップグレードイベント、またはシステム寿命の間隔を大幅に超えることが示されることを意味します。ゼロ ダウンタイムには大規模な冗長性が伴い、これは一部の種類の航空機やほとんどの種類の通信衛星に必要です。グローバル ポジショニング システムは、ゼロ ダウンタイム システムの一例です。

障害計測は、冗長性が制限されたシステムで使用して、高可用性を実現できます。メンテナンス アクションは、障害インジケーターがアクティブになった後の短いダウンタイム中にのみ実行されます。障害が重大なのは、ミッション クリティカルな期間中に発生した場合のみです。

モデリングとシミュレーションは、大規模システムの理論的な信頼性を評価するために使用されます。この種のモデルの結果は、さまざまな設計オプションを評価するために使用されます。システム全体のモデルが作成され、コンポーネントを削除してモデルにストレスがかけられます。冗長性シミュレーションには、Nx 基準が含まれます。N は、システム内のコンポーネントの合計数を表します。x は、システムにストレスをかけるために使用されるコンポーネントの数です。N-1 は、1 つのコンポーネントに障害が発生する可能性のあるすべての組み合わせでパフォーマンスを評価することによってモデルにストレスがかけられることを意味します。N-2 は、2 つのコンポーネントに同時に障害が発生する可能性のあるすべての組み合わせでパフォーマンスを評価することによってモデルにストレスがかけられることを意味します。

2010年に学術的な可用性の専門家を対象に行われた調査では、企業のITシステムが利用できない理由がランク付けされています。すべての理由は、以下の各領域でベストプラクティスに従っていないことに起因しています（重要度順）。^[25]

1. 関連コンポーネントの監視
2. 要件と調達
3. オペレーション
4. ネットワーク障害の回避
5. 内部アプリケーション障害の回避
6. 失敗する外部サービスの回避
7. 物理的環境
8. ネットワークの冗長性
9. バックアップの技術的ソリューション
10. バックアップのプロセスソリューション
11. 物理的な場所
12. インフラストラクチャの冗長性
13. ストレージアーキテクチャの冗長性

これらの要因自体に関する本は2003年に出版された。^[26]

IBMグローバル・サービスの1998年の報告書によると、システムが利用できないことによる生産性と収益の損失により、1996年にアメリカの企業は45億4000万ドルの損失を被ったと推定されています。^[27]

• 可用性
• フォールトトレランス
• 高可用性クラスタ
• 総合設備効率
• 信頼性、可用性、保守性
• 応答性
• スケーラビリティ
• ユビキタスコンピューティング

• エンタープライズコンピューティングに関する講義ノート 2013年11月16日アーカイブ、Wayback Machineテュービンゲン大学
• Phil Koopman教授による組み込みシステムエンジニアリングの講義ノート
• 稼働時間計算ツール (SLA)