みなさんこんにちは。年に2回更新される、世界のスーパーコンピュータの性能ランキング Top500が発表されました。
※ Top500は、昔 「一位じゃないとだめなんですか？」で話題になったスーパーコンピュータのランキングです。
日本では国立研究開発法人 産業技術総合研究所（産総研）のAI Bridging Cloud Infrastructure（ABCI）が7位、最先端共同HPC基盤施設のOakforest-PACSが14位、国立研究開発法人 理化学研究所（理研）の京が18位などなどとなっています。あれだけ世間を沸かせた京が今となっては18位なのかと思うと計算機の進歩の速さに改めて驚かされます。
TEXT＿痴山紘史 / Hiroshi Chiyama（日本CGサービス）
EDIT＿尾形美幸 / Miyuki Ogata（CGWORLD）
新章突入
前回まではクライアント側での環境構築とレンダリングまでのながれをつくることに注目してお話を進めました。CG映像制作を行う場合、これと同じかそれ以上に大きな要素となるのがレンダーファームをはじめとしたサーバ側の計算機環境です。今回からは、サーバ側の技術に注目してお話を進めていきます。
プロダクションでサーバ側に行わせる仕事と言えばレンダリングが最も一般的でしょう。むしろ、それ以外となると意外と活用されていなかったりします。でも、レンダーファームとして用意されているものも、われわれが普段使用しているPCと同じハードウェア、OSが動いてて、同じプログラムが動くのです。ということは、普段手元のPCで行なっている処理でバッチ処理が可能なものの多くはサーバ側で処理できると考えるのが自然です。
先日行われたCGWORLD 2018 クリエイティブカンファレンスでも、アニマが「アニメ「モンスターストライク」の品質と物量を支えた、mGearを使ったアニメーションワークフロー」の中でサーバを使って各種自動化を行なっているという発表をされていました。ここではアセットのリギングやショットシーンのビルドといった処理をサーバ側で行う、素晴らしいしくみを垣間見ることができました。これは映像制作に直結するとても良い事例です。
ほかにも工夫次第で様々なことができます。例えば、アプリケーションのインストールをジョブとして投入することがあります。サーバが百台あった場合、一台一台手動でインストール作業を行うのはとても大変ですが、サーバ上で処理可能なジョブとして全マシンに投入すれば、ワンクリックで全マシンにインストールを行うことができます。このようなしくみがあるとないとで天と地ほどの差が生まれます。
サーバ側で処理をする環境がないと自分の作業マシンで重たい処理を走らせることしかできず、その間の30分とか1時間、手持無沙汰でとりあえず漫画でも見るか......となってしまいますが、これはとても勿体ないことです。上手くしくみをつくってサーバにがんばってもらうようにすれば格段に作業の密度を上げることができます。
世界の大型計算機
まず、世界中でどのような環境が構築・運用されているのか見てみます。私もいわゆるスーパーコンピュータは使用したことがないので、今回、記事を書くにあたっていろいろ調べてみました。万全を期して書いているつもりですが、間違っていたり抜けている部分があったらご指摘いただけると嬉しいです。
たくさんの計算機を並べて膨大な計算を行わせるというのはCGのレンダリングだけに限らず、多くの分野で行われています。前述の京も規模こそ桁ちがいですが、たくさんのCPUを並列して計算させるという意味では同じで、各種分野の最先端の研究に使用されています。京でどのような研究が行われているか紹介されているページもあるので興味のある方はご覧になってみてください。
どれくらいスーパーコンピュータがすごいのか比較するのに何かいい例はないかなと思って調べたところ、Top500で使用しているベンチマークソフトをMac book proで走らせている人がいました。この記事によると京と比べると、約28万倍くらいの性能差があるようです。興味本位で自分のPC（Dynabook R73, Corei7-4710MQ/Windows）でも試してみたところ75GFlops程度だったので京と比べて14万倍の差です。
ちなみに「そんなにすごい計算機があるなら、私もレンダリングとかシミュレーションに使いたい！！」と思うかもしれませんが、残念ながらわれわれが普段使用しているMayaやArnoldといったソフトウェアは動作させることができません。われわれが普段使っているPCにはIntel（もしくはその互換チップ）のCPUが載っていますが、京ではそれとは異なるしくみで動いているCPUが採用されているからです。ただ、世界にはIntelのCPUを使用したスーパーコンピュータも多数あります。
※ 例えば東京工業大学のTSUBAME3.0（正確にはNVIDIAのGPUがメインですが）や、Top500で4位となっているTianhe-2Aがあります。
そのため、これらはまったく別世界のお話というわけでもないです。そして、京やTSUBAMEも含めて最近のスーパーコンピュータの多くはLinuxで動いているため、手元にあるLinuxマシンでもスーパーコンピュータでも動作するソフトウェアというのがたくさん存在します。
※ ここでおや？と思った方は鋭いです。CPUアーキテクチャやOSが異なっていても動作するソフトウェアをつくることは可能なのです。ただ、そのためには膨大な労力を要するので対応するか否かは開発者の判断次第です。MayaやArnoldも、WindowsだけではなくLinuxやMac OSXで動きますよね。あれは開発者がものっっっっすごいがんばって対応しているのです。Maya（Alias）なんかは、昔は今とまったく異なるOS、CPUの環境で動いていましたしね。
ひるがえってCG界隈の計算機（レンダーファーム）はどうでしょうか。
Weta DigitalはTop500に情報が載っています。
Wetaは2015年に実効性能470.6TFlops/sで187位でした。当時首位のTianhe-2Aの33,862.7TFlops/sと比較すると72倍のちがいがあることになります。Wetaはその後も2017年秋までは順位を下げつつもTop500に載っています。それから、Industrial Light & Magic（ILM）も掲載はされていますが情報がかなり古いです。ほかのプロダクションは私が探した範囲では見つけることができませんでした。
もちろん映像制作に使われる機材と研究・開発用途で使われる機材とでは、得意・不得意がちがうので一概に言うことはできないですが、これらの数字を見比べてみると何となく全体的な立ち位置はわかるかと思います。
[[SplitPage]]制御に使用されているソフトウェア
たくさんの計算機を並べて膨大な計算を行わせるためには、それを制御するためのソフトウェアが必要になります。これはスケジューラやキューイングシステム、ジョブ管理システムなどと呼ばれ、商用のものからオープンソースのものまで多数存在します。これだけ聞くと難しそうですが、われわれがレンダーサーバで使用しているBackburnerや Deadline、Qube!などもこの仲間です。
京では富士通が開発したParallelnaviが使用されています。また、TSUBAME3.0ではUNIVA Grid Engineを採用しています。そのほかTorque（PBS）、NQS、LFSといったソフトウェアが広く使われているようです。
CG界隈ではどうでしょうか。Weta Digitalでは以前はAlfredを使用していたものの、Plowを独自に開発して現在はそちらを使用しています。ILMはこれまた自社開発のObaQを使用しています（していた？ 最近の情報が見つからないので詳細は不明です）。ObaQ はアカデミー賞も受賞しています。また、こちらのページに動作中の画面などが映っています。ちなみにObaQの名前の由来は日本の漫画の主人公だそうです。そういえば何だか聞いたことあるような名前ですね。オバ...... :-) Pixar Animation Studiosも独自開発でTractorを使用・販売しています。
そのほかのプロダクションも独自開発するか、Deadline、Qube! といったシステムを使用しており、スーパーコンピュータで使用されているものを選択している例はとても少ないです。これはちょっと面白い傾向ですね。私の印象では、ユーザー層のちがいからスケジューラの本体の機能よりも、GUIを含めたトータルのパッケージに注力しているのかなという気がします。
今回使用するソフトウェア
全体の概略が見えてきたところで、手元に環境をつくっていきます。今回使用するのはHTCondorという、アメリカのウィスコンシン大学で30年（！！）にわたって開発が行われ、今もアクティブな活動が続けられているソフトウェアです。
前述のTorque（PBS）、NQS、LFSに比べてシェアは高くないようですが、いくつかの点で非常に魅力的です。
・Windows版も公式サポートしており、インストーラを使って簡単に導入できる
・クライアントPCの空き時間にジョブを実行することが最初から想定されている
・長期に渡って開発されており、近日中にプロダクトがなくなる心配が少ない
・オープンソースソフトウェアであり、無料で使用できる
・少ないながらもMayaなどを動作させた実績がある
全ての環境をLinuxに移行しているプロダクションには特にメリットにはならないですが、映像制作をしているとどうしてもWindowsがないとできない作業というのが存在します。処理の自動化をする場合でもそこに対応できないと困ってしまうので、公式にWindowsがサポートされているのはとても助かります。また、インストーラを使って手軽に環境構築できるのもありがたいです。加えて、クライアントPCの空き時間にジョブを実行するのはプロダクションではよく行われているので、この機能が標準で存在するのは嬉しいです。Mayaを動かした実績も"Rendering Maya Projects With Condor"としてドキュメント化されています（大分古いですが）。実際のところ、ここで書かれているような専用のツールを用意しなくてもMayaのジョブを実行することは可能です。
反面、デメリットとしては標準のモニタリング用GUIが存在しません。標準では全てコマンドラインからの操作になるので、コマンドラインインターフェイスに慣れていない初心者の方にとってはちょっとハードルが高いです。
※ とは言っても世間的に見れば、われわれが普段触れているファンシーでゴテゴテしたGUIツールが山ほど揃った環境の方が特殊ではあるのですが。
ただ、探せばHTCondor用のGUIインターフェイスを作成している方もいます。例えばCondor GUIはWindows版の実行ファイルも用意されており、ダウンロードして実行するだけで使用できます。管理者向けの環境もElasticsearchやGrafanaといった一般的に使用されているツールを使って構築する事例が紹介されていたりします。
次回予告
次回からは、実際にHTCondorの環境構築を行い、レンダリングやそのほかサーバ上で可能な処理を実行できるようにしていきます。これらのジョブの実行はHTCondorに限らずBackburnerやDeadlineといったソフトウェアでも同様のことができるので、上手く応用することで手元にある環境の改善につながるヒントを見つけられるでしょう。
第8回の公開は、2019年1月上旬を予定しております。
プロフィール
