AVATAR製作時、その超巨大データはどのように大陸間転送されたか？

3D映画として現在大ヒットを飛ばしているAVATAR。私の周りでも凄く話題になっていて、IMAXを持つ映画館に近いうちに見に行きたいと思っています。

本日は、AVATAR製作時に使われたITシステムの話を、ご紹介したいと思います。

34ラックという、驚きの超巨大システム

AVATARのデータ総容量は、何と、3PB(ペタバイト)!もの大きさだったそうです。毎週、ときには日ごとに数TB(テラバイト)ものデータが出来る上に、それらを色々なフォーマットで保存しなければならないためだそうです。

これだけのデータを処理するために、ITシステムのラック総数は何と34本、そして各ラックには32台のサーバが搭載され、プロセッサ総数は40,000、メモリ合計は104TBに達したそうです。しかも、全てのサーバが10GbEで接続されていたとのこと。

とてつもなく巨大なシステムですね。ここまで来ると小規模なスパコンを作るのに近いかもしれません。システムの運用だけでとても苦労したであろうことが容易に想像できます。

データの大陸間転送に苦しむ

そして、更に製作を難しくした点は、3D映像の撮影スタジオ（ロサンゼルス）と画像のCGI レンダリングを行う会社（ニュージーランド）が地理的にかなり離れていたことだったそうです。映像データはロサンゼルスからニュージーランドに逐次送られる必要があり、ここで大変な苦労をしたようです。(上記ITシステムはニュージーランドに建設されたそうです)

製作チームは、当初、データ転送にFTPを使っていたそうです。しかし、FTPの下でトランスポートプロトコルとして使われるTCPは、ターンアラウンドタイムの大きい状況ではネットワークの帯域をうまく使い切れないという弱点を持っています。例えば、パケットロスが発生するとウィンドウサイズが小さくなり、スループットが落ちてしまうなどの問題があります。

そのため、このような大陸間転送のケースでは、FTPはスループットを全然出せなかったようです。しょうがなく、製作チームは物理的なデータ搬送を併用して何とか凌いでいたとのこと。しかし、物理的なデータ搬送はタイムラグなどから使い勝手はよくなく、ベストな解とは言えません。

FASPによるスループットの改善

そのような問題を解決したのが、Aspera社のFASPという製品だったそうです。FASPは、トランスポート層にTCPの代わりにUDPを使い、その上のアプリケーション層でパケットロスを管理する仕組みにしているそうです。TCPとは異なり、パケットロスがある状況下でもウィンドウサイズを大きく保ち、ロストパケットだけをうまく再送するような仕組みになっているそうです。

このケースでは、FTPの15〜30倍のスループットをたたき出したとのこと。

FASPはターンアラウンドタイムが長くてもスループットは落ちないようです。以下はAspera社のサイトから引用させて頂いた画像です(画像ソース)。