LoginSignup
34
27

More than 5 years have passed since last update.

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

Last updated at Posted at 2018-11-20

はじめに

AWSクラウドデザインパターンとは、AWSを用いたシステムアーキテクチャの設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を分類し、ノウハウとして利用できるように整理したものである。

今回は、アーキテクティングの基本コンポーネントである仮想サーバや仮想ディスクの特性を活かした、基本となる5つのパターンをまとめた。

尚、本文中のAWSクラウドコンポーネントの説明は割愛する。
※AWSクラウドコンポーネントに関してはここを参照。

Snapshot

ある瞬間のデータを複製し、バックアップする。
Snapshot.png

特徴

  • プログラムを書けばバックアップを自動化できる
  • 耐久性の高いS3にバックアップできる
  • 任意のリージョンにバックアップから新たにEBSを作成できる
  • OSごとバックアップすればAMIとして利用できる
  • 障害や不具合があった場合、容易に環境を再現したり任意のタイミングに戻したりできる

注意点

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

Stamp

環境構築を済ませた状態のAMIを作成しておき、仮想サーバを複製する。
Stamp.png

特徴

  • 環境構築済みのAMIを使ってEC2インスタンスを起動すれば、起動後の設定が不要になる
  • 全く同じ状態のEC2インスタンスを、任意の数だけ複製できる
  • EC2インスタンス起動後の設定作業が不要になるので、自動化のスクリプトをシンプルに記述できる
  • 環境構築済みのAMIを特定のユーザーにシェアしたり、公開したりできる

注意点

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

Scale Up

必要に応じて、サーバスペックを切り替える。
ScaleUp.png

特徴

  • システム設計・開発時に、厳密にサーバスペックを見積もらなくてよい
  • リソース不足による機会損失を減らせる
  • 費用面の無駄を省ける

注意点

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

Scale Out

同程度のスペックのサーバを複数台並べ、高トラフィックのリクエストを処理する。
ScaleOut.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

特徴

  • 後からボリュームサイズを変更できるので、見積もり時の負担を軽減できる
  • 必要なときにディスク容量を確保することで、費用を抑えられる
  • ストライピングを行えば、ディスクI/Oの性能を向上できる

注意点

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

関連

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

参考

34
27
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
34
27