2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
機械学習開発部門(Machine Learning室) サーバーサイドエンジニアの仕事ご紹介(全1記事)
提供:LINE株式会社
リンクをコピー
記事をブックマーク
大東哲平氏(以下、大東):大東です。よろしくお願いします。Data Scienceセンターという部門の中のMachine Learning Infrastructureチームに所属しています。
こちらがLINEの各サービスになりますが、この中で比較的データ量が多いところを担当していることが多いです。
これがLINEのアプリの5つのタブですが、だいたいこのようなところに機械学習が使われています。こちらはすべてがMachine Learning室の担当ではなく、社内の各組織で分担しています。
こちらがデータの流れです。私たちのチームが担当する部分は、この青い部分になります。他のチームが運用しているHadoop上でデータを処理することが多いです。
ログはクライアントやサーバーから流れてきますが、ログ以外のコンテンツも処理して、最終的に推薦したり、なんらかの出力をしています。
例えばLINEスタンプだと、使ったことがある人も多いかと思いますが、こちらの四角で囲った部分が、Machine Learning室で出力したものになります。
また、スタンプを送る時に、どのようなスタンプを使うかが提案されると思いますが、この部分にも関わっています。それ以外にも、A/Bテストを行うためのツールなどを作ったりしています。
Machine Learning Infrastructureチームは、実際先ほどの組織図の中の機械学習チームになりますが、その中で機械学習を行わないで、こういったツールを作ったり、あと実際に環境を整備することが仕事になっていて、機械学習自体は行っていません。
大東:こちらが求める人物像です。大きなJobをGPUやCPUノードを複数台使って、お互い通信しながら長い時間計算するので、これらを安定して動かすクラスタを構築することが仕事になります。
ミドルウェアやKernelを試して、どうしてこれを選んだのかを明確に説明できて、そしてそれを必要に応じて直す能力。あとはそれらを便利にするツールを作ったり、継続的に改善していくことが非常に重要になります。最終的には、機械学習エンジニアに便利な環境を提供し続けて、そしてセキュリティを担保することが目標になります。
別のケースですが、こちらはMesosというミドルウェアからKubernetesに移行してきたばかりなので、まだ未実装のものが多くて、たくさん準備していかなきゃいけないところです。
機械学習エンジニアは、自由にモデリングがしたい。サーバーサイドエンジニアとだいぶ見ている部分が違うのですが、私たちとしても、最大限自由にさせてあげたいので、そのための環境を作っていく必要があります。
先ほどのA/Bテストの画面で、推薦結果を可視化するツールがありますが、こちらは計算結果に対してすぐデモを表示するような機能を持っています。こういったツールを作ったりして、結果をより早く、またサービスに対してすぐ提供できるように、見せられるようにするような機能も準備しています。あるいは再現性や安全性といったものを担保して、適切に表示していくなどといったことが求められます。
あとは、GPUノード1つで動くような小さなJobではないので、ドライバから複数のノードにソースを送りつけて実行するライブラリなども提供しています。
またそういったものを作って、Jupyter上でGPUノード上でそのまま試すのではなく、そういったツールを使うことによってどこででもGPUを使えるようになるので、非常に利便性を感じてもらっており、移植しやすいものも出てくるんじゃないかなと思います。
今はDevOpsエンジニアとサーバーサイドエンジニアを募集していますが、こちらはサーバーサイドエンジニアで、APIを作るのが仕事になります。
レスポンスはミリ秒で。例えば秒間5,000リクエストぐらい捌けるものを10台ぐらい並べて捌くものから、1リクエストに対して24時間計算し続けて、その結果を返すものもあります。
24時間ですと、たいていはキューに入れて、最終的に結果をコールバックしたり、あるいは別のキューに入れて相手に更新してもらったりすることになると思うんですけれども。そういったものを適切に実装する能力が必要になります。
また、APIをHTTPで提供するのではなく、UDFなどでSQLから叩けるようなものにして提供することで、多くの方が使えるのも、非常にいいと思います。
こちらに必要な能力は、スループットやレスポンス速度をよく見てボトルネックを特定したり、キューを使って適切にバランシングしたりする能力と、他にはあんまりto Cではないですが、この時間帯には落ちますということを利用者と話し合って決めて、適切なダウンタイムを設定したり。
また、ここにコールバックとありますが、もし仮にAPIが落ちた場合にどういった出力を返すか。例えば前日分で返したり、全体に対してある程度許されそうな結果を返すなど、そういったものを策定するのも必要になります。
それ以外にも、機械学習エンジニア自身に使ってもらうAPIでしたら、モデルとパラメーターを直接渡したり、サービスエンジニアであればログのスキーマを渡してもらえればそれに合わせて出力したり、サービス企画者であれば先ほどのUDFなどの利用を想定して、どういったものが便利かを自分で考えて提案して構築していくことが仕事になります。
これが一番重要なことですが、他のすべてにも関係するもので、監視項目とかアラートもすべてGitで管理されています。こちらのアラートはモデルの精度もあるので、監視項目とアラート方法を準備して、機械学習エンジニアに書いてもらうというケースも多いです。それ以外にも、もちろんクラスタやAPI自体の監視も必要になってきます。
こちらが使われている技術関連です。以上です。
司会者:はい、ありがとうございます。樋村さん、続いてお願いします。
樋村隆弘氏(以下、樋村):DSP MLチームのマネージャーを務めています樋村と申します。私からは、DSP MLチームについて簡単に紹介したいと思います。よろしくお願いいたします。
DSP MLチームですが、先ほどの大東さんと同じく、Machine Learning室の下に所属するチームになります。このチームは2020年に発足した比較的新しいチームで、現在メンバーは私を含めて4名が所属しています。
Machine Learning室は、他のチームだと社内の各種サービスに対して機械学習を提供することが多いのですが、DSP MLチームはちょっと異色で、LINE広告という特定のサービスの改善に取り組むチームとなっています。
なのでDSP MLチームのミッションは非常にシンプルでして、機械学習を通じてLINE広告の競争力・利益に貢献するのが、私たちのミッションとなります。
最初に私たちが主に担当しているLINE広告について、簡単に紹介します。LINE広告は、その名の通りLINEに広告を配信するためのプラットフォームです。
LINEアプリの月間アクティブユーザーは、国内で8,800万人を突破しておりまして、国内最大規模の運用型広告プラットフォームになっています。
ここにきているみなさんは、LINEをインストールしたことがある人も多いと思うので、恐らく実際にLINE広告を見たことがあると思います。代表的なものとしては、LINEのトークのトップのヘッダーの部分やニュース面、あとはタイムライン面などがありますが、これらはどちらも非常にトラフィックが多いものになっています。
また、最近はLINEの中だけではなくて、LINEの外の、他社アプリについても広告を配信する「LINE広告ネットワーク」というアドネットワークがありまして、こちらに対しても、私たちが広告を配信できるようになっています。
私たちDSP MLチームでは、広告の機械学習におけるロジックの開発に加えて、サーバーサイドまで見ている、横断型の組織になっています。
樋村:今日はサーバーサイドエンジニアの説明会ということで、サーバーサイドを中心に紹介します。
さっそく広告のサーバーサイドに求められることをちょっと話したいと思います。広告は落ちないのは当然なんですが、広告業界では「50ms or die」という言葉がよく聞かれます。
ご存じの方も非常に多いと思いますが、「50ms or die」っていうのは、現在の広告配信は、リアルタイムビッディングという仕組みで成り立っています。
リアルタイムビッディングは、その名のとおり、広告を表示するタイミングで、リアルタイムで都度広告のリクエストをアプリから送るものです。
したがって、このレスポンスが悪いと、広告の表示のタイミングを逃してしまい、売り上げの毀損につながるといった影響があります。サーバーのレスポンス、パフォーマンス、レイテンシーについては、非常にシビアな運用が求められています。
ということを表して「50ms or die」とよくいわれますが、実際にはこのように、SSPといった広告枠側のプラットフォームや、広告主側のデマンドサイドプラットフォームといった多段構成になってつながっていることが多くて、50msとはいっても、プラットフォームによってはさらに短く20msを要求されることもあるかと思います。LINEの場合は、LINE社内で閉じていますので、50msを目標にがんばっている感じです。
この中で私たちDSP MLチームがどこを担当するかというと、名前のとおりDSP側の機械学習ロジックなどを担当しています。
LINEのDSP開発なんですが、実はもともと韓国側のチームが担当していまして、機械学習のロジックについても、韓国側のチームで行なっていました。2020年に私たちのチームが発足したことで、韓国側のMLチームと私たちが協力して、広告効果の改善に取り組んでいる状態になりました。
DSPには、クリックやコンバージョンを最大化するための予測モデルを始めとして、Auto Biddingといったような、予算ベースコントロールのためのモデルなど、さまざまなモデルが動いています。DSP MLチームでは、これらのモデルの改善や、特徴量の提供を主に行なっています。
先ほどもお話ししたとおり、50ms or dieといったように、DSPは非常にレイテンシーの制約が厳しいので、LINEのDSPのモデル自体は主にFactorization Machine(FM)をベースとした、シンプルなモデルが用いられています。
CVRについても、FM拡張して遅延などを入れたモデルが使われていますが、このあたりは2020年に韓国側のチームが発表していますので、もし興味がありましたら、そちらもご覧いただくといいかなと思います。
このモデルの開発や、モデルに入れる特徴量の提供などを行なっていますが、LINE DSPでは、特徴量についてはユーザーやAD、広告枠といったもの、いろいろな特徴量を用いて最適化しています。実際にどういったものを使っているかについては、ちょっとあまり詳しくは話せませんが、今日はその概略だけお話できればと思います。
実際DSP MLチームがどんなことをやっているかということですが、例えばユーザーやADといった単位だけではなく、ユーザーとADの組み合わせみたいな、そういったものに対して、フィーチャーを提供したり、そのパイプラインの設計などをしたりしていました。
ということで、実際どんな感じのもの作ったかを簡単に紹介できればと思います。
これは概略図ですが、このコンポーネントはap−workerと呼ばれていまして、実際にUser x Ad Similarityといった、特徴量の提供のために利用されているものになります。
このUser x Ad Similarityは、その名のとおりユーザーとADのペアでCTR予測するようなモデルなのですが、そのままユーザー×ADみたいなものを入れちゃうと、非常に膨大な量になってしまうので、ユーザーとAD、それぞれのembedding vectorを作って、その近さを特徴量として入れるようなモデルになっています。
このembedding vectorをリアルタイムで更新できると、ユーザーのアクションなどに基づいて即座に更新し最適化できるので良い、ということでこういったパイプラインを作っています。
ざっくりパイプラインについてお話しすると、アプリからきた広告表示やクリックとかのイベントが、Kafkaに流れてきますので、Kafkaからイベントをconsumeして、クリックをRedisに書いておいて、インプレッションをさらに遅延させてKafkaに流してジョインして、そのジョインしたイベントを用いて学習するフローになっています。
この構造自体は非常に一般的なもので、User x Ad Similarity以外でも使えますので、こちらは拡張可能コンポーネントとして作成しています。
User x Ad Similarityでは使っていませんが、他の特徴量の生成では、広告素材のテキストや画像の情報も必要になるのですが、そういったバッチ類についてはユーザーのクリックなどと比べると頻繁に更新しなくてもいいものなので、そういったバッチについてはKubernetes上のArgoを使って実装しています。
という感じで、その作った特徴量についてはバッチでHDFSなどに書き込んでWorkerから読み込んで使うような工夫になっています。
樋村:DSP MLチームとして求められる技術スタックについて、最後にお話ししたいと思います。DSP MLチームでは広告配信の最適化に必要な機械学習から特徴量生成のためのサーバーサイドまで一貫してやっているような感じです。特徴量を追加するにあたって、オフラインテストなどをガンガン回す感じなので、Pythonや機械学習系フレームワークの知識があると、うれしいです。
サーバーサイドとしては、Pythonに加えてap−workerを最初Javaで書いていたのですが、その後Kotlinに移植したりしたので、Java系の言語の知識や、JVM系の監視や運用の経験があると非常にうれしいと思います。
また、LINEのDSPはGoで書かれていますので、Goについてもある程度読めたり書いたりできるとうれしいという感じです。
またKubernetesについては、LINEのプライベートクラウドのVKS(Verda Kubernetes Service)というサービスを利用して構築しています。ですので、Kubernetes自体の構築は必要ないんですが、その上の設定やArgo Workflowの管理など、そういった部分については、私たちで行う必要がありますので、Kubernetesの知識が豊富にあると非常によいと思います。
また、その先ほどのap−workerといったそういったストリーム処理についても、Kafkaを利用しており、このKafka自体も運用は別途専門のチームがいまして、そちらで運用しています。
ただ、そういったストリーム処理の監視やトラフィック量の見積もりといった部分については、ある程度経験と知識があると、非常にうれしいかなというふうに思います。
DSP MLチームではそんな感じで、サーバーサイドとML両方やるチームになっていますので「両方やってみたい」「機械学習やったことないけどちょっと興味あるんだよね」っていう方でも、ぜひ応募いただければと思います。共に広告業界をよくしていけるとうれしいです。以上でDSP MLチームの紹介といたします。ご清聴ありがとうございました。
司会者:大東さん、樋村さん、ありがとうございました。それでは、質問に答えていきたいと思います。3つほど質問をもらっていまして、順番に回答したいと思います。
まず1つ目ですが、MLチームの中でサーバーサイドエンジニアが何人いて、どういう経歴の方がいるのですか。
大東:発表順で私から答えますと、サーバーサイドエンジニアは、現在4名か5名です。
それでどういった経歴かというと、広告出身の方もいらっしゃいますし、それから機械学習を学生時代行なっていたというような方もいますし、機械学習自体にまったく縁がなくて、コンピューターサイエンスの出身の方もいます。
司会者:はい、ありがとうございます。樋村さんのほうはいかがですか。
樋村:そうですね。DSP MLチームでは、みんな機械学習もやればサーバーサイドもやりますという感じなんですが、特に強いメンバーとなると2人ですかね。
広告出身というよりかは、他から来た人がけっこう多いですが、私はもともと動画の広告ネットワークを前職としています。
司会者:ありがとうございます。次の質問ですが、学習に用いる時間はどの程度かかりますか。
大東:本当にモノによりますが、長いものですと24時間程度やっているものもありますし、短ければ分単位のものとかもあります。
樋村:DSP MLチームについても同じで、モノによりますね。先ほどのap−workerについては、本当にストリーム処理なので、分単位で処理できないとまずいですし。バッチについては本当に1時間とか、1日とか、そういったものもあります。
司会者:ありがとうございます。次にエンジニアのキャリアについて質問がきていますね。キャリアをスタートする上で、サーバーサイドエンジニアでスタートするのがおすすめだったりしますか。これは、Machine Learningに限ったお話じゃないとは思うんですが、いかがでしょう。
大東:比較されているものがなにかによりますね。例えばiOSのエンジニアに比べると、リリース周期が短いからもう少し自分で制御しやすくてよいとか、そういった部分があるかもしれませんが、ちょっと好みになってしまうので、これぐらいで勘弁してください。
樋村:そうですね。広告についてもサーバーサイドエンジニアというと、けっこうリリースしたものがすぐ売上に直結しますので、そういった意味では非常に楽しいと僕は思っています。
ただ、もちろん何か失敗、というかサービスを落としてしまった時は、その影響がけっこう大きいので、そこはちょっとものによるかなという感じですね。
司会者:ありがとうございました。
LINE株式会社
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには