本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。
著者: Xiang Dongwei（JoinQuantのシニア定量エンジニア）、Tao Yuchen（JoinQuantのシニア定量エンジニア）
背景
絶えず変化する金融市場において、データ駆動型の意思決定という利点を持つ定量投資は、投資コミュニティの中で新たな力として台頭しています。JoinQuantはテクノロジー企業であり、さらに国内金融市場におけるビッグデータに基づく定量研究のパイオニアでもあります。私たちは、定量研究や人工知能といった最先端技術を活用し、市場パターンの継続的な探求、アルゴリズムモデルの最適化、プログラム取引による戦略実行の自動化に取り組んでいます。JoinQuantの典型的な定量投資研究プロセスには、以下のいくつかの重要なステップがあります。
- ファクター抽出: 先進的なデータ分析技術を利用して、膨大なデータから投資戦略に予測力をもたらす主要な変数を特定します。
- 収益予測: 機械学習などの高度な技術を複数のファクターと組み合わせて、線形回帰、決定木、ニューラルネットワークなどのアルゴリズムをカバーした正確な予測モデルを構築します。
- ポートフォリオ最適化: 期待収益とリスク制約に基づいてアルゴリズムを最適化し、投資ポートフォリオの最適な配分を達成して投資収益を最大化します。
- バックテスト: 歴史的データで取引戦略をシミュレーションし、その有効性と安定性を評価します。
これらの各ステップは、大量のデータによって駆動される計算集約型タスクです。ECS、ECI、ACK、NAS、OSSなど、アリババクラウドが提供するクラウド製品を利用することで、JoinQuantの技術チームは過去数年間で完全な定量投資研究プラットフォームを迅速に構築しました。
JoinQuant投資研究プラットフォームに適用されたソフトウェア技術スタック
私たちはKubernetesを基盤とし、同時にNAS、OSS、SLS、GPU共有、HPA、Prometheus、Airflowといったアリババクラウドネイティブ技術を採用しています。これにより、計算コストの低さと容易な拡張性、コンテナ化による効率的なデプロイメントと俊敏な反復開発の強みを得ました。このおかげで、大量の歴史的金融データによって駆動されるファクター計算、定量モデルトレーニング、投資戦略のバックテストなど、多くの計算シナリオに対応できるようになりました。
しかし、実際の運用では、データ集約型および弾力的な柔軟性が必要なシナリオに対する真の定量投資研究製品のサポートにはまだ多くの不足があることがわかりました。
チャレンジ
定量投資研究の過程で、プラットフォームはパフォーマンスのボトルネック、コスト管理、複雑なデータセット管理、データセキュリティ問題、ユーザーエクスペリエンスの確保など、さまざまな課題に直面しました。特に高同時アクセスやデータセット管理に関して、従来のNASやOSSストレージソリューションでは、性能とコスト効率の両方の要件を満たせなくなっています。データサイエンティストは、データをより効率的かつ柔軟に処理しようとする際に、既存の技術によってしばしば制限されています。
-
データ管理の課題: 時間の経過とともに、データはNASやOSSといった異なるストレージプラットフォームに分散されます。ファクター抽出を行う際、研究者はNASとOSSに分散されたデータを統合する必要があり、データ管理が非常に複雑になります。場合によっては、データを手動で一つのプラットフォームから別のプラットフォームへ移行する必要があります。
-
パフォーマンスのボトルネック: ポートフォリオ最適化の際、定量研究者はバックテストのために大量の履歴データを迅速に読み込む必要があります。この場合、多数のマシンが同時に同じデータセットにアクセスします。そのため、ストレージシステムには数百GbpsやTbpsレベルの極めて高い帯域幅が求められます。しかし、分散ファイルストレージシステムの帯域幅の制限により、読み込み速度が遅くなり、モデルトレーニングの効率に悪影響を及ぼします。
-
コスト管理: 定量研究者が研究実験に費やす時間は非常に不確実で、一日に多数の実験を行う日もあれば、全く実験を行わない日もあります。これにより、帯域幅の需要が大幅に変動します。大量の帯域幅を予約すると、ほとんどの時間でリソースが無駄になり、不要なコストが増加します。
-
データセキュリティへの懸念: 異なるデータセットは研究者チーム間で隔離されていますが、同じOSSバケットやNASインスタンス内ではデータを効果的に隔離できません。
-
高い技術使用のハードル: 多くの定量研究者はデータサイエンティストであり、Kubernetesに詳しくありません。YAMLを使用して複数の永続ボリューム要求（PVC）を設定し、データソースを管理することは彼らにとって大きな課題です。
-
動的なデータソースマウントの問題: 定量研究者がJupyter Notebookを使用してデータを処理する際、頻繁に新しいデータソースをマウントします。この操作はNotebook環境を再起動させ、効率に深刻な影響を与えます。
ソリューション
私たちは、KubernetesのCSIシステムだけでは複数のデータソースの加速ニーズを満たすことができないことを発見しました。一方、CNCFサンドボックスプロジェクトであるFluidは、OSSやNASからのデータを簡単に管理・加速する方法を提供します。Fluidは、JindoRuntime、AlluxioRuntime、JuiceFSRuntime、VIneyard Runtimeなどのさまざまなランタイムをサポートしています。比較の結果、JindoRuntimeはシナリオの適合性、パフォーマンス、安定性において優れていることがわかりました。
JindoRuntimeはJindoCacheという分散キャッシュアクセラレーションエンジンに基づいて構築されています。JindoCache（以前はJindoFSxとして知られていました）は、アリババクラウドのデータレイク管理チームが提供するクラウドネイティブなデータレイクアクセラレーションサービスです。JindoCacheはOSS、HDFS、標準S3プロトコル、POSIXなどをサポートし、データキャッシュやメタデータキャッシュなどの機能を備えています。さらなる調査と実践的な使用を通じて、キャッシュコストやデータセットの安全な管理と柔軟な使用に関する多くの問題が効果的に解決されていることがわかりました。現在、このシステム全体はFluidに基づき、ほぼ1年間順調に稼働しており、定量研究チームに大きな助けとなっています。以下に私たちの経験と成果を共有します。
高いパフォーマンスと自動スケーリングによるコスト削減
個別設定によるパフォーマンス向上:
課題: 異なるタイプのデータ処理タスクを実行する際、単一のデータストレージ設定では要件を満たせません。例えば、トレーニングタスクのデータセットは読み取り専用にする必要がありますが、中間で生成される特徴データやチェックポイントには読み書き権限が必要です。従来のPVCには異なるストレージからのデータソースを同時に処理する柔軟性がありません。
解決策: Fluidを使用して、各データタイプごとに異なるストレージポリシーを設定できます。例えば、同じストレージシステム内で、トレーニングデータを読み取り専用に設定し、特徴データやチェックポイントを読み書き可能に設定できます。これにより、Fluidは顧客が同じPVC内で異なるデータタイプを柔軟に管理し、
Fluidを使用したデータキャッシュの弾力性と効率性の向上
最も注目に値するのは、これらの操作がPythonインターフェースを通じて実行できることです。これにより、ローカル開発環境と本番環境の両方で同じコードセットを使用して、正確な予測モデルを開発およびトレーニングできます。開発環境を再起動せずにデータソースを更新する方法について説明します。
問題点：
研究者がJupyterコンテナ内で作業している場合、新しいストレージデータソースを動的にマウントすることがよくあります。従来の方法では、ポッドを再起動する必要があり、これは時間の無駄になるだけでなく、ワークフローも中断されます。この問題は長年にわたり批判されてきました。
解決策：
FluidのDataset機能を使用すると、複数のデータソースを記述し、新しいポイントを動的にマウントしたり、古いポイントをアンマウントしたりすることができます。これらの変更は、コンテナを再起動することなく即座に反映されます。これが、データサイエンティストがコンテナ使用に関して抱える最大の懸念を解決します。
ただし、オープンソースのFluidには多くの利点があるものの、実際の運用において、それが私たちのニーズを完全には満たしていないことがわかりました。
不十分なサポート：
-
複数の種類の弾力的リソースに対するサポートが不完全
例えば、Alibaba CloudではElastic Compute Service (ECS) インスタンスとElastic Container Instance (ECI) を使用しています。ワークロードのスケジューリング中、システムは優先的にECSインスタンスにワークロードを割り当てます。ECSリソースが枯渇しない限り、システムはECIに切り替えません。そのため、Fluidには両方のリソースをサポートする必要があります。私たちが知る限り、オープンソース版のFluidのFUSE Sidecarは特権モードが必要であり、これはECIでは実装できません。 -
監視および可観測性ソリューションの不足と複雑な設定
プロダクションシステムでは、完全なログ監視ソリューションが依然として重要ですが、それを自前で開発するのは煩雑です。 -
動的マウントのサポートがない
これはデータサイエンティストにとって比較的硬直した要件です。
私たちは解決策を探し、ACKクラウドネイティブAIスイート内のack-fluidを見つけました。これにより、これらの問題をうまく解決できます。
ack-fluidの主な特長：
-
オープンソースのFluid標準に基づくJindoRuntimeの完全サポート
オフラインでのオープンソース版Fluidのデバッグ後、ACK上でフル機能を利用できます。 -
Alibaba Cloud Elastic Container Instance（ECI）とのシームレスな統合
特権モードを有効にする必要がなく、クラウド上の異なるデータソースへのアクセス要件を完全に満たします。 -
フル機能の監視ダッシュボードの統合
Managed Service for Prometheusにインストールするだけで簡単にアクセス可能です。 -
ECSおよびECI上での複数データソースの動的マウント
これは私たちが特に評価している機能です。
経験共有
高いネットワークI/Oと大容量メモリを持つECSおよびECIをキャッシュワーカーとして選択
FluidのJindoRuntimeは、高いネットワークI/Oと大容量メモリ能力を持つECSおよびECIを優先的にキャッシュワーカーとして選択します。ECSインスタンスのネットワーク能力は継続的に向上しており、現在のネットワーク帯域幅は標準SSDのI/O能力をはるかに超えています。例えば、Alibaba CloudのECSインスタンスタイプであるecs.g8i.16xlargeは、基本的なネットワーク帯域幅が32Gbit/s、メモリが256GiBです。仮にこのようなECSインスタンスを2つ提供した場合、理論上2秒で32GBのデータを読み込むことができます。
特定条件下でのECIスポットインスタンスの採用
バッチ処理などの高いフォールトトレランスが必要なシナリオでは、キャッシュワーカーとしてスポットインスタンスを使用し、Kubernetesアノテーション k8s.aliyun.com/eci-spot-strategy: SpotAsPriceGo を追加することで、コストメリットを得ながら高い安定性を確保できます。
スケジュールされた自動スケーリングポリシー
投資リサーチプラットフォームのスループットは、ビジネス特性により明らかな潮汐変動を示すため、キャッシュノードのスケジュールされた自動スケーリングポリシーを構成することで良い効果が得られます。これにはコスト管理とパフォーマンス改善が含まれます。また、個別に必要なデータセットについては、研究者が手動でスケーリングできるインターフェースを予約することもできます。
データ使用前のプリフェッチ
JindoRuntimeは、データを読み込みながらプリフェッチをサポートしています。しかし、この同時実行方式は高いパフォーマンスオーバーヘッドを伴います。私たちの経験では、まずプリフェッチを行い、同時にキャッシュ比率を監視します。キャッシュ比率が一定のしきい値に達すると、タスクがトリガーされます。これにより、事前に高並列タスクを実行することによるI/O遅延の問題を回避できます。
定期的なキャッシュ内のメタデータ更新
データ読み込み速度を向上させるために、JindoRuntimeのマスターにメタデータを長期保存し、複数回プルすることを選択しました。一方、ビジネスデータはしばしばバックエンドストレージシステムに収集され、キャッシュされないため、Fluidはこれらの変更を検出できません。この問題に対処するために、Fluidを定期的にデータプリフェッチを実行するように設定し、基盤となるストレージシステムのデータ変更を同期します。この設定はDatasetおよびDataLoadの設定ファイルで行っています。
弾力的なスループットによるパフォーマンスとコストの恩恵
実際の評価では、ecs.g8i.16xlarge仕様の20台のECIをワーカーノードとして使用してJindoRuntimeクラスターを構築しました。単一ECIの最大帯域幅は32Gbit/sで、タスクノードは最大帯域幅16Gbit/sのecs.gn7i-c16g1.4xlargeを選択しました。ダウンロードされるファイルサイズは30GiBです。高性能分散ストレージのピーク帯域幅は3GB/sで、この帯域幅はストレージ容量の増加とともに増加します。さらに、データ読み込み速度を向上させるために、メモリをデータキャッシュに使用することを選びました。比較のために、アクセス時間を計測し、Fluid技術を使用してデータにアクセスするのにかかった時間と比較しました。
サンプル結果:
並列ポッドの数が少ない場合、従来の高性能分散ストレージの帯域幅で需要を満たすことができます。この場合、Fluidは顕著な利点を示しません。しかし、並列ポッドの数が増加すると、Fluidのパフォーマンス上の利点がより明らかになります。並列処理が10ポッドに拡張されると、平均所要時間は従来法の1/5に短縮されます。並列処理が100ポッドに拡張されると、データアクセス時間は15分から38.5秒に短縮され、計算コストは1/10に削減されます。これにより、タスク処理速度が大幅に向上し、I/O遅延によるECIコストが削減されます。さらに重要なのは、Fluidシステムのデータ読み込み帯域幅がJindoRuntimeクラスターのサイズと正の相関を持っていることです。より多くのポッドを拡張する必要がある場合、JindoRuntimeのレプリカを修正してデータ帯域幅を増やすことができます。従