アリババの10億レベルの長距離ゲートウェイのクラウドネイティブな進化パス

AServerアクセス​​ゲートウェイは、Ali Group全体の入力トラフィックを伝送し、数億人のユーザーの長鎖キープアライブを担当し、数万人のルーティング戦略転送をサポートし、数億人のユーザーと数十万のバックエンドサービスノードを接続するブリッジです。安全で信頼性の高い転送ルーティングを実現し、スムーズでスムーズなユーザーエクスペリエンスを実現するには、数億のオンラインユーザー、数千万のQPS、および効果的な数万のAPI制御戦略をサポートする必要があります。

大規模なビジネストラフィックと管理制御のサポートの背後には、すべての潜在的なリスクポイントを排除するために、システムのすべての詳細を正確に制御する必要があります。

クラウドネイティブアーキテクチャの助けを借りて、O&M操作を大幅に簡素化し、潜在的なリスクを軽減できます。今年のDouble Eleven Ali AServerアクセス​​ゲートウェイは、数千のポッドが着実にピークを超えました。この記事では主に、AliAServerアクセス​​ゲートウェイが前世代のアーキテクチャからの変更と包括的なクラウドネイティブの進化をどのように受け入れるかを紹介します。

アーキテクチャの進化の背景


毎年恒例のダブルイレブンプロモーションは、Alibabaのすべてのサービス、特にAServerアクセス​​ゲートウェイにとって最も厳しいテストです。Alibabaグループの最初のポータルとして、ピークプロモーションによって引き起こされるトラフィックのピークに抵抗し、攻撃トラフィックをクリーンアップする必要があります。クラスターの規模は巨大です。

巨大なクラスタースケールとマシンパフォーマンスの極端な要件により、運用と保守が複雑になっています。アクセスサービスの増加に伴い、サポートされるビジネスシナリオが拡大し、ルーティング戦略の柔軟性とビジネスの効果的なリアルタイム要件が変化します。高いため、ルーティング戦略の動的なオーケストレーション機能に対する強い需要があります。サービスの多様性、ビジネスラインのさまざまなネットワークブロッキングリズム、および障害の切り分けにより、トラフィックの切り分けの安定性が求められます。

運用と保守の複雑さ、動的なオーケストレーションの需要、トラフィックの分離、および極端なパフォーマンス要件により、AServerアクセス​​ゲートウェイの継続的な進化と成長が促進されます。ビジネス開発のペースに対応しながら、運用と保守のコストを徐々に削減し、システムの安定性を高めます。セックス、ダブルイレブンのテストに何度も耐えることができます。

▐ビジネスの  背景

AliグループのAServerアクセス​​ゲートウェイとして、Aliグループ全体の入力トラフィックを伝送します。最初にドメイン名転送戦略をサポートするtengineゲートウェイは、ドメイン名をさまざまなバックエンドサービスに転送し、ビジネスフォームは比較的単純です。

オールインワイヤレス時代に向けて、モバイル側のユーザーエクスペリエンスを最適化し、サーバー担当者の開発コストを削減するために、グループが独自に開発したMTOP(Mobile Taobao Open Platform)APIゲートウェイは、クライアントとサーバーに一貫したAPIを提供します。同じドメイン名のプラットフォームは、URIによって運ばれるAPI情報を介してのみ、対応するサービスに転送されます。アクセスゲートウェイは、API(URIによって区別される)に従ってルーティングおよび転送機能をサポートする必要があります。APIは、数年で数万のルールに急速に増加しています。

ビジネス開発がより洗練されるにつれて、同じAPIの下でのさまざまなビジネスシナリオが細分化されることが予想されます。たとえば、モバイルショッピング、Alipayなどのダブルイレブンプロモーション会場のソース、およびより洗練された制御のための他の外部投資ページなどです。ゲートウェイは、ビジネス開発に適応するために、洗練された管理および制御機能をサポートし、サービス要求パラメーターおよび要求ヘッダーに基づいて管理、制御、および配布を実行する必要があります。各リクエストは、非常に高いパフォーマンスを維持しながら、何万もの柔軟な構成ルールからの一意のパスに一致する必要があります。これは非常に困難です。

ビジネスモデル図

▐運用・  保守システムの背景

当初、基本的なサポートインフラストラクチャは完全ではありませんでした。ゲートウェイレイヤーはtengine上に構築されていました。最も簡単で迅速なソリューションは、物理マシンを使用することであり、展開プロセスと構成でサービスのセットアップを完了することができました。ビジネスが成長するにつれて、構成管理がボトルネックになります。ゲートウェイレイヤーには、標準化された方法でビジネス構成を生成するための強力な構成管理プラットフォームが必要です。自己開発の構成管理プラットフォームは、構成をアプリケーション構成、パブリック構成管理、および証明書構成に分割します。 3つの部分。

  • パブリック構成:モジュール構成の有効化、tengine実行ロジック構成など、Gitバージョン管理を介して実行されるtengineの基本構成を生成します

  • アプリケーション構成:標準テンプレートを使用して、ビジネスに必要なtengine構成を生成します

  • 証明書の構成:証明書には有効期間があるため、有効期限が切れたときに更新を忘れないようにするために、証明書の自動更新のタスクも実行します。

初期のシステム展開アーキテクチャ:

このソリューションは、ビジネスセルフサービスアクセスを実現できます。tengine構成は、構成管理プラットフォームのテンプレートを介して生成され、ゲートウェイマシンに定期的にプッシュされ、再ロードされて構成が有効になります。

この運用・保守方式により、インフラに依存せず、急速に進化することができますが、事業の成長やクラスター規模の拡大に伴い、物理機械の運用・保守方式のデメリットが徐々に現れ、野蛮な成長の時代が過ぎ、アリのサービスポータルとして安定物理マシンのバイナリリリースは手動展開に依存しています。rpmパッケージをインストールするには、コマンドをバッチで実行し、プロセスをバッチで再開する必要があります。これらはすべて、黒い画面で完了します。

明らかに、この種の操作および保守方法は、現在の安定性要件を満たすことができません。手動リリースを使用すると、誤操作によるシステム障害が非常に発生しやすくなります。さらに、バイナリの一貫性やマシン自体の環境(カーネルパラメータなど)の一貫性チェックなど、物理的なマシンの操作とメンテナンスの一貫性を確保することは困難です。これまでの手動の操作とメンテナンスの方法は、明らかに時代のペースに追いついていないのです。

リリースと環境の一貫性の問題を解決するための最良のソリューションは、コンテナ化テクノロジーです。グループのインフラストラクチャの改善により、アクセスゲートウェイのコンテナ化変換により、障害が取り除かれ、不変条件(システム構成、バイナリ)がリリース用に1つにパックされます。変数(アプリケーション構成、パブリック構成、証明書)は、引き続き構成管理プラットフォームによって管理され、コンテナー化テクノロジーによって調整されます。

コンテナ化変換後のリリースおよび構成変更プロセス:

コンテナ化されたアーキテクチャは、サイトの構築、拡張、縮小の操作を簡素化し、公開効率を大幅に向上させ、承認プロセスを向上させ、スタックポイントをシステム化し、人的操作による障害を回避します。公開プロセスを監視システムに接続して、自動的にアラートを出し、公開を一時停止します。

▐主要な  問題

eコマースビジネスの発展が加速するにつれて、規模がボトルネックに達した後、ビジネスはより水平方向に拡大し、洗練度はますます高くなり、反復速度も向上します。ゲートウェイ層はビジネスの変化に適応します。コストが高いほど、これがもたらす主要な問題は次のとおりです。

  • 運用および保守運用の複雑さ:パフォーマンスに対する極端な要件のため、ゲートウェイクラスターにはマシンに対する特別な要件があります。ゲートウェイ構成管理の特殊性により、運用および保守運用の複雑さが発生します。特殊性の存在は、既存のグループに適切に接続できません。運用および保守システムをアップグレードする必要があります。

  • 不十分な動的オーケストレーション機能:アクセスサービスの増加に伴い、サポートされるビジネスシナリオが拡大し、サービスのルーティング戦略の柔軟性とリアルタイムパフォーマンスの要件がますます高まっています。静的構成をリアルタイムまたはポリシーの柔軟性で有効にすることは困難です。ビジネス開発のニーズを満たすには、ルーティング戦略をサポートする動的なオーケストレーション機能が必要です。

  • 高いトラフィック分離コスト:軽量のビジネススコープ分離機能がなく、新しいクラスターを作成するコストが高すぎます。ビジネスラインのさまざまなネットワーク閉鎖リズムをサポートし、障害分離をサポートするには、軽量のマルチクラスタートラフィック分離ソリューションが必要です。

近年のクラウドネイティブの急速な発展により、ゲートウェイレイヤーのアーキテクチャの選択肢も増えています。

クラウドネイティブアーキテクチャ


アクセスゲートウェイの既存の問題を解決するために、グループのビジネスシナリオとクラウドネイティブのオープンソースシステムを組み合わせて、AServerアクセス​​ゲートウェイのクラウドネイティブの進化パスが開かれました。段階的な検証のために、運用および保守システムのアップグレード、サービスの3つのフェーズの分解が徐々に実現されます。ガバナンスとゲートウェイメッシュ、南北分割アーキテクチャ。次に、各ステップについて詳しく説明します。

▐運用および  保守システムのアップグレード


解決すべき問題

コンテナ化されたアップグレードと展開により、展開と運用および保守の方法が大幅に簡素化され、その時点で最も顕著な問題を解決できます。ただし、展開方法を変更するだけでは不十分です。

  • アクセスゲートウェイの特殊な性質(構成管理プラットフォームに接続する必要がある、VIP要件が多数あるなど)のため、グループのインフラストラクチャに直接接続することはできず、独立したカスタマイズされた運用および保守ツールが開発されています。拡張および縮小プロセスには複数の基盤が必要です。コンポーネントは非標準のインターフェースを介して調整されます。これは、運用および保守製品の反復効率に大きく影響します。

  • 故障した機械への交換などの操作は、外部システムによるポーリングと検出に依存しており、グループの基本設定システムは、カスタマイズされた操作および保守プラットフォームとドッキングすることによってのみ処理できます。

  • 運営・維持管理業務はグループ運営・維持管理システムから分離されています

進化論

グループ内のクラウドネイティブアプリケーション用に設計された統合インフラストラクチャASI(Alibabaサーバーレスインフラストラクチャ)の段階的な改善により、ネイティブK8SAPIに基づく完全なクラウドネイティブテクノロジースタックサポートが提供されます。

クラウドネイティブソリューションには強力なオーケストレーション機能があります。カスタマイズによるk8s拡張を実装することで、ゲートウェイレイヤーの特性を簡単にスムーズにすることができます。ASI独自の自動化された操作および保守方法をゲートウェイレイヤーに直接適用できます。

ゲートウェイ層のモデルの特殊性は、ノードプールを分割することで実現できます。ゲートウェイマシンのノードプールのモデルとカーネルパラメータをカスタマイズして、ゲートウェイの運用と保守の特殊性を排除し、運用と保守の統合管理を行うことができます。

進化計画

k8s独​​自のコントローラー拡張機能であるカスタムコンテナーレイアウトにより、拡張および縮小中のポッド変更イベントを監視して、構成管理プラットフォームへのマシンの追加と削除を実行できます。また、VIPをマウント/アンインストールして、操作とメンテナンスの特殊性をスムーズにすることもできます。また、すべてのリソースは宣言型APIを介して定義されているため、運用と保守に便利です。

ゲートウェイの運用・保守についても、ウェブサイトの構築にのみ使用される非常にシンプルな運用・保守プラットフォームを維持する必要があります。通常のアプリケーションと比較して、ゲートウェイの構築では、対応するエリアにVIPを作成し、ドメインバインディングなどの操作を実行する必要があります。これは、軽量で保守が容易です。

ASI変換により、アクセスゲートウェイの運用と保守がグループのASIクラウドネイティブシステムに統合され(配信効率が向上し、特別な運用と保守が削除されます)、一般的な機能がASIと基本システムに削減されます。同時に、リスクの分離、自己回復、および柔軟性

  • リスクの分離:サイドカー機能を使用してセキュリティ機能とエンジニアリング機能を分離し、2つの間の相互干渉を回避します。異常なセキュリティ機能はトラフィックのクリーニングにのみ影響します。セキュリティ機能が低下した後は、サービス全体が利用できなくなります。

  • 自己修復:コンテナの自己修復機能については、元のコンテナ化方法は外部アプリケーションのポーリング検出に依存しています。精度とリアルタイムパフォーマンスの両方が不足しています。ASIをアップグレードした後、コンテナ自体の検出は3〜5になる可能性があります。障害のあるコンテナを数分以内に特定して交換します。

  • 復元力: ASIの変換により、各システムのドッキング方法は、標準の宣言型APIを使用して、グループ内のさまざまなコンポーネントを統合できます。これにより、拡張および縮小操作が大幅に簡素化され、自動柔軟性がサポートされます。

  • シールドモデルの違い:ノードプールを分割することにより、ゲートウェイアプリケーションに特別なモデルを使用でき、基礎となる構成は特別な操作なしで違いをシールドします。

▐サービス  ガバナンスとゲートウェイメッシュ


解決すべき問題

ゲートウェイ層でアクセスされるサービスの種類が増えるにつれて、何万ものAPIルーティングルールをサポートする必要があり、ルーティング戦略はますます洗練されており、tengineのネイティブ機能の使用はビジネスニーズを満たすことができません。非標準の定義方法であるカスタム開発のtengineモジュールにより、過去数年間のビジネスの発展にうまく適応できますが、ビジネスの需要がさらに洗練されるにつれて、カスタム開発のtengineモジュールのコストは徐々に増加しています。

元の構造

  • ルーティング構成は、モジュール構成とネイティブ構成の組み合わせです。複数のモジュール構成が共同でルーティング戦略を決定します。分散構成では、要求の完全なルーティングパスを識別できません。

  • 機能モジュールを分割することにより、ビジネスの細かさに応じて増分更新を実現することは困難です。

  • tengineアーキテクチャに基づくと、動的に変更する機能は不十分であり、ドメイン名の変更は毎日定期的にプッシュおよび構成されます。これは、迅速なビジネス反復のニーズを満たすことができません。

  • 非標準プロトコルは、さまざまな管理および制御プラットフォームに直接接続されています。これは、接続コストが高く、閉じて制御するのが簡単ではありません。

  • さまざまなビジネスライン(Taoxi、Youkuなど)では、リソースの分離を実現する必要があります。ほとんどのモジュール構成は静的なパブリック構成を使用するため、Webサイトの構築コストは比較的高くなります。

▐進化の  アイデア

ルーティング戦略を動的に調整して細かく制御する方法は、クラウドネイティブシステムの主な考慮事項です。Kong、Ambassadorなどの業界ゲートウェイレイヤーのプラクティスを参照してください。主流のゲートウェイデータプレーンの実装はすべてnginxまたはenvoyに基づいています。さまざまな製品のスケーラビリティ、動的オーケストレーション機能、および成熟度の比較:

ダイナミクス、標準化、およびパフォーマンスの観点から、データプレーンとしてエンボイを使用することは、クラウドネイティブの進化により適しています。

  • ダイナミックで柔軟

    • 使節によって実装された標準のxDSプロトコルは十分に柔軟性があり、完全に構成して動的に変更できます

    • Envoyは十分に拡張可能であり、フィルター拡張を実装することで、グループ内の独自のルーティングロジックを実現できます。

  • 標準

    • istio標準コンポーネント、強力なコミュニティサポート、迅速な開発

    • Ali Groupのメッシュは、データプレーンオプションとしてistioテクノロジーソリューションとenvoyを使用しており、グループのビジネス管理および制御と統合できます。

  • パフォーマンス

    • C ++の実装、パフォーマンスは十分に優れており、開発効率はtengineよりも高い

エンボイの欠点は、istioの標準コンポーネントとして、強力な東西ルーティング機能を備えていることです。南北方向として、特定のパフォーマンスと安定性の最適化が必要ですが、長期的には、ダイナミクスと標準化がより重要です。

進化計画

統合されたコントロールプレーンコンポーネントとして、Reuse Group Pilotは、ゲートウェイ自体のメッシュ化を実現します。

コントロールプレーンは、公開された各ビジネス製品の書き込みを提供するために、アクセス許可を閉じるための管理および制御ロジックのレイヤーを提供する必要があります。各製品は、k8s宣言APIを介してルーティング戦略を書き込み、パイロットコントロールプレーンからxDSデータプレーンプロトコルに変換されて、リアルタイムで同期されます。データプレーンEnvoyの場合、サウスバウンドルーティングゲートウェイの実装アーキテクチャは次のとおりです。

グループの大規模な構成、数十万のルーティングルール、数千のアプリケーション、および数十万のビジネスノードのため、オープンソースシステムがそのような規模になることはめったにありません。Pilot + Envoyソリューションを南北ゲートウェイに適用した後、スケールによって引き起こされるパフォーマンスと安定性の問題を解決するために、ネイティブコンポーネントを最適化およびカスタマイズする必要があります。

  • PilotはSRDSプロトコルをサポートします:大規模なAPI構成によって引き起こされる線形マッチングパフォーマンスの問題を解決します

  • 増分構成の更新:完全な更新によって変更の半径が拡大するリスクを回避するために、コントロールプレーンの増分更新機能を実現および改善します

  • ノード変更の最適化:数十万のビジネスノードの状態変更がコントロールプレーンとデータプレーンのパフォーマンスに与える影響を解決します

  • 拡張カスタマイズ:グループ固有のルーティングルール用にカスタマイズされたフィルターの実装

オープンソースシステムをカスタマイズおよび最適化することにより、グループのニーズを十分に満たすことができ、柔軟な構成の組み合わせにより、高速反復制御プレーン透過伝送の機能により、グループ内のさまざまなビジネスの特別なニーズを実現できます。

▐  南北分割


解決すべき問題

ユーザーとビジネスの間の架け橋として、ゲートウェイはユーザー側で長鎖を維持し、プロトコルを最適化して、ユーザーがグループにできるだけ迅速かつ安定して接続できるようにします。柔軟なルーティングをサポートし、ビジネスの電流制限戦略と負荷分散を融合します。接続の維持、ゲートウェイとしてのルーティングと転送の全体的な機能は明らかにされていますが、2つの反復効率とサービス特性の要件はまったく異なります。

一部の大規模なプロモーションシナリオでは、予期しないトラフィックピークが発生した場合でも、ビジネスサービスを保護するためのバリアとしてのゲートウェイ層は、高性能と水位の予約に依存して、堅固なものになる可能性があります。キープアライブのロングチェーンを考慮すると、プロトコルの最適化はこの長い反復サイクルを持ち、パフォーマンスは非常に高く、柔軟で複雑な戦略のため、ルーティング転送とトラフィッククリーニングは当然比較的高くなります。この2つをアーキテクチャに分割すると、大幅に大きくなる可能性があります。全体的なリソース使用率を向上させるため。

進化のアイデアと計画

プロトコルのアンインストール、長鎖キープアライブなどはクライアントと対話し、非常に高性能なモジュールを維持できます。これらのモジュールは、ノースバウンドクラスターに個別に分割できます。パフォーマンスが優れているため、洪水をブロックするための高いダムを構築するために使用できるマシンは少数です。ビジネスルーティング戦略は、より多くのパフォーマンスを消費するセキュリティクリーニング機能に関連しています。これはサウスバウンドクラスターに分割され、サウスバウンドクラスターはノースバウンドハイダムを介して過負荷から保護されます。サウスバウンドクラスターは予約水位を下げることができるため、全体的なリソース使用率が向上します。このようにして、リソースの使用率を向上させるだけでなく、迅速なビジネス開発のニーズを満たすように柔軟に構成することもできます。

▐全体的な  アーキテクチャ

進化の3つの段階を通じて、最終的なアーキテクチャ図は次のようになります。

AServerアクセス​​ゲートウェイクラウドネイティブアーキテクチャ

  • 統合制御プレーン:サービスアクセス、サービスディスカバリ、およびグループの統合制御プレーンを介した電流制限制御。これらは、変更の統合処理で役割を果たします。

  • ノースバウンド接続レイヤー:数億のオンラインユーザーとトラフィックのピークを運ぶtengineに基づいて、ハイダムとして機能し、サウスバウンドルーティングレイヤーのリソース使用率を向上させます。

  • サウスバウンドルーティングレイヤー: Envoy through Pilot変換xDSプロトコルに基づいて、動的ルーティングと軽量トラフィック分離ソリューションを実現するためのルーティング戦略を動的に発行します。

  • クラウドネイティブベース:運用と保守の運用は、グループの統合インフラストラクチャASIで確立されます。これにより、ゲートウェイの違いが保護され、運用と保守の複雑さが軽減されます。


未来


Ali AServerアクセス​​ゲートウェイは段階的にクラウドネイティブに進化しています。それぞれの進化は、長い間私たちを悩ませてきた問題に基づいているだけでなく、問題を解決することだけではありません。同時に、現在の時代のソリューションに基づいて、クラウドネイティブアーキテクチャの変革は終わりにはほど遠いです。 、クラウドネイティブの利点はまだ十分に活用されていません。テクノロジーのアップグレードは、最終的には製品を提供することです。クラウドネイティブのアップグレード後、強力なエンジンができました。次に行う必要があるのは、このエンジンを使用して製品フォームを変換し、ゲートウェイに基づく開発者が最終的に利益を得るようにすることです。

▐製品の  統合

ゲートウェイ製品の最良の状態はどのような状態ですか?開発者は毎日使用していますが、ゲートウェイの存在を気にする必要がないため、存在感が最も低い状態が最適な状態かもしれません。現在のアクセスゲートウェイは、製品フォームからいくつかの実装の詳細を公開しています。エントリアプリケーションは、アクセスを完了するためにいくつかの異なるシステムと対話する必要があります。クラウドネイティブ変換が完了すると、オールインワンをより適切に実現し、製品を統合できます。そして閉ループ。

▐迅速  かつ柔軟

ASIポッドのアップグレードは完了していますが、マシンの交換や移行の失敗などの操作を自動的に実行して、運用と保守のコストを削減できますが、クラウドの最も重要な機能の1つは、ダブルイレブンピークプロモーション前の迅速な拡張など、迅速な柔軟性です。 、大規模なプロモーション後の急激な縮小により、大規模なプロモーションの準備のために予約されているマシンリソースを大幅に削減できるため、コストを大幅に節約できます。もちろん、セキュリティ、信頼性、弾力性のあるリアルタイムなど、解決すべき多くの問題があります。これらはすべて、クラウドを真に活用するためにクラウドインフラストラクチャと一緒に構築する必要があります。

タオ部門建築および基本サービスチーム

タオ部門とアリに基本的なコア機能、製品、ソリューションを提供することをお約束します。

  • 次世代ネットワークプロトコルQUIC-XQUICの実装と着陸

  • アダプティブハイアベイラビリティソリューションとコア機能-ノア

  • 新世代のビジネス研究開発モデルプラットフォーム-ガイア

  • Aliのモバイルミドルウェアシステム全体をサポートします(数千万のQPSアクセスゲートウェイ、APIゲートウェイ、プッシュ/メッセージ、モバイル構成センターなど)

チームは大きな牛を集めます~~私たちに参加したい場合は、履歴書を[email protected]メールしてください。

✿さらに  読む

著者| Deng Bo(ライトコーン) 

編集|オレンジ

生産|アリババの新しい小売技術

おすすめ

転載: blog.csdn.net/Taobaojishu/article/details/110102413