DeNATechCon2019に参加した際にメモしたことを折角なので公開。

全体的に内容がまとまっていて、かつ分かりやすく噛み砕いてくれていたものが多かったので良かった。 4つのセッションが同時並行していて、常に興味あるセッションがあったのも有り難かった。

D-STAGEがかなり狭くて座れず断念したので、次参加する際は注意したい。

1. ヘルスケアサービス開発の裏側 〜品質と開発効率の両立〜

DeNAのヘルスケアサービス

• DeNAでのヘルスケアサービス
  • MYCODE
    • 自宅で唾液から遺伝子検査可能なサービス
  • 2015年から他にもいろいろやってる
• なぜいろいろやるのか
  • 人々の健康寿命（健康の状態で過ごした時間）を伸ばす、をミッションにしている
  • １つのサービスだと限界がある
  • 健康に関するいろいろな側面（運動、食事、睡眠など）から支えていきたい
  • 長期間にわたって（高齢まで）使ってもらいたい
• どうすれば長期的に使ってもらえるか
  • 機能面
    • 長期に渡って無理なく自然に楽しく利用可能な仕組み
  • 技術面
    • セキュリティの品質を担保しつつスピードを維持して開発できるアーキテクチャ・プロセス

バックエンドのアーキテクチャ刷新

• 最近の課題
  • アーキテクチャやプロセスが起因で開発スピードが低下
  • 具体的にはシステムの複雑性が増した
    • プロダクトが増加
    • 外部プロダクトとの連携
      • OAuth
      • お薬の情報などの取得
    • 内部のサービスも増加。アドホックに追加されていったのでサービスの分け方も適当
  • なぜ複雑性が増したか＝新機能開発を優先したため
• やりたいこと
  • サービスの分割と統治
    • 分割することで改修時の影響範囲を限定的にする
    • 共通機能は統治する
  • BFF（Backend For Frontend）構成
    • プロダクトごとに求められる形式でAPIを返す
  • プロダクトやサービスとチームの対応付
    • マイクロサービス、BFF、プロダクトごとにチーム分けする
• どうやったか
  • 新環境は既存環境とは全く別に構築し、タイミングを見計らって移行
• 新環境の技術スタック
  • GCP
    • GKEを用いたかったため
    • セキュリティなど非機能要件の懸念はあったが、そこも工夫でなんとかできそう
  • Istio
    • サービス間の通信制限、暗号化
    • outbound通信の制限などのセキュリティ要件の担保
  • Cloud Memorystore
  • CloudSQL
  • Golang
    • Microservice
  • Node.js
    • BFF

リーン開発と設計

• 前提
  • 自社サービス・新規開発・内製
  • 大枠のテーマに沿ってサービス開発
  • 少数精鋭
• プロダクト開発は不確定要素が多い
  • 作り始めてから問題が発覚する
• 対策
  • プロトタイピング
    • 実際の端末とリアルに近いデータで一通り触れるものを作る
    • 序盤に問題を発見できる
  • ドッグフーディング/アルファ・ベータテスト
    • とにかく自分で使う
    • 本当に健康に効果があるのかデータを集める
    • Fabric、OTA、Test Flight
  • 開発中に起こった問題を自動修正する
    • データモデルの修正
      • Swagger
        • APIの仕様をバージョン管理
        • ライブラリを自動生成
        • DockerでAPI/ mock serverを自動生成
    • UIの変更
      • 1 Storyboard & routing

所感

• 導入でヘルスケア事業をやっていく上で大切にしていること（＝人々の健康寿命の伸ばす）を述べてくださったのは良かった。そのために長期的に使ってもらうというのは理にかなっているし、ビジネス面でのメリットもあるなと感じた。
• BFFはなぜか今まで適用範囲は限定的に感じていたが、共通のAPIを利用するコンポーネント（プロダクト）群のバックエンド層、と考えると、割と適用箇所は多いのかなと感じた。

2. AIによるアニメ生成の挑戦

GAN/提案手法

• GAN
  • GeneratorとDiscriminatorを戦わせる深層学習手法
  • Progsessive GAN
    • モデルの解像度を段階的に上げることで高解像度のモデルを生成
  • Big GAN
    • 多様な対象に対して画像を生成できるようになった
• 提案: 構造的生成学習 PSGAN
  • 従来難しかった全身のような複雑な構造での高解像度生成を実現
  • 構造と画像生成を同時学習
  • 解像度を段階的に上げ、より高解像度の画像（progressive）

SPGAN

• コストの高いアニメ中割
  • 近年アニメ現場で制作にかかるコスト・時間が課題になっている
  • 動画マン
    • 原画と原画の間を埋める絵（アニメ中割）を描く人
    • ３０分アニメ１話あたり３５００〜４０００枚
    • 一枚数時間かかる上に報酬２００円
• アニメ中割の自動化
  • Multi Frame Interpolation
    • 現在あるもの
      • Super SloMo
        • 30/60 FPS→８倍くらいのフレームレートにできる
      • Deep Voxel Flow
        • 30 FPS → 60 FPSに
    • 共通点
      • NNによるOptical Flowの計算
        • 2枚の動画間におけるpixelの移動量を表したベクトルマップ
• アニメへの適用の問題点
  • 低FPS
  • アニメ調なのでOptical Flowを計算しづらい
    • pixel対応点の特定が難しい
• SPGAN
  • Optical Flowに加えい、構造情報も利用したマルチタスク学習モデル
  • Input
    • 入力画像
    • Optical Flow
    • Pose Keypoint
    • 各部位のマスク
  • 2つのDiscriminatorを利用
    • 一枚絵の細部を見たときのDiscriminator
    • Image Sequenceを見たときのDiscriminator
• 実アニメへの適用

感想

• 現役で戦えるDNNの研究者まで囲っている技術者層の厚さ、社内のデータを使っての研究、また、会社の事業との親和性が高い「アニメ」という分野への応用など、DeNAさんの組織としての強さを感じた
• 技術的な疑問
  • 実アニメの場合、構造変化が大きいものはまだ難しそう？
    • 実アニメへの適用、の具体例で構造変化が大きいものの紹介がなかった
  • Pose Keypointには基本的な構造位置しか含まれてないので、まばたきや口の動きなどの変化は補完できなさそう
    • そこはOptical Flowでできる？
  • アニメ調、という課題が結局SPGANで解決されたのかはよくわからなかった（構造がわかれば大まかな対応が分かるからpixel対応点の特定も容易になった、ということ？）

3. 運用中のゲームにAIを導入するには〜プロジェクト推進・ユースケース・運用〜

AI施策をどのように作ってきたか

• 課題
  • 面白さを体験するまでに多くの試行錯誤を要求する
    • どのようにデッキを組めばいいか
    • コマの活用の仕方
• デッキ編成サポート機能
  • 上位プレイヤーのデッキ編成ログをもとにキャラクターを編成
  • アソシエーション分析
    • 各キャラクター間の関係が支持度、信頼度、リフト の３つの指標で定量化できる
  • ただし、ユーザの納得感が大事
    • 適当におすすめしただけではユーザのプレイの文脈に沿わないおすすめをしてしまう
    • そのためのチューニングは行っている
      • リーダーコマを選ぶときは別のルールを併用
      • スキルが活動可能かをチェック
      • マイナーなコマを選ぶときはルールを変更
• 深層学習を使った戦略の学習
  • 上位プレイヤーの棋譜を用いる

AI施策を実現するための技術

• モデル開発には周辺タスクがいろいろ
  • Hidden Technical Debt in Machine Learning System
• システム設計
• 推論APIに求められる要件
  • オンライン処理（バッチ処理はだめ）
    • ただし、ターン処理なので１５秒以内に返せば良い
• Cloud ML Engineの課題
  • 一定割合でタイムアウト（１０秒超える、をタイムアウトと定義）
  • インスタンス増加のタイミングで発生
  • 対策
    • 普段はMainで処理
    • ５秒超えたらBackupに回す
  • 結果
    • Backupのmin nodeを20にすると、タイムアウト率が0になった
• 運用を楽にする技術
  • Experiment as Codeを徹底
    • 再実験と共有が楽になった
  • 設定ファイル
    • ModelRecipeというクラスを作ってまとめている
      • 特徴量のスキーマ定義など

プロジェクトの振り返りと今後

• スモールスタートで
  • AIプロジェクトの最大の課題は不確実性
    • AIに何ができるのかわからない
  • 細かいサイクルで検証を回す
  • 検証
    • AIの学習は可能か
    • キャラ拡張は可能か
    • 勝率を上げることは可能か
    • 現実のユースケースに耐えうるか
• 期待値の合意
  • 不確実性があるので期待値は人それぞれ
    • AIメンバーと事業側の認識が異なることがある
  • ３つの見通しをすり合わせることで共通の期待値を醸成した
    • 現実ライン
      • その時点で現実的に着地しそうな見通し
    • 最低ライン
      • 想定通りの精度が出なかった場合など、保守的な見通し
      • これが一番大事
    • 理想ライン
• AIチームの役割を分散
• 目的を見失わない
  • AIのためのAI開発をしない
  • 強いAIやAIと対戦できることそれ自体はメリットにならない

感想

• 特に最後のプロジェクトの振り返り、で言われてたことはとても納得感のある知見だと思った。AIを事業に適用する上でのコミュニケーションの重要性を認識できた。

4. パネルディスカッション：データサイエンスの競技者、Kagglerたちが活躍する職場とは

• 社内Kaggle制度
  • Kaggle上位者は入社してからも業務のN%をKaggleに当てて良い
• Kagglerが行った業務の例
  • 関西電力とDeNAが石炭火力発電の運用最適化を行う
• チーム構成
  • AIシステム部
    • AI研究開発エンジニア
    • データサイエンティスト
    • MLエンジニア
  • 分析基盤グループ
    • AI・分析ツールエンジニア
    • AI・分析インフラエンジニア
    • 分散基盤エンジニア
• データサイエンティストに求められるスキルセット
  • http://www.datascientist.or.jp/news/2014/pdf/1210.pdf
  • ビジネス
  • データサイエンス
  • データエンジニアリング
• ビジネスアナリスト、MLエンジニア、Kagglerが一緒に仕事をする
• ビジネスアナリスト
  • 事業と話して課題を決め、その後Kagglerとともに問題解決をしていく
  • 事業が抱える問題をどうやってデータサイエンスに落とし込むか
    • そもそも何がしたいのかを考えて問題設定する
    • 定量的に問題比較
    • 事業の場合はKaggleの問題より精度を求められない
      • そのため、Kagglerにとってはそこまで面白くないらしい
• MLエンジニア
  • Kagglerと一緒にAuto motive
  • モデルを作る以外のエンジニアリングをいろいろやっている
• Kagglerがやってきてどう変わったか
  • できることが広がった
    • LTVモデルを高い精度で作成
      • 広告費をどれくらいかけるかなどの応用に役立っている
    • 関西電力との石炭火力発電の運用最適化
• Kagglerにとって
  • 様々なバックグラウンド（研究分野など）を持つメンバーがいる環境が快適
  • みなKaggleが好きなので共通の価値観があってすごしやすい
• なぜ転職したか
  • Kaggler枠
  • 事業の多様性
• Kagglerとビジネスアナリストの関わり方
  • ビジネスアナリスト
    • 事業がデータサイエンスにもとめるレベルは上がっている一方で、技術面はどんどんタコツボ化しているので、間を取り持つ者として頑張っていきたい
  • Kaggler
    • どうしても問題解決のことを考えてしまうが、事業課題の設定をしてくれる人＝ビジネスアナリストがいてくれることがありがたい

感想

• 機械学習を事業に適用する上でかなりしっかりとチームが分けられていて、組織としての体制が整っているように感じた。
• 事業部と話し合って課題設定を行い、かつ機械学習にも（Kagglerほどではないが）精通している「ビジネスアナリスト」のポジションはかなり重要になりそうだと感じた。
  • 特に「事業の場合はKaggleの問題より精度を求められない」という話であれば、そういう人材がバリューを発揮する場所はかなり多そう

5. DeNAゲーム事業におけるデータエンジニアの貢献

第1部: LTV予測による事業への貢献

• LTVはなぜ重要か
  • 顧客生涯価値
  • DeNAでは、ゲームごとに一人のお客様が支払う累積額
  • 獲得コスト＜LTV
    • 30億円
• LTV予測の課題
  • 特定の期間にゲームをインストールしたユーザがその後支払った総額の平均
  • 従来
    • 30日LTV実績から180日LTV予測を作成（倍率など）
    • CM放映予定時期と同じ月の実績をLTV予測値として使う
  • 課題
    • 時系列で客の傾向が変わる
    • ゲーム内施策が未確定、あとから変更されるなど
• LTV運用の課題
  • 予測における恣意性
    • 予測の教師データとしてどの時期を採用するかを考慮項目として何を選ぶか自由度があるとLTVを高く見積もる傾向
  • 予測モデル更新の負荷
    • 累乗近似法の予測が用いられた
    • 修正が面倒
  • 予測手順が後でわからなくなる
    • 恣意性や予測モデルの更新が潜在するため
• 課題の解決
  • 恣意性
    • サンプリング期間を固定
    • 考慮項目を固定
      • ゲーム内施策などは（不確実性が高いので）考慮しないで、週次、月次トレンドなどだけ考慮する
  • モデル更新の運用の手間
    • Prophetにすることによって、更新、推論などが自動化された
      • Jenkinsなども使っている
  • LTV提供に時間がかかる
    • 予測を社内BIツールで提供

第2部: システム運用の改善について

• BigQueryのコストを最適化した
  • ストレージ容量 2PB+
  • 680万円/月 （9月）
  • 420万円/月（12月）
• どうやって減らしたか
  • 現状の可視化
    • 請求データ
    • BigQueryのメタデータ
  • システム的な改善
  • 運用の改善
• 現状の可視化
  • StackdriverMonitoring
    • ストレージ容量
      • ストレージの一部のディレクトリサイズが異様に大きい、などがわかる
    • クエリ検索量（多分クエリの対象データ量のこと）
      • タイトルごとにクエリ検索量を色分け
• システム的な改善・運用の改善
  • データライフサイクルの定義
    • テーブルごとに必要な保存期間は異なる
    • 必要な保存期間を定義してローテーションする
  • Clustered Tablesの導入
    • インデックス
    • 面倒なところ
      • 新規テーブルを作成して既存テーブルからコピー
  • jsonペイロードのparse
    • 巨大なjsonペイロードを1カラムに入れたまま使わない
  • 不要な定期実行機能を停止
  • 巨大クエリ実行時のSlack通知
    • システム的にガードをかけるのではなく、あくまで通知をするだけ
    • 当月の累積課金額も日時で通知
• MLOps
  • 環境構築の面倒をなくす
  • MLモデルをDocker containerで起動するように変更
    • メリット
      • 環境構築が用意（Registryからpullするだけ）
  • 今後の課題
    • Docker imageの自動生成など

感想

• LTVは大事だと思う半面、CMによる流入ユーザ数がいくらかという話や、CMによって流入したユーザとオーガニックユーザの定着率の違い、なども恐らくあると思うので、その辺りを総合してどのように評価しているかは気になった
• BigQueryでもEMRによる運用などと同じ問題は抱えつつも、可視化等の改善がやりやすそうなのは魅力的だなと感じた