# 定義
このホワイトペーパーでは、クラウドの信頼性を対象として、次の 4 つの分野のベストプラクティスについて説明します。
+ 基礎
+ ワークロードアーキテクチャ
+ 変更管理
+ 障害管理
信頼性を実現するには、基盤、つまりワークロードに対して Service Quotas とネットワークトポロジを適応させた環境を作ることから始める必要があります。分散システムにおけるワークロードのアーキテクチャは、障害を防止および軽減するように設計する必要があります。ワークロードは需要または要件の変化に対応する必要があり、障害を検出して自動的に復旧するように設計する必要があります。
**Topics**
+ [回復力、および信頼性のコンポーネント](resiliency-and-the-components-of-reliability.md)
+ [利用可能な状況](availability.md)
+ [ディザスタリカバリ (DR) 目標](disaster-recovery-dr-objectives.md)
# 回復力、および信頼性のコンポーネント
クラウド内のワークロードの信頼性はいくつかの要因に依存しますが、その基本となるのは回復力です。
+ **回復力**は、インフラストラクチャまたはサービスの中断から復旧し、需要に合わせて動的にコンピューティングリソースを取得し、設定ミスや一時的なネットワーク問題のような障害を軽減するワークロードの能力です。
ワークロードの信頼性に影響を与えるその他の要因には、次のようなものがあります。
+ 運用上の優秀性。これには、変更の自動化、障害対応のためのプレイブックの利用、アプリケーションに本番運用の準備ができていることを確認するための運用準備状況レビュー (ORR) が含まれます。
+ セキュリティ。これには、可用性に影響を与える、悪意のある行為によるデータまたはインフラストラクチャへの危害を防止することが含まれます。例えば、データの安全性を確保するには、バックアップを暗号化します。
+ パフォーマンス効率。これには、最大リクエストレートの設計とワークロードに対するレイテンシーの最小化が含まれます。
+ コスト最適化。これには、静的な安定性を達成するために EC2 インスタンスにより多く費用をかけるか、より多くの容量が必要な場合に自動スケーリングに依存するかどうかといったトレードオフが含まれます。
回復力は、このホワイトペーパーにおける最大の焦点です。
他の 4 つの要素も重要であり、[AWS Well-Architected フレームワーク](https://aws.amazon.com/architecture/well-architected/)のそれぞれの柱によってカバーされています ここに記載されているベストプラクティスの多くは、信頼性の面にも対応しますが、焦点は回復力です。
# 利用可能な状況
可用性 (サービス可用性とも呼ばれます) は、回復力を数量的に測定するためによく使用されるメトリクスであると同時に、的を絞った回復力目標でもあります。
+ **可用性**は、ワークロードが使用可能な時間の割合です。
「使用可能」とは、取り決めた機能を必要なときに正常に実行できることを意味します。
この割合 (%) は、月、年、直近 3 年などの時間単位で計算します。可能な限り厳密に解釈すると、予定された中断や予定外の中断を含め、アプリケーションが正常に動作しないときは、可用性が下がることになります。可用性は次のように定義されます。
![\[\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/images/availability-formula.png)
+ 可用性は、一定期間 (通常は 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 トランザクション、通信ワークロード |
**リクエストに基づく可用性の測定。**サービスの場合、「使用可能な時間」の代わりに、成功したリクエスト数と失敗したリクエスト数をカウントする方が容易かもしれません。この場合、次の計算を使用できます。
![\[Mathematical formula for calculating availability using successful responses divided by valid requests.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/images/availability-formula-requests.png)
これは多くの場合、1 分間または 5 分間で測定されます。次に、これらの期間の平均から、1 か月の稼働時間率 (時間ベースの可用性測定) を計算できます。特定の期間に受信したリクエストがなかった場合、その時間の可用性は 100% になります。
**ハードな依存関係を持つ可用性を計算する。**多くのシステムは他のシステムとハードな依存関係にあり、依存するシステムでサービス停止が起こると、呼び出す側のシステムにも影響します。この反対はソフトな依存関係で、依存関係にあるシステムに障害が起こると、アプリケーションがそれを補完します。ハードな依存関係が存在する場合、呼び出す側のシステムにおける可用性は、依存するシステムの可用性の積になります。例えば、可用性 99.99% を実現するように設計されたシステムが、同様に可用性が 99.99% である他の 2 つのシステムに依存する場合、このワークロードの可用性は、理論的には 99.97% になります。
Availinvok × Avail*dep1* × Avail*dep2* = 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.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/images/image2.png)
Availeffective = *Avail*MAX − ((100%−Availdependency)×(100%−Availdependency))
99.9999% = 100% − (0.1%×0.1%)
*ショートカット計算*: 計算内のすべてのコンポーネントの可用性が 9 のみで構成されている場合は、9 の桁の数を合計するだけで答えが得られます。上記の例では、2 つの独立した、冗長なコンポーネントは 9 が 3 つの可用性を持つため、結果は 9 が 6 つになります。
**依存するシステムの可用性を計算する** 依存関係によっては、多くの AWS のサービスの可用性設計目標など、可用性に関するガイダンスを提供するものもあります。ただし、これを利用できない場合 (メーカーが可用性情報を公開していないコンポーネントなど)、推測する 1 つの方法は、**平均故障間隔 (MTBF)** と**平均復旧時間 (MTTR)** を特定することです。可用性の推測値は、次の方法で計算できます。
![\[\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/images/avail-est-formula.png)
例えば、MTBF が 150 日、MTTR が 1 時間なら、可用性の推測値は 99.97% です。
詳細については、可用性の計算に役立つ、「[Availability and Beyond: Understanding and improving the resilience of distributed systems on AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-and-beyond-improving-resilience.html)」を参照してください。
**可用性のコスト** 通常は、アプリケーションの可用性レベルを高く設計すればコストは増大するため、設計に着手する前に可用性の正確なニーズを特定することが重要です。可用性レベルが高いと、網羅的な障害シナリオのもとで、厳しいテスト条件と検証条件が課されることになります。このような場合、あらゆる種類の障害からの回復に自動化が必要になり、システム運用のすべての側面が同様に構築され、同じ基準に基づいてテストされることが必要になります。例えば、容量の追加や削除、更新されたソフトウェアや設定変更のデプロイまたはロールバック、システムデータの移行などが、可用性の設計目標を満たすように実施される必要があります。極めて高いレベルの可用性を前提にソフトウェア開発のコストを積み上げると、システムのデプロイ速度が遅くなるため、イノベーションが難しくなります。このため、これに対するガイダンスは、基準を適用しながら、システム運用におけるライフサイクル全体にわたって適切な可用性の目標を検討することです。
可用性の設計目標が高いシステムにおけるもう一つのコスト増大の原因は、依存関係にあるシステムの選択にあります。目標レベルが高ければ、依存関係を持つソフトウェアまたはサービスの選択肢が狭くなり、前述のようにそれに基づくコストも増大していきます。可用性の設計目標が高くなるほど、リレーショナルデータベースのような多目的のサービスは少なくなり、目的に特化したサービスが多くなります。これは、後者の方が評価、テスト、自動化が容易で、含まれているが使用されていない機能との予期せぬ相互作用の可能性が低いためです。
# ディザスタリカバリ (DR) 目標
可用性の目標に加えて、回復力戦略には、災害イベント時にワークロードを復旧する戦略に基づいた、ディザスタリカバリ (DR) 目標も含める必要があります。ディザスタリカバリは、自然災害、大規模な技術的障害、または攻撃やエラーなどの人為的脅威に対応する、1 回限りの復旧目標に焦点を当てています。これは、コンポーネントの障害、負荷の急増、ソフトウェアのバグに対応して、一定期間の平均回復力を測定する可用性とは異なります。
組織によって定義された**目標復旧時間 (RTO)** RTO とは、サービスが中断してから復旧するまでに経過した時間の、許容される最大値のことです。これにより、サービスが使用不可のときに許容される時間枠が決まります。
組織によって定義された**目標復旧時点 (RPO)** RPO とは、データが最後に復旧した時点を起点とする経過時間の、許容される最大値のことです。これにより、最後の回復時点からサービスが中断されるまでの間に許容できるデータ損失の程度が決まります。
![\[Business continuity timeline showing RPO, disaster event, and RTO with data loss and downtime periods.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/images/business-continuity.png)
*RPO（目標復旧時点）、RTO（目標復旧時間）、災害イベントの関係。*
RTO は、停止の開始からワークロード復旧までの時間を測定する点で、MTTR (平均復旧時間) と似ています。ただし、MTTR は、一定期間にわたって複数の可用性に影響を与えるイベントに対して取られる平均値であり、RTO は、可用性に影響を与える*単一*のイベントの目標値、つまり許容される最大値です。