Mackerel Meetup #9に登壇させて頂きました!(これまでの課題とMackerelを導入して)
↑の続きです。
登壇では時間が無かったので極力内容をハショりました。
なので、ちょっと細かい所までここでは書いて色々吐き出したいと思います。
Mackerel x Twilio 連携して
とりあえずTwilio連携したかった理由として以下があります。
- 別のシステムでTwilio連携しているものがあった
- 元々の監視の仕組みとしてzabbixで架電通知してたのでMackerelでもやりたかったが出来なかった
- 通知先がメールやSlack等だけだと障害を取りこぼす可能性がある
- サービス影響のある無しを迅速に判断したい
これをかいつまんで図にすると↓になります。
別にTwilioに拘らなくても架電通知は出来るじゃんと思いますが、実装予定のシステムのリリース日までに余裕が無い事もあり、他の架電通知の仕組みを作り込むのは時間的に厳しい・・という事で半ば諦めていました。
が、風の噂でMackerelとTwilioが連携するってよ!という話を聴いたので、リリース前に連携するのを待っていました。
そしてとうとう↓が来ました。
待ちに待ったブログをナイスタイミングで はてなさん が出してくれたので、即設計と開発に着手しました。
何を決めたか
架電通知したいと言ってもやりたい事が何か分かっていないと設計も何も無いので、まずやりたい事を纏めました。
- システム担当者全員に順番で通知したい
- 着信する順番を日付でローテーションさせたい
- アラートが閉塞するまで電話を鳴らし続ける
- 誰かが電話を取ったらSlackに通知させたい(Aさんが電話を取りましたみたいな文言を流す)
大まかに分けると↑のような感じです。
しかし、色々調査していたら時間的制約もあり以下のことは出来ませんでした・・
- 誰かが電話を取ったらSlackに通知させたい(Aさんが電話を取りましたみたいな文言を流す)
ですが、他の事は実装出来たので概要図を書きますとこうなります。
これだけじゃなんのこっちゃって感じだと思いますので説明を書きますと
Mackerel架電通知詳細
通知フロー仕様
- Mackerelでアラートを検知
- Mackerelで設定したFromの電話番号(TwilioアカウントA)からToの電話番号(TwilioアカウントB)に発信
- TwilioアカウントBは電話を受け、指定したTwiMLにより音楽ファイルをリピート再生する
※音楽ファイルをリピート再生して電話を受けている状態を維持しないと電話を掛けてもすぐに終了してしまう - 3のリピート再生が行われている間、同時にMackerelで設定したTwilioアカウントAのTwiMLをTwilio上で実行
- TwilioアカウントAがTwiMLに設定された内容で各メンバーに電話を発信。このアクションはTwiMLに設定したメンバーに対して順次着信を行い、誰かが電話を取るか、TwiMLに記述された電話番号全てに発信が終わるまで処理する(1名当たり60秒間発信)
- 誰かが電話を取った場合、TwilioはTwiMLに指定したURLのTwiMLに記載されているメッセージを読み上げて電話を終了する。この電話終了と合わせて音楽ファイルのリピート再生も終了する
- アラートが解消されるまでMackerelは指定した通知の再送間隔でアラートを発信し、再度2から処理を実施する
制限事項
- メンバー着信時に発信者番号を表示させる為に、Twilioアカウントを2つ用意したが着信側で「発信者不明」等と表示されてしまう
- TwiMLに記載できる電話番号は10人までで、かつ同じ番号を複数記載出来ない
- CallbackStatusを持たせて後続処理を実施する際には作り込みが必要な為、Twilioからの着信を誰かが電話を取っても電話を取ったことを通知出来ない
制限事項はあるものの、障害の取りこぼしを極力防いでなおかつ迅速に障害検知出来る仕組みは実装出来たので、架電通知の仕組みとしてはこれで良しとしました。
他に電話番号のローテーションをどうしているか等は↓になります。
基本的にJenkinsを使って日時でJOBを実行している形になります。
電話番号ローテーション仕様
- 指定した時刻でリポジトリから対象ファイルを取得
- シェルスクリプトを実行し、電話番号が記載されているTwiMLファイルをローテーションする
S3設定
- バケットポリシーは設定せず、バケットおよびオブジェクトはバケットACLにてパブリック公開とする
- バケット名はパスワードジェネレーターなどを使用して設定可能な最大文字数(63文字)ランダムな文字列で作成し難読化