NVIDIA様のブログ「PARALLEL FORALL」にLabellioの技術的なバックエンドの記事を寄稿しました
弊社CTO原田とCEO(チーフエンジニアリングオフィサー)林が、NVIDIA様のCUDAなどを活かした並列計算を扱うブログ「PARALLEL FORALL」に、弊社プロダクトである「Deep Learningによる画像認識を可能にする最も簡単なプラットフォームLabellio」(ラベリオ、URL: https://www.labell.io/ja/)に関する技術的なバックグラウンドの記事を寄稿しました。
全体的な構成は下記のようになっております。かなり技術寄りの内容ですが、Deep Learningを扱うシステムを設計した際の様々な検討事項などが記載されており、この分野に興味のある人には非常におもしろい内容であると思いますので、ぜひ御覧ください。
僕も読んでいていくつか気になったポイントがあり、原田に質問しましたので、そちらを皆様と共有したいと思います。
- 今回の設計のポイントはGPUインスタンスの最大活用ということですが、この辺りについて、他のシステム設計者が気をつける必要がありそうなポイントはどこでしょうか？
やはりジョブスケジューリングは常に念頭に置くことでしょうか。機械学習やDeep Learningというと、データサイエンティストの方がマシンを専有して大規模データに対して実験して結果が出た、というところまでは良いのですが、それを実際のアプリケーションにして動かすと当然複数のタスクを同時に処理したり時には順番に処理したりということが必要になってきます。特にGPUは最近かなりスペックが上がってきたとはいえ、一つのタスクでGPUメモリを使い切るようなタスクも多々あると思いますが、それが2個同時に走ったら動かない、というようなことは容易に想像できます。
- RabbitMQの採用が印象的ですが、DeepLearningを扱うシステムを構築する上で相性が良かったということでしょうか？
Deep Learningにはある程度時間がかかる処理が多い、というというのは特徴的かもしれません。Webアプリケーションでユーザにインタラクティブに状況を説明しながらリーズナブルな時間で処理を進めていく上で、どの処理が同期的でどの処理が非同期的であるべきかを詳細に設計しました。特に非同期処理については一度Webアプリケーションのコンテキストから切り離されRabbitMQにタスクが流れることで、Fault Toleranceやジョブスケジューリングがやりやすくなっているという面は確実にあります。逆にRabbitMQをうまくコントロールしないと、コードバグによりキューが永遠に捌けないという状況が起きたりするので、MQにすればよいというものでもないですね。
- Dockerを全面的に採用したことによるメリット・デメリットなどあったら教えて下さい。
Labellioのバックエンドは主にPythonを言語として利用していますが、科学計算系のライブラリを多数使っていく上で依存性の管理は大変になります。Dockerはその辺りの管理がとてもやりやすいので重宝しています。逆に、Dockerをフル利用すると開発スピードは落ちるかなと思っていて、特に頻繁にコードを書きなおしてデバッグして、というのはベアに比べると大変になります。そこでLabellioでは実はアプリケーションコードはgitで管理しつつホスト側においておき、マウントオプションを使うことで、Dockerには依存性管理だけを託しています。ただこの組み合わせで、サービスへのデプロイやクラスタの構成変更は非常に容易になっています。 Dockerに関連して実は当初、Dockerコンテナのスケジュール管理を行うKubernetesの利用も検討しましたが、さすがにクリティカルなサービスに使うにはまだ早すぎたようで、Labellioは自前でコンテナ間の通信やアロケーションをコントロールするようになっています。このあたりも弊社としては技術が成熟してくるといいなと思っているところです。
以上となります。NVIDIA様のブログ記事や、本エントリーが皆様がDeep Learningを活用するシステムを設計する際の参考になりましたら幸いです。Twitter/Facebookなども開始しておりますので、よろしければフォローください！
- Alpaca JP Twitter: Alpaca Japan (@AlpacaJPN) | Twitter
- Alpaca Facebook Page: Alpaca | Facebook
また、Alpacaの様々な技術はNVIDIA様より提供していただいたGPUを活用して開発されております。この場を借りてお礼を申し上げます。
