役員SNS
TuringTechTalk#42 ペタバイト級データセットの作り方 ─ 学習を止めないためのスループット・再現性・運用設計
はじめに
自動運転AIの性能は、モデルそのものだけでなく、どのようなデータを学習に利用するかによって大きく左右されます。高品質なモデルを継続的に開発するためには、膨大な走行データを効率よく収集・管理し、学習に適したデータセットへ変換する仕組みが欠かせません。
チューリングでは、自社で収集した走行データがすでにペタバイト級に達しており、その膨大なデータを安定して運用しながら、機械学習モデルの学習を止めないデータ基盤の構築に取り組んでいます。
今回のTech Talkでは、CTOの山口祐と、自動運転第4グループマネージャーの安本雅啓が登壇。チューリング社内で開発・運用しているデータセット基盤「GARUDA」を題材に、ペタバイト級データセットの設計思想から、データパイプライン、ストレージ設計、開発者体験の改善、そして運用まで、その技術的な取り組みを詳しく紹介しました。
※本記事は「Turing Tech Talk #42」の内容をもとに、一部編集のうえお届けします。
山口：皆さん、こんにちは。Turing Tech Talk 第42回「ペタバイト級データセットの作り方」を始めていきたいと思います。私はTuringのCTOの山口です。本日は自動運転第4グループのマネージャーで、MLOps(機械学習の開発・運用基盤)を担当している安本さんに来てもらっています。安本さん、今日はよろしくお願いします。
安本：よろしくお願いします。
山口：今回「ペタバイト級データセットの作り方」ということで、結構大きく出たタイトルかなと思うんですけど。
安本：そうですね。大きく出ないとなかなか来ていただけないかなと思って、今回は大きく出てみました。
山口：煽り気味ですね。ただ間違ってはいなくて、言っていること自体は本当にペタバイト級のデータを扱っているので、その作り方をお話しできればと思います。実際にこのペタバイト級のデータを扱ってデータセットを作っているのがまさにTuring内部でやっていることで、その中身がどうなっているかを今日は深掘りできたらと考えています。それでは登壇者紹介です。安本さん、簡単に自己紹介をお願いします。
安本：私は新卒で日立製作所に入社し、鉄道のITシステムの研究開発を担当していました。その後、AIスタートアップのアラヤにて開発案件に携わり、CTOに就任。2021年4月にatama plusへ入社し、アルゴリズム開発エンジニアとしてAI教材atama＋のレコメンドエンジンの開発を担当しました。2024年5月にTuringへ入社し、ちょうど2年と少しが経ったところです。
山口：安本さんは入社当初からずっとMLOpsに関わっていて、今はその責任者を務めています。MLOpsがまだ担当者1人という時代から、Turing社内のMLOpsを立ち上げてきて、いよいよスケールするようになってきたというところなので、今日はその歴史的経緯も含めて色々と聞いていければと思います。Turing Tech Talkは、Turingの最新の研究開発の内容を、担当エンジニアが直接解説するという企画です。今回はデータセット設計、特に自動運転というドメイン、あるいは最近でいう「フィジカルAI」(現実世界のセンサー情報を扱うAI全般を指す言葉)のドメインで、データセットをどう設計し、どう運用するかについて、幅広く応用可能な技術を取り上げます。この後、会社紹介を挟んで、安本さんから本題であるペタバイトデータセットの作り方を解説してもらいます。本日のタイトルは「実例を元に解説、自動運転モデル開発のためのペタバイト級データセットの作り方」です。
安本：実例を話すというより、MLOpsの設計やアーキテクチャに踏み込んだ話が中心になります。これからMLOpsをやりたいという方には参考になる内容かなと思います。
データパイプラインの全体像
安本：自動運転AIの学習データがどのように作られるのか、その全体像を紹介ご紹介します。Turingは自動運転の開発のために自社で車両を保有し、データを収集しています。平和島の車庫にたくさんの車両があり、それが毎日東京中、さらには全国を走り回ってデータを取得しています。このデータをいかにMLモデルへ読み込める形にするか、というのが今回のデータパイプラインの内容です。
流れとしては、まず車から上がってきたデータが、クラウド(AWS)内に格納されます。最初に入るのが「データレイク」で、これは動画や生のバイナリデータなど非構造化データを格納する場所です。ただこれだけではデータがどこにあるか分かりにくいため、そこから構造化したデータに変換して格納する場所が「レイクハウス」で、Turingでは実際の基盤としてDatabricks(データ分析基盤サービスを提供する企業、およびそのサービス)上に構築しています。レイクハウス上のデータはテーブル形式、いわばデータウェアハウスのようなものです。このテーブルのままではMLモデルに直接入力するのは難しいため、最終的にファイル形式のデータセットに変換して保存する工程があり、これが「データセット作成」で、できあがったデータセットはS3(Amazon S3、AWSのオブジェクトストレージサービス)のバケットに格納されます。さらに、このS3上のデータセットは、オンプレミスのGPUクラスターで使う際には、Lustre(大規模計算環境向けの高速並列ファイルシステム)と呼ばれるストレージシステムにダウンロードして利用します。
山口：ここまでの流れが非常に分かりやすかったのですが、何人かエンジニアではない人も聞いているかもしれないので、ベースから色々と教えて欲しいなと思います。
チューリングは自分たちで車両を持っていて、センサーをつけたりして人間が運転をしてデータを集めている訳なんですけれども、一日どれくらいの分量が取られていますか？
安本：日によってかなり変動しますが、数十テラバイトは入っているという形ですね。
山口：車両には4TBほどのSSDを積んでいますが、1日の走行で1台分が足りなくなることもあり、10台程度が走ると1日で40TB程度のデータが上がってくることもあります。これがSSD経由でインターネット越しにAWSへアップロードされ、データレイクに蓄積されていきます。すでにデータレイクに入っているデータの量が、タイトルにもある「ペタバイト級」です。普通のPCで100GBのZIPファイルを扱うだけでも時間がかかりますが、それが1000倍、1万倍の規模になるということです。保存コストも当然大きな課題です。
DatabricksとSparkについて
山口：Databricksという会社について補足しておくと、Databricksは米サンフランシスコに本社を置く未上場のソフトウェア企業で、時価総額はおよそ20兆円規模とされ、日本の上場企業でいえば時価総額10位前後に匹敵する規模です。Databricksは、Apache Spark(分散データ処理のためのオープンソースフレームワーク。Apache Software Foundation、略称ASFが管理する)を開発したメンバーが立ち上げた会社で、Sparkをエンタープライズ向けに使いやすく、また高性能にチューニングし、クラウド上で扱えるようにしたマネージドサービスです。Apache Sparkは2010年前後に登場したフレームワークで、その前身にあたるHadoopのMapReduce(分散処理の仕組みの一つ)がディスクへの書き込みを多用して低速だったのに対し、Sparkはできるだけインメモリで処理を完結させることで高速化を実現した、という歴史的経緯があります。
プロジェクト「GARUDA」
安本：今回お話しする新しいデータセット作成の仕組みには、開発時のコードネームとして「GARUDA（ガルーダ）」という名前がついています。ガルーダはヒンドゥー教などにおける神鳥の名で、インドネシアの国章やガルーダ・インドネシア航空の社名にも使われています。【大事なデータをMLモデルやMLエンジニアに届ける、そのための力強い鳥】、というイメージから名付けました。
安本：GARUDAには、社内のユーザー(Turingの車内エンジニア)に対する「4つの約束」があります。1つ目は全く新しいデータセットフォーマット(ガルーダビルダー)、2つ目は刷新された開発者体験、3つ目はオンザフライでの動画デコーディング、4つ目は圧倒的なストレージコストの効率化です。これらはすでにすべて実現されており、社内では旧システムから完全に移行が完了しています。それでは一つずつ説明していきたいと思います。
約束1:新しいデータセットフォーマット
安本：以前は、nuScenes(自動運転分野でデファクトスタンダードとなっている、複数の関連データをリレーショナルデータベースのような形で正規化して格納するデータセットフォーマット)準拠の形式を採用していました。これは拡張性が高く、アカデミアの実装や論文でよく引用されるため、既存のモデルを試しやすいというメリットがありました。一方で、nuScenes自体が公開している走行データはおよそ6時間分と非常に少なく、大規模スケールを想定した設計にはなっていません。また、1つのJSONファイルが数十GBに達し、メモリに載り切らなくなるなど、フォーマット自体にスケーラビリティの限界がありました。
安本：そこでGARUDAでは、1テーブルのみ、1レコードが1サンプルに対応するシンプルなフォーマットに変更し、必要なデータをすべてそこに格納するようにしました。これにより高速な読み込み性能と高いスケーラビリティを確保しています。ただし、キャリブレーション情報のように本来はサンプルごとに変化しないデータも、あえて冗長に持たせるトレードオフを採用しています。これは、スケーラビリティと高速な読み出しを最優先した設計判断です。
山口：なるほど。なお、車両データはほぼ映像データが容量の大部分を占めており、CAN(Controller Area Network、車内の通信プロトコル)から得られるステアリングやウインカーの情報、IMU(慣性計測装置)やGNSS(衛星測位システム)による位置・加速度情報なども含まれますが、これらのデータ容量は全体の1%以下です。またTuringのデータはカメラ(RGBカメラ)ベースであり、現状ではライダーやレーダーのセンサーデータは含めていないという状態でしたよね。
約束2:On-the-fly GPUデコーディング
安本：以前は、動画から画像を事前にすべて切り出し、学習時はその画像を読み込んでいました。これはモデル学習時の取り扱いが簡単というメリットがある一方、切り出し作業に時間がかかること、動画と画像を二重に保存するためストレージコストが増大すること、さらに動画から画像への変換時にエンコード・デコードを繰り返すことで画質が劣化する可能性がある、というデメリットがありました。
GARUDAでは、NVIDIA GPUに搭載されたハードウェアデコーダーであるNVDEC(NVIDIA Decoder、動画デコードに特化した専用回路)を利用し、学習中に動画をon-the-fly (その場)でデコードする方式に変更しました。これにより画像の事前準備が不要になり、動画をそのまま学習に使えるようになりました。デコードされたデータはGPUメモリ上に直接展開され、そのまま学習に利用できるため、CPU・GPU間でのメモリ転送というボトルネックも回避しています。
山口：一般的な機械学習では、動画を画像に分解して学習しますが、画像として保存するとデータ量が大幅に増えます。GARUDAでは、ストレージコストや転送時間を抑えるため、動画をそのまま学習に利用し、NVDECで学習時にリアルタイムでデコードする方式を採用しています。
安本：一方で、高性能なNVDECをフルに活用する必要があり、GPU1基あたり搭載されているNVDECは7基程度で、複数の動画を並列にデコードし続けるマルチプロセス処理を適切に管理する必要がありました。また前処理やデータ拡張(オーギュメンテーション)もすべてGPU上、つまりCUDA(NVIDIAのGPU向け並列計算プラットフォーム)で実装する必要があり、実装難易度は高いものの、社内のCUDAに強いエンジニアが移植を担当し、最終的に旧方式と同程度の速度を実現しました。
約束3:刷新された開発者体験
安本：以前は、データセット作成にAWS Batch(AWS上でバッチ処理を実行するサービス)とEC2(Amazon Elastic Compute Cloud、AWSの仮想サーバーサービス)インスタンス群を利用していました。本番環境は作り込まれていた一方、開発環境の整備が追いついておらず、MLエンジニアがデータセットに変更を加えたい場合はローカルでデバッグしたうえで本番にマージする必要があり、大規模実行して初めて分かるバグを踏みやすいという課題がありました。
安本：現在はDatabricksが提供するサーバーレスのSpark環境を利用し、事前にサーバーを用意しなくてもデータ量に応じて自動的にスケールするようになりました。これにより開発環境と本番環境がほぼ同一のSpark環境となり、MLエンジニアが少し試して問題なければ、そのまま本番でも同じ環境で実行できるようになったことで、バグを踏みにくくなりました。またPySpark(PythonからApache Sparkを扱うためのAPI)によりSparkやデータベースに詳しくないエンジニアでも扱いやすく、ジョブの実行も数分程度で結果が返るため、開発サイクルの速度も大きく落ちていません。
約束4:圧倒的なストレージコスト効率化
安本：以前は、異なるデータセットが同じシーン(同じ時間帯の走行データ)を参照する場合でも、それぞれのデータセットに画像を重複して保存していました。これは、メタデータと画像データが1つのディレクトリにまとまっているためポータビリティが高いというメリットがある一方、MLエンジニアが試行錯誤のたびに多数のデータセットを作成するため、重複した画像の保存コストが膨大になるという問題がありました。現在は、異なるデータセットが同じシーンを参照する場合でも、動画そのものへのポインタ情報だけを保持し、動画データ自体は重複して持たない方式に変更しました。データ利用時には、そのポインタに紐づく動画を都度ダウンロードする必要がありますが、データ容量やストレージコストの観点では圧倒的に効率的です。この変更により、同じLustreストレージ容量で扱えるシーン数はおよそ10倍に向上したとのことです。また、元の動画ファイルは変更不可(イミュータブル)かつリードオンリーとして扱われ、どのデータセットがどの動画を参照しているかをデータベースで管理しているため、不要な動画を安全に判別・削除できる仕組みになっています。
追加のトピック: AIエージェントとGUI
安本：GARUDAのリリース後の追加の取り組みとして、2点あります。1つ目はAIエージェントの活用です。Turingでは「Devin」と呼ばれるAIエージェントを導入しており、Slack上でDevinに話しかけてタスクを依頼すると、裏側で自動的に処理を実行してくれます。ガルーダの各種APIをDevinから呼び出せるようにしたことで、MLエンジニアは従来のCLIやクエリを自分で書く代わりに、自然言語でデータセットの作成や削除を依頼できるようになりました。
安本：2つ目はGUIダッシュボードの整備です。作成したデータセットがどの車両番号のデータをどれくらいの割合含んでいるか、どのエリア(例えばお台場など)のデータがどれくらいの割合を占めるかといった構成を可視化でき、また複数保有するGPUクラスターのうち、どのクラスターに現在どのデータセットがダウンロードされているかも確認できるようになっています。文字ベースの操作が得意なAIエージェントと、地図表示など視覚的な確認が得意なGUIとで、役割分担が進んでいる状況です。なお、GUI上からデータセットを直接ダウンロードする機能は現時点ではまだ実装されておらず、今後の課題です。
Q&A一覧（一部抜粋）
以降は視聴者のQAに回答していきました。詳しくは動画をご覧ください。
- データはほぼ動画データなのでしょうか？それともカメラ以外のセンサデータなども含まれているのでしょうか？
- nuScenesはLidar x1とRadarx5も含まれると理解していますが、今のご説明ではそれを除いたnuscenes互換のデータと解釈しました。違っていたらご指摘いただければ幸いです。
- 動画の長さによって、NVDECでの処理にかかる時間が変わるのかなと思います。複数の動画を並列に処理するのか、単一動画を複数フレームで並列処理しているのか，どちらの方がいいのでしょうか？
チューリングでは、完全自動運転の技術を共に創る仲間を募集しています。今日お話ししたMLOpsチームはもちろんのこと、機械学習エンジニア、リサーチャー、ソフトウェアエンジニア、組み込みエンジニア、インフラエンジニアなど、非常に幅広いエンジニア職種で仲間を募集しています。ご興味のある方は、ぜひ採用ページをご確認ください。多様な職種がありますので、ご自身がどれに当てはまるか、ぜひチェックしてみてください。
