私は Web サービスを管理していますが、サービスがダウンしているかどうか、またサービスが実行する操作のいずれかが応答に時間がかかりすぎているかどうかを検出して通知することが、私の会社にとって非常に重要です。これまでは、15 分ごとにそれらのエンドポイントにランダムな操作を要求するためだけに、独立した Web アプリケーション (フロントエンドとバックエンドを含む) がありましたが、この目的のためだけに Web アプリケーション全体を保守する必要があるため、複雑であることがわかりました。また、この目的を果たす無料の Web サービスが多数あることも知っています。
ポーリング Web アプリを置き換えるために AWS Healthchecks をセットアップし、稼働時間の部分については完璧に機能していますが、応答時間の部分について質問があります。
これらすべての API ヘルスチェック サービスは、それほど複雑ではないリクエストに対応しているようです。したがって、ヘルスチェック サービスの「ステータス」エンドポイントを提供し、データベースのレイテンシなどの「OK」情報を含めるのは API の責任であるべきでしょうか。それとも、複雑なリクエストを実行するのは「ヘルスチェッカー」の責任でしょうか。どちらのアプローチがより適切でしょうか。
ありがとう！
答え1
アプリケーションのヘルスチェック パスを介してデータベースのパフォーマンスを監視することはおそらく避けてください。危険なケースが発生する場合があります。AWS 内で ASG を使用し、LB ヘルスチェックを使用して ASG がマシンをローテーションする必要があるかどうかを判断するとします。データベースの競合 (アプリケーションとは無関係) が発生し始めると、ASG はノードの削除を開始します。そのため、データベースのパフォーマンスが低下するだけでなく、ASG も枯渇します。
通常、パフォーマンスは健全性の帯域外で監視する必要があります。当社では statsd を頻繁に使用し、すべてのメトリック、アプリケーション、データベースを statsd に投入して、それに基づいてグラフ化やアラート生成を行っています。
また、規模を拡大すると、ヘルスチェックの速度も拡大することにも留意してください。1 秒間に何千ものヘルスチェック要求を受信するサービスがあり、そのそれぞれが合成の高価なクエリを実行している場合、データ レイヤーはオフラインになります。
キャッシュ レイヤーを追加すると、ロジックも複雑になります。データベースは正常だが KV キャッシュが正常でない場合、ヘルス チェック エンドポイントは何を返すべきでしょうか。
全体的に、エンドツーエンドの監視は効果的な監視戦略にとって重要ですが、データベースに流れている既存のクエリ メトリックについては、アウトオブバンド監視を強くお勧めします。これらは実際のユーザー パフォーマンスを表し、アプリケーションの健全性が実際にどのように機能しているかを定量化できるメトリックを提供します。