Download - JAWS-UG Osaka勉強会 第2回 「災害後 活動報告」
自己紹介: 後藤 和貴
プロフィールアイレット株式会社cloudpack 事業部 エバンジェリストJAWS-UG TokyoコアメンバーJAWS-UG Osaka メンバー?好きなAWSサービス: S3
Blog: http://5net.com/ Email: [email protected] Twitter: @kaz_goto
最近の活動2月 JAWSUG Osaka 第1回勉強会参加3月 Cloud Days Tokyo パネルディスカッション登壇3月 震災後サーバー復旧ボランティア4月 AWSアドバンストセミナー
2
Amazon EC2 をはじめとするクラウド導入設計、運用・保守サービス
クラウド環境をバックエンドとした月額費用固定型フルマネージドホスティング
AWS導入・構築支援、コンサルティング、システム構築サービス
2010年4月サービス開始
2011年1月 認定
2011年4月時点 30社・100インスタンス超、さらに増加中
3
4
続きはウェブで
最近の案件相談: 用途別
商品紹介ウェブサイト
キャンペーンウェブサイト
ウェブサービス提供サイト
EC
CMS
大規模配信
ソーシャルアプリ・ソーシャルゲーム
データストレージ
5
最近の案件相談: 動機別
拡張縮退運転
AWSならではの機能利用
コスト(価格モデル)
ライセンスモデル
既存DC/ハードウェアリプレイス
災害対策
6
災害時対応での事例
7
その前に地震当日の話
8
有楽町某社で打ち合わせ中地震に遭遇
9
「あ、ゆれ」
10
「結構長いですね」
11
「あれ?かなり... ですね」
12
「うわ、これ結構ですね」
13
「やばいかも」
14
「机の下に入るレベル?」
15
「いや、あ、潜りましょう」
16
「いや、潜れ」
17
「ちょ、まじで、すごい」
18
「やばいやばい」
19
「これはまずい、ビルやばいかも」
20
「男三人で死ぬのは嫌だ」(笑無)
21
「あ、やっと収まりましたな」
22
非常時のサイレンビル管理室からのアナウンス
23
「すぐに避難してください」(女性)
24
有楽町駅前に出て
できるだけ道の真ん中に
25
26
電話通じず、インターネットOK
SMS/Facebookで連絡取りまくる
27
28
29
30
31
32
都内で軽い被災
帰宅後テレビをみて東北の惨状を知る
変なテンション
各サイトがアクセス不能に
「これなんとかできる」「やるしかない」
JAWS-UG / cloudpack チームと連携して対応
東京
札幌
大阪
仙台
名古屋女子部
福岡
北陸
山口
!"#$%#& 各サイトがダウンしている。助けられないか?
!"#$%&'↓'
電話会議'↓'
各支援プロジェクト始動
やっちゃいましょう!!
35
地震発生後 チームで行った対応
情報発信用CMS導入済みAMI作成
SAVE JAPAN: ミラーサイト作成 (CDN)
JustGiving: AWS移行、スケールアップ、負荷分散構成 (DB分離、LB配置)、メールサーバー移行
buji.me: AWS移行、冗長化構成準備(負荷分散)
ゆれくるコール: ストレージサービス組み込み(負荷分散)
medica.net: AWS移行
sinsai.info: ミドルウェア負荷調査、スケールアウト構成準備(負荷分散)
茨城大学: DNSホスト
36
SAVE JAPAN! PROJECT
37
Twitter上の震災情報を正確な情報のやり取りするためのサイト
ハッシュタグを使って都道府県別に整理
早い段階で出来た震災情報サイトだったためアクセスが集中
http://savejapan.simone-inc.com/
SAVE JAPAN! PROJECT
38
http://savejapan.simone-inc.com/
3/12 0:29
SAVE JAPAN! PROJECT
39
http://savejapan.simone-inc.com/
3/12 1:15
SAVE JAPAN! PROJECT
40
http://savejapan.simone-inc.com/
3/12 1:25
SAVE JAPAN! PROJECT
41
http://savejapan.simone-inc.com/
3/12 3:00
30分ほどでミラーサイト構築済み
Text
SAVE JAPAN! PROJECT
42
ポイント
Twitter で拡散されたおかげで対応が必要な事を知り、すぐさま応援
作業時間わずか30分でCDNへミラーサイトを構築(S3+CloudFront利用)
http://savejapan.simone-inc.com/
オリジンサーバー
玉川さんがS3で対策をしていた...
JustGiving Japan
50
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. (深夜になったこともあり)一旦落ち着いたのでアプリを継続修正依頼して一旦完了
51
13日正午付近
14日0時半
その後、18日までアプリサーバー冗長化調整/DB/メール配信/アプリ負荷改善がつづく...
フロントキャッシュ導入班Apache最適化調査班DB負荷調査班
13:22top - 13:22:34 up 13:57, 10 users, load average: 91.19, 89.79, 66.40
Tasks: 473 total, 70 running, 403 sleeping, 0 stopped, 0 zombie
Cpu(s): 16.3%us, 7.1%sy, 0.0%ni, 72.7%id, 0.1%wa, 0.0%hi, 1.7%si, 2.1Mem: 7136220k total, 6683404k used, 452816k free, 201388k buffers
Swap: 0k total, 0k used, 0k free, 1002020k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9060 apache 20 0 383m 16m 5384 S 29.8 0.2 0:06.13 httpd 8701 apache 20 0 397m 26m 8144 R 23.5 0.4 0:20.02 httpd
9022 apache 20 0 406m 40m 6040 R 23.5 0.6 0:07.74 httpd 8996 apache 20 0 396m 25m 7716 R 20.4 0.4 0:07.21 httpd
8556 apache 20 0 388m 21m 6248 R 18.8 0.3 0:18.46 httpd
8750 apache 20 0 391m 25m 6140 S 18.8 0.4 0:14.28 httpd 8585 apache 20 0 388m 22m 6168 R 17.2 0.3 0:20.89 httpd
8655 apache 20 0 407m 36m 8112 R 17.2 0.5 0:17.60 httpd 8733 apache 20 0 398m 28m 8220 R 17.2 0.4 0:13.14 httpd
8467 apache 20 0 405m 39m 6064 S 15.7 0.6 0:18.56 httpd
8487 apache 20 0 433m 62m 8032 R 15.7 0.9 0:27.72 httpd 8645 apache 20 0 407m 41m 6156 R 15.7 0.6 0:22.01 httpd
8744 apache 20 0 387m 21
52
16:23(scaleup-ed, but Horiemon-shot attacked)
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
53
JustGiving Japan
54
ウェブサーバー スケールアップ
c1.xlarge (7GB 20ECU) → m2.2xlarge (34.2GB 13ECU)
ミドルウェアチューニング
Apache設定見直し(ReverseProxy→Redirect、メモリ使用量削減、起動プロセス数調整...)
メール配信改善
アプリ改修
HTMLキャッシュ
DBアクセス一部キャッシュ化(memcached)
http://justgiving.jp/
ここまでの対策で一旦安定
JustGiving Japan
ポイント
スナップショット利用で本番稼働中にテスト環境作成
調査継続しながら、合間にマシンスケールアップ
スケールアップで延命している間にさらに調査
アプリ改修と同感覚でインフラの改善ができる
55
http://justgiving.jp/
56
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/
災害時対応で感じたAWSのメリットすぐに利用開始
まずは IaaS
VMより上は既存概念と同じなので移行がスムース
高負荷への対抗策
S3を始めとする負荷分散を考慮した機能
スケールアップ・スケールアウトの選択肢
強大なパワーを一瞬で手に入れることができる
仮想化・スナップショット
検証環境構築・本番適用・切り戻しが自由自在に可能
57
災害時の対応とクラウドの相性
緊急時の負荷対策
安定的でかつフレキシブルなインフラでなければ、現実的なコストで対応できない=パブリッククラウド
クラウドと DR
データバックアップを複数のロケーションへ
待機系サーバーをOSイメージ保存で停止状態で保管可能
待期系サーバーを別リージョンへ配置可能(cloudworksなど利用すると簡単)
58
今後基幹系システムも含め、パブリッククラウドへの移行が進んでいくと予想される
参考情報
59
電通国際情報サービス 加藤 章さん著[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
副産物
S3 を複数の EC2 で mount して負荷分散構成(s3fs利用)
Sticky Session with ELB の検証
60
Thank You!