1.
AWSクラウドデザインパターン
-Eコマース編-

2.
自己紹介
名前
玉川憲
所属
アマゾンデータサービスジャパン株式会社
ID
@KenTamagawa
好きなもの
イカとミスチル
好きなAWSサービス
AWS DynamoDB

3.
やりたいこと
AWSクラウドを
より伝わりやすくしたい
既存ノウハウを伝えたい
(暗黙知→形式知化)

4.
そこで
AWSクラウドデザインパターン
[beta]
(略して、CDP)

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

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

7.
Wikiでノウハウを共有

8.
例: Clone Serverパターン
ロードバランサ
Web Web Web
仮想
マスタ
サーバ
②ディスクを同期
仮想
ディスク ①サーバ起動
マシン
イメージ

9.
CDPカテゴリ (as of 2012/03/03)
基本パターン 静的コンテンツを処理 バッチ処理
Snapshot Web Storage Queuing Chain
Stamp Direct Hosting Priority Queue
Scale Up Private Distribution Job Observer
Ondemand Disk Cache Distribution Scheduled Autoscaling
Rename Distribution
可用性を高める 運用保守
Multi-Server クラウドへデータをアップロード Bootstrap
Multi-Datacenter Write Proxy Cloud DI
Floating IP Storage Index Stack Deployment
Deep Health Check Direct Object Upload Server Swapping
Monitoring Integration
動的コンテンツを処理 リレーショナル・データベース Web Storage Archive
Scale Out DB Replication
Clone Server Read Replica ネットワーキング
NFS Sharding Inmemory DB Cache OnDemand NAT
NFS Replica Sharding Write Backnet
State Sharing Functional Firewall
URL Rewriting Operational Firewall
Rewrite Proxy Multi Load Balancer
Cache Proxy WAF Proxy
CloudHub

10.
CDP、誰が作ったの？
Ninja of Three

11.
Ninja of Three

12.
このシナリオの前のシナリオ
雲の写真を載せるブログサイト開始
はじめは個人的に開始
動画や過去画像集も公開し始める
まさかの大人気
まさかの海外展開

13.
デザイン推移
動画 海外 最終
人気

14.
このシナリオの背景
まさかの
雲グッズ販売サイト開始

15.
この実装シナリオの狙い
Eコマースサイトをとりあげ、
可用性
耐障害性
を高めるパターンを中心にAWSを使用し
た実装方法を解説

16.
利用環境・ソフトウェア
EC-CUBEバージョン 2.11.4
Amazon Linux (64bit)
PHPバージョン PHP 5.3.8
DBバージョン MySQL 5.1.52

17.
ec.cloudesignpattern.org
EC-CUBEバージョン 2.11.4
Amazon Linux (64bit)
PHPバージョン PHP 5.3.8
DBバージョン MySQL 5.1.52

18.
初期のデザイン
EC-CUBE
Apache
MySQL

19.
課題
課題： 利用ソフトのバージョンアップ
が必要
テスト環境でバージョンアップ、検証し
て、本番環境との入れ替えにFloating IP
を利用

20.
Floating IPパターンの適用後
Amazon
Route 53 ec.clouddesignpattern.org
EIP
④EIPを付け替える
EIP「46.51.xxx.xxx」
本番 テスト
環境 環境 ③ソフトウェアをアップデー
トしテストを行う
EC2 EC2
①AMIを ②テスト環境用の
取得する EC2インスタンスを
立ち上げる
EC2 AMI

21.
課題
課題： サーバに障害が発生して、
速やかに復旧したい
 以前取得したマシンイメージを元に仮
想サーバを立てる
(壊れた)本番環境の最新データを持つディ
スクを移行して、復旧する

22.
Server Swappingパターンの適用後
サーバに障害
仮想 仮想
サーバ起動
サーバ サーバ
データ データ マシン
イメージ
仮想ディスク 仮想ディスク

23.
Server Swappingパターンの適用
 緊急対応サーバで、EBSボリュームをマウントする
# sudo mkdir /ebs サーバに障害
# sudo mount /dev/sdf /ebs
 「html」で新しくアタッチしたEBSボリュームを 仮想
サーバ
仮想
サーバ
サーバ起動
参照するようにシンボリックリンク作成
# sudo mv /var/www/html /var/www/html-
org
# sudo ln -s /ebs/var/www/html
/var/www/html データ データ マシン
イメージ
仮想ディスク 仮想ディスク
 MySQLのデータのディレクトリを退避させておき、
新しくアタッチしたEBSボリュームを参照するよう
にシンボリックリンクを作成する
# sudo mv /var/lib/mysql /var/lib/mysql-org
# sudo ln -s /ebs/var/lib/mysql /var/lib/mysql

24.
課題
課題： Webサーバが落ちても、システ
ム全体で稼働し続けるようにしたい
 Multi-Serverパターンを適用し、Web
サーバを冗長化する

25.
Multi-Serverパターンの適用後
ロードバランサ
オリジ 冗長
ナル 構成
EC2 EC2
インスタンス インスタンス
MySQL DB
インスタンス

26.
Amazon RDS(MySQL)とは
2009年に登場した設定と運用が容易なクラウド上
でのRDBMSサービス
Webコンソールから、設定済みでサイズ変更可能
なDBインスタンスを、ものの数分で起動
AWSが自動バックアップ、パッチ更新を管理
レプリケーション、リードレプリカも可能
現時点で、MySQLとOracle DBが選択可能
Oracleの場合、時間単位の従量課金 と、既存ライ
センス持込みをサポート

27.
RDSの作成
27

28.
Multi-Serverパターンの適用
 DBのデータをダンプする
 $ mysqldump -u ユーザー名 -pパスワード デー
タベース名 > backups/backup.sql ロードバランサ
 作成したRDSのDBインスタンスにデータをイン
ポート オリジ 冗長
$ mysql -u eccube_db_user -peccube -- ナル 構成
database=eccube_db -- EC2 EC2
host=eccubedbins.xxxxxxxxxx.ap- インスタンス インスタンス
northeast-1.rds.amazonaws.com <
backups/backup.sql
 EC-CUBEのデータベースへの接続情報を書き換え
MySQL DB
“config/config.php” インスタンス
define ('DB_SERVER',
'eccubedbins.xxxxxxxxxx.ap-northeast-
1.rds.amazonaws.com');

29.
RDSのスナップショット取得

30.
RDSでScale Upパターン

31.
Multi-Serverパターンの適用後
ロードバランサ
オリジ 冗長
ナル 構成
EC2 EC2
インスタンス インスタンス
MySQL DB
インスタンス

32.
ロードバランサの起動

33.
ロードバランサの起動
EC-CUBEでは、SSLをサポート。
ELBでも対処可能だが、今回はELBではSSLの処理はしないことに。

34.
ヘルスチェックの設定

35.
ELB配下にEC2を追加
AMIからEC2起動
ELB配下に追加

36.
Multi-Serverパターンの適用後
ロードバランサ
サーバーわざと
停止させても動く？？
オリ
冗長
ジ
構成
ナル
EC2 EC2
インスタン インスタン
ス ス
MySQL DB
インスタン
ス

37.
課題
課題： DB部分のSPOFを解消したい
 DB Replicationパターンを適用し、
DBをマルチ構成に切り替える

38.
DB Replicationパターンの適用後
ロードバランサ
オリジ 冗長
ナル 構成
EC2 EC2
インスタンス インスタンス
同期
MySQL DB MySQL DB
インスタンス スタンバイ
ゾーン1a ゾーン1b

39.
マルチAZに変更

40.
課題
課題： サーバレベルだけでなく、デー
タセンタレベルの障害にも対応できるよ
うにする
 Multi-Datacenterパターンを適用し、
すべてのレイヤで冗長化を行う

41.
Multi-Datacenterパターンの適用後
ロードバランサ
オリジ 冗長
ナル 構成
EC2 EC2
インスタン インスタン
ス ス
同期
MySQL DB MySQL DB
インスタンス スタンバイ
ゾーン1a ゾーン1b

42.
デザイン推移
SPOF回避
障害対応 最終
障害対策

43.
クラウドアーキテクティング原則
• できるだけサービスを利用
• 机上実験よりも実証実験
• スモールスタートからスケールアウト
• 変化に対し全レイヤで対処
• 故障のための設計(Design For Failure)
• 最初だけでなく周期的なカイゼン

44.
その他 適用可能なパターン
Mutli-Regionパターン
Deep Health Checkパターン
Monitoring Integrationパターン
Stack Deploymentパターン

45.
Wikiで編集できます！

46.
今日のセッション

47.
Next Step
ミッション：
新しいCDPを
追加してみよう
目標: Ninja of “Thousand”

48.
ご清聴ありがとうございました
@KenTamagawa
表千家