クラウドネイティブ API ゲートウェイインスタンスの作成 - API Gateway

クラウドネイティブ API ゲートウェイインスタンスは、サービスの公開、トラフィック管理、セキュリティ保護、API ライフサイクル管理を可能にします。このトピックでは、クラウドネイティブ API ゲートウェイインスタンスを作成する方法について説明します。

基本構成

初回アクティベーションには権限付与が必要です

システムポリシー:

AliyunServiceRoleForNativeApiGw: ACK、VPC、SLB、MSE などの他のクラウドサービスへのアクセスを許可します。

AliyunServiceRolePolicyForNativeApiGwInvokeFC: Function Compute (FC) サービスへのアクセスを許可します。

クラウドネイティブ API ゲートウェイコンソールにログインし、左側のナビゲーションウィンドウで [システム管理] をクリックし、[インスタンス] ページで [インスタンスの作成] をクリックします。[クラウドネイティブ API ゲートウェイ] 購入ページで、次のパラメーターを構成します。

[プロダクトタイプ]: [従量課金] と [サブスクリプション] をサポートしています。詳細については、「課金の概要」をご参照ください。
- 従量課金: 課金は時間単位で計算されます。使用時間が 1 時間未満の場合は、1 時間分の料金が請求されます。決済は 1 時間に 1 回行われます。
- サブスクリプション: 課金は月単位で計算されます。年間サブスクリプションは 12 か月として計算されます。
[リージョン]: ゲートウェイが配置されるリージョンを選択します。これは、バックエンドサービスが配置されているリージョンと同じである必要があります。インスタンスの作成後にリージョンを変更することはできません。
[インスタンス名]: ゲートウェイ名をカスタマイズします。test や order-prod など、環境または環境とビジネスタイプを示す名前を使用することをお勧めします。名前の長さは最大 64 文字です。

[インスタンスの仕様]: キャパシティ評価を実行した後、実際のビジネス要件に基づいてノード仕様を選択します。

異なるノード仕様のキャパシティしきい値

次の表に、さまざまなインスタンスの仕様のキャパシティしきい値を示します。ゲートウェイキャパシティメトリックの値が警告しきい値よりも小さい場合、サービスレベルアグリーメント (SLA) の要件は完全に満たされます。主要なビジネスでは、ゲートウェイキャパシティメトリックの値を安全しきい値よりも小さく保つことをお勧めします。これにより、システムの安定性が確保されます。

安全しきい値: 安全しきい値以上では、ゲートウェイインスタンスはトラフィックが 2 倍になっても高いスループットと低いレイテンシーを確保できます。
警告しきい値: インスタンスが警告しきい値に達すると、レイテンシーが増加し、トラフィックの急増時に安定性のリスクにさらされます。
シングルノードインスタンスには SLA 保証は提供されません。通常、テストシナリオに推奨されます。本番ビジネスにはマルチノードインスタンスを使用するようにしてください。

ゲートウェイインスタンスタイプ	クライアント接続		1 秒あたりの新規 HTTPS 接続数		CPU 使用率		メモリ使用量
ゲートウェイインスタンスタイプ	安全レベル	警告レベル	安全レベル	警告レベル	安全レベル	警告レベル	安全レベル	警告レベル
apigw.dev.x1	12,000	24,000	400	800	30%	60%	75%	75%
apigw.small.x1	24,000	48,000	800	1,600	30%	60%	75%	75%
apigw.small.x2	48,000	96,000	1,600	3,200	30%	60%	75%	75%
apigw.small.x4	96,000	192,000	3,200	6,400	30%	60%	75%	75%
apigw.medium.x1	192,000	384,000	6,400	12,800	30%	60%	75%	75%
apigw.medium.x2	384,000	768,000	12,800	25,600	30%	60%	75%	75%
apigw.medium.x3	576,000	1,152,000	19,200	38,400	30%	60%	75%	75%
apigw.large.x1	768,000	1,536,000	25,600	51,200	30%	60%	75%	75%
apigw.large.x2	1,536,000	3,072,000	51,200	102,400	30%	60%	75%	75%
apigw.large.x3	2,304,000	4,608,000	76,800	153,600	30%	60%	75%	75%
apigw.large.x4	3,072,000	6,144,000	102,400	204,800	30%	60%	75%	75%

[リソースグループ]: 既存のリソースグループまたはデフォルトのリソースグループを選択します。リソースグループを使用して、クラウドアカウントのリソースを分類および管理します。個々のリソースを個別に管理する必要なく、グループレベルでアクセスの制御、リソースのプロビジョニング、およびモニタリングを実行します。新しいリソースグループを作成するには、[リソースグループの作成] をクリックします。
[ネットワークタイプ]: [パブリック]、[プライベート]、および [パブリック + プライベート] をサポートしています。
- [パブリック]: パブリックを選択した場合、Cloud Data Transfer (CDT) はアクセスに対して BGP (マルチ ISP) サービスを提供し、パブリックトラフィック料金を請求します。詳細については、「インターネットデータ転送」をご参照ください。
- [プライベート]: プライベートネットワークを介して転送されるデータは無料です。
- [パブリック + プライベート]: パブリック + プライベートを選択した場合、データはインターネットまたはプライベートネットワークを介して転送できます。インターネットを介して転送されるデータは、アクセスに対して BGP (マルチ ISP) サービスを提供する CDT によってパブリックトラフィック料金が請求されます。プライベートネットワークを介して転送されるデータは無料です。
[Virtual Private Cloud]: インスタンスが実行される Virtual Private Cloud (VPC) を選択します。クラウドネイティブ API ゲートウェイインスタンスは、インスタンスがアクセスするサービスと同じ VPC に存在する必要があります。
[ゾーンの選択]: [自動割り当て] または [手動で選択] をサポートしています。
- [自動割り当て]: ゲートウェイノードをデプロイするための [VSwitch] を選択すると、システムは自動的に 2 つのゾーンを割り当ててゲートウェイノードをデプロイします。
- [手動で選択]: ゲートウェイノードをデプロイするための [ゾーン] と [VSwitch] を手動で選択します。

構成が完了したら、[今すぐ購入] をクリックします。[注文の確認] ページで、クラウドネイティブ API ゲートウェイの構成詳細を確認し、[今すぐアクティブ化] をクリックします。
インスタンスの作成には 1 ～ 5 分かかる場合があります。
クラウドネイティブ API ゲートウェイコンソールの [インスタンス] ページで、作成されたゲートウェイインスタンスのステータスを確認します。ステータスが [実行中] と表示されたら、ゲートウェイは正常に作成されています。

高度な特徴

ゲートウェイインスタンスを作成する際、ログデータをモニタリングや分析に使用する必要がある場合や、リクエストとレスポンスを圧縮してゲートウェイトラフィックを削減する必要がある場合は、以下の操作を構成できます。Gzip ハードウェアアクセラレーションはインスタンス作成時にのみ有効にでき、後から有効にすることはできませんが、ログサービスには制限はありません。

Gzip ハードウェアアクセラレーションを有効にする

Gzip ハードウェアアクセラレーションとは、専用のハードウェアデバイスを使用してデータを高速に圧縮および展開する技術のことです。Gzip 形式の展開タスクを CPU から専用のハードウェアデバイスにオフロードすることで、処理効率を大幅に向上させ、CPU 負荷を軽減します。

手順

クラウドネイティブ API ゲートウェイの購入ページで、基本構成を完了した後、次のパラメーターを構成し、[今すぐアクティブ化] をクリックします。
- [リージョン]: Gzip ハードウェアアクセラレーションは、杭州、北京、上海、深圳、ウランチャブ、中国 (香港)、シンガポールの各リージョンでサポートされています。
  現在、サポートされているリージョンの一部のゾーンでは、この機能がサポートされていない場合があります。具体的な可用性については、製品購入ページをご参照ください。
- [インスタンスの仕様]: apigw.medium.x1 以上の仕様を選択します。
- [Gzip ハードウェアアクセラレーション]: Gzip ハードウェアアクセラレーションを有効にするために選択します。
インスタンスが正常に作成された後、ターゲットインスタンスの ID/名前をクリックし、左側のナビゲーションウィンドウで [パラメーター構成] をクリックし、[ゲートウェイエンジンパラメーター] セクションの [EnableGzipHardwareAccelerate] パラメーターを編集します。
購入時に [Gzip ハードウェアアクセラレーションを有効にする] を選択しなかった場合、この構成を有効にすることはできません。
有効にした後、クライアントは Gzip 圧縮データを処理できる必要があります。サポートされているクライアントの場合、リクエストヘッダーに Accept-Encoding: gzip を追加します。

パフォーマンスリファレンス

Gzip 圧縮を有効にすると、有効にする前と比較してどのくらいのトラフィックを節約できますか？

Gzip 圧縮を使用する場合、圧縮率 (圧縮データサイズと非圧縮データサイズの比率) はデータ自体に大きく影響されます。圧縮率が低いほど圧縮効果が高く、圧縮率が高いほど圧縮効果が低くなります。

通常、データに多くの反復パターンや構造 (テキスト内の文字、単語、句読点など) が含まれている場合、Gzip 圧縮はより効果的に機能し、圧縮率が低くなります。逆に、ランダム性が高くエントロピーが高いデータ (画像、動画、圧縮ファイルなど) の場合、内部の反復性が低いため、圧縮率は通常高くなり、圧縮効果は限定的です。

Gzip 圧縮を使用する場合、ビジネス属性が異なるため、顧客ごとに圧縮率に大きな違いがあります。コアリージョンで Gzip が有効になっているインスタンスの統計によると、ほとんどのインスタンスの圧縮率は 10% から 50% の間であり、Gzip を有効にすると、これらのユーザーは平均で 50% 以上のトラフィックを節約できることを意味します。

Gzip がすでに有効になっている場合にハードウェアアクセラレーションを使用すると、どのくらいのインスタンスリソースを節約できますか？

Gzip ハードウェアアクセラレーションを有効にすると、ゲートウェイは専用のハードウェアデバイスを使用して圧縮するため、CPU リソースを節約できます。以下のストレステストデータは、同じ QPS トラフィックを処理する際に、Gzip ハードウェアアクセラレーションが有効なシングルノードインスタンスと、ソフトウェア Gzip を使用する 4 ノードインスタンスの CPU 消費量を比較したものです。

たとえば、圧縮データは約 120k のサイズの JSON テキストです。

QPS	ハードウェアアクセラレーション Gzip/apigw.medium.x1/シングルノード CPU 消費量	ソフトウェア Gzip/apigw.medium.x1/4 ノード CPU 消費量
2,000	9%	11%
5,000	26%	28%
10,000	56%	56%
13,000	69%	72%

表のデータから、Gzip ハードウェアアクセラレーションを有効化/シングルノード の CPU 消費量は、ソフトウェア Gzip/4 ノード のそれとほぼ同等であることがわかります。これは、元々 4 ノードで処理する必要があったものが、Gzip ハードウェアアクセラレーションを有効にすることで、わずか 1 ノードで処理できるようになり、インスタンスリソースを約 75% 節約できることを意味します。

クラウドネイティブゲートウェイのログ配信を有効にする

ゲートウェイの操作ログを収集、保存、分析する必要がある場合は、ゲートウェイインスタンスの作成中に Simple Log Service (SLS) をアクティブ化して、ログ分析とダッシュボードモニタリングを行うことができます。

基本構成を完了する際に、[Simple Log Service (SLS) を使用] を選択すると、システムが Simple Log Service (SLS) をアクティブ化し、ゲートウェイのログ配信を有効にします。

ログ配信を有効にすると、[可観測性] > [ログセンター] でゲートウェイログを表示できます。

ログフィールドの説明

フィールド名	タイプ	説明
__time__	long	ログが生成された時間。
cluster_id	string	購入したゲートウェイインスタンス。
ai_log	json	Model API、Agent API、MCP API 用に設計されたログフィールド。フィールドは JSON 形式です。このフィールドは他のタイプの API では空です。 api: AI API の名前。 cache_status: Model API でコンテンツキャッシュが有効になっている場合、このフィールドはリクエストがキャッシュにヒットしたかどうかを示します。 consumer: コンシューマー認証が有効になっている場合、このフィールドは現在のリクエストのコンシューマーの ID を記録します。 fallback_from: Model API でフォールバックポリシーが有効になっている場合、このフィールドはリクエストがフォールバックしたルートを記録します。 input_token: LLM リクエストの入力トークンの数。 llm_first_token_duration: LLM リクエストの最初のパケットの応答時間 (RT)。 llm_service_duration: LLM リクエストの全体的な RT。 model: LLM リクエストのモデル名。 output_token: LLM リクエストの出力トークンの数。 response_type: ストリーミングや非ストリーミングなど、LLM リクエストの応答タイプ。 safecheck_status: LLM リクエストの Content Moderation ステータス。 token_ratelimit_status: LLM リクエストがトークンベースのレート制限によってブロックされたかどうかを示します。
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 を生成し、それを `x-request-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 リクエストの `x-forwarded-for` ヘッダー。このヘッダーは通常、HTTP クライアントの送信元 IP アドレスを示します。

次のステップ

クラウドネイティブ API Gateway は、REST API、HTTP API、WebSocket API など、複数の API タイプをサポートしています。ビジネス要件に基づいて、さまざまなタイプの API のルーティングルールまたはポリシーを設定できます。
サービスを作成して、インスタンスにバックエンドサービスを追加できます。その後、インスタンスはバックエンドサービスのエンドポイントを取得して一元管理できます。
内部サービスへの外部アクセスを許可するルーティングが必要な場合は、「HTTP API を使用して ACK のアプリケーションにアクセスする」をご参照ください。
クラウドネイティブ API ゲートウェイの使用に関するよくある質問の詳細については、「FAQ」をご参照ください。