はじめに

2019年7月末にリリースされたTOAST Service Monitoringサービスについて紹介します。

開発者にとって重要なツールの1つにモニタリングツールがあります。サービスが安定的に動作しているか常時モニタリングし、正常に動作していないときは障害と判断して、関連する担当者に伝える機能が必要です。

モニタリングツールの機能は、大きく次の3つの機能で構成されています。

• モニタリング対象となるサービスを階層的な構造で管理する機能
• モニタリングのシナリオを作成して、障害判定基準を定める機能 – モニタリング設定
• 障害を担当者に配信できるように設定する機能

サービス階層の設定

開発チームや開発者は、複数のサービスやシステムに対する開発および最低限の運営業務を担当します。たとえば、複数のポータルサービスを運営する部門では、階層的なサービス構造を登録・管理する必要があります。

次のように仮想的なサービスがあると仮定しましょう。

• TOASTメール
• TOASTニュース
• TOASTブログ

「TOASTニュース」の下位サービスにはさらに小さな規模のサービスが存在します。

• ニュースメーリングサービス
• ニュースミキシングサービス
• ニュース収集サービス
• ニュースキュレーションサービス

下図のように、左側のサービス一覧領域から「追加」ボタンをクリックし、サービス名、説明、上位ディレクトリなどを指定して、「サービス登録」ボタンをクリックすると、階層的なサービス構造を定義できます。

「ディレクトリ」のチェックボックスがチェックされていれば、下位にサービスを含めることができ、「ディレクトリ」がチェックされていないサービスに対してのみ、モニタリングシナリオを作成することができます。そのため、「TOASTニュース」サービスは、他の下位サービスを含めるだけで、モニタリングシナリオを追加することができません。モニタリングシナリオは「ニュースメーリングサービス」に追加できます。

このように、上位サービスである「TOASTニュース」の下位に複数のサービスを作成する理由は次のとおりです。ユーザーには同じサービスに見えますが、内部では「ニュースメーリングサービス」と「ニュースキュレーションサービス」の重要度が異なる場合があり、発生した障害を配信する方法においても、配信担当者や配信チャンネルが異なる場合があります。このように、運営の観点から細分化して小さな規模のサービスを管理できるように、階層的なサービス構造を定義しておくと便利です。

モニタリング設定

モニタリング設定は下の3つに分けられます。

• ウェブサービスを対象とする「Webモニタリング」
• TCP/UDP/ICMPサービスを対象とする「TCPモニタリング」
• サービスで定期的に独自のジョブの成否をService Monitoring側に通知するバッチモニタリング

上段タブで「Webモニタリング」または「TCPモニタリング」「バッチモニタリング」をクリックし、特定のタブに移動してシナリオを追加することができます。シナリオ追加ボタンが有効になっていない場合は、左の「サービス一覧」領域で最下位のサービスをクリックすると、「シナリオ追加」ボタンが有効になり、シナリオを追加することができます。

それぞれのモニタリング設定について、もう少し詳しくみてみましょう。

Webモニタリング設定

まず、シナリオタイプを「API」「ブラウザ」「モジュール」のいずれかに選択する必要があります。一般的には、APIモニタリングやブラウザモニタリングを選択しますが、同じログイン機能を繰り返し設定するのが面倒な場合は「モジュール」を選択してシナリオを共有することができます。

簡単なウェブページやAPIモニタリングの事例

シナリオ名と説明を入力し、実行方法の反復周期を60秒単位で指定します。一定の反復周期でない場合は、年/月/日/時/分単位でスケジュールを直接入力することもできます。

（毎年3ヶ月ごとの1日0時5分に1回モニタリングが実行されるようにするスケジュール）

一時的なネットワークエラーによって誤検知が発生しても、もう一度モニタリングを実行してみて、失敗が繰り返される場合にのみ障害と判定させるように「許容エラー回数」を1に指定します。

最も重要な情報は「URL」と「検証タイプ」です。上述の例ではURLを入力し、検証タイプに「レスポンスコード」と「テキスト検証」を1回ずつ選択して、レスポンスコードが200で返されるか、レスポンスのJSONデータに “result”:”ok”というテキストを含んでいるかを検証するようにシナリオを作成します。

すべての作成が完了したら、下段の「テスト」ボタンをクリックしてシナリオが正常に実行されることを確認し、異常がなければ「確認」ボタンをクリックして保存します。保存が完了すると、シナリオのリストに今回新しく追加したシナリオが公開されます。

ブラウザモニタリングの事例

JavaScriptで画面をレンダリングする場合には、単にサーバーからの応答内容だけをモニタリングして正常な結果であるかを確認するのは困難です。このような場合には「シナリオタイプ」で「ブラウザ」を選択し、JavaScriptのレンダリング結果をHTMLで回答してもらい、重要な要素がうまくレンダリングされているか確認することが必要です。

「ブラウザ」は「CHROME」を選択し、「スクリプトエラー無視」と「イメージダウンロード除外」にチェックをします。JavaScriptのエラーが発生したり、一部のイメージが正しく表示されなくても、画面の主要要素がうまくレンダリングされることと、正常な機能が提供できるかは関係しないことがありますので、必要に応じてチェックボックスを選択します。

「URL」を入力し、「検証タイプ」で「テキストの検証」を選択して、「〇〇様こんにちは」と「マイニュースを表示する」というテキストが正常にレンダリングされ、表示されることを確認します。

同様に、テストしたあとに「確認」ボタンをクリックすると保存されます。

モジュールの作成

複数のサービスに複数のシナリオを作成すると、同じプロセスを踏まなければならない場合があります。たとえば、IDとパスワードを入力してログインした後に、それぞれのページに移動してそのページが正常にアクセスされるかを確認するシナリオが複数存在する場合があります。

ログインのプロセスが繰り返されますが、これをシナリオごとに作成するのはかなり面倒です。

上段の「シナリオタイプ」から「モジュール」を選択し、ログインモジュールを作成して共有しておいて、それぞれのブラウザモニタリングシナリオからログインモジュールを選択すると、面倒なログインプロセスのシナリオを繰り返し作成する必要がありません。

上記のようにログインスクリプトを実行するモジュールであらかじめ作成しておきます。「SSOログインモジュール」という名前のシナリオに保存しておけば、他のシナリオで共有して使用できます。

シナリオは他の開発者と共有する可能性が高いですが、ログインに使用されるIDとパスワードが露出されるとセキュリティ上のリスクとなります。このような場合、secret()関数で囲んでおくと、本人にはIDとパスワードが正常に表示されますが、他の開発者にはマスキング処理され「*」で表示されます。

ログインモジュールを選択し、ブラウザモニタリングのシナリオに含めることができます。その後、ログインプロセスが進行されると、このシナリオで指定したURLのページにアクセスして結果を検証できます。

TCPモニタリング設定

インターネットサービスの通信プロトコルに準拠したIPパケットを直接定義してサービスをモニタリングすることもできます。

上記のように、SMTPサービスが正常に動作するかを確認するために、IPアドレスとポート番号を指定し、下記のようにSMTPパケットを作成して送信します。通常の場合には受けることになる応答メッセージを同様に入力しておくと、検証が可能です。

16進数の値を入力するか、テキストを作成する方法で編集できます。

頻繁に使用するpingパケットを簡単に使用できるように「プロトコル」で「ICMP」を基本提供しています。「ICMP」を選択すると「転送データ」と「結果検証」を直接入力する必要がありません。

バッチモニタリングの設定

先ほど説明した「Webモニタリング」と「TCPモニタリング」が、TOAST Service Monitoringが能動的にモニタリングを実行する機能であるなら、今回紹介する「バッチモニタリング」は、ユーザーのサービスやバッチプログラムが能動的にモニタリング情報を送信して、サービス障害の有無を判断する機能といえます。

アプリキーを新規に作成し、シナリオ名と説明を入力します。ユーザーのサービスやバッチプログラムで定期的に送信するモニタリング情報に含まれるJSONデータの主なフィールドの値を指定して検証します。

上記のサンプルでは、「is_successful」フィールドの値が「yes」で「count」フィールドの値が10以上なら正常と判定します。

5分ごとにユーザーのサービスやバッチプログラムから送信されるJSONメッセージを受信しますが、定められた期限よりも少し先に到着する必要があるため、2分前に到着しても有効なメッセージであると見做します。定められた期限より遅く到着すると、正常にメッセージを受信できなかったと判断し、障害と判定します。

配信設定

モニタリングシナリオを使って障害を検知しても、配信設定がされていなければ実質的な効果はありません。障害が発生した場合、誰に知らせるか、どの通信手段を利用して障害メッセージを送信するかの設定が必要です。

「サービス管理」タブの下段にある「配信設定」領域で、配信担当者と配信チャンネルを設定できます。
「保存」ボタンをクリックして保存します。

Webフック設定

配信チャンネルとしてWebフック（webhook）を呼び出すように設定することもできますが、Webフックは「サービス管理」タブ中央の「Webフック情報」領域で設定できます。

JSONメッセージやテキストメッセージを定義して、HTTP/HTTPSプロトコルに送信できます。簡単設定を使用してSlackにメッセージを送信したり、GitHubにイシューを作成することもできます。

その他の機能

配信状況の照会および配信処理

「配信状況」タブで発生した障害のリストを照会し、障害を後続グループに配信したり、配信を停止することができます。未完了の障害は、3時間後に自動的に後続グループに配信されるため注意が必要です。

障害が発生しても一時的なエラーのため障害配信されないように配信を停止したい場合は、「配信停止」ボタンをクリックします。1次グループは障害メッセージが送信されますが、2次グループには障害メッセージが送信されません。

後続の配信グループが存在しない場合には、自動的に配信はキャンセル処理されます。

メンテナンス設定（配信停止）

一定期間障害が発生しても障害を配信しないようにメンテナンス期間を設定することができます。「Webモニタリング」などのモニタリング設定タブから「配信停止」ボタンをクリックして期間を設定できます。このサービスは対象期間中に発生する障害を配信しません。

モニタリング履歴

個別シナリオのモニタリング履歴を調べることもできます。「Webモニタリング」などのモニタリング設定タブに移動し、個々のシナリオの成功/失敗ボタンをクリックすると、モニタリング履歴を照会できます。
「検知結果」条件を「全体」から「失敗」に変更すると、モニタリングが失敗し、障害と判定された場合のみを選別して照会できます。
また、個々の履歴項目をクリックすると、どのようなサービスリソースにアクセスしているときに失敗したかがわかるデバッグ情報を確認できます。

おわりに

サービスのモニタリングは、安定したサービス運営において核心的なツールといえます。さまざまな機能を提供するTOAST Service Monitoringを活用することで、迅速に障害に対応することができ、サービスの顧客が経験する不便性を最小限に抑えることができます。

障害の原因となるサービスの単位要素を分けてモニタリング設定をしておくと、モニタリングが自動的に動作するため、サービスの開発者とオペレータの負担を軽減し、障害原因分析に役立てることができます。