信頼性

信頼性の柱には、インフラストラクチャやサービスの中断から復旧し、需要に適したコンピューティングリソースを動的に獲得し、誤設定や一時的なネットワークの問題といった中断の影響を緩和する能力が含まれます。

この信頼性の柱では、設計原則、ベストプラクティス、質問の概要を説明します。実装に関する規範的なガイダンスについては、信頼性の柱のホワイトペーパーを参照してください。

設計原則

クラウドでの信頼性には、5 つの設計原則があります。

定義

クラウドでの信頼性には、3 つのベストプラクティスの分野があります。

高い信頼性を達成するため、システムの基盤について十分に計画し、モニタリングを実施する必要があります。需要や要件の変更に対応するためのメカニズムも必要です。障害を検出し、自動的に修復できるシステムを設計することが必要です。

ベストプラクティス

基盤

システムを設計する前に、信頼性に影響を与える基本的な要件を満たしておく必要があります。例えば、データセンターへの十分なネットワーク帯域幅が必要です。このような要件は、単一のプロジェクトの範囲を超えているため、無視される場合があります。この点を無視すると、システムの信頼性の達成に多大な影響が及びます。オンプレミス環境では、依存関係により、このような要件が長いリードタイムの原因となる可能性があるため、初期計画に組み込んでおく必要があります。

AWS では、このようは基本的な要件のほとんどが既に組み込まれており、必要に応じて変更できます。クラウドは基本的に制限を持たないように設計されています。つまり、十分なネットワーク性能とコンピューティング性能という要件を満たすことは AWS の責任であり、お客様はストレージデバイスのサイズといったリソースのサイズと割り当てを需要に応じて自由に変更できます。

以下の質問は、信頼性に関するこれらの考慮事項に焦点を当てています。

REL 1: サービス制限をどのように管理していますか?
REL 2: ネットワークトポロジをどのように管理していますか?

AWS では、お客様が意図せずにリソースを過剰にプロビジョニングすることのないよう、サービスの制限を設定しています (チームが要求できる各リソースの数の上限)。ビジネスのニーズに合わせて制限をモニタリングし、変更するためのガバナンスとプロセスを用意することが必要になります。クラウドを導入する際に、既存のオンプレミスリソースと統合する計画が必要になる場合があります (ハイブリッドアプローチ)。ハイブリッドモデルでは、時間をかけて徐々にオールインクラウドに移行できます。そのため、AWS とオンプレミスのリソースがネットワークトポロジとしてどのように作用し合うかを考えて設計することが重要です。

変更管理

変更がシステムに及ぼす影響に注意していれば、事前に計画できるようになります。また、モニタリングによってキャパシティーの問題や SLA 違反につながりかねない傾向をすばやく識別できます。従来の環境では、変更管理プロセスはしばしば手動で行われ、誰がいつ変更するかを効果的に制御するには、監査との注意深い連携が必要です。

AWS を使用すると、システムの動作をモニタリングし、KPI への応答を自動化できます。例えば、システムを使用するユーザーが増えた場合には、サーバーを自動で追加できます。システムの変更や変更履歴の監査を行う権限を持つユーザーを制御できます。

以下の質問は、信頼性に関するこれらの考慮事項に焦点を当てています。

REL 3: システムが需要の変化にどのように対応していますか?
REL 4: リソースをどのようにモニタリングしていますか?
REL 5: 変更をどのように実施していますか?

需要の変動に対応してリソースの追加や削除を自動で行うシステムを設計しておけば、信頼性が高まることに加え、ビジネスの成功が負担に変わってしまうことを避けられます。モニタリングを実行しておけば、KPI が予測された基準から逸脱すると、アラートが自動的にチームに送られます。環境の変更は自動的にログに記録されるため、アクションを監査して、信頼性に影響を与える可能性のあるアクションを特定できます。変更管理をコントロールすることで、必要な信頼性を実現するためのルールに効力を持たせることができます。

障害の管理

どのようなシステムでも、ある程度複雑になると障害が発生することが予想されます。そのため、それらの障害をどのように検出して対応し、再発を防止するかが問題です。

AWS では、自動化を利用してモニタリングデータに反応できます。例えば、特定のメトリクスがしきい値を超えたときに、その問題を解決する自動化されたアクションがトリガーされるよう設定できます。また、障害が発生したリソースを本番環境で診断して修正するのではなく、まずリソースを新しいものに置き換えてから、障害の発生したリソースの分析を別途実施できます。クラウドではシステム全体の一時的なバージョンを低コストで立ち上げることができるため、自動化されたテストで復旧プロセス全体を検証することも可能です。

以下の質問は、信頼性に関するこれらの考慮事項に焦点を当てています。

REL 6: データをどうバックアップするか?
REL 7: どのようにしてシステムがコンポーネントのエラーに耐えるか?
REL 8: 弾⼒性をどのようにテストしていますか?
REL 9: 災害対策をどのように計画していますか?

定期的にデータをバックアップして、バックアップファイルをテストすることで、論理的および物理的なエラーから確実に復旧できるようになります。障害の管理で重要なのは、システムに対し自動化されたテストを頻繁に実施して障害を発生させ、どのように復旧するかを確認することです。そのためには、このようなテストは定期的なスケジュールでも大きなシステム変更後にトリガーされます。KPI を積極的に追跡し、目標復旧時間 (RTO)、目標復旧時点 (RPO)、システムの回復力を評価する (特にテストシナリオで障害が発生した場合)。KPI の追跡は、単一障害点を特定して排除するのに役立ちます。目的は、システム復旧プロセスを徹底的にテストして、問題が持続する場合でも、すべてのデータを復旧し、サービスをお客様に提供し続けられることを確認することです。復旧プロセスも、通常の本番プロセスと同じように実施する必要があります。

主要な AWS のサービス

信頼性に不可欠なAWS のサービスは Amazon CloudWatch であり、はランタイムメトリクスをモニタリングします。。以下のサービスと機能では、信頼性の 3 つの分野がサポートされます。

リソース

信頼性に関する AWS のベストプラクティスの詳細については、以下のリソースを参照してください。

Reliability Pillar
How do I manage my AWS service limits?
Embracing Failure: Fault-Injection and Service Reliability
AWS Limit Monitor
Service Limits
Service Limits Reports Blog
Amazon Virtual Private Cloud
AWS Shield
Amazon CloudWatch
Amazon S3
AWS KMS
Backup Archive and Restore Approach Using AWS
Managing your AWS Infrastructure at Scale
AWS Disaster Recovery
AWS Amazon VPC Connectivity Options
AWS Premium Support
Trusted Advisor