2021年11月10日・11日の2日間にわたり、LINEのオンライン技術カンファレンス「LINE DEVELOPER DAY 2021」が開催されました。特別連載企画「DEVDAY2021 アフターインタビュー」では、登壇者たちに発表内容をさらに深堀りし、発表では触れられなかった関連の内容や裏話などについてインタビューします。今回の対象セッションは「次世代マーケティングデータ活用基盤『Business Manager』開発の裏側」です。
「Business Manager」は、広告主である企業がLINEの各種広告プロダクトを横断してさまざまなデータを有効活用するための基盤です。2021年1月に開発がスタートし、2021年10月に正式リリースしました。現在はLINE公式アカウントやLINE広告、Talk Head View、LINE NEWS TOP ADの間におけるオーディエンスや広告用タグの相互利用に対応しており、今後も連携アカウントの拡大や統計分析機能の追加などを予定しています。
*参考: プレスリリース
「Business Manager」の開発では、いくつもの課題が立ちはだかりました。それらを乗り越えるために取り組んだ施策の秘話を、Business Data Platform開発チーム ソフトウェアエンジニアの中村俊之が解説します。
いかにしてデータベースとKafkaを同一トランザクションでハンドリングするか
――Business Data Platform開発チームの役割や中村さんの業務内容を教えてください。
Business Data Platform開発チームは、LINEの広告のためのデータを収集・提供するプラットフォームを管理している部署です。「Business Manager」や他のセッションで解説された「LINE DMP」の開発・運用を行っています。私は「Business Manager」の開発リーダーを担っています。
――「LINE DEVELOPER DAY 2021」で中村さんは、「Business Manager」の開発において「データベースとKafkaを同一トランザクションでどうやってハンドリングするか」を検討されたと解説されていました。なぜ、この課題が生じたのかをご説明いただけますか？
「Business Manager」では、ユーザーが管理画面から共有権限の設定を変更できます。この際、変更されたデータの情報を「LINE DMP」に対して確実に漏れなく正しい順序で通知する必要がありました。
なぜなら「LINE DMP」では「オーディエンスデータの共有が開始された」「共有が止まった」といった「Business Manager」側での変更を、Kafkaを通じて正しい順序で受信することにより処理しているためです。この前提条件を満たすには、データベースとKafkaを同じトランザクション内でハンドリングすることが必要になりました。
実現する方法をチームで議論するなかで、3つほど案が出ました。1つ目はAPIコールバックを用いる方法です。データベースの同一トランザクション内でデータベースの更新処理をした後、共有権限が変更されたというメッセージ情報をパブリッシュします。その後、コンシューマー側でAPIを呼び出すことで、変更がデータベースに反映されているかを確認してもらう方式です。
この方法の長所は実装がシンプルである点です。また、LINE社内の他のチームでもよく使われており、実績があることも利点でした。非常に魅力的な案だったものの、コールバック用のAPIにパフォーマンスの懸念があり、この方法は早い段階で見送りました。
2つ目はチェンジデータキャプチャを使う方法です。私たちの部署ではMySQLのbinlogを情報源として、Debeziumというソフトウェアを使って変更内容をKafkaに通知する方式の実績がありました。この方法の利点はほぼリアルタイムで処理できること。さらに、LINE社内の他のチームでも導入実績があるため、実現の見通しも立てやすいことです。
しかし、共有権限の設定を管理するテーブルの構成が複雑であることから、コンシューマーの設計の難易度が高くなることが考えられました。また、インフラのセットアップといった追加作業が必要になり、工数が肥大化することからスケジュール的にも厳しいことがわかってきました。また、他のチームで採用されている方法では順序の保証がされないため、今回のユースケースには適さないと判断し、この方法も見送りました。
3つ目はPolling publisherを使う方法です。共有権限設定が変更された際、同時にイベントキューを保持するテーブルにも同一トランザクションでイベントを書き込みます。その後、バッチがイベントキューのテーブルをPollingして、変更があればKafkaに通知します。
この方法の利点は実装がシンプルであり順序保証もされることです。反面、Pollingの間隔次第ではリアルタイム性が失われることと、データの変更が多い場合にはスケールしないことが欠点として挙げられます。
しかし、「Business Manager」の要件ではリアルタイム性はそれほど必要なく、かつ権限設定を頻繁に変更するユースケースは考えにくかったため、この方法を採用しました。アーキテクチャの詳細についてはセッションにて解説していますので、よろしければ動画をご覧ください。
他チームとの情報連携を円滑にするために
――「Business Manager」のAPIは複数のチームが利用するそうですね。そうした性質のサービスの場合、情報連携や仕様確認などを行うためのコミュニケーションコストが肥大化する傾向にあります。他チームとの情報連携を円滑にするために工夫したことはありますか？
「Business Manager」の開発初期では、他チームに提供するためにスケジュールが厳しい状況下でAPIドキュメントの作成を迅速に行う必要がありました。私たちはこの課題をspringdoc-openapiを採用することで対応しました。springdoc-openapiは、Springのコントローラーにアノテーションを付けるだけでOpenAPIバージョン3形式のJSONやYAMLを生成するライブラリです。
特定のエンドポイントでSwagger UIを利用可能になるため、エンジニアがわざわざドキュメントを作成しなくても、コントローラーが生成した最新のAPIドキュメントをいつでも閲覧可能になります。さらに、閲覧するだけではなく実際にAPIを実行してレスポンスを確認することもできます。
「Business Manager」の開発プロジェクトではサーバーサイドの言語としてKotlinを用いたのですが、springdoc-openapiはKotlinもサポートしています。さらに、Kotlinの型がNon-NullであればAPIの必須要素と判定してくれ、言語とライブラリとの親和性も高いです。また、プロジェクト独自のアノテーションを記述することでドキュメントに任意の項目を追加するなど、カスタマイズも可能です。
さらに別の工夫としては、分散トレーシングの技術を用いてAPIのリクエストごとにトレースIDを発行しています。この仕組みを社内のログ基盤と組み合わせて、トレースIDを元にして処理の流れを追跡できるようになっています。これにより、調査が必要な際の他チームとのコミュニケーションが円滑になっています。
「Business Manager」をより良いサービスへと改善していく
――チームビルディングやナレッジシェアのために「Business Manager」の開発チームでモブプログラミングに取り組んでいる旨が、セッション内で語られていました。モブプログラミングの効果を向上させるために工夫した点があれば教えてください。
基本に忠実にモブプログラミングを実施していたので、特別なことはしていませんでした。強いて言うなら、モブプログラミングのタイムマネジメントを適切に行うことで、1日の中でなるべく全員がドライバー（コーディングする役割）を担えるようにしました。
また、作業効率の向上のため、GitHubのリポジトリ上でIntelliJ IDEAの設定ファイルを共有し、全員が同じ設定でIDEを利用できるようにしました。さらに、チーム内で「Business Manager」に関するプロジェクトや設計の知識を共有することに加えて、プログラミングにおいて役立つようなツールの使い方やショートカットキーの知識などを共有することで、チーム内における技術レベルの差を埋めるようにしていました。
それから、チーム内の雰囲気やメンバーのモチベーションが向上するように、なるべく楽しくモブプログラミングを実施できるように心掛けていましたね。
――複数人で取り組むモブプログラミングと、個々人が取り組む通常のプログラミングはどれくらいの割合で実施しましたか？
モブプログラミングに取り組んだのはプロジェクト初期の頃で、中期から後期にかけてはエンジニアが個別でプログラミングを実施していました。モブプログラミングには利点と欠点のどちらもあり、状況に応じて使い分けています。
利点としては、メンバー同士がコミュニケーションを取りながら作業を進めるため、情報共有の効率が非常に良いことです。その反面、すでに知識を共有できており実施すべきことを各メンバーが理解できている場合には、個別でプログラミングを実施するほうが作業効率が良くなるケースも多いです。そのため、このプロジェクトにおいても初期は頻繁にモブプログラミングに取り組み、全員が知識を共有できたら個別のプログラミングに移行するような方針をとっていました。
ただし現在でも、インフラ構築や各種ツールの設定といった、運用に関連する知見をチーム全員で共有し、なるべく属人性を低くしたほうがよい業務に関しては、複数人によるモビング作業を続けています。
――今後「Business Manager」をどのように改善したいですか？
これからも「Business Manager」にはさまざまな機能を追加する予定ですし、なるべく多くの方々に使っていただきたいと思っています。とはいえ、現在の設計ではデータ利活用の対象サービスを追加する仕組みが汎用的ではないため、より簡単に追加できるように改善していきたいです。
さらに、データ利活用の対象となるサービスやそのアカウントが増えるにつれて徐々にパフォーマンスの懸念も生じてくるでしょうから、より大量のデータを扱えるようなアーキテクチャへと、さらに進化させていきたいと考えています。
採用情報
LINE株式会社では一緒に働くエンジニアを募集しています！
今回のインタビューと関連する募集ポジションはこちらです。