Launching LivePing (日本語)
Cron、Unix系統のオペレーティング・システムならどれでも内蔵されている定時実行のスケジュール管理システム。
ソフトウェアの会社なら、必ず使ってると言っても過言ではない普遍的な素晴らしい技術です。しかし、実行中にエラーが発生した時はいったい何が起こるんでしょうか。。？
Silent Failure
ここ数ヶ月は、自分のためのサイドプロジェクトに取り掛かっていて、そしてできたものをしばらく使っていました。ある程度公開しても大丈夫な仕様になりましたので、ぜひ見てみてください。
LivePingは一言で言うと死活監視のためのシステムです。ただ、死活監視と言っても大きくは、
- 外部ネットワークからチェックできるUptime Monitoring
- ネットワークからそもそもアクセスできない代わりに、自身がシステムを通知するHeartbeat Monitoring
の２種類に分かれます。LivePingは後者のHeartbeat Monitoring（直訳だと鼓動監視？）のシステムです。
さて、Cronってそこまで重要なものでしょうか？実は、TwilioのCEOが半冗談でツィートしたように、少なくともアメリカのソフトウェア業界を裏で支えてる重要な技術の一つです。しかし、どんな技術にも長所と短所があります。そしてCronも例外ではありません。利用したことのある人なら一度は考えたことがあるのではないでしょうか？
もし実行時に何か問題が発生した場合はどうやってそれを認知する？
Cronを筆頭に、オフラインで実行するソフトウェアは基本的に、全く音を立てずに、静かに障害を起こします。今頭に浮かぶだけでも、
- データベースのバックアップ失敗
- 外部向けのSSL/TLSの証明書の自動更新の失敗により、後日サービス全体へのアクセス障害が発生
- 再訓練された機械学習のモデルがデプロイされず、パーソナライズのサービスが日に日に不備を蓄積
- 社内やサービス間のTLS証明書の更新失敗により、サービス間の通信に障害が発生
- 毎月に顧客のために自動で生成されるレポートが生成されずに、クレームに繋がる
以上の例以外にも他に多くの問題を経験しました。
そして、畳み掛けるかのように、時には問題が発覚するのは数カ月先ということも珍しくありません。
Attempts in the past
当然問題を認知しているなら、それを解決しようとします。過去には何度か社内ツールとしてこの問題に対応してきました。そして、毎度同じように、メンテナンスの優先順位という課題にぶつかるのです。
監視システムである以上、稼働時間が短かったり、簡単に落ちていては意味がありませんが、片手間で簡単にできるものでもありません。少なくとも社内で唯一のSRE、あるいは数少ないSREの場合、障害対応以外にも対応しなければならないものや自動化させるものが他に大量にある中で、どうしても社内ツールの対応する優先順位は下がってしまうのです。
ならば社内ツールを担当するチームが存在するほどの規模の会社なら解決する問題なのか？それが面白いことに、意外とそうでもないことが多いのです。ツールのチームが担当する範囲のものは多岐に渡り、同じ社内ツールでも、エンジニアたちが直接影響されやすい、言語系フレームワークやCI/CDのような継続開発をサポートするツールに意識が行きやすく、Heartbeat Monitoringのシステムへの注意がどうしても後回しになってしまうことが多いです。
また、システムの担当や所有権も一つの問題になりえます。簡単に言えば、もし現在担当してるエンジニアが会社を去った場合、誰がシステムを引き継ぐのかという問題です。シリコンバレーは特に人材流動の激しい地域です。それによって多くの会社ではシステム構築者がその会社を去った後に、所有権が有耶無耶のシステムが数多くあり、誰も触ろうとせず、その上エンジニアの多くはドキュメンテーションを書きたがらないため、現実と認識のズレが発生し、知らない合間に会社のソフトウェアサービスが静かに危機的な状況に陥ることも珍しくありません。
そして最後に、「監視者を誰が監視する？」という問題も付いてきます。香ばしくなってきましたね？
じゃあ外部サービスを使えばいいじゃないか？と思うかもしれませんが、当然すでに試しました。最低限に必要な機能は確かに備えていますが、最低限ということは、つまり追加機能は結局自分が実装することになるので、別に大して仕事量が減ることもありませんでした。
Problems LivePing solves (for now)
現時点のLivePingはまず、僕個人の問題を解決するために作っています。一つは上記のような優先順位や会社を去った後の劣化の問題と、もう一つは自分が何度も何度も同じようなシステムを作る羽目になる問題です。
そして、これは問題ではないですが、僕が得意とするスケールとシステムの信頼性の一部を雇用関係になることなく、多くの人に提供できるかもしれません。
さて、ここで一旦僕個人の問題はさておき、LivePingはどのような問題が解決できるのか、少しお見せしましょう。
- サイレント障害の防止
- Cronが仕事をしていなかった場合のためのアラート
- データベースバックアップやTLS証明書の更新がちゃんと走ったかどうかのチェック
他に使える定時実行の例としては、
- データ同期のパイプライン
- データの集約やデータの廃棄
- システムの脆弱性のチェック
などがあります。当然、何かしら定時実行する必要なものであれば、基本的に対応できると思っていただいて大丈夫です。
現在のLivePingのアラートはEmailとSlackのみ対応していますが、これからどんどん機能と他のアラート先を実装していくつもりです。
短期のロードマップとしては、
- PagerDutyのアラート
- Webhookの対応
- アラートを飛ばす前の猶予期間
- 一時的なアラートのミュート
- APIアクセスとドキュメント
- OAuth2による認証
これ以外にもまだまだいっぱい機能を追加する予定です。
上記の機能の実装以外にもシステムの信頼性をあげるための自動化も全力で取り組んでおります。利用された際にはぜひフィードバックをいただけたら幸いです。また、希望する機能やアラート先がある場合はFeature requestを提出してください。各種のフォームや連絡情報はContactページに掲載しております。
簡単にお試しができるように、LivePingは無料で5つのPingを提供しております。有料プランもすべて14日の試用期間を設けております。詳細はPricingページを参照してください。
What’s next?
短期的には、まず僕が過去にぶつかった多くの問題を解決するための機能を追加していく予定です。
しかし、長期的には会社やチームとともに成長できるシステムにしていきたいです。最初はもしかしたら、ただひと握りのCronを監視するために。次第にはそれぞれのチームで使い分け、アクセス制御やダッシュボードの提供。そして究極的にはサービスとともに監視を自動化していく。
Monitoring（監視）は、あくまでObservability（可観測性）の一部に過ぎません。監視の中でもサービスの死活監視と、分散されたスケジュールシステムだと対応も違ってきます。故にPrometheusにもHeartbeat Monitoringのために、Push Gatewayという副次的な機能が備えているのです。
もしPrometheusをすでに利用されているのであれば、Heartbeat MonitoringもそのままPrometheusを利用し続けることをお勧めします。しかし、もし運用してない、あるいは社内でそのようなチームを作る余裕がない場合は、ぜひLivePingを一度試してみてください！
質問、または単に話してみたいだけでも、遠慮なく連絡をください！
最後まで読んでくれてありがとうございます！
