【ITニュース解説】From Zero to .glb: Building a Serverless 3D Asset Pipeline in with Rust and Cloudflare

このニュース記事は、わずか48時間という短期間で「Zayry」という3Dモデル変換パイプラインを構築した記録を詳細に説明している。Zayryの目的は、一般的な3Dモデルファイル形式である.objファイルを、ウェブやアプリケーションでの利用に適した軽量な.glbファイル形式に変換することにある。開発者は、サーバーレス技術とエッジコンピューティングを最大限に活用することで、高速かつ低遅延なサービスを実現しようと試みている。この記事は、まだ概念実証段階のシステムでありながら、そのアーキテクチャの選択、技術的な課題、そしてそれらをどのように克服したかという開発の軌跡を公開している点が特徴だ。

Zayryのシステムは、Cloudflareが提供する様々なサーバーレスサービスを全面的に利用して構築されている。サーバーレスとは、開発者がサーバーの構築や運用を意識することなく、アプリケーションのコードに集中できる仕組みのことだ。また、エッジコンピューティングは、ユーザーから地理的に近い場所にあるサーバーで処理を行うことで、データ通信の遅延を最小限に抑える技術である。これらの技術を採用することで、世界中のどこからでも利用できる、非常に応答性の高い3Dアセットパイプラインの実現を目指している。

このシステムのアーキテクチャは、いくつかの重要なコンポーネントで構成されている。まず、システムへの入り口となる「APIインジェスト」の役割を担うのは、TypeScriptで書かれたCloudflare Workerだ。これは、ユーザーからの変換リクエストを受け付け、それが有効なリクエストであるかどうかの検証、認証を行い、次の処理ステップへ進めるためのキュー（待ち行列）に登録する。このWorkerは「エッジ」に配置されるため、ユーザーは地理的な距離に関わらず非常に高速な応答を得られる。次に、「アセットストレージ」としてはCloudflare R2が利用される。R2は、変換前のオリジナルの.objファイルと、変換後の最終的な.glbファイルの両方を保存する場所となる。R2の大きな利点は、保存されたデータを外部へ送信する際の料金（エグレス費用）がかからないことで、世界中にデータを配信するサービスにとって、運用コストを大幅に削減できる重要な要素となる。

「ジョブのデカップリング」にはCloudflare Queuesが採用されている。これは、API Workerが受け付けた3Dモデルの変換依頼を一時的に保持する待ち行列だ。アップロードが急増してシステムへの負荷が高まった場合でも、処理エンジンが処理しきれなくなることなく、全ての変換依頼が確実に処理されるようにする役割がある。これにより、システムの安定性と耐障害性が向上する。そして、「状態管理」にはCloudflare D1というサーバーレスSQLiteデータベースが使われている。D1は、アップロードされた各3Dアセットがパイプラインのどの段階にあるか（例：アップロード済み、変換中、完了）といったステータス情報を追跡し、管理するために利用される。

このシステムの心臓部とも言えるのが「コアエンジン」だ。これは、高性能なシステムプログラミング言語であるRustで開発された3D処理エンジンであり、WebAssembly（WASM）という形式にコンパイルされて、別のCloudflare Worker内で実行される。WASMは、Webブラウザ上でJavaScriptよりも高速に動作するバイナリ形式として知られているが、Cloudflare Worker環境ではサーバーサイドでその高性能を発揮する。これにより、サーバーレスという環境でありながら、ほぼネイティブアプリケーションに近い処理速度で、複雑な3Dモデルの変換処理を行うことが可能になる。

システム全体のデータフローはシンプルながらも強力だ。まず、ユーザーがAPI Workerを通じて.objファイルをアップロードすると、そのファイルはCloudflare R2に保存される。この時点で、ファイルは変換される前の「ソース」アセットとして扱われる。次に、変換リクエストがCloudflare Queuesに登録され、処理の順番を待つ。キューに登録されたリクエストは、WASM化されたRustエンジンを内蔵した「プロセッサーWorker」によって取り出され、実際の.objから.glbへの変換処理が実行される。変換が完了すると、新しく生成された.glbファイルは再度Cloudflare R2に保存される（この時点では「処理済み」アセットとなる）。最後に、Cloudflare D1データベースが更新され、このアセットの処理ステータスが「完了」と記録される。

開発プロセスでは、まずモノレポと呼ばれる複数のプロジェクトを一つのリポジトリで管理する構成が作られ、API WorkerとプロセッサーWorkerの基本的な骨格がTypeScriptで構築された。その後、API Workerにおけるユーザー認証やリクエストの検証機能が実装された。最初の大きな達成は、仮の処理を挟む形で、ファイルのアップロードからR2への保存、キューへの登録、プロセッサーによる取り出し、そしてD1へのステータス更新という一連のデータフローが正しく機能することを確認した点だった。これにより、システムの各コンポーネント間の連携（いわゆる「配管」）が正しく接続されたことが証明された。

次に、この仮の処理部分を、Rustで書かれた本物の3D処理エンジンに置き換える作業が行われた。Rustが選ばれたのは、その高いパフォーマンスと安全性、そしてWebAssembly（WASM）への優れた対応が理由である。変換エンジンの開発は主に二つのステップに分けられた。一つは「入力の解析」で、.objファイルからモデルの頂点、法線、面といった形状データを読み取るために「tobj」というRustのライブラリ（クレートと呼ばれる）が使われた。もう一つは「出力の合成」で、これは最も技術的に挑戦的な部分だったが、「gltf」という別のクレートを利用して.glbファイルを生成した。このプロセスには、.objデータから必要な情報を抽出し、glTFという形式が要求する構造に精密にマッピングする作業が含まれる。具体的には、メッシュデータを一つのバイナリバッファにまとめ、glTFがそのバイナリデータをどのように解釈すべきかを指示する「ビュー」や「アクセサー」を作成し、これら全てを有効なglTFシーン構造として組み立て、最終的にJSON構造とバイナリバッファを組み合わせて.glb形式としてシリアル化するという複雑な手順を踏む。

Rustで実装された変換関数は、「wasm-pack」というツールを使って軽量なWASMモジュールにコンパイルされた。その後、このWASMモジュールがプロセッサーWorkerに組み込まれ、わずか一行のTypeScriptコードでRustの高性能な関数を呼び出すことが可能になった。初めて.objファイルをアップロードし、意図通りに有効な.glbファイルが処理済みのR2バケットに現れた瞬間は、開発者にとって大きな技術的ブレイクスルーであったという。

今後のZayryの開発では、より複雑な3Dモデルファイル形式である.fbxのサポート、3Dモデルに質感や見た目を与えるマテリアルやテクスチャの処理、遠くから見たときにモデルの細かさを自動的に調整するLOD（Level of Detail）生成機能の実装、そしてより堅牢なエラーハンドリング機能の追加などが計画されている。現状はまだプロトタイプ段階だが、最も困難な技術的課題は既に解決されており、実用的なエンジンの基盤はしっかりと確立されたと言える。

この事例は、最新のクラウド技術、特にサーバーレスとエッジコンピューティング、そして高性能言語であるRustとWebAssemblyの組み合わせが、いかに迅速に複雑な問題を解決するシステムを構築できるかを示す素晴らしい例である。システムエンジニアを目指す初心者にとって、アーキテクチャ設計、技術選定の理由、具体的な実装手法、そして開発における課題解決の過程を理解する上で非常に参考になるだろう。