はじめに

Workatoは、コンテナベースのクラウドネイティブで非常に可用性の高いインフラの上でサービスが提供されており、高い可用性は確保されていますが、そのような環境下であっても、Workatoサービスの低レイヤに存在するクラウドサービスプロバイダのハードウェアやネットワーク障害等に起因する、偶発的なサービス障害が発生することはあります。

これにより、例えばある時刻に実行予定であった処理が遅延あるいは停止する、実行中の処理が中断する、Webhookエンドポイントに対するリクエストが処理できない等の問題が発生する場合があります。

ユーザー側においては、再現可能な（再実行でやり直しのきく）アプリ間連携レシピを作成する、障害が発生した際にいち早く気づいて対処できるような仕組みを用意することで、偶発的なサービス障害に対するレジリエンスを高めることは可能ですが、Webhook（＝リアルタイムトリガー）に関してはサービス障害発生時においてはアプリケーションから受けたリクエストを処理できず、かつWorkato上にはその履歴も残りません。

アプリケーションによってはリトライにより処理を再試行する、Webhookリクエストの成功・失敗をログに記録する、Webhookリクエスト失敗時に管理者へ通知する等、Webhookリクエスト時の障害に対応する機能を提供している場合はありますが、そのような機能を持たない（リクエスト投げっぱなしで結果を何も残さない）アプリケーションも存在します。お使いのアプリケーションが後者に該当する場合は、いつ障害が発生したかを全く気づけないため、Workato外で何らか障害を検知するための仕組みを用意する必要があります。

StatusCakeでWorkatoのWebhookを死活監視

WorkatoのWebhookの障害を検知する最も手軽な方法として、外形監視ツールによるWorkatoのWebhook URLの監視が挙げられます。

この方法は、特定のレシピのWebhookトリガーやリアルタイムトリガーを監視するものではありませんが、そのワークスペースのWebhook機能に発生した障害を検出する方法としては有効です。

以下ではStatusCakeというSaaS型の外形監視サービスを例に、WorkatoのWebhookの死活監視の手順を説明します。なお、StatusCakeの設定および通知先（Slack）の設定、Workatoのレシピ作成方法などの詳細についてはここでは触れません。

Workato監視用レシピを作成する

Webhookを監視するために、最初にWebhook監視用のレシピを作成します。

監視用のレシピは、以下の通りGETリクエストに対応したWebhookトリガーと、Stopアクションで構成されています。このレシピは、タスクにカウントされるアクションが存在しないため、タスクを消費することなく運用することが可能です。

なお、ここで出力されたWebhookのURLは後から必要になりますので、コピーしてテキストエディタ等に記録しておきます。

StatusCakeに監視を追加する

StatusCakeに先ほどコピーしたWebhookのURLを貼付し、監視を追加します。

動作確認

Webhook監視用のレシピをStart/Stopすることで、指定された通知先に監視状況（Up/Down）が通知され、死活監視の動作を確認することができます。

おわりに

今回は外形監視ツールによるWorkato Webhookの死活監視をご紹介しました。外形監視ツールはStatusCakeを利用しましたが、Uptime RobotやMackerel, Zabbixなど他の外形監視ツールでも結構ですし、Google Apps ScriptやAWS Lambda,LinuxのCronやWindowsのタスクスケジューラで監視スクリプト作成し定期実行する方法でも同様の運用が可能です。

Workatoのリアルタイムトリガー（Webhook）の監視を検討されている方の参考になりましたら幸いです。