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