grpc のリバースプロキシとして nginx を使用する場合の落とし穴の概要

背景

ご存知のとおり、nginx は高性能な Web サーバーであり、負荷分散やリバースプロキシによく使用されます。いわゆるリバースプロキシは、フォワードプロキシに対応します。フォワードプロキシは、従来の意味での「プロキシ」です。たとえば、通常の状況では、中国では Google にアクセスできません。アクセスする必要がある場合は、プロキシのレイヤーを介して転送する必要があります。このフォワードプロキシはサーバー (つまり Google) を表し、リバースプロキシはクライアント (つまりユーザー) を表します。ユーザーのリクエストが nginx に到達すると、nginx はユーザーのリクエストを実際のバックエンドサービスにプロキシし、結果をユーザーに返します。

(画像はWikipediaより)

フォワードプロキシとリバースプロキシは、実際にはユーザーの観点から定義されます。フォワードは、ユーザーが要求するサービスをプロキシすることを意味し、リバースとは、ユーザーがサービスへの要求を開始するようにプロキシすることを意味します。両者の間には非常に重要な違いがあります。

フォワードプロキシサーバーは要求元を認識せず、リバースプロキシ要求元はサーバーを認識しません。
上記の例について考えてみましょう。プロキシ経由で Google にアクセスすると、Google はリクエストがプロキシサーバーから送信されたことしか感知できず、ユーザーを直接感知することはできません (もちろん、Cookie などを通じて追跡することはできます)。nginx リバースプロキシを使用する場合、リクエストがどのバックエンドサーバーに転送されるかはわかりません。

nginx をリバースプロキシとして使用する最も一般的なシナリオは、よく知られている http プロトコルです。nginx.conf ファイルを構成することで、リバースプロキシルールを簡単に定義できます。

ワーカープロセス 1;

イベント {
    ワーカー接続 1024;
}

http {
    mime.types を含めます。
    デフォルトタイプ アプリケーション/オクテットストリーム;

    サーバー{
        聞く 80;
        server_name ローカルホスト;

        
        位置 / {
            proxy_pass http://ドメイン;
        }
    }
}

Nginx は 1.13.10 以降で gRPC プロトコルのリバースプロキシをサポートしており、設定も同様です。

ワーカープロセス 1;

イベント {
    ワーカー接続 1024;
}

http {
    mime.types を含めます。
    デフォルトタイプ アプリケーション/オクテットストリーム;

    サーバー{
        81 http2 を聴く;
        server_name ローカルホスト;

        
        位置 / {
            grpc_pass http://ip;
        }
    }
}

しかし、需要シナリオがより複雑になると、nginx の gRPC モジュールには実際には多くの落とし穴があり、実装能力は http ほど完全ではないことがわかります。http のソリューションを適用すると、問題が発生します。

シナリオ

当初、私たちのシナリオは非常にシンプルでした。gRPC プロトコルを通じてシンプルな C/S アーキテクチャを実装しました。

ただし、この単純な直接接続は、一部のシナリオでは実現できません。たとえば、クライアントとサーバーが 2 つのネットワーク環境にあり、相互に接続されていない場合などです。この場合、単純な gRPC 接続を介してサービスにアクセスすることはできません。 1 つの解決策は、上記の nginx リバースプロキシ gRPC メソッドを使用して、中間プロキシサーバーを介して転送することです。

nginx プロキシは、両方の環境にアクセス可能なクラスターにデプロイされるため、ネットワーク環境間での gRPC アクセスが可能になります。次の質問は、このルーティングルールをどのように構成するかということです。初期の gRPC ターゲットノードは明確であり、server1 と server2 の IP アドレスであることに注意してください。中間に nginx プロキシのレイヤーが追加されると、クライアントによって開始された gRPC 要求のオブジェクトはすべて nginx プロキシの IP アドレスになります。クライアントが nginx との接続を確立した後、nginx はリクエストを server1 に転送するか server2 に転送するかをどのように判断するのでしょうか? (ここで、server1 と server2 は、単に同じサービスの冗長展開ではありません。ユーザー ID などの要求の属性に基づいて誰が応答するかを決定する必要があるため、負荷分散を使用して応答要求をランダムに選択することはできません。)

解決

http プロトコルの場合、実装方法は多数あります。

パスによる差別化

リクエストはパスにサーバー情報を追加します (例: /server1/service/method)。その後、nginx はリクエストを転送するときに元のリクエストを復元します。

ワーカープロセス 1;

イベント {
    ワーカー接続 1024;
}

http {
    mime.types を含めます。
    デフォルトタイプ アプリケーション/オクテットストリーム;

    サーバー{
        聞く 80;
        server_name ローカルホスト;

        場所 ~ ^/server1/ {
            proxy_pass http://domain1/;
        }
        
        場所 ~ ^/server2/ {
            proxy_pass http://domain2/;
        }
    }
}

http://domain/ の末尾のスラッシュに注意してください。このスラッシュがない場合、要求されたパスは /server1/service/method となり、サーバーは /service/method の要求にのみ応答できるため、404 エラーが発生します。

リクエストパラメータによる差別化

リクエストパラメータに server1 の情報を入れることもできます:

ワーカープロセス 1;

イベント {
    ワーカー接続 1024;
}

http {
    mime.types を含めます。
    デフォルトタイプ アプリケーション/オクテットストリーム;

    サーバー{
        聞く 80;
        server_name ローカルホスト;

        場所 /サービス/メソッド {
            $query_string ~ x_server=(.*) の場合 {
                プロキシパス http://$1;
            }
        }
    }
}

しかし、gRPC の場合はそれほど単純ではありません。まず、gRPC は URI の書き込みをサポートしていません。nginx によって転送されたリクエストは元のパスを保持し、転送時にパスを変更することはできません。つまり、上記の最初の方法は実行できません。次に、gRPC は HTTP 2.0 プロトコルに基づいています。HTTP2 には queryString の概念がありません。リクエストヘッダーには、/service/method などのリクエストパスを表す項目があります。このパスはリクエストパラメータを運ぶことができません。つまり、パスを /service/method?server=server1 のように記述することはできません。つまり、上記の 2 番目の方法も実行不可能であるということです。

HTTP2:path のリクエストヘッダーはリクエストのパスを指定するので、:path を直接変更しないのはなぜでしょうか。

ワーカープロセス 1;

イベント {
    ワーカー接続 1024;
}

http {
    mime.types を含めます。
    デフォルトタイプ アプリケーション/オクテットストリーム;

    サーバー{
        80 http2 を聴く;
        server_name ローカルホスト;

        場所 ~ ^/(.*)/service/.* {
            grpc_set_header:パス/service/$2;
            grpc_pass http://$1;
        }
    }
}

しかし、実際に検証してみると、この方法は実行不可能であることがわかります。:path のリクエストヘッダーを直接変更すると、サーバーがエラーを報告します。考えられるエラーの 1 つは次のとおりです。

rpc エラー: コード = 利用不可、説明 = 不正なゲートウェイ: HTTP ステータスコード 502、トランスポート: 予期しないコンテンツタイプ「text/html」を受信しました

パケットをキャプチャした後、grpc_set_header は :path の結果を上書きせず、新しいリクエストヘッダーを追加したことがわかりました。これは、リクエストヘッダーに 2 つの :path があるのと同じです。これが、サーバーが 502 エラーを報告した理由である可能性があります。

困ったときは、gRPC のメタデータ機能を思いつきます。クライアント側のメタデータにサーバー情報を保存し、nginx ルーティング時にメタデータ内のサーバー情報に従って対応するバックエンドサービスに転送することで、ニーズを満たすことができます。 Go 言語の場合、メタデータを設定するには、PerRPCCredentials インターフェースを実装し、接続を開始するときにこの実装クラスのインスタンスを渡す必要があります。

タイプ extraMetadata 構造体 {
    IP文字列
}

func (c extraMetadata) GetRequestMetadata(ctx context.Context, uri ...string) (map[string]string, error) {
    マップ[文字列]文字列を返す{
        「x-ip」：c.Ip、
    }, なし
}

func (c extraMetadata) RequireTransportSecurity() bool {
    偽を返す
}

関数main(){
    ...
    // nginxProxy は nginx プロキシの IP またはドメイン名アドレスです var nginxProxy string
    // serverIp はリクエスト属性に基づいて計算されたバックエンドサービスの IP アドレスです
    var serverIp 文字列
    con、err := grpc.Dial(nginxProxy、grpc.WithInsecure()、
        grpc.WithPerRPCCredentials(extraMetadata{Ip: serverIp}))
}

次に、nginx 構成のこのメタデータに従って、対応するサーバーに転送します。

ワーカープロセス 1;

イベント {
    ワーカー接続 1024;
}

http {
    mime.types を含めます。
    デフォルトタイプ アプリケーション/オクテットストリーム;

    サーバー{
        80 http2 を聴く;
        server_name ローカルホスト;

        場所 ~ ^/service/.* {
            grpc_pass grpc://$http_x_ip:8200;
        }
    }
}

ここで、渡した x-ip メタデータ情報を参照するために、構文 $http_x_ip が使用されていることに注意してください。この方法は効果的であることが証明されており、クライアントは nginx プロキシを介してサーバーの gRPC サービスに正常にアクセスできます。

要約する

nginx の gRPC モジュールに関するドキュメントが少なすぎます。公式ドキュメントでは、いくつかの指示の目的のみが記載されており、メタデータメソッドについては説明されていません。また、このトピックについて触れているオンラインドキュメントもほとんどないため、トラブルシューティングに 2、3 日かかりました。同じ問題に遭遇した人々の役に立つことを願って、ここでプロセス全体を要約します。

grpc のリバースプロキシとして nginx を使用する際の落とし穴に関するこの記事はこれで終わりです。より関連性の高い nginx grpc リバースプロキシコンテンツについては、123WORDPRESS.COM で以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後も 123WORDPRESS.COM を応援していただければ幸いです。

以下もご興味があるかもしれません: