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

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

はじめに

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を使ってストライピングする

ひとこと

次回は可用性向上パターンについてまとめます。

参考

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