More Related Content
Similar to CloudWatch(+sns+sqs)で障害対応を自動化してみた
Similar to CloudWatch(+sns+sqs)で障害対応を自動化してみた (20)
More from Terui Masashi (20)
CloudWatch(+sns+sqs)で障害対応を自動化してみた
- 2. プロフィール
てるい まさし
照井 将士 登録だけして放置していましたが、
ちゃんと使ってみようと思っています。
http://www.facebook.com/marcy.terui
(株)アグレックス 札幌事業所 システム
部
1987年 東京都大田区生まれ
1992年 札幌移住
2011年 (株)アグレックス入社
色々やらされてやらせていただいて、
担当業務：ECサイト構築・運用 気がついたら、インフラもやる人に・・・ｗ
役職：下っ端・小間使い
好きなサービス
SQS、CloudWatch、RDS （奇跡的に）チューニンガソン５で優勝しました！
ご褒美はJAWS DAYS 2013（社費で）無料ご招待！
最近嬉しかったこと 第１子(♂)が生まれました！
Copyright © 2013 AGREX INC. 1
- 3. 目次
• 経緯
• 自動化したい！だって・・・
• 前提と求めるもの
• 実際の仕組み
• やってみて思ったこと
• まとめ
Copyright © 2013 AGREX INC. 2
- 4. 経緯
よくある構成
でも、冗長化できない
機能や処理もありますよね？
DB更新系のバッチ処理とか・・・
冗長化されている
Web Web
サーバ サーバ
スケールアウトして増えることも
DB DB
(Master) (Slave)
RDS RDS
Copyright © 2013 AGREX INC. 3
- 6. 前提と求めるもの
前提
同時実行や余分に実行されると困る
→常に１台だけで処理してほしい
求めるもの
• 準備や実装に時間を掛けたくない
• 監視や特定処理専用のサーバは作りたくない
• スケールアウト（イン）してもそのままでOK
• 障害なので、できる限り確実に処理したい
• 万が一復旧に失敗しても時間をおいて再実行
• 障害の発生と復旧は検知したい
これはCloudWatch(+SNS)でOK！
Copyright © 2013 AGREX INC. 5
- 7. 実際の仕組み・・・の前に
一般的（？）な方法 間違いがあったらすいません
KeepAlivedで互いに監視・復旧
• 手間が大きい
• スケールイン・アウトまで考えると面倒
• サーバ(KeepAlived)の死活監視で、
実際に処理が行われているかは確認不可
AutoScalingで1台固定設定
• 復旧までけっこう時間がかかる（らしい）
• 専用のサーバが一台必要
• 実際に処理が行われているかは確認不可
Copyright © 2013 AGREX INC. 6
- 8. 実際の仕組み
Alarmを通知 Messageを格納
CloudWatch データが SNS(Simple Notification Service) SQS(Simple Queue Service)
来なくなった！！
定期的にMessage取得
定期的にメトリクス送信
MessageをGet！
バッチ処理担当 交代します！！
障害発生
Webサーバ Webサーバ Webサーバ
Copyright © 2013 AGREX INC. 7
- 9. 補足 (主にSQSについて)
• 取得されたメッセージは一定時間隠される
→同時に処理されない
• 隠されたメッセージは、明示的に削除することでキューから完
全に消去される
→復旧処理の完了を確認してから削除できる
• 隠されたメッセージは、明示的に削除されなければ、一定時間
後に再取得可能となる
→万が一失敗しても再実行される
• 当然ながら、全てのメッセージは冗長化
→失われる心配はまず無い あと、NW障害等で
想定外のAlarmが発生するかも
※つい昨日CloudWatchの障害が・・・
• メッセージの削除は保証されていない
→複数回行われても問題ない or 冪等性のある処理を書く必要有
今回の例で言うと正常時に処理されても無駄に交代しちゃうだけ的な
Copyright © 2013 AGREX INC. 8
- 10. 補足 (実装について)
• CloudWatch→SNS→SQSの連携
→ManagementConsole(GUI)上で設定するだけ
• メトリクス送信、SQSからのメッセージ取得
→ネット上にサンプルが山程
• 復旧処理
Copyright © 2013 AGREX INC. 9
- 11. やってみて思ったこと
• 監視・通知はサービスがやってくれる
• 排他や再実行・確実性はSQSが保証してくれる
• 作ったのはほぼフェイルオーバー処理だけ
• 料金は無料～$1/月程度(APIリクエスト1回/分で計算)
• AlarmがQueueに入るまでの時間＋Queueを見る間隔
数分～十数分程度ですが・・・
• CloudWatchのアラームは色々な条件が作れる
Copyright © 2013 AGREX INC. 10
- 12. まとめ
• 復旧処理以外はサービスがやってくれる
• 確実性や再実行も保証される
それをCloudWatchの
アラームに登録する
• 障害とみなす条件や正常な状態を定量化
• 対応手順をコード化
想定できる障害については・・・
すいません。でもやっぱり怖いです・・・
Copyright © 2013 AGREX INC. 11
- 13. おまけ（障害以外にも・・・）
• こんな使い方も？
1. 更新頻度やデータ量の多いテーブルに対してサンプ
リングされたSQLを定期的に実行
2. 一日平均○秒超えたらアラーム
3. 深夜に一回だけSQSにリクエストして、アラームが
上がってたらOPTIMIZEしたり、古いデータを退避
させたり・・・
逆にめんどくさいような気も・・・
Copyright © 2013 AGREX INC. 12
