可用性 - 信頼性の柱

可用性

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

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

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

この割合 (%) は、月、年、直近 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 トランザクション、通信のワークロード

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

$\text{Availability} = \ \frac{\text{Successful}\ \text{Responses}\}{\text{Valid}\ \text{Requests}}$

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

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

Availinvok × Availdep1 × Availdep2 = Availークロード

99.99% × 99.99% × 99.99% = 99.97%

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

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

Avail費用対効果 = AvailMAX − ((100%−Availdependency)×(100%−Availdependency))

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

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

依存するシステムの可用性を計算する 依存関係によっては、多くの AWS のサービスの可用性設計目標など、可用性に関するガイダンスを提供するものもあります を指定する必要があります。しかしここに情報がない場合 (例えば、メーカーが可用性に関する情報を開示していない場合) は、平均故障間隔 (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」(可用性とその先へ: AWS での分散システムの回復力の把握と改善) を確認すると、可用性の計算の役に立ちます。

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

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