【CI・CD戦略編その6】アプリケーションレベルヘルスチェック

ネットワークサービス部のid:a8544です。

連載19回目の今回は、わたしたちの開発するシステムに備わるヘルスチェック（正常性確認）機能についてご紹介します。

以前の記事で、インフラに着目した間接的なヘルスチェックについてご紹介しました。わたしたちのシステムには、それとは別に、アプリケーションが自身のヘルスチェックを行う機能もあります。

🌐 システムが依存する外部の系

わたしたちが開発している「プライベートブリッジのバックエンド」の機能は、 Pythonのコードが動作するPython処理系以外の外部の系にも依存しています。たとえば、

データベース管理システム (DBMS)
メッセージキュー
インターネット越しに利用する社内・社外のサービスのAPI

があります。

これら外部の系とのやりとりがうまくいかないと、リクエストを正しく処理できず、場合によってはサービスの障害につながります。

👨‍⚕️ なぜヘルスチェックをするのか

わたしたちは、システムの運用を通じて前述のような外部の系との通信に起因する障害を過去に経験しており、そのたびにその個別具体的な問題に対する対処をしてきました。

しかし、障害として問題が発覚してから原因を修正するより、障害につながりうる異常を早期に検知し、サービスへ影響する前に対処するほうがよいことは明らかです。

わたしたちの過去の経験にあったような異常を検知するためには、外部から観測しにくいアプリケーションの内部状態を観測する必要がありました。例えば、「アプリケーションとDBMSとの接続状況」は外部からは観測しにくいです。下図のように、あるコンテナ中のあるプロセスがもつコネクションプール中のコネクションの一つ一つまで、それが正常か外部から確認するのは困難です。

コンテナ内部に複数のプロセスが存在し、そのプロセスの健全性を外部から確認する様子を示した画像。プロセスはコンテナに内包されているさまが描かれている。 — コンテナ内のプロセスの状態を観測するのは難しい

ほかに検知が困難だった例として、アプリケーションから外部APIへの通信経路中の異常（プロキシサーバ等）があります。アプリケーションが実際に使う通信経路で通信を試行しなければ、その経路中にある問題には気づくことができません。さらには、外部API自体に障害が発生していることもあり、この場合も実際に通信せずに気づくことは困難です。

この種の監視を、外部に存在する監視基盤 だけで 実現するのは困難だと考えられました。

そこでわたしたちは、外部の系へのアクセスを含めた、実際のリクエスト処理に近い形の動作をチェックするヘルスチェックを、 アプリケーション自体のAPIの一つとして 実装することにしました。

アプリケーションだけで完結する単純なエコーのようなチェックに比べ、ヘルスチェックの実装は複雑になりますが、アプリケーションの内部からしか分からない、より複雑な問題を実際のリクエストを処理する前に検知できるようになります。また、APIの一部として実装することで、外部からの定期的な監視が容易になります。

🧱 ヘルスチェックの構成・実装

わたしたちの開発しているバックエンドは、モジュラーモノリスの構成をとっています。そのため、ヘルスチェックも各モジュールごとに実装されています。

各モジュールのヘルスチェックでは、複数のヘルスチェック項目についてチェックを実施し、すべての項目について成功すれば成功を、一つでも失敗すれば失敗とします。

加えて、モジュールごとの結果を集約し、その結果を外部に公開するためのエンドポイントが用意されています。この集約エンドポイントへアクセスするたびに、ヘルスチェックが行われます。このエンドポイントでは、各モジュールでのヘルスチェック結果がすべて成功すれば成功を、一つでも失敗すれば失敗とします。これにより、集約エンドポイントで「成功」が返ることをチェックするだけで、全てのモジュールの全ての項目で成功したことが確認できるようになっています。

ヘルスチェックの動作を示した画像。モジュールが複数存在し、さらにそれらのヘルスチェック結果を集約するエンドポイントがある。さらに、集約エンドポイントを利用するZabbixがシステムの外部に置かれている。 — ヘルスチェックの動作

各項目の実装

データベースに関する項目では、実際のリクエスト処理と同様の方法でトランザクションを開始し、値が読み書きできることを確認します。
メッセージキューに関する項目では、テスト用に一時的に作成したキューについて、実際のリクエスト処理と同様の方法でメッセージを発行し、正しくワーカーが処理することを確認します。メッセージの流れは、可能な限り実際の処理を模倣しています。
- 具体的には、下図のようにワーカー間でヘルスチェック用のメッセージをやりとりさせ、もとのWeb API ワーカーに戻ってくることを確認します。これにより、各ワーカーが実際にメッセージを送受信可能な状態にあることが確認できます。
  メッセージキューのヘルスチェックの動作
外部APIに関する項目では、インターネット経由で利用するAPIについて、実際のリクエスト処理と同様の方法（使用するプロキシ、リトライ処理等）でリクエストを行います。この際利用するAPIは、例えばSlack APIにあるテスト用エンドポイントのように、テスト用のものを使います。

🔎 ヘルスチェックを活用した監視

わたしたちが使っている監視基盤であるZabbixからこの集約エンドポイントに定期的にアクセスして、その結果を監視しています。

このヘルスチェックを定期的に実行する運用を始めてから、これまで気付いていなかった、システムに潜在する問題に気付くことができています。例えば、コンテナやワーカープロセスは正常に動作しているように見えて、実際にはメッセージキューからのメッセージの取得ができなくなっているワーカーが存在しうる問題がありました。このような問題は、実際にメッセージをエンキュー・デキューする過程を踏まないと気付きにくいものです。

また、依存する外部サービスのAPIに障害が発生した際にも、実際のリクエストをまたずに気付くことができ、わたしたちのシステムの正常な運用に必要な対応をすばやくとることができるようになりました。

まとめ

わたしたちのシステムに実装されている、アプリケーションレベルのヘルスチェックについてご紹介しました。

実際のユースケースにより近い内容のチェックを実装することで、外部からは気付きにくい異常に気づきやすくなります。その際には、アプリケーション側でヘルスチェックを実装することが有効です。またヘルスチェックの実施・結果取得を外部から利用しやすい方法で提供することで、監視基盤との統合がはかりやすくなります。

以前ご紹介したインフラ面のチェックと合わせて、ヘルスチェックが充実していることは、システムの運用をより自信をもって（安心して）行う助けになっています。

次回からは、テーマを変えて「システム開発戦略編」と題して、わたしたちがシステム開発全体を通して取っている戦略をご紹介していきます。お楽しみに。