機械学習プラットフォーム でのDocker利用事例 スタートアップなエンジニアLT！ 〜スタートアップはどんな技術を駆使して開発を行っているのか？〜 ABEJA, Inc Toshiya Kawasaki 15-E-7 #devsumiE 2018/02/15

河崎 敏弥 @toshitanian ABEJA, Inc. Platform Division Lead Engineer •創業1年の時にABEJAに参画 •バックエンドエンジニア •クラウド上でシステム構築 •IoTデバイスとのシステム連携 •コンテナ •エッジコンピューティング

No content

機械学習のプロセス 4 入力データ 学習 推論 教師データ モデル モデル 入力 入力 学習 推論結果 推論 デプロイ

機械学習のプロセス + 周辺システム 5 入力データ 学習 推論 教師データ モデル モデル 入力 入力 学習 推論結果 推論 デプロイ データ蓄積/データセット管理/ジョブの管理 /コードの管理/ログ・メトリクス/デバイス管理/etc… 周辺システム

•学習フェーズ •推論フェーズ •クラウドサーバでの推論 •エッジデバイス上での推論 •マイクロサービス Dockerの使い所 6

•特徴 •ジョブの起動時間が長い（数時間〜数週間） •GPUを使って学習する •現在の構成 •Kubernetesのクラスタを作っている •GPUのノードをたくさんぶら下げている •nvidia-docker2経由でコンテナがGPUを使える 学習フェーズ 7

•特徴 •アプリケーションによってCPUで処理するか、GPUで処理するか変わる •HTTPでモデルをサーブする・バッチ処理でデータを処理するの大きく2種類の使い方 •現状の構成 •モデルの利用形式によりECSとAWS Batchを使い分けている •HTTPでモデルをサーブする場合: ECS •クラスタを分けてCPU/GPUノードへのスケジュールをしている •バッジ処理で利用する場合: AWS Batch •全てスポットインスタンス 推論フェーズ - クラウドサーバ上 - 8

•特徴 •リソース制約がある(CPU/メモリ/etc…) •ネットワーク制約がある。 •常時インターネット接続があるとは限らない •NAT超え •現状の構成 •AWS IoTをベースに、デバイスへDockerコンテナをデプロイ •ARMアーキテクチャ向けのDocker Imageを利用している •基本的にDockerを動かす事によるオーバーヘッドは無い 推論フェーズ - エッジデバイス上 - 9

•特徴 •学習⇔推論プロセスをユーザが運用するための周辺システム •データ管理/ジョブ管理/デプロイ管理/コード管理/デバイス管理/etc… •現状の構成 •基本的に全てのAPIサーバはDockerでデプロイ •ECSのひとつのクラスタで全てのAPIサーバを同居させている •ちなみに、マイクロサービスの前段に独自のAPIゲートウェイ マイクロサービス 10

•基本的に全てのアプリケーションはDockerコンテナとして動かしている •AWSのサービスやKubernetesを用途に合わせて使い分けている •7分では話しきれないので、詳細は別の機会で… ! まとめ 11 "