UAEK における Istio の実践的変革

ServiceMesh が必要な理由は何ですか?

UCloud App Engine on Kubernetes（以下、「UAEK」といいます）は、UCloudが社内で構築したKubernetesベースのコンピューティングリソース配信プラットフォームです。高可用性、データセンター間の災害復旧、自動スケーリング、3次元監視、ログ収集、簡単な運用と保守などの特徴を備えています。コンテナ技術を活用して社内の研究開発や運用保守の効率を向上させ、開発者がビジネスの研究開発そのものにより多くのエネルギーを注ぐことができるようにすることを目指しています。同時に、運用保守部門は、リソースのスケーリング、グレースケールのリリース、バージョンアップ、監視、アラームなどの日常的なタスクをより落ち着いて処理できるようになります。

Kubernetes はもともと自動展開、スケーリング、コンテナ化のために設計されたものであり、UCloud UAEK チームが IPv6 ネットワーキングの研究と設計の実装を完了した後、成熟したコンテナ管理プラットフォームが北京の第 2 地域の複数のアベイラビリティ ゾーンですぐに正式にリリースされました。アプリケーション サービスを展開するために仮想マシンを申請して管理するという従来の方法と比較すると、Kubernetes は、便利で柔軟な自動スケーリングや手の届く範囲にあるマイクロサービス アーキテクチャなど、実際の利便性をもたらし、シンプルな構成で可用性ゾーン全体にわたる災害復旧を実現できます。

ただし、マイクロサービスは、サービス検出、監視、グレースケール制御、過負荷保護、リクエスト呼び出し追跡など、システム アーキテクチャに多くの新しい問題をもたらします。私たちは、サービス検出とクライアント負荷分散を実現するために、Zookeeper クラスターを運用および保守することに慣れています。 UAEK を使用すると、Zookeeper の運用と保守の作業を回避できますか?業務の運用状況を監視するには、コードにバイパス レポート ロジックを追加する必要があります。 UAEK を使用して、侵入やゼロ結合なしで監視とレポートを実現できますか?

さらに、過去には、システム モジュール間の多くの呼び出しにヒューズ保護戦略が欠如していたため、ピーク トラフィックによってヒューズがダウンしていました。 UAEK を使用すると、ビジネス側は大規模な変革を回避できますか?これまで、問題のトラブルシューティング、特に時間のかかるリンクのトラブルシューティングは、常に時間がかかり、手間のかかる作業でした。 UAEK を使用すると、ボトルネックを見つけるための便利なツールが提供されますか?

明らかに、安定した Kubernetes プラットフォームだけではこれらの問題を解決するのに不十分です。そのため、UAEK プロジェクトの開始時に、チームは ServiceMesh を必ず達成すべき目標として設定しました。 UAEK にデプロイされた TCP バックグラウンド サービスは、ServiceMesh によってもたらされる次の機能を利用できます。

• SideCar モードの展開、ゼロ侵入、マイクロサービス ガバナンス コードとビジネス コードの完全な分離。
• Kubernetes プラットフォームに統合されたサービス検出メカニズムと負荷分散スケジューリング。
• レイヤー 7 サービス情報に基づいて、柔軟でリアルタイム、再起動不要、グレースケールのトラフィック管理機能を提供します。
• 監視およびアクセス ポリシー制御のための統合抽象データ レポート API レイヤーを提供します。
• 分散リクエスト リンク追跡システムを使用して、バグを迅速に追跡し、システム パフォーマンスのボトルネックを特定します。
• 過負荷保護メカニズム。リクエスト数がシステム設計容量を超えた場合に自動的に回路ブレーカーをトリガーできます。
• サービスがオンラインになる前に障害シミュレーション注入演習スクリプトを提供し、事前に障害処理訓練を実施できます。
• このように、UAEK を使用してアプリケーション サービスを展開した後、アカウントごとに小規模なグレースケール起動から開始し、継続的な監視と観察を通じて、異常なバージョンのロールバック、グレースケール範囲の拡張、完全なリリース、過負荷保護、異常な要求の場所の追跡などの情報を簡単に把握できます。

なぜ Istio なのか?

ServiceMeshの実装に関しては、Istioに注目しました。予備調査とテストを通じて、Istio のいくつかの機能が UAEK のニーズを十分に満たすことができることがわかりました。

• ***Kubernetes プラットフォームをサポートします。
• 制御プレーンとデータ転送プレーンは分離されています。
• サイドカーの展開では、すべてのサービス間呼び出しトラフィックを無制限に制御します。
• Sidecar 実装として Envoy を使用します。 Envoy は C++11 で開発され、イベント駆動型およびマルチスレッド メカニズムに基づいて実行されます。 NGINX に匹敵する優れたパフォーマンスと強力な同時実行性を備えています。
• ビジネス コードおよび構成ファイルへの侵入はゼロです。
• シンプルな構成、簡単な操作、完全な API。

サービス メッシュ全体は、コントロール パネルとデータ プレーンの 2 つの部分に分かれています。データ プレーンは、アプリケーション ポッドに挿入された Envoy コンテナを指し、プロキシ スケジューリング モジュール間のすべてのトラフィックを担当します。コントロール プレーンは、Pilot、Mixer、Citadel の 3 つのモジュールに分かれています。具体的な機能は以下の通りです。

• Pilot は、Kubernetes API からクラスター全体のサービス検出情報を取得して監視し、クラスターのサービス検出情報とユーザーがカスタマイズしたルーティング ルール ポリシーを Envoy に送信する役割を担います。
• Mixer は、ポリシーとテレメトリの 2 つのサブモジュールに分かれています。ポリシーは、Envoy にアクセス ポリシー制御、ブラックリストとホワイトリストの制御、および QPS フロー レート制御サービスを提供するために使用されます。 Telemetry は、アラームとログ クエリを監視するためのデータ レポートおよびログ収集サービスを Envoy に提供します。
• Citadel は、サービスとユーザーの認証と承認を提供し、資格情報を管理し、RBAC を提供します。
• さらに、Istio は運用・保守担当者に、Kubernetes の kubectl に似た istioctl というコマンドライン ツールを提供します。運用および保守担当者がルーティング ルールの YAML ファイルを作成したら、istioctl を使用してルーティング ルールをクラスターに送信できます。

Istio の全体的な動作の原則とプロセスの詳細は非常に複雑であり、関連するテクノロジー スタックには一定の深さと幅があります。一般的なプロセスの概要は次のとおりです。

• 運用および保守担当者は、istioctl を使用するか、API を呼び出して、制御レイヤーでルーティング ルール ポリシーを作成および変更します。
• Pilot は、Kube API サーバーからクラスター サービス検出情報を取得して監視します。
• アプリケーションをデプロイすると、Istio は Envoy コンテナをポッドのデプロイ構成に挿入します。 Envoy は、iptables nat リダイレクトを通じてプロキシ ポッド内のすべての TCP トラフィックをハイジャックします。
• Envoy は、Pilot からクラスターのサービス検出情報とルーティング ルール ポリシーをリアルタイムで更新し、この情報に基づいてクラスター内のトラフィックをインテリジェントにスケジュールします。
• 各リクエストが送信される前に、Envoy は Mixer Policy に Check リクエストを送信して、リクエストがポリシー制限またはクォータ制限の対象かどうかを確認します。各リクエストを受信すると、呼び出しが成功したかどうか、戻りステータス コード、時間のかかるデータなど、リクエストに関する基本情報が Mixer Telemetry に報告されます。
• Citadel は、双方向 TLS クライアント証明書の生成と挿入、サーバー キーと証明書の発行と挿入、および K8S RBAC アクセス制御を実装します。

UAEK 環境における Istio の変革

上記の調査と一連のテストを経て、UAEK チームは Istio の設計コンセプトと潜在的な価値を十分に認識し、Istio の豊富で強力なマイクロサービス ガバナンス機能を活用して、より多くの社内チームがサービスを UAEK 環境に移行することを期待しました。

しかし、実際には、Istio を UAEK に統合するプロセスはスムーズではありません。私たちが最初に Istio の調査を始めたとき、それはまだバージョン 0.6 であり、その機能は完全ではありませんでした。 UAEK 環境ではそのまま使用できませんでした。

IPv6 の問題に対する解決策

最初に遭遇した問題は、UAEK が純粋な IPv6 ネットワーク環境であり、Istio の IPv6 トラフィックのサポートが完全ではないということでした。一部のコンポーネントは IPv6 環境に展開することさえできません。

具体的な変換事例を紹介する前に、まずは Istio Sidecar がビジネス プログラムのトラフィックをどのように引き継ぐのかを理解しましょう。

上の図に示すように、Istio は proxy-init コンテナと envoy コンテナの 2 つのコンテナをアプリケーション Pod に挿入します。 proxy-init コンテナは iptables 設定を初期化し、すべての TCP 層トラフィックを nat リダイレクトを通じて Envoy がリッスンするポート 15001 にリダイレクトします。着信トラフィックを例にとると、リダイレクトされた TCP 接続を受信した後、Envoy のサービス ポートは getsocketopt(2) システム コールを使用し、SO_ORIGINAL_DST パラメータを使用して TCP 接続の実際の宛先 IP アドレスを見つけ、要求を実際の宛先 IP に転送します。

しかし、IPv6 環境では、Envoy は Pod トラフィックをハイジャックできないことがわかりました。パケットをキャプチャしてソース コードをトレースすると、Pod が起動すると、最初に iptables 初期化スクリプトが実行され、Pod 内の NAT リダイレクト構成が完了し、コンテナ内の TCP 受信トラフィックと送信トラフィックが Envoy リスニング ポートにハイジャックされることがわかりました。ただし、この初期化スクリプトには ip6tables の対応する操作がなく、すべての IPv6 トラフィックが破棄されます。そのため、IPv6 トラフィック ハイジャックを実装するために初期化スクリプトを変更しました。

一つの波が静まるとすぐに、別の波が立ち上がる。 IPv6 トラフィックのハイジャックが完了した後、ビジネス サービス ポートにアクセスするすべての TCP トラフィックが Envoy によってリセットされたことがわかりました。 Envoy コンテナに入ると、ポート 15001 が開いていないことがわかりました。 Envoy と Pilot のソース コードを遡ってみると、Pilot から Envoy に送信されたリッスン アドレスは 0:0:0:0:15001 であり、これは IPv4 アドレスであることがわかりました。 Envoy がアドレス [::0]:15000 をリッスンする必要があるため、Pilot ソース コードの変更を続けます。

上記の作業の後、アプリケーション サーバー プログラム Pod は、開始した TCP 接続を最終的に正常に受け入れることができるようになります。しかしすぐに、リクエスト接続はサーバーによって閉じられました。クライアントが接続するとすぐに TCP FIN セグメントを受信しましたが、要求は依然として失敗しました。 Envoy の実行ログを観察すると、Envoy が TCP 要求を受信した後、対応するレイヤー 4 トラフィック フィルターが見つからないことがわかりました。

ソースコードをさらに調査した結果、Envoy は getsocketopt(2) システムコールを通じて、ハイジャックされたアクセス要求の実際の宛先アドレスを取得する必要があることがわかりました。ただし、次のコードに示すように、IPv6 環境での Envoy 実装にはバグがあります。ソケット fd タイプの決定がないため、getsocketopt(2) に渡されるパラメータは IPv4 環境のパラメータになります。したがって、Envoy はリクエストの実際の宛先アドレスを見つけることができず、エラーを報告し、クライアント接続を直ちに閉じます。

問題を発見した後、UAEK チームはすぐに Envoy ソース コードを修正し、getsocketopt(2) の SO_ORIGINAL_DST オプションの IPv6 互換性を改善しました。その後、この変更は Envoy オープンソース コミュニティに送信され、その後現在のマスター ブランチにマージされ、Istio1.0 の Envoy イメージで更新されました。

これまでのところ、Istio SideCar は、UAEK IPv6 環境でサービス間のアクセス トラフィックを正常にスケジュールできるようになりました。

さらに、Pilot や Mixer などのモジュールでは、IPv6 形式のアドレスを処理する際に配列の範囲外が発生し、プログラムがクラッシュすることも判明したため、これらを一つずつ修正していきました。

パフォーマンス評価

Istio1.0 がリリースされる前は、パフォーマンスの問題は常に業界で批判の的となっていました。まず、Envoy を追加すると、リクエストが開始される前にトラフィック レプリケーションの追加レイヤーと Mixer ポリシーへのチェック リクエストが発生するかどうかを調べました。これらの要因がビジネスに許容できない遅延を引き起こすのではないかと疑問に思いました。多くのテストを行った結果、UAEK 環境でのレイテンシは、Istio を使用しない場合よりも約 5 ミリ秒高いことがわかりました。これは、ほとんどの内部サービスでは完全に受け入れられます。

次に、Istio Mesh アーキテクチャ全体に焦点を当て、Mixer Policy と Mixer Telemetry がクラスター全体のパフォーマンスの欠点になりやすいという結論に達しました。 Envoy は各リクエストを開始する前にポリシー サービスで Check リクエストを実行する必要があるため、一方ではビジネス リクエスト自体のレイテンシが増加し、他方では単一ポイントとしてのポリシーへの負荷圧力が増加します。サンプル テストとして Http1.1 リクエストを使用したところ、グリッド全体の QPS が 2000 ～ 3000 に達すると、ポリシーが深刻な負荷ボトルネックに遭遇し、すべてのチェック リクエストに通常の 2 ～ 3 ミリ秒から 100 ～ 150 ミリ秒とかなりの時間がかかるようになり、すべてのビジネス リクエストの遅延が大幅に増加することがわかりました。この結果は明らかに受け入れられないものである。

さらに深刻なのは、Istio 0.8 以前のバージョンでは、ポリシーがステートフル サービスであることです。グローバル QPS レート制限クォータ制御などの一部の機能では、メッシュ全体のリアルタイム データを記録するために単一のポリシー プロセスが必要です。つまり、ポリシー サービスはインスタンスを水平にスケーリングしてパフォーマンスのボトルネックを解決することはできません。慎重に検討した結果、現在、ポリシー サービスを無効にし、QPS グローバル クォータ制限などの一部の機能を削減しました。

前述したように、Mixer Telemetry は主に、Envoy への各リクエストの呼び出しステータスを収集する役割を担っています。 Mixer Telemetry のバージョン 0.8 にも重大なパフォーマンスの問題があります。ストレス テスト中に、クラスターの QPS が 2000 を超えると、Telemetry インスタンスのメモリ使用量が急増することが判明しました。

分析と位置付けの結果、テレメトリのメモリ使用量が増加した理由は、さまざまなバックエンド アダプタによって消費されるデータの速度が Envoy がデータを報告する速度に追いつかず、アダプタによって処理されなかったデータがメモリに急速に蓄積されたためであることがわかりました。その後、Istio に付属していた実用的ではない stdio ログ収集機能を削除したところ、問題は大幅に軽減されました。幸いなことに、Istio 1.0 のリリースにより、テレメトリ メモリ データのバックログ問題は解決されました。同じテスト条件下では、単一のテレメトリ インスタンスは少なくとも 35,000 QPS でデータを収集してレポートできます。

問題、希望、そして未来

途中で多くの問題を乗り越え、ようやく本番環境で使えるServiceMeshがUAEK環境で稼働するようになりました。このプロセスの間、部門内の他のチームは UAEK チームの影響を受け、Istio の概念を学び、プロジェクトで Istio を使用し始めました。しかし、現状は当初の意図からは程遠い状況です。

Istio は依然として高速で反復を続けています。 Istio 自体と Envoy Proxy はどちらも日々進化し、更新されています。各バージョンのアップデートにより、より強力な機能、より簡潔な API 定義、より複雑なデプロイメント アーキテクチャが提供されます。 0.7.1 から 0.8 までの新しいルーティング ルール v1alpha3 は、以前の API と完全に互換性がありません。新しい仮想サービスは元のルータールールとはまったく異なるため、すべてのユーザーに多大な問題を引き起こします。

Istio のアップグレードによる既存ネットワークへの悪影響を完全に回避するにはどうすればよいですか?公式はまだ最もスムーズなアップグレードソリューションを提供していません。また、各コンポーネントのパフォーマンスは 0.8 から 1.0 に大幅に向上しましたが、業界からのフィードバックから判断すると、全員が満足しているわけではありません。 Mixer のチェック キャッシュ メカニズムがポリシーのパフォーマンス負荷をどの程度軽減できるかはまだわかりません。

私たちが発見したバグの多くは、コミュニティ内の他の開発者によっても 1 つずつ発見され、解決されたことも特筆に値します。私たちにとって嬉しいのは、UAEK チームが情報孤島ではないということです。 Istio 公式コミュニティは、高速で反復作業に熱心に取り組んでおり、開発者が懸念するさまざまな問題の解決に常に尽力していることが感じられます。私たちが提出した問題には、数時間以内に回答できます。これらすべてから、Istio は Kubernetes と同じくらい成功する可能性のあるプロジェクトであると確信しています。

UAEK アクセス ユーザーの経験に基づくと、ユーザーは Istio を正しく使用するために、詳細な Istio ドキュメントを学習する必要があります。 UAEK は、ユーザーが独自のルーティング ルールをシンプルかつ直感的にカスタマイズできるように、このプロセスの簡素化に引き続き取り組んでいきます。これが私たちの次のビジョンになります。

UAEK チームは、UCloud の内部 R&D プロセスを改革し、R&D の効率を向上させ、運用と保守の手間を減らし、職場の全員の幸福を図ることに常に取り組んできました。 UAEK は、ServiceMesh 機能の継続的な改善に加えて、今年後半にはさらに多くのリージョンとアベイラビリティ ゾーンをオープンし、より機能豊富なコンソールを提供し、自動化されたコード管理パッケージングや継続的インテグレーション (CI/CD) 機能をリリースする予定です。乞うご期待！

著者について

UCloud のシニア R&D エンジニアである Chen Sui は、監視システム、サーバーレス製品、PaaS プラットフォーム ServiceMesh などの開発を担当しており、分散システム開発において豊富な経験を持っています。