0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

Envoy: HTTP ルーティング

Posted at

tldr

勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントはこちらのディレクトリ以下にあります(ライセンス:Apache License 2.0, NOTICE)。

HTTP ルーティング

Envoy には、高度なルーティングタスクを実行するためにインストールできるHTTPルーターフィルタが含まれています。これは、エッジトラフィックの処理(従来のリバースプロキシ要求処理)と、サービスto Envoyメッシュ(通常は特定のアップストリームサービスクラスタに到達するためのホスト/認証HTTPヘッダーでのルーティングによる)の構築の両方に役立ちます。 Envoyにはフォワードプロキシとして設定する機能もあります。フォワードプロキシ設定では、メッシュクライアントは自分のhttpプロキシをEnvoyになるように適切に設定することで参加できます。上位レベルでは、ルータは着信HTTP要求を受け取り、それをアップストリームクラスタと照合し、アップストリームクラスタ内のホストに接続プールを取得して、その要求を転送します。ルータフィルタは次の機能をサポートします。

  • ドメイン/権限を一連のルーティングルールにマッピングする仮想ホスト。
  • プレフィックスと正確なパスマッチングルール(大文字と小文字の区別と大文字と小文字の区別なし)。正規表現とスラッグのマッチングは、現在サポートされていません。これは、ルーティングルールが互いに矛盾するかどうかをプログラムで判断するのが困難/不可能になるためです。このため、リバースプロキシレベルでの正規表現/スラッグルーティングはお勧めできませんが、将来的には需要に応じてサポートを追加する可能性があります。
  • 仮想ホストレベルでのTLSリダイレクト
  • ルートレベルでのパス/ホストリダイレクション
  • ルートレベルでの直接(プロキシではない)HTTP応答。
  • 明示的なホストの書き換え
  • 選択したアップストリームホストのDNS名に基づく自動ホスト書き換え。
  • 書き換えのプレフィックス。
  • HTTPヘッダーまたはルート設定を介して指定された要求再試行。
  • HTTPヘッダーまたはルート設定を介して指定された要求タイムアウト。
  • ランタイム値を介したトラフィックのアップストリームクラスタ間のトラフィックシフト(トラフィックシフト/分割を参照)。
  • ウェイト/パーセンテージベースのルーティングを使用した複数のアップストリームクラスタ間でのトラフィック分割(トラフィックシフト/分割を参照)。
  • ルーティングルールに一致する任意のヘッダー
  • 仮想クラスタの仕様仮想クラスタは仮想ホストレベルで指定され、標準のクラスタレベルの統計に加えて追加の統計を生成するためにEnvoyによって使用されます。仮想クラスタは正規表現照合を使用できます。
  • 優先度ベースのルーティング
  • ハッシュポリシーベースのルーティング
  • 絶対URLは、非TLSフォワードプロキシでサポートされています。

ルートテーブル

HTTP接続マネージャの設定は、設定されたすべてのHTTPフィルタによって使用されるルートテーブルを所有します。ルータフィルタはルートテーブルの主要なコンシューマですが、他のフィルタも、要求の最終的な宛先に基づいて決定を行いたい場合に備えてアクセス権を持ちます。たとえば、組み込みレート制限フィルタは、ルートテーブルを調べて、グローバルレート制限サービスをルートに基づいて呼び出す必要があるかどうかを判断します。接続マネージャは、その決定がランダム性を含む場合であっても(例えば、実行時構成ルートルールの場合)、ルートを取得するためのすべての呼び出しが特定の要求に対して安定していることを確認する。

再試行セマンティクス

Envoyでは、ルート設定とリクエストヘッダを介した特定のリクエストの両方で再試行を設定できます。以下の構成が可能です。

  • 最大再試行回数:Envoyは何度でも再試行します。各再試行の間に指数バックオフアルゴリズムが使用されます。さらに、すべての再試行は全体の要求タイムアウト内に含まれています。これにより、多数の再試行による長い要求時間が回避されます。
  • 条件の再試行:アプリケーションの要件に応じて、Envoyはさまざまな種類の条件で再試行できます。たとえば、ネットワーク障害、すべての5xx応答コード、べき等4xx応答コードなど
  • ホスト選択の再試行プラグイン:再試行のためにホストを選択するときに、ホスト選択のロジックに追加のロジックを適用するようにEnvoyを設定できます。再試行ホスト述語を指定することは、特定のホストが選択されたとき(例えば、既に試みられたホストが選択されたとき)にホスト選択を再試行することを可能にする。

x-envoy-overloadedの内容によっては、再試行が無効になることがあります。

優先ルーティング

Envoyはルートレベルで優先ルーティングをサポートしています。現在の優先度の実装では、優先度ごとに異なる接続プールと回線遮断設定が使用されます。これは、HTTP / 2要求でも、2つの物理接続が上流のホストに使用されることを意味します。将来的には、Envoyは単一の接続で真のHTTP / 2優先度をサポートするでしょう。

現在サポートされている優先順位は、デフォルトと高いです。

直接の回答

Envoyは「直接」回答の送信をサポートしています。これらは事前設定されたHTTP応答で、上流のサーバーへのプロキシを必要としません。

ルートで直接応答を指定する方法は2つあります。

  • direct_responseフィールドを設定してください。これはすべてのHTTPレスポンスステータスに有効です。
  • リダイレクトフィールドを設定します。これはリダイレクト応答ステータスに対してのみ機能しますが、Locationヘッダーの設定を単純化します。

直接応答にはHTTPステータスコードとオプションの本文があります。 Route設定では、レスポンスボディをインラインで指定するか、ボディを含むファイルのパス名を指定できます。 Route設定がファイルパス名を指定している場合、Envoyは設定のロード時にファイルを読み込み、内容をキャッシュします。

注意

応答本体が指定されている場合、それがインラインで提供されているかファイルで提供されているかにかかわらず、サイズは4KB以下でなければなりません。 Envoyは現在、本文全体をメモリに保持しているため、4KBの制限は、プロキシのメモリ使用量が大きくなり過ぎないようにするためのものです。

response_headers_to_addがルートまたはそれを含む仮想ホストに設定されている場合、Envoyは指定されたヘッダーを直接HTTP応答に含めます。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?