災害時対応とクラウド
>100 Views
May 14, 11
スライド概要
クラウドコンピューティングEXPO2011春、cloudpackブースにて行ったセミナーで使った資料。震災後に行った支援活動紹介とAWS/クラウドのメリットについて紹介。
関連スライド
各ページのテキスト
クラウドコンピューティングEXPO 2011春 災害時対応とクラウド アイレット株式会社 後藤 和貴 kaz@cloudpack.jp 2011.5
アイレット株式会社 Web開発を得意とするシステム開発会社。開発のほ か、システム保守・運用、ホスティング事業なども展 開。 2003年8月 創業 従業員数 23名 事業内容: ITコンサルティング、システム開発、システム保守・運 用、Webデザイン・制作、サーバハウジング・ホスティ ング、講師事業 2
Amazon EC2 をはじめとするクラウド導入設計、運用・保 守サービス クラウド環境をバックエンドとした 月額費用固定型フルマネージドホスティング AWS導入・構築支援、コンサルティング、システム構築 サービス 2010年4月サービス開始 2011年1月 認定 2011年4月時点 30社・100インスタンス超、さらに増加中 4
フルマネージドホスティング ファイアーウォール ロードバランサー バックアップ・リストア サーバー/リソース監視 バースト保障 EC2/S3/EBS/ELB/CloudFront構成のベストプラクティスを 標準設定として提供 電話/メールによる24時間サポート 初期費用なし、運用保守込みで月額5万円〜 5
フルマネージド サービス/リソース監視 ディスク使用量、メモリ使用量、プロセス数、 Webサーバー・DBサーバー死活... バックアップ/リストア EBSスナップショットを利用した二世代（過去 二日分）バックアップ アクセス制御(ファイアーウォール) 適切なセキュリティグループを設定、OS・ミド ルウェアレベルでさらに細かな設定も対応可能 6
定額課金・請求書払い Amazon Web Servicesでは... 従量課金では予算計画が立てられない クレジットカードでUSドル決済では利用料の予測が難しい 月額固定＋日本円請求書発行 7
バースト保障 キャンペーンなど急激なアクセス増加へ合わせてインフ ラ準備するのは不可能 いつあるかわからないピークのために予め準備できない 追加料金無しでスケールアウト （7インスタンス/日まで） 8
スピンオフ・サービス 引っ越し職人 監視職人 CDN職人 開発職人 MT(MovableType)職人 SSL職人 負荷テスト職人 保守職人 請求代行サービス 9
最近の事例 用途 商品紹介ウェブサイト キャンペーンウェブサイト ウェブサービス提供サイト EC CMS 大規模配信 ソーシャルアプリ・ソーシャルゲーム データストレージ 10
最近の事例 動機 拡張縮退運転 さまざまな機能 コスト（価格モデル） ライセンスモデル 既存DC/ハードウェアリプレイス 災害時対策 11
災害時対応での事例 12
13
地震発生後 cloudpackチームで行った対応 情報発信用CMS導入済みAMI作成 SAVE JAPAN: ミラーサイト作成 (CDN) JustGiving: AWS移行、スケールアップ、負荷分散構成 (DB分離、LB配 置)、メールサーバー移行 buji.me: AWS移行、冗長化構成準備(負荷分散) ゆれくるコール: ストレージサービス組み込み(負荷分散) medica.net: AWS移行 sinsai.info: ミドルウェア負荷調査、スケールアウト構成準備(負荷分 散)主に被災者向け情報・サービスサイトの立ち上げ およびAWS移行・負荷対策の面で支援しました 茨城大学: DNSホスト 14
SAVE JAPAN! PROJECT http://savejapan.simone-inc.com/ Twitter上の震災情報を正確な情報のやり取りするためのサイト ハッシュタグを使って都道府県別に整理 早い段階で出来た震災情報サイトだったためアクセスが集中 15
SAVE JAPAN! PROJECT http://savejapan.simone-inc.com/ 3/12 0:29 16
SAVE JAPAN! PROJECT http://savejapan.simone-inc.com/ 3/12 1:15 17
SAVE JAPAN! PROJECT http://savejapan.simone-inc.com/ 3/12 1:25 18
SAVE JAPAN! PROJECT http://savejapan.simone-inc.com/ Text 3/12 3:00 30分ほどでミラーサイト構築済み 19
SAVE JAPAN! PROJECT http://savejapan.simone-inc.com/ ポイント Twitter で拡散されたおかげで対応が必要な事を知り、すぐさま 応援 作業時間わずか30分でCDNへミラーサイトを構築 （S3+CloudFront利用） オリジン サーバー 20
Just Giving http://justgiving.jp/ 21
JustGiving Japan http://justgiving.jp/ 3/12 13:41 22
JustGiving Japan http://justgiving.jp/ 3/12 14:10 23
JustGiving Japan http://justgiving.jp/ 3/12 18:50 24
JustGiving Japan http://justgiving.jp/ 3/12 18:53 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. 画像転送をリバースプロキシ→リダイレクトへ 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
JustGiving Japan http://justgiving.jp/ ウェブサーバー スケールアップ c1.xlarge → m2.2xlarge ミドルウェアチューニング Apache設定見直し（ReverseProxy→Redirect、メモリ使用量削減、起動プ ロセス数調整...） メール配信改善 アプリ改修 HTMLキャッシュ DBアクセス一部キャッシュ化（memcached） ここまでの対策で一旦安定 30
JustGiving Japan http://justgiving.jp/ ポイント スナップショット利用で本番稼働中にテスト環境 作成 調査継続しながら、合間にマシンスケールアップ スケールアップで延命している間にさらに調査 アプリ改修と同感覚でインフラの改善ができる 31
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/ 32
災害時対応 AWSのメリット すぐに利用開始 まずは IaaS である OS以上は同じで移行がスムース 強力な PaaS S3を始めとするとする負荷分散しやすいサービス群 スケール可能なミドルウェア (MySQL/Apache) 仮想化・スナップショット 検証環境構築・本番適用・切り戻しが自由自在に可能 パブリッククラウド 強大なパワーを一瞬で手に入れることができる 33
負荷対応・環境分散の選択肢 負荷分散対応 ロードバランサー + 冗長化サーバー = ELB + EC2 ストレージサービス = S3 CDN = CloudFront グローバル対応 データセンター世界で 5 Region CDN 17 Edge Location 34
災害時対策とクラウド利用の相性 緊急時の負荷対策 安定して調達可能で、かつフレキシブルなインフラでなけれ ば、現実的な対応はできない ＝ パブリッククラウド クラウドと DR データバックアップを複数のロケーションへ 待機系サーバーOSイメージを別リージョンへコピー （cloudworksなど利用） 今後基幹系システムも含め、パブリッククラウド への移行が進んでいくと予想される 35
まとめ 災害時の対応でも、拡張性・経済性の 面でAWSのようなパブリッククラウド が適合 移行が容易だったことも重要な要素 先が読みにくく非常時への対策がしにくい場合 パブリッククラウド利用が必勝の法則 36
Thank You! http://www.cloudpack.jp/ suuport@cloudpack.jp @cloudpack_jp