cloudwatch(+sns+sqs)で障害対応を自動化してみた

Copyright © 2013 AGREX INC.

CloudWatch(+SNS+SQS) で障害対応を自動化してみた

Copyright © 2013 　 AGREX INC. 2

プロフィール

てるい　まさし

照井　将士http://www.facebook.com/marcy.terui

( 株 ) アグレックス　札幌事業所　システム部

1987 年　東京都大田区生まれ1992 年　札幌移住2011 年　 ( 株 ) アグレックス入社

担当業務： EC サイト構築・運用

役職：下っ端・小間使い

好きなサービスSQS 、 CloudWatch 、 RDS

最近嬉しかったこと

色々やらされてやらせていただいて、気がついたら、インフラもやる人に・・・ｗ

登録だけして放置していましたが、ちゃんと使ってみようと思っています。

第１子 (♂) が生まれました！

（奇跡的に）チューニンガソン５で優勝しました！ご褒美は JAWS DAYS 2013 （社費で）無料ご招待！


目次

• 経緯• 自動化したい！だって・・・• 前提と求めるもの• 実際の仕組み• やってみて思ったこと• まとめ


経緯

よくある構成

DB(Master)RDS

Webサーバ

Webサーバ

DB(Slave)RDS

冗長化されている

スケールアウトして増えることも

でも、冗長化できない機能や処理もありますよね？

DB 更新系のバッチ処理とか・・・

障害起きたらどうする？


自動化したい！だって・・・

• 手動でやるとその分時間が取られる• 勤務時間外に障害が起きたら緊急出動？• 勤務時間内でも気が付くのが遅れるかも• 単純にめんどくさい• そしてたぶん対応するのって・・・

CloudWatch や ZABBIX で監視はしているけど・・・

僕ですよね？（汗


前提と求めるもの

• 準備や実装に時間を掛けたくない• 監視や特定処理専用のサーバは作りたくない• スケールアウト（イン）してもそのままで

OK• 障害なので、できる限り確実に処理したい• 万が一復旧に失敗しても時間をおいて再実行• 障害の発生と復旧は検知したい

同時実行や余分に実行されると困る→ 常に１台だけで処理してほしい

前提

求めるもの

これは CloudWatch(+SNS) で OK ！


実際の仕組み・・・の前に

KeepAlived で互いに監視・復旧• 手間が大きい• スケールイン・アウトまで考えると面倒• サーバ (KeepAlived) の死活監視で、

実際に処理が行われているかは確認不可

一般的（？）な方法

AutoScaling で 1 台固定設定• 復旧までけっこう時間がかかる（らし

い）• 専用のサーバが一台必要• 実際に処理が行われているかは確認不可

間違いがあったらすいません


実際の仕組み

WebサーバWebサーバ

CloudWatch

Webサーバ

SQS(Simple Queue Service)SNS(Simple Notification Service)

障害発生

データが来なくなった！！

交代します！！バッチ処理担当

定期的にメトリクス送信

Alarm を通知 Message を格納

Message を Get ！

定期的に Message 取得


補足 (主に SQS について )

• 取得されたメッセージは一定時間隠される　→同時に処理されない

• 隠されたメッセージは、明示的に削除することでキューから完全に消去される

　→復旧処理の完了を確認してから削除できる

• 隠されたメッセージは、明示的に削除されなければ、一定時間後に再取得可能となる

　→万が一失敗しても再実行される

• 当然ながら、全てのメッセージは冗長化　→失われる心配はまず無い

• メッセージの削除は保証されていない　→複数回行われても問題ない or 冪等性のある処理を書く必要有

今回の例で言うと正常時に処理されても無駄に交代しちゃうだけ的な

あと、 NW 障害等で想定外の Alarm が発生するかも※つい昨日 CloudWatch の障害が・・・


補足 ( 実装について )

• CloudWatch→SNS→SQS の連携　→ ManagementConsole(GUI)上で設定するだけ

• メトリクス送信、 SQS からのメッセージ取得　→ネット上にサンプルが山程

• 復旧処理

→ 自分で作ったのここだけ！


やってみて思ったこと

• 監視・通知はサービスがやってくれる• 排他や再実行・確実性は SQS が保証してくれる• 作ったのはほぼフェイルオーバー処理だけ• 料金は無料～ $1/月程度 (API リクエスト 1回 / 分で計算 )→ お手軽！便利！安い！

• Alarm が Queue に入るまでの時間＋ Queue を見る間隔

→即時対応はできない数分～十数分程度ですが・・・

→ もっと色々できるんじゃない？• CloudWatch のアラームは色々な条件が作れる


まとめ

• 復旧処理以外はサービスがやってくれる• 確実性や再実行も保証される

• 障害とみなす条件や正常な状態を定量化• 対応手順をコード化

→ ただの監視ツールと甘くみてました。CloudWatch先生すいません・・・

→ 色んな障害対応を自動化できる！

もう障害は怖くない！すいません。でもやっぱり怖いです・・・

それを CloudWatch のアラームに登録する

想定できる障害については・・・


おまけ（障害以外にも・・・）

• こんな使い方も？1. 更新頻度やデータ量の多いテーブルに対してサンプ

リングされた SQL を定期的に実行2. 一日平均○秒超えたらアラーム3. 深夜に一回だけ SQS にリクエストして、アラーム

が上がってたら OPTIMIZE したり、古いデータを退避させたり・・・

逆にめんどくさいような気も・・・


あれ？なんか忘れてない？←これは・・・？


ありません！

仕事が増えると息子と触れ合う時間が減るのでｗ


ありがとうございました！

cloudwatch(+sns+sqs)で障害対応を自動化してみた

Technology