信頼性
信頼性の柱には、期待されるタイミングで、意図した機能を正確かつ一貫して実行するワークロードの能力。これには、そのライフサイクル全体を通じてワークロードを運用およびテストする機能が含まれます。が含まれます。
この信頼性の柱では、設計原則、ベストプラクティス、質問の概要を説明します。実装に関する規範的なガイダンスについては、信頼性の柱のホワイトペーパーを参照してください。
設計原則
クラウドでの信頼性には、5 つの設計原則があります。
-
障害から自動的に復旧する: ワークロードで主要業績評価指標 (KPI) をモニタリングすることで、しきい値を超えた場合にオートメーションをトリガーできます。この場合の KPI は、サービスの運用の技術的側面ではなく、ビジネス価値に関する指標である必要があります。これにより自動的に障害を通知および追跡することができ、障害を回避または修正する復旧プロセスも自動化できます。より複雑な自動化を使用すると、障害が発生する前に修正を予期できます。
-
復旧手順をテストする: オンプレミス環境においては、多くの場合、ワークロードが特定のシナリオで動作することを実証するためにテストが実施されます。復旧戦略を検証するためにテストを実施することはあまりありません。クラウドでは、どのようにシステム障害が発生するかをテストでき、復旧の手順も検証できます。自動化により、さまざまな障害のシミュレーションや過去の障害シナリオの再現を行うことができます。このアプローチでは、実際の障害シナリオが発生する前にテストおよび修正できる障害経路が公開されるため、リスクが軽減されます。
-
水平方向にスケールしてワークロード全体の可用性を高める: 1 つの大規模なリソースを複数の小規模なリソースに置き換えることで、単一の障害がワークロード全体に与える影響を軽減します。リクエストを複数の小規模なリソースに分散させることで、共通の障害点を共有しないようにします。
-
キャパシティーを推測することをやめる: オンプレミスのワークロードにおける障害の一般的な原因はリソースの飽和状態で、ワークロードに対する需要がそのワークロードのキャパシティーを超えたときに発生します (よくサービス妨害攻撃の目標となります)。クラウドでは、需要とワークロード使用率をモニタリングし、リソースの追加と削除を自動化することで、プロビジョ二ングが過剰にも過小にもならない、需要を満たせる最適なレベルを維持できます。制限はまだありますが、制御および管理できるクォータもあります (サービスクォータと制約の管理を参照)。
-
オートメーションで変更を管理する: インフラストラクチャに対する変更は、オートメーションを使用して実行する必要があります。管理する必要がある変更には、自動化に対する変更が含まれており、それを追跡して確認することができます。
定義
クラウドでの信頼性には、4 つのベストプラクティスの分野があります。
信頼性を実現するには、基盤、つまりサービスクォータとネットワークトポロジがワークロードに対応する環境作りから始める必要があります。分散システムのワークロードアーキテクチャは、障害を防止および軽減するように設計する必要があります。ワークロードは需要や要件の変化に対応する必要があり、障害を検出して自動的に復旧するように設計する必要があります。
ベストプラクティス
基盤
基盤となる要件は、単一のワークロードまたはプロジェクトの範囲を超える要件です。システムを設計する前に、信頼性に影響を与える基本的な要件を満たしておく必要があります。例えば、データセンターへの十分なネットワーク帯域幅が必要です。
AWS では、このようは基本的な要件のほとんどが既に組み込まれており、必要に応じて変更できます。クラウドはほぼ制限を持たないように設計されています。つまり、十分なネットワーク性能とコンピューティング性能の要件を満たすのは AWS の責任であり、お客様はリソースのサイズと割り当てを需要に応じて自由に変更できます。
以下の質問は、信頼性に関するこれらの考慮事項に焦点を当てています。
REL 1: サービスクォータと制約はどのように管理しますか? |
REL 2: ネットワークトポロジをどのように計画しますか? |
クラウドベースのワークロードアーキテクチャには、サービスクォータ (サービスの制限とも呼ばれます) というものがあります。このようなクォータは、誤って必要以上のリソースをプロビジョニングするのを防ぎ、サービスを不正使用から保護することを目的として API 操作のリクエスト頻度を制限するために存在します。多くの場合、ワークロードは複数の環境に存在します。これらのクォータは、すべてのワークロード環境でモニタリングおよび管理する必要があります。このような環境には、複数のクラウド環境 (パブリックにアクセス可能なクラウド環境とプライベートの両方) が含まれるほか、既存のデータセンターインフラストラクチャが含まれる場合があります。計画する際は、システム内およびシステム間の接続、パブリック IP アドレスの管理、プライベート IP アドレスの管理、ドメイン名解決といったネットワークに関する諸点も考慮する必要があります。
ワークロードアーキテクチャ
信頼性の高いワークロードは、ソフトウェアとインフラストラクチャの両方について事前に設計を決定することから始まります。アーキテクチャの選択は、5 つの Well-Architected の柱すべてにかけてワークロードの動作に影響を与えます。高い信頼性を保つには、特定のパターンに従う必要があります。
AWS では、ワークロード開発者は使用する言語とテクノロジーを選択できます。AWS SDK は、AWS のサービス用に言語固有の API を提供することで、コーディングの複雑さを排除します。これらの SDK と言語の選択により、開発者はここにリストされている信頼性のベストプラクティスを実装できます。開発者は、The Amazon Builders' Library で Amazon がソフトウェアを構築および運用する方法について読み、学ぶこともできます。
以下の質問は、信頼性に関するこれらの考慮事項に焦点を当てています。
REL 3: どのようにワークロードサービスアーキテクチャを設計すればよいですか? |
REL 4: 障害を防ぐために、分散システムの操作をどのように設計しますか? |
REL 5: 障害を緩和または耐えるために、分散システムの操作をどのように設計しますか? |
分散システムは、サーバーやサービスなどのコンポーネントを相互接続するために通信ネットワークを利用しています。このネットワークでデータの損失やレイテンシーがあっても、ワークロードは確実に動作する必要があります。分散システムのコンポーネントは、他のコンポーネントやワークロードに悪影響を与えない方法で動作する必要があります。
変更管理
ワークロードを信頼できる形で実行するには、ワークロードやその環境に対する変化を予測して対応することが不可欠です。変更には、需要の急増などのワークロードに負荷がかかる変更や、機能のデプロイやセキュリティパッチの適用といった内部からの変更があります。
AWS を使用すると、ワークロードの動作をモニタリングし、KPI への応答を自動化できます。たとえば、ワークロードがより多くのユーザーを獲得するにつれ、ワークロードはサーバーを追加できます。ワークロードの変更や変更履歴の監査を行う権限を持つユーザーを制御できます。
以下の質問は、信頼性に関するこれらの考慮事項に焦点を当てています。
REL 6: ワークロードリソースをモニタリングするにはどうすればよいですか? |
REL 7: 需要の変化に適応するようにワークロードを設計するには、どうすればよいですか? |
REL 8: 変更はどのように実装するのですか? |
需要の変動に対応してリソースの追加や削除を自動で行うワークロードを設計しておけば、信頼性が高まることに加え、ビジネスの成功が負担に変わってしまうことを避けられます。モニタリングを実行しておけば、KPI が予測された基準から逸脱すると、アラートが自動的にチームに送られます。環境の変更は自動的にログに記録されるため、アクションを監査して、信頼性に影響を与える可能性のあるアクションを特定できます。変更管理をコントロールすることで、必要な信頼性を実現するためのルールに効力を持たせることができます。
障害の管理
どのようなシステムでも、ある程度複雑になると障害が発生することが予想されます。信頼性は、発生時点で障害を認識し、可用性への影響を回避するための措置を講じることをワークロードに要求します。ワークロードは、障害に耐え、問題を自動的に修復できる必要があります。
AWS では、自動化を利用してモニタリングデータに反応できます。例えば、特定のメトリクスがしきい値を超えたときに、その問題を解決する自動化されたアクションがトリガーされるよう設定できます。また、障害が発生したリソースを本番環境で診断して修正するのではなく、まずリソースを新しいものに置き換えてから、障害の発生したリソースの分析を別途実施できます。クラウドではシステム全体の一時的なバージョンを低コストで立ち上げることができるため、自動化されたテストで復旧プロセス全体を検証することも可能です。
以下の質問は、信頼性に関するこれらの考慮事項に焦点を当てています。
REL 9: データはどのようにバックアップするのですか? |
REL 10: ワークロードを保護するために障害分離をどのように使用しますか? |
REL 11: コンポーネントの障害に耐えるようにワークロードを設計するにはどうすればよいですか? |
REL 12: どのように信頼性をテストしますか? |
REL 13: 災害対策 (DR) はどのように計画するのですか? |
定期的にデータをバックアップして、バックアップファイルをテストすることで、論理的および物理的なエラーから確実に復旧できるようになります。障害の管理で重要なのは、ワークロードに対し自動化されたテストを頻繁に実施して障害を発生させ、どのように復旧するかを確認することです。そのためには、このようなテストは定期的なスケジュールでも大きなワークロード変更後にトリガーされます。KPI を積極的に追跡し、目標復旧時間 (RTO)、目標復旧時点 (RPO)、ワークロードの回復力を評価します (特にテストシナリオで障害が発生した場合)。KPI の追跡は、単一障害点を特定して排除するのに役立ちます。目的は、ワークロード復旧プロセスを徹底的にテストして、問題が持続する場合でも、すべてのデータを復旧し、サービスをお客様に提供し続けられることを確認することです。復旧プロセスも、通常の本番プロセスと同じように実施する必要があります。
リソース
信頼性に関する AWS のベストプラクティスの詳細については、以下のリソースを参照してください。
Reliability Pillar: AWS Well-ArchitectedAWS Well-Architected Reliability Labs
The Amazon Builders' Library: How Amazon builds and operates software
AWS Documentation
AWS Global Infrastructure
AWS Auto Scaling: How Scaling Plans Work
Implementing Microservices on AWS
What Is AWS Backup?