sonots先生の話を聞きに行ってきたので、そのメモを残しておきます。
- 瀬尾 直利 氏
- DeNA Co., Ltd.
- AIシステム部 リードエンジニア
DeNAの機械学習基盤
- ディープラーニングの基盤 => GPU基盤 という認識
- GPUすごくて、CPU使って30日のところ、GPUを使うと4日くらいのオーダー
GPUの特徴
- 並列処理が得意
- CPUだと24coreとかのオーダー
- GPUでは3000〜4000core
- 分岐処理は苦手
- 行列演算に向いている
GPU製品
- NVIDIA Tesla
- HPC向けにGPUシリーズ
- NVIDIA GeForce GRID
- クラウドゲーミング向け
- AMD FirePro
NVIDIA Tesla
- API
- CUDA
- OpenCL
- DirectCompute
CUDAのアーキテクチャ
- CPU(ホスト)からGPU(デバイス)にデータを転送
- GPUで処理
- GPUからCPUに転送
AI案件の環境
- トライアンドエラーな開発用途
- 占有GPUマシン
- パラメータチューニング用途
- パラメータを少し変えて大量に並列実行
- チューニングの時だけ使う
- クラウドのGPUインスタンスが相性が良い
- サービス提供環境はCPUでもよい
オンプレGPU環境
- Xeon E5 *2
- NVIDIA Tesla ＊2
AWS
- g2インスタンス
- NVIDIA GeForce GRID
- p2インスタンス
- NVIDIA Tesla
- 今は東京リージョンは使えないので、USリージョンを使っている
GCP
- Alpha版
- 申請したらk80が使える(p2インスタンスと同じ)
APIサーバ
- 2つのフェーズ
- 学習フェーズ
- 予測フェーズ
- 学習フェーズは開発環境で (GPU)
- 予測フェーズが本番環境で (CPU)
実例
- Chainer - Python
- Django
- ローカル Jubatus
- Blue Green Deployment
機械学習支援ツール
- GPUサーバのオンデマンドオートスケール
- 並列で学習を走らせたいので、必要な分だけ自動で起動する
- 終わったら自動で落ちる
- ec2-scale-run
- 既に立ち上がって使われていないインスタンスがいれば使用
- AWSは1時間課金なので、すぐには殺さない
- docker対応
- ECSは使っていない
- NFSマウント
- 中間データや学習結果データは共有ストレージにいれている
- Amazon EFSをマウント
- 容量自動拡張、値段は高め(S3の14倍)
- 東京リージョンでは使えない
- スポットインスタンスも活用している
- 70%OFFのコストで処理できることも
DeNA流データエンジニアリングの極意
データレイクとDWHに分けるべし
- レイヤを分けておく
- 全ては一度データレイク(HDFS)に入れて、そこから統合DWH(BigQuery)へ
- データレイクに集める
- 収集だけでも困難
- フォーマットやカラムなど、同時に考えるのは難しい
ストリーミング収集にはバッファを設けるべし
- ストリーミング収集
- 利点：リアルタイム性がある
- 欠点：運用が難しい
- メモリリークを引き起こしやすい、再転送が困難、負荷上昇時に遅延発生
- バッチ収集
- 利点：プロセスが常駐しないので、メモリリークが問題にならない、データ取り直しも再実行でOK
- 欠点：リアルタイム性がない、マシンリソースを最大利用するため、他に影響が出る可能性がある
- 処理が終わったら全くリソースを使わない時間がある
- 使い分け
- ストリーミング
- ログ収集
- バッチ
- DBのマスタデータの取り込みなど
- ストリーミング
- ログ収集基盤
- fluentdがログAPIにデータを転送
- HDFSに格納
- Importdb
- sqoopをベースにした内製ツール
- MapReduceでHDFSに格納
- Cassandraをログのバッファレイヤーに使っている
- 細かく書き込むとI/O負荷高い
- 送信側(fluentd)にもバッファレイヤーがあるデータをまとめて送ることで効率化
Retryableにすべし
- 手動で再実行する場合の考え事を少なく
- 自動リトライできるように
- 冪等にすべし
- リトライで同じデータを二重にいれてしまう問題など
- 追記ではなく上書きを原則とする
- それでも追記したい場合は、ユニークなjob_idを振って、リトライしても二重実行されないように
- atomicにすべし
- 途中までスカデータが格納されていない状態で、後続のジョブが走ってしまう問題
- リトライすると格納先のデータが一時的に消されてしまい、データが存在しない瞬間が発生する問題
- atomicな操作をストレージごとに調査
- HDFSだとtmp領域に書き込んで、終わったらrenameする、など
- uuidで重複除外すべし
- ログにuuidカラム設けて、基盤側で重複除去
Validationすべし
- 何もエラーが起こらずデータがnull値に変わっているような問題
- Validationして早めに気づくべし
SQLで分析すべし
- 生成系BIツールの問題点
- 内部で複雑なクエリが生成されて異常に重い
- やりたいことがサポートされていなかったり
- 分析者が自分でSQLを記述すべし
- 自由度高い
再取り込みを容易にすべし
- 再取り込みは頻繁に発生しうる
- データ遅延
- データ不正
- BigQueryが不安定、などで取り込み失敗
- 極意
- Retryableにすべし
- 時間パラメータの指定を可能にすべし
- デフォルト値としてのNOW()以外にも、再実行時に時間パラメータを指定できるようにしておく
- データ発生事項でデータをわけるべし
- データ発生時刻でディレクトリを分割する
- データのつながりを管理すべし
- ワークフローツールやJenkinsパイプラインで依存関係を整理する
- Triglav活用
- データ駆動ワークフロー形成ツール
- データ駆動でつながりのないツールにつながりを持たせてワークフロー形成を支援するツール(OSS)
- https://github.com/triglav-dataflow
追記
sonots先生が、資料を公開されていますので、そのリンクを。
