企業がモダンアプリケーションの構築に向けてAPIファーストの設計手法を採用する中、APIの運用パフォーマンスと価値を測定することが最優先課題となっています。APIの指標を明確に定義し、主要業績評価指標(KPI)と関連付けるフレームワークの確立は、API戦略を成功に導くうえで最も重要なステップの1つです。
通常、KPIは特定の目標に関連付けられ、明確な期間が設定されています。また、API戦略で達成すべき成果に沿って定められます。一方、APIメトリクスは重要なデータポイントです。すべてのメトリクスがKPIになるわけではありませんが、すべてのKPIはメトリクスから始まります。
では、何から始めればよいのでしょうか。まず、API戦略の目標を最初に明確にし、その目標に沿ったメトリクスを選択します。各チームが重視することやビジネスに不可欠なことに応じて、測定および追跡すべきメトリクスは異なる点に留意してください。
大きく分けると、企業が追跡できるAPI指標には3つの種類があり、それぞれ異なる問いに答えます。
- 運用メトリクス – APIは、必要な安定性、信頼性、パフォーマンスを実現していますか?
- 導入状況の指標 – 開発者はAPIを導入し、利用していますか?
- プロダクト指標 – APIはビジネス目標の達成にどのように貢献していますか?
これらの包括的な指標をピラミッドとして捉えてみましょう。最下層では、運用指標によって、個々のAPIとそれを支えるインフラストラクチャの実務的なパフォーマンスを測定します。最上層では、製品指標によって、APIが生み出すビジネス価値を測定します。この2つをつなぐのが導入指標です。これは、エンドユーザー(開発者)によるAPIプログラムの利用拡大を追跡します。一般に、製品指標と導入指標は測定すべきビジネス成果に対応し、運用指標は維持すべき技術標準に対応します。
本記事では、測定が不可欠な12の具体的な指標を詳しく取り上げ、それらがインフラストラクチャチームとアプリケーションチームにどのように役立つか、またKPIとどのように関連するかを解説します。
運用メトリクス
取り組みを始めたばかりの段階では、通常、運用メトリクスを最初に測定します。運用メトリクスは戦術的な指標であり、APIの稼働状況を把握するのに役立ちます。通常、運用メトリクス自体はKPIではありません。代わりに、チームが開発しているソフトウェアの品質とパフォーマンスを測定するのに役立ちます。また、新たな問題の兆候を早期に把握したり、詳細に分析して重要なKPIに影響を及ぼしている可能性のある問題を特定したりするのにも役立ちます。
追跡する運用メトリクスは、チームや担当業務によって異なります。
インフラストラクチャチーム
プラットフォーム運用チームは、各チームがアプリケーションを提供するために使用する一連のインフラストラクチャとテクノロジーの保守、接続、セキュリティ確保を担います。APIプログラムでは、多くの場合、APIゲートウェイとAPI開発者ポータルも対象となります。
Platform Opsなどのインフラストラクチャチームにとって重要な指標は次のとおりです。
- 稼働時間 – 最も基本的な指標の1つでありながら、稼働時間はサービスの可用性を測定するための最も重要な基準です。多くの場合、サービスレベル契約(SLA)に関連付けられます。
- CPUとメモリの使用率 – APIゲートウェイでリソース使用率を追跡することは、インスタンスのスケールアウトが必要になる可能性を把握するうえで不可欠です。また、障害の兆候や、エラーによる使用量の急増を早期に検知するためにも役立ちます。
- 成功率とエラー率の合計 – APIがHTTPエラー(
200以外)のステータスコードを返す頻度を測定することで、APIでエラーが発生する可能性を把握できます。この集計指標は、チームが本番環境に投入するAPIの全体的な品質を判断するために役立つ情報を提供します。
アプリケーションチーム
API開発者とサービスオーナーで構成されるアプリケーションチームは、個々のサービスやアプリケーションの構築と運用を担当します。これらは、より大規模な製品の一部として使用されるほか、パートナーとの連携や、開発者向けにAPIをサービスとして提供する際にも利用できます。
アプリケーションチームにとって、以下の指標を測定することが重要です。
- 1分あたりのリクエスト数 – このパフォーマンス指標は、APIが処理するリクエスト数を測定します。時間の経過とともに変動しますが、APIユーザーに最適なエクスペリエンスを提供できるよう、通常は減少させる方向で管理します。
- 平均レイテンシと最大レイテンシ – APIがリクエストを受信してからレスポンスを返すまでの平均時間を追跡することが重要です。1つのAPIの応答が遅いだけでも、ユーザーエクスペリエンスが損なわれ、ひいてはビジネスにも悪影響が及ぶ可能性があります。
- 1分あたりのエラー数 – ほかのものと同様、完璧なAPIはありません。障害は発生するかどうかではなく、いつ発生するかの問題です。エラーを監視し、急増し始める前に修正できるよう、対応手順をあらかじめ策定しておく必要があります。
eBook『Mastering API Architecture』の第3~5章でAPI運用を掘り下げ、ビジネスの観点から重要なKPIと指標について学べます。O’Reilly発行、NGINX提供。
導入状況の指標
APIファーストのビジネスでは、エンジニアリング指標だけでなく、開発者がAPIをどのように利用しているかを把握することが不可欠です。また、開発者がAPIを導入し、その価値を得られていることを確認するために、API開発者エクスペリエンスを測定、監視する必要があります。
導入状況を示す指標の例:
- 一意のAPI利用者 – 多くの場合、月間ユーザー数として期間を区切って集計し、APIを導入して利用している開発者の数を測定する指標です。より多くの開発者がAPIをアプリケーションに統合するにつれて、この指標が継続的に増加することが理想です。
- API利用量の増加 – この指標もAPIの導入状況を測定するもので、多くの場合、その測定に適した指標として選ばれます。APIを利用するアプリケーションや開発者の数が増えるにつれて、APIトラフィックも月ごとに増加することが理想的です。
- 初回呼び出しまでの時間 – この指標は、開発者がアカウントを作成し、API認証情報を生成して、最初のAPI呼び出しを実行するまでにかかる時間を測定します。開発者ができるだけ早く利用を開始できるようにすることは優先度が高いため、API開発者エクスペリエンス全体を測定するうえで、この指標が最も重要です。
注:少なくとも1つのKPIでAPIの導入状況を測定することを推奨します。これにより、APIプログラム全体の成長を算出しやすくなります。たとえば、APIを使用して継続的なインテグレーションやアプリを作成した開発者数の増加をKPIとして設定できます。
プロダクト指標
APIの価値を把握するうえで、APIプロダクトの指標は重要な役割を果たします。収益に直接貢献するAPIはごく一部に限られる場合がありますが、すべてのAPIがビジネスに価値をもたらす必要があります。
測定すべき主なプロダクト指標は次のとおりです。
- 直接収益と間接収益 – これらの指標は、APIが収益に貢献するさまざまな方法を測定します。直接収益化されるAPIがある一方で、ビジネスパートナーとの連携を支援するAPIや、お客さまが価値を認めるサードパーティ連携もあります。APIの導入率と同様に、間接収益を追跡することで、開発者によるパートナー向け収益創出アプリの構築を支援できます。
- APIあたりのアプリケーション数 – APIには再利用性が必要です。この指標では、各APIと連携するアプリケーションの数を測定し、最も大きな価値を提供するAPIを特定します。
- パートナー数 – APIは、多くの場合、ビジネス関係の構築を可能にします。パートナーによるAPI統合の数を追跡することで、導入を促進し、他の事業部門に価値を示すことができます。
注:これらのプロダクト指標はビジネスへの影響と密接に関連しており、ビジネス目標に応じて、その一部をKPIとして設定することもできます。たとえば、API戦略のビジネス目標が、サードパーティプロバイダーを通じてより多くの顧客にリーチすることである場合、APIを利用しているパートナー数と、それらの連携を通じて生み出される間接収益の両方を追跡する必要があります。
API製品のライフサイクル(ビジネスおよび運用上のKPIを含む)について詳しくは、『Mastering API Architecture』の第3~5章をご覧ください。
まとめ
APIメトリクスとビジネスKPIを整合させることは、データに基づく意思決定を行い、API戦略によって組織が必要とする価値を確実に提供するための主要な方法の1つです。さらに、APIの可視性を確保することで、インフラストラクチャチームやアプリケーションチームは、それぞれにとって最も重要な運用メトリクスを測定できるようになります。
NGINXでは、数十種類の重要なAPIメトリクスを可視化できます。リアルタイムおよび過去のメトリクスを確認し、任意のアプリケーションパフォーマンス監視(APM)ソリューションやデータ分析ソリューションに簡単にエクスポートできます。
今すぐ、NGINX Management Suiteの30日間無料トライアルをお試しください。このトライアルでは、API Connectivity Manager、APIゲートウェイとしてのNGINX Plus、およびAPIを保護するためのNGINX App Protectをご利用いただけます。
関連するブログ記事
チュートリアル:NGINXを使用してアプリケーション向けにOpenTelemetryを構成する
OpenTelemetryを使用してNGINXサーバーの状態と健全性をより明確に把握することで、問題のトラブルシューティングを行い、Webアプリケーションのパフォーマンスを向上できます。
AkitaのNGINX Plus認定モジュールでAPIエンドポイントの問題を特定・修正
Akita SoftwareのAPIオブザーバビリティ向け新しいNGINX Plus Certified Moduleを活用して、APIエンドポイントの問題をより迅速に特定し、修正できます。
JavaプロジェクトをスキャフォールディングしてKubernetesネイティブアプリを構築する方法
Red HatのシニアプリンシパルデベロッパーアドボケイトであるDaniel Oh氏が、Javaプロジェクトをゼロから構築するためのひな形を作成し、Kubernetesネイティブアプリケーションとしてビルドする方法を解説します。
F5 NGINXaaS for Azureのご紹介:Microsoft Azureでネイティブに利用できるSaaS型ロードバランシング
NGINXaaS for Azureは、NGINX PlusをAzureネイティブのSaaSとして利用できるサービスです。NGINXの設定を容易にリフト&シフトできるため、クラウド導入とモダンアプリの展開を加速できます。

SELinuxでNGINXおよびNGINX Plusを使用する
Red Hat Enterprise Linux(RHEL)および関連ディストリビューションでSecurity-Enhanced Linux(SELinux)を有効にすると、デフォルト設定によりNGINXとNGINX Plusの一部の操作が制限されます。この記事では、すべての機能を利用できるようにSELinuxの設定を変更する方法について説明します。
NGINX PlusによるAWS Auto Scalingグループの負荷分散
新しいnginx-asg-sync統合ソフトウェアにより、NGINX PlusはAWS Auto Scalingグループの負荷を直接分散できるため、クラウドでの負荷分散がさらに柔軟になります