AWS

簡単に出来るAWSのデザインパターン

More than 1 year has passed since last update.

簡単に出来るAWSのデザパタをメモっておく

EC2

Snapshotパターン

スナップショットからAMIを作成する
※AMIから新たなEC2インスタンスを作成可

Stampパターン

EC2インスタンスを雛形から作成する
AMIを使ってEC2インスタンスをたくさん複製するもの

EC2→AMI→EC2...

メリット

  • 例えば、全く同じ設定のサーバを作るのは結構面倒なので、このStampパターンにより、AMIを複製するだけでこの煩わしさを回避できる
  • AWS上でCPUやメモリは変更可能なので、設定だけ同じにしてスケーリングさせることができ非常に便利

デメリット

  • AMI自体は最新に反映されるわけではないので、再作成の必要がある
  • 再作成するとAMI-IDが変更されてしまうので、このIDを指定する箇所がある時は面倒くさい
  • AMI作成時に整合性を取るために元のEC2インスタンスが再起動するため、非稼働中となる

Scale Upパターン

リソースを考慮し、サーバスペックを変更する

注意点

  • EC2インスタンスを一旦停止にする必要あり
  • インスタンスタイプの上限を超すことはできない
  • t2.microは無料だが、その一段階上のt2.smallは当然有料

Scale Outパターン

  • トラフィック量に合わせてEC2インスタンスを増やしたり、削減させたり可能なので、運用の手間が省ける
  • 具体的には、ロードバランサーを使って負荷分散をする

注意点

  • 数分でトラフィック量が数倍に跳ね上がるレベルの急激な奴は防げない
  • 上記の根拠は、EC2インスタンスを増加させる処理自体も時間がかかるものだから、間に合わない
  • 予めスケジューリングしてトラフィック量を予測したEC2インスタンスの増加をしておいて対応するのが良い
  • 複数のAZに分散しないと一方が死ぬと共倒れになる

Ondemand Diskパターン

  • 動的にディスク容量を変更する
  • EC2のディスクを増強、あるいは新しいディスクを増設したり、既存のディスクを拡張したりできる
  • RAIDのストライピング構成もできる

手順

  • アタッチまではAWSコンソール上
  • マウントはSSHで入ってやる
# ボリューム確認
lsblk

# Linuxパーティションにファイルシステムを作る(ext4はcentosのデフォルトだし安定している)
sudo mkfs -t ext4 /dev/xvdf

# マウント
sudo mkdir /ebs
sudo mount /dev/xvdf /ebs

# ※アンマウント(デタッチ時のEC2停止前に)
sudo umount /dev/xvdf

S3

  • 99.9*9の信頼性
  • 秒間数百万リクエストの負荷も耐える

Web Storageパターン

  • 負荷が大きいものがよくサービスにはある。例えば動画とかZip系ファイルの配信とか
  • こういうのをサーバで取得してレスポンスいちいち渡していたらコネクションが長く切れずになってしまって回線帯域が専有される→充分な速度で通信できなくなる
  • StampパタとかScaleUpパタもセオリーかもしれないが、いかんせん金がかかる

手順

  1. S3のバケット生成
  2. アクセス権をジェネレートして設定
  3. 作ったバケットのCNAMEを設定して短縮URLでアクセスできるようにする
  4. バケットにファイルをUPLOAD
  5. 直リン貼る http://バケット名.s3.amazonaws.com/ファイル名

Direct Hostingパターン

  • CDNにする
  • エッジサーバにコンテンツを経由させることによって主サーバへのアクセスを防ぐことができ、コネクションのOpenやCloseなどの問題を考えることから解放される

これでcloudFront使ってるかわかる

nslookup www.hogehoge.jp

Rename Distributionパターン

  • CDNのデメリットを防ぐ
  • キャッシュが前提の仕組みなので、更新系処理が多いコンテンツにおいては、先のパターンは意味が無い
  • やり方は、更新系処理が起きにくい静的コンテンツだけをCDNにし、そうでないものは普通のS3に入れて管理する
  • 変更する時は、名前を変更する。そうすることで最新のデータをユーザに見せる