クラウドネイティブ API Gateway インスタンスは、サービス公開、トラフィック管理、セキュリティ保護、API のライフサイクル全体の管理を提供します。このトピックでは、コンソールでクラウドネイティブ API Gateway インスタンスを作成し、その際に Gzip ハードウェアアクセラレーションとゲートウェイログ配信を有効にする方法について説明します。
前提条件
サービスリンクロールの権限付与：クラウドネイティブ API Gateway を初めて有効化する際は、次のシステムアクセスポリシーを付与する必要があります：
AliyunServiceRoleForNativeApiGw：ACK、VPC、SLB、MSE など、他の Alibaba Cloud サービスへのアクセス権限を付与します。AliyunServiceRolePolicyForNativeApiGwInvokeFC：Function Compute (FC) へのアクセス権限を付与します。
リージョン：バックエンドサービスと同じリージョンにゲートウェイを作成します。
VPC と vSwitch：サービスが稼働する既存の VPC と、ゲートウェイノード用の vSwitch が必要です。ゲートウェイは、サービスと同じ VPC で稼働する必要があります。
インスタンスの作成後にリージョンを変更することはできません。Gzip ハードウェアアクセラレーションは購入ページで選択する必要があり、既存のインスタンスでは有効化できません。
基本構成
クラウドネイティブ API ゲートウェイコンソールにログインします。左側のナビゲーションペインで、インスタンスを選択します。インスタンスページで、インスタンスの作成をクリックします。
Cloud-native API Gateway 購入ページで、次のパラメーターを設定します：
[プロダクトタイプ]: Pay-as-you-go または サブスクリプション を選択します。各課金方法の料金詳細については、「課金の概要」をご参照ください。
[従量課金] — 時間単位で課金されます。1 時間未満の使用は 1 時間として請求されます。料金は 1 時間ごとに決済されます。
[サブスクリプション] — 月単位で課金されます。1 年間のサブスクリプションは 12 か月として請求されます。
[ゲートウェイ名]：ゲートウェイのカスタム名を入力します。ベストプラクティスとして、
testやorder-prodのように、環境やビジネスドメインに基づいてゲートウェイに名前を付けます。名前の長さは最大 64 文字です。[GatewaySpec]：ビジネス要件に基づいて容量評価を実施し、ノード仕様を選択します。各仕様のしきい値については、「さまざまなノード仕様の容量しきい値」をご参照ください。
単一ノードで実行されるゲートウェイには SLA が提供されません。本番ワークロードには、複数のノードをデプロイするスペックを選択してください。
Gzip ハードウェアアクセラレーションを使用するには、
apigw.medium.x1以上のスペックを選択してください。
[リソースグループ]: 既存のリソースグループまたはデフォルトのリソースグループを選択します。リソースグループを使用すると、Alibaba Cloud アカウントのリソースを分類してグループ化し、個々のリソースごとではなくグループ全体で権限管理、リソースのデプロイ、およびリソースの監視を行うことができます。リソースグループを作成するには、リソースグループの作成 をクリックします。
[Network Type]: インターネット、Private Network、または[パブリック + プライベート]を選択します。クライアントがプライベートネットワーク経由でのみゲートウェイにアクセスする場合は、[プライベート]を選択すると、パブリックネットワークのトラフィック料金を回避できます。
[インターネット] — ゲートウェイがパブリックネットワーク経由でアクセスされると、パブリックネットワークのトラフィック料金が適用されます。 パブリックネットワークトラフィックは、パブリックネットワークトラフィックで説明されているように、Cloud Data Transfer (CDT) を通じて BGP (マルチライン) モードで課金および請求されます。
[Private Network] — プライベートネットワークアクセスでは、トラフィック料金は発生しません。
[パブリック + プライベート] — ゲートウェイにパブリックネットワーク経由でアクセスする場合、パブリックネットワークトラフィック料金が発生します。パブリックネットワークトラフィックは、BGP (マルチライン) モードの Cloud Data Transfer (CDT) を通じて課金および請求されます。プライベートネットワークアクセスにはトラフィック料金は発生しません。
[VPC]：ゲートウェイインスタンスが実行される VPC を選択します。ゲートウェイの VPC は、サービスの VPC と同じである必要があります。
[ゾーンの選択]：[自動割り当て] または [手動選択] を選択します。
自動割り当て — ゲートウェイノード用の vSwitches を選択します。システムは、ゲートウェイノードに 2 つのゾーンを自動的に割り当てます。
手動選択 — ゲートウェイノードの [ゾーン] と vSwitches を手動で選択します。 このオプションは、ゲートウェイノードを Gzip ハードウェアアクセラレーションをサポートするゾーンなど、特定のゾーンで実行する必要がある場合に選択します。
[今すぐ購入] をクリックします。 [注文の確認] ページで、クラウドネイティブ API ゲートウェイインスタンスの構成詳細を確認し、今すぐ有効化 をクリックします。
説明ゲートウェイインスタンスの作成には 1 ~ 5 分かかります。
クラウドネイティブ API ゲートウェイの インスタンス ページで、作成したゲートウェイインスタンスのステータスを確認します。ステータスが 実行中 の場合は、ゲートウェイが作成されたことを示します。
ノード仕様ごとの容量しきい値
次の表に、Cloud-native API Gateway の各 GatewaySpec における容量しきい値を示します。ゲートウェイの容量メトリクスが警告しきい値を下回っている場合、ゲートウェイは完全な SLA の対象となります。コアビジネスでは、より高い安定性を確保するために、容量メトリクスを安全しきい値未満に維持してください。
安全しきい値：トラフィックが突然 2 倍になっても、ゲートウェイは高いスループットと低いレイテンシーを維持します。
警告しきい値：容量が警告しきい値を超えると、ゲートウェイのレイテンシーが増加する可能性があり、トラフィックの急増時に安定性のリスクが生じることがあります。
シングルノードゲートウェイ：単一ノードで稼働するゲートウェイでは SLA は提供されず、テスト用途のみを想定しています。本番ワークロードでは、複数ノードをデプロイする GatewaySpec を使用してください。
ゲートウェイ仕様 | クライアント接続数 | 新規 HTTPS 接続数 | CPU 使用率 | メモリ使用量 | ||||
安全しきい値 | 警告のしきい値 | 安全しきい値 | 警告のしきい値 | 安全しきい値 | 警告のしきい値 | 安全しきい値 | 警告のしきい値 | |
| 12,000 | 24,000 | 400 | 800 | 30% | 60% | 75% | 75% |
| 24,000 | 48,000 | 800 | 1,600 | 30% | 60% | 75% | 75% |
| 48,000 | 96,000 | 1,600 | 3,200 | 30% | 60% | 75% | 75% |
| 96,000 | 192,000 | 3,200 | 6,400 | 30% | 60% | 75% | 75% |
| 192,000 | 384,000 | 6,400 | 12,800 | 30% | 60% | 75% | 75% |
| 384,000 | 768,000 | 12,800 | 25,600 | 30% | 60% | 75% | 75% |
| 576,000 | 1,152,000 | 19,200 | 38,400 | 30% | 60% | 75% | 75% |
| 768,000 | 1,536,000 | 25,600 | 51,200 | 30% | 60% | 75% | 75% |
| 1,536,000 | 3,072,000 | 51,200 | 102,400 | 30% | 60% | 75% | 75% |
| 2,304,000 | 4,608,000 | 76,800 | 153,600 | 30% | 60% | 75% | 75% |
| 3,072,000 | 6,144,000 | 102,400 | 204,800 | 30% | 60% | 75% | 75% |
高度な機能
Cloud-native API Gateway インスタンスを作成する際、以下の設定を使用してログデータを監視および分析したり、リクエストとレスポンスを圧縮してゲートウェイトラフィックを削減したりできます。Gzip ハードウェアアクセラレーションは、購入ページで選択した場合にのみ利用できます。Simple Log Service (SLS) にはこのような制限はありません。
Gzip ハードウェアアクセラレーションの有効化
Gzip ハードウェアアクセラレーションは、専用ハードウェアを使用してデータを高速に圧縮および解凍します。Gzip 解凍を CPU から専用ハードウェアにオフロードすることで、処理効率が向上し、CPU 負荷が軽減されます。
この機能の有効化には 2 つの段階があります。購入ページで選択したオプションによって、インスタンスが Gzip ハードウェアアクセラレーションを使用できるかどうかが決まり、既存のインスタンスにこの機能を追加することはできません。インスタンスの作成後、[EnableGzipHardwareAccelerate] パラメーターで機能を制御します。
購入ページで Gzip ハードウェアアクセラレーションを構成するには
Cloud-native API Gateway 購入ページで、基本設定と以下の設定を完了し、今すぐ有効化 をクリックします:
[Region]: Gzip ハードウェアアクセラレーションは、中国 (杭州)、中国 (北京)、中国 (上海)、中国 (深圳)、中国 (ウランチャブ)、中国 (香港)、およびシンガポールで利用できます。
説明サポート対象リージョン内の一部のゾーンでは、この機能はサポートされていません。購入ページには、実際に利用可能なゾーンが表示されます。
[GatewaySpec]: apigw.medium.x1 以上の仕様を選択します。
[Gzip ハードウェアアクセラレーション]： このオプションを選択して Gzip ハードウェアアクセラレーションを有効にします。
apigw.medium.x1以上であるか、選択したゾーンがこの機能をサポートしているかを確認してください。
例
次の例は、Gzip ハードウェアアクセラレーションの要件を満たす購入ページの設定を示しています。各仕様の容量については、ノードスペック別の容量のしきい値をご参照ください。
[GatewaySpec] には apigw.medium.x1 を選択します。 [リソースグループ] には [デフォルトリソースグループ] を選択します。 [ネットワークタイプ] には [インターネット] を選択します。 [VPC] にはターゲット VPC を選択します。 [ゾーン選択] では [手動選択] をクリックし、[Hangzhou Zone J] と [Hangzhou Zone K] (いずれも Gzip ハードウェアアクセラレーションに対応) を選択してから、各ゾーンの vSwitch を選択します。
インスタンスの作成後に Gzip ハードウェアアクセラレーションを有効にするには
インスタンスが作成されたら、対象インスタンスの ID または名前をクリックします。左側のナビゲーションペインで、Parameters を選択します。Gateway Engine Parameters セクションで、EnableGzipHardwareAccelerate パラメーターを編集します。
重要インスタンスの購入時に [Gzip ハードウェアアクセラレーション] を選択しなかった場合、このパラメーターを有効にすることはできません。
[パラメーター] ページで、[EnableGzipHardwareAccelerate] の現在の値が設定した値であることを確認します。
この機能が有効になると、クライアントは Gzip 圧縮データを処理できる必要があります。 Gzip をサポートするクライアントの場合は、
Accept-Encoding: gzipリクエストヘッダーを追加してください。
ゲートウェイログ配信の有効化
ゲートウェイランタイムログを収集、保存、分析するには、ゲートウェイインスタンスの作成時に Simple Log Service (SLS) をアクティブ化します。その後、SLS をログ分析とダッシュボードモニタリングに使用できます。
基本設定 を完了する際に、[Simple Log Service (SLS) を使用] を選択します。システムは Simple Log Service (SLS) をアクティブ化し、ゲートウェイログ配信を有効にします。
ログ配信を有効にした後、ゲートウェイログがObservation and Analysis > Logsに表示されることを確認します。
各ログフィールドの意味については、ゲートウェイログフィールドをご参照ください。
関連ドキュメント
Gzip パフォーマンスリファレンス
Gzip 圧縮でどの程度トラフィックを削減できますか？ Gzip 圧縮では、圧縮データのサイズを元のデータサイズで割った値である圧縮率は、データそのものに大きく左右されます。圧縮率が低いほど圧縮効果が高く、圧縮率が高いほど圧縮効果が低くなります。
一般に、Gzip はテキスト内の文字、単語、句読点など、繰り返しパターンや構造を多く含むデータをより効果的に圧縮し、圧縮率を低くできます。一方、画像、動画、圧縮済みファイルなど、ランダム性が高くエントロピーが大きいデータは内部の反復が少ないため、通常は圧縮率が高くなり、圧縮効果は低くなります。
ビジネスデータはお客様ごとに異なるため、圧縮率も大きく異なります。コアリージョンで Gzip を有効にしたインスタンスの統計によると、多くのインスタンスの圧縮率が 10%～50% の範囲にあります。平均すると、これらのユーザーは Gzip を有効にすると 50% 以上のトラフィックを削減しています。
次の図は、コアリージョンで Gzip を有効にしたインスタンスで測定した圧縮率を示します。
Gzip がすでに有効な場合、ハードウェアアクセラレーションでどの程度インスタンスリソースを削減できますか？ Gzip ハードウェアアクセラレーションを有効にすると、ゲートウェイは専用ハードウェアでデータを圧縮し、CPU リソースを節約できます。次のストレステストデータは、同じ QPS を処理する場合における、Gzip ハードウェアアクセラレーションを使用するシングルノードインスタンスと、ソフトウェアベースの Gzip を使用する 4 ノードインスタンスの CPU 使用率を比較したものです。
例：圧縮対象のデータが約 120 KB の JSON テキストファイルの場合
| QPS | CPU 使用率：ハードウェアアクセラレーション Gzip/apigw.medium.x1/シングルノード | CPU 使用率：ソフトウェア Gzip/apigw.medium.x1/4 ノード |
| 2,000 | 9% | 11% |
| 5,000 | 26% | 28% |
| 10,000 | 56% | 56% |
| 13,000 | 69% | 72% |
この表から、Gzip hardware acceleration/single node の CPU 使用率は、software Gzip/4 nodes の CPU 使用率とほぼ同等であることがわかります。従来 4 ノードを必要としていたワークロードは、Gzip ハードウェアアクセラレーションを有効にすると 1 ノードで稼働するようになり、インスタンスリソースを約 75% 節約できます。
ゲートウェイのログフィールド
次の表では、Cloud-native API Gateway が Simple Log Service (SLS) に配信するログのフィールドについて説明します。
フィールド名 | タイプ | 説明 |
__time__ | long | ログが生成された時間。 |
cluster_id | string | 購入したゲートウェイインスタンス。 |
ai_log | json | Model API、Agent API、および MCP API 用に設計されたログフィールド。フィールドは JSON フォーマットです。このフィールドは、他のタイプの API では空です。
|
authority | string | リクエストメッセージの Host ヘッダー。 |
bytes_received | long | ヘッダーを除くリクエストボディのサイズ。 |
bytes_sent | long | ヘッダーを除く応答本文のサイズ。 |
downstream_local_address | string | ゲートウェイ Pod のアドレス。 |
downstream_remote_address | string | ゲートウェイに接続するクライアントのアドレス。 |
duration | long | リクエストの処理にかかった合計時間。これは、ゲートウェイがダウンストリームサービスから最初のバイトを受信してから、応答の最後のバイトを送信するまでの期間です。単位: ミリ秒。 |
method | string | HTTP メソッド。 |
path | string | HTTP リクエストのパス。 |
protocol | string | HTTP プロトコルのバージョン。 |
request_duration | long | ゲートウェイがダウンストリームサービスから最初のバイトを受信してから、ダウンストリームサービスから最後のバイトを受信するまでの期間。単位: ミリ秒。 |
request_id | string | ゲートウェイは各リクエストの ID を生成し、それを |
requested_server_name | string | SSL 接続に使用されるサーバー名。 |
response_code_details | string | 応答コードに関する追加情報を提供します。たとえば、`via_upstream` は応答コードがバックエンドサービスによって返されたことを示し、`route_not_found` はリクエストに一致するルートが見つからなかったことを示します。 |
response_tx_duration | long | ゲートウェイがアップストリームサービスから最初のバイトを受信してから、ダウンストリームサービスに最後のバイトを送信するまでの期間。単位: ミリ秒。 |
route_name | string | ルート名。 |
start_time | string | リクエストが開始された時間。フォーマット: UTC。 |
trace_id | string | トレース ID。 |
upstream_cluster | string | アップストリームクラスター。 |
upstream_host | string | アップストリーム IP アドレス。 |
upstream_local_address | string | アップストリームサービスへの接続に使用されるローカルアドレス。 |
upstream_service_time | long | アップストリームサービスがリクエストを処理するのにかかった時間 (ミリ秒単位)。これには、ゲートウェイがアップストリームサービスにアクセスするためのネットワーク遅延と、アップストリームサービス自体の処理時間が含まれます。 |
upstream_transport_failure_reason | string | アップストリームサービスへの接続が失敗した理由。 |
user_agent | string | HTTP リクエストの User-Agent ヘッダー。 |
x_forwarded_for | string | HTTP リクエストの |
次のステップ
Cloud-native API Gateway は、REST API、HTTP API、WebSocket API など、複数の API タイプをサポートしています。各 API タイプに対して、ルーティングルールやポリシーを設定できます。
サービスを作成すると、バックエンドサービスがゲートウェイに追加され、ゲートウェイはバックエンドサービスのエンドポイントを一元的に取得して管理します。
ゲートウェイ ルートを設定して内部サービスを外部に公開するには、「HTTP API を使用して Container Service for Kubernetes (ACK) のアプリケーションにアクセスする」をご参照ください。
Cloud-native API Gateway の使用中に問題が発生した場合は、「よくある質問」をご参照ください。