2019 21 Feb

【後編】DeNAゲーム事業におけるデータエンジニアの貢献〜客観性を担保したLTV予測やBigQuery運用におけるコスト最適化、そしてMLOpsへの挑戦〜

【後編】DeNAゲーム事業におけるデータエンジニアの貢献〜客観性を担保したLTV予測やBigQuery運用におけるコスト最適化、そしてMLOpsへの挑戦〜

  • このエントリーをはてなブックマークに追加

2019.02.21

  • Facebookでシェアする!
  • Twitterでツイートする!
  • はてなブックマークでブクマする!

2019年2月6日、渋谷ヒカリエにて、技術者向けの大規模イベント「DeNA Technology Conference 2019」が開催されました。

本記事では、DeNAゲームサービス事業部の分析部に所属する岩尾と石川による「DeNAゲーム事業におけるデータエンジニアの貢献」と題したセッションの後編をレポートします。

前編はコチラをご覧ください。
※記事の最後にはセッション時に投影した資料を掲載していますので、そちらもご覧ください。

BigQuery運用のコスト最適化、その事例に迫る

第2部”システム運用の改善”は、分析部の3つの役割の中の改善系がテーマ。BigQueryの運用におけるコスト最適化やMLOpsへの挑戦といった裏で動いているシステム、特に運用周りにおける課題とその解決策について、岩尾が解説していった。

分析部データエンジニアリンググループ グループリーダー:岩尾一優

昨年7月にDeNAにジョインした岩尾は、「入社以来、ずっとBigQuery周りのコストの事が気になっていた」と、ただ規模が大きいだけでなく秩序が乱れているように感じたそうで、現在”BQ警察”としてコスト最適化に注力している。

始めに岩尾は、DeNAゲーム事業でどれくらいの規模のデータを扱っているか数値で示し、BigQueryのストレージ容量が2PB以上、BigQueryのコスト(2018年9月時点)が月680万円かかっていると説明。「これはかなり大きい部類のデータとコスト」(岩尾)だが、それが12月の時点で420万円になったという。

その3ヵ月間でコストを削減した過程で何を行ったのか? 岩尾は大きく分けて3つあるとし、その1つが現状の可視化。請求データを使って全体を見た後に、BigQueryのメタデータを見て何にどれくらいかかっているのかを可視化したそうだ。

可視化によって攻め所がわかってきたので、次にシステム的な改善に着手。ここで岩尾は、「BigQueryはスキャンしたデータ量によって従量課金である」という特徴を紹介し、この点が重要なトピックスとした。

3点目は運用の改善。そもそも巨大なクエリを投げてしまったときに気づく仕組みがこれまでなかったという背景があり、そこを気付ける仕組みを導入し、気づきの後にメンバー間で改善するマインド醸成に取り組んだという。

採用した主な技術を紹介

現状の可視化(請求データ)について、2018年1月~9月の期間、どのようにコストが推移しているのか現したグラフが提示され、「ストレージもクエリ検索もコスト増加傾向で、3ヵ月ごとに月額で100万円ほど伸びている」と解説した岩尾。

その詳細を確認するために利用されたのが、Stackdriver Monitoring。これは専門的な知識がなくても簡単な操作でGCPやAWSのリソースと連携してメタデータを可視化できるという。「我々の使い方では、BigQueryのメタデータ(ストレージ容量やクエリ検索量)の見える化に利用している」(岩尾)とのこと。

ストレージ容量の内訳を確認する際、あるゲームでは特定のデータセットがストレージの大半を占めていることなどがわかるという。その部分を削減することができれば「ストレージ容量が大幅に削減できそうだなというあたりを付けることができる」と岩尾は語った。

そしてクエリについては、ゲームごとのクエリ検索量を色分けして明確化した。これで、ある部分が全体の大部分を占めていることがわかる。

「ゲーム自体は十数タイトル管理しているが、その中でもいくつかのタイトルだけに集中していることが見てとれます。もちろんデータの保存量自体バラつきはあり、これで一概に良い悪いは言えません。利用者によるスキルのバラつきや、そもそも検索対象となっている中間テーブルの設計に問題があるのかも」という部分にも踏み込んだと岩尾は語った。

また、別の切り口として、ある日、クエリが1日に50TBくらい投げられた事件が発生した事例を紹介。これも可視化することにより、担当者が意図していたクエリかどうか、その原因を調べることができるなど対策の検討がしやすいという。

ここまでが現状の可視化について。次に岩尾は5つの改善事例を紹介。

1つ目は、データライフサイクルの定義することでストレージ容量を削減した改善事例。データ分析は本来1日だけ保存しておけばいい場合や、ずっと残しておきたいなど、必要な保存期間が異なる。ただ、「リリース時にそれが確実にわかるかと言えばいえばそうではない」と岩尾。

そこで重要なのが定期的な棚卸。「我々はデータアナリストと同じ部内にいるので、連携しながらこれは消していいのかどうか棚卸しながら設計しました」(岩尾)とし、必要な保存期間に応じてローテーションさせる仕組みを導入した。

そして設定ファイル上で、どのプロジェクト、どのデータセットでどのテーブルを何日間保存したいのかを一元管理した。一つのプロジェクトだけではなく、全体でどんな感じで設定されているか一元管理することで、検討漏れがなくなる。あるゲームタイトルでは約60%のストレージ容量を削減できたそうだ。

※一部AWSを利用しているのはシステム移行中のため

2点目の改善策は、Clusterd Tables(β版)を導入したクエリ検索量の削減。これまでBigQueryは分割テーブルを使って検索量を抑えていたがそうだが、一方で日付レベルよりさらに絞り込む方法はなかったという。

そこで、「他のカラムについてもインデックス付与することにより、ある程度検索範囲を絞れる機能を導入した」と岩尾。実際にこれまで1回で2TB検索しなければいけなかったものが、2GBまで抑えられたという例もあったそうだ。

また、移行については新規テーブルを作成し、既存テーブルからレコードをコピーするので面倒ながらも、「そこさえ乗り越えればかなりの恩恵がある」(岩尾)とのこと。

3点目はjsonペイロードのparseによるクエリ検索量削減。ユーザーが保持しているアイテムの1~100から1だけを抜き出したい場合でも、これまではjsonペイロード全体を検索してしまい、クエリ検索量の増加につながってしまっていた。そこで、よく使うデータはparseして別のカラムとして保持して検索するのがクエリ検索量削減になるそうだ。

4点目は、BIツールの不要な定期実行機能を停止することでのクエリ検索量の削減。岩尾は「我々は、使っているBIツールをcron形式で行っていたので、それに慣れていないデータアナリストであれば、不用意に週末だったり夜間を実行してしまうことがあった」と説明し、その点も改善した。

最後の改善事例は、巨大クエリ実行時にSlack通知をする仕組みを作ったこと。

岩尾によると、システム的にガードをかけることも可能だそうだが、「本当に必要なクエリをたたくときにエラーが返ってきたら、イラっとすると思う。システム的ガードではなく敢えてメンバーを信頼し、巨大クエリを投げてしまっても通知を見て皆でどうすれば良かったか話し合える文化をつくりたかった」とのこと。

そして岩尾は、紹介した改善事例にって、結果的に月260万円のコストを削減し、ストレージは40%、クエリ検索は41%改善したことを明かした。

MLOpsへの挑戦、今後のデータエンジニアリンググループの展望

最後にMLOpsへの取り組みについて紹介した岩尾。

伝えたいこととして、「初心者にとってMLモデルの実行はハードルが高いです。部内のデータサイエンティストがJupyter Notebookで作成したMLモデルをgithubなどで経由してやり取りしていたが、それだと自分の環境だけ動かないみたいなことも発生してします。環境構築ほどイライラする作業はないと思っている」とそれを解決したいと考えたのが取り組みへのキッカケだそうだ。

従来のシステムは、VM上にMLモデルの設置、実行をしていたが、この構成だと環境構築が面倒で、今後の移行も困難だという。そこでBigQuery、Dockerに加え、ContainerRegistryという主な技術を活かし、「dockerコンテナで起動するよう変更した」(岩尾)という。

それによる新しいシステム構成では、EC2上でdockerコンテナを起動する方式を採用。Container Registryから必要なDockerイメージをpullして使うだけで環境構築が簡単で、GCP移行時もGCEでdocker runするだけの容易さがメリットのようだ。

※一部AWSを利用しているのはシステム移行中のため

岩尾は、「これまでデータ分析におけるMLの導入は環境構築や移行の手間に悩まされてきたが、MLモデルをdockerコンテナを入れたことで解決に向かっている」とML Opsの現状に触れたが、「まだまだ未解決な部分もある」とし、今後の展開として、現在ローカルで行っているDockerイメージのビルドを自動化したり、もしくは学習・推論でモジュールを分割すること、モデルのバージョン管理、ロギングについて、「現在対応をしている最中」とコメントした。

そして最後に、「データエンジニアリンググループは2月から出来たばかりの組織です。本日お話した内容以外にも色々行っています。現在立ち上げ期ですので、我こそはというデータエンジニアの方はジョインして一緒に盛り上げていきましょう」とメッセージを送った。

前編を読む
【前編】DeNAゲーム事業におけるデータエンジニアの貢献……客観性を担保したLTV予測やBigQuery運用におけるコスト最適化、そしてMLOpsへの挑戦

セッション時の投影資料はこちら

※本記事は2019年2月時点の情報です。
※本記事は、SocialGameinfoに掲載された内容を一部構成を変更して掲載しています。

GeNOM(ゲノム)とは

DeNAのゲームクリエイターを様々な切り口で紹介するメディア(運営:株式会社ディー・エヌ・エー)です。ゲーム開発の現場で生まれる様々なエピソードや、クリエイター紹介、イベント紹介などを通して、DeNAで働くメンバーの”ありのまま”をお伝えしていきます。

GeNOMの最新情報は、公式Twitter アカウントにて確認いただけます。ぜひフォローをお願いします!