最近のブログ投稿で、Muxは、Kubernetesと長時間のHTTP/2接続でのスケーリングと負荷分散の問題を解決するためにEnvoyの使用とEnvoyをシステムにどのように組み込むかについて説明した。Muxは、ビデオストリーミングインフラストラクチャのソフトウェアとパフォーマンス分析に重点を置いている。彼らのサービスは、UdemyやTEDなどの人気のあるアプリケーションで使用されている。
MuxはKubernetesでサービスを実行し、サービス間の通信は、長時間有効なHTTP/2接続上でgRPCを介して実行される。残念なことに、Kubernetesは長時間接続の負荷分散を行わないため、一部の Pod は他よりも多くのリクエストを受信する可能性がある。その結果、負荷が不均一になり、水平方向のスケーリングが無効になる。Muxのエンジニアリングチームは手動で再起動することで問題を軽減できるが、この解決策は望ましいものではなくまた持続できないものであることが明らかだ。
Muxのエンジニアリングチームは、Kubernetesでの長時間接続のスケーリングに関するブログで提案したように、gRPCクライアントライブラリの機能を利用してクライアントサイドの負荷分散を適切に処理することを始めに検討した。このソリューションのエレガントさは、サービス自体の外に最小限の依存関係や障害点の追加が必要なだけであることだ。ただし、いくつかの重大な欠点もある。まず、MuxのgRPCサービスは複数の言語とフレームワークがある。したがって、Muxのエンジニアリングチームは、クライアントサイドの負荷分散を何度も実装する必要がある。さらに、ほとんどのクライアントベースのソリューションは開発のやや初期段階にあり、Muxの主要言語であるGoの公式のgRPCバランサはまだ実験的なものとしてリストされていた。しかも最後に、分散システム環境でのクライアントベースのアプローチでは、さまざまな言語の複数の異なるサービス間でバージョンと機能の互換性が必要であり、将来の保守ではさまざまな標準化の課題が生じる。
クライアントベース戦略、出典: Mux’s engineering blog
完全なサービスメッシュのソリューションは、Envoyなどのネットワークレベルのコンポーネントと、ネットワークレベルのコンポーネント上で実行される構成およびコントロールプレーンとして機能するIstio、Linkerd、Maesh、Consul Connectなどの管理レイヤを組み合わせる。ただし、Muxは、かなりの複雑さを伴うことや運用と保守に追加のコストがかかることから、このソリューションを却下した。さらに、これらのサービスの一部は、1.8 や 1.12 などの古いバージョンにあったMuxのKubernetesクラスタの古い部分との互換性がなかった。
完全なサービスメッシュ戦略、出典: Mux’s engineering blog
Muxは、言語非依存で、新しいサービスや継続的なメンテナンスに過度のオーバーヘッドをもたらさないというニーズを満たす、中立的なソリューションを見つけたいと考えていた。Muxの妥協案は、Envoyをインフラストラクチャのネットワークプロキシとして使用し完全なサービスメッシュを使用しない方法でデプロイすることだった。Muxには、EnvoyをスタンドアロンのKubernetesデプロイメント、デーモンセット、またはサイドカーコンテナとしてデプロイするオプションがあった。
スタンドアロンデプロイメントのセットアップで、MuxはgRPCリクエストを行うすべてのサービスのリクエストをフィールド化するEnvoyインスタンスのプールを作成する。ただし、このアプローチでは、すべてのgRPCリクエストにホップを追加する必要がある。これは、ネットワークパフォーマンスに影響があり、十分なプロキシ容量を確保するために追加の自動スケーリングの構成が必要だ。
デーモンセットアプローチは、gRPCリクエストを行うPodを実行するすべてのホストに、すべてのトラフィックをプロキシする実行中のEnvoy Podがあることを保証することで、追加のネットワークホップの可能性を軽減するが、このアプローチには、利点を上回る複数のリスクがある。この単一デーモンセットPodが失われると、ホスト上のすべてのアウトバウンドgRPCリクエストが失敗する。さらに、ホスト上の変動するネットワークトラフィックは、単一Podによってのみ処理されるため、水平スケーリングがより困難になる。
サイドカーコンテナアプローチは、スタンドアロンのデプロイメントセットアップとデーモンセットアプローチの両方の課題を解決する。このアプローチで、MuxはEnvoyをサイドカーコンテナとしてプライマリサービスのPodに追加し、フラグや環境変数をプライマリコンテナに追加して、gRPCネットワーキングのEnvoyサイドカーのローカルホストアドレスを指すように構成する。この設定により、サービスの自動スケーリングに加えて、ネットワークプロキシ容量のスケーリングが可能になる。
サイドカー/プロキシベース戦略、出典: Mux’s engineering blog
このセットアップを実行してロールアウトしてから、MuxではgRPCとKubernetesの負荷分散の問題を認識しなくなった。Muxは、Envoyを介して無料のいくつかの優れたネットワーキングメトリックも取得できた。彼らは、gRPCサービス以外でもEnvoyプロキシを注入する他のいくつかの有用なユースケースを見つけることができた。