みなさんこんにちは。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番目の構成をベースに、必要に応じて拡張する方法を採っていきます。
[[SplitPage]]仮想環境上で、ネットワークを構築
潤沢なスペースと空きマシンがあるなら実際の環境をつくることもできますが、なかなかそうもいかないので、仮想環境上で前述のネットワークを構築します。仮想環境のホストはLinuxを使用し、KVM上に作成します。
Linux上での仮想環境の構築についての詳細は、オンラインや書籍で多くの情報が提供されているため省略します。ここでは下記を行います。
・virt-managerを使用して、仮想環境内だけで接続できるネットワーク（private）を構築する
・計算サーバはprivateだけに接続させる
・セントラルマネージャはprivateと作業ネットワークの両方に接続させる
環境構築はコマンドラインやXMLファイルを直接編集して行うこともできますが、今回はお手軽にvirt-managerを使用します。
まずはネットワークの作成を行います。
virt-manager上で、［Edit］→［Connection Details］を選びます。
左下の［+］ボタンを押して表示されたダイアログで［Network Name］を入力し、［Forward］ボタンを押します。
ネットワーク設定を聞かれます。必要であれば適切な値を設定します。今回の場合、ここの設定はそのままでいいので［Forward］ボタンを押します。次にIPv6の設定を行うか聞かれますが、これもチェックを外したまま［Forward］ボタンを押します。
ホストマシンが接続しているネットワークに接続するかどうか聞かれるので、［Isolated virtual network］を選びます。これで外とはつながっていない、仮想環境だけで閉じたネットワークが作成できます。
以上でローカルネットワークが作成できました。
続いて、計算サーバとセントラルマネージャを接続していきます。計算サーバとセントラルマネージャの仮想マシンは既に用意してあるものとします。
計算サーバは先ほど作成したprivateのみに接続すればいいため、［NIC］の［Network source］を private にします。
セントラルマネージャはprivateとホストが接続しているネットワークの両方に接続する必要があるため、NICを2つ用意します。最初のNICはBridgeネットワークに接続します。
※ Bridgeネットワークはホストマシン側の設定で作成しなければいけないのですが、ここで解説するには手順がちょっと煩雑なのと、オンラインでドキュメントが豊富にあるので割愛します。すみません.........
続いて、NICをもうひとつ作成します。［Add Hardware］ボタンを押し、［Network］を選んで ［Network source］にprivateを選びます。その後［OK］を押します。
これでネットワークの作成ができました。2つの仮想マシンを立ち上げて接続テストをします。少しわかりづらいですが、左上から時計回りに計算サーバ、セントラルマネージャ、それから実際の作業とジョブの投入に使用するマシンになります。
計算サーバはセントラルマネージャのみと通信でき、セントラルマネージャは計算サーバと作業用マシンの両方と通信できていることがわかります。
HTCondorの立ち上げ
セントラルマネージャと計算サーバでHTCondorを立ち上げます。このあたりの設定は過去の記事を参考にしてください。
無事に環境構築ができ、セントラルマネージャに情報が登録されました。今回は作業用マシンでもジョブを実行可能な設定にしてあるため、計算サーバと作業用マシンの情報が表示されています。
次回予告
駆け足でしたが、基本の環境をつくることができました。次回からこの環境を基にクラウド化のお話を進めていきます。
第15回の公開は、2019年8月を予定しております。
プロフィール
