DevOps & SRE

可用性の稼働時間チェック

2023年6月1日

https://storage.googleapis.com/gweb-cloudblog-publish/images/insights_2022.max-2500x2500.jpg

Google Cloud Japan Team

※この投稿は米国時間 2023 年 5 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

信頼性の高いシステムとエンドユーザーエクスペリエンスは、組織の成功に不可欠です。組織のアプリケーションにダウンタイムが発生したり、ユーザーエクスペリエンスが低下すると、ステークホルダーに価値を提供することができなくなります。

Cloud Monitoring の稼働時間チェック機能によりアプリケーションの可用性とパフォーマンスをモニタリングできます。稼働時間チェックの主な目的は、リソースの可用性とレイテンシを一定間隔でトラッキングすることです。これはシステムの「パルスチェック」に似ており、アプリケーションの可用性とレイテンシの問題をプロアクティブに検出し、サービス停止の期間とその影響を軽減する可能性があります。

また、稼働時間チェックは、計測なしで可用性のモニタリングを始めるための、非常に便利で迅速な方法となります。

この投稿では、可用性をサポートする方法として、稼働時間チェックのアラートを生成することの利点について考え、ベストプラクティスを明らかにします。

可用性とアラート

まず、いくつかの前提条件を述べ、可用性とアラートに関する用語を定義することから始めます。

可用性とは

可用性の定義は、システムが特定の時点で目的の機能を実行できるかどうかです。可用性は特定のイベントに基づいて決定する必要があります（例：「ユーザーがアイテムを購入する」、「アプリケーションがデータベースにクエリを行う」）。可用性は、アプリケーション全体の可用性、リージョンのワークロード、特定の機能、または個々のコンピューティングリソースの可用性など、複数のレベルで特定できます。

稼働時間チェックと可用性の関係性

稼働時間チェックとは、サービスやリソースのネットワーク到達性を定期的にテストすることです。稼働時間モニタリングは、エンドユーザーを模倣し、夜間や休日など、時間や季節によってトラフィックが少なくなる時間帯でも、リソースの可用性を継続的に検証します。これだけでもある程度十分ですが、可用性の全体像を把握するためには、トラフィックモニタリングで補完する必要があります。同様に、システムが外部に依存している場合、他の指標にアクセスできない場合でも、稼働時間チェックによって依存関係にある可用性の問題を示すことができます。

Google Cloud の場合、Cloud Monitoring を使用することで、数分の構成によってパブリックとプライベートの両方のリソースの稼働時間チェックを簡単に作成できます。

可用性に対してアラートを生成する方法

アラート対象のイベントは、ユーザーの満足度やアイテムの購入成功など、ビジネス上意味を持つイベントであることが理想的です。組織の目標に影響を与える可用性インシデントに対してアラートを発生させる必要があります。各アラートの関連性と意図する結果に焦点を当てることで、ノイズと偽陽性を最小限に抑える必要があります。

ノイズを回避することで、対応時間を改善し、問題の緊急性に対する全体的な信頼性を高めることができます。実際には注意を払う必要のないアラートが多発すると、オペレーターは問題を検出して対応することが難しくなります。対処できないアラートや無関係なアラートによるストレス、疲労、逆効果なコンテキストの切り替えを考えると、何に対してアラートを生成するか、なぜアラートを生成するか、論理的に考える価値があるのです。

Google Cloud Monitoring では、アラートとその通知ポリシーによって、自動化したフローをトリガーするか、または、ユーザーに通知することもできます。人の手動介入が必要なときのみ（緊急度に応じて、チケットまたはページングによって）通知するようにします。Google Cloud Monitoring では、Pub/Sub や Webhooks などの通知チャンネルは、チケットやページングのための他のツールに分割できます。

たとえば、インフラストラクチャの障害ではなく、アプリケーションとその機能の障害に対してアラートを生成するなど、システムが自動化されるほど、アラートの抽象度を上げることができます。原因ではなく症状に注目する理由や Google SRE ハンドブックで述べたとおり、私たちの目標は、ユーザーの視点からアラートを生成する状態へと徐々に移行することであり、それ以外はほとんど何もしないことです。

可用性の問題を検出するために稼働時間チェックが有効なケース

誰かが自分のリソースに手動でアクセスして動作するかどうかを確認する代わりに、公開の稼働時間チェックを活用できます。高可用性アーキテクチャを使用し、個々のリソースの障害を安全に発生させるように設計すれば、アラート戦略に基づく稼働時間チェックを、以下のようなユーザーに最も関係のあるリソースに集中させることができます。

ウェブサイトの可用性
リクエストの解決（外部ロードバランサが利用可能）
地理的可用性

これらの主要なユースケースに加えて、稼働時間は、重要だが使用頻度が低いリソースをチェックするために使用することもできます。重要なエンドポイントが 1 日に数回しかリクエストを受け取らないとしても、その時間帯は稼働している必要があるとします。このような場合、稼働時間チェックでアラートを生成すると、ユーザーや外部システムが停止を試みる前にサービスがダウンした場合に警告を出すことができます。サービスが十分なトラフィックを得るようになり、他の指標のアラートに切り替えるまで、稼働時間チェックを維持することを選択することもできます。

Google が原因ではなく症状に注目する理由で強調したように、ユーザー向けの症状に対するアラート生成には例外がいくつかあります。状況によっては、より信頼性の高いシステムに移行していない場合や、外部との依存関係で可視性が限られている場合などの理由により、（まだ）障害を安全に発生させることができない重要なリソースが存在する場合もあります。このような場合、稼働時間チェックを使って問題をプリエンプトできます。しかし、一般的には、ノイズを避けるために、できるだけ症状に対するアラートにフォーカスするべきですが、公開の稼働時間チェックは、その性質上、症状にフォーカスします。

稼働時間チェックによるアラートのベストプラクティス

稼働時間ベースのアラートを作成する場合、以下のベストプラクティスを念頭に置く必要があります。

頻度: 稼働時間チェックは間隔を空けて行われるため、その間に停止しても気づかれないことがあります。稼働時間チェックが終了した直後にリソースがダウンし、次の間隔まで障害がわからないということもあり得ます。適切な間隔はユースケースによってかなり異なるので、事前に「対応に必要な時間はどれくらいか、停止を許容できる時間はどれくらいか」を検討してください。稼働時間チェックは、最大で 60 秒に 1 回の頻度で実行できます。（チェック頻度の構成方法については、下部のリソースセクションを参照してください。）
適切な構成: 稼働時間チェックは、計測を必要とせず、サービス稼働状況の手動によるテストの代替として機能しますが、適切に構成されていない場合や、モニタリングしているリソースに断続的な問題が発生している場合は、不正確な場合があります。たとえばファイアウォールの構成によって稼働時間チェックサーバーがブロックされている場合、他の IP アドレスを持つ通常のユーザーがリソースにアクセスしても問題がないにもかかわらず、稼働時間チェックサーバーに可用性がないように見えることがあります。このような問題は、最初にチェックを作成したときや、構成の変更があったときに明らかになり、テストによって軽減できます。
ノイズの最小化: 良い計画を立てたとしても、ある程度の大きさのシステムではノイズが発生します。注意すべきは、アラートはスヌーズして絞り込むことができることです。チームが繰り返し信頼性を向上させるにつれて、アラートはユーザーへの通知から自動的な修復の開始へと移行する可能性があります。常に意識すべきなのは、このアラートは、自分の組織の価値創造能力と実際に関連性があるかという点と、関連性があるとすると、アラートに対してどのような対応を期待するのかという点です。どちらの質問にも答えがない場合、アラートをアクティブにしておくことは、より多くの妨げや混乱を生む可能性があります。

稼働時間チェックは、Google Cloud でリソースの稼働時間を確保するための貴重なツールであり、計測なしでモニタリングを始めるための最適な方法です。チームがアラートをどのように使用するかについて柔軟に対応することで、アラートがそれ自体の運用上の問題を引き起こし始める状況を回避できます。稼働時間チェックを慎重に計画し、実施することで、こうした問題のリスクを最小限に抑え、稼働時間チェックを使用するメリットを最大化できます。