JAWS-UG Fukuoka勉強会 第3回

災害時の対応とAWSの力

後藤 和貴　kaz@cloudpack.jp　

2011.6.21

自己紹介: 後藤 和貴

プロフィールアイレット株式会社　　　　　　　　　　エバンジェリスト出没するJAWS-UG: Tokyo, Osaka, Fukuoka new!

好きなAWSサービス: プレミアムサポート（Goldなら1時間以内！）SSID: kaz_goto　

最近の活動4月 AWSアドバンストセミナー、　　JAWS-UG Osaka 第2回勉強会5月 AWS Partner Advisory Summit　 　in Seattle

2

@kaz_goto

アイレット株式会社

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インスタンス/日まで）

定額課金・請求書払い

従量課金では予算計画が立てられないクレジットカードでUSドル決済では利用料の予測が難しい

8

Amazon Web Servicesでは...

月額固定＋日本円請求書発行

フルマネージド

サービス/リソース監視

ディスク使用量、メモリ使用量、プロセス数、Webサーバー・DBサーバー死活...

バックアップ/リストア

EBSスナップショットを利用した二世代（過去二日分）バックアップ

アクセス制御(ファイアーウォール)

適切なセキュリティグループを設定、OS・ミドルウェアレベルでさらに細かな設定も対応可能

9

10

続きはウェブで

キャンペーン型サイト事例紹介

11

社団法人 日本プロゴルフ協会 公式サイト

12

http://www.pga.or.jp/

社団法人 日本プロゴルフ協会 公式サイト

課題

毎年トーナメントの時期にアクセスピークが来るが、そのピークに耐えられない

サーバーの増強はかなり前から準備が必要＋コストが上昇する

13

http://www.pga.or.jp/

社団法人 日本プロゴルフ協会 公式サイト

14

トーナメント前後数日間 5台追加（EC2 SMALL マスター1台＋スレーブ5

台）

スケールアウトしやすい構成: コンテンツ配信冗長化、フォーム系はすべてにマスターに転送（ReverseProxy）、CMSもマスター、配信はrsyncで実行

http://www.pga.or.jp/

(master)

slave

slave

slave

slave

slave

ELB

バースト保証適用（固定費用内）

宅麺.com

15

http://www.takumen.com/

宅麺.com

16

課題

TVでの紹介によるアクセス急増に耐えきれずサーバーダウン

ウェブサイトがビジネスの唯一の入り口

一旦できあがったサイトなので容易に移行はできない

http://www.takumen.com/

宅麺.com 第1段階

EC(ウェブアプリ)部分は既存インフラのまま

画像、CSS、JS、SWFなどスタティックファイルのみ CloudFront 利用（カスタムオリジン）

17

http://www.takumen.com/

Text既存サーバー(EC)

www.takumen.com cdn.takumen.com

カスタムオリジン設定

宅麺.com 第2段階

EC(ウェブアプリ)部分もEC2へ移行！

バックアップ・リストア設定、運用・監視の強化

18

http://www.takumen.com/

既存サーバー(EC) 移行

宅麺.com

第1段階CDNのみ導入

第2段階本体EC2へ移行

バックアップ・リストア設定、運用・監視の強化

第3段階

スケーラブルな構成へ → 6/24に勝負！

19

http://www.takumen.com/

段階的、かつスムースな移行が可能

災害時対応での事例

20

21

地震発生後 cloudpackチームで行った対応

情報発信用CMS導入済みAMI作成

SAVE JAPAN: ミラーサイト作成 (CDN)

JustGiving: AWS移行、スケールアップ、負荷分散構成 (DB分離、LB配置)、メールサーバー移行

buji.me: AWS移行、冗長化構成準備(負荷分散)

ゆれくるコール: ストレージサービス組み込み(負荷分散)

medica.net: AWS移行

sinsai.info: ミドルウェア負荷調査、スケールアウト構成準備(負荷分散)

茨城大学: DNSホスト

22

Just Giving

23

http://justgiving.jp/

JustGiving Japan

24

http://justgiving.jp/

3/12 13:41

JustGiving Japan

25

http://justgiving.jp/

3/12 14:10

JustGiving Japan

26

http://justgiving.jp/

3/12 19:13

JustGiving Japan

27

http://justgiving.jp/

3/12 19:16

JustGiving Japan

28

3月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. （深夜になったこともあり）一旦落ち着いたのでアプリを継続修正依頼して一旦完了

29

13日正午付近

14日0時半

その後、18日までアプリサーバー冗長化調整/DB/メール配信/アプリ負荷改善がつづく...

フロントキャッシュ導入班Apache最適化調査班DB負荷調査班

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, 0 stopped, 0 zombie

Cpu(s): 43.7%us, 13.8%sy, 0.0%ni, 39.1%id, 0.4%wa, 0.0%hi, 2.9%si, 0.2%stMem: 35133768k total, 9500728k used, 25633040k free, 101084k buffers

Swap: 0k total, 0k used, 0k free, 867780k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

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

JustGiving Japan

31

ウェブサーバー スケールアップ

c1.xlarge(7GB, 20ECU) → m2.2xlarge(34.2GB, 13ECU)　

ミドルウェアチューニング

Apache設定見直し（ReverseProxy→Redirect、メモリ使用量削減、起動プロセス数調整...）

メール配信改善

アプリ改修HTMLキャッシュ

DBアクセス一部キャッシュ化（memcached）

http://justgiving.jp/

ここまでの対策で一旦安定・作業終了

JustGiving Japan

ポイント

スナップショット利用で本番稼働中にテスト環境作成

調査継続しながら、合間にマシンスケールアップ

スケールアップで延命している間にさらに調査

アプリ改修と同感覚でインフラの改善ができる

32

http://justgiving.jp/

33

AWS移行ミドルウェア負荷調査スケールアウト準備（既存アプリ構成を変更せず対応する方法の調査）

sinsai.infohttp://sinsai.info/

AWS移行冗長化構成

buji.mehttp://ww.buji.me/

S3ホスティングゆれくるコールfor iPhone

AWS移行サーバー構築DNS切り替え(Route53)

medica.nethttp://medica.net/

DNS切り替え(Route53)茨城大学http://www.ibaraki.ac.jp/

災害時対応で改めて感じたAWSの力すぐに利用開始

まずは IaaS であるOS以上は同じで移行がスムース

強力な PaaS

S3を始めとするとする負荷分散しやすいサービス群

スケール可能なミドルウェア (MySQL/Apache)

仮想化・スナップショット検証環境構築・本番適用・切り戻しが自由自在に可能

最大規模のパブリッククラウド強大なパワーを一瞬で手に入れることができる

34

35

#AWS77

Thank You!

http://www.cloudpack.jp/suuport@cloudpack.jp

@cloudpack_jp