2017.05.23

チャットもいいけど電話もね！（障害通知編）

丹念

はじめに

お久しぶりです。製品開発部の奴賀(ぬか)です。
早いものでもう１１月ですね。気の早い方は忘年会のために体調を万全に仕上げている頃でしょうか。（私も今月から忘年会が入っているため、急ピッチで脂肪を燃焼させようと企んでいるところです）
そんな忘年会好きのシステム運用担当の強い味方！障害通知システムを今回はSkyOnDemand上で実装してみようと思います。
でも、オンコール担当者は呑んじゃダメですよ(´∀｀*)ｳﾌﾌ

想定しているユースケース

1時間に1度、売上予測アルゴリズムを更新するストアドファンクションを実行します。 実行時に障害が発生した場合、障害発生日時に依り下記のように通知先を振り分けます。

  • 平日10時00分～18時59分の場合：システム運用チームのチャットツールに通知する
  • それ以外の場合：オンコール担当者の携帯電話に通知する

チャットツールに通知する部分は、前回ご紹介した 簡単！３ステップでウェルネス連携！ の ChatWork に投稿する部分が流用できそうですね。携帯電話に通知する部分は、 Twilio を利用して作成したいと思います。

さて、まずは Twilio の準備をしましょう。

Twilioの準備

  1. こちらからアカウントを登録します。
  2. 検証可能な携帯電話番号を用意し、Twilio電話番号(050番号)を取得します。
  3. コンソールダッシュボードに記載されてある、ACCOUNT SID と AUTH TOKEN を覚えておきます。

今回は Twilio REST API の Calls リストリソースにPOSTリクエストを発行することになります。また、テキスト読み上げを行うために TwiML を作成する必要があります。 TwiML は Public な場所ならどこに置かれていてもよいので、今回はサクッと使える Amazon S3 上にアップロードしようと思います。

ストアドファンクションの作成

今回の目的は障害通知システムの構築ですので、売上予測アルゴリズムを更新するストアドファンクションはテストスタブとして、TemporaryDBに作成しておこうと思います。 下記の画像のような感じですね。

SkyOnDemandスクリプト作成

それでは、必要な準備が整いましたので、スクリプトを作成していきます。

今回のスクリプトの全体図は下記のとおりです。

メインスクリプト

  • M_メイン処理実行 ・・・ 本プロジェクトのメイン処理を行う

バッチ処理サブスクリプト

  • S01_00_売上予測アルゴリズム更新 ・・・ テストスタブのストアドファンクションを実行するスクリプト

障害通知関連サブスクリプト

  • S02_00_障害通知_メイン ・・・ 障害発生時刻に依り、各障害通知スクリプトに処理を振り分ける
  • S02_01_障害通知_電話 ・・・ 障害内容をオンコール担当者の携帯電話に通知する
  • S02_02_障害通知_チャット ・・・ 障害内容をシステム運用チームのチャットグループに通知する

グローバルリソース設定

スクリプトで利用するグロバールリソースを下記の内容で設定します。

接続名 接続タイプ URL 備考
REST接続設定_TwilioAPIエンドポイント REST(REST接続設定) https://api.twilio.com/2010-04-01 Twilio REST APIを利用するためのグローバルリソース設定
REST接続設定_ChatworkAPIエンドポイント REST(REST接続設定) https://api.chatwork.com/v1 ChatWork APIを利用するためのグローバルリソース設定

接続名 接続タイプ ドライバクラス名 URL 備考
JDBC接続設定_TemporaryDB接続 JDBC(JDBC接続設定) org.postgresql.Driver jdbc:postgresql://localhost:5432/db_user テストスタブのストアドファンクションを実行するためのグローバルリソース設定

接続名 接続タイプ Endpoint 備考
Amazon S3接続設定_TwiML置き場 Amazon S3(Amazon S3接続設定) s3-ap-northeast-1.amazonaws.com TwiMLを公開するS3に接続するためのグローバルリソース設定

スクリプト詳細

それでは、主なスクリプト内容をご説明したいと思います。

バッチ処理サブスクリプト

S01_00_売上予測アルゴリズム更新


なんのことはないですね。JDBCアダプタのストアドプロシージャ実行コンポーネントで、テストスタブのストアドファンクションを Call しているだけです。

障害通知関連サブスクリプト

S02_00_障害通知_メイン

現在日時を取得し条件により通知先を振り分け、各サブスクリプトを実行します。実行の際には呼び出し元から渡されたエラーメッセージ(スクリプト入力変数の i-message)を渡します。

現在日時ロジックアイコンにて現在日時を取得します。日時フォーマッティングロジックアイコンを利用し曜日のみを dayOfTheWeek スクリプト変数へ格納します。また、時の取得ロジックアイコンを利用し時刻のみを currentTime スクリプト変数へ格納します。

条件のプロパティにて、先ほど格納した２つのスクリプト変数を利用し、適切に通知先を振り分けられるように条件分岐させます。(月曜日～金曜日の10時00分～18時59分以外が携帯電話へ通知でしたね。)

S02_01_障害通知_電話


Twilioの準備で前述した TwiML をローカルに作成し、その後 Amazon S3 上にアップロードします。そして、 Twilio REST API を実行します。

TwiMLの仕様に従ってXMLファイルをローカルに生成します。個人的にドイツ語が障害発生時の緊迫感が増す雰囲気がして好きなのですが、今回は素直に日本語でメッセージを読み上げて頂こうと思います。

From には Twilio電話番号(050番号) を、 To には障害を通知したい相手(オンコール担当者)の電話番号を E.164形式で設定します。また、 Method は Get である必要があります。URLスクリプト変数には TwiML がアップロードされる Amazon S3 の URL が設定されています。

あとは、 TwilioAPI の仕様に従って、RESTアダプタのPOST実行コンポーネントで実行するだけです。 Twilio の準備で取得した ACCOUNT SID と AUTH TOKEN を利用して Basic認証の設定を行うのも忘れないようにしましょう。

S02_02_障害通知_チャット

こちらのスクリプトは、前回ご紹介した 簡単！３ステップでウェルネス連携！ の 流用となりますので、割愛させて頂きます。

メインスクリプト

M_メイン処理実行

売上予測アルゴリズム更新サブスクリプトを実行し、実行に失敗した場合はエラーメッセージを設定し、S02_00_障害通知_メインサブスクリプトを呼び出す流れとなります。
S02_00_障害通知_メインサブスクリプトの i-message 入力変数に渡すエラーメッセージは下記になります。

固定のメッセージ + 売上予測アルゴリズム更新サブスクリプトで例外が発生した場合に設定される error_message をエラーメッセージとしています。

さて、これでスクリプトは完成しました。続いてはおなじみスケジュールトリガーの設定です。

スケジュールトリガー(インターバル)設定

それでは、実行間隔1時間でスケジュールトリガーを設定しましょう。
スケジュールトリガー設定の前に障害通知システムプロジェクトをサービスとして登録しておきます。

次に、下記の内容でスケジュールトリガーの設定を行います。

実行間隔(時:分:秒) 休日の動作 サービス スクリプト
01:00:00 休日にも実行する root@障害通知システム M_メイン処理実行

これにて全ての作業が完了となります。
現在の時刻は16時43分。次回トリガー発火タイミングである17時を楽しみに待ちましょう。

それから・・・

お待ちかねの17時となりましたが、どこにも通知が来ていません。そうですね。障害発生時の通知であるにも関わらず、正常に処理が終了する状態にしていました。
やはりデバッグは大事です。スクリプト作成時には細かい単位でデバッグするように心がけたいものです。テストスタブであるストアドファンクションの名前を update_sales_prediction_algorithm から update_sales_prediction_algorithmXXX に変更してデバッグ実行してみます。正しく Chatwork に通知されました。S02_01_障害通知_電話もデバッグしてみましたが、問題なさそうです。それではスクリプトの状態はこのままで、次のトリガー発火タイミングである18時を待ちます。

18時となりました。


正しく障害内容が通知されていますね。それではお疲れ様でした。

・・・時刻は19時ちょうど。

プルルルルルッ♪ ガチャッ！
ぬ「(´∇｀)|ｮ しもしも～？」
電「障害が発生しました。・・・」
ぬ「ヽ(ﾟДﾟ;)ﾉ!!」
このような事にならないように、テストで使用した不要なトリガーは忘れずに無効化するようにしましょう。

最後に

簡単ながら統合管理ツールの障害通知システム的な利用方法をご紹介させて頂きましたが、如何でしたでしょうか。 通知はメールで行いたい！という場合は、メール通知サブスクリプトを作成して、条件分岐に付け加えるだけですね。 EC2インスタンスの障害を通知したい！という場合は、Amazon EC2アダプタのインスタンス情報取得コンポーネントで情報を取得し instanceState が running 以外の場合に例外通知コンポーネントで例外を通知するのは如何でしょうか。
このようにあれもしたい、これもしたい、となった場合に簡単に試せるのが SkyOnDemand のいいところの一つかなと思っております。 今回は Twilio からの架電でしたが、機会があれば 問い合わせを Twilio で受電して 通話内容を AI に連携して返答するといったカスタマーサポート編のようなものもご紹介できればと思っております。 それでは、またお会いしましょう(o･･o)/~

1 件
    　
  • banner
  • banner

関連する記事

関連するキーワード