みなさんこんにちは。先日開催されたCGWORLD 2019 クリエイティブカンファレンスにて、「ウォーターフォール型パイプラインの問題点と、コンカレント型パイプラインの将来性」と題したセッションを実施し、本連載に関係する内容のお話をさせていただきました。おかげさまで満員御礼で、セッションの内容についても良い反応をいただけたようでホッと一安心しました。来場いただいた方はありがとうございました。
本セッションの資料はこちらで公開しているので、興味のある方はご覧になってください。また、セッション中にお見せしたGafferの操作ムービーも公開しています。映像だけでコメントなどは一切入っておらず、わかりづらくて申し訳ないのですが、Gafferがどのようなソフトウェアなのか雰囲気は伝わると思います。
TEXT＿痴山紘史 / Hiroshi Chiyama（日本CGサービス）
EDIT＿尾形美幸 / Miyuki Ogata（CGWORLD）
クラウド環境上のネットワーク構築
前回までで、HTCondor Annexのcondor_annexと、自分がカスタマイズしたイメージを使用して、AWS上にインスタンスを立ち上げることができるようになりました。計算サーバを単独で動かすだけなら今の環境でも十分ジョブの投入・実行ができますが、このままではジョブを実行するたびに、ローカル環境からクラウド環境に必要なファイルを全て転送してから計算を行う必要があります。
さらにインスタンス間ではデータ共有ができないため、同じシーンを複数のインスタンスで計算するような場合でも、全てのインスタンスに対して全てのデータを転送する必要があります。これはとても効率がよくないです。
そこで、クラウド環境上にもネットワークを構築し、そこにファイルサーバを置いて全てのインスタンスからファイルサーバ上にあるファイルにアクセスできるようにします。プロジェクトを通して共有されるようなアセットは事前にファイルサーバ上にアップロードしておくことで、データの転送時間や転送量、ディスクの使用量を軽減することができます。
AWS上でのネットワーク構築
AWSでは、ネットワークを構築をするための機能としてAmazon Virtual Private Cloud（VPC）があります。VPCを使うと驚くほど簡単に必要なネットワークを構築することができます。また、condor_annexを使用して作成したインスタンスは、AWS標準で作成されているデフォルトVPCに接続されています。
そのため、このネットワーク上にファイルサーバを構築すればアセットを共有することができます。
といわけで、最低限のネットワークは勝手につくられるので、われわれは何もしなくていいということになります。
注意点として、AWS上でVPCは複数作成することができるのですが、condor_annexを使用した場合はデフォルトVPCしか使用することができません。これは気を付けてください。
AWSが提供するクラウドストレージ
続いて、 AWS上にファイルサーバを構築します（結果的には"サーバ"ではないのですが）。AWSが提供するクラウドストレージに使用可能なストレージの種類がまとまっているので、これを元にどのような構成にするか検討します。
ざっくりと内容を見ていきましょう。
Amazon Elastic Block Store（EBS）
「EBSは、単一のEC2インスタンスからアクセスする永続的ストレージが必要なワークロード向けに設計されています」ということなので、PCに接続しているHDD（SDD）と似たようなイメージで使用することができます。反面、ネットワーク上の共有ファイルシステムとして使用する場合は、それ用のしくみを自分で構築する必要があります。
Amazon Elastic File System（EFS）
「何千ものAmazon EC2インスタンスに対して大規模な並列共有アクセスを提供するように設計されており、アプリケーションが一貫した低レイテンシーで高レベルの集約スループットとIOPSを実現できるようにします」。 ほうほう。これは何だか今回の用途に向きそうですね。
Amazon S3（S3）
「S3は、バックアップと復旧、階層化されたアーカイブ、ユーザー主導コンテンツ（写真、動画、音楽、ファイルなど）、ビッグデータ分析やデータウェアハウスプラットフォームのためのデータレイク、またはサーバレスコンピューティング設計の基盤として使用されます」。大量のデータを安全に保存できるようです。もしかしたら目的にマッチするかもしれません。
Amazon FSx for Lustre（FSx）
「Amazon FSxの使用により、毎秒最大数百ギガバイトのスループット、百万単位のIOPS、およびミリ秒未満のレイテンシーで大量のデータセットを処理できるLustreファイルシステムを起動し、実行することが可能になります」。ものすごく速いようです。大量のサーバから一気にアクセスするような今回の例にとてもマッチしそうです。とりあえずLustre使ってみたいですよね～（よね？
Amazon FSx for Windows ファイルサーバー
FSxのWindows版のようです。FSxがあるのでそちらでよさそうです。
Amazon S3 Glacier と S3 Glacier Deep Archive
「データのアーカイブや長期バックアップに使用できます」。バックアップ用途なので今回の目的には合わなさそうです。
AWS Backup
バックアップ用途なので今回の目的には合わなさそうです。
AWS Storage Gateway、データ転送サービス
データの保存場所ではなく、転送を支援するためのシステムのようです。
どのような種類のストレージがあるのかはわかりました。これだけだと具体的に何がどのようなケースに向いているのかイメージがわきづらいです。そこで、もうひとつ別の資料を見てみます。こちらでは、AWSで使用できるストレージをそれぞれどのように使い分けるかが詳細に解説されています。
こちらを穴が開くほど眺めながら、自分の環境と照らし合わせて最適なストレージタイプを選ぶのがよさそうです。資料の詳細は各自見ていただくとして、典型的なケースでの技術の採択例が表になっています。
※ AWS ストレージサービスの特性理解と選択指針より引用
これらの資料をざっくりと見た感じ、EFS、S3、FSxあたりが候補に挙がってきそうです。その中で、今回はS3を使用してみます。
S3を使用する理由は以下の通りです。
・安価
・ローカル→クラウドへの手軽なデータ転送手段がある
・多くの計算機からアクセスしたときにも問題が少なそう
なお、S3を使用する際の不安点としては、以下のようなものがあります。
・アクセスに対しても課金されるので、コスト感がわかりづらい
・十分な速度が出るのかわからない
このあたりは環境や条件によって異なるので、本番環境を構築する際にはきちんと検証を行なっておく必要があります。多少金額が高くてもパフォーマンスを稼ぎたい場合はFSxも選択肢に入ってくるでしょう。