LINE DMPというプロダクト
加賀谷北斗氏（以下、加賀谷）：私からは「LINE DMPにおけるサーバーサイド開発」と題して、DMPというプロダクトにおけるサーバーサイドエンジニアの役割、おもしろさみたいなところについてお話ししたいと思います。よろしくお願いします。
まず自己紹介をしたいと思います。今の松田さんと一緒なのですが、開発4センター Official Account 開発室の Business Data Platform 開発チームで、サーバーサイドエンジニアをやっている加賀谷北斗と言います。
この会社には、2016年に新卒で入社しました。入社前は機械学習の応用に関しての研究をやっていて、Preferred Networks社でインターンシップなどを経験して、この会社に入りました。入社後は、2019年9月までLINE GAMEのプラットフォームを開発する部署にいまして、そこでサーバーサイドエンジニアや開発リードを経験しました。
その後、2019年10月に現在の部署に移動しまして、LINE DMPというプロダクトに関わるサーバーサイドの開発を幅広く担当しています。ちなみに好きなミドルウェアはElasticsearchで、過去のLINE DEVELOPER DAYなどでも、何度もElasticsearchに関する発表をしています。
あとはコロナ禍になって、おうち時間が増えたので、最近はコーヒーを入れることにハマっています。
それではまず、LINE DMPというプロダクトの紹介から入っていきたいと思います。みなさん、「LINE」と聞くとB2C、いわゆる一般のお客さま向けのサービスを思い浮かべる人も多いんじゃないかなと思いますが、今日すでにいくつか発表があったように、B2Bのプロダクトもいっぱいあります。
1つ前の話で出たLINE公式アカウントだったり、このあと話があるLINE広告だったり、あとはLINEポイントといわれるポイントサービスとなどが主に挙げられるかなと思います。
そんな中で、LINE DMPというプロダクトもB2Bプロダクトの1つになっています。まずDMPというのは、Data Management Platformの略称です。これは特に社内用語とかではなくて、Web広告の文脈で一般に使われている単語になります。
どんなプロダクトかという話なのですが、基本的には外部からアップロードされた、あるいはLINEのサービス内で得られたさまざまな情報受け取ってきて、よしなにETLして、先ほど出てきたプロダクトを始めとしたLINEのB2Bサービスを通じて、顧客のみなさんが有効に活用できるようにすること。ざっくり言うと、これがLINE DMPのプロダクトがやっていることです。
ここで少しちょっと注意していただきたいのは、LINE DMPはDMPの中でもPrivate DMPと呼ばれるもので、データの活用はLINEの中に閉じているということです。
しかしこれだけだと、具体的に何をやっているかわからないという話もあると思うので、もう少しだけ、どんなことをやっているのかを次のスライドでブレイクダウンしていきたいと思います。
LINE DMPのプロダクトがやっていること
まず情報を集めてくるというフェーズです。ここでは、広告のクリックであったり、先ほどのLINE公式アカウントのメッセージをクリックしたという情報であったり、あとはWebサイトを訪問したよという情報であったりというところの、さまざまなデータをLINEのB2Bプロダクトを通じて収集します。これはWebのAPIで受け取ったりJavaScriptのタグを提供していたりします。
次のフェーズですが、それを必要なかたちに加工していきます。このフェーズがDMPの肝になってきます。ここでは、Kafkaなどを使ったストリーミング処理やスケジュール実行される巨大なバッチ処理なんかをもっています。そして最後には、B2Bプロダクトのところにターゲティング情報を始めとしたデータのかたちで、フィードバックして活用できるようにしていきます。
こちらもAPIを経由して提供したり、必要に応じてKafkaを通じて連携したりしています。こういった感じで、とにかくデータそのものが主役になるプロダクトになっています。
なのですが一方で、AppleやGoogleといった2大プラットフォームの最近の施策であったり、日本を含めた各国の法律にも出ているように、個人情報の保護というのが、今社会の最重要課題の1つになっています。ここにもありますが、サードパーティクッキーに対して強い規制が入るようになってきていたり、いわゆるコンバージョンの計測にも、すごく影響が出てきています。
そのため、データを活用する場においても、いかに個人情報を守りつつも有効なマーケティングを行っていくかが大事な観点になっていきます。そのため弊社としては、現在LINEが持っているデータをLINEのサービス内で最大限活用していくニーズが、どんどん高まってきているという状況です。
それに対する私たちの1つの答えとして、LINE広告やLINE公式アカウントといったB2Bサービスのアカウントを相互に接続してデータを活用していく、という仕組みを構築しています。この新しいデータ活用基盤をBusiness Managerと呼んでいまして、2020年7月現在、鋭意開発中となっています。
これによって、各サービスで溜めたデータのシームレスな相互活用、権限管理の統合、プロダクト横断のデータ分析などが可能になります。
LINE DMP開発におけるサーバーサイドの技術スタック
さてここからは、LINE DMP開発におけるサーバーサイドエンジニアはいったいどういうものなのかについて、もう少し話していきたいと思います。まずいわゆるテックスタックですね。先ほどから何度も似たようなスライドが出てきていて、もしかしたら見飽きている方もいるかもしれませんが、特に一般的なWeb開発と比較して、DMPの開発に特徴がありそうなところに、下線を引いています。
まず上から。DBの部分ではHBase、RedisといったNoSQLをかなり多用しています。これはやはりデータが主役のプロダクトなので、性能やスケーラビリティに対する要求が非常にシビアになってくるためです。
次にミドルウェアでいうと、Kafkaによるストリーミング処理がすごく多くて、あるところからデータを受け取って、何らかの加工をしてまた次のところに流すような処理が非常に多くて、アプリケーション単位でいうと、本当に数十個ものKafkaコンシューマのアプリがいるかたちになっています。
言語、Webフレームワーク、プロビジョニング、モニタリングなどは、たぶんだいたいのチームが一緒で、Java11の上でSpring Bootのアプリを書いて、Ansible、Jenkinsでプロビジョニング、デプロイをして、Prometheus、Grafanaでモニタリングするようなスタックになっています。
その次のデータ解析と書いてあるところは、もちろん専門のこういったデータの分析を別途するチームもありますが、私たちの場合、そもそもデータを多く扱っているので、SQLを使ってアドホックな解析をしたり、アラーティングを行ったりするためにマネージドな社内データウェアハウスがあったりするので、それに対してPresto、Spark、Hiveといったツールを使ってクエリするといったことも、かなり多くなっています。
その他の部分に関しては、GitHub Enterpriseを使っていたり、Slackでコミュニケーションしたりしています。
おもしろいところ① 扱うデータの膨大さ
続いてどんなところがおもしろいかについて、話していきたいと思います。ソフトウェアエンジニアにとっては、やはり難しさというのが≒（ニアリーイコール）でおもしろさだったりするかなと思うので、LINE DMPの難しさとも言い換えられるかもしれません。
個人的には、DMPは1粒で2度おいしいプロダクトだと思っています。何と何かというと、1つは技術的なところで、膨大なデータ量との戦いです。もう1つは、難解なビジネス要求とそれに関わってくるコミュニケーションの部分です。このあと、それぞれについて少しずつ見ていこうと思います。
1つ目は、「扱うデータの膨大さ」というところ。ものすごく大きなトラフィック、あるいは累積データを扱うことになるプロダクトです。単純にそれを処理すると、現実的なコストで処理できない場合も出てくるので、ちょっといろいろ工夫をしないといけないところですね。少し数字で見ていくと、まずデータのメインストレージとしては、先ほど少し話しましたがHBaseを使っていて、これはメインのデータで2,000億を超えるレコード数があります。
またWebのタグやモバイルアプリからのイベントを受ける部分を始めとして、外部からのリクエストに関しては、ピーク時で5万RPSを超えています。またサーバーの数としても全体で500を超えていまして、1つ特徴的なのは、物理サーバーも多く持っているというところです。これはやはりデータを多く扱う関係上、インメモリデータベースであるRedisを始めとしたNoSQLのDBサーバーを置くために多く使われています。
データの膨大さが垣間見えるプロジェクトの例を1つ紹介します。B2Bのプロダクトの1つに、先ほどお話したLINE広告があります。以前、LINEのDeveloper Meetupでも紹介しましたが、LINE広告のリーチを推定する機能があります。これは、DMPで持つデータから、ある広告が最大どれくらいユーザーにリーチできるか、リーチするのかを推定するものです。
先ほどLINE DMPは、各プロダクトに対してターゲティングに関する情報などを提供するという話をしましたが、この機能は実際の広告配信の前に、今の設定だとどのくらいのユーザーに届くのか、ある程度あたりを付けておくものと思ってもらえればいいかなと思います。やはりLINEユーザーはとても多くて、何千万というオーダーですから、単純に処理するのは、コスト的にもレスポンスタイムが悪くなったりするので、UXを考えても難しいというところになります。
そのため、適切なデータのサンプリングであったり、ここではElasticsearch……、さきほどからElasticsearchをいっぱい使っていますが（笑）、適切なストレージの選定であったり実際のメインのストレージから、Elasticsearchへのデータシンクの方法の吟味なども、必要になってきます。
少し右のほうに、小さいですがアーキテクチャ図を載せていますが、Elasticsearchに対してデータソースもいっぱいあるので、いろいろなデータソースから適切なかたちでシンクして、APIを通じてLINE広告に提供するかたちになっています。
今日は深く話すことはできませんが、以前の発表のログミー記事のURLを貼っているので、そちらに興味のある方は参照していただければと思います。
おもしろいところ② 難解なビジネス要求とそれに伴う多くの部署との協業
もう1つおもしろさのところで、難解なビジネス要求とそれに伴う多くの部署との協業も、個人的にはチャレンジングでもあり楽しさでもある点かなと思っています。それも、私たちの普段のワークフローを紹介しながら、見ていきたいと思います。
まず企画の段階ですね。ここでは、ニーズの洗い出しであったり仕様の検討であったりを、プロダクトの企画チームであったりビジネスの企画のチームとやったり、直接コミュニケーションを取りながら協業をしています。DMPの場合だと「ただ何か新しい機能をどんどん作っていくぞ！」だけではなくて。もちろんそれも重要なのですが。
先ほど出てきた個人情報保護も含めて、さまざまな制約を守りながらやっていく必要があるので、仕様そのものが難解になりがちです。そのため、サーバーサイドエンジニアも、この段階からガッツリと議論に参加していきます。また場合によっては、新しい機能であったり既存の機能もそうですが、法律や社内のルールに対して問題ないかを、情報セキュリティを担う部署と議論することもあります。
いろいろチェックをクリアして、いよいよ開発ですが、ここでもプロダクトとデータのやり取りをするプロダクトの性質上、チームの企画、開発チームだったりフロントエンドのエンジニアのチームとも協業していきます。そのあとは、リリースの環境構築やリリースチェックですが、ここはLINEの一般的なフローに乗っかっていて、インフラエンジニアであったりデータベースのエンジニアなどのチームとコミュニケーションを取りながら進めていきます。セキュリティチェックも同様です。
最後のQAのセクションでは、仕様を満たしているかどうかのチェックを行っていきます。ここでも、データを使った実際の機能が出ていくのは他のプロダクトだったりするので、ここで例として出したのは、LINE広告やLINE公式アカウントですが、こういったチームの開発やQAのチームとも深くコミュニケーションしていきます。
このように、開発しながらもさまざまなコミュニケーションを取る機会があります。またそれに伴って、技術に限らないさまざまな分野の知識を学ぶ機会もあります。情報セキュリティのところで話したように、そういったやり取りに伴って触れることがある法律関係。ここはとくに、わかりやすいポイントかなと思っています。
さまざまな分野の新しい知識との邂逅、出会いを楽しめるという方が向いている
では最後に、自分が思うこんな人と働きたいというところを紹介して、まとめの代わりにしたいと思います。まずは、やはりデータが膨大なので、そんな大量のデータを使ったサービスビジネスの課題解決に取り組みたい方は、向いているんじゃないかなと思います。それから、ビジネス要求がそもそも複雑なので、たくさんのチームとコミュニケーションを取りながらしていく開発が好きな方は、ぜひジョインしていただきたいなと思います。
最後に、先ほども話したとおり、技術だけではなくて同業他社、あるいは業界の動向や、法律といったさまざまな分野の新しい知識との邂逅、出会いを楽しめるという方は、まさにLINE DMPのサーバーサイドエンジニアとしてフィットするんじゃないかなと思います。
ということで私の発表は以上になります。みなさんとご一緒に働くことを楽しみにしています。ご清聴ありがとうございました。
