設計原則

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

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

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

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

• キャパシティーを勘に頼らない: オンプレミスのワークロードにおける障害の一般的な原因はリソースの飽和状態で、ワークロードに対する需要がそのワークロードのキャパシティーを超えたときに発生します (これは頻繁にサービス妨害攻撃のターゲットとなる)。クラウドでは、需要とワークロード使用率をモニタリングし、リソースの追加と削除を自動化することで、プロビジョ二ングが過剰にも過小にもならない、需要を満たせる最適なレベルを維持できます。それでも制限はありますが、一部のクォータは制御でき、その他のクォータは管理可能です (「 サービスクォータと制約を管理する) を指定する必要があります。

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