#はじめに
AWSクラウドデザインパターンとは、AWSを用いたシステムアーキテクチャの設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を分類し、ノウハウとして利用できるように整理したものである。
今回は、アーキテクティングの基本コンポーネントである仮想サーバや仮想ディスクの特性を活かした、基本となる5つのパターンをまとめた。
尚、本文中のAWSクラウドコンポーネントの説明は割愛する。
※AWSクラウドコンポーネントに関してはここを参照。
#Snapshot
ある瞬間のデータを複製し、バックアップする。
##特徴
- プログラムを書けばバックアップを自動化できる
- 耐久性の高いS3にバックアップできる
- 任意のリージョンにバックアップから新たにEBSを作成できる
- OSごとバックアップすればAMIとして利用できる
- 障害や不具合があった場合、容易に環境を再現したり任意のタイミングに戻したりできる
##注意点
- EC2インスタンスを起動したままスナップショットを取れるが、スナップショットを取得する際にデータの整合性を取る必要がある
- ブート領域とデータ領域をひとつのディスクで構築すれば、スナップショットの取得やEC2インスタンスの起動は容易だが、ブートディスクのデータサイズは小さいほど起動が早いし、定期的なディスクチェックにかかる時間も短くて済む。
#Stamp
環境構築を済ませた状態のAMIを作成しておき、仮想サーバを複製する。
##特徴
- 環境構築済みのAMIを使ってEC2インスタンスを起動すれば、起動後の設定が不要になる
- 全く同じ状態のEC2インスタンスを、任意の数だけ複製できる
- EC2インスタンス起動後の設定作業が不要になるので、自動化のスクリプトをシンプルに記述できる
- 環境構築済みのAMIを特定のユーザーにシェアしたり、公開したりできる
##注意点
- どの時点でAMIを作成・更新するかはケースバイケースである
- 全く同じ状態のEC2インスタンスが複製されるので、各インスタンスに独自の設定が必要な場合には工夫が必要
- ベースOSの更新があった場合、更新内容が自動的にAMIに反映されないため、AMIの再作成が必要
- AMIを再作成すると、AMI-IDが変わるので、スクリプトやAuto ScalingでAMI-IDを指定している場合は注意が必要
- EC2インスタンス起動時のディスクサイズを変更する場合、論理的なサイズの変更が必要
#Scale Up
必要に応じて、サーバスペックを切り替える。
##特徴
- システム設計・開発時に、厳密にサーバスペックを見積もらなくてよい
- リソース不足による機会損失を減らせる
- 費用面の無駄を省ける
##注意点
- サーバスペック変更時に、EC2インスタンスを一時的に停止する必要がある
- 必要なスペックがインスタンスタイプの上限を超えてしまう場合、Scale Outパターンやキャッシング、AWSの別サービスで代替する必要がある
#Scale Out
同程度のスペックのサーバを複数台並べ、高トラフィックのリクエストを処理する。
##特徴
- トラフィック量に合わせて、処理を担当する仮想サーバの数を動的に変更できるため、サービスの継続やコスト削減、運用の手間を省ける
- ELB配下に必要なEC2インスタンスを並べるため、Scale Upよりも処理能力の限界が高い
##注意点
- EC2インスタンスの増加が必要と判断し、起動するまでに時間がかかるため、短時間でトラフィックが急増する場合は対処できない
- スケールインやスケールアウトを自動制御すると、サーバ台数の変動が頻繁に起き、利用料金が増加することがある
- HTTPセッション管理やSSL処理などをELBに任せるのか、配下のサーバで処理するのか考慮する必要がある
- ELBにはスペックに応じて分散量を変える仕組みはないため、配下のEC2インスタンスタイプは統一した方がよい
- Web/APサーバレイヤーのスケールアウトに比べ、DBサーバレイヤーのスケールアウトは難しい
- 耐障害性を高めるため、複数のAZに分散してスケールアウトさせたほうがよい
- 新たに起動したEC2にSSHする場合、ログイン時にホスト認証でフィンガープリントの確認が行われる場合があり、SSHを利用した自動処理が機能しなくなる場合がある
- EC2の設定環境の更新が必要な場合、Auto Scalingで起動する元のAMIも更新する必要がある
#Ondemand Disk
必要に応じて、ディスク容量を変更する。
##特徴
- 後からボリュームサイズを変更できるので、見積もり時の負担を軽減できる
- 必要なときにディスク容量を確保することで、費用を抑えられる
- ストライピングを行えば、ディスク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/ )