🥇Tinder から Kubernetes への移行

ノート。翻訳。: 世界的に有名な Tinder サービスの従業員は最近、自社のインフラストラクチャを Kubernetes に移行する技術的な詳細を共有しました。このプロセスにはほぼ 8 年かかり、その結果、200 個のコンテナでホストされる 48 のサービスで構成される、KXNUMXs 上での非常に大規模なプラットフォームが立ち上げられました。 Tinder エンジニアはどのような興味深い困難に遭遇し、どのような結果に至りましたか? この翻訳を読んでください。

なぜですか？

ほぼ XNUMX 年前、Tinder はプラットフォームを Kubernetes に移行することを決定しました。 Kubernetes を使用すると、Tinder チームは不変のデプロイメントを通じて最小限の労力でコンテナ化して本番環境に移行できるようになります。 (不変のデプロイメント)。この場合、アプリケーションのアセンブリ、その展開、およびインフラストラクチャ自体はコードによって一意に定義されます。

また、スケーラビリティと安定性の問題の解決策も探していました。スケーリングが重要になると、新しい EC2 インスタンスが起動するまでに数分間待たなければならないことがよくありました。コンテナを起動して、数分ではなく数秒でトラフィックの処理を開始するというアイデアは、私たちにとって非常に魅力的でした。

そのプロセスは困難であることが判明した。 2019 年初頭の移行中に、Kubernetes クラスターがクリティカルマスに達し、トラフィック量、クラスターサイズ、DNS に起因するさまざまな問題に遭遇し始めました。その過程で、200 のサービスの移行と、1000 のノード、15000 のポッド、および 48000 の実行コンテナで構成される Kubernetes クラスターの維持に関連する多くの興味深い問題を解決しました。

どうやって？

2018 年 XNUMX 月以来、私たちは移行のさまざまな段階を経てきました。私たちはすべてのサービスをコンテナ化し、Kubernetes テストクラウド環境にデプロイすることから始めました。 XNUMX 月から、すべての既存サービスを Kubernetes に計画的に移行し始めました。翌年の XNUMX 月までに移行が完了し、現在では Tinder プラットフォームは Kubernetes 上でのみ実行されます。

Kubernetes 用のイメージの構築

Kubernetes クラスター上で実行されるマイクロサービス用のソースコードリポジトリが 30 を超えています。これらのリポジトリ内のコードは、同じ言語用の複数のランタイム環境を備えた異なる言語 (Node.js、Java、Scala、Go など) で記述されています。

ビルドシステムは、各マイクロサービスに完全にカスタマイズ可能な「ビルドコンテキスト」を提供するように設計されています。通常、これは Dockerfile とシェルコマンドのリストで構成されます。それらのコンテンツは完全にカスタマイズ可能であり、同時に、これらすべてのビルドコンテキストは標準化された形式に従って記述されます。ビルドコンテキストを標準化すると、XNUMX つのビルドシステムですべてのマイクロサービスを処理できるようになります。

図1-1。 Builderコンテナによる標準化されたビルドプロセス

ランタイム間で最大限の一貫性を実現するには (実行環境) 開発時とテスト時に同じビルドプロセスが使用されます。私たちは非常に興味深い課題に直面しました。プラットフォーム全体でビルド環境の一貫性を確保する方法を開発する必要がありました。これを実現するために、すべての組み立てプロセスは特別なコンテナ内で実行されます。 ビルダー.

彼のコンテナ実装には高度な Docker テクニックが必要でした。 Builder は、プライベート Tinder リポジトリにアクセスするために必要なローカルユーザー ID とシークレット (SSH キー、AWS 認証情報など) を継承します。ソースを含むローカルディレクトリをマウントして、ビルドアーティファクトを自然に保存します。このアプローチでは、Builder コンテナーとホストの間でビルドアーティファクトをコピーする必要がなくなるため、パフォーマンスが向上します。保存されたビルドアーティファクトは、追加の構成を行わずに再利用できます。

一部のサービスでは、コンパイル環境をランタイム環境にマップするために別のコンテナーを作成する必要がありました (たとえば、Node.js bcrypt ライブラリはインストール中にプラットフォーム固有のバイナリアーティファクトを生成します)。コンパイルプロセス中に、要件はサービス間で異なる場合があり、最終的な Dockerfile はオンザフライでコンパイルされます。

Kubernetes クラスターのアーキテクチャと移行

クラスターのサイズ管理

使用することにしました kube-aws Amazon EC2 インスタンスでの自動クラスター展開用。当初は、すべてが XNUMX つの共通のノードプールで動作していました。私たちは、リソースをより効率的に使用するために、サイズとインスタンスタイプによってワークロードを分離する必要があることにすぐに気づきました。そのロジックは、ロードされた複数のマルチスレッドポッドを実行する方が、多数のシングルスレッドポッドと共存するよりもパフォーマンスの点で予測しやすいことが判明したというものでした。

最終的には次のことに落ち着きました。

大規模な — 監視用（プロメテウス）;
c5.4xラージ - Node.js ワークロード (シングルスレッドワークロード) の場合。
c5.2xラージ - Java および Go (マルチスレッドワークロード) の場合。
c5.4xラージ — コントロールパネル用 (3 ノード)。

移行

古いインフラストラクチャから Kubernetes に移行するための準備手順の XNUMX つは、サービス間の既存の直接通信を新しいロードバランサー (Elastic Load Balancer (ELB)) にリダイレクトすることでした。これらは、Virtual Private Cloud (VPC) の特定のサブネット上に作成されました。このサブネットは Kubernetes VPC に接続されました。これにより、サービスの依存関係の特定の順序を考慮せずに、モジュールを段階的に移行できるようになりました。

これらのエンドポイントは、新しい各 ELB を指す CNAME を持つ DNS レコードの加重セットを使用して作成されました。切り替えるために、Kubernetes サービスの新しい ELB を指す新しいエントリを重み 0 で追加しました。次に、エントリセットの Time To Live (TTL) を 0 に設定しました。この後、古い重みと新しい重みは次のようになります。ゆっくりと調整され、最終的には負荷の 100% が新しいサーバーに送信されました。切り替えが完了すると、TTL 値はより適切なレベルに戻りました。

私たちが持っていた Java モジュールは低 TTL DNS に対応できましたが、Node アプリケーションは対応できませんでした。エンジニアの 60 人は、接続プールコードの一部を書き直し、XNUMX 秒ごとにプールを更新するマネージャーにラップしました。選択したアプローチは非常にうまく機能し、目立ったパフォーマンスの低下はありませんでした。

レッスン

ネットワークファブリックの限界

8 年 2019 月 XNUMX 日の早朝、Tinder プラットフォームが予期せずクラッシュしました。その朝早くに発生したプラットフォームのレイテンシーの無関係な増加に応じて、クラスター内のポッドとノードの数が増加しました。これにより、すべてのノードで ARP キャッシュが枯渇してしまいました。

ARP キャッシュに関連する Linux オプションは XNUMX つあります。

(ソース)

gc_thresh3 - これは厳しい制限です。ログ内に「隣接テーブルオーバーフロー」エントリが出現するということは、同期ガベージコレクション (GC) 後でも、ARP キャッシュに隣接エントリを保存するのに十分なスペースがないことを意味していました。この場合、カーネルは単にパケットを完全に破棄しました。

を使用しておりますフランネル Kubernetes のネットワークファブリックとして。パケットは VXLAN 経由で送信されます。 VXLAN は、L2 ネットワーク上に構築された L3 トンネルです。このテクノロジーは MAC-in-UDP (MAC Address-in-User Datagram Protocol) カプセル化を使用し、レイヤー 2 ネットワークセグメントの拡張を可能にします。物理データセンターネットワーク上のトランスポートプロトコルは、IP と UDP です。

図 2–1。フランネル図 (ソース)

図2-2。 VXLAN パッケージ (ソース)

各 Kubernetes ワーカーノードは、より大きな /24 ブロックから /9 マスクを使用して仮想アドレス空間を割り当てます。各ノードについて、これは次のようになります。手段ルーティングテーブルに 1 つのエントリ、ARP テーブル (flannel.XNUMX インターフェイス上) に XNUMX つのエントリ、およびスイッチングテーブル (FDB) に XNUMX つのエントリ。これらは、ワーカーノードが初めて起動されるとき、または新しいノードが検出されるたびに追加されます。

さらに、ノードとポッド (またはポッドとポッド) の通信は最終的にインターフェイスを経由します。 eth0 (上記のフランネル図に示されているように)。これにより、対応する送信元ホストと宛先ホストごとに ARP テーブルに追加のエントリが作成されます。

私たちの環境では、この種のコミュニケーションが非常に一般的です。 Kubernetes のサービスオブジェクトの場合、ELB が作成され、Kubernetes は各ノードを ELB に登録します。 ELB はポッドについて何も知らないため、選択されたノードがパケットの最終宛先ではない可能性があります。重要なのは、ノードが ELB からパケットを受信すると、ルールを考慮してパケットを考慮するということです。 iptables 特定のサービスのポッドを選択し、別のノード上のポッドをランダムに選択します。

障害が発生した時点では、クラスター内に 605 個のノードがありました。上記の理由により、これは重要性を克服するには十分でした gc_thresh3、これがデフォルトです。これが発生すると、パケットがドロップされ始めるだけでなく、/24 マスクを持つ Flannel 仮想アドレス空間全体が ARP テーブルから消えます。ノードとポッドの通信と DNS クエリが中断されます (DNS はクラスター内でホストされています。詳細については、この記事の後半を参照してください)。

この問題を解決するには、値を増やす必要があります gc_thresh1, gc_thresh2 и gc_thresh3 Flannel を再起動して、不足しているネットワークを再登録します。

予期しない DNS スケーリング

移行プロセス中、DNS を積極的に使用してトラフィックを管理し、古いインフラストラクチャから Kubernetes にサービスを段階的に移行しました。 Route53 では、関連付けられた RecordSet に比較的低い TTL 値を設定します。古いインフラストラクチャが EC2 インスタンスで実行されていたとき、リゾルバー設定は Amazon DNS を指していました。私たちはこれを当然のことと考えており、私たちのサービスや Amazon サービス (DynamoDB など) に対する低い TTL の影響はほとんど注目されませんでした。

サービスを Kubernetes に移行すると、DNS が 250 秒あたり 1000 万件のリクエストを処理していることがわかりました。その結果、アプリケーションでは DNS クエリに対して重大なタイムアウトが継続的に発生するようになりました。これは、DNS プロバイダーを最適化し、CoreDNS に切り替えるという多大な努力にもかかわらず (ピーク時の負荷では 120 コアで実行される XNUMX ポッドに達しました) にもかかわらず発生しました。

他の考えられる原因と解決策を調査したところ、次のことがわかりました。 статью、パケットフィルタリングフレームワークに影響を与える競合状態について説明します。 ネットフィルタ Linuxでは。観察されたタイムアウトとカウンターの増加 挿入_失敗 Flannel インターフェースの結果は論文の調査結果と一致していました。

この問題は、送信元および宛先ネットワークアドレス変換 (SNAT および DNAT) とその後のテーブルへのエントリの段階で発生します。 コンコースラック。内部で議論され、コミュニティによって提案された回避策の XNUMX つは、DNS をワーカーノード自体に移動することでした。この場合：

トラフィックはノード内に留まるため、SNAT は必要ありません。インターフェイス経由でルーティングする必要はありません eth0.
宛先 IP はノードに対してローカルであり、ルールに従ってランダムに選択されたポッドではないため、DNAT は必要ありません。 iptables.

私たちはこのアプローチを貫くことにしました。 CoreDNS は Kubernetes の DaemonSet としてデプロイされ、ローカルノード DNS サーバーを Kubernetes に実装しました。 resolve.conf フラグを設定して各ポッド --cluster-dns チーム キューブレット 。この解決策は、DNS タイムアウトに対して効果的であることが判明しました。

ただし、依然としてパケット損失とカウンターの増加が見られました。 挿入_失敗 フランネルインターフェイスで。 DNS トラフィックのみ SNAT や DNAT を排除できたため、この問題は回避策の実装後も継続しました。他のタイプのトラフィックでは競合状態が維持されました。幸いなことに、パケットのほとんどは TCP なので、問題が発生しても再送信されるだけです。私たちは、あらゆるタイプのトラフィックに適したソリューションを見つけるためにまだ努力しています。

Envoy を使用した負荷分散の向上

バックエンドサービスを Kubernetes に移行すると、ポッド間の負荷の不均衡に悩まされ始めました。 HTTP キープアライブにより、ロールアウトされた各デプロイメントの最初に準備が完了したポッドで ELB 接続がハングすることがわかりました。したがって、トラフィックの大部分は、利用可能なポッドのごく一部を通過しました。私たちがテストした最初の解決策は、最悪のシナリオに備えて、新しい展開で MaxSurge を 100% に設定することでした。大規模な展開に関しては、その影響はわずかであり、期待できないことが判明しました。

私たちが使用したもう XNUMX つの解決策は、重要なサービスに対するリソース要求を人為的に増やすことでした。この場合、近くに配置されたポッドは、他の重いポッドに比べて操作する余地が大きくなります。資源の無駄になるので、長期的にはうまくいきません。さらに、Node アプリケーションはシングルスレッドであったため、使用できるコアは XNUMX つだけでした。唯一の本当の解決策は、より優れた負荷分散を使用することでした。

私たちは長い間、十分に感謝したいと思っていましたエンボイ。現在の状況では、非常に限定された方法で導入し、すぐに結果を得ることができました。 Envoy は、大規模な SOA アプリケーション向けに設計された、高性能のオープンソースのレイヤー XNUMX プロキシです。自動再試行、サーキットブレーカー、グローバルレート制限などの高度な負荷分散技術を実装できます。 (ノート。翻訳。: これについて詳しくは、こちらをご覧ください。この記事 Envoy をベースにした Istio について。)

次の構成を思いつきました。ポッドごとに Envoy サイドカーと XNUMX つのルートを持ち、ポート経由でクラスターをローカルでコンテナーに接続します。潜在的なカスケードを最小限に抑え、小さなヒット半径を維持するために、サービスごとにアベイラビリティーゾーン (AZ) ごとに XNUMX つずつ、Envoy フロントプロキシポッドのフリートを使用しました。彼らは、特定のサービスの各 AZ 内のポッドのリストを返すだけの、エンジニアの XNUMX 人が作成したシンプルなサービス検出エンジンに依存していました。

次に、サービスフロント Envoy は、XNUMX つの上流クラスターとルートでこのサービス検出メカニズムを使用しました。適切なタイムアウトを設定し、すべてのサーキットブレーカー設定を増やし、最小限の再試行構成を追加して、単一の障害に対処し、スムーズな展開を確保しました。これらの各サービスフロントエンボイの前に TCP ELB を配置しました。メインプロキシレイヤーからのキープアライブが一部の Envoy ポッドでスタックしていたとしても、それらは依然として負荷をより適切に処理でき、バックエンドの minimum_request を通じてバランスをとるように構成されていました。

デプロイメントには、アプリケーションポッドとサイドカーポッドの両方で preStop フックを使用しました。このフックは、サイドカーコンテナーにある管理エンドポイントのステータスをチェックする際にエラーをトリガーし、アクティブな接続を終了できるようにするためにしばらくスリープ状態になりました。

私たちがこれほど迅速に移行できた理由の XNUMX つは、一般的な Prometheus インストールに簡単に統合できた詳細なメトリクスによるものです。これにより、構成パラメータを調整し、トラフィックを再分散している間に何が起こっているかを正確に確認できるようになりました。

結果はすぐに現れ、明らかでした。最もアンバランスなサービスから開始しましたが、現時点ではクラスター内の 12 の最も重要なサービスの前で動作しています。今年は、より高度なサービス検出、サーキットブレーカー、外れ値検出、レート制限、トレースを備えたフルサービスメッシュへの移行を計画しています。

図 3–1。 Envoy への移行中の XNUMX つのサービスの CPU 収束

最終結果

この経験と追加の調査を通じて、私たちは大規模な Kubernetes クラスターの設計、デプロイ、運用における強力なスキルを備えた強力なインフラストラクチャチームを構築しました。すべての Tinder エンジニアは、コンテナをパッケージ化し、アプリケーションを Kubernetes にデプロイするための知識と経験を備えています。

古いインフラストラクチャで追加のキャパシティが必要になったとき、新しい EC2 インスタンスが起動するまで数分待たなければなりませんでした。コンテナーが実行を開始し、数分ではなく数秒以内にトラフィックの処理を開始するようになりました。単一の EC2 インスタンス上で複数のコンテナをスケジュールすると、水平集中も向上します。その結果、2019 年の EC2 コストは昨年に比べて大幅に削減されると予測しています。

移行には 2019 年近くかかりましたが、200 年 1000 月に完了しました。現在、Tinder プラットフォームは、15 のサービス、000 のノード、48 のポッド、および 000 の実行コンテナで構成される Kubernetes クラスター上でのみ実行されます。インフラストラクチャはもはや運用チームの唯一の領域ではありません。当社のエンジニア全員がこの責任を共有し、コードのみを使用してアプリケーションの構築とデプロイのプロセスを制御します。

翻訳者からの追伸

私たちのブログの一連の記事もお読みください。

出所： habr.com

Tinder から Kubernetes への移行