SaaS が適切に実行されているかどうかを知りたいですか?これら3種類の分析指標を理解しなければなりません！

[[418169]]

この記事はWeChatの公開アカウント「Computer World」から転載したもので、著者はComputer Worldです。この記事を転載する場合は、Computer World 公式アカウントまでご連絡ください。

分析メトリックは、すべての最新の SaaS アプリケーションの中核です。 SaaS アプリケーションの実行方法、その中で実行されるタスク、目標の達成度を監視しなければ、SaaS アプリケーションを「正常に」実行することはできません。

ただし、最新のアプリケーションでは、複数の種類の分析メトリックの監視と可視性が求められます。これらの分析メトリックの有用性、価値、精度、信頼性は、測定方法、使用方法、および使用者によって大きく異なります。

分析メトリックには基本的に 3 つのカテゴリがあり、それぞれ使用例がまったく異なります。

クラスA分析指標

カテゴリー A 分析指標は、アプリケーションの重要な指標です。これらの分析メトリックがないと、アプリケーションはすぐに失敗する可能性があります。これらのメトリックは、アプリケーションの実行状況を評価し、実行状況を調整し、アプリケーションがスムーズに実行されるように動的な調整を行うために使用されます。

分析メトリックは、アプリケーションの動作環境を継続的に監視および改善するフィードバック ループの一部です。

カテゴリー A の分析メトリックの良い例は、自動スケーリングに使用されるメトリックです。このようなメトリックは、アプリケーションの負荷の変化に応じてインフラストラクチャのサイズを動的に変更し、現在の需要や予想される需要を満たすために使用されます。

よく知られている例としては、AWS Auto Scaling クラウド サービスがあります。このサービスは、特定の Amazon CloudWatch メトリクスを自動的に監視し、トリガーとしきい値を探します。特定のメトリクスが一定の基準に達すると、AWS Auto Scaling はアプリケーションの Amazon EC2 インスタンスを追加または削除することで、アプリケーションの実行に使用されるリソースを自動的に調整します。追加のリソースが必要な場合はインスタンスを追加し、リソースが不要になったことをインジケーターが示す場合はインスタンスを削除します。

AWS Auto Scaling を使用すると、任意の数の EC2 インスタンスで構成されるサービスを作成し、トラフィックと負荷の需要に基づいてサーバーを自動的に追加または削減できます。トラフィックが少ない場合、使用されるインスタンスは少なくなります。トラフィックが混雑している場合は、より多くのインスタンスが使用されます。

たとえば、AWS Auto Scaling は CloudWatch メトリックを使用して、サービスのすべてのインスタンスの平均 CPU 負荷を測定する場合があります。 CPU 負荷が一定のしきい値を超えると、AWS Auto Scaling はサービスプールに追加のサーバーを追加します。

何らかの理由でこれらの Amazon CloudWatch メトリクスが利用できないか正しくない場合、アルゴリズムは正しく機能しないことに注意してください。その結果、サービスに追加するインスタンスが多すぎてコストが無駄になったり、サービスに追加するインスタンスが少なすぎてアプリケーションの速度が低下したり、完全に失敗したりします。

明らかに、これらの指標は不可欠です。これらが利用できない、または間違っている場合、アプリケーションの動作が危険にさらされます。そのため、これらはクラス A インジケーターと呼ばれます。

AWS Elastic Load Balancing も別の例です。 AWS は、各負荷分散システムに入力される現在のトラフィック量に基づいて、特定のユースケースでトラフィック負荷分散サービスを実行するために必要なインスタンスのサイズと数を自動的に調整できます。トラフィックが増加すると、負荷分散システムは自動的に、より大きなインスタンスまたはより多くのインスタンスを使用するように切り替わります。トラフィックが減少すると、負荷分散システムは自動的に小さいインスタンスまたはより少ないインスタンスを使用するように切り替えます。これらはすべて、特定の CloudWatch メトリクスを使用する内部アルゴリズムに基づいて自動化されています。これらのメトリックが利用できないか正しくない場合、ロード バランサーは適切なサイズを設定できず、ロード バランサーのトラフィック負荷を処理する能力に影響が出る可能性があります。

クラスB分析指標

カテゴリー B の分析指標はビジネス上重要な指標ではなく、差し迫った問題の早期兆候を示したり、問題が発生したときに解決したりするために使用されます。クラス B 分析指標は、システム障害を防止したり、障害から回復したりするために重要です。

カテゴリー B のメトリックは通常、アプリケーションまたはサービスの内部操作に関する洞察を提供したり、アプリケーションまたはサービスが実行されるインフラストラクチャに関する洞察を提供したりします。この洞察をプロアクティブまたはリアクティブに活用して、アプリケーションまたはサービスの動作を改善できます。

予防的な側面では、ユーザーは、アプリケーションまたはサービスにとって通常ではない傾向を示すカテゴリ B の指標に注意を払うことができます。これらの傾向に基づいて、インジケーターを使用してアラートをトリガーし、システムに問題がないか確認する必要があることを運用チームに警告することができます。

パッシブ側では、システム障害またはパフォーマンス低下の発生時に、B インジケーターの過去の状態を調べて、障害またはパフォーマンスの問題の原因を特定し、問題を解決する方法を特定できます。このようなメトリックは、サイトの停止時や事後検証時によく使用されます。

障害発生時には、クラス B インジケーターを使用して、何が問題だったのか、どのように問題を修正すればよいのかを迅速に把握します。これらは、停止中に問題を発見するまでにかかる平均時間である平均検出時間 (MTTD) と、停止中に問題の解決策を決定するのにかかる時間である平均修復時間 (MTTR) を短縮するために使用されます。これらは両方とも、高性能 SaaS アプリケーションにとって重要な目標です。

この指標はクラス A 指標と同じ程度の重要性を持ちません。クラス A メトリックが失敗すると、アプリケーションが失敗する可能性がありますが、クラス B メトリックが失敗すると、アプリケーションは失敗しません。ただし、アプリケーションに問題があり、クラス B インジケーターが正しく機能していない場合は、問題の発見と修正に時間がかかる可能性があります。

カテゴリー B のメトリクスの例は数多くあり、AppDynamics、Datadog、Dynatrace、New Relic など多くの企業がこれらのメトリクスの生成に重点を置いています。カテゴリー B のメトリックには、Elastic や Splunk などの企業からのログ記録やその他のメトリックも含まれます。

著者: Lee Atchison は、クラウド コンピューティングとアプリケーションの近代化における思想的リーダーとして知られています。彼は、Amazon、Amazon Web Services (AWS)、New Relic、その他の最新アプリケーション組織で、製品開発、アーキテクチャ設計、スケーリング、最新化の分野で 30 年以上の経験を持っています。彼の名前は数多くの出版物に掲載されており、世界中で頻繁にゲスト講演を行っています。 Lee 氏の最新の著書は「Architecting for Scale」です。

元の URL: https://www.infoworld.com/article/3625233/the-importance-of-classifying-analytics.html