設計原則

クラウドには、信頼性の向上に役立ついくつかの原則があります。ベストプラクティスについてこれから説明しますが、以下の原則を覚えておいてください。

• 障害から自動的に復旧する: システムでワークロードの主要業績評価指標 (KPI) をモニタリングすることで、しきい値を超えた場合に自動化を実行できます。この場合の KPI は、サービスの運用の技術的側面ではなく、ビジネス価値に関する指標である必要があります。これにより、障害発生時の自動通知と追跡が可能になり、障害に対処する、または障害を修正するための復旧プロセスを自動化できます。より複雑な自動化を使用すると、障害が発生する前に修正を予期できます。

• リカバリ手順をテストする: オンプレミス環境では、ワークロードが特定のシナリオで動作することを実証するためのテストを行うことがよくあります。復旧戦略を検証するためにテストを実施することはあまりありません。クラウドでは、どのようにワークロードに障害が発生するかをテストし、復旧の手順を検証できます。オートメーションを使用してさまざまな障害をシミュレートすることも、以前に障害が発生したシナリオを再現することもできます。このアプローチでは、実際の障害シナリオが発生する前にテストを行い、修正できる障害経路が公開されるため、リスクが軽減されます。

• 水平方向にスケールしてワークロード全体の可用性を高める: 1 つの大規模なリソースを複数の小規模なリソースに置き換えることで、1 つの障害がシステム全体に及ぼす影響を軽減します。リクエストを複数の小規模なリソースに分散することで、一般的な障害点を共有しないようにします。

• 容量の推測をやめる: オンプレミスのワークロードにおける障害の一般的な原因はリソースの飽和状態で、ワークロードに対する需要がそのワークロードの容量を超えたときに発生します (サービス妨害攻撃の目標となることがよくあります)。クラウドでは、需要とワークロード使用率をモニタリングし、リソースの追加と削除を自動化することで、プロビジョニングが過剰にも過小にもならない、需要を満たす最適なレベルを維持できます。制限はまだありますが、いくつかのクオータは制御可能で、そのほかのクオーターも管理できます (「Service Quotas と制約の管理」を参照)。

• 自動化の変更を管理する: インフラストラクチャに対する変更は、自動化を使用して実行する必要があります。管理する必要がある変更には、自動化に対する変更が含まれており、それを追跡して確認することができます。