Post on 15-Jan-2015
description
Amazon Web Servicesクラウドアドバンテージセミナー
キャンペーンサイトでのクラウド活用事例＋ 災害時対応での事例
アイレット株式会社
後藤 和貴 kaz@cloudpack.jp
2011.4.6
アジェンダ
自己紹介、会社紹介、サービス紹介
なぜAWSがキャンペーン型ウェブサイトに向いているのか？
キャンペーンサイト事例紹介
災害時対応での事例紹介
まとめ
2
自己紹介: 後藤 和貴
プロフィールアイレット株式会社cloudpack 事業部 エバンジェリストJAWS-UG Tokyoコアメンバー
好きなAWSサービス: EBS
Blog: http://5net.com/ Email: kaz@cloudpack.jp Twitter: @kaz_goto
職歴日本オラクル （ソフトウェアエンジニア） 1995~
Oracle Corporation（ソフトウェアエンジニア） 1998~
ビジネス・アーキテクツ（ディレクター/取締役） 2001~
WIRED VISION（CTO/サイト運営） 2007~
3
アイレット株式会社
Web開発を得意とするシステム開発会社。開発のほか、システム保守・運用、ホスティング事業なども展開。
2003年8月 創業
従業員数 23名
事業内容:
ITコンサルティング、システム開発、システム保守・運用、Webデザイン・制作、サーバハウジング・ホスティング、講師事業
4
5
Amazon EC2 をはじめとするクラウド導入設計、運用・保守サービス
クラウド環境をバックエンドとした月額費用固定型フルマネージドホスティング
AWS導入・構築支援、コンサルティング、システム構築サービス
2010年4月サービス開始
2011年1月 認定
2011年4月時点 30社・100インスタンス超、さらに増加中
6
フルマネージドホスティング
ファイアーウォール
ロードバランサー
バースト保障
バックアップ・リストア
サーバー/リソース監視
電話/メールによる24時間サポート
初期費用なし、月額5万円(SMALLプラン)からのスタート
7
バースト保障
キャンペーンなど急激なアクセス増加へ合わせてインフラ準備するのは不可能
いつあるかわからないピークのために予め準備できない
8
追加料金無しでスケールアウト（7インスタンス/日まで）
定額課金・請求書払い
従量課金では予算計画が立てられない
クレジットカードでUSドル決済では利用料の予測が難しい
9
Amazon Web Servicesでは...
月額固定＋日本円請求書発行
フルマネージド
サービス/リソース監視
ディスク使用量、メモリ使用量、プロセス数、Webサーバー・DBサーバー死活...
バックアップ/リストア
EBSスナップショットを利用した二世代（過去二日分）バックアップ
アクセス制御(ファイアーウォール)
適切なセキュリティグループを設定、OS・ミドルウェアレベルでさらに細かな設定も対応可能
10
11
スピンオフ・サービス
引っ越し職人
監視職人
CDN職人
開発職人
MT(MovableType)職人
SSL職人
負荷テスト職人
保守職人
請求代行サービス
最近の事例
用途
商品紹介ウェブサイト
キャンペーンウェブサイト
ウェブサービス提供サイト
EC
CMS
大規模配信
ソーシャルアプリ・ソーシャルゲーム
データストレージ
12
最近の事例
動機
拡張縮退運転
さまざまな機能
コスト（価格モデル）
ライセンスモデル
既存DC/ハードウェアリプレイス
災害時対策
13
なぜAWSがキャンペーン型ウェブサイトに
向いているのか？
14
15
なぜAWSがキャンペーン型ウェブサイトに向いているのか？
オンデマンド
初期費用無しで、すぐに稼働（調達）
テスト 開発 設計 企画 (要件定義)
▲発注 ▲リリース
テスト 開発 設計 企画 （要件定義）
▲リリース
▲調達
▲調達
今まで
AWS利用
【とあるプロジェクトの例】
16
なぜAWSがキャンペーン型ウェブサイトに向いているのか？
スケールイン・アウト、スケールアップ・ダウン
スモールスタートでインフラ設計を緻密にしなくても良い
計画できないアクセス増にも迅速に対応可能
出典: 米国RightScale社 (http://rightscale.com/)
従来型(オンプレミス)調達モデル クラウド型調達モデル
17
なぜAWSがキャンペーン型ウェブサイトに向いているのか？
負荷分散対応
ロードバランサー + 冗長化サーバー = ELB + EC2
ストレージサービス = S3
CDN = CloudFront
グローバル対応
データセンター世界で 5 Region
CDN 17 Edge Location
キャンペーン型サイト事例紹介
18
社団法人 日本プロゴルフ協会 公式サイト
課題
毎年トーナメントの時期にアクセスピークが来るが、そのピークに耐えられない
サーバーの増強はかなり前から準備が必要＋コストが上昇する
20
http://www.pga.or.jp/
社団法人 日本プロゴルフ協会 公式サイト
21
トーナメント前後数日間 5台追加（EC2 SMALL マスター1台＋スレーブ5
台）
スケールアウトしやすい構成: コンテンツ配信冗長化、フォーム系はすべてにマスターに転送（ReverseProxy）、CMSもマスター、配信はrsyncで実行
http://www.pga.or.jp/
(master)
slave
slave
slave
slave
slave
ELB
バースト保証適用（固定費用内）
宅麺.com
23
課題
TVでの紹介によるアクセス急増に耐えきれずサーバーダウン
ウェブサイトがビジネスの唯一の入り口
一旦できあがったサイトなので容易に移行はできない
http://www.takumen.com/
宅麺.com 第1段階
EC(ウェブアプリ)部分は既存インフラのまま
画像、CSS、JS、SWFなどスタティックファイルのみ CloudFront 利用（カスタムオリジン）
24
http://www.takumen.com/
Text既存サーバー(EC)
www.takumen.com cdn.takumen.com
カスタムオリジン設定
宅麺.com 第2段階
EC(ウェブアプリ)部分もEC2へ移行！
バックアップ・リストア設定、運用・監視の強化
25
http://www.takumen.com/
宅麺.com
第1段階
CDNのみ導入
第2段階
本体EC2へ移行
バックアップ・リストア設定、運用・監視の強化
第3段階 (現在進行中)
スケーラブルな構成へ
26
http://www.takumen.com/
段階的、かつスムースな移行が可能
BOSSブランドサイト (Roland)
27
http://www.boss.info/global/
BOSSブランドサイト (Roland)
28
課題
オリジナルのCMSが社内で運用されていて、安定稼働・信頼性に乏しい状態
日本以外の世界向けのコンテンツ配信
http://www.boss.info/global/
BOSSブランドサイト (Roland)
「BOSS」ブランドのグローバルサイトで EC2 導入
自社オリジナルCMSのため Windows Server を選択し、監視サービスを追加
世界展開向けにUSｰWESTリージョン利用29
http://www.boss.info/global/
まとめ
一時的なピークへスケールアウト・スケールアップで対応、コストは完全従量制（cloudpackでは一部固定費用）
さまざまなサービスを利用することで迅速かつ段階的に移行するオプションがある
日本以外への配信でも特別な段取りは不要
30
災害時対応での事例
31
32
地震発生後 cloudpackチームで行った対応
情報発信用CMS導入済みAMI作成
SAVE JAPAN: ミラーサイト作成 (CDN)
JustGiving: AWS移行、スケールアップ、負荷分散構成 (DB分離、LB配置)、メールサーバー移行
buji.me: AWS移行、冗長化構成準備(負荷分散)
ゆれくるコール: ストレージサービス組み込み(負荷分散)
medica.net: AWS移行
sinsai.info: ミドルウェア負荷調査、スケールアウト構成準備(負荷分散)
茨城大学: DNSホスト
33
SAVE JAPAN! PROJECT
34
Twitter上の震災情報を正確な情報のやり取りするためのサイト
ハッシュタグを使って都道府県別に整理
早い段階で出来た震災情報サイトだったためアクセスが集中
http://savejapan.simone-inc.com/
SAVE JAPAN! PROJECT
35
http://savejapan.simone-inc.com/
3/12 0:29
SAVE JAPAN! PROJECT
36
http://savejapan.simone-inc.com/
3/12 1:15
SAVE JAPAN! PROJECT
37
http://savejapan.simone-inc.com/
3/12 1:25
SAVE JAPAN! PROJECT
38
http://savejapan.simone-inc.com/
3/12 3:00
30分ほどでミラーサイト構築済み
Text
SAVE JAPAN! PROJECT
39
ポイント
Twitter で拡散されたおかげで対応が必要な事を知り、すぐさま応援
作業時間わずか30分でCDNへミラーサイトを構築（S3+CloudFront利用）
http://savejapan.simone-inc.com/
オリジンサーバー
JustGiving Japan
47
12～13日でAWS移行完了済み
DB RDS利用 (db.m2.4xlarge 1台)
イメージサーバー (m1.large 1台)
ウェブ/アプリサーバー (c1.xlarge 1台)
アプリ負荷分散対応
アプリケーション構成が不明なため対応後回し
http://justgiving.jp/
この後AWS負荷対策チームとして参戦
1. PHP APC化
2. Apache MaxClients 増加 256 → 600
3. メモリ使用低減のためLoadModule 調整（削減）
4. 画像転送をリバースプロキシ→リダイレクトへ
5. Apache Timeout 120 → 20
6. S3 化トライ、設定困難で別の方法を優先することに
7. c1.xlarge → m2.2xlarge
8. サーバーログインしてトラブルシュート開始
9. Apache disk cache トライ
10. DB調査開始、Slow Query チェック設定
11. DB、QueryCache設定（ぞくぞくと Slow Query みつかる）
12. disk cache のためアプリで Last-Modfied + Expire 追加
13. memcached 導入
14. アプリの一部でキャッシュ開始
15. アクセスの多いリクエスト、パフォーマンスの悪いリクエストにしぼり、いくつかアプリ内キャッシュ化（10秒以上かかるリクエスト多数有り）
16. （深夜になったこともあり）一旦落ち着いたのでアプリを継続修正依頼して一旦完了
48
13日正午付近
14日0時半
その後、18日までアプリサーバー冗長化調整/DB/メール配信/アプリ負荷改善がつづく...
JustGiving Japan
49
ウェブサーバー スケールアップ
c1.xlarge → m2.2xlarge
ミドルウェアチューニング
Apache設定見直し（ReverseProxy→Redirect、メモリ使用量削減、起動プロセス数調整...）
メール配信改善
アプリ改修
HTMLキャッシュ
DBアクセス一部キャッシュ化（memcached）
http://justgiving.jp/
ここまでの対策で一旦安定
JustGiving Japan
ポイント
スナップショット利用で本番稼働中にテスト環境作成
調査継続しながら、合間にマシンスケールアップ
スケールアップで延命している間にさらに調査
アプリ改修と同感覚でインフラの改善ができる
50
http://justgiving.jp/
51
AWS移行
ミドルウェア負荷調査スケールアウト準備（既存アプリ構成を変更せず対応する方法の調査）
sinsai.infohttp://sinsai.info/
AWS移行
冗長化構成buji.me
http://ww.buji.me/
S3ホスティングゆれくるコールfor iPhone
AWS移行
サーバー構築DNS切り替え(Route53)
medica.nethttp://medica.net/
DNS切り替え(Route53)茨城大学http://www.ibaraki.ac.jp/
災害時対応でのメリットすぐに利用開始
まずは IaaS である
OS以上は同じで移行がスムース
強力な PaaS
S3を始めとするとする負荷分散しやすいサービス群
スケール可能なミドルウェア (MySQL/Apache)
仮想化・スナップショット
検証環境構築・本番適用・切り戻しが自由自在に可能
パブリッククラウド
強大なパワーを一瞬で手に入れることができる
52
災害時対策とクラウド利用の相性
緊急時の負荷対策
安定的でかつフレキシブルなインフラでなければ、現実的なコストで対応できない＝パブリッククラウド
クラウドと DR
データバックアップを複数のロケーションへ
待機系サーバーOSイメージを別リージョンへコピー（cloudworksなど利用）
53
今後基幹系システムも含め、パブリッククラウドへの移行が進んでいくと予想される
参考情報
54
電通国際情報サービス 加藤 章さん著[TechTargetジャパン] http://techtarget.itmedia.co.jp/tt/news/1103/30/news03.html
IIJ 小川 晋平さん著[ITmedia] http://www.itmedia.co.jp/enterprise/special/0608/disaster/index.html
まとめ
55
キャンペーン型サイトでは、拡張性・経済性の面でAWSのようなパブリッククラウドが必須
災害時の対応でも、実は同じだった
移行が容易だったことも重要な要素
先が読みにくく非常時への対策がしにくい場合パブリッククラウド利用が必勝の法則
Thank You!
http://www.cloudpack.jp/suuport@cloudpack.jp
@cloudpack_jp