機械学習プラットフォーム でのDocker利用事例 / DevSumiAbeja

Transcript

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

   View Slide

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

   View Slide

3. View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide