快手ドラゴンフライ戦略エンジンの設計と応用

1. 問題と課題

1. 問題の背景

2018年以来、Kuaishouの事業全体は急速に発展しており、チームも急速に拡大しています。過去 5 年間で、DAU は 1 億から 3 億 7,600 万に増加しました。 2021年、KuaishouのDAUは3億を突破しました。主な推奨シナリオも、初期の発見ページ、フォローページ、ローカルページから、eコマース、ライブストリーミング、成長、海外とローカルライフなど、現在では数百の推奨シナリオに拡大しています。

事業の急速な発展に伴い、R&Dチームは数十人から数千人に拡大しました。このような状況において、2 つの主要なビジネス上の要求が浮上しました。1 つ目は、新しい推奨シナリオを迅速に構築すること、もう 1 つは、効果的な戦略を迅速に複製することです。

2. 問題

当初、開発チームはこれら 2 つの要求を満たすために、既存の機能のアーキテクチャ コードをコピーして開発プロセスを高速化することを選択しました。しかし、シーンの数が増え続けるにつれて、このアプローチは受け入れられなくなってきました。したがって、長期的には、Kuaishou は既存のコード アーキテクチャを再検討して最適化し、将来の開発ニーズに適応できるようにする必要があります。

同時に、このアプローチでは、アーキテクチャ全体の保守が困難になります。 Kuaishou では、アーキテクチャとアルゴリズムの人員比率が比較的低く、アーキテクチャ エンジニアにかかるプレッシャーが高くなります。オンライン システムのすべてのコードは C++ で記述されています。アルゴリズム チームの人数が増えるにつれて、システムはますます複雑になり、オフライン コードの品質を管理することが難しくなります。オンラインの安定性の問題は、多くの場合、コードのバグによって発生します。

さらに、エンジニアリング チームとアルゴリズム チームの間には、当然ながら目標の違いがあります。たとえば、アルゴリズム チームは迅速な反復と実験的なリリースを追求しますが、エンジニアリング チームはシステムの保守コストに重点を置いています。したがって、Kuaishou は、システム全体の安定性と保守性を確保するために、2 つのチームのニーズと目標のバランスを取る必要があります。

もう 1 つの深刻な状況は、プロジェクトのアルゴリズムとエンジニアリング コード全体が同じワークスペースに記述されているため、互いに支え合い絡み合う DNA の二重鎖構造のように、コードが深刻に結合してしまうことです。これは、それぞれの側が他方に予期せぬ影響を及ぼす可能性があることを意味します。

このようなモデルでは、エンジニアリング チームは周期的な再構築の悪循環に陥ることがよくあります。システムの反復時間が長くなるにつれて、システム全体の複雑さが徐々に増大します。一定のしきい値に達すると、エンジニアリング チームはシステムを再構築するために多くの人的リソースを投入する必要があります。再構築が完了すると、システムの複雑さは一定のレベルまで軽減されますが、時間が経つにつれて、1、2 年の反復を経て、システムは再び複雑になり、再度再構築が必要になります。このサイクルは1～2年ごとに発生します。

このような大規模な改修が行われるたびに、エンジニアリング チームは疲弊し、チーム メンバーが他のより価値の高い建築のアップグレードに集中することが難しくなります。したがって、この循環的な復興の運命をいかにして打破するかが、緊急に解決しなければならない重要な課題となっている。

詳細な分析の結果、チームは問題の根本的な原因はビジネス コードとアーキテクチャ コード間の過剰な結合にあることを発見しました。この問題を解決するために、Kuaishou は独自に戦略エンジン フレームワークを開発しました。以下では、フレームワークがこれらの問題をどのように解決するかについて詳しく紹介します。

2. Dragonflyフレームワークの紹介

1. トンボとは何か

Dragonfly は、検索、広告、プロモーション分野向けの汎用グラフ エンジン フレームワークとその周辺ツールによって構築された開発エコシステムとして位置付けられています。このシステムは、Kuaishou の社内検索、広告、プロモーション サービスに統合されたベース エンジンを提供するとともに、上位レベルのビジネスに柔軟なプロセス オーケストレーション機能を提供します。

最下層には、いくつかの効率的なデータ モデルが組み込まれており、豊富な周辺ツールが提供されています。上図はアーキテクチャ全体を示しています。最上層は、さまざまな検索、広告、プロモーション分野のポリシー エンジンです。その下には、ポリシー サービス、リコール サービス、大まかなランキング サービスと細かいランキング サービスをサポートするコア レイヤーがあります。最下層は、グラフ スケジューリング エンジンです。 DSL オペレータ オーケストレーションにより、アルゴリズム開発モデルは C++ ベースから Python ベースに正常に変換されました。

2. 戦略オーケストレーション

上の図は、Dragonfly が戦略を記述する方法で表現されたコード例を示しており、非常に直感的です。このコードは、ワークフローの概念に似たフロー プロセス オブジェクトを定義します。このフローでは多くのメソッドが提供されており、各メソッドの背後には対応する演算子があります。スクリプトを通じて、このプロセスを簡単に理解できます。最初の 2 つの方法は 2 段階のリコールであり、インデックスとサービスからリコールし、その後重複排除、公開、フィルタリングなどを実行します。次に、嫌いな機能に応じてフィルタリングして切り捨てます。次に、多様性を分割し、切り捨てて戻すという次の段階に進みます。

Python の DSL 記述により、アルゴリズム開発者は C++ コードを書く必要がなく、Python スクリプトを通じてポリシー プロセスを簡単かつ直感的に記述できます。この DSL スクリプトは Json ファイルにコンパイルされ、オンライン C++ サービスに渡されて実行されます。こうすることで、オンライン パフォーマンスを犠牲にすることなく、Python でロジックを記述する利便性を享受できます。

この効果を実現するために、プロセス抽象化とデータ抽象化という 2 つのコア抽象化を作成しました。

3. プロセスの抽象化

演算子化メソッドと DAG を組み合わせて、ビジネス機能全体をさまざまな演算子に分割して抽象化します。これらの演算子には、フィルタリング、リコール、モデル推定などの一般的な演算子がいくつか含まれます。これらの演算子は基本的にアーキテクチャによって記述および保守されるため、繰り返し記述する必要なく、さまざまなビジネスで直接再利用できます。

カスタム演算子は、一般的な演算子では満たすことができないカスタマイズされたビジネス ロジックを満たすために使用されます。これらのカスタム演算子は、非常に柔軟な要件を満たすためにビジネス担当者自身が作成できます。

前述の Python DSL を使用すると、開発者はこれらの演算子を簡単に調整できます。さらに、このスクリプトは本質的に Python コードであるため、Python 独自の構文機能を使用して、より複雑なコード分割やモジュール管理機能を実装できます。

DAG 構築方法全体はデータ駆動型の暗黙的な構築に基づいているため、すべてのオペレーターがフルプロセスドリフトを実現できます。

図に示すように、6 つの演算子を含むフローがあり、そのうち B、C、D は非同期演算子であり、それぞれ下流の依存関係 E と F があるとします。データの依存関係と位相順序に基づいて、B と C が並列関係にあり、B、C、E 全体と D も並列関係にある DAG グラフを一意に推測できます。したがって、全体の処理構造は上図の中央のようになります。

このような構成メカニズムを通じて、理論的には任意の複雑なビジネス ロジックとビジネス プロセスを構築することが可能です。ここで言うフルプロセスドリフトとは、さまざまなメソッドの位置を任意に変更すると、構成の構造が自動的に変化することを意味します。

最後に、プロセス全体のスケジュールは、高いオンライン同時実行要件をサポートするためにロックフリー設計になっています。

4. データの抽象化

プロセスの抽象化に加えて、Dragonfly のもう 1 つの重要な抽象化機能はデータの抽象化です。ビッグデータ分野における列格納テーブルの概念に似た、DataFrame テーブル構造と呼ばれる高性能なデータ構造を提供します。

論理的には、DataFrame テーブル構造は、図に示す 2 次元データ テーブルのようなものです。アイテム側のデータを例にとると、各行はアイテムを表し、各列はアイテムの属性または機能を表します。 Common 側のデータは実際には似ていますが、共通データはすべての項目で共有されるため、それを運ぶための基盤レイヤーとして、特殊な 1 行の DataFrame 構造が使用されます。このような DataFrame 構造により、統合データ インターフェースの機能を実現するのは比較的簡単です。たとえば、Dragonfly アーキテクチャは、上位層にシンプルなキー値データ インターフェイスを提供します。アイテムが機能の値にアクセスする場合、値を取得するには、アイテムのキー (通常は item_id) と名前を渡すだけで済みます。スキーマフリー機能により、新しい機能やデータの追加によってオンライン システムを頻繁に再コンパイルする必要がなくなり、protobuf よりも使いやすく効率的になります。

さらに、Dragonfly フレームワークでは、データのインデックス作成や DataFrame 間のデータ転送など、さまざまな側面で実行されるゼロコピー テクノロジなど、構造に対して多くのパフォーマンス最適化が行われています。

Dragonfly フレームワークのより高度な機能は、論理テーブルの包括的なサポートです。複雑なビジネス シナリオでは、処理する物理テーブルが大きい場合があり、各チームはプロセスの一部にのみ集中する必要があります。したがって、データベースのビューに似た概念である、基礎となる物理テーブルに基づいて論理テーブルを作成できます。読み取り専用ビューとは異なり、Dragonfly アーキテクチャによって作成された論理テーブルは読み取りおよび書き込み可能であり、他のチームがデータ操作スペースを分割するための参照として使用できます。このようにして、チーム全体がより明確かつ柔軟にデータ操作スペースを管理できるようになります。

統合データインターフェースにより、データの読み取りと書き込みの管理が簡単に実行でき、非準拠のデータ使用の有無を含め、オンラインデータの読み取りと書き込みの使用状況を簡単に整理して監視できます。フレームワーク全体には、データの同時セキュリティを確保するためのセキュリティ メカニズムが組み込まれています。

5. DSL層は高レベルの抽象化機能を提供する

前のセクションでは、基盤となるフレームワークのコア機能を紹介しましたが、ユーザーは主に DSL レイヤーを認識します。 Dragonfly は、ユーザーが直接使用できる標準演算子のカプセル化などの、いくつかの高レベルの抽象機能を提供します。ユーザーにとって、同期や非同期は気になりません。基盤となる実装が同期か非同期かを気にすることなく、オペレーター インターフェイスを呼び出すだけで済みます。

さらに、Dragonfly は、最下層で分岐プロセス制御やデータ並列コンピューティングなどの高レベル機能を提供します。上の図は、データ並列計算の例を示しています。double 型のスコアを計算するとします。計算されたスコアごとに 1 ミリ秒かかる場合、8 回の連続計算には 8 ミリ秒かかります。ただし、実際には各スコアの計算は独立しており、データに対する並列操作と見なすことができます。フレームワークが提供する @parallel デコレータを使用して、データをスライスするためのパラメータを指定できます。各スライスには 4 つの項目が含まれます。各スレッドは 1 つのデータを処理して並列操作を実現し、8 ミリ秒を 4 ミリ秒に短縮します。原理はベクトル化アクセラレーションと同じです。

このプロセスでは、Dragonfly はサブプロセスを非同期にするのに役立つ @async デコレータを提供し、上位レベルの DSL がより複雑なビジネス ロジックを構築するのに役立つモジュール コンポーネントも提供します。従来の C++ コード実装と比較すると、Dragonfly の DSL を使用する場合、多くの複雑な機能を実装するためにデコレータを追加するだけで済みます。

6. 階層的分離

Dragonfly Python DSL を通じて、アルゴリズムとアーキテクチャ全体の R&D ワークスペースを分割および分離し、明確な階層を実現します。 DSL の上にはアルゴリズムのワークスペースがあります。アルゴリズム開発者は、基礎となるオペレータの実装を気にすることなく、オペレータを調整し、構成を送信するための DSL を記述するだけで済みます。 DSL の下にはアーキテクチャ ワークスペースがあり、アーキテクトはここでオペレーターを記述し、構成を実行するためのバイナリを提供するだけで済みます。アーキテクチャでは、上位レベルのビジネス ロジックを考慮する必要はありません。このようにして、明確な階層分割が達成され、両者の間に強い結合効果は発生せず、相互干渉が回避されます。

7. 申請状況

現在、Dragonflyは検索とプロモーションの分野全体で数千のオフラインサービスの運営をサポートしており、オンラインレコメンデーションのコアリンク全体をカバーする技術モデルを実現しています。図に示すように、適用範囲はポリシー サービスだけでなく、リンク全体でのリコール サービス、粗いソート、細かいソート、再ソート サービスも含まれます。

この一連の技術モデルを採用することで、いくつかの重要な目標が達成されます。まず、統一された技術モデルによって、オンライン サービス プロトコル全体が実装されます。この技術モデルは便利な監視条件も提供し、リンク全体の各サービスの内部オペレータステータス、CPU 消費量、その他のシステムリソース指標を簡単に監視できます。さらに、一部の基礎となる最適化とコンパイラの最適化も一度開発すれば、すべてのサービスで再利用できます。

すべてのサービスがこのモデルを採用すると、リンク全体が柔軟になります。これは、リンク ノード上の各ノードを柔軟に分割および結合できることを意味します。ビジネスの反復時間が長くなるにつれて特定のノードのサービスが肥大化し、単一マシンのリソースでは対応できなくなった場合は、大きな単一ユニットのサービスから 2 つの小さな単一ユニットのサービスに分割できます。同様に、一部のサービスが単一のマシン上でリソースをあまり消費していないことが判明した場合、2 つのアップストリーム サービスとダウンストリーム サービスを柔軟に統合して 1 つのサービスにすることができます。この柔軟なアーキテクチャはマイクロアーキテクチャのように機能し、新旧のサービスの移行を含め、リンク全体のアーキテクチャを柔軟に調整できます。移行経験によると、この一連の技術モデルを採用すると、元のサービスの C++ コードの量を 50 ～ 80% 削減でき、コードの複雑さとオンラインの安定性およびセキュリティのリスクが大幅に軽減されます。

3. エコロジカルな建設

1. エコツール

ビジネス チームがこのフレームワークを効率的に使用するには、優れたフレームワークを作成するだけでは十分ではありません。ユーザーがこのフレームワークの利点を十分に体験できるようにするには、ツールの巨大なエコシステムを構築する必要があります。

上の画像は現在利用可能なツールを示しています。これらのツールは、オンライン化前のコーディング支援や機能のデバッグ、オンライン化後の指標監視やアラーム分析など、戦略開発の全プロセスをカバーします。このフレームワークの最大の利点は、これらすべてのエコロジカル ツールを一度構築すれば、ビジネス全体で再利用できることです。次に、いくつかの重要なツールを紹介します。

2. 遊び場

これは Web バージョンのデバッグ ツールです。ユーザーはページ上で直接 DSL を記述し、Web ページを通じて結果を表示できます。この Web バージョン ツールを使用すると、ユーザーはゼロ デプロイメントのオンライン ライティングとデバッグを実現できます。応答時間は数秒で、ユーザーは Python コードで入力データと出力データを作成し、実行して効果を確認するだけです。結果を直接表示するだけでなく、ユーザーは Python print を通じてプロセス内の機能データを表示したり、基礎となる C++ 演算子の glog ログを表示したりすることもできます。これにより、ユーザーはプログラム ロジックを簡単にデバッグできるようになります。

3. ホワイトボックスレビュー

すでに開始されているオンラインサービスでは、何らかの不都合な状況が発生して調査が必要な場合、フレームワーク全体で自動的にチェックする機能があります。ユーザー ID (uid) を使用すると、履歴レコードでリクエストの完全な実行を追跡できます。リクエストがどのオペレータを通過したか、各オペレータが費やした時間、出力データ、その他の詳細情報を確認できます。このようにして、開発者は履歴を追跡し、起こりうる問題をトラブルシューティングすることができます。

4. 視覚化

これにより、ビジネスプロセスを上から下へ、大まかから細かいものまで表示できるため、ビジネスプロセス全体の概要をより明確かつ直感的に理解できるようになります。

5. コードガバナンス

多くの開発チームは、アルゴリズム コードの無限拡張の問題に直面しており、効果的な防止メカニズムを必要としています。 Dragonfly フレームワークは、オンラインで実行されている無駄な演算子を自動的に検出して呼び出すことができ、無駄なブランチを識別することもできます。これにより、システムは右側のブランチごとのレポートなどの定期的なレポートを生成できるようになります。このレポートでは、どの作成者がどのファイルと関数のどの未使用のブランチを作成したか、また何日使用されていないかを正確に特定できます。

このようなレポートがあれば、無駄なコードを書いた人を直接特定し、その作成者にレポートを送信して、より深い分析を行い、無駄なコードを削除するよう促すことができます。このようにして、コードが無限に拡張されることを効果的に防ぐことができ、将来のシステムの合理化と再構築に対する不必要な圧力と消費を回避できます。

IV. 計画の見通し

今後は、全体の枠組みを見据えて、以下の3つの分野で引き続き取り組んでまいります。

1. パフォーマンス

NUMA 対応機能を提供するための作業が進行中です。新しい世代の CPU アーキテクチャはマルチ NUMA アーキテクチャへと移行しており、これにより既存のサービスのパフォーマンスが最適ではなくなる可能性があります。ハードウェアのパフォーマンスを最大限に活用するには、上位レベルのコードが CPU アーキテクチャをより深く認識できる必要があります。現在のフレームワークにより、上位レベルのオペレーターは NUMA アーキテクチャの状況をより簡単に把握し、メモリ割り当て戦略を柔軟に制御して、より優れたメモリ アクセス パフォーマンスを実現できるようになります。

さらに、リンク関係全体に基づいてグラフの最適化を実行し、オンライン サービスの時間の消費を削減することができ、この最適化はリンク全体に拡張できます。

2. 制御と管理

フルリンク統合ベースエンジンのサポートにより、フルリンク機能の管理とデータソースの追跡を簡単に実現できます。将来的には、どのデータが不要になったかを自動的に検出し、直接削除できるようになります。

同時に、システムの自己浄化機能を構築し、コードガバナンスを自動化します。システムは、無駄なロジックや非効率的なコードを識別し、定期的にコードベースから自動的に削除できるため、システムの堅牢性が継続的に確保されます。

3. 製品化

今後はエコツールチェーン全体の構築を強化し、よりスマートなツールを提供し、AI技術を活用してより効率的な研究開発プロセスを推進していきたいと考えています。

このシステムは、より完全な統合ソリューションの提供や、B2B 機能の提供にも取り組んでいます。

この分野に興味があり、私たちと一緒に素晴らしい成果を生み出したいとお考えの方は、履歴書を [email protected] までお送りください。私たちは協力して、より強力でスマートなツールとサービスを構築していきます。ご参加、ご支援いただいた皆様ありがとうございました！

5. 質疑応答

Q1: Dragonfly のカスタム演算子の表現力には限界がありますか? それとも、常に C++ に変換できますか? あるいは、より複雑な C++ 推奨ロジックをカバーできますか?

A1:演算子の抽象化の程度によって異なります。この演算子は C++ コードに直接変換されるのではなく、C++ コードからアセンブルされるためです。たとえば、フィルターを実行するには、非常に詳細で具体的なフィルター コードを直接 Python で記述してから翻訳するのではなく、まずフィルターに関連するロジック (公開されているロジックと構成可能なロジック) を抽象化し、フィルターのコア ロジックを抽象化して誰でも再利用できるようにする必要があります。演算子はコード行レベルまで細かく指定できません。

Q2: カスタム演算子の分割粒度はどれくらいですか?実際の開発では、カスタム演算子にするか、アルゴリズム側にするかは学生が決めます。

A2:これは通常、アルゴリズム側で開発され、エンジニアリング側では通常、いくつかの一般的な演算子が開発されます。カスタム演算子の部分には、実際的な問題がいくつかあります。たとえば、アルゴリズムを学習する学生によって、抽象化能力やコーディング能力が異なります。カスタム演算子の粒度制御や設計が不十分な場合があり、カスタム演算子の再利用性が制限されることになります。

Q3: 3 番目の質問は制御フローについてです。制御フローと TensorFlow のグラフの本質的な違いは何ですか?制御フローはどのように実装されますか?

A3:概念的にはTensorFlowに似ており、同じくデータ駆動型の構成方法です。 TensorFlow はこれを変数として直接公開し、変数を渡すことでデータの依存関係を推測できます。ただし、データは DSL では隠れた概念です。たとえば、この記事の例では、ctr や pctr などのデータは構成項目とみなされ、特定のオペレーターの構成に反映されます。コードレベルでは、このデータを引き継ぐための pctr Python 変数のようなものは存在しませんが、DSL の下に隠された概念です。データの関係が非常に複雑なため、変数渡しを使用して明確に表現することは困難です。これは TensorFlow との違いです。 TensorFlow はパラメータ渡しを通じてデータを転送し、制御フローは関数構成を通じて行われます。その入力パラメータには、pctr と呼ばれるリテラル値があります。後続の演算子には、その前の依存関係と次の依存関係を決定するために、構成された入力として pctr 値があります。したがって、全体のロジックもトポロジとデータ依存関係によって構築されます。つまり、原則は似ていますが、具体的な実装の詳細は若干異なります。

Q4: マイクロサービスの分割についてですが、Dragonfly で実装されているファイルはマイクロサービスです。DSL における演算子の構成とマイクロサービスの分割にはどのような関係があるのでしょうか。

A4: DSL は実際にはサービスの構成に対応しています。たとえば、ポリシー サービスは最終的に Json 構成を生成し、それがシステムに引き渡されて展開および操作されます。対応する下流のリコールの粗いソート、細かいソート、および再ソートにも独立した構成があります。これは、オンライン サービス ノードに対応する DSL に相当します。ノードを分割したい場合は、実際には DSL の前半のメソッド呼び出しを抽出し、別の DSL ファイルに移動するだけです。