【AWS】クラウドデザインパターン -基本

#はじめに
AWSクラウドデザインパターンとは、AWSを用いたシステムアーキテクチャの設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を分類し、ノウハウとして利用できるように整理したものである。
 
今回は、アーキテクティングの基本コンポーネントである仮想サーバや仮想ディスクの特性を活かした、基本となる**5つ**のパターンをまとめた。

尚、本文中のAWSクラウドコンポーネントの説明は割愛する。
※AWSクラウドコンポーネントに関しては[ここ](http://aws.clouddesignpattern.org/index.php/CDP:%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%82%B3%E3%83%B3%E3%83%9D%E3%83%BC%E3%83%8D%E3%83%B3%E3%83%88)を参照。

#Snapshot
ある瞬間のデータを複製し、バックアップする。
![Snapshot.png](https://qiita-image-store.s3.amazonaws.com/0/252756/477c7d35-55b9-abaa-c662-5d5cf7882a1a.png)
##特徴
- プログラムを書けばバックアップを自動化できる
- 耐久性の高いS3にバックアップできる
- 任意のリージョンにバックアップから新たにEBSを作成できる
- OSごとバックアップすればAMIとして利用できる
- 障害や不具合があった場合、容易に環境を再現したり任意のタイミングに戻したりできる

##注意点
- EC2インスタンスを起動したままスナップショットを取れるが、スナップショットを取得する際にデータの整合性を取る必要がある
- ブート領域とデータ領域をひとつのディスクで構築すれば、スナップショットの取得やEC2インスタンスの起動は容易だが、ブートディスクのデータサイズは小さいほど起動が早いし、定期的なディスクチェックにかかる時間も短くて済む。

#Stamp
環境構築を済ませた状態のAMIを作成しておき、仮想サーバを複製する。
![Stamp.png](https://qiita-image-store.s3.amazonaws.com/0/252756/f8f37f8c-2ace-5641-da16-a4177da00567.png)
##特徴
- 環境構築済みのAMIを使ってEC2インスタンスを起動すれば、起動後の設定が不要になる
- 全く同じ状態のEC2インスタンスを、任意の数だけ複製できる
- EC2インスタンス起動後の設定作業が不要になるので、自動化のスクリプトをシンプルに記述できる
- 環境構築済みのAMIを特定のユーザーにシェアしたり、公開したりできる

##注意点
- どの時点でAMIを作成・更新するかはケースバイケースである
- 全く同じ状態のEC2インスタンスが複製されるので、各インスタンスに独自の設定が必要な場合には工夫が必要
- **ベースOSの更新があった場合、更新内容が自動的にAMIに反映されないため、AMIの再作成が必要**
- **AMIを再作成すると、AMI-IDが変わるので、スクリプトやAuto ScalingでAMI-IDを指定している場合は注意が必要**
- EC2インスタンス起動時のディスクサイズを変更する場合、論理的なサイズの変更が必要

#Scale Up
必要に応じて、サーバスペックを切り替える。
![ScaleUp.png](https://qiita-image-store.s3.amazonaws.com/0/252756/e7195ec0-4cbd-3786-d274-c7ddba88bcbc.png)
##特徴
- システム設計・開発時に、厳密にサーバスペックを見積もらなくてよい
- リソース不足による機会損失を減らせる
- 費用面の無駄を省ける

##注意点
- **サーバスペック変更時に、EC2インスタンスを一時的に停止する必要がある**
- 必要なスペックがインスタンスタイプの上限を超えてしまう場合、Scale Outパターンやキャッシング、AWSの別サービスで代替する必要がある

#Scale Out
同程度のスペックのサーバを複数台並べ、高トラフィックのリクエストを処理する。
![ScaleOut.png](https://qiita-image-store.s3.amazonaws.com/0/252756/0a01ef43-faac-cc87-189e-5e572f29ca20.png)
##特徴
- トラフィック量に合わせて、処理を担当する仮想サーバの数を動的に変更できるため、サービスの継続やコスト削減、運用の手間を省ける
- ELB配下に必要なEC2インスタンスを並べるため、Scale Upよりも処理能力の限界が高い

##注意点
- **EC2インスタンスの増加が必要と判断し、起動するまでに時間がかかるため、短時間でトラフィックが急増する場合は対処できない**
- スケールインやスケールアウトを自動制御すると、サーバ台数の変動が頻繁に起き、利用料金が増加することがある
- HTTPセッション管理やSSL処理などをELBに任せるのか、配下のサーバで処理するのか考慮する必要がある
- **ELBにはスペックに応じて分散量を変える仕組みはないため、配下のEC2インスタンスタイプは統一した方がよい**
- Web/APサーバレイヤーのスケールアウトに比べ、DBサーバレイヤーのスケールアウトは難しい
- 耐障害性を高めるため、複数のAZに分散してスケールアウトさせたほうがよい
- 新たに起動したEC2にSSHする場合、ログイン時にホスト認証でフィンガープリントの確認が行われる場合があり、SSHを利用した自動処理が機能しなくなる場合がある
- EC2の設定環境の更新が必要な場合、Auto Scalingで起動する元のAMIも更新する必要がある

#Ondemand Disk
必要に応じて、ディスク容量を変更する。
![OndemandDisk.png](https://qiita-image-store.s3.amazonaws.com/0/252756/41c575b5-8d1c-1afa-fef9-7c9a59be8714.png)
##特徴
- 後からボリュームサイズを変更できるので、見積もり時の負担を軽減できる
- 必要なときにディスク容量を確保することで、費用を抑えられる
- ストライピングを行えば、ディスクI/Oの性能を向上できる

##注意点
- **EBSはS3と異なり、確保したディスク容量に応じて課金する**
- ひとつのEBSに設定できるディスク容量の上限は16TBなので、単一パーティションでそれ以上の容量が必要な場合は、ソフトウェアを利用して複数のEBSを単一のボリュームとして扱うなどの工夫が必要
- 20,000IOPS以上のスループットが必要であれば、複数のEBSを使ってストライピングする

##関連
【AWS】クラウドデザインパターン -可用性向上
https://qiita.com/AtsushiUemura/items/12d47243c948f1760a2d

#参考
- Amazon Web Services クラウドデザインパターン設計ガイド 改訂版 ( http://amzn.asia/d/flWZUTC )
- AWSクラウドデザインパターン( http://aws.clouddesignpattern.org/ )