株式会社ROBOT PAYMENT（以下、ロボペイ）CRE課の山下です。
ロボペイのCREについての興味がありましたら、過去の記事をぜひ読んでみてください！↓
ROBOT PAYMENTのCREを考えてみた https://tech.robotpayment.co.jp/entry/2022/05/19/145953
Redashのバージョンを10にしてみて https://tech.robotpayment.co.jp/entry/2023/10/26/070000
今回はRedashのアラート機能の利用を始めたことについて話そうと思います。
今までのクエリ結果を基にしたアラート検知
CREは以前よりサポートからの問い合わせを受ける立場もあり、バグやインシデントなどの対応に関わることが多くありました。
また顧客の不安を取り除くというミッションもあるため、人一倍アラートにも敏感なチームです。
そのため、CREでは不整合なデータが発生していないか、SQLクエリ結果でのアラート検知を積極的に追加をしてきました。
その中で利用してきたのがMackerelというサービスです。
通常はサーバー監視で利用されるサービスですが、クエリ結果を投稿しその値によってアラートを流すこともできます。
ただMackerelの監視ルールはコードベースで管理しています。そのため、リリースとデプロイの作業が若干手間という課題を感じておりました。
定期クエリ実行結果に伴うアラートの検知においては、CREとしては簡易的かつ迅速に検知をリリースしたいという点で、Redashがいいのではということになりました。
Redashのアラート機能の利用を一度断念した過去
Mackerelを利用する中で一度Redashのアラート機能を活用しようと試みたことがありました。
実際にアラートを設定して運用してみたのですが、
- 安定してアラート通知が流れてこない。
- 通知されるアラートはタイトルがそのまま通知されるだけでわかりづらい。
など利用するには課題が大きかったです。
当時はまだRedashのバージョン7.4を利用しており、なんでアラートが安定しないのかの原因もわからず、
Mackerelを継続利用するという判断をしました。
V10にアップデートして久しぶりにアラートを触ってみた
Redashのアラート機能を利用することを一度断念した後、権限などの一部機能の拡張を目的としてV10へのアップデートを行いました。
（Redashのバージョンを10にしてみて）
それからしばらくしてふとアラートのことを思い出しました。もしかしたらバージョンアップもしたし上手く組んじゃないかと以前と同じようにアラートを追加し確かめてみると、スケジュール通りに安定してクエリが実行され、アラートが流れるではないですか。
それにアラートが安定しただけではなく、アラートの通知に説明文をカスタマイズして追加できるようになっていました。
クエリのスケジュール実行がなんで上手くいったのか気になって、確認したところクエリのスケジュール実行についてのバグがいくつか修正されていました。
Redash変更履歴
- スケジュールされたクエリのエラーが多すぎると、OverflowError が発生します。
- スケジュールされた実行が失敗すると、クエリの「updated_at」のタイムスタンプが変更されます。
- refresh_queries ジョブで、スケジュールオブジェクトで不正なクエリが含まれている場合に中断する問題を修正しました。
上記もうまくいくようになった理由だとは思いますが、よくよく考えてみるとアップデートの過程でメモリやストレージを拡張した経緯がありました。
もしかするとメモリやストレージの原因で単純にスケジュール実行が失敗していただけだったのかもしれません。
さらに、V8よりクエリオーナーに対してスケジュール実行の失敗が通知できるようになりました！
これで万が一スケジュール実行の失敗でアラートが流れなくても安心です！
といったように、断念した理由も解消されたことでRedashのアラート機能を本格的に使い始めることにしました！
Redashのアラートを使い始めてやはりアップデート前に比べて便利になったなと感じます。
ということでせっかくなのでアラートで便利になったなと感じる点について紹介したいと思います。
V7からV10へのアップデートでのアラート機能の変更点
個人的にアラート機能の変更点で嬉しかったことは以下になります。
1. アラートメッセージのカスタマイズ
2. アラートのミュート機能
3. アラート設定画面のUI/UX改善
1. アラートメッセージのカスタマイズ
前述で少し触れていますが、まずV10へのアップデートで一番嬉しかったのがアラートのメッセージをカスタマイズできるようになったことです。
今までは、アラートタイトルの一文だけが通知され、どんなアラートなのかがわかりづらくなっていました。
しかし、メッセージの説明文をカスタマイズできるようになり、アラート通知時の件名もアラートのタイトルとは別に設定できるようになっています。
これにより、対象のアラートを追加した経緯やアラート検知後の対応などを通知文に細かく示せるようになりました。
2. アラートのミュート機能
次に地味に嬉しいのは、一時的に止めたいアラートなどを削除せずミュートにできる機能の追加です。
今までは、アラートを一時的に通知したくない時はアラートごと削除する必要があり、その後必要となっても再度1から作成しなくてはいけませんでした。
しかし、ミュート機能が追加されたことによって、狼アラートになってしまっているなどの理由で一時的に止めたいアラートを削除せずに通知を止めることができるようになりました。
3. アラート設定画面におけるUI/UXの改善
UI/UXも以前と比べわかりやすくなっていました。
アラートの閾値の設定が、「greater than」などの言葉での設定から「>」などの等号/不等号での設定になりわかりやすくなっています。
→
また、アラートの再通知設定に関しても設定しやすくなりました。
今までは、ステータスが「triggered」から変更がない場合の通知の頻度を秒数設定するのみでした。
しかしV9以降では、受信頻度を3タイプから選べるようになっています。
→
具体的には以下の選択肢から選べるようになっています。
- ステータスが「OK」から「triggered」に変更した時のみ通知
→V8以前では再通知の秒数設定をしないことで同様の挙動
- クエリ実行で「triggered」となった場合全てで通知
→V8以前ではクエリ実行の頻度と秒数を合わせることで同様の挙動
- クエリ実行で「triggered」となった場合で設定した時間の間隔が経過している場合に通知（秒〜週の単位で設定可能）
→V8以前では秒数でのみ設定
まとめ
アラート機能が進化していることに気づかず、V10へのアップデート後すぐにアラート機能について確認をしていなかったのですが、今回触ってみてもったいなかったなと感じました。
リリース、デプロイなどの作業が必要になると、頻繁に追加することはできないですし腰も重くなります。
その点Redashであれば、RedashであればUIからアラートをスピーディーにかつ気軽に追加修正できます。
リアルタイムにすぐ修正できるので、仮に余分な範囲まで検知して狼アラートになったとしても気づいた時に修正ができ、
ハードルも下がるので気づいた人が気づいた時に追加するという運用ができるようになりました。
また、エンジニア以外もこのアラートを活用できます。
バージョンアップをした時に確認しておけばよかったという反省はありますが、これでまたCREの目指す姿にまた一歩近づいた気がします！
引き続きCREとして顧客の不安を取り除く活動をしていきたいです！
We are hiring！！
ROBOT PAYMENTでは一緒に働く仲間を募集しています!!!
speakerdeck.com
www.robotpayment.co.jp
