[編集者 – この投稿は、 rtapi
バージョン 0.2.0で導入された改訂レポートに関する情報で更新されました。]
Akamai のインターネット セキュリティ状況レポートによると、API は現代のアプリケーションと進化するデジタル アーキテクチャの中心に位置しており、API 呼び出しはすべての Web トラフィックの 83% を占めています。 消費者がデジタル競合他社に乗り換えるのが非常に容易な今日の状況では、消費者がサイトやアプリで肯定的な体験をすることが最も重要です。スピードは非常に重要であり、最終的には応答性が高く、健全で、適応性の高い API によって推進されます。 これを正しく実行すれば、つまり API が競合他社の API よりも高速であれば、開発者はあなたを選択するでしょう。
IDC レポート「API - デジタル ビジネスの成功と失敗を決定する要因」によると、組織の 90% 以上が 50 ミリ秒 (ms) 未満のレイテンシを期待しており、ほぼ 60% が 20 ミリ秒以下のレイテンシを期待しています。 (レイテンシは、API インフラストラクチャが API 呼び出しに応答するまでにかかる時間、つまりリクエストが API ゲートウェイに到着してから応答の最初のバイトがクライアントに返されるまでの時間として定義されます。)
私たちはこのデータと API ライフサイクルのエンドツーエンドの分析を組み合わせて、レイテンシが 30 ミリ秒以下のリアルタイム APIを定義しました。 さらに、処理されるリクエストの 99 パーセンタイルまで、30 ミリ秒のレイテンシしきい値を維持する必要があります (つまり、平均して 100 件のリクエストのうち 1 件だけが 30 ミリ秒を超える時間がかかります)。 詳細については、 API 管理ソリューションのパフォーマンス ベンチマークに関するブログをご覧ください。
ほとんどの企業にとって、API 呼び出しを可能な限りリアルタイムに近い時間で処理することは大きな課題です。特に、API エンドポイントへのエントリ ポイントとして、アーキテクチャ的に複雑な API ゲートウェイを使用している場合はなおさらです。 では、あなたの API はどのように評価されているでしょうか? すでにリアルタイムとみなせるほど高速ですか、それとも改善が必要ですか? 製品の動作が少し遅いように感じますが、その理由がよくわかりませんか? API のレイテンシーがどのようなものかよくわからないのではないでしょうか?
rtapi
は、NGINX が作成したリアルタイム API レイテンシ ベンチマーク ツールで、API ゲートウェイとエンドポイントの応答性をテストし、同僚間で簡単に配布して共有できるレポートを生成します。 利用可能なレポート形式は、概要グラフを含む PDF と、詳細なメトリックの ASCII 形式の表の 2 つです。
rtapiの
実行次の 2 つの方法のいずれかを使用して、GitHub からrtapi
バイナリをダウンロードします。
Golangがインストールされている場合は、次のコマンドを実行します。
$ github.com/nginxinc/rtapi にアクセスします
次の例のように、JSON または YAML 形式で、クエリする 1 つ以上の API エンドポイント (ターゲット) を指定します。 JSON または YAML を、 endpoints.jsonまたはendpoints.ymlというファイルに保存することをお勧めします。 (JSON の場合は、次の手順で、 --data
フラグのパラメーターとしてrtapi
コマンドラインにデータを含めることもできます。)
各エンドポイントに必要なパラメーターはtarget.url
とtarget.method
のみです。 target.body
とtarget.header
を指定しない場合は空のままになります。 query_parameters
オブジェクトでパラメータを指定しない場合、 rtapi は
次の例に示す (デフォルトの) 値を使用します。
サンプルJSON入力
[
{
"ターゲット": {
"url": "https://www.example.com",
"メソッド": "POST",
"body": "{\"id\":\"0\"}",
"header": {
"Content-Type": [
"application/json"
]
}
},
"query_parameters": {
"threads": 2,
「最大スレッド数」: 2,
「接続」: 10,
「期間」: 「10 秒」
「リクエスト レート」: 500
}
}
]
サンプルYAML入力
- ターゲット: URL: https://example.com/api/id
メソッド: POST
本文: '{"id":"0"}'
ヘッダー:
コンテンツ タイプ:
- application/json
クエリ パラメータ:
スレッド: 2
最大スレッド数: 2
接続: 12
期間: 10秒
リクエストレート: 500
次のコマンドを実行します。-- file
には、API エンドポイントの JSON/YAML 形式のリストを含むファイルの名前を指定し、 --output に
は、 rtapi
によって生成される PDF レポートの名前を指定します。 (手順 2 で説明したように、コマンド ラインで JSON 入力を指定できます。-- file
endpoints.json
の代わりに、 --data
に続けて JSON 文字列を指定します。)
$ rtapi --file エンドポイント.json --output レポート.pdf
ターミナルに ASCII 形式のメトリック テーブルを表示するには、--output フラグの代わりに (または--output
フラグに加えて) --print
フラグを含めます。
$ rtapi --file エンドポイント.json --print
rtapi
によって生成された PDF レポートには、次のような応答遅延のHDR ヒストグラムが含まれています ( NGINX コントローラー API 管理モジュールを使用して構成された NGINX Plus API ゲートウェイから)。 Y 軸にはミリ秒単位のレイテンシが表示され、X 軸には指定されたレイテンシ未満で処理された呼び出しの割合がパーセンタイルで表示されます。 (次の例では、スペースの都合上、Y 軸を圧縮しています。)
API の結果を強調表示するために、軸に平行な破線が交差し、99 パーセンタイル (グラフでは99% ) での API の測定されたレイテンシが表示されます。 API がリアルタイムであるとみなされるためには、交差点でのレイテンシが 30 ミリ秒未満である必要があります。
API のレイテンシは 30 ミリ秒未満ですか?
私たちが話をする多くの企業と同様であれば、おそらくそうではないでしょう。 多くの API ゲートウェイおよび API 管理ソリューションでは、100 ミリ秒のレイテンシは一般的であり、500 ミリ秒でもそれほど珍しいことではありません。
NGINX は API パフォーマンスの向上をお手伝いします。NGINX と NGINX Plus は業界最速の API ゲートウェイであり、NGINX Controller と組み合わせることで、30 ミリ秒未満で API 呼び出しのルーティング、認証、保護、シェーピング、キャッシュを行うことができます。 nginx.com/real-time-apiで詳細を確認し、NGINX の専門家に相談して、リアルタイム API への移行において NGINX がどのように役立つかを確認してください。
「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"