Kubernetes での gRPC トラフィック負荷分散の実装

gRPC サービスを Kubernetes クラスターにデプロイしようとするときに一部のユーザー (私を含む) が直面する課題の 1 つは、適切な負荷分散を実装することです。 gRPC のバランスをとる方法を説明する前に、Kubernetes がすでにこの処理を行っているのに、なぜトラフィックのバランスをとる必要があるのか​​という疑問に答える必要があります。

この記事では、Kubernetes と Golang に焦点を当てます。

Kubernetes で gRPC トラフィックを適切に分散できないのはなぜですか?

gRPC トラフィックのバランスをとるのが難しい主な理由は、人々が gRPC を HTTP として扱うことであり、これが問題の根本です。それらは設計上異なります。 HTTP はリクエストごとに接続を作成して閉じますが、gRPC は長時間存続する TCP 接続で実行される HTTP2 プロトコルを使用するため、複数のリクエストが同じ接続で多重化されるため、バランスをとることがより困難になります。ただし、Kubernetes で gRPC サービスを構成するとバランスの問題が発生する理由はこれだけではありません。よくある誤った設定は次のとおりです。

• gRPC クライアントの設定が正しくありません
• Kubernetes サービスの構成が正しくありません

gRPC クライアントの設定が正しくありません

gRPC クライアントをセットアップする際の一般的な状況は、デフォルト構成を選択することです。これは、1 対 1 の接続タイプでは完全に機能しますが、実稼働環境では期待するほど効果的ではありません。その理由は、デフォルトの gRPC クライアントでは、単純な IP/DNS レコードを使用して接続することができ、ターゲット サービスへの接続が 1 つだけ作成されるためです。

そのため、複数のサーバーとの接続を確立し、接続タイプを 1-1 から 1-N に変換するには、異なる設定が必要です。

デフォルト設定:

 func main(){ conn, err := grpc.Dial("my-domain:50051", grpc.WithInsecure()) if err != nil { log.Fatalf("error connecting with gRPC server: %v", err) } defer conn.Close() cli := test.NewTestServiceClient(conn) rs, err := cli.DoSomething(context.Background(), ...) . . . }

新しい設定:

 func main(){ conn, err := grpc.Dial("my-domain:50051", grpc.WithInsecure()) if err != nil { log.Fatalf("error connecting with gRPC server: %v", err) } defer conn.Close() cli := test.NewTestServiceClient(conn) rs, err := cli.DoSomething(context.Background(), ...) . . . }

ここで注目すべき重要な変更点が 2 つあります。

• アドレス: 最終的に解決されるアドレスは dns:///my-domain:50051 のようになります。この形式が使用されるのは、Dial 機能では Scheme://Authority/Endpoint で構成される宛先を使用できるためです。このケースでは Authority を省略しています。そこで、最初にドメインを解決してその変更を監視し続けたいため、スキームとして DNS を追加しました。リゾルバ オプションは、透過 (デフォルト)、DNS、および手動です。詳細はこちらをご覧ください。
• ロード バランサ オプション: クライアントが複数のサーバーに接続する場合、gRPC クライアントは選択したロード バランシング アルゴリズムに基づいてリクエストを分散できます。

要約すると、ドメイン名が複数の A または AAAA レコードに解決される場合、gRPC クライアントは異なる接続を作成できるようになりました。それだけでなく、リクエストを異なるサーバーに均等に分散できるようになりました。

次に、Kubernetes で動作させる方法について、欠けている部分を見てみましょう。

Kubernetes サービスの構成が正しくありません

Kubernetes でサービスを作成するのは非常に簡単です。以下に示すように、サービスがポッドを動的にグループ化し、リクエストを自動的に分散できるように、サービス名、ポート、セレクターを定義するだけで済みます。

 apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: my-app ports: - name: grpc protocol: TCP port: 50051 targetPort: 50051

以前のセットアップでは、デフォルトの Kubernetes サービスが単一の IP にリンクされた 1 つの DNS レコードのみを作成したことが問題でした。したがって、 nslookup my-service.{namespace}.svc.cluster.local のような操作を実行すると、返されるのは単一の IP であり、一般的な gRPC 実装では接続グラフは次のようになります。

たとえば、デフォルトの Kubernetes サービス接続グラフを使用する場合:

緑の線はクライアントとのアクティブな接続を表し、黄色は非アクティブなポッドを表します。クライアントは Kubernetes サービスと永続的な接続を持ち、サービスは Pod の 1 つと接続していますが、これはサービスが残りの Pod と接続していないことを意味するものではありません。

ヘッドレス サービスを使用してこれを解決してみましょう。

 apiVersion: v1 kind: Service metadata: name: my-service spec: clusterIP: None **this is the key*** selector: app: my-app ports: - name: grpc protocol: TCP port: 50051 targetPort: 50051

ヘッドレス サービスが作成されると、nslookup の見た目が少し変わり、関連付けられているレコード (Pod の IP をサービスにグループ化) が返されるようになり、gRPC クライアントは接続する必要があるサーバーの数をより正確に把握できるようになります。

gRPC クライアントの構成を確認したので、Kubernetes サービスが Pod のセットに関連付けられた IP を返すことがなぜ重要であるかを理解しているはずです。その理由は、クライアントが接続を確立するために必要なすべてのサーバーを確認できるためです。この時点で気付いたかもしれない注意点の 1 つは、バランス調整の責任が Kubernetes 側ではなくクライアント側にあるということです。現時点で Kubernetes に必要な主なことは、サービスに関連付けられた Pod のリストを最新の状態に保つことです。

たとえば、ヘッドレス Kubernetes サービスとの接続図では、接続が少し変更されていることがわかります。ここで、Kubernetes サービスを介して Pod にアクセスする代わりに、Kubernetes サービスを使用してドメイン名に関連付けられた Pod のリストを取得し、Pod と直接接続を確立します。ただし、ポッドに直接接続しているため慌てる必要はありません。クライアントに DNS リゾルバー タイプが設定されており、ヘッドレス サービスによる変更を継続的に監視し、利用可能なポッドとの最新の接続を維持するためです。

サービスメッシュを使用しないのはなぜですか?

可能であれば、サービス メッシュを使用してください。サービス メッシュでは、これらすべての設定が透過的であり、最も重要なのは、プログラミング言語に依存しないことです。主な違いは、サービス メッシュはサイドカー パターンとコントロール プレーンを活用して受信トラフィックと送信トラフィックを調整し、すべてのネットワークとトラフィック タイプ (HTTP、TCP など) を可視化して、リクエストを適切に分散できることです。つまり、サービス メッシュを使用していない場合は、各クライアントから複数のサーバーに直接接続するか、リクエストのバランスを取るために L7 プロキシに接続する必要があります。

追加情報

以前のセットアップは機能しますが、alpine Linux イメージでポッドのローテーションやスケーリングを行うときに接続を再バランスしようとすると問題が発生します。調べてみると、この問題を抱えているのは私だけではないことが分かりました。こことここで、関連する GitHub の問題を確認してください。そこで、独自のリゾルバを作成することにしました。ここで私が作成したカスタム リゾルバを確認できます。私が作成したカスタム リゾルバは非常に基本的なものですが、今のところ問題なく動作しています。 gRPC クライアントはドメイン名の変更を再度リッスンできるようになりました。また、ライブラリに構成可能なリスナーを追加しました。このリスナーは、定期的にドメイン名を検索し、gRPC 接続マネージャーに提供される IP のセットを更新します。貢献したい方は、ぜひご参加ください。

一方、私はさらに深く学びたかったため、独自の gRPC プロキシを作成することにしました (これも多くのことを学びました)。gRPC の http2 基盤を活用することで、proto ペイロード メッセージを変更したり、proto ファイルの定義を知らなくてもプロキシを作成することができました (前述のカスタム パーサーも使用)。

最後に、gRPC クライアントが多数のサーバーに接続する必要がある場合は、プロキシをバランス調整メカニズムとして使用することを強くお勧めします。このメカニズムをメイン アプリケーションに配置すると、多くの接続を開いたままにして再バランス調整しようとするため、複雑さとリソース消費が増大します。最終的なバランスがアプリケーション内にあると想像してください。インスタンスは N 個のサーバー (1-N) に接続されますが、プロキシを使用すると、M 個のプロキシが N 個のサーバー (1-MN) に接続されたインスタンスが作成されます。ここで、M<N です。これは、各プロキシ インスタンスが異なるサーバーへの多数の接続を処理できるためです。