【レポート】【ABEJA 様ご登壇事例】Deep Learning プラットフォームを支える技術 #AWSSummit

まいど、大阪の市田です。

本記事は、現在開催中のAWS Summit 2018 Tokyoで行われた事例セッション「【ABEJA 様ご登壇事例】Deep Learning プラットフォームを支える技術」のレポートです。

セッション概要

ABEJA は多くの AWS サービスを活用し、10,000 コンテナ、4,000 を超える IoT エンドポイントを運用しています。このセッションでは、Deep Learning プラットフォーム「 ABEJA Platform 」を支える技術についてご説明します。kubernetes や GPU に加え、Python / Elixir / Go などの多様な言語で実装されたマイクロサービスであるプラットフォームを構築してわかった、AWS をおいしく活用するノウハウをバッドノウハウも含めてお伝えします。

株式会社ABEJA Platform Developer：石川 尊教 氏
株式会社ABEJA Platform Developer：上野 祐介 氏

セッション内容

今日話すこと

• DeepLearningプラットフォームとその裏側
• 最初は石川 尊教 氏の登壇で始まりました。

前半パート

• DeepLearningのGoogleトレンドが「2012年01月」あたりから急激に上昇
  • 何があったか
  • 東京でスカイツリー完成、金環日食、生の牛レバーが食べられた最後の年
  • Dynamodbの東京リージョンリリース、Redshiftの発表
  • ILSVRC 2012の開催
    • 大規模なデータセットの画像認識のコンテスト
      • 年次開催だがこの年は特別な回であった
      • なぜならブレイクスルーが発生した
      • ディープラーニングの手法でそれまでの統計モデルを使った従来のものより10%以上の差をつけて圧勝した

DeepLearningの5つの工程

１. Data collection

• センサから発生するデータ収集

２. Annotation

• 集めたデータはそのままでは使えないので、ラベル付けする必要がある

３. Training

• ラベル付けしたデータをモデルを学習
• 処理には数日かかることも

４. Inference

• 推論させる
• APIとして提供するのか、バッチ処理にするのか検討
  • バッチの実行状態の管理など

５. Re-training

• 精度を保つために再度学習が必要

上記1〜5のサイクルの繰り返し

• こういった作業に多大な人的リソースがかかった
• 2018年で
  • 500超えるPOC
  • 10TBバイト以上のデータ・・・という状態

ABEJA PLATFORM

• 上記5つの工程をサポートしている
  • Annotation専門のAnnotationサービスを提供している
• 検討すべき課題も多い
  • Annotationが終わってしまえばGPUでモデル構築、Lambdaにデプロイでいいか？それで十分なのか？
  • GPUの管理は誰がする？利用費高いよ？
  • 開発者まかせにして、思わぬコスト
    • モデル学酒につかったJupyterリソースの管理
    • ミドルのテンプレート化などで省力化はできるけど・・・
  • 推論のモデルの管理、権限管理どうするか
  • メンテナンスはどうするのｋ？
• ABEJA PLATFORMはこういったことを前提としたプラットフォーム
• マイクロサービスアーキテクチャの採用
  • 突発的なデータロードに耐えうるデータコレクション
  • トレーニングは数日のジョブを確実に実行できる、など

構成

• EC2,ECS,ALB,Route53
• S3,RDS,Dynamodb,Lambda/Step Functions
• Cloudwatch,Kinesis stream など

（実際にはスクリーンには構成図が移されていました）

構成その2

• Github
  • 30リポジトリ
• 5つの言語
  • python,Go,Elixir,Ruby,JavaScript
• 10人程度で開発

後半パート

ここで登壇者が「上野 祐介」氏に交代となりました。

学習で問題になること

• 実験条件を毎回記録するのがめんどう
• 学習を複数同時に行えない
• 学習が上手く行っていない場合には打ち切りたい
• その他に「学習環境に求められること」といった点の話がありました。

コンテナクラスタの管理

• 学習ジョブコンテナ
• 学習可視化コンテナ
• 学習館入りコンテナ
• Jupyter notebookコンテナ
• Kubernetesを使用している
  • EC2 GPUインスタンスのコンテナクラスタを構築

なぜKubernetesか？

• EBSの管理が可能
  • ロードした大量のデータの使い回しが可能
  • daemon set の仕組み
  • 管理系のコンテナをすべてのインスタンスに配置可能
  • インスタンスのリソースの使用率が低くてもスケール

プロビジョニングツール

• kops/kube-aws/rancher/kubeadm
  • kubeadmを採用
  • 既存のリソースとの兼ね合いなどから採用
  • マスターの高可用性（etcd,controle panel)

EKSへの期待

• 少人数の体制なのでこういったサービスにまかせたいと思ってる

Inference

• 推論で行うこと
• 重みデータを使用する推論コードを実行するPAPIの作成
• 推論API基盤に求められるもの
  • 手軽にAPI化できる仕組み
  • データサイエンティストの本業ではないAPI化構築作業に時間を割きたくない
  • デプロイの仕組み
  • アプリケーションのログ収集の仕組み

推論API構築機能

• Blue/Green Deploymentの機能も提供
• ロギング機能も提供

API構築機能

• 初期：ユーザの推論APIをECSタスクとして作成
• ALBのListner ruleで各ECSタスクにリクエストルーティング
  • ALBの制限
  • LBあたりのリスナー数50
  • ルール数100

新たな推論API基盤

• 自作のgatewayでリクエストのルーティング
• CloudWatch Eventsを使用してルーティング情報を作成（Lambda）
• ヘルスチェックに失敗したコンテナ情報をDynamodbから削除
• ところが、ECS Service Discoveryが先日発表された
  • これがほしい機能だった。
  • 変更も視野に入れている

推論APIをクラスタ運用

• CPUとGPUの２つのクラスタを運用
• 各APIはそれぞれが必要なVPUとメモリー数を予約

Spotinstの利用

• SpotinstのElastigroupを使っている
• クラスタインスタンスを安全に切り替えることができる。
• 安く運用することが出来ている

Blue/Green Deployment

• エンドポイントへのエイリアスの張替えで Blue/Green Deploymentを実現
• Dynamodbのレコードを書き換えてゲートウェイがリクエストを送信先のタスクを変更

ロギング機能

• ECSクラスタのログをawslogsでCloudWatch Logsに送信
• CloudWatch LogsをAPIでラッピング

[インファレンスクラスタ] → [CloudWatch] → [APIサーバ]

CloudWatch Logsの制限

• 1秒、１アカウント、1リージョンあたり
  • DescribeLogStreams：5トランザクション
  • GetLogEvents：10リクエスト
• 見直して
  • CloudWatch Logsの制限回避のためにDynamodbに格納
  • 期間指定で取得可能
  • 運用の容易さ
  • コストの低さ

Dynamodb に格納

• cwlogsのサブスクリプション機能を利用してKinesisに配置
• コスト削減のため、Lambdaにて1つのDynamodbレコードに複数ログエントリーをまとめて格納

[CloudWatch] → [kinesis] → [Lambda] → [Dynamodb] → [API server]

まとめ

• AWSを使って学習、推論できる仕組みを実現しました
• 利用者がコードを書いたり実験することに集中できる環境の提供
• EKSやECSサービスディスカバリの機能は今後導入を検討したい
  • 先日東京リージョン利用可能になったEFSも

最後に

近年非常に注目を集めているDeepLearningですが、AWSに最適化されたプラットフォームの構築とその運用方法について、とても興味深い内容でした。
また、EKSやECSサービスディスカバリ等、ユーザが欲しいと思っている機能を次々とリリースするAWSのパワーの一端を垣間見るセッションともなりました。