一言で言うと非常にエキサイティング　LINEのDMP開発チームで大規模データを扱う楽しさ

LINE DMPとはなにか

渡邉直樹氏：私からは、LINE DMPというサービスについて紹介いたします。最初に自己紹介を簡単にします。私は渡邉直樹と申します。先ほど発表にあったCRSっていうサービスと、これから紹介するLINE DMPを開発しているチームのマネージャーをしています。

けっこう社歴は長くて、今までBtoCのサービスを中心に開発してきましたが、ここ数年はBtoBのサービス開発に携わっています。趣味は書いてあるとおり、料理とスプラトゥーンです。僕の最近の悩みは、スプラトゥーンの腕前がさっぱり上がらないことです。あ、そういう話は別にいいですね。はい。

今日はこんな感じで話を進めていこうと思います。まずは、LINE DMPがどんなサービスなのかを簡単に紹介しつつ、技術的な構成や、どんなおもしろさがあるのかをさらっと紹介したのちに、どんな人が開発に向いているのかみたいな話をしていきたいと思います。

まずLINE DMPとは何ぞやという話なのですがこのDMPという用語、わりと一般的に使われるシステムの名称でして、Data Management Platform、この頭文字を取ってDMPと言います。これ、名前からするとちょっとモヤっとしますが、大事なのは具体的にどんなデータをマネージしているのかという話です。

主にLINE DMPでは、ユーザーに関する情報を扱っています。BtoBではどんな情報を誰に出すかが非常に大事なのですが、このDMPでは、誰に出すかという部分を主に扱っています。

具体的に言うと、LINEのユーザーの推定情報や、あとはLINEサービスの利用履歴など。今日紹介した中で言うと、LINE公式アカウントでみなさんがどんなアカウントと友だちになっているかといった情報をもっています。

あとは企業が独自に持っている顧客リストであるとか。LINE Tagと呼ばれる、これはJavaScriptで書かれていますが、これをWebページに設置すると、コンバージョンのイベントや訪問などのイベントを送ってきます。

また、LINEのユーザーはたくさんいますが、全ユーザーの中からこれらの複数のリストのユーザーに似ているユーザーを探してくる。類似ユーザー拡張なんていう機能もあります。こういった、さまざまなリストを扱っているサービスです。

個人情報保護の流れを最大限に尊重しつつ、できることはなにか

しかしながら最近世の中では、個人情報保護の流れがすごく強まってきています。GDPRやCCPAみたいな法律や規則による規制。Appleが最近推し進めているIntelligent Tracking Preventionなど。

あと、今iOS14などで話題になっていますけど、AppTrackingTransparencyみたいなもの。またはGoogleが提唱しているPrivacy Sandboxなど。すごくいろいろあって、僕らも困っちゃうくらいにたくさんあります。

こういうものがある中で、DMPの役割としては、個人情報保護の流れを最大限に尊重しつつ、効率のいいターゲティングを提供することで、企業とユーザーの良質な接点を作るのがミッションになります。これは技術だけじゃなくて、世の中のトレンドであるとか、法律の解釈、あとはポリシーといったものも考えていかないといけなかったりします。

このLINE DMPのLINE内における重要性ですが、非常に重要なプロジェクトの1つです。なぜかと言うと、LINEにはBtoBのプラットフォームがいくつもあります。今日紹介されていたところで言うとLINE広告とか、LINE公式アカウント、LINEセールスプロモーションなどです。ほかにもいくつかあります。

企業はこれらのさまざまなプラットフォームを使って、いろいろなマーケティングができます。ただ、今までこの複数のプラットフォームは独立してデータをもっていて、共有できませんでした。使う側からするとちょっとやりづらい、かつ非常にもったいない状態だったと思います。

そこで、LINE DMPが中央に入ることによって、データを相互活用できるようになり、複数のプラットフォームを使っていてもデータを共有し、効率のいいマーケティングができるようになります。

我々はこれをクロスプラットフォームと呼んでいて、去年あたりからかなりのリソースをかけて開発しています。ちょっと話が抽象的でわかりづかったと思うので、簡単な例をいくつか挙げたいと思います。

LINE公式アカウントとLINE広告、2つのプラットフォームでデータを活用するケースを想定してみます。LINE公式アカウントでは、ユーザーにメッセージを送信すると、誰がメッセージを見てくれたかとか、そのメッセージの中にあるリンクを誰がクリックしてくれたかといった情報をもっています。

これらを使って、メッセージを開封したユーザーをターゲットにして、メッセージ内のリンクをクリックしてくれたユーザーを除外配信に設定して広告を配信します。こうすると、公式アカウントのメッセージは見てくれたけど、クリックまでは至らなかったユーザーに対して、もう一押しのアプローチができます。

かつ、すでにクリックしたユーザーには除外配信で出ないようになっているので、何度も何度も同じ情報をプッシュすることなく、効率的にプロモーションできます。

また、ほかの例を挙げると、LINE公式アカウントには友だちになってくれた経路別のユーザーリストというのがあります。このリストに含まれるユーザーと似ている人をLINE全体のユーザーの中から探してきて、広告配信対象にできます。つまり、すでにもう使ってくれているユーザーに似ている人たちを新規ユーザーとしてアプローチできるので、非常に効率的です。

ここに挙げているのは一例なので、ほかにもいろいろなデータがあって、いろいろな組み合わせができるのですが。ここですごく大事なこととしては、これらのデータはあくまでも社内で使っているデータで、外に出ることがありません。

先ほど言ったとおり、ユーザーの個人情報が大事だと言われている昨今では、外に漏れることがないように配慮されて運用されているので、個人情報保護の流れを守りながらプロモーションできるのが大きいです。

このクロスプラットフォーム、今後まだまだ機能追加予定で、非常に活発に開発しているプロジェクトです。また、今後ビジネス的にも非常に重要なものだと我々は考えています。

LINE DMPのアーキテクチャ

難しい話はこれくらいにして、もうちょっと技術的な話をしたいと思います。非常に簡略して書きますが、雰囲気を掴んでもらうようにと思って、アーキテクチャをさらっと説明します。

LINE DMPは、基本的にデータを集めてきて、ほかのサービスに必要なときにデータを提供するのが役割ですが、まずデータを集めてくるところも、けっこういろいろ経路があります。

まず、社内共通のHadoopクラスタにあるデータをバッチ的にもってくるケースです。2つ目は、例えばLINE広告やのCMSから、広告主が顧客リストをアップロードするケースです。これは、APIでオンデマンドに送られてくるケースです。

3つ目、これはLINE TagみたいなWebサイトに設置されているところから、イベントログがリアルタイムで送られてくるケースです。これは、Kafka経由のストリーミングデータで送られてきたりします。

こういうデータをDMPは、いったんHBaseやRedisに保存しておいて、ほかのサービスが必要なタイミングでAPIで返したり、Kafka経由でストリーミングデータとして提供したりします。こういう連携がたくさんあると思ってください。

実装ですが、言語はほぼJavaで、フレームワークはSpring Boot 2です。今日紹介されてきたプロジェクトとだいたい同じですが、特徴的なところで言うと、HBaseをハードで使っていてデータ量がものすごくあるということと、あと大量データにいろいろな加工をしたりするので、Apache Sparkを一部使っていたりします。

秒間40万のリクエストが流れてくる

最後にサービスの規模がわかりそうな数値をいくつかもってきました。まず1個目は2000億。これ、何だと思いますか？　実はこれはHBaseにあるRowの数です。この数は、社内でもかなり多いほうなんじゃないかなと思います。

真ん中の450は、これはサーバー台数ですね。VMが250台くらいで、PM、物理マシンが200台くらいあります。最後にあるのが40万。これは40万rpsです。

さきほどアーキテクチャの中でも紹介したように、ストリーミング型のデータもけっこう増えてきています。これが最大風速というか、秒間40万リクエストが瞬間最大風速になっています。ずっとこれが流れ込んできているわけじゃなく、瞬間的なものですが、なかなかハードな数値になっていると思います。

一言で言うと非常にエキサイティング

DMPの開発ってどんな感じでやっているんですか、という紹介に移ります。一言で言うと……まあ一言というか、スライドで見てもらっているような感じですね。非常にエキサイティングであることが伝わるんじゃないかなと思います。

あ、「ちょっとこれつらそう！」みたいに見えちゃうかもしれないので、楽しいところも紹介していきますね。DMPを開発してきて楽しいところは、まずエンジニアとしてはめちゃめちゃデータが多くて、システムの規模が大きいというところで、非常にやり応えがあるかなと思っています。

データが多すぎて、弊社の中でも一般的にこう作ったらだいたいうまくいくよねみたいな王道パターンがありますが、DMPにおいてはわりと通用しないことも多いです。うっかり作ると、バッチが数日かかっても終わらない！　みたいなこともけっこうあって、実装上の工夫が必要だったりします。

データが多いから並列数を上げて分散処理！　みたいなことだけ考えていると、どっかに影響して何かが壊れたりします。非常に怖いですが、楽しいところでもあります。

最後、これすごく大事なのですが、がんばって開発してきたものがBtoBのプラットフォームですから、ダイレクトにビジネスに影響してきます。売上はもちろん、企業のキャンペーンの成果、CTRとかCVRが上がったとか。LINE公式アカウントで言うと、友だちが増えたみたいなやつがわかりやすいかたちで、データとして出てきます。

とは言っても、このデータを出すのも僕たちで、このデータを出すためにはやっぱり巨大なデータに立ち向かう必要があります。非常にモチベーションにつながるようなデータになっています。

そんなプロジェクトの中で、エンジニアとして何をする必要があるのかという話に移ります。一般的に、システム開発ってこんなサイクルをグルグル回す感じだと思いますが、みなさんはエンジニアの職域ってどのあたりだと思いますか？　っていう話を今日はしようかと思っていましたが、今日の樋村さんの話でこのあたりが出てしまいましたね。

LINEにおいては、これの全部が対象になると思っています。もちろん企画は、企画を担当するチームがいて、PMがいるのですが。とくにこういうLINE DMPみたいな開発って、世の中の技術的なトレンドや規制もけっこう多いので、ポリシーなんかも加味する必要があります。

なので、企画だけでやるより、開発のメンバーとかも一緒に入って、企画から一緒に議論していく。要件定義をして、すぐさま開発に移っていくというところが非常に大事です。

最後に、開発にどんな人が向いているのかという話で締めくくりたいと思います。まず、大規模データを使ってビジネスに活用したい人には向いているんじゃないかなと思います。やっぱり、ビッグデータとかって、エンジニアだと興味がある方も多いんじゃないかなと思います。非常にでっかい、ビッグなデータがここにあるので、ぜひ来てください。

最近バッチだけじゃなくて、リアルタイムの処理なんかも非常に多いので、こういったパイプラインを作るのもなかなか楽しいです。サーバーサイドのエンジニアだと、トラフィックが大きいサービスがやりたい！　なんて人も非常に多いますが、トラフィックもなかなかすごいものがあります。なので、このあたりも工夫しなくちゃいけないと思っています。

最後にやっぱりこれですね。パフォーマンスチューニング。うっかり作って、バッチが3日間かかっちゃうっていう処理をどうやって1日以内に収めるかみたいなことが、ちょこちょこあります。もちろん並列数を上げるだけで解決できないこともけっこうあって、データの持ち方であるとか、処理の順番とか、そういったものを工夫していくのが非常に楽しいです。

今挙げてきたこの3つの中で、どれか1つでも該当するのであれば、非常に向いているんじゃないかなって僕は思っています。ぜひ検討してみてください。応募をお待ちしています！