一般的な設計原則

容量ニーズの推測が不要: ワークロードのデプロイ時に容量の決定を誤ると、費用のかかるアイドル状態のリソースが発生したり、容量の制約によるパフォーマンスへの影響に対処する必要が生じたりする可能性があります。クラウドコンピューティングにはこのような問題はありません。必要な分のみ容量を使用し、自動的にスケールインまたはスケールアウトできます。

本稼働スケールでシステムをテストする: クラウドでは、オンデマンドで本稼働規模のテスト環境を作成し、テストが完了したらリソースを削除することができます。テスト環境の支払いは実行時にのみ発生するため、オンプレミスでテストを実行する場合と比べて、わずかなコストで本番環境をシミュレートできます。

アーキテクチャの実験を念頭に置いた自動化: 自動化により、低コストでワークロードを作成およびレプリケートすることが可能になり、手作業による負担を回避できます。自動化に対する変更を追跡し、影響を監査して、必要に応じて以前のパラメータに戻すことができます。

発展するアーキテクチャを検討する: 従来の環境では、アーキテクチャに関する決定は 1 回限りの静的イベントとして実装されることが多く、システムの存続期間中に主要なバーションがいくつか発生していました。ビジネスとその状況が進化し続けるにしたがって、当初の決定では変化するビジネス要件にシステムが対応できなくなる可能性があります。クラウド上では、自動化し、オンデマンドでテストできるため、設計変更によって生じる影響のリスクを軽減できます。これにより、イノベーションを標準プラクティスとしてビジネスで活用できるよう、システムを経時的に進化させることができます。

データに基づいてアーキテクチャを駆動する: クラウドでは、アーキテクチャの選択がワークロードの動作に与える影響に関するデータを収集できます。これにより、ワークロードの改善について、事実に基づいた意思決定を行うことができます。クラウドのインフラストラクチャはコードのため、そのデータに基づいて、アーキテクチャに関する選択と改善を徐々に進めることができます。

ゲームデーを利用して改善する: ゲームデーを定期的にスケジュールし、本番環境のイベントをシミュレートすることで、アーキテクチャとプロセスのパフォーマンスをテストします。これは、改善できる箇所を把握し、組織がイベントに対応することを経験するのに役立ちます。