Baidu のクラウドネイティブ推奨システムの設計と実践

1. クラウドネイティブテクノロジースタック

次の図は、CNCF が公開したクラウド ネイティブ インフラストラクチャの抽象図です。

一般的なクラウドネイティブ テクノロジー スタックは、プロビジョニング、ランタイム、オーケストレーションと管理、アプリの定義と開発の 4 つのレイヤーに分けられます。また、監視、ログ記録、コール トレース、カオス エンジニアリングなどの観測および分析インフラストラクチャも含まれます。

私たちがすべきことは、レコメンデーション システムでクラウド ネイティブ アーキテクチャのこれらのレイヤーをうまく活用して、基本的な技術的機能を実現することです。初期の頃はクラウドネイティブなインフラがまだ完成していなかったため、レコメンデーションシステムを構築する際、インフラの一部を自社で構築した企業もありました。その後、クラウド ネイティブ テクノロジーが改善された後、レコメンデーション システムを設計する際、モジュール設計はクラウド ネイティブ テクノロジー スタックに基づいて行われます。形式に関係なく、より優れた統合を実現するには、クラウドネイティブ テクノロジ スタックと推奨システムのインフラストラクチャをより深く理解する必要があります。

2. 推薦システムのアーキテクチャ

推奨システムの技術アーキテクチャは、オンライン部分とオフライン部分に分けることができます。

オフライン部分では通常、コンテンツのモデリングが行われます。データが導入される際には、コンテンツエコロジーや協調データの導入など、コンテンツモデリングが行われるのが一般的です。私たちは、ラベル付け、ラベル特徴抽出、ベクトル化（つまり、いくつかのモデルに基づいて Doc データをベクトルに変換する）など、これらのデータのコンテンツを処理します。ユーザーのクリック、シェア、共有などのユーザーデータについては、データマイニング、ユーザープロファイリング、注目度抽出などを実施し、ユーザー属性のベクトル化も行います。これに基づいて、関連性や関連付けなどのユーザーのプッシュまたはドキュメント ディメンションの属性が呼び出され、並べ替えられ、最終的に表示されます。

流れに関しては、日常的に明らかな潮汐現象が見られます。たとえば、夕方のピーク時には交通量が多くなり、オフピーク時には交通量が少なくなります。

3. クラウドネイティブレコメンデーションシステム設計のポイント

レコメンデーションシステムの特性を考慮すると、設計時には3つのレベルから基本機能とビジネスアーキテクチャを構築する必要があります。最初のレイヤーでは、PaaS、イベント メカニズム、サービス オーケストレーション、サービス プロファイリング、インジケーター収集などを含むクラウド ネイティブ インフラストラクチャを構築する必要があります。これを基に、第 2 層では、ALM の完全なライフサイクル管理、容量管理、SaaS リソース管理、スケジューリング メカニズム、トラフィック管理、カオス エンジニアリングの安定性などの構築を含むクラウド ネイティブ機能を構築します。最終的には、コストの削減、研究開発の効率化、安定性の確保、ビジネス成果の向上、パフォーマンスの向上など、第 3 層のビジネス価値に反映されます。

次に、仮想化とマイクロサービス変革、サービスガバナンスと弾力性構築、クラウドネイティブ機能に基づく推奨ビジネスアプリケーション、安定性構築の 4 つの側面に焦点を当てます。

1. 仮想化とマイクロサービス変革

仮想化テクノロジーは、クラウドネイティブ システムの最も基本的な部分であり、本質的にはソフトウェアとハ​​ードウェアのテクノロジー スタックです。ハードウェア仮想化 (HVM) は、主に CPU などのハードウェアを使用して機密命令の処理を支援し、クライアント オペレーティング システムを変更せずに完全な仮想化機能を実現します。

VMware Workstation、Xen、KVM 製品またはアーキテクチャはすべてこのテクノロジを使用します。現在の市場における主流のハードウェアのほぼすべてが、ハードウェア支援による仮想化テクノロジをサポートしています。

仮想化を実装する最も一般的な方法は、機密命令を処理することで CPU、メモリ、および IO 仮想化テクノロジを実装する KVM テクノロジです。

もう 1 つのトレンドは GPU です。これはレコメンデーション システムでますます人気が高まっており、主にモデルのトレーニングやオンライン推論などの一連の高密度で複雑な計算に使用されます。 GPU は大容量のビデオ メモリと強力なコンピューティング能力を備えているため、企業がより低コストで使用し、効率的なコンピューティング結果を達成できるように、さらに仮想化およびセグメント化する必要があります。

仮想化が構築された後、重要なステップはマイクロサービスの変換です。マイクロサービス変換は、洗練されたスケジュールとサービス リソース操作の基盤となります。 Baidu を例に挙げると、初期のビジネストラフィックは急速に成長し、R&D の反復の効率は非常に高かった。初期の実装方法は巨大なサービスでした。各業務モジュールの機能が複雑化した後も、機能は依然としてモジュール内に実装されており、開発の反復がますます困難になっていました。モジュールが大きくなるにつれて、マシン上の一部のリソースが完全に占有され、一部がアイドル状態になることがわかり、マイクロサービス変換が必要になります。例えば、推定レイヤーでは、CTR推定、期間推定などが抽出され、サービスが細分化されます。

マイクロサービス分解の目標は、巨大なサービスとポータブルなサービスがないようにすることです。巨大なサービスは存在しないため、サービスのリソースの粒度は制限されます。同時に、移植性があり、各サービスは自動インスタンス移行を実装します。共通の容量拡張に加えて、移行によりサービス インスタンスの自己修復も可能になります。例えば、マシン全体にホットスポットが発生したり、サービスモジュールに異常が発生したりした場合に、それを素早く検出して自己修復することができます。

分割の原則としては、戦略とビジネスプロセスによる分割、組織チームによる分割、一般的なサービスのプラットフォーム化などがあります。

推奨システム サービスを変換する一般的な方法は、ユーザー モデル、コンテンツ データ、インデックス ソートなどの巨大なサービスを抽象化し、独立したプラットフォーム処理を実行することです。つまり、RPC を介して外部サービスにアクセスし、元の推奨サービスからそれらを抽出します。

一般的なサービス フレームワークを構築し、コンポーネント ベースの開発を通じて組み立て可能な戦略コンポーネントを構築します。ビジネスモジュールとアーキテクチャモジュールを含みます。アーキテクチャ モジュールには、フィルターやいくつかの基本関数などの再利用可能な基本モジュールと、CTR、ランクなどのいくつかの戦略的演算子が含まれており、アセンブリベースで使用するための演算子ライブラリの形式でビジネスに提供されます。

一般的に使用されるアセンブリ方法は DAG エンジンです。コード ロジック全体は、いくつかの構成ファイルを通じて組み立てることができます。

2. サービスガバナンスとレジリエンスの構築

アプリケーション ライフサイクル管理 (ALM) の目標は、サービス ガバナンスを通じてすべてのサービスを適切な動作状態に保ち、健全なリソース使用率を確保し、検出可能で介入しやすい状態にすることです。サービス ガバナンスの能力と効率は、アーキテクチャの持続可能な開発における重要な要素です。基本的な依存は、コンテナ オーケストレーションと仮想化のサポートです。これに基づいて、基本パラメータとパフォーマンスパラメータを収集してサービスオーケストレーションが実行されます。同時に、可観測性も実現する必要があります。

ALM によって収集されたデータを使用することで、統一的かつ標準化された方法でサービスを管理し、リソースの合理的な使用を実現できます。ただし、一部のサービスでは、リソース使用率は QPS の増加に比例して増加せず、サービスごとに使用率の許容率が異なります。そこで、サービスポートレートを中心としたクラウドネイティブ技術を構築しました。

システムコストの全体的な最適化を実現するために、各サービスの極端な負荷に応じて適切な容量が設定されています。サービス モデルの優先順位に基づくスケジューリング戦略により、最適なリソース割り当てを実現し、システム パフォーマンスを向上させることができます。従来の固定容量モデルを廃止し、サービス容量を動的に調整し、オンデマンドのリソース割り当てを実現します。

負荷変動の大きな違い、弾力性のレベルの大きな違い、負荷許容度の大きな違いなどの問題に対処するために、さまざまな種類のポートレートを通じて弾力性機能を構築します。たとえば、オンライン シナリオでは、夕方のピーク時間帯にトラフィックが高くなり、プッシュ シナリオでは、新しいホットスポットへのトラフィックが大幅に増加します。さまざまなサービスごとに、その変動特性を説明するためにパーソナライズされたトラフィック ポートレートが作成されます。さらに、各サービスの弾力性は、ストレージとコンピューティングの 2 つの側面からスコア付けされ、弾力的なスケーリングの基礎として機能します。

メトリック エージェントやデータ ポーリング、外れ値処理、欠損値の補完、データ集約などのデータ収集やその他の前処理方法を通じて、多次元のサービス ポートレートが構築されます。

ポートレートに基づいてパーソナライズされた ALM クォータ サイズ変更アーキテクチャが構築され、事前スケーリング、フィードバックおよびサーキット ブレーカー メカニズム、および段階的な調整制御プロセスを通じて安定性が確保されます。

ポートレートベースのサーバーレスは、トラフィック予測に基づいた弾力的なスケーリング戦略であり、早期予測と負荷フィードバックを提供できます。交通予測は、STL や LSTM などの時系列アルゴリズム モデルに基づいて実行されます。能動的な予測、事前評価、負荷監視、能動的な方法と受動的な方法の組み合わせを通じて、安定性とコストの両方を考慮した安全で回復力のあるメカニズムが構築されます。

上図は予測結果を示しています。推定誤差は 4% であり、単純なルールの 18% よりも大幅に優れていることがわかります。

3. クラウドネイティブ機能に基づく推奨ビジネスアプリケーション

解放されたリソースを追加の計算に使用して、さらなるメリットを得ることができます。

推奨される製品はユーザーの積極的な入力に依存せず、ほとんどのユーザーの「興味」は長期的かつ安定しています。ニアライン リコール メカニズムは、オンラインとオフライン間の新しいタイプのリコール方法です。数秒単位の遅延を許容し、コンピューティングの規模と複雑さが大きく、断片化されたアイドル リソースを使用でき、メカニズムのコストが削減されます。

非同期コンピューティングにより、オンラインコンピューティングから分離され、システム負荷に応じてアクティブに計算されるため、事前に予測結果が得られ、効果が向上します。リソースの状況に応じて計算パラメータが動的に調整され、リソースの安定した完全な利用が実現します。

4. 安定性の構築 - カオスエンジニアリング

カオス エンジニアリングは、2018 年に CNCF によって提案されました。これは、実験的な方法を使用して、複雑な分散システムが運用中の緊急事態に耐える能力に対する信頼を構築できるようにする、新しい技術分野です。

過去の事例とエンジニアの経験に基づく従来の安定性作業は、（障害発生 -> 問題解決 -> 次の障害発生）というサイクルです。システムを再構築してアップグレードした後、その安定性が維持されない可能性があります。

カオス エンジニアリングの全体的な目標は、これまでのケース ベースの受動的な運転を能動的な実験的な運転に置き換え、制御可能な範囲内で定期的に障害を注入し、システム リスクを積極的に発見し、安定性を検証し、アーキテクチャの反復的な最適化を促進することです。

カオスエンジニアリングの主なメカニズムは、赤青対立メカニズムを通じて障害のランダムな事前訓練を実施することです。障害シナリオを調整し、検査を自動化することで、回復力指数を使用して安定性を定量化できます。

過去の問題の抽象障害ライブラリに基づいて、定量化可能な安定性評価システムを確立し、回復力信頼度指標仕様を導入し、カオス実験を定期的に検査し、回復力指標を更新し、駆動アーキテクチャを最適化します。