awsクラウドデザインパターンd36cz9buwru1tt.cloudfront.net/jp/summit2012/pdf/aws-summit-cdp-03.pdf ·...
Post on 30-Aug-2019
5 Views
Preview:
TRANSCRIPT
AWSクラウドデザインパターン -Eコマース編-
自己紹介
名前
北迫 清訓 (きたさこ きよのり)
所属
アマゾンデータサービスジャパン株式会社
ソリューションアーキテクト
ID
Facebook: Kiyonori Kitasako
好きなAWSサービス
Amazon Glacier
好きなCDP
Web Storage Archiveパターン
AWSクラウドデザインパターンとは...
AWSクラウドを使ったシステムアーキテクチャ設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を、分かりやすく分類して、ノウハウとして利用できるように整理したもの。
例えば... (Web Storage Archive)
解決したい課題 サーバで大量に発生するログを一元管理したい
クラウドでの解決 容量無制限ウェブストレージを利用し、キャパシティを気にすることなく格納可能
実装 EC2上でローテートされたログをAPI等のツールを利用しS3に転送
利点 ディスクスペース管理が不要になり、堅牢性の高いストレージでログを管理
注意点 AutoScale時には、停止前に該当ログの退避の仕組みを実装する必要がある
構造
Webでノウハウを共有
WIKI http://aws.clouddesignpattern.org/index.php
FACEBOOK https://www.facebook.com/awscdp
書籍でノウハウを共有
http://www.amazon.co.jp/dp/4822211967/
Amazon Web Services クラウドデザインパターン 設計ガイド
CDPカテゴリ (2012.09.13現在)
基本 Snapshot
Stamp
Scale Up
Ondemand Disk
可用性を向上 Multi-Server
Multi-Datacenter
Floating IP
Deep Health Check
動的コンテンツを処理 Scale Out
Clone Server
NFS Sharing
NFS Replica
State Sharing
URL Rewriting
Rewrite Proxy
Cache Proxy
Scheduled Scale Out
静的コンテンツを処理 Web Storage Direct Hosting Private Distribution Cache Distribution Rename Distribution
データをアップロード Write Proxy Storage Index Direct Object Upload
リレーショナルデータベース DB Replication Read Replica In-memory DB Cache Sharding Write
バッチ処理 Queuing Chain Priority Queue Job Observer Scheduled Autoscaling
運用保守 Bootstrap
Cloud DI
Stack Deployment
Server Swapping
Monitoring Integration
Web Storage Archive
Weighted Transition
Hybrid Backup
ネットワーク On-Demand NAT
Backnet
Functional Firewall
Operational Firewall
Multi Load Balancer
WAF Proxy
Cloud Hub
Eコマースサイト編
シナリオ
今回のシナリオをご紹介する前に...
CDP画像・動画配信編(Movable Type)
雲の写真を載せるブログサイト開始
はじめは個人的に開始
動画や過去画像集も公開し始める
まさかの大人気
まさかの海外展開
デザイン推移
動画 人気
海外 最終
今回のシナリオ
まさかの
本実装シナリオの狙い
Eコマースサイトをとりあげ、
を高めるパターンを中心にAWSを活用 した実装方法を解説
利用環境・ソフトウェア
EC-CUBE (2.12.2)
Amazon Linux (64bit)
Apache (2.2.22)
MySQL (5.5.25)
PHP (5.3.15)
ec.cloudesignpattern.org
初期のデザイン
EC2 インスタンス
本番 環境
Amazon Route 53
ec.clouddesignpattern.org
EIP
問題発生 (その１)
問題： インストール製品にセキュリティホールが発覚！ソフトウェアのバージョンアップ作業が急務に
アクション： ”Floating IP” テスト環境でバージョンアップ！！ 検証後、本番環境のIPアドレスをテスト環境に付け替え
Floating IPパターンの適用
EC2
本番 環境
EIP
Amazon Route 53
ec.clouddesignpattern.org
EIP「54.248.xxx.xxx」
EC2 AMI
EC2
テスト 環境
Floating IPパターンの適用
利点 検証環境を必要な時だけ準備できる
検証環境をそのまま本番環境として利用できるため、2重の作業もなく、本番/検証環境差異が派生しない
切り戻しも簡単
注意点 EIPの切換に通常数秒程度かかる
問題発生 (その2)
問題： サーバに障害発生！ 速やかにサーバを復旧したい
アクション： “Server Swapping” 以前取得したマシンイメージから別サーバを起動 (壊れた)本番環境の最新データを持つディスクを移行して、復旧実施
Server Swappingパターンの適用
仮想 サーバ
サーバに障害発生
仮想ディスク
データ データ
仮想 サーバ
仮想ディスク
マシン イメージ
サーバ起動
EIP
Server Swappingパターンの適用
利点
代替環境の準備が瞬時にできる
Diskの付け替えでデータ移行も容易
注意点
EBSの障害も考慮し、スナップショットなどのバックアップも行うことを推奨
問題発生 (その3)
問題： Webサーバが落ちても、システム全体で 稼働し続けるようにしたい
アクション： “Multi-Server” Webサーバを冗長化し、単一障害点を削減
Multi-Serverパターンの適用
EC2 インスタンス
オリジ ナル
Amazon Route 53 ec.clouddesignpattern.org
ロードバランサ
MySQL DB インスタンス
EC2 インスタンス
冗長 構成
Amazon RDS(MySQL)とは
2009年に登場した設定と運用が容易なクラウド上でのマネージドRDBMSサービス
RDSの特徴
Webコンソールから、設定済みでサイズ変更可能なDBインスタンスを、数分で起動可能
AWSが自動バックアップ、パッチ更新を管理
スケールアップ、レプリケーション、リードレプリカの作成も可能
現時点で、MySQL, Oracle, SQL Serverをサポート
OracleやSQL Serverの場合、時間単位の従量課金と、既存ライセンス持込みをサポート
Amazon RDSの作成
AWS Management
Console
Multi-Serverパターンの適用
DBのデータをダンプする
$ mysqldump -u ユーザー名 -pパスワード データベース名 > backups/backup.sql
作成したRDSのDBインスタンスにデータをインポート $ mysql -u eccube_db_user -peccube --database=eccube_db --host=eccubedbins.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com < backups/backup.sql
EC-CUBEのデータベースへの接続情報を書き換え “config/config.php” define ('DB_SERVER', 'eccubedbins.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com');
S3 ストレージ
Multi-Serverパターンの適用
EC2 インスタンス
冗長 構成
EC2 インスタンス
オリジ ナル
MySQL DB インスタンス
ロードバランサ
Amazon Route 53 ec.clouddesignpattern.org
Amazon RDSのスナップショット取得
AWS Management
Console
Multi-Serverパターンの適用
EC2 インスタンス
冗長 構成
EC2 インスタンス
オリジ ナル
MySQL DB インスタンス
ロードバランサ
Amazon Route 53 ec.clouddesignpattern.org
複製
ロードバランサの起動
AWS Management
Console
ロードバランサの起動
EC-CUBEでは、SSLをサポート。 ELBでも対処可能だが、今回はELBではSSLの処理はしないことに。
AWS Management
Console
ELB配下にWebサーバを追加
負荷分散させるWebサーバを確認
ELB配下にWebサーバを追加
AWS Management
Console
Multi-Serverパターンの適用
EC2 インスタンス
冗長 構成
EC2 インスタンス
オリジ ナル
MySQL DB インスタンス
ロードバランサ
Amazon Route 53 ec.clouddesignpattern.org
複製
Multi-Serverパターンの適用
利点
AMIによるシステムイメージの流用と、Elastic Load Balancingにより、簡単にWebサーバの冗長化が可能
Amazon RDSの採用によりDBの運用負担を大幅に削減
注意点
Webサーバ上の画像ファイル等の同期処理が必要となる場合がある
問題発生 (その4)
問題： Webサーバを冗長化したことで、 DBサーバの性能が低下し不安定に
アクション： “Scale Up” DBサーバのインスタンスサイズを変更
Scale Upパターンの適用
EC2 インスタンス
冗長 構成
EC2 インスタンス
オリジ ナル
ロードバランサ
Amazon Route 53 ec.clouddesignpattern.org
MySQL DB インスタンス
MySQL DB インスタンス
Amazon RDSでScale Up
AWS Management
Console
Scale Upパターンの適用
利点
管理画面での設定だけで、インスタンスサイズ、ＤＢサイズの変更が可能
アクセス状況を見ながら適時、適切なDBサイジングを選択することが可能
注意点
DBの再起動が発生するため、実施時間の調整が必要
問題発生 (その5)
問題： DBのSPOF(単一障害点)を解消する 必要あり！
アクション： “DB Replication” DBをマルチ構成に変更し、耐障害性を強化！
マルチAZに変更
AWS Management
Console
DB Replicationパターンの適用
EC2 インスタンス
冗長 構成
EC2 インスタンス
オリジ ナル
MySQL DB インスタンス
ロードバランサ
Amazon Route 53 ec.clouddesignpattern.org
MySQL DB スタンバイ
DB Replicationパターンの適用
利点
管理画面での設定だけで、マルチAZ(フォールトレラント)構成をとることが可能
スタンバイ側でDBのバックアップが行われるようになり、サービスへの影響がより軽減
注意点
DBのインスタンスコストが2倍になる
RDSのフェイルオーバーに多少時間がかかる
問題発生 (その6)
問題： 災害対策の一環としてデータセンター レベルでのBCPの検討が必要に！
アクション： “Multi-Datacenter” 物理的に別のデータセンターを利用し、 すべてのレイヤで冗長化
Multi-Datacenterパターンの適用
EC2 インスタンス
冗長 構成
EC2 インスタンス
オリジ ナル
MySQL DB インスタンス
ロードバランサ
Amazon Route 53 ec.clouddesignpattern.org
MySQL DB スタンバイ
ゾーン1a ゾーン1b
Multi-Datacenterパターンの適用
利点
他のAZを利用することへの追加コストが発生しない
DCレベルでの耐障害性構成を簡単に実現可能
注意点
AZ(DC)間を跨いだWebサーバとDBサーバ間の通信に少額の課金が発生
様々な対策を経て
BCP対策までもが簡単かつ安価に実現！
デザインパターンの推移
開始
保守対応
復旧対応
障害対策
可用性対応
SPOF回避
BCP対応
その他 適用可能なパターン
Mutli-Regionパターン グローバル展開を見据えたBCP対策
Deep Health Checkパターン 全レイヤー串刺しチェックによる可用性の向上
Monitoring Integrationパターン 運用プロセス向上のための監視ソフト環境導入
WAF Proxyパターン セキュリティ向上のためのWAF(Web Application Firewall)の導入
まとめ
デザインパターンを活用し
システム規模に合わせた可用性を持つシステムを構築が可能に
低コストで耐障害性の高いシステムを簡単に構築することが可能に
システムが拡大しても、運用者の負担を削減する仕組みづくりが可能に
まとめ (改善・革新)
今までできていたことを、 より早く、簡単に、安く実現できる
今までできなかったことが 実現できる
改善
革新
CDPでAWSをもっと楽しく
ご清聴ありがとうございました。
FACEBhttps://www.facebook.com/awscdp
top related