クイックダウンロード:
APIの回復力には、ユーザーからコードに至るまでのインターネット経路全体にわたるエンドツーエンドの可視性が必要です。
-
現代のシステムは、トランザクションごとに数百ものAPI呼び出しに依存しており、たった1つの依存関係の不具合がサービス全体のパフォーマンスを低下させたり、停止させたりする可能性がある。
-
従来の監視ツールはクラウドサーバー上で動作するため、ISPの混雑、地理的なルーティングの違い、ラストマイルの状況といった現実世界の問題を見逃してしまう。
-
インターネットパフォーマンス監視機能は、インターネットスタック全体(DNS、SSL、ルーティング、認証)を明らかにするため、チームは症状を検出するだけでなく、根本原因を特定できます。
-
現在のAPI監視を、回復力の基準(到達可能性、可用性、パフォーマンス、信頼性)に基づいて評価してください。評価項目は、すべての依存関係における回復力です。
企業は毎年、APIの障害やパフォーマンス低下によって数百万ドルもの損失を被っています。システムが分散化され、相互接続性が高まるにつれ、サーバー側からのAPI監視だけでは不十分になっています。真の回復力を実現するには、ユーザーからコードに至るまで、インターネット経路全体を可視化する必要があります。
今日、ほぼすべてのシステムがAPIに依存しています。データ統合、認証、決済処理、その他数十もの重要な機能は、複数のAPIが信頼性高く高速に動作することに依存しています。たとえば、世界中の銀行は、 オープンバンキングAPI 決済、信用スコアリング、融資実行、不正検出など、さまざまな用途に利用できます。
APIは至る所に存在し、あらゆるものに不可欠である。
APIはインターネットの内部で動作する働き手です。単一のウェブサイトに接続したり、ATMのようなビジネスアプリケーションを使用したり、モバイルアプリを開いたりするだけで、数十回(場合によっては数百回、数千回)ものAPI呼び出しが発生します。それぞれのAPI呼び出しはサービス全体に影響を与えます。API呼び出しが遅いとサービス全体の速度が低下し、エラーが返されるとサービスが完全に停止してしまう可能性があります。
サービスと、それらが利用するAPIとの相互作用を理解することは、サービスの回復力を高める上で非常に重要です。
APIを監視する方法はいくつかあります。最低限、すべてのシステムは、内部APIとサードパーティAPIの両方を含む、重要なAPIを積極的に監視、測定、テストする必要があります。 API監視システム 監視は以前から存在しており、到達可能性を確認する基本的なpingから、応答時間、機能検証などを評価する高度な多段階スクリプトによるプロアクティブな監視まで多岐にわたります。最も成熟したアプローチでは、カオスエンジニアリングの手法が取り入れられています。これは、特定のAPIでエラーをブロックまたはシミュレートし、システム全体への影響を観察するものです。
APIの回復力が重要な理由
APIを介して通信するほとんどのアプリケーションやシステムは地理的に分散しており、異なるクラウドに接続し、インターネット上の複数のポイントを経由します。単純な事前監視だけではもはや十分ではありません。従来のAPI監視手法では重要なインシデントを見逃し、根本原因の特定にも役立ちません。
目標は 回復力のあるAPIを選択します。 回復力の公式 4つの要素に分解できます。
- 到達可能性: 消費者は、自分のいる場所からAPIにアクセスできますか?
- 在庫: APIは正常に機能していますか?期待通りの動作をしていますか?
- パフォーマンス: APIは想定される時間内に応答しますか?
- 信頼性: 消費者はAPIが常に正常に動作すると信頼できるだろうか?
次に、その公式をシステム内のすべてのAPIに適用します。システムの全体的な回復力は、システムが依存するすべてのAPIにおける最小回復力に等しくなります。

実際には次のようになります。
可用性100

図1:1つの依存関係の不具合がシステム全体の障害につながる可能性がある
その目標を念頭に置いて、API監視に実際に何が必要なのかを見ていきましょう。
基本的なAPI監視戦略に含めるべきもの
これらは、あらゆるAPI監視戦略に必要な基本機能です。これらの機能により、チームは基本的な運用レベルで問題の検出、可用性の確認、パフォーマンスの検証を行うことができます。
- 反応時間: APIの応答時間を測定し、レイテンシーの問題を特定するのに役立ちます。
- エラー率: 失敗したリクエストの割合を追跡し、異常やバグを検出します。
- スループット: 特定の期間に処理されたAPIリクエストの数を監視し、スケーラビリティを確認します。
- 稼働時間と可用性: APIが常にアクセス可能で正常に動作していることを確認します。
- ロギング: トラブルシューティングやインシデント後の分析を支援するため、タイムスタンプ、イベントの種類(エラー、警告)、メッセージなど、APIイベントの詳細なログを収集します。
- アラート: 事前に定義されたしきい値または異常(例えば、応答時間が200msを超える場合や、エラー率が5%を超える場合など)に基づいて通知をトリガーします。
- 機能テスト: APIエンドポイントが期待される結果を返すことを検証します。
- CI/CD の統合: パイプラインやツールに監視機能を統合します。 ジェンキンズ or テラフォーム 自動テストの作成と更新、別名「コードとしての監視」。
- プロアクティブな監視: 合成メカニズムを使用して、APIのパフォーマンスを継続的に監視し、問題が発生した際にそれを検出します。
- スクリプト: Playwrightなどのスクリプト標準をサポートし、特定の顧客フローやAPIフローをテストできます。
- 過去のデータ: 前年比のパフォーマンス比較を可能にするため、最低13か月分のデータを保持します。
- 高カーディナリティデータ分析: 固有のユーザーIDやセッション固有の情報といった詳細なデータポイントを分析し、パフォーマンスの傾向や異常に関する詳細な洞察を提供します。
- カオスエンジニアリング: トラフィックが少ない期間や非本番環境において、意図的に制御されたエラーを導入することで、システムの回復力を検証します。
インターネット経路全体にわたる最新のAPI監視
今日のシステムには、基本的な稼働状況チェックや応答速度指標以上のものが求められます。最新のAPI監視は、地理的条件、インフラストラクチャ、ユーザーエクスペリエンス、外部依存関係といった、現実世界の複雑さを考慮に入れる必要があります。これらの機能は、基本的な機能を超え、深く実用的な洞察を提供します。
- 重要な場所から監視する: ほとんどの監視ツールはクラウドサーバー上でエージェントを実行しますが、クラウドサーバーは実際のシステムとは接続性、リソース、帯域幅が異なります。そのため、ルーティングの地理的な違い、ISPの混雑、ラストマイルの状況には対応できません。効果的な監視には、 システムがAPIを利用するすべての場所にエージェントが展開される実際の消費者と類似した特性を持つエージェントを使用します。たとえば、ラストマイルエージェントを使用して顧客向けAPIからアプリケーション全体をテストし、クラウドプロバイダーでホストされている中間マイクロサービスをテストし、データセンターが所在する都市とISPにあるバックボーンエージェント(またはデータセンター内のエンタープライズエージェント)からバックエンドAPIをテストすることができます。
- インターネットスタックの可視性: 知っている を特定いたします。 APIが応答しない、または遅い場合、その状況を理解することが重要です。 現在も将来も、 はより強力です。最新の API モニタリングは、DNS 解決、SSL、ルーティングなど、API に影響を与えるインターネット スタックのすべてに関する洞察を提供します。また、内部ネットワーク、SASE 実装、またはゲートウェイによって発生するレイテンシとパフォーマンスへの影響も明らかにします。次のようなツール インターネットスタックマップ これらの依存関係を視覚的に表現することで、劣化の原因をより迅速に特定できるようになります。

インターネットスタックとは、BGPなどのコアインターネットシステム、TCP/IPなどのネットワーク技術、SASEなどのセキュリティ技術、QUICやPOPなどのプロトコル、クラウドサービス、APIやWebサービスなどのサードパーティ依存関係、SaaSアプリケーションなど、あらゆるデジタルユーザーエクスペリエンスを可能にし、影響を与える技術、システム、サービスの集合体です。この用語は、パブリックインターネット、プライベートネットワーク、そしてその間のあらゆるものを含む、すべてのIPベースのネットワークを指します。
- 認証: 現代の監視システムでは、セキュアなAPIへの認証情報をハードコーディングすべきではありません。監視ツールは、シークレット管理、OAuth、トークン、および最新の認証メカニズムをサポートする必要があります。
- 合成コードトレース: APIのテストが行われる際、システムはコード実行トレースを収集・分析し、アプリケーション、接続性、データベースの問題など、サーバー側の問題を特定します。
- OpenTelemetryのサポート: 最新の可観測性実装では、複数のシステムからのデータを共有および統合するための標準メカニズムとしてOTelをサポートし、テレメトリスタック全体にわたる柔軟性を提供する必要があります。
- ユーザー エクスペリエンスの重視: API は、より広範なシステムの構成要素の 1 つにすぎません。たとえば、決済 API はオンライン購入取引の一部です。エンドユーザーの視点から取引全体が正しく機能していることを確認したい場合、Internet Stack Map のようなツールが役立ちます。 ユーザー取引におけるすべての依存関係の視覚的なマップエンドユーザーからインターネット、ネットワーク、システム、API、そしてコードトレースに至るまで、あらゆる段階を網羅します。
- 幅広いプロトコルサポート: 多くのAPIはHTTP経由のRESTを使用していますが、監視システムはIPv4とIPv6の両方のエージェントからテストを行い、HTTP/3やQUICなどの最新プロトコル、IoTアプリケーション向けのMQTT、時刻同期用のNTP、さらにはアプリケーションが使用する独自のプロトコルもサポートする必要があります。
従来型API監視と最新型API監視の概要
以下の表は、従来のAPI監視手法と、回復力とユーザーエクスペリエンスをサポートする最新のインターネットパフォーマンス監視戦略との主な違いをまとめたものです。
| 機能 | 従来のAPIモニタリング | 最新のAPIモニタリング(インターネットパフォーマンスモニタリング) |
| 対象領域 | サーバー中心の指標 | エンドツーエンドのユーザーエクスペリエンス+インフラストラクチャ |
| プロトコルサポート | HTTP/S、RESTに限定 | HTTP/3、QUIC、MQTT、カスタムプロトコル |
| データの粒度 | 高カーディナリティデータは入手可能だが、多くの場合サービス境界内に限定される | システム間相関のある高カーディナリティのトレース(ユーザーID、セッション) |
| 根本原因分析 | アプリ/サーバー層に限定 | インターネットスタック全体(DNS、SSL、ルーティングなど) |
| テストの観点 | クラウドデータセンター | ラストマイル、バックボーン、クラウド、ワイヤレス、およびエンタープライズインテリジェントエージェント |
| パフォーマンスコンテキスト | コードのコンテキストにおけるAPIのパフォーマンス | ユーザーエクスペリエンスの観点から見たAPIのパフォーマンス |
| アラート方法論 | エラー率に基づくアラートしきい値 | 経験スコアとXLO |
| 可視化 | コード中心のダッシュボード | システムに影響を与えるすべての要素を視覚的に表現したもの |
API監視はアーキテクチャに合わせて進化する必要がある
クラウドが登場してからまだ15年ほどしか経っていないというのは、少々意外なことだ。技術やシステムアーキテクチャが進化するにつれて、APIへのアプローチ方法も含め、監視方法もそれに合わせて進化していく必要がある。
今日私たちが「所有」または「オンプレミス」インフラストラクチャと呼ぶものは、通常、コロケーションデータセンターに設置され、DNSおよびSSLプロバイダーに依存し、少なくとも2つのISPを経由して接続し、クラウドベースの認証システムに依存し、クラウドベースのセキュリティプロバイダーを経由してルーティングを行い、その過程で他のいくつかのAPIを呼び出します。
運用チームは、「APMシステムは正常と表示されているのに、ユーザーから苦情が絶えない」という声を常に耳にします。オンプレミスのAPIのみを監視するシステムでは、自社環境外で発生したインシデントを検知、診断したり、有用な根本原因情報を提供したりすることはできません。
LogicMonitorのアプローチは インターネットパフォーマンス監視 方程式が変わります。 LM Envisionの インターネットパスの可視性を備えたインフラストラクチャテレメトリと エドウィンAIの インテリジェンスレイヤーにより、チームはユーザーからコードまでを網羅した統合ビューを得ることができます。つまり、根本原因の特定が迅速化され、盲点が減り、事後対応型の緊急対応から、予防的で統制された運用へと移行することが可能になります。
APIの回復力を確保するためには、企業はインターネット経路全体にわたるエンドツーエンドの可視性を提供する監視機能、実際のユーザーへの影響に基づいたプロアクティブなアラート機能、そして問題が障害に発展する前に対応するためのインテリジェンスを必要とします。
エンドツーエンドのインターネットパフォーマンス監視が、APIの回復力をどのように強化するかをご覧ください。
LogicMonitorは、インフラストラクチャのテレメトリとインターネットパス全体の可視化、そしてEdwin AIのインテリジェンスを組み合わせることで、ユーザーからコードまでを網羅した統一的なビューをチームに提供します。事後対応型のトラブルシューティングから、予防的で統制された運用へと移行しましょう。
よくあるご質問
従来のAPI監視とインターネットパフォーマンス監視の違いは何ですか?
従来のAPI監視は、クラウドベースのエージェントからの応答時間やエラー率といったサーバー側の指標に焦点を当てています。一方、インターネットパフォーマンス監視は、DNS、SSL、ルーティング、ラストマイルの状況など、インターネット経路全体にわたる可視性を提供し、APIの応答が遅い、あるいはアクセスできない理由について、実用的な洞察をもたらします。
クラウドベースの監視エージェントが、現実世界のAPIの問題を見逃してしまうのはなぜですか?
クラウドエージェントは、実際のエンドユーザーとは異なる接続性、リソース、帯域幅を持っています。そのため、地理的なルーティングの違い、ISPの混雑、ラストマイルの劣化などを検出できません。実際の顧客拠点にエージェントを配置することで、APIのパフォーマンスをより正確に把握できます。
APIの回復力を構成する4つの要素とは何ですか?
APIの回復力は、到達可能性(利用者がAPIにアクセスできるかどうか)、可用性(正しく機能するかどうか)、パフォーマンス(期待される時間内に応答するかどうか)、信頼性(一貫して動作するかどうか)の4つの要素に分けられます。システムの全体的な回復力は、そのシステムを構成するすべてのAPI依存関係における最小回復力に等しくなります。




