DeNAにおける、データ活用の重要性
松木秀憲氏（以下、松木）：よろしくお願いします。「2020年代に向けたDeNAの分析基盤」というタイトルでお話をさせていただきます。松木と申します。株式会社ディー・エヌ・エーのAIシステム部でAIと分析の基盤を担当しております。
なぜ「AI＆分析基盤」という担当になってるかなどを含め、お話させていただきたいと思います。
まずDeNAとAIシステム部という部署について、紹介させていただきます。
DeNAという会社はいろいろなサービスを提供している会社です。そして、自社独自であるいはパートナーさまと一緒に日々多くの価値あるサービスを創出するべく取り組んでいます。それでいて、大規模のインターネットサービスのプラットフォームの構築・運用力も持った会社です。
そのDeNAでのデータ活用ですが、やはりサービスを提供している会社なので、スライド右下の部分ですが、サービスを軸にデータを分析して、さらにサービスを改善するということを、ずっと続けてきました。
最近いわゆるAI分野に力を入れていますので、サービスで生まれたデータをAIの研究開発に活用し、その成果を新たな価値あるサービスの設計・実装に活かすというようなサイクルを回そうとしています。
AIシステム部のミッション
そんな中で、私の所属しているAIシステム部の役割、とくに分析に関して申し上げますと、やはりサービスの会社なので、「すべてはDeNAのサービスを使ってくださってるカスタマーのために」、というところが根底にあります。
ゲームで遊んでいただいたり、スポーツを観に来てくださったり、その他いろんなサービスをカスタマーに活用していただくために、それらサービスの運営体制の中には、アナリストと呼ばれるデータの分析をメインに行なっている人たちがアサインされています。
対する私たちAIシステム部の分析基盤担当は、そのアナリストさんがいかに容易に自由に分析できるかを軸に、インフラを構築して提供することをミッションとして持っています。
ただ、後ほど申し上げますが、とくにオンプレミスのインフラの構築や運用は、私たちだけでは完結しません。IT基盤部と呼ばれる社内のインフラ部署と連携したり、セキュリティ、例えばデータの扱いが適切かとか、社内のポリシーに合っているかとか、お客さまの迷惑にならないかとか、そういったことを社内のCERTと相談したりして、進めております。
DeNAの分析基盤を俯瞰する
次にそのような組織で構築・運用しているDeNAの分析基盤がシステムとして今どういった構成になっているかをご紹介します。
DeNAの分析基盤の特徴です。
おそらく国内では早い時期に構築された分析基盤の1つではないかと思っており、2010年頃にHadoopによる大規模なデータ分析基盤を構築・運用しはじめました。
そして現在では、あらゆるサービスのログを蓄積し分析することが当たり前になっています。ゲームに限らずサービスの企画・開発当初から、サービス自体の設計と並行してログ設計を行います。
いわゆるETL（Extract, Transform and Load）の部分は社内で定型化されていて、品質を担保した分析が行えるようになっています。例えば、社内向けにログフォーマットが決まっていて、それにのっとってカスタマイズすることで分析しやすくなっています。
ペタバイトクラスのデータ量があり、またサービスや関係部署を合わせて60以上の部署や部門から使われています。ゲームに限らず、BtoC、BtoB、多彩な事業の分析データを扱っています。
こうしたデータは、先ほどの図にもあったアナリストという職種の方が主に使いますが、それ以外の方、例えばビジネス職の方だったり、バックオフィスの方がクエリを投げたりと、社内に多くの利用者がいます。
その分析基盤のシステム構成について紹介させていただきます。
全体の概要を図で描くとこのようになります。スライド左から、「Services」と書いているところが、ゲームやその他いろんなアプリケーションです。アプリケーションサーバーや、後ほどご紹介するDBスナップショットの収集サーバーにFluentd といくつかのパッケージを入れていただいていて、Log Gatewayと呼んでいるサーバーに送ってもらいます。
Log Gatewayで受けたログとデータベースのスナップショットは、Hadoopに蓄積されます。そして、Hadoopに蓄積されたログを、一定周期で真ん中のEmbulkの部分、バルクローダーで、Google BigQueryやHP Verticaに送り込んでいます。それで、右側のダッシュボードを使って、一番右端のアナリスト職の方がクエリを投げて分析する、というのがDeNAの分析基盤の全体概要です。
ServicesとLog Gatewayについて
まずはこのServicesとLog Gatewayについてご紹介させていただきます。
最初はもちろんアプリケーションログとデータベースのスナップショットを集めるんですが、アプリケーションログはアプリケーションサーバーで発生しますので、Fluentd といくつかの内製プラグインを使用して、ログを送ってもらっています。
先ほどの図にありましたLog Gatewayと呼んでいるサーバーに送ってもらいますが、プロトコルはHTTPS POSTを使用しています。これは主に認証をかけたいという理由によります。
次にデータベースのスナップショットなんですけども、こちらもアプリケーションサーバーと同じネットワーク内に、DBスナップショットの収集サーバーを建ててもらい、そこからアプリケーションログと同じくLog Gateway宛にHTTPS POSTしてもらっています。
また、データベースサーバーがオンプレミスの場合は、Apache Sqoopという、Hadoop上でデータベースをなめるミドルウェアを使用してスナップショットを収集するケースもあります。
みなさまお馴染みだと思うFluentdですが、使っていてやはりすごいなと思うのは、ほとんど落ちないというところと、もし落ちても再起動すれば、またログを再送してくれるというところです。
あと、導入時にはやはり社内外の利用者から問い合わせをいただくことはあるんですけども、一旦導入してしまえば、各サービス内で担当エンジニアの方の交代などがあっても特段問い合わせをいただかずに、そのまま順調に運用できているというのもありがたいところです。
またプラグインによって柔軟にカスタマイズできますので、例えば私たちの場合であれば、HTTPSでPOSTしたいとか、そういう場合も非常にやりやすいです。
Fluentd のコンセプトの図に描いてあるとおりですが、やっぱりストリームデータのハブとして機能しているので、結果いろんなアーキテクチャを考えたり、いろんなミドルウェアを見ても、わるい意味ではなくむしろ良い意味で、「Fluentdでいいよね」という結論にたどり着くような、優れたアーキテクチャだなと感じています。
貯めたログをクエリエンジンへ送る
次にLog Gatewayで受けてからHadoopに格納するところまでを、紹介させていただきます。
まず2018年現在、Hadoopを私たちは主にデータレイクとして使っていて、実はあまりクエリを投げていません。なのでHDFS部分がメインになります。ただしHiveQLを使っているサービスや人もまだいますので、そういった方のためにHueを提供していたりして。なので、「バージョンアップつらいな」とか、そういう気持ちになることがあります。
Log Gatewayに集まったログをHDFSに書き込むんですが、その際にいくつかのことをやっています。1つは、全社共通の受け口で受けていますので、サービスごとに分けて、異なるHDFSパスだったり、Hadoopのクラスタを選んだり、そういう機能を持たせています。また、ログが重複してしまうことがありますので、重複を排除するようなロジックを仕込んでいます。
次にHDFSに貯めたログをクエリエンジン、BigQueryやVerticaに送る部分について、紹介させていただきます。
これもまた現在と過去の話がありますが、現在はクエリエンジンとしてGoogle BigQueryを全社的に推奨しています。BigQueryは最近のサービスですので、その前どうしていたかというと、2013年頃はHP Verticaというクエリエンジンを導入して使っていました。Verticaを使っているサービスは、現在は順次良いタイミングでBigQueryへの移行を進めています。
“移行してます”と書いてしまうと1行なんですけど、やはりけっこう大変なところがあって。例えばゲームのサービスなんかを思い浮かべていただくとわかりやすいかもしれませんが、分析ができてさえいれば、クエリエンジンを気にする人はそんなにいなくてですね。
そうすると、やはり「なんでわざわざBigQueryに移さなきゃいけないんだ」みたいな気持ちになりがちですね。そういった時に、「すいませんがクエリを書き換えて、BigQueryに移してください」と言うのはとても難しい部分があり、そこが非常に調整が発生する部分であったりもします。
VerticaとBigQueryの違い
VerticaとBigQueryの違いとして、クエリそのものの違いとはまた別に、ライセンス・料金体系にも違いがあります。BigQueryはご存知のとおり従量課金ですが、Verticaというのは容量ライセンスを買い切るタイプの料金体系です。
なので、例えば1テラ分の容量を買って、そこに500ギガしかログがなかったとしても、1テラ分のお金がかかります。逆に1.1テラになってしまったら、もう1テラ買い足さなくちゃいけないといった料金体系なんですね。それで、当社ではスケールで悩むこともありました。
2013年にVerticaを導入するまではどうしていたかというと、HiveQLがメインでした。Hadoop自体は何度かのバージョンアップを経ていますが、基盤のバージョンアップというのは、先ほどの（Treasure Data佐々木さんの）お話にもあったとおり、かなり大変でですね。とくにオンプレミスでHadoopクラスタを構築して運用していると、データのバックアップを取るというのが現実的に難しいという状況があります。
ペタバイトクラスのデータのバックアップを取るためには、同じ数のサーバーを用意して、結局同じ規模のHadoopクラスタなり、分散ストレージのクラスタを用意しなくちゃいけないんですけど、それは現実的ではないので、どうしても一部をエイヤッとやってしまう部分が発生しがちです。それはとてもリスキーですし、基盤の利用者の方にも長いメンテ時間を我慢していただく必要が生じるので、非常に悩ましいところです。
それで、先ほどのお話にあったように、ストレージのレイヤーと、その上のミドルウェアあるいはアプリケーションレイヤーを、きれいに分けることができると理想的だと思うんですが、そうするとS3のようなオブジェクトストレージを使いたくなりますね。ここがオンプレミスのHadoopの悩ましいところの1つと感じています。
内製したバルクロードツール「Medjed」でできること
次に、内製のバルクロードツール。「Medjed」という名前をつけていますが、こちらをご紹介します。こちらはHDFSからBigQueryやVerticaにデータを転送するツールです。中身は何かといいますと、実はEmbulkとEmbulkを管理するWebアプリケーションです。
Embulkを使われている方はご存知の通り、Embulkは設定をYAMLで書きますので、エンジニアにとってはやさしいんです。しかしアナリスト職やビジネス職の方にとっては、YAMLを理解していただくというハードルがあります。
そのハードルを解消するために、Excel文化みたいで恐縮ですが、Googleスプレッドシートに定義を書いてもらうと、YAMLが実行時に生成されるというような仕組みを（“Medjed”の機能として）持ってます。
この仕組みにすることで、アナリスト職の方やエンジニアではない方がスキーマを定義できるようになり、さらに、Googleスプレッドシートベースではありますがスキーマ管理が行えるようになるというメリットが生じます。
あとは、Embulk自体も複数のワーカーノードで、それぞれ並行して動かすような仕組みになっていますので、スケールがしやすくなります。
画面をスクリーンショットでご紹介したいんですが、こういったWeb UIを社内向けに提供しています。
この（Web UI上の）タスクというのが、Embulkのジョブを1つ実行するとイメージしてください。タスクをデイリーやhourlyで自動実行したり、Web UIからリトライや手動実行ができます。
こちらの画像がスキーマ定義に使っているスプレッドシートのサンプルです。モザイクが多くて恐縮ですが、こういった感じで、もとのスキーマと送り先のスキーマを定義できます。
Embulkについては、やはりFluentd のようなプラグインアーキテクチャで非常に便利だなと感じております。
このスライド上の3つのリンクがのうち一番上のリポジトリに、社内でつくったEmbulk関係のリポジトリが集まっています。いろいろプラグインを開発したり、OSSで公開されているものを使わせていただくことで、自由自在にいろいろなデータソースやクエリエンジンを読み書きできるのがメリットだと思います。
あと、前のページで触れたとおり設定をYAMLで書けますのでエンジニアにはやさしいですね。ただ、アナリストの方にはあまりやさしくないので、そこはWeb UIとGoogleスプレッドシートでがんばっています。
柔軟な対応ができる内製ダッシュボード
バルクロードまでご紹介しましたので、次にクエリエンジンとダッシュボードのところについて、説明させていただきます。
ダッシュボードも2014年頃から内製してまして、「Argus」という名前をつけています。現在対応しているクエリエンジンは、社内で使われているGoogle BigQueryとHP Verticaです。
最近はOSSからプロプライエタリなものまで多くのダッシュボードがあり、Web UIからクエリを実行して結果を表示することができますが、Argusも同様にクエリを書いてグラフ等を表示できるダッシュボードです。
内製のメリットとしては、細かな要望に素早く対応できることがあります。直近のリリースサイクルを見てきましたが、2018年現在でも週に数回程度はリリースが行われています。
また他の機能として、社内に合わせた細かな権限管理を行えるようになっています。これは先ほどご紹介したMedjedも共通です。DeNAでは他の多くの企業様と同様、認証基盤としてActive Directoryを導入していまして、そのActive Directoryのグループに合わせた管理・編集・閲覧それぞれの権限を付与できます。
こちらの画面では、実際にお見せできなくて申しわけないのですが、様々な粒度のレポートや、それらレポートを束ねたプロジェクトという単位のグループがあります。右側のほうにクエリを書いて、Web UI上の実行ボタンを押すと、クエリが実行されます。
実行するとこのスクリーンショットのように、グラフが出たり、表が出たりします。
このように使用感は普通のダッシュボードと大きくは変わらないんですが、権限管理やグルーピングなどのかゆいところに手が届くのがポイントです。
ジョブスケジューラーについて
最後にジョブスケジューラーとWorkstationについて説明させていただきます。
ジョブスケジューラーはJenkinsを使用しています。けっこう長く使っていて、アナリストの方が慣れていたり、使いやすいというのが使い続けている理由です。また、Jenkinsを使われている方はご存知だと思いますが、いろんなことができてしまうので、なかなか他のツールに移行しづらいというのもあります。例えば権限管理もプラグインを入れるとかなり柔軟に対応できて、社内のおおよそのことがまかなえています。
ただ正直、運用はけっこう大変なので、いいジョブスケジューラーがないかなと日々探してはいます。
さらに、Web UI、つまりJenkinsで完結しない業務のために、LinuxのWorkstationも提供しています。こちらは普通のLinuxサーバーで、アナリストの方がSSHでログインして使用します。
このWorkstationは元々は使っていたんですけど、最近はやはりBigQueryを叩いたり、Pythonスクリプトの開発に使われるケースが増えてきました。
ジョブスケジューラーといえばDigdagですが、なかなか魅力的なミドルウェアだなと思って検討しています。魅力的に感じるポイント、導入したいポイントは、やはりEmbulkと同じくYAMLで書けること、それから、ワークフローをコードで管理できることです。
さらにDigdagはYAMLだけではなくて、Shell、Ruby、Pythonのスクリプトも扱えます。これによってワークフローやタスクを自由度高く書けますので、条件分岐したり、依存関係を表したり、繰り返しを表現したり、おおよそのことができるなと感じています。 また、設定をすべてPostgreSQLに持つため、HA構成やスケールアウトが、非常に容易という印象を持っています。
ここまで書くと導入できそうな気持ちになってきますが、ただ、権限管理が現状ほぼないので、ここをどうにかできればきっと導入できるんではないかなと思っています。
