APIモニタリング：指標、課題、ベストプラクティス

今日の分散型アプリケーションがますます普及する中で、アプリケーションプログラミングインターフェース（API）は、システム間の通信と連携の要となっています。かつてはモノリシックアプリケーションへの入り口と考えられていたAPIは、今日では進化を遂げ、単一アプリケーション内のマイクロサービス間のリアルタイム通信を可能にし、インターネットを介したサードパーティサービスプロバイダー間のデータ交換を容易にしています。

APIモニタリングとは、APIの信頼性、可用性、および全体的なパフォーマンスを確保するために、APIのパフォーマンスと動作を綿密に監視する手法です。これは、質の高いユーザーエクスペリエンスを提供し、ソフトウェアシステムの整合性を維持する上で不可欠なステップです。 

この記事では、APIモニタリングの重要性について解説し、モニタリング指標、その実装方法、および測定手法についてより深く理解していただけるように説明します。応答時間、エラー率、飽和度などの指標に注目することで、APIを積極的に管理し、問題を特定し、深刻化する前に適切に対処することができます。それでは、詳しく見ていきましょう。

主要なAPI監視概念の概要

主要なAPI監視指標

以下に、API監視における重要な指標をいくつか示します。

応答時間

応答時間とは、APIがリクエストを処理して応答を返すまでにかかる時間の尺度です。応答時間が速いほど、ユーザーエクスペリエンスが向上し、システムの信頼性が維持されます。応答時間には、以下のようなさまざまな側面があります。 

特定のAPIに必要な応答時間の具体的な要件は、ユースケースによって異なります。例えば、ペースメーカーのような医療機器は、厳格なリアルタイム要件を満たさなければなりません。遅延が発生すると、患者の健康に悪影響を及ぼす可能性があります。一方、月次財務報告のような他のアプリケーションは、要件がそれほど厳しくなく、リアルタイム応答に依存しません。 

いずれの場合も、システムの信頼性を確保するためには、APIの応答を監視することが重要です。APIの要件と使用事例の両方が、リアルタイム監視（ライブトラフィックによる監視）を実施するか、トラフィックがAPIインフラストラクチャを通過した後の履歴監視を実施するかの決定に影響を与えます。

エラー率

エラー率とは、APIによって生成された応答総数に対する、誤った応答の割合を表します。エラー率が高いと、ユーザーの信頼、アプリケーションの安定性、そして成長に悪影響を及ぼすため、エラー率を可能な限り低減することが重要です。 

最もよくあるエラーは以下の3つのカテゴリーに分類されますが、例外もあるかもしれません。 

• データエラー、
• ネットワークエラー、 
• 認証エラー。 

各エラーのコードとその解釈方法を理解することは、エラーの原因と解決方法を特定する上で不可欠です。一般的なエラーの種類とその関連カテゴリについては、以下の表を参照してください。

レイテンシ

レイテンシとは、リクエストが開始されてから対応するレスポンスが受信されるまでの時間遅延を測定するものです。これは応答時間に大きな影響を与え、リアルタイムのデータ配信にとって非常に重要です。

遅延には多くの要因が影響します。例えば、複数のインターネットサービスプロバイダのネットワークを経由するVPN接続は遅延を引き起こす可能性があり、エンドツーエンドのトランザクションパスの各セグメントを監視しないと診断が困難です。

通常、APIが複雑化するにつれて、処理ステップとデータ量が増えるため、レイテンシも増加します。APIのアーキテクチャを拡張する際には、テスト駆動開発を活用し、早期にレイテンシを削減することが不可欠です。

スループット

スループットとは、APIが一定時間内に処理できるリクエスト数を定量化したものです。スループットは応答時間にも大きな影響を与えます。最適なスループットを維持することは、ユーザーのニーズを満たし、高負荷時におけるボトルネックを防ぐために不可欠です。

レート制限

レート制限は、APIの監視とセキュリティ確保において考慮すべき重要な指標です。レート制限とは、単一のクライアントがAPIに対して実行できるリクエスト数を制御する仕組みです。1秒あたりのリクエスト数を制限することで、悪意のあるユーザーによる不正利用を防ぐことができます。また、ハッカーがAPIアーキテクチャを調査する機会を制限することで、パスゲーミング攻撃などの攻撃を軽減することもできます。

利用状況

可用性は、API監視において不可欠な指標です。これは、APIが稼働状態を維持し、アクセス可能な状態にある時間の割合を示します。APIの高い可用性を維持することは、ユーザーからの信頼を築き、アプリケーションやサービスの評判を高める上で重要です。

飽和

APIのリソースが完全に利用された状態が飽和状態です。飽和状態は応答時間と可用性の両方に悪影響を及ぼす可能性があります。APIが飽和状態に近づくにつれて、リクエストをキューに格納したり、完全に拒否したりする必要が生じるため、応答時間が長くなります。 

理想的には、運用チームは負荷テストを実施し、システムが限界に達するまで合成エミュレートトランザクションを増やしていくことで、事前に飽和点を特定します。そして、監視ツールで1分あたりのトランザクション数（TPM）のしきい値を設定し、システムがピークに近づいたときにアラートを発するようにします。

PythonでのAPI監視の例 

API監視には、以下のような複数のPythonオープンソースライブラリを使用できます。 Requests、Locust、GRErequests、Pyperfect、Requests-Mock、Flask-Limiter、 (NAIST) と Djangoのレート制限さらに、サービスとしてのソフトウェア（SaaS）ツールなど LogicMonitor に準拠する オープンテレメトリ フレームワークを活用することで、ベンダーロックインを防ぎ、オープンソースプロジェクトに基づいたAPI監視ツールのセットアップとメンテナンスにかかる時間を節約できます。 

API監視の具体的な実装方法は、APIのニーズとアーキテクチャによって異なります。以下に、上記で説明した主要なメトリクスの一部を監視するPythonの例を示します。この実装には、オープンソースライブラリであるRequestsを使用しています。

import requests
import time

# API endpoint for fictional coffee shop website
api_url = "https://GreatfulGrounds.com/products"

# Number of requests to make
num_requests = 20

# Initialize variables for tracking metrics
total_response_time = 0
error_count = 0
successful_requests = 0

# Loop to make API requests
for _ in range(num_requests):
    start_time = time.time()
    response = requests.get(api_url)
    end_time = time.time()

    # Calculate response time
    response_time = end_time - start_time
    total_response_time += response_time

    # Check for errors
    if response.status_code != 200:
        error_count += 1
    else:
        successful_requests += 1

# Calculate average response time
average_response_time = total_response_time / num_requests

# Calculate error rate
error_rate = (error_count / num_requests) * 100

# Calculate throughput
throughput = num_requests / total_response_time

# Calculate availability
availability = (successful_requests / num_requests) * 100

# Print metrics
print(f"Average Response Time: {average_response_time:.4f} seconds")
print(f"Error Rate: {error_rate:.2f}%")
print(f"Throughput: {throughput:.2f} requests per second")
print(f"Availability: {availability:.2f}%")

オープンソースソリューションには限界があります。ダッシュボード、レポート、アラートなどの機能を統合ソリューションの一部として提供し、DNS、CDN、インターネットサービスプロバイダなど、エンドツーエンドのトランザクションパスに関わるサードパーティサービスの監視も含むオブザーバビリティソリューションを利用する方が望ましいでしょう。 

もう一つの重要な機能は、リアルユーザーモニタリング（RUM）と合成モニタリングの両方を通じてエンドユーザーエクスペリエンスを監視することです。これらを組み合わせることで、ユーザーがアプリケーションのUIで実際にどのような体験をしているかを可視化し、誰もアプリケーションを積極的に使用していない場合でも重要なトランザクションを検証できます。 

OpenTelemetryフレームワークなどのオープンスタンダードを活用することで、これらのプラットフォームは、複数のプログラミング言語に対応したコミュニティが維持管理する計測機能や、テレメトリデータを受信、処理、1つまたは複数のバックエンドにエクスポートする柔軟なコレクターを利用できます。これにより、チームはベンダーロックインを回避しながら、統合ソリューションのメリットを享受できます。

アーキテクチャ関連のAPI監視の課題

APIアーキテクチャは非常に多様であり、新しい技術の出現に伴い拡大し続けています。現在最も一般的なアーキテクチャは、モノリシック、マイクロサービス、サーバーレス、REST、そしてGraphQL APIです。それぞれのアーキテクチャには、長所と短所があります。 

モノリシック vs. マイクロサービス

モノリシックアーキテクチャは、単一の自己完結型システムで構成されます。そのシンプルさゆえに監視は容易になりますが、アップグレードや稼働時間の管理は困難を伴います。モノリシックAPIの一部に障害が発生すると、API全体が停止してしまいます。

対照的に、マイクロサービスアーキテクチャは、独立した小さなサービスの集合体で構成され、大規模かつ中断のない可用性を必要とするアプリケーションのリファレンスアーキテクチャとして認識されています。この設計は、モノリシックシステムと比較して、より高い柔軟性と水平スケーラビリティを提供します。ただし、ローカルAPIを介して通信する相互依存するマイクロサービスの複雑なメッシュのため、監視はより煩雑になります。APIは通常、コンテナ化され、オーケストレーションされます。 Kubernetes サービスメッシュフレームワークなど イスティオモノリシックからマイクロサービスへの移行については、こちらで詳しく学ぶことができます。 記事. 

サーバレス

サーバーレスアーキテクチャは、GCPなどのクラウドプロバイダーを使用します。 AWSAPIのホスティングと管理にはAzureを使用します。このアプローチにより、リソース管理が効率化され、社内人員の必要性も軽減されます。

これらの利点がある一方で、いくつかの欠点もあります。このシナリオでは、監視がより複雑になります。

• サーバーへの直接アクセスができない
• 動的スケーリングによるリソース使用量の絶え間ない変動
• クラウドプラットフォームに潜む複雑な構造のため、システムのデバッグに課題が生じる。

REST と GraphQL

RESTとGraphQLの選択は、上述のアプリケーションアーキテクチャの選択肢とは無関係です。REST APIは、業界での長い歴史、シンプルなリクエスト/レスポンスモデル、そして明確に定義された業界標準への準拠といった理由から、APIアーキテクチャの定番として定着しています。また、開発と監視を容易にするためのオープンソースおよびクローズドソースのツールも豊富に用意されています。しかし、エンドポイントが多数存在する大規模なシステムになる可能性があり、監視上の課題も生じます。 

API設計に比較的新しく加わったGraphQLは、近年注目を集めています。その独自のデータ取得方法により、クライアントはデータ要求を非常に細かく制御できます。しかし、これはデータ要求の増加につながり、多種多様な要求を監視する上で新たな課題を生み出します。

API監視に関する推奨ベストプラクティス

API監視のための戦略計画は、API開発の前、開発中、開発後に検討する必要があります。API監視計画を策定する際に考慮すべき戦略をいくつかご紹介します。

適切な工具を選択する

ユースケース、アーキテクチャ、技術スタック、そして予算に最適なツールを選択する必要があります。ここでは、注文管理アプリとグローバルサプライヤー管理アプリという2つのシナリオを検証してみましょう。注文管理アプリは主に、特別な高度な顧客注文に使用されます。アプリがシンプルでユーザーベースも限られているため、アプリをサポートするAPIを監視するには、ターゲット監視で十分です。 

一方、グローバルサプライヤーアプリは、6大陸にわたる数千ものサプライヤーパートナーにサービスを提供し、原材料や完成品を目的地までタイムリーに配送することを保証しています。アプリのアーキテクチャがより複雑で、対象となるユーザー数もはるかに多いため、包括的なモニタリングが不可欠です。サプライヤーアプリに不具合が発生すれば、世界中の関係者にドミノ効果をもたらす可能性があります。 

合成監視は、2番目の例で示したユースケースのように、グローバルAPIを監視するための包括的な計画において不可欠なツールです。その核となる価値は、多様なシナリオをシミュレートし、問題が発生する前に、そして複数の大陸やサービスプロバイダーに影響を及ぼす前に、積極的に対処できる点にあります。 

監視頻度と間隔を決定する 

リアルタイム監視と定期監視のどちらを選択するかは、APIのユースケース、データの鮮度に関する要件、サービスレベル契約、そしてAPIが組織の基本的なニーズにとってどれほど重要かに基づいて決定する必要があります。例えば、医療機器をサポートするAPIは、リアルタイムでのデータ可用性を必要とします。重大な結果を招く可能性があるため、遅延の余地はほとんどありません。したがって、ペースメーカーAPIや類似技術のAPI監視戦略では、分単位や時間単位ではなく、秒単位で測定されるリアルタイム監視が求められます。

一方、財務予測をサポートする小売アプリケーションの財務報告について考えてみましょう。APIは、一日の終わりに在庫数と売上高を報告します。APIの結果の正確性については明確なビジネス要件がありますが、緊急性はそれほど高くありません。この場合、APIの監視は、ユーザーがアクセスする必要があるときにAPIがまだ稼働していることを確認するための日々のチェックだけで十分かもしれません。 

トレースを取り入れる

メトリクスはAPIモニタリングの基本ですが、マイクロサービスとサードパーティAPIが大規模に連携する環境では、トランザクショントレースもほぼ必須となっています。マイクロサービスアーキテクチャは、運用チームが単一障害点を発生させることなくアプリケーションを拡張することを可能にし、サードパーティAPIは企業境界を越えた効率的な通信を可能にしますが、その価値は複雑さという代償を伴います。数十のマイクロサービスとサードパーティAPIで構成される環境でパフォーマンス低下をトラブルシューティングするには、トランザクショントレースなしでは複雑すぎるため、APIモニタリングに使用するツールにこの機能が含まれていることを確認してください。分散トレーシングの概念については、こちらをお読みください。 記事.

OpenTelemetryフレームワークに依存する 

オープンスタンダードやフレームワークなど オープンテレメトリ このフレームワークは、顧客とベンダー双方にメリットをもたらします。顧客は独自の技術への依存を回避できるため、ベンダーは複数のプログラミング言語をサポートし、トレース、ログ記録、メトリクス機能を提供することで、研究開発コストを最小限に抑えることができます。開発コストの削減は、より競争力のある価格設定につながり、結果として顧客にも利益をもたらします。エンドユーザーにとって、APIコードの計測に使用するライブラリを変更することなくベンダーを変更できるという安心感は、非常に大きな価値があります。

アラートをカスタマイズする

APIのアラートをカスタマイズすることは、APIの信頼性を維持し、ビジネス上の重要な要件を満たすための強力なツールとなります。APIを使用するアプリケーションの種類は多岐にわたり、それぞれに異なるニーズがあるため、アラートをカスタマイズする機会も数多く存在します。ビジネスニーズにとって最も重要な指標に対して、適切なしきい値を設定してアラートを設定しましょう。 

例えば、消費者に直接販売を行うエネルギー関連アプリを考えてみましょう。アプリをサポートするAPIは、応答時間、決済処理の成功率、決済ゲートウェイの稼働時間などのアラートを発信するように設定できます。各アラートには、ビジネスニーズに合わせた独自のしきい値を設定できます。例えば、アプリの応答時間が2秒を超えた場合にアラートを発信するといった設定が可能です。戦略的なアラート設定により、応答時間の長さが原因で潜在顧客を失うことを防ぐことができます。 

アラートが設定されると、それによってさらなる自動化がトリガーされ、問題が解決されます。

テストプロセスを文書化してください

製品やサービスの最適化の機会を見つけるために、テストプロセス全体を文書化してください。また、APIのライフサイクル全体を通して、反復的にテストを継続してください。最も重要なのは、APIに関する一般的な問題を特定して解決するための、会社の標準運用手順をまとめた中央文書またはランブックを作成することです。文書やランブックを整理する際には、タスクを自動化レベル別に整理することを検討してください。これにより、関連するスクリプトを使用してタスクを部分的または完全に自動化することが可能になります。また、サービスワークフローをさらに効率化し、チームの運用効率を最適化するのにも役立ちます。

SLO管理でリアルタイムダッシュボードを作成する

リアルタイムダッシュボードは、サービスレベル目標（SLO）を視覚化、追跡、共有するための簡単な方法を提供します。SLOとは、企業や組織が顧客に提供することを約束したサービスレベルを定義する測定可能な目標です。通常、稼働時間、応答時間、エラー率などが含まれます。たとえば、サービスレベル目標が稼働率99%の場合、リアルタイムダッシュボードを使用して、この目標が達成されているかどうかを確認できます。また、主要な指標は解釈しやすく、技術担当者やビジネス担当者と共有しやすいため、問題の特定と迅速な対応に役立ちます。これらのサービスレベル目標をリアルタイムで追跡することで、顧客のニーズを満たしていることを確認できます。

トランザクションパス全体にわたってトラブルシューティングを行う

トラブルシューティングは、APIモニタリングを活用してパフォーマンス問題の根本原因を特定することに依存します。ボトルネック、スケーリング、エラー処理といった一般的な課題は、APIモニタリングデータとエラーコードを戦略的に活用することで全て改善できます。

例えば、スループットは、APIのスケーリング性能を示す良い指標となります。また、パフォーマンスの問題の原因がAPI自体にあるのか、それともAPIリクエストパス上のサードパーティツールにあるのかを区別することも重要です。例えば、DNS遅延、IPトラフィック遅延、データパケットの損失といったネットワーク障害は、API自体とは無関係にパフォーマンスの問題を引き起こす可能性があります。そのため、エンドユーザーエクスペリエンスを含めたAPIトランザクションのパス全体を監視し、アプリケーションの速度低下の影響を把握し、面倒なトラブルシューティングを行うことなくパフォーマンス問題の根本原因を特定することが重要です。

結論

APIは今日のアプリケーションにおいて重要な役割を果たしており、その重要性はますます高まっています。主要な指標と適切なツールを活用し、明確な監視戦略を策定することで、APIの耐久性、拡張性、回復力を向上させることができます。上記で紹介したAPI監視のヒントとベストプラクティスを活用して、ユースケース、技術スタック、インフラストラクチャに合わせたAPI監視を改善しましょう。

よくあるご質問