可用性 - 信頼性の柱

可用性

可用性 (サービス可用性とも呼ばれます) は、回復力を数量的に測定するためによく使用されるメトリクスであると同時に、的を絞った回復力目標でもあります。

  • 可用性は、ワークロードが使用可能な時間の割合です。

「使用可能」とは、取り決めた機能を必要なときに正常に実行できることを意味します。

この割合 (%) は、月、年、直近 3 年などの時間単位で計算します。可能な限り厳密に解釈すると、予定された中断や予定外の中断を含め、アプリケーションが正常に動作しないときは、可用性が下がることになります。可用性は次のように定義されます。

$\text{Availability} = \ \frac{\text{Available}\ \text{for}\ \text{Use}\ \text{Time}}{\text{Total}\ \text{Time}}$

  • 可用性は、一定期間 (通常は 1 か月または 1 年) の稼働時間の割合 (例: 99.9%) です。

  • 一般的には「9 の数」で省略して表現され、例えば、「ファイブナイン」は 99.999% の可用性という意味になります。

  • 一部のお客様は、計画されたサービスのダウンタイム (計画メンテナンスなど) を計算式の合計時間から除外することを選択します。ただし、このような時間にもユーザーがサービスを利用したい可能性があるため、この方法はお勧めしません。

アプリケーションの可用性における一般的な設計目標と、この目標の達成中、1 年以内に中断が発生する可能性のある最大時間を以下の表に示します。この表には、可用性レベルごとによく知られているアプリケーションの種類の例が示されています。このドキュメント全体を通して、これらの可用性の値を参考にします。

可用性 最大利用不可能時間 (年間) アプリケーションのカテゴリ
99% 3 日と 15 時間 バッチ処理、データの抽出、転送、ロードジョブ
99.9% 8 時間 45 分 ナレッジ管理、プロジェクト追跡などの社内ツール
99.95% 4 時間 22 分 オンラインコマース、POS
99.99% 52 分 動画配信、ブロードキャストワークロード
99.999% 5 分 ATM トランザクション、通信ワークロード

リクエストに基づく可用性の測定。サービスの場合、「使用可能な時間」の代わりに、成功したリクエスト数と失敗したリクエスト数をカウントする方が容易かもしれません。この場合、次の計算を使用できます。

これは多くの場合、1 分間または 5 分間で測定されます。次に、これらの期間の平均から、1 か月の稼働時間率 (時間ベースの可用性測定) を計算できます。特定の期間に受信したリクエストがなかった場合、その時間の可用性は 100% になります。

ハードな依存関係を持つ可用性を計算する。多くのシステムは他のシステムとハードな依存関係にあり、依存するシステムでサービス停止が起こると、呼び出す側のシステムにも影響します。この反対はソフトな依存関係で、依存関係にあるシステムに障害が起こると、アプリケーションがそれを補完します。ハードな依存関係が存在する場合、呼び出す側のシステムにおける可用性は、依存するシステムの可用性の積になります。例えば、可用性 99.99% を実現するように設計されたシステムが、同様に可用性が 99.99% である他の 2 つのシステムに依存する場合、このワークロードの可用性は、理論的には 99.97% になります。

Availinvok × Availdep1 × Availdep2 = Availworkload

99.99% × 99.99% × 99.99% = 99.97%

したがって、お客様自身で可用性を計算する場合は、このシステムとの依存関係と、それらの可用性の設計目標を理解することが重要です。

冗長コンポーネントの可用性を計算する 独立した、冗長化されたコンポーネント (複数のアベイラビリティーゾーンの冗長リソースなど) をシステムが使用する場合、理論的な可用性は、100% からそのコンポーネントの障害率の積を引いたものになります。例えば、あるシステムが 2 つの独立したコンポーネントを利用し、それぞれ 99.9% の可用性を持つ場合、この依存関係の実効可用性は 99.9999% になります。

Diagram showing calculation of availability with redundant components in a system.

Availeffective = AvailMAX − ((100%−Availdependency)×(100%−Availdependency))

99.9999% = 100% − (0.1%×0.1%)

ショートカット計算: 計算内のすべてのコンポーネントの可用性が 9 のみで構成されている場合は、9 の桁の数を合計するだけで答えが得られます。上記の例では、2 つの独立した、冗長なコンポーネントは 9 が 3 つの可用性を持つため、結果は 9 が 6 つになります。

依存するシステムの可用性を計算する 依存関係によっては、多くの AWS のサービスの可用性設計目標など、可用性に関するガイダンスを提供するものもあります。ただし、これを利用できない場合 (メーカーが可用性情報を公開していないコンポーネントなど)、推測する 1 つの方法は、平均故障間隔 (MTBF) と平均復旧時間 (MTTR) を特定することです。可用性の推測値は、次の方法で計算できます。

$$\text{Avail}_{\text{EST}} = \frac{\text{MTBF}}{MTBF + MTTR}$$

例えば、MTBF が 150 日、MTTR が 1 時間なら、可用性の推測値は 99.97% です。

詳細については、可用性の計算に役立つ、「Availability and Beyond: Understanding and improving the resilience of distributed systems on AWS」を参照してください。

可用性のコスト 通常は、アプリケーションの可用性レベルを高く設計すればコストは増大するため、設計に着手する前に可用性の正確なニーズを特定することが重要です。可用性レベルが高いと、網羅的な障害シナリオのもとで、厳しいテスト条件と検証条件が課されることになります。このような場合、あらゆる種類の障害からの回復に自動化が必要になり、システム運用のすべての側面が同様に構築され、同じ基準に基づいてテストされることが必要になります。例えば、容量の追加や削除、更新されたソフトウェアや設定変更のデプロイまたはロールバック、システムデータの移行などが、可用性の設計目標を満たすように実施される必要があります。極めて高いレベルの可用性を前提にソフトウェア開発のコストを積み上げると、システムのデプロイ速度が遅くなるため、イノベーションが難しくなります。このため、これに対するガイダンスは、基準を適用しながら、システム運用におけるライフサイクル全体にわたって適切な可用性の目標を検討することです。

可用性の設計目標が高いシステムにおけるもう一つのコスト増大の原因は、依存関係にあるシステムの選択にあります。目標レベルが高ければ、依存関係を持つソフトウェアまたはサービスの選択肢が狭くなり、前述のようにそれに基づくコストも増大していきます。可用性の設計目標が高くなるほど、リレーショナルデータベースのような多目的のサービスは少なくなり、目的に特化したサービスが多くなります。これは、後者の方が評価、テスト、自動化が容易で、含まれているが使用されていない機能との予期せぬ相互作用の可能性が低いためです。