Upload
hiroshi-koyama
View
2.015
Download
0
Embed Size (px)
Citation preview
Copyright © 2013 AGREX INC.
2013/05/18
札幌事業所
マネジャー 古山浩司
JAWS-UG 函館 第1回勉強会
S3 と CloudFront を活用してWebサイトの性能向上
Copyright © 2013 AGREX INC. 1
こやま ひろし
古山 浩司 (株)アグレックス 札幌事業所 システム部
JAWS-UG 札幌支部 支部長
facebook.com/H.Koyaman
*1972年 静岡県浜松市生まれ
*1997年 某・重工メーカー入社
*2001年 (株)アグレックス 入社
企業向けオープン系システム開発 (主にJava)
2011年~ ECサイト構築&運用ビジネス担当
好きなAWSサービス : VPC、RDS
自己紹介
Copyright © 2013 AGREX INC. 2
ECサイト構築・運用スキーム
EC決済&請求・回収プラットフォーム ・銀振 / クレカ / コンビニ / ペイジー ・振込専用口座 ・入金消込み ・請求書・払込票発行 (アウトソーシングサービス)
低コスト・柔軟・高可用性・セキュアなインフラ
(某メガバンクとの提携サービス)
オールインワンECパッケージ
ただ「売る」だけの仕組みではなく、 ショップ側の運用コスト・手間を軽減!
繁忙・閑散期ギャップや急激な事業成長にも追従 → 販売チャンスのロスなし!
Copyright © 2013 AGREX INC. 3
・ECサイトの負荷傾向
・大量アクセス対策に使えるAWSサービス
・ECサイトでのつかいどころ
・まとめ
本日のお話
Copyright © 2013 AGREX INC. 4
負荷傾向 ~1 季節性
Nov. Dec. Jan. Feb.
Capacity
洋菓子系ECサイトの傾向
アク
セス
比較的対応しやすい
Copyright © 2013 AGREX INC. 5
負荷傾向 ~2 スパイク
Sat.
Capacity
ゴールデンタイムのTV放映
Sun. Mon. Fri.
超潜入! リアル・・・
シルシル・・・ サンデー
アク
セス
とくに危険 ・画面に商品名が出た直後 ・合間のCMに入った直後
Copyright © 2013 AGREX INC. 6
Server
大量アクセスにどう対応する?
Server Server Server Server
Server
Scale Up Scale Out
その前に・・・そもそも、 そのリクエスト、サーバーで受ける必要ありますか?
・まずは、リクエストを減らす策を考える。
・それでもダメなら、Scale Up / Scale Out。
Copyright © 2013 AGREX INC. 7
リクエストを減らす手段 ~1
Server
Server
HTML
PHP
静的ページのためにサーバーはもったいない
HTML
PHP
S3
静的ページに特化したサービスに任せる
Copyright © 2013 AGREX INC. 8
S3の特徴
◆本来は、ストレージサービス • 容量無制限、堅牢性 99.999999999% 。
• 世界で2兆個のオブジェクト、110万req/sを処理。
◆静的Webサイトのホスティングも出来る • 全てのオブジェクトにユニークなURLが付与される。
(https://xxxx.amazonaws.com/mybucket/index.html)
• 現サイトのディレクトリ構造のまま、バケットに放り込むだけ。あとはバケットに公開設定をするだけでWebサイトに。
• DNSのCNAMEにS3のURLを設定すれば、独自ドメインでのホスティングもOK。
• Route53と併用で、ルートドメイン(例:http://mysite.com)
でも可能。
• アクセスログも取得可能。(指定したバケットに溜まる)
Copyright © 2013 AGREX INC. 9
リクエストを減らす手段 ~ 2
Server
Server
サーバーの手前にキャッシュを置く
同一コンテンツを何度も作るのは無駄
CloudFront
中華まん 中華まん
中華まん
http://shop.com/?item=中華まん
Copyright © 2013 AGREX INC. 10
CloudFrontの特徴
◆高速で信頼性の高いCDNサービス • 世界中のエッジロケーションからコンテンツを配信 。
(同じURLでも、各アクセス元からのレイテンシが最短のところにつながる)
• 国内には東京と大阪の2箇所。
◆従量課金 • リクエスト料金 - $0.0095 /1万req
• データ転送量 - $0.201 /GB
◆何をオリジンとするかは自在 • EC2やS3だけでなく、AWS以外のサーバーでもOK。
• キャッシュ期間はデフォルト1日、短くもできる。(削除も可)
• DNSのCNAMEにCloudFrontのURLを設定すれば、独自ドメインでの配信もできる。(httpのみ)
Copyright © 2013 AGREX INC. 11
S3、CloudFront ともに、 なにより素晴らしいのは・・・
• どれだけアクセスされてもびくともしない、天井知らずのスケーラビリティ
• それでいて、料金は使った分だけの従量課金。
「リアル***」も「シルシル***」も、
恐れる必要全くなし!
Copyright © 2013 AGREX INC. 12
・・・と、ここまでは教科書的な一般論。
Copyright © 2013 AGREX INC. 13
ECサイトは動的ページ、S3には置けない。
現実(例えばECサイト) はそう簡単でない
◆ S3
◆ CloudFront
キャッシュされたらまずい部分が至る所に。
URLは同じでも、誰が? いつ? によって見せるべき内容が違う。
アプリの構造自体に手を入れないと難しい。 でも・・・部分的になら、今すぐ活用できる!
Copyright © 2013 AGREX INC. 14
簡単にできる、S3の適用事例
サイトトップ 会社概要
店舗情報
リクルート
製品情報
オンラインショップ マイページ
ショッピングカート
商品一覧
商品詳細
Server
(EC2)
S3
http://www.mysite.com
http://shop.mysite.com
静的HTMLで作る or CMSからHTMLを生成
ランディングページがS3上にあれば、一気にアクセスが来ても 「何も見れない」という事態は、まず起きない。
Copyright © 2013 AGREX INC. 15
「Direct Hostingパターン」に相当
Copyright © 2013 AGREX INC. 16
簡単にできる、CloudFrontの活用事例
Server
(EC2)
http://shop.mysite.com/xxx.php
<img src=“http://cf.mysite.com/xxx.jpg”/>
リクエスト全体の大部分を占める、画像等の静的パーツをCloudFrontにキャッシュする。 → EC2が受けるリクエスト数は1/10以下に!
cf.mysite.com
shop.mysite.com
origin
Copyright © 2013 AGREX INC. 17
簡単にできる、CloudFrontの活用事例
アプリが生成したページそのままの記述
Apache mod_sed
OutputSed “s/ ¥/images¥/ / http:¥/¥/cf.mysite.com¥/images¥/ /g"
URL書き換え方法の一例 (Apache mod_sed)
<img src=“/images/xxx.jpg” />
<img src=“http://cf.mysite.com/images/xxx.jpg” />
クライアントが受け取るページの記述
置換 (sedコマンドと同等)
Copyright © 2013 AGREX INC. 18
「URL Rewritingパターン」に相当
Copyright © 2013 AGREX INC. 19
URL Rewritingパターンの効果 実測
0 200 400 600 800
m1.medium
m1.small
t1.micro
◆ 1分間あたり最大PV数
0 5000 10000
m1.medium
m1.small
t1.micro
■EC2のみ
■静的パーツはCloudFront
◆ 最大負荷時のページあたり読込み時間 (msec)
■EC2のみ
■静的パーツはCloudFront
EC2上の ECDirect デモサイト、JMeter (×4台)での負荷試験
Copyright © 2013 AGREX INC. 20
まとめ
いきなりEC2のScale Up/Outに頼るのは早計。「EC2へのアクセスをいかに減らすか」をまず考える。
S3とCloudFrontを使えば、大量アクセスを
安定して、安価に捌くことができる。
サイト丸ごとでなくとも、部分的にでもS3とCloudFrontを利用する価値あり。
AWSを利用すれば、サービス構築・問題解決
のスピード感は飛躍的に向上する。
Copyright © 2013 AGREX INC. 21
最後にこちらも…
Copyright © 2013 AGREX INC.
【公開資料はこちら】