>   >  痴山紘史の日本CG見聞録:第14回:クラウド環境構築[ネットワーク構成の設計]
第14回:クラウド環境構築[ネットワーク構成の設計]

第14回:クラウド環境構築[ネットワーク構成の設計]

みなさんこんにちは。7/7にAMDから新しいRyzenシリーズが発売されました。注目度 No.1のRyzen 9 3900Xが日本円で税込6万4,584円ということで、それほど無茶な価格設定ではなかったこともあり、販売当日は大盛況だったようです(ニュースによると秋葉原に800人以上集まったとか?)。解禁されたベンチマークも驚異の結果で、ここ十年で最大のPCリプレースタイミングでしょう!!という感じです。私は残念ながら当日購入はできなかったので、これからジックリとパーツリストと睨めっこしていきます............なんて言っていると後続の3950Xが発売されてしまうんですよね。

TEXT_痴山紘史 / Hiroshi Chiyama(日本CGサービス
EDIT_尾形美幸 / Miyuki Ogata(CGWORLD)

パフォーマンスを見積もる

クラウドや外部のネットワークを使用する際に見落としがちなのが、データの転送時間です。最近のネットワークや計算機はとても速く、ローカル環境で作業をするのであれば、多少の不満はあっても最終的には力業でゴリ押しすれば何とかなるケースが多いです。

その感覚のまま外部のネットワーク上にあるサービスを使用すると、思わぬところでつまづくことになります。そうならないように、事前にある程度の見積もりをしておくことが大事です。

例えば、会社のインターネット接続に1GbpsのFlets 光を契約しているとします。社内LANも1Gbpsで構築しているから、社内環境と同じくらいの感覚で外部とも接続できるのではないかと考えてしまいそうです。

本当にそうでしょうか?ざっくりと計算してみましょう。

まず、Flets 光が実際にどれくらいの速度が出ているのか調べます。

Googleさんに尋ねてみたところ、上り(アップロード)も下り(ダウンロード)も100Mbps~200Mbpsくらいの速度が出るようです。この時点で1Gbpsという謳い文句の1/5~1/10ですね。今回は真ん中を取って、150Mbpsの転送速度が出ているとして計算してみましょう。

※ ちなみに私の環境では、上りが137.6Mbps、下りが134.6Mbpsでした。まあまあボチボチという感じでしょうか。

150Mbpsは、1秒間に150メガビット(18.75メガバイト)のデータを転送できるということです。つまり、1GBのファイルなら53秒(約1分)の転送時間がかかることになります。1TBなら1.5時間、10TBなら15時間ということです。一度だけ転送するなら待てなくはないけれども、レンダリングジョブを投げるたびにこれだけ待つことはできないなぁと私なら考えます。

また、社内で1人がYouTube動画を観ていた場合、当然ながらこの回線の帯域を消費します。YouTube ヘルプによると、フルHD動画で大体10〜20Mbpsとのことなので、これだけで全体の1割を消費します。

さらに、最近よく聞く運用として、チェック動画やリファレンス動画をクラウドにアップロードしてみんなでそれを閲覧するケースがあります。この場合も、閲覧のために1人あたり数Mbpsの帯域を消費することになります。

このように、クラウド環境との通信以外の通信が多く発生すると、すぐに数分の一程度の転送速度しか出なくなってしまいます。実際には上りと下りで転送速度がちがったり、いろいろ条件があったりするので見積もりは難しいですが、最低でもこれくらいの時間はかかりそうという目安をつけることはとても大事です。

インフラを専門でやっている人なら今更何言ってんの??という話ではあるのですが、特に「現場からの要望」で構築されたシステムの場合、ここがマルっと抜けていて後から大変な目を見ることが本当に多いのです.........(遠い目

ネットワーク構成の設計

続いて、クラウドシステムを活用した運用をするためのネットワーク構成の設計を行います。今回は既存のインフラはなく、イチから環境を構築でき、かつ、当初はそれほどパフォーマンスが出なくても徐々に改良していけるという、現実にはあり得ないような理想的な状態から始めます。

多くの現場では、アーティストが作業に使用するPCとファイルサーバ、レンダーファームの計算機は同じネットワーク上にあり、アーティストがファイルサーバに保存したファイルを使用して、レンダーファームでレンダリングを行なっていると思います。

これを図にしてみます。黒いラインがネットワーク、赤いラインがデータのながれです。


これは構成がシンプルなため、ファイルサーバにファイルを置いてレンダリングジョブを投げると、そのまま処理できるという手軽さがあります。反面、レンダリングの負荷が高くなり、レンダーサーバからファイルサーバへのアクセスが増えると、ネットワークやファイルサーバの負荷も高くなり、アーティストの作業環境にも影響をおよぼす可能性があります。午前中は快適なのに、夕方になるにつれネットワークが重くなり、作業に支障をきたすといった経験がある方も多いのではないでしょうか。そのような場合、もしかしたらこういうことが影響しているのかもしれません。

もうひとつ、別の構成を考えてみます。


こちらはレンダーファームとアーティスト環境を完全に分離したケースです。レンダリングジョブはセントラルマネージャ経由でレンダーファームに送られ、同時に必要なファイルもレンダーファームのファイルサーバへ転送されます。

この構成のメリットは、レンダーファーム(ないしはアーティスト環境)で起きたトラブルが、相手の環境に影響をおよぼさないことです。また、この構成であれば、社内にレンダーファームがあろうと、クラウド上にレンダーファームがあろうと、同じような使い勝手で使用することができます。

反面、レンダリング時には必要なファイルを収集してレンダーファーム側に転送したり、レンダリングされた結果をレンダーファームから転送する処理を行う必要があります。

さらに、もうひとつ考えてみます。


これはレンダーファーム側にファイルサーバが存在せず、計算サーバが個別にストレージをもっている構成です。

この構成のメリットは、「向こう側」を圧倒的にシンプルにできることです。また、ファイルサーバやネットワークがボトルネックになるおそれがなくなります。

反面、プロジェクトで共有するアセットやキャッシュデータも各計算サーバに配るのか?という問題が出てきます。また、計算サーバのストレージも、ある程度の容量を確保しておく必要があります。

このように、ネットワーク構成は様々な形を考えることができ、それぞれにメリットとデメリットがあります。本連載では3番目の構成をベースに、必要に応じて拡張する方法を採っていきます。

次ページ:
仮想環境上で、ネットワークを構築

その他の連載