harvester - python workshop 2010/12

CG映像制作用ジョブディスパッチシステム

マーザ・アニメーションプラネット株式会社２０１０.１２.０８

Harvester

R&Dセクション・マネージャ　　　　　齊藤　淳R&Dセクション・CGエンジニア　　　　　石川　雄介@yusukei

© MARZA ANIMATION PLANET INC.

会社案内

「最高の物語を、世界中のこどもたちへ」

グローバルに通用する、フルCGアニメーションを用いたエンタテインメントを供給

2006年4月: 株式会社セガ VE研究開発部として発足

2009年6月: 株式会社セガより分社、セガサミービジュアル・エンタテインメント株式会社となる

2010年7月: 社名変更により　マーザ・アニメーションプラネット株式会社となる


Python活用事例

・CG業界ではPythonが結構使われている！

・例えば、Maya, Houdini, Cinema4D, Blender, Nukeなど　多数のアプリケーションに組み込まれている

・社内の開発でもPythonが多く使われている　Pythonが組み込まれていないソフトウェアに対して、独自に組み込みも行う

0

50

100

出典）Marzaリポジトリ

C++ Python MELJavaScript Ruby Perl


映像制作にはたくさんのマシンリソースが必要

・映像を制作するには多くのCPUリソースが必要

・先ほどの映像、1:30バージョンと3:30バージョンを作るのには　70764040 sec (=820日)処理時間がかかっている

・これを１数台のPCで処理を行っていたら終わらないので、サーバを使って　分散処理を行っている


現在はブレードサーバで約140台(1300+ cores)

ストレージは100TB程度

03256509751300

2008 2009 2010

レンダリング用のサーバ群＝レンダーファーム


サーバを必要とする作業は多い

・サーバを必要とする作業はレンダリングだけじゃない！　シミュレーション、エンコード、ベイクといった作業でも多くの　CPUパワーが必要となる

・これらの作業をサーバで行うことにより、アーティストの作業停止時間減少

作業能率向上作品全体のクオリティアップ!!!


このサーバ群を管理するのがディスパッチャ

・人の手で管理するとサーバが取り合いになってしまう

・夜間のレンダリングなど空くまで待たなければいけない！

・なので人の手で管理を行うのは無理！！

・だからソフトウェアで管理する

・キューのスケジューリングを行うものがディスパッチャ


Harvesterのこれまで！

・最初のバージョンは開発してみたものの、サーバプログラムの　経験もなく作ったため、ボロボロだった。　cronで定期的に再起動をかけたり、DBの内容に　不整合がないかチェックをかけていたりした。

・バージョン２ではv1を元に再度作り直した。　基本的な部分はここでほとんど固まった。　このバージョンから落ちることはほとんどなくなった

・バージョン３はアーキテクチャをPush型からPull型に　変更を行って再設計を行う。　


Pythonのモジュールはこんなのを使っている

Python2.6ベース、ターゲットは、ManagerはLinux、workerはWindows

ほとんど標準モジュールで作っている

それ以外には、・SQLAlchemy・MySQLdb・pywin32・memcached・paste・zope.pagetemplate・wxPythonなどを使っている


Harvesterの特徴（１）

・サーバをグループに分ける際に、マシン固定ではなく割合として設定

・これによりサーバのメンテナンス、追加、削除に対して再設定が必要がない

・新しいプロジェクトが追加された際も設定が容易　新しいプロジェクトに対して割合を設定するだけで、既存の設定に変更は必要ない


Modeling Effect LookDev Lighting

自グループのサーバを使い切っても、他グループのサーバを使ってくれない!!

!

今までのディスパッチの問題

・グループごとに台数が決まっており、どこかのグループのサーバが　空いていても使われないため、リソースを最大限に活用できない！


Lighting 40%

Effect 30%

使用中使用中未使用使用中

ModelingTeamの割り当て分を、 LightingTeamのジョブの処理にまわすことが可能!!!

Modeling 20%

使用中

LookDev 10%

Harvesterでの解決策

・全体の台数からの割合で決定を行う　空きサーバはどんどん使い、混み始めると決められた割合に調整される


Harvesterの特徴（2）

・タグを割り振ることにより特定のノード群のみで実行されるように可能


Harvesterの特徴（３）

・ジョブテンプレートによりフレームごとに行う処理を簡易的に記述できる

・新しいアプリケーションに対応させる際に簡単に追加が可能


WebによるGUIとデスクトップの連携（１）

GUIはExtJSで構築

HTMLを採用することで、アーティストがクライアントアプリケーションを　インストールすることなく使用可能

クロスプラットフォームで閲覧可能


WebによるGUIとデスクトップの連携（２）

右クリックメニューから出力先ディレクトリを開くことが可能

アーティストのワークステーションにもサーバを立てて、Managerと通信

一度サーバ側が受けたリクエストをmod_proxyでアーティストのワークステーションへとリクエストをproxyしている


JSONベースのAPI

WSGIを使ってZopeのScriptPythonに似た仕組みを用意し、APIとして公開マネージャとレンダーファームとの間の通信にはJSONを使用

JSONを採用した理由としては、・ベースがHTTPなので安定している・流れるデータがイメージしやすいため、デバッグがしやすい・ブラウザを使ったデバッグが可能　（Firebugなどを使ってデバッグができる！）・GUIがライブラリのExtJSと親和性が高いなどが挙げられる

欠点としてはHTTPはstatelessなので複数のリクエスト間でのトランザクションの様なことがしにくい


WSGIのミドルウェアを活用したAPIとドキュメント

・APIのドキュメントをWebから見られるような仕組みを用意

・Web上からAPIドキュメントの確認、パラメータを指定して、　テスト呼び出しができるような仕組みを開発


運用

・サーバがハングアップした際にはGUI上から強制的に再起動が可能

・Zabbixと連動させ、消費電力や稼働率のデータを可視化


苦労話

・レンダラーがメモリを使い果たし、メモリが確保できなくて通信しようとし　てエラーになってしまうようなことが起きた

　メモリを事前に確保し、アロケーションが起きないようにすればいいのか　もしれないが、インタプリタがいつアロケーションするか分からないので、　対処のしようがない

・バージョンが上がるごとに機能が膨らみ、SQLクエリが重くなっている　−＞SQLを使わないことも検討する必要があるか？


苦労話

・GUI用のデータをJSONで提供しているが、10000フレーム分のジョブがあっ　たりとデータサイズも大きくなってきた

　また、今後ワークステーション、レンダーファームが増えると通信量が増　え、ボトルネックになる可能性もあり得る

・そこでApacheのdeflateを使用し通信量を削減してみた

・結果、通信量が700kb/s -> 20kb/s程度に圧縮

・フレーム間のデータは非常に似通ったデータが多いため、圧縮が効きやすい


苦労話

・WindowsではWMIを使っているが、イマイチ安定性に欠けている　データを取得しようとするとエラーを返すことがある

・time.sleepを使うと、稀にinterrupt call backが発生する　原因が分からず、現状Win32 APIを直接呼ぶことで回避している

・最近コア数が増えてきてますが、3dsMaxの古いバージョンなどでは16コア　より多い環境だとアプリケーションが立ち上がらないという問題がる

　処理の内容によってはコア数が増えてもロックの関係からパフォーマンスが　落ちるものもある

　今後、コア数が増えるとこういったトラブルも増えそうである


今後のお話とか

・Ver.1, 2ではManagerがWorkerにジョブを送信するPush型のアーキテクチャ　Ver.3ではPull型のアーキテクチャへ変更。どちらの機能も必要

・Pull型にもPush型にもどちらにも利点があるので、ハイブリッド型の　アーキテクチャを検討する必要がある

・タスクを処理する際に割り当てるスレッド数を指定しているのだが、　フラグメントを起こしてしまい、小さいスレッドを指定したタスク　ばかり走ってしまう

・電力管理を行えるようにし、電力コストを下げる

ご静聴ありがとうございました

harvester - python workshop 2010/12

Documents