金融サービス企業が信頼性の高いAIデータ配信を実現

欧州の大手資産運用会社は、オブジェクトストレージだけではAIワークロードの同時実行負荷に対応できないことを、深刻な事態を通じて認識しました。クライアントの設定ミスによってサービス拒否イベントが発生した後、同社はF5ソリューションを導入し、AIモデルのトレーニングに必要なS3データを、信頼性、拡張性、パフォーマンスを確保しながら配信できるようにしました。

課題

金融サービスと不動産の分野で確固たる地位を築いている欧州の資産運用会社は、AIに多額の投資を行っています。同社のデータサイエンスチームは、S3互換のオブジェクトストレージであるDell Elastic Cloud Storage（ECS）に保存された大規模なデータセットを使用してモデルをトレーニングし、AIワークロードをKubernetes上で実行しています。課題は、これらのワークロードとストレージを結ぶ経路にありました。

オブジェクトストレージプラットフォームは、トラフィックを制御するためではなく、容量を拡張できるように設計されています。長年にわたり、アプリケーションは管理されたネットワーク上で専用プロトコルを介してストレージに接続していたため、ファイラーやストレージアレイの前段でトラフィックを管理する必要はありませんでした。しかし、S3ストレージの登場によって状況は変わりました。現在、オブジェクトストレージには、キーを持つあらゆるクライアントがHTTP経由でアクセスします。そのため、ストレージのフロントエンドはWebサービスのように動作し、同様の原因で障害が発生する可能性があります。個々のストレージノードが同時に処理できるTCP接続数には、実用上の上限があります。AIパイプラインがトレーニングデータを取得するために数千もの並列セッションを開くと、その上限にすぐ達する可能性がありますが、ストレージチームが問題の兆候を事前に把握できることはほとんどありません。

この金融サービス企業では、設定に不備のあるクライアントがオリジンの処理能力を超える数の同時接続を確立し、実質的に自社のストレージに対するサービス拒否状態を引き起こしました。その結果、AIデータの取り込みが停止しました。

このインシデントにより、インフラストラクチャチームとストレージチームにとって、2つの点が明らかになりました。

第1に、1つのクライアントの異常動作によって、共有データプラットフォーム全体が停止するようなことがあってはなりません。特に金融サービスでは、信頼性は不可欠です。モデルのトレーニングスケジュール、分析、その後のビジネス上の意思決定はすべて、データプラットフォームが稼働し続けることを前提としています。

第2に、拡大するAIの取り組みを支えるためにECSノードを追加するという会社の計画を踏まえると、この問題はさらに深刻化する一方でした。前進するには、ストレージ境界での厳格なエンジニアリングと、S3トラフィックがストレージノードに到達する前に、そのトラフィックを制御、分散、保護できる制御ポイントが必要でした。

ソリューション

同社は、HAProxyやKemp Technologiesの製品を含む複数のソリューション候補を評価しましたが、S3プロトコル向けのアプリケーションデリバリー機能が限られていることが分かりました。

初期の価値実証デモンストレーションが決め手となりました。F5ソリューションは、ECSとシームレスに統合しながら、セッション維持などS3プロトコル固有の課題に対応できることを示しました。同社とF5双方の技術パートナーであるDellは、F5ソリューションとECSインフラストラクチャの整合を図り、共同アーキテクチャを推進することで、重要な役割を果たしました。

最終的に、この金融サービス企業はF5を採用し、BIG-IP Local Traffic Manager (LTM)を実行するF5 rSeries r5600アプライアンス4台を、ECSストレージの前段に専用のデリバリーティアとして導入しました。

導入には実績のあるリファレンス設計を採用し、リスクを軽減するとともに、AI環境の成熟に向けたロードマップを提供しています。その結果構築された2拠点のデータセンターによるアクティブ／アクティブアーキテクチャは、意図的にシンプルな構成となっています。動的ルーティングの仕組みを活用することで、DNSに依存せずに水平スケーリングと高可用性を実現します。現在、Kubernetes上で稼働するAIワークロードからのすべてのS3リクエストは、ストレージに到達する前にBIG-IP LTMを経由します。この設計上の1つの判断により、当初の障害原因が解消され、成長に向けた基盤が確立されました。

成果

コネクションプーリングによって同時接続の問題を直接解消するため、このプロジェクトの発端となったインシデントの再発を防止できます。BIG-IP-LTMは、クライアント側の大量のTCP接続を管理し、ECSノードへのサーバー側接続を、より少数の制御された接続群に集約します。また、接続を適切に制御することで、設定ミスのあるクライアントや過剰な接続を行うクライアントが1台だけでストレージノードのリソースを枯渇させることを防ぎます。1台のクライアントが不適切な動作をしても、すべてのチームがECSプラットフォームを引き続き利用できます。

測定可能なパフォーマンス向上を実現

一貫性のあるURLハッシュにより、リクエストはランダムではなく効率的に分散されます。同じオブジェクトへのリクエストはECSクラスター全体に予測可能な形で振り分けられるため、キャッシュ使用率が向上し、ホットスポットを回避できるほか、ストレージノードを追加してもスループットを安定して維持できます。

さらに、Mongooseストレージパフォーマンステストツールを使用した社内パフォーマンステストでは、データパスにF5ソリューションを導入した後、処理された入出力のパフォーマンスが500%向上したことが実証されました。TCP接続の最適化、サーバー側リクエストの多重化、動的ルーティングの活用により、このプラットフォームは、要求の厳しいAIワークロードのスループットを即座に向上させました。

再設計せずにAIの取り組みを拡張

同社は、AIの導入拡大に伴い、ECS環境を拡張する計画です。BIG-IP LTMは、ストレージエンドポイントを単一の仮想アドレスの背後に抽象化するため、アプリケーション構成を変更したり、ワークロードを中断したりすることなく、ノードを追加してECS環境を拡張できます。このように、信頼性の問題を解決したアーキテクチャが、事業の成長にも対応します。

ストレージを設計されたサービスへ

ストレージの前段に専用のアプリケーションデリバリ層を配置することで、適切なエンジニアリングプラクティスを実践しやすくなります。クライアントがノードに直接アクセスする、管理されていない密結合のメッシュ構成とは異なり、トラフィックを一元的に可視化し、負荷分散と制御を行えます。ストレージアーキテクトにとっては、ノードの挙動を予測しやすくなり、明確なキャパシティプランニングが可能になります。CIOにとっては、AIデータプラットフォームがポイントツーポイント接続の寄せ集めではなく、適切に設計されたシステムであることを意味します。

AIデータ配信のパートナーシップを基盤に構築

F5とDellは、まさにこの種のワークロードに対応するため、BIG-IP LTMのトラフィック管理とAIパイプライン向けのS3互換オブジェクトストレージを組み合わせ、共同でエンジニアリングを続けています。他の企業がここから得られる教訓は、S3オブジェクトストレージはWebサービスであり、AIワークロードによってWebサービスと同様に大きな負荷がかかるということです。ストレージの前段に専用のアプリケーションデリバリーコントローラーを配置することで、外部に公開されたオリジンを、AIの効果的な導入に必要なレジリエントなデータパイプラインへと変えることができます。