Cloud-native API Gateway は受信リクエストを処理する際、設定されたルートルールを優先度の高い順に評価します。リクエストがルールに一致した場合、ゲートウェイはそのルールで定義されたバックエンドサービスにリクエストを転送します。一致するルールがない場合、ゲートウェイは 404 エラーを返します。
ルートのマッチング優先度
優先順位は次のとおりです:[Associated Domain Name] > [Path] > [Header] > [Query Parameters] > [Created At]。
-
[Associated Domain Name]に基づく場合:ドメイン文字列が長いほど、優先度が高くなります。
-
[Path]に基づく場合:
-
異なる[Match Rule]タイプの場合、優先度は [Equals To] > [Prefix] > [Regular Expression Match] の順になります。
-
同じ[Match Rule]タイプの場合、[Path]文字列が長いほど優先度が高くなります。
-
-
[Header]内のキーと値のペアの総数に基づく場合:ペアの数が多いほど、優先度が高くなります。
-
[Query Parameters]内のキーと値のペアの総数に基づく場合:ペアの数が多いほど、優先度が高くなります。
-
[Created At]に基づく場合:作成日時が早いほど、優先度が高くなります。
同一インスタンス内のすべての API のルートルールは、マッチングの際に一括でソートされ、前述の優先度に基づいて評価されます。異なる API に属するルートも、競合しない限り同じルールに従います。
REST API がプレフィックスルートとして公開される場合、ゲートウェイは API 操作ごとに 1 つのルートを生成しません。API 全体は、API の有効なベースパスにマッチする 1 つのプレフィックスルートに集約されます。そのため、そのルートにはプレフィックスマッチルートとして上記の優先度ルールが適用されます。つまり、一致するパス文字列が長いほど優先度が高くなり、完全一致がプレフィックスよりも優先され、プレフィックスが正規表現よりも優先されます。
REST API、HTTP API、および WebSocket API によって生成されたルートが同じゲートウェイとドメイン名の下に共存する場合、ゲートウェイは最初に通常の REST API ルート、次に HTTP API と WebSocket API ルート、最後にプレフィックスルートとして公開されている REST API をマッチングします。HTTP API または WebSocket API ルートのマッチング範囲が、プレフィックスルートとして公開されている REST API の範囲と重複する場合、完全に一致した HTTP API または WebSocket API ルートが優先されます。
操作手順
-
Cloud-native API Gateway では、インスタンスの外部から、またはインスタンスの内部から、2 つの方法でルートを作成できます。
インスタンスの外部
-
Cloud-native API Gateway コンソールにログインします。ナビゲーションペインで、[API] を選択します。上部メニューで、リージョンを選択します。
-
対象のAPIをクリックします。表示されるドロップダウンリストで、ルートを設定するインスタンスを選択するか、All Instances を選択します。上部の [すべてのインスタンス] ドロップダウンメニューから、対象のインスタンスを選択します。
-
Create Route をクリックします。
インスタンスの内部
-
Cloud-native API Gateway コンソールにログインします。ナビゲーションペインで、Instance を選択します。上部メニューで、リージョンを選択します。
-
Instance ページで、対象のゲートウェイインスタンスのIDをクリックします。ナビゲーションペインで [API] を選択し、対象のAPIをクリックします。
-
Create Route をクリックします。
-
-
Create Route ページでパラメーターを設定し、Save または Save and Publish をクリックします。
説明-
マッチルールは論理ANDで結合されます。指定するルールが多いほど、マッチング範囲は狭くなります。
-
ルートのマッチング優先度は、ルート設定ページでの表示順序に対応します。
パラメーター
説明
[Route Name]
ルートのカスタム名を入力します。
[Route Description]
Add Route Description をクリックして、ルートの説明を入力します。
[Domain Name]
-
ルートのマッチ対象となるドメインを1つ以上選択します。
-
新しいドメインを作成するには、[ドメインの追加] をクリックし、表示されるパネルで作成します。
[Path]
HTTPリクエスト内でマッチング対象とするパスパラメーターを指定します。
-
同じマッチルールタイプの場合、パス文字列が長いほど優先度が高くなります。
-
異なるマッチルールタイプの場合、優先度は [Equals To] > [Prefix] > [正規表現マッチング] の順になります。
-
[Equals To]:リクエストパスが完全に一致する必要があります。たとえば、
/userと完全に一致する必要があります。 -
[Prefix]:リクエストパスが指定されたプレフィックスで始まる必要があります。たとえば、
/userなどです。 -
[正規表現マッチング]:リクエストパスが指定された正規表現と一致する必要があります。
-
[Method]
HTTPリクエスト内でマッチング対象とするメソッドを指定します。複数のHTTPメソッドを選択できます。デフォルトは ANY です。
[Header]
HTTPリクエスト内でマッチング対象とするヘッダーパラメーターを指定します。同じマッチルールタイプの場合、キーと値のペアの総数が多いルールほど優先度が高くなります。
[Query Parameters]
HTTPリクエスト内でマッチング対象とするクエリパラメーターを指定します。同じマッチルールタイプの場合、キーと値のペアの総数が多いルールほど優先度が高くなります。
[Instance]
ルートを有効にする Cloud-native API Gateway インスタンスを選択します。
[Scenario]
このルートのターゲットサービスタイプを選択します。
-
基本:[Single Service]
-
グレースケールリリース:[By Percentage (Multi-service)]、[Tag (Tag-based Routing)]
-
その他:モック、[Redirect]
さまざまなタイプのターゲットサービスの詳細については、「ルート」をご参照ください。
説明すべての重み付けターゲットサービスのトラフィックの重みの合計は、100%にする必要があります。
[Backend Services]
関連付けるバックエンドサービスとポートを選択します。
説明-
Associated Service をクリックして、パネルでソースとサービスを選択できます。
-
ソースタイプごとに、追加できるソースの数に異なる制限があります。
-
Container Service for Kubernetes (ACK) の場合、最大 5 つのソースを追加できます。
-
Nacos または Zookeeper のソースは 1 つしか追加できません。
-
[Timeout Period (seconds)]
タイムアウト期間を入力します。デフォルトは 60 秒です。値 0 はタイムアウトが無効になることを示します。
フォールバック
フォールバックサービスを指定します。ルートのバックエンドサービスに使用可能なノードがない場合、ゲートウェイは元のリクエストを指定されたフォールバックサービスにルーティングします。
説明現在、フォールバック機能はHTTPサービス間でのみサポートされています。
[Retry Times]
リトライ回数を入力します。デフォルトは 2 です。値 0 はリトライを無効にします。
[Retry Condition]
リトライをトリガーする条件を選択します。
[Retry Status Code]
リトライをトリガーするステータスコードを 1 つ以上追加します。
-