JAWS-UG Summit2012にいってきた　(2012-03-03)第二日目 その２

ここからはパターン実践編。仮想シナリオをもとにパターン適用していきます。

クラウドデザインパターン コンテンツ配信編 (Amazon 片山氏 @c9katayama)

  1. シナリオ
    1. 雲の写真を載せるブログサイト開始
    2. はじめは個人的に開始
    3. 動画や過去画像集も公開
    4. まさかの大人気
    5. まさかの海外展開
  1. ブログサイトの開始
  1. 動画・過去画像集を公開
    1. 課題
      • サイズが大きく、ダウンロード負荷の高いコンテンツの配信
      • EC2のスケールアップ・アウトが費用がかかる
      • データ容量は未知数
    1. そこで「WebStorageパターン」ですよ
      • アクセス不可の高い動画や画像コンテンツをS3に逃すパターン
      • S3のDNS名をCNAMEに登録して仕様
      • S3のWEBサーバ機能を利用
      • EC2を複数立てるより安価
    1. パターン適用
  1. まさかの大人気
    • アクセス増加によりアクセスできない状況に
    • EC2やELB導入は費用がかかる
  1. そこで「DirectHostingパターン」ですよ
    • HTML、画像、CSSなど静的コンテンツをすべてS3でホスティング
    • EC2はコンテンツ更新とコメント投稿や動的ページだけで使用
    • JSONPを使用し、EC2から表示用の差分データだけを取得して画面更新する方法も可能
  1. パターン適用
    • MTで生成したファイルをすべてS3へ定期保存
    • サイトのメインDNSをS3へ割り当て、訪問者はS3へ
  1. S3マウントのソリューション
    • S3へデータコピーするOSSを利用する
    • S3FSなど
  1. まさかの海外展開
    1. 課題
      • 海外のマニアがサイト発見
      • 海外の有名ニュースサイトへの掲載が決定
      • 掲載までに海外の対応を行う
    1. そこで「Cache　Distributionパターン」ですよ
      • ユーザに近い場所からの配信
      • 世界各地のエッジサーバを利用し、オリジンサーバのコンテンツをキャッシング
      • AmazonCloudFrontを利用
    1. パターンの適用
      • ３つのサブドメインを利用
      • ブログコンテンツ（www)、動画・画像(data)、コンテンツ管理コメント投稿(mt)
      • S3から配信するデータは、S3のファイルをCloudFrontへ展開
      • メインコンテンツをS3＋CloudFrontにしたので更新が遅い（最大１時間など）
      • CloudFrontへの初回アクセスは遅い。更新後、バッチでクロールしておくなど
  1. 最終型
    • コンテンツ＝S3
    • 画像・動画＝CloudFront＋S3
    • Blog投稿＝EC2
  1. 重要なのは、最初だけでなく周期的なカイゼン

クラウドデザインパターンEC編 (玉川氏)

  1. シナリオ
    • 雲グッズ販売サイト開始
    • ECサイトをとりあげ「可用性」「耐障害性」を高めるパターンを中心にQWSを使用した実装方法を解説
  1. 初期
  1. FloatingIPパターン
    1. 課題
    • 利用ソフトのバージョンアップが必要
    • テスト環境でバージョンアップし、懸賞して、本番環境とのIPアドレス入れ替えを行う
    1. 解決
      • EIPでサーバに静的IPを振って、切り替える。Route53を使えばDNSの伝播は一瞬
  1. Server Swappingパターン
    1. 課題
      • サーバに障害が発生して、速やかに復旧したい
      • 以前取得したマシンイメージを元に仮想サーバをたてる
      • （壊れた）本番環境の最新データを持つディスクを移行して、復旧する
    2. 解決
  1. Multi-Serverパターン
    1. 課題：
      • Webサーバが落ちてもシステム全体で稼働し続けるようにしたい
      • Multi-Serverパターンを適用し、Webサーバを冗長化する
    2. 解決
      • ロードバランサ（ELB)
      • WEBサーバ（EC2)ｘ２の冗長構造
      • DBサーバ（RDS）
      • の３層構造にする。

RDSとは,クラウド上でのRDBMSサービス.作成が簡単

    1. パターンの適用
      • DBデータをダンプする
      • 作成したRDSのDBインスタンスにインポートする
      • ECCudeのデータベースの接続情報をRDSに書き換える
      • ロードバランサの起動
        • ECCUBEでSSLをサポート、ELBでも対処可能だがECCUBEを使う。
        • ELBでもSSLの解除は可能。ELB-EC2間の通信は平文でも暗号でも対応できる
      • ヘルスチェックの設定
      • ELB配下にEC2を追加
      • 切り離しテストも可能
  1. DBReplicationパターンの適用
    1. 課題：
      • DB部分のSPOF(単一障害点)を解消したい
    2. 対応
      • RDSでマルチAZを設定。障害時に自動でスタンバイサーバのレプリカDBに切り替わる
  1. Multi-Datacenterパターンの適用
    1. 課題
      • サーバレベルだけでなくデータセンタレベルの障害にも対応できるようにする
    2. 対応
      • ロードバランサ以下のレイヤをマルチリージョンで設定する。
      • EC2から異なるリージョンのRDSへ接続は可能（遅延はある3-5ms）
  1. 最終型
    • ELB（ロードバランサ）
    • （異なるリージョン）のAZ(AbilityZone)にEC2-RDSを２台配置
    • RDSはMultiAZとして、一台をスタンバイとし、２台のEC2はメインサーバに接続する
  1. その他適用可能なパターン
    • Multi-Region
    • DeepHelthCheck

デザインパターン　キャンペーンサイト編（鈴木氏 cloudpack(iret社)　@suz_lab）

  1. シナリオ
    • ECサイトが大人気
    • さらなる販促のためのキャンペーンサイト
    • アクセス急増のため順次パターンを適用
    • WordPressを使用
  1. キャンペーンサイト解説
    • スモールスタート
    • EC2 1インスタンスで開始
    • EIPで静的IPを振って。Route53でDNSに登録
  1. CloneServerパターン
    • サーバのクローン
    • 現状のシステムを変更することなく容易にスケールアウト
    • マスタEC2がSPOF
    • ファイルアップロードなどはマスタで
    • マスタのAMIをEC２に展開。
      • ファイルはマスタにアップし、rsyncで定期的にスレーブに同期
    • クローン用AMIを作成
      • rsync/MySQLの調整
      • 起動したままAMIのスナップショットをとる
      • スレーブインスタンスをEC2で起動し、AMIを適用して、設定を調整
      • ELBを設定して負荷分散、マスタとスレーブを格納
  1. ScaleOutパターン
    • サーバ数の動的増減
    • 手動/Auto ScalingでAMIから起動
      • CloudWatchでしきい値監視し、AutoScalingを設定していて自動スケールアウト（EC2インスタンス起動、コンテンツ同期、ELB格納など）
    • ELBの利用を前提
    • ただし、急なトラフィック増には対応しきれない
  1. NFS Sharingパターン
    • 共有コンテンツの利用
    • リアルタイムで共有コンテンツを反映
    • 共有コンテンツを頻繁に変更
    • セットアップが容易
    • ただし、NFSサーバがSPOF
    • NFSでリアルタイム同期
  1. NFSReplicaパターン
    • 共有コンテンツの複製
    • NFS部分のパフォーマンス問題
    • ローカルディスクのコンテンツをコピー
    • NFSサーバが落ちていても読み取りは可能
    • 読み取りはローカルディスク(rsync) -> EBSよりも高速
    • 書き込みはNFS
    • 読み取り・書き込みのディレクトリを分けてシンボリックリンクで使い分ける
  1. Read Replicaパターン
    • 読み取り専用のDBを作成
    • 頻度の高い読み込みの複製
    • DBの読み取りクエリの負荷分散
    • データ解析用途で利用することも可能
    • 非同期レプリケーションになることを注意
    • HyperDB（WordPressプラグイン）で読み書きの分散
    • RDS化
    • WEBコンソールでRead専用レプリカを作成可能
    • その他MySQLProxyを使うなど
  • 課題：アクセスは静的コンテンツがほとんどだった！
  1. URLRewritingパターン
    • 静的コンテンツの退避
    • 静的コンテンツのアクセスをS3/CF(CloudFront)に
    • mod_ext_filterやNginxでURLの書き換え（WEBサーバ側で静的コンテンツのURLを書き換えてS3へ振る）
    • CloudFrontの場合は、コンテンツがキャッシュ