クラウドのメリットを活かした設計を行うには、オンプレミスとは異なる設計原理がある。
故障に備えた設計（Design for Failure）
時間が経てば故障する、ということを認識してアーキテクチャに取り入れる。
故障に備えたメカニズムを構築しておく。
Design for Failure = 単一障害点をなくす。
- 1つのデータセンターのみで運用しない
- 単一のインスタンスのみで構成しない
コンポーネントの分離
クラウドはサービス指向アーキテクチャの設計原理を踏襲する。
システムのコンポーネントを疎結合にすればするほど、スケーリングしやすくなる。
コンポーネントの分離を実現するには、Amazon SQSを使ったキューイングチェーンを利用して非同期かつ疎結合にすることができる。
また、マイクロサービスアーキテクチャを用いて、システムを複数の小規模なアービスの集合体として構成することで、コンポーネントの分離を進めることができる。
弾力性の実装
クラウドには弾力性（Elastic）という概念がある。伸縮性とも言って、リソースの性能を柔軟にスケールアウトしたり、スケールインすることができる。
弾力性を実現する方法は3つある
- 巡回スケーリング
- 一定間隔に発生する定期的なスケーリング
- イベントベーススケーリング
- イベントのためにトラフィックリクエストが急増されると予想されるときに実現するスケーリング
- スケジュールドスケールアウトパターンを利用
- Auto Scalingで定時に起動を指示
- オンデマンドの自動スケーリング
- 監視サービスを利用して、監視項目に基づいてスケールアウト、スケールインを行う
- スケールアウトパターンを利用
- CloudWatchでリソースを監視
- トラフィック増加を検知したらAuto Scalingに通知
- Auto Scalingがインスタンスを起動
並列化を考慮する
ロードバランサーを組み合わせて、並列処理を行う。
動的コンテンツデータをコンピュータの近くに、静的コンテンツデータをエンドユーザーの近くに保管する
クラウドでは、データをネットワーク経由で利用するため、配信のオーバーヘッドやボトルネック対策は必須。
- 静的コンテンツは外部に出して、エンドユーザの近くに保管
- 動的に処理するデータは、クラウド上のコンピューティングリソースの近くに保管