オープンソースシステムに基づくクラウドネイティブマイクロサービスガバナンスの実践と探究

著者について

Ctrip のシニア R&D マネージャーである CH3CHO は、クラウド ネイティブやマイクロサービスなどの技術分野に重点を置いて、マイクロサービスやゲートウェイなどのミドルウェア製品の R&D を担当しています。

1. Ctripのマイクロサービス製品の開発履歴

Ctrip のマイクロサービス製品は 2013 年に始まりました。当初、同社はオープンソース プロジェクト ServiceStack に基づいて二次開発を行い、.Net プラットフォームでマイクロサービス フレームワーク CServiceStack を立ち上げました。

同社は2014年に、CServiceStackと完全に相互運用可能な自社開発のマイクロサービスフレームワークであり、Javaプラットフォーム上の第1世代のサービス登録センターであるBaijiをリリースしました。サービス登録センターはその後数回の改修を経て、現在は第 4 世代の製品を使用しています。

同社は2017年にオープンソース製品Dubboを正式に導入し、Ctripのガバナンス機能を統合するCDubboフレームワークを立ち上げました。このフレームワークは当初、Dubbo 2.5.4 に基づいて開発されました。数回のバージョンアップを経て、現在はDubbo 2.7.7を使用しています。

同社は2020年に正式にサービスメッシュプロジェクトの実装の検討を開始しました。現在、関連製品は生産段階で正式に発売されており、アクセス促進作業が進行中です。

Ctrip のマイクロサービス製品の状況は複雑ですが、主に次の 4 つの点が挙げられます。

まず、3 つのマイクロサービス フレームワーク製品が同時にオンラインで実行されています。

2 番目に、HTTP と Dubbo の両方の通信プロトコルが使用されます。

3番目に、登録センターや構成センターを含む完全に自社開発のインフラストラクチャを採用します。

4 番目に、100,000 を超えるインスタンスを持つ 8,000 を超えるオンライン サービスがあります。

研究開発が進むにつれて、私たちのチームは主に次の 3 つの問題に直面しました。

まず、類似した機能を持つ複数のミドルウェア製品を維持するのは大きな作業負荷であり、製品間の機能の整合性を確保するには多大な労力が必要です。

第二に、製品はSDK公開依存パッケージの形で業務アプリケーションに統合されるため、バージョンアップには業務側の協力が必要となり、アップグレードの促進が難しく、深刻なバージョンロングテール問題が生じます。

3 番目に、チームの作業エネルギーとテクノロジー スタックの制限により、SDK サポートはいくつかの言語プラットフォームでのみ利用可能であり、マイクロサービス製品を使用するニッチな言語のユーザーにとって不便です。

2. Ctripのクラウドネイティブマイクロサービスアーキテクチャ設計

オンラインクラスターが形になり始めたため、フレームワークをいかにスムーズに移行・運用していくかが重要な課題となってきました。既存のインフラストラクチャを完全に放棄し、完全なクラウドネイティブをワンステップで実現することは、実装が難しいだけでなく、プロジェクトサイクルも長くなります。

そのため、プロジェクトでは「小さなステップ、速い進歩」のアプローチを採用することにしました。まず、コードが完全に下位互換性があることを確認します。次に、全体的なアーキテクチャがビジネス アプリケーションの移行をサポートし、アクセスのフォールト トレランスが向上することを確認します。

プロジェクトの建築設計中に、3 つの主要な問題が発生しました。

データ権限の問題: 一般的なサービス メッシュのプラクティスでは、K8s をガイドラインとして使用し、すべてのデータを K8s に保存しますが、プラットフォームの既存のデータのほとんどは、独自に開発された登録センターと構成センターに保存されています。

クラウド内のデータは K8s に保存され、クラウド外のデータは既存の登録センターに保存され、外部ツールまたはコンポーネントを通じて双方向の同期が実現される、2 プッシュ アプローチを採用するという提案があります。ただし、双方向同期は、データの正確性とリアルタイム性、および同期がループを形成しないようにすることの両方が求められるため、比較的複雑です。

したがって、アーキテクチャのシンプルさのために、プロジェクトでは最終的に、レジストリ データの権限ステータスを変更せずに、外部コンポーネントを通じて K8s にデータを書き込むことを選択しました。

境界分割の問題: 現在のプロジェクト展開システムでは、リージョンに複数のゾーンが含まれ、ゾーンに複数の K8s クラスターが含まれ、クラスターはネットワークを介して相互接続されています。ただし、障害を分離する必要があるため、インスタンス情報をゾーン間で同期する必要がないように、データをゾーン内に収束しておくことが最適です。

ゾーン内コンバージェンスの問題は、発信者がゾーン間通話を開始するときに、その通話をゲートウェイ経由で転送する必要があることです。この呼び出し方法は既存の呼び出しチェーンとは異なり、計算の複雑さが増します。

そのため、プロジェクトでは最終的に、既存の作業モードを変更せずに維持することを選択しました。これにより、呼び出し元はリージョン内のすべてのゾーン サービス インスタンスを取得し、リージョン内でデータを透過的に維持できるようになります。

技術選択の問題: これまで、プロジェクトの R&D 製品のほとんどは社内で開発され、チーム全体が協力して開発作業を完了していました。ただし、オープンソース コミュニティに頼ることで、優れた製品を作成しやすくなります。

そのため、プロジェクトでは最終的にオープンソース製品をベースに二次開発を行うことを選択しました。

現在使用されているサービス メッシュ アーキテクチャ設計 (「プログレッシブ」アーキテクチャとも呼ばれます) には、3 つの主な特徴があります。

オープンソース: Service Mesh のインフラストラクチャとして Istio と Envoy が選択されています。

インスタンスと構成の同期に関しては、新しく開発された SOA Operator が、登録センターと構成センターに保存されているデータを K8s に書き込む役割を担います。

同時に、プログラムは K8s クラスター内のサービス プロバイダーのデータも登録センターに書き込むため、K8s クラスター外のユーザーもサービス データを正常に読み取ることができます。また、このサービスでは SDK サポートは必要ありません。登録と検出は SOA Operator によって直接完了し、あらゆる言語をマイクロサービス製品システムに簡単に接続できます。

使用方法: K8s クラスター外のアプリケーションは、引き続き以前の対話方法を使用し、SDK と登録センターを介して通信します。

K8s クラスター内のアプリケーションの場合、SDK を使用すると、Sidecar の存在を検出した後、SDK はサービス ガバナンス機能を自動的に無効にし、リクエストに特別なホストを使用します。 SDK がサポートされていない場合は、HTTP クライアントを直接使用してメッシュにアクセスし、引き続き特別なホストを使用してリクエストを開始できます。

HTTP プロトコルはサービス メッシュ アーキテクチャでは適切に機能しますが、Dubbo プロトコルはサイドカー ゲートウェイではいくつかの問題があります。

まず、メタデータの場所です。HTTP プロトコルではメタデータはメッセージの先頭に配置されますが、Dubbo プロトコルではメタデータはメッセージの末尾に配置されます。したがって、メタデータの場所を見つけるには、まずメッセージを解析する必要があります。

2 番目は、シリアル化の問題です。メッセージを解析するには、メッセージのデシリアル化が必要です。現在、Envoy は Dubbo のデフォルトのシリアル化プロトコルをサポートしています。ただし、このアプローチでは追加のオーバーヘッドが発生し、Dubbo サービスで使用されるシリアライザーは複雑です。一部のチームでは、圧縮アルゴリズムを使用してメッセージ サイズをさらに縮小し、ゲートウェイによる解析を困難にしています。

Dubbo 3 は、HTTP/2 をベースにした gRPC を使用し、リクエスト ヘッダーを通じてメタデータ情報の配信を実装する通信プロトコル Triple をリリースしました。これは、Dubbo 3 で推奨されるサービス通信プロトコルでもあります。

Triple プロトコルは Envoy フレームワークに適しており、サービス メッシュに簡単に接続できます。 Dubboのバージョンアップグレードは複雑ではありません。

gRPC の PB シリアル化形式のため、Triple プロトコルを直接使用することはできません。 Triple プロトコルは PB との互換性が高いですが、PB ではコードを生成する前に契約を記述する必要がありますが、Dubbo では最初にコードを記述する必要があり、契約はなく、データ モデルは PB オブジェクトとはまったく異なる POJO 形式です。

POJO と PB オブジェクトを接続するために、Triple プロトコルは Wrapper を設計しました。元の POJO オブジェクトがシリアル化されてセカンダリ データを取得した後、PB を使用してシリアル化するために Wrapper に渡されます。

ただし、このアプローチではメモリ使用量が増加するだけでなく、GC もさらにトリガーされます。複数の GC と繰り返しのシリアル化により、CPU 負荷が増加します。

Triple プロトコルによって引き起こされる問題を解決するために、プロジェクトでは gRPC にカスタム シリアライザーを追加しました。これにより、ストリーミングのシリアル化が実現されるだけでなく、ネイティブ Dubbo と同じユーザー エクスペリエンスがユーザーに提供されます。

他の言語でこの gRPC サービスを呼び出す場合は、このカスタム シリアライザーのみが必要です。デフォルトのカスタム シリアライザー JSON は、ほとんどの言語で解析できます。

ガバナンスの面では、Service Mesh はインフラストラクチャとして Istio と Envoy を使用し、Istio を介して K8s の CRD データを読み取り、Envoy にプッシュする構成を生成します。

そのため、自社開発のサービスガバナンスシステムに保存されているすべてのインスタンスデータと構成データを CRD 形式に変換し、Istio 処理のために K8s に同期する必要があります。

トランスレータとして、Operator には多くのモデル変換ロジックが含まれており、構成モデルを CRD モデルに変換できます。一部の複雑な機能については、プロジェクトでは、Envoyfilter または Envoy の二次開発を通じてカスタム Envoyfilter を追加することで実装します。

現在、よく使われる機能はすべて揃っており、全体の機能カバレッジ率は90％を超えています。数千件のオンライン申請がアクセスを完了し、その後のアクセス促進作業に入りました。

3. クラウドネイティブマイクロサービス製品の今後の開発動向

サービス メッシュは、グループ化、ルーティング、トラフィック制御、負荷分散などの共通機能を提供します。これらの機能自体にはセマンティクスがないため、最前線のビジネス R&D および運用保守担当者が理解するのは困難です。

さらに、製品の機能は既存のガバナンス システムの機能とは異なります。最前線の担当者に優れたマイクロサービス ガバナンス エクスペリエンスを提供するには、実際の運用および保守要件を基礎となる制御データにリンクする必要があります。

現在、コミュニティ内ではDubbo Meshの研究開発も活発に進められており、そのアプローチはCtripのクラウドネイティブなマイクロサービスガバナンスフレームワークに似ています。別のコントロール プレーンを介して構成データを K8s に書き込み、MCP を介してインスタンス データを同期します。

さらに、新しいオープンソース製品である OpenSergo も開発中です。公式の紹介によると、このプロジェクトは、一連のユニバーサルなクラウドネイティブ マイクロサービス ガバナンス標準を作成し、一連の API および SDK プラクティスを提供することを目指しています。

現在、多くの大手インターネット企業とオープンソースコミュニティが共同でプロジェクトを推進しており、サービスガバナンスからクラウドネイティブインフラストラクチャまでのフルリンクエコロジカルカバレッジの完成を目指しています。