元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2017/02/17

デブサミ2017「DeNAの機械学習基盤と分析基盤」講演メモ #devsumi


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先生が、資料を公開されていますので、そのリンクを。

はてなユーザーのみコメントできます。はてなへログインもしくは新規登録をおこなってください。

トラックバック - http://d.hatena.ne.jp/rx7/20170217/p1

オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)