AI(ここではDeep Learning(以下DL)と同義として話を進めます)開発を行う環境でお悩みはありませんか。一人でやっているのなら何とでもなるかもしれませんが、多数の人間が複数の共有マシンで作業をしはじめると阿鼻叫喚なことになりがちです（私たちの会社がそうでした…）。そのような経験を経て私たちはDocker をベースとした DL 環境管理システム Maison DLを構築しています（運用もしています）。本連載では開発の経緯を含めMaison DLをご紹介していきます。
1. 背景など
当社では日本においてはかなり早い段階である 2013 年頃から AIの分析や 開発に着手してきました。古くは GPU を搭載したサーバ(以下 GPU サーバ)を用意し、OS(Ubuntu 14.04) をインストール、その上に cuda-convnet や Theano など各種 DL ミドルウェア(DLMW)をインストールして開発していました。 その後 AI案件を多数頂く様になったと共に、 caffe, tensorflow, chainer など多種多様な DLミドルウェア が登場してきました。この様な状況の中で 2017 年の始め位までは逐次 GPU サーバを導入しホスト OS 上に DL 環境を構築していたのですが、最新バージョンへの追随・新規 DLミドルウェア への対応・環境更新に伴う開発者への負担など様々な問題が発生するようになってきました。そこで 2018夏現在、Docker をベースとする DL 環境管理システム Maison を開発し、社内で運用しています。
2. DL 環境の利用状況
私たちは技術集団でして、フロアは別れていますが顔が見える範囲で作業をしています。情報セキュリティこそ厳しいですが（ISMSを運用しています）、開発や作業環境面では伝統的に緩い運用をしています。つまりプロジェクトで規定されたOS・ライブラリ・ミドルウェア・コンパイラ等のバージョンさえ守れば各自自由な環境を構築して作業しています。
- 環境を必要とする人数
数十人程度。プロジェクト状況により変動します。 - マシン台数
メインの共有機を 10数台です。各機GPUを１~２枚搭載しています。その他プロジェクトによって専用機、クラウドやお客先指定環境を利用する場合もあり。 - DLミドルウェアの種類
様々です。keras, chainer, caffe,Tensorflow等。お客様の指定、問題への向き不向き、技術者の好みなど様々な事情のためです。バージョンも様々となっています。 - GPU サーバの使い方
メインはDLの学習ですが、各種前処理・データ加工でも使用します。 - バッチジョブ vs コンソール作業
各自コンソール作業が多し。長時間学習やバッチ的に使うこともありますが、どちらかというと少数派。各サーバは 24時間運用で、出社後は ssh/VNC で繋ぎっぱなしという使い方です。
3. Maison 導入前
私たちは個の信頼・技の管理を大方針のもと作業環境は各個かなり自由となっていました。とは言え、GPUは希少リソースですので共有機での作業となります。現状GPU環境の環境分離をまともとできるのはDocker位のものですから、私たちも各人／各プロジェクトはDocker上に構築するようにしました。後は頑張れということで、
- 共有サーバのアカウントは各自自分で勝手に作れ。どのサーバを使うは当事者間で調整せよ。
- Docker コンテナの環境構築や実行は各自でやってね
- ディスクは足りなくなった追加するので適宜使おう
まぁ、兎に角うまくやれということで。
4. 山積する課題
こんな（不）管理では課題が出てくるのは当然で…
- どれを使ったらよいの？
当初はマシン毎にチャットチャネルを作って各自調整としていました。使う人が少ないうちは運用できましたが、多くなるに従い状況がわからなくなってきました。使用状況がマシン毎（チェネル毎）に分割されていて全体像を把握できません。
⇒予約管理 の必要性 - リソースは足りているの、いないの、いつ増強する？
全体像を把握することが困難なため、全体としてリソースが足りているのか足りていなかもわからない状態でした。いつ増強すべきかがわかりません。
⇒使用状況などリソースの可視化 の必要性 - このDocker imageはどうなっているの？またbuildしないといけないの？
各環境はDockerにという決まりしかありませんでしたから、自分でDockerfileを書いてbuildする人から、他人のイメージを借りる人まで区々になってしまいました。あまり色々なのでプロジェクトが変わったときに困る人が出てくるようになりました。自由もよいですが硬さも必要です。
⇒自由さと硬さ のバランス - 誰のもだかわかりません！
不要なコンテナは削除するルールになっているものの、このルールはあまり守られませんでした。誰のものかわからない巨大な docker image が残りディスクを圧迫する事態となりました。動いているコンテナや存在する docker image などは docker コマンドなどから調査することはできますが、「誰」のコンテナか、「誰」が作った docker image か、など「誰」を後から追跡できませんでした。
⇒作業者の追跡性 の必要性 - データはどこに置く？引っ越しが大変
DL絡みではデータはどうして大きくなります。データサーバの機材はありますが、ネットワーク越しでの学習では遅すぎです。結局コンテナにあるホストでデータを持ってくるのですが、データ転送に時間がかかったり、ネットワークに負荷がかかったりして大変です。
⇒環境間でのデータ共有
このように問題山積な状況を有志のメンバーが立ち上がりました（大袈裟）。そこで開発したのがDL 環境管理システム Maison DLです。次回Maison DLの設計思想と機能について説明します。