jaws-ug函館 s3とcloudfrontを利用してwebサイトの性能向上

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

自己紹介


ECサイト構築・運用スキーム

EC決済＆請求・回収プラットフォーム・銀振 / クレカ / コンビニ / ペイジー・振込専用口座・入金消込み・請求書・払込票発行 (アウトソーシングサービス)

低コスト・柔軟・高可用性・セキュアなインフラ

(某メガバンクとの提携サービス)

オールインワンECパッケージ

ただ「売る」だけの仕組みではなく、ショップ側の運用コスト・手間を軽減！

繁忙・閑散期ギャップや急激な事業成長にも追従 → 販売チャンスのロスなし！


・ECサイトの負荷傾向

・大量アクセス対策に使えるAWSサービス

・ECサイトでのつかいどころ

・まとめ

本日のお話


負荷傾向～1 季節性

Nov. Dec. Jan. Feb.

Capacity

洋菓子系ECサイトの傾向

アク

セス

比較的対応しやすい


負荷傾向～2 スパイク

Sat.

Capacity

ゴールデンタイムのTV放映

Sun. Mon. Fri.

超潜入！リアル･･･

シルシル･･･サンデー

アク

セス

とくに危険・画面に商品名が出た直後・合間のＣＭに入った直後


Server

大量アクセスにどう対応する？

Server Server Server Server

Server

Scale Up Scale Out

その前に・・・そもそも、そのリクエスト、サーバーで受ける必要ありますか？

・まずは、リクエストを減らす策を考える。

・それでもダメなら、Scale Up / Scale Out。


リクエストを減らす手段～1

Server

Server

HTML

PHP

静的ページのためにサーバーはもったいない

HTML

PHP

S3

静的ページに特化したサービスに任せる


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)

でも可能。

• アクセスログも取得可能。(指定したバケットに溜まる)


リクエストを減らす手段～ 2

Server

Server

サーバーの手前にキャッシュを置く

同一コンテンツを何度も作るのは無駄

CloudFront

中華まん中華まん

中華まん

http://shop.com/?item=中華まん


CloudFrontの特徴

◆高速で信頼性の高いCDNサービス • 世界中のエッジロケーションからコンテンツを配信。

(同じURLでも、各アクセス元からのレイテンシが最短のところにつながる)

• 国内には東京と大阪の2箇所。

◆従量課金 • リクエスト料金－ $0.0095 /1万req

• データ転送量－ $0.201 /GB

◆何をオリジンとするかは自在 • EC2やS3だけでなく、AWS以外のサーバーでもOK。

• キャッシュ期間はデフォルト1日、短くもできる。(削除も可)

• DNSのCNAMEにCloudFrontのURLを設定すれば、独自ドメインでの配信もできる。(httpのみ)


S3、CloudFront ともに、なにより素晴らしいのは・・・

• どれだけアクセスされてもびくともしない、天井知らずのスケーラビリティ

• それでいて、料金は使った分だけの従量課金。

「リアル＊＊＊」も「シルシル＊＊＊」も、

恐れる必要全くなし！


・・・と、ここまでは教科書的な一般論。


ECサイトは動的ページ、S3には置けない。

現実(例えばECサイト) はそう簡単でない

◆ S3

◆ CloudFront

キャッシュされたらまずい部分が至る所に。

URLは同じでも、誰が？いつ？によって見せるべき内容が違う。

アプリの構造自体に手を入れないと難しい。でも･･･部分的になら、今すぐ活用できる！


簡単にできる、S3の適用事例

サイトトップ会社概要

店舗情報

リクルート

製品情報

オンラインショップマイページ

ショッピングカート

商品一覧

商品詳細

Server

(EC2)

S3

http://www.mysite.com

http://shop.mysite.com

静的HTMLで作る or CMSからHTMLを生成

ランディングページがS3上にあれば、一気にアクセスが来ても「何も見れない」という事態は、まず起きない。


「Direct Hostingパターン」に相当


簡単にできる、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


簡単にできる、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コマンドと同等)


「URL Rewritingパターン」に相当


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台)での負荷試験


まとめ

いきなりEC2のScale Up/Outに頼るのは早計。「EC2へのアクセスをいかに減らすか」をまず考える。

S3とCloudFrontを使えば、大量アクセスを

安定して、安価に捌くことができる。

サイト丸ごとでなくとも、部分的にでもS3とCloudFrontを利用する価値あり。

AWSを利用すれば、サービス構築・問題解決

のスピード感は飛躍的に向上する。


最後にこちらも…

jaws-ug函館 s3とcloudfrontを利用してwebサイトの性能向上

Documents