JAWS-UG Fukuoka勉強会 第3回 災害時の対応とAWSの力
>100 Views
June 23, 11
スライド概要
2011年6月21日に行われたJAWS-UG大阪にて、LTで発表した資料。RDSの紹介とRDS for Oracleへの移行でハマる箇所の紹介。
関連スライド
各ページのテキスト
JAWS-UG Fukuoka勉強会 第3回 災害時の対応とAWSの力 後藤 和貴 [email protected] 2011.6.21
自己紹介: 後藤 和貴 プロフィール アイレット株式会社 エバンジェリスト 出没するJAWS-UG: Tokyo, Osaka, Fukuoka new! @kaz_goto 好きなAWSサービス: プレミアムサポート（Goldなら1時間以内！） SSID: kaz_goto 最近の活動 4月 AWSアドバンストセミナー、 JAWS-UG Osaka 第2回勉強会 5月 AWS Partner Advisory Summit in Seattle 2
アイレット株式会社 Web開発を得意とするシステム開発会社。開発のほ か、システム保守・運用、ホスティング事業なども展 開。 2003年8月 創業 従業員数 23名 事業内容: ITコンサルティング、システム開発、システム保守・運 用、Webデザイン・制作、サーバハウジング・ホスティ ング、講師事業 3
4
Amazon EC2 をはじめとするクラウド導入設計、運用・保 守サービス クラウド環境をバックエンドとした 月額費用固定型フルマネージドホスティング AWS導入・構築支援、コンサルティング、システム構築 サービス 2010年4月サービス開始 認定 2011年1月 2011年6月時点 40社・100インスタンス超、さらに増加中 5
フルマネージドホスティング ファイアーウォール ロードバランサー バースト保障 バックアップ・リストア サーバー/リソース監視 電話/メールによる24時間サポート 初期費用なし、月額5万円(SMALLプラン)からのスタート 6
バースト保障 キャンペーンなど急激なアクセス増加へ合わせてインフ ラ準備するのは不可能 いつあるかわからないピークのために予め準備できない 追加料金無しでスケールアウト （7インスタンス/日まで） 7
定額課金・請求書払い Amazon Web Servicesでは... 従量課金では予算計画が立てられない クレジットカードでUSドル決済では利用料の予測が難しい 月額固定＋日本円請求書発行 8
フルマネージド サービス/リソース監視 ディスク使用量、メモリ使用量、プロセス数、 Webサーバー・DBサーバー死活... バックアップ/リストア EBSスナップショットを利用した二世代（過去 二日分）バックアップ アクセス制御(ファイアーウォール) 適切なセキュリティグループを設定、OS・ミド ルウェアレベルでさらに細かな設定も対応可能 9
続きはウェブで 10
キャンペーン型サイト 事例紹介 11
社団法人 日本プロゴルフ協会 公式サイト http://www.pga.or.jp/ 12
社団法人 日本プロゴルフ協会 公式サイト http://www.pga.or.jp/ 課題 毎年トーナメントの時期にアクセスピー クが来るが、そのピークに耐えられない サーバーの増強はかなり前から準備が必 要＋コストが上昇する 13
社団法人 日本プロゴルフ協会 公式サイト http://www.pga.or.jp/ ELB (master) slave slave slave slave slave トーナメント前後数日間 5台追加（EC2 SMALL マスター1台＋スレーブ5 台） スケールアウトしやすい構成: コンテンツ配信冗長化、フォーム系はすべて にマスターに転送（ReverseProxy）、CMSもマスター、配信はrsyncで実行 バースト保証適用（固定費用内） 14
宅麺.com http://www.takumen.com/ 15
宅麺.com http://www.takumen.com/ 課題 TVでの紹介によるアクセス急増に耐えき れずサーバーダウン ウェブサイトがビジネスの唯一の入り口 一旦できあがったサイトなので容易に移 行はできない 16
宅麺.com 第1段階 http://www.takumen.com/ www.takumen.com 既存サーバー cdn.takumen.com Text (EC) カスタムオリジン設定 EC(ウェブアプリ)部分は既存インフラのまま 画像、CSS、JS、SWFなどスタティックファイルのみ CloudFront 利用 （カスタムオリジン） 17
宅麺.com 第2段階 http://www.takumen.com/ 既存サーバー (EC) 移行 EC(ウェブアプリ)部分もEC2へ移行！ バックアップ・リストア設定、運用・監視の強化 18
宅麺.com http://www.takumen.com/ 第1段階 CDNのみ導入 第2段階 本体EC2へ移行 バックアップ・リストア設定、運用・監視の強化 第3段階 スケーラブルな構成へ → 6/24に勝負！ 段階的、かつスムースな移行が可能 19
災害時対応での事例 20
21
地震発生後 cloudpackチームで行った対応 情報発信用CMS導入済みAMI作成 SAVE JAPAN: ミラーサイト作成 (CDN) JustGiving: AWS移行、スケールアップ、負荷分散構成 (DB分離、LB配 置)、メールサーバー移行 buji.me: AWS移行、冗長化構成準備(負荷分散) ゆれくるコール: ストレージサービス組み込み(負荷分散) medica.net: AWS移行 sinsai.info: ミドルウェア負荷調査、スケールアウト構成準備(負荷分 散) 茨城大学: DNSホスト 22
Just Giving http://justgiving.jp/ 23
JustGiving Japan http://justgiving.jp/ 3/12 13:41 24
JustGiving Japan http://justgiving.jp/ 3/12 14:10 25
JustGiving Japan http://justgiving.jp/ 3/12 19:13 26
JustGiving Japan http://justgiving.jp/ 3/12 19:16 27
JustGiving Japan http://justgiving.jp/ 3月12日13日でAWS移行完了済み DB RDS利用 (db.m2.4xlarge 1台) イメージサーバー (m1.large 1台) ウェブ/アプリサーバー (c1.xlarge 1台) アプリ負荷分散対応 アプリケーション構成が不明なため対応後回し この後AWS負荷対策チームとして参戦 28
13日正午 付近 1. PHP APC化 フロントキャッシュ導入班 2. Apache MaxClients 増加 256 → 600 3. メモリ使用低減のためLoadModule 調整（削減） 4. 画像転送をリバースプロキシ→リダイレクトへ Apache最適化調査班 DB負荷調査班 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/メール配信/アプリ負荷改善がつづく... 29
16:23 (スケールアップ後、その後ホリエモン砲発射直後) top - 16:23:31 up 1:13, 8 users, load average: 273.91, 166.21, 115.99 Tasks: 704 total, 400 running, 304 sleeping, Cpu(s): 43.7%us, 13.8%sy, Mem: 35133768k total, Swap: PID USER 0.0%ni, 39.1%id, 0 stopped, 0.4%wa, 0.0%hi, 9500728k used, 25633040k free, 0k total, 0k used, 0 zombie 0k free, 2.9%si, 101084k buffers 867780k cached PR NI VIRT RES SHR S %CPU %MEM 4004 apache 20 0 376m 29m 16m R 1.3 0.1 0:09.98 httpd 4018 apache 20 0 391m 40m 13m R 1.3 0.1 0:07.36 httpd 4030 apache 20 0 373m 25m 15m R 1.3 0.1 0:06.82 httpd 4036 apache 20 0 379m 32m 16m R 1.3 0.1 0:08.54 httpd 4043 apache 20 0 372m 24m 15m R 1.3 0.1 0:07.54 httpd 4044 apache 20 0 394m 44m 14m R 1.3 0.1 0:04.96 httpd 4048 apache 20 0 385m 36m 15m R 1.3 0.1 0:07.04 httpd 4062 apache 20 0 391m 41m 13m R 1.3 0.1 0:04.45 httpd 4072 apache 20 0 372m 24m 15m R 1.3 0.1 0:07.69 httpd 4090 apache 20 0 380m 31m 14m R 1.3 0.1 0:05.05 httpd 4108 apache 20 0 374m 25m 15m R 1.3 0.1 0:05.71 httpd 4111 apache 20 0 382m 31m 19m R 1.3 0.1 0:06.02 httpd 4114 apache 20 0 372m 24m 15m R 1.3 0.1 0:04.89 httpd 30 TIME+ COMMAND 0.2%st
JustGiving Japan http://justgiving.jp/ ウェブサーバー スケールアップ c1.xlarge(7GB, 20ECU) → m2.2xlarge(34.2GB, 13ECU) ミドルウェアチューニング Apache設定見直し（ReverseProxy→Redirect、メモリ使用量削減、起動プ ロセス数調整...） メール配信改善 アプリ改修 HTMLキャッシュ DBアクセス一部キャッシュ化（memcached） ここまでの対策で一旦安定・作業終了 31
JustGiving Japan http://justgiving.jp/ ポイント スナップショット利用で本番稼働中にテスト環境 作成 調査継続しながら、合間にマシンスケールアップ スケールアップで延命している間にさらに調査 アプリ改修と同感覚でインフラの改善ができる 32
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/ 33
災害時対応で改めて感じたAWSの力 すぐに利用開始 まずは IaaS である OS以上は同じで移行がスムース 強力な PaaS S3を始めとするとする負荷分散しやすいサービス群 スケール可能なミドルウェア (MySQL/Apache) 仮想化・スナップショット 検証環境構築・本番適用・切り戻しが自由自在に可能 最大規模のパブリッククラウド 強大なパワーを一瞬で手に入れることができる 34
#AWS77 35
Thank You! http://www.cloudpack.jp/ [email protected] @cloudpack_jp