LINEのBotを作るAPIに、大量に流れてくるデータをどう捌くか　LINE Bot Platformのサーバーサイド開発

Messaging APIのサーバー開発

川田裕貴氏（以下、川田）：「LINE Messaging APIのバックエンド開発」についてLINE Platform Developmentセンター1で、Bot Platform Development室 Bパートチームの川田が話します。よろしくお願いします。

自己紹介します。僕は新卒でLINEに入社しました。2014年に開発インターンシップに来て、そのまま新卒で、先ほど説明された片桐さんたちがいたチームに最初配属されました。いろいろLINE Thingsの開発や、Botのまわりに近いような開発をした後に、今のMessaging APIのサーバーサイドの開発をしています。Twitterのアカウントもあるので、興味があれば何か話かけてみてください。

LINEのMessaging APIのサーバー開発ということで、まずLINEのMessaging APIがどういうものかを軽く説明します。LINEのMessaging APIは、LINEでBotと言われるようなLINE公式アカウントを作るAPIとそのプラットフォームです。すべてみなさんに公開しているAPIなので、無料で気軽に使えるAPIになっています。

どんなプロダクトがあるかといえば、LINEで提供しているのは韓国語の通訳や英語の通訳をしてくれる翻訳Botで、これを実装できたりあとはLINE NEWSというニュースが配信されるもので、これはFlex Messageなどを使ってきれいなメッセージを配信するようなものだったり。あとは「どこの地域のお天気を教えてください」などと話したりすると、天気を教えてくれるようなBot。こういうものを実現するためのAPIになっています。

たぶんLINEを使ったことがあれば、一度はLINE公式アカウントをフォローしたり、何か機能を使ってみたりしたことがあるのではないかと思います。その裏側で動いているのが、Messaging APIです。

Messaging APIはBotを作るAPI

このMessaging APIは、LINE公式アカウントと言われる、いわゆるBotから使うものになっています。LINE公式アカウントも、最近ではいろいろな企業の方が使っています。こういうものも、すべてMessaging APIを使っていますし、あとはLINE公式アカウントで下のほうから出てくるような、リッチメニューと言われるボタンのようなものを見たことがある方も多いと思いますが、こういうものもMessaging APIで実装されています。

リッチメッセージやFlex Messageなど、ただテキストを送るだけじゃなくて、JSONなどで送った形式をもとに、LINEのクライアント上できれいに画像を混ぜて表示するようなものも提供しています。

まとめると、LINEのMessaging APIは基本的にはBotを作るAPIなんですが、Botからユーザーへの一斉配信、広告的なみなさまにお知らせするようなものだったり、あとはBotからユーザーに、個別にそれぞれの人へプッシュしたり、レコメンデーションを送信したり、あとはユーザーからのメッセージに対応して、何かリプライを送ったり。

そういう個別配信をするようなAPIと、あとはユーザーから何かメッセージが送信されたり、ユーザーから友だち追加されたり、アクションが来た場合に、みなさんのBotのサーバーにWebhookを送信するような機能だったり。あとは先ほどのリッチメニューや、ユーザーの情報を取得したり、メッセージをどれぐらい送信したか、そういうものを管理するようなAPIを、まとめて提供しています。僕たちは、これらのサーバーサイドの開発を行っています。

Messaging APIサーバーサイド開発の三つの柱

Messaging APIのサーバーサイド開発がどういうことをやっていて、どんな開発課題があって、どんな技術を使っていて、ちょっと内部的な仕組みがどうなっているかをこれから説明したいと思います。「LINE公式アカウント」と対外的に言っていますが、ふだん社内ではみんなBotと言っているので、「Bot Backend Dev」ということで話します。

僕たちのチームの開発がどういうことをやっているかというと、1つ目が新機能の開発です。これが割合が大きいです。リッチメニューや、あとは例えば最近だとナローキャストと言われる、年齢とか住んでいる地域や、性別、そういうのを絞って配信できるようにする機能などを最近も追加しています。

Webhookまわりでも、新しいパラメータを追加したり、お客さまからの意見をもとに、新しくこういうものを追加すればもっとMessaging APIが便利になるんじゃないかというものもけっこう開発しています。なので、そういうものをどんどん良くしていくという開発が1つ。

あとは、既存のMessaging APIも、ここ最近コロナの影響もあってか、けっこうメッセージの送信数が増え、やり取りが直近でも増えています。なので、そういうメッセージが増えても安定して稼働できるように、保守や改善を行っています。これも、けっこう割合が大きいです。

また運用と監視ですね。実際に、今まで動いていたものも突然何かサーバーが壊れたり、何かソフトウェアのアップデートによって、問題が発生したりすることもあるので、そういうものが起きないように日々監視なども行っています。大きくこの3本柱の仕事をしているかたちですね。

Messaging APIサーバーサイド開発の技術課題

実際にどんな技術課題があるか。このチームでどういう課題に向き合っているかということですが、今我々のチームで、多い時には1日20億以上メッセージを配信しています。この中で1つ問題になっているのが、メッセージ送信の安定性や速度、あとはいろいろな機能を追加していくとどうしても遅くなったりするので、そういう部分に向けて、今システムのリプレースみたいなものを内部的に行っています。

先ほども言ったように、送信数が増えているので、さらにこの先もっと増えたことを想定して、それでも耐えられるようなアーキテクチャを考えていて、LINEの中ではけっこうApacheのKafkaというキューソフトウェアを使っているので、これをもとにリプレースを行う作業を最近は進めています。

あとは、APIのユーザビリティ向上です。先ほども言ったように、もっとMessaging APIにこういう機能があれば便利だなというものがいろいろあるのは、僕たちも把握はしているので、それをもとに継続的に新機能を投入するような課題。あとはやはりシステムの安定性ですね。

LINEが出てから10年近く経ちましたが、Messaging APIもけっこう初期から、Messaging APIという名前ではなかったと思いますが、公式アカウントのような機能はあったので、その頃からずっと引き継がれているようなものもあります。ただ、やはりメッセージ送信が多くなったり幅広く使われるようになると、どうしても安定性に欠けるような場面が出てきたりするので、これらを改善することを進めています。

これが大きな課題だと思います。特に、1個目の「メッセージの量」がとても多いのが、うちのチームの特徴ですね。

Messaging APIサーバーサイド開発の技術スタック

ではどういう構成なのか、どういう技術スタックを使っているのかですけど、まずこれは、Botのメッセージ配信ですね。Bot側からユーザーのアカウントへメッセージを送信する場合には、このような感じになっています。API Gatewayサーバーがいて、メッセージを処理して送信するためのサーバーがあって、配信を行うためのキューがあって、ここはRabbitMQなどでできていて、その先は配信サーバー。

そのキューから、コンシュームして配信していくようなサーバーがあって、実際にLINEのtalk-serverと言われるようなLINEの根幹のサーバーに送信して、みなさんのLINEアカウントにメッセージが送信されるアーキテクチャになっています。

この中で、特に我々のチームで特徴的なのが、かなりマイクロサービス化されているにもかかわらず、それぞれが多くのリクエストを処理しています。なので、チームに入ると、ご自分で「ここのコンポーネントは得意だから行ってみたい」というのがあることが多いのですが、どこのコンポーネントに行ってもリクエスト数がとても多いです。全部ではないですが、EnvoyやConsulを使ってサービスメッシュが構成されていて、そういうもので基本的にAPIやRPCでつながっています。

最近は、このRabbitMQの配信Queueの部分をKafkaに置き換えたり、このあたりの改良をけっこう重点的に行っています。言語については「Java」、フレームワークは「Spring Boot」と、あとはLINEで作っているOSSの「Armeria」を主に使っています。

次に、ユーザーから送信されたメッセージをWebhookを使ってBotに届けるような逆側の構成も、同じようにキュー使って非同期処理をしていて、こちらもRabbitMQではなくて、2020年あたりにいろいろ改善をして、すべてKafkaに置き換えています。

BotもLINEの中であれば1つのアカウントとしてみなすので、ユーザーから送られたメッセージをすべて受信して、LINEに送られて来たメッセージを一度すべてコンシュームしてからBotであるものを選別し、Botのものだけを取り出して、イベント処理サーバーへ送信することを行っているんです。

このイベント量はめちゃくちゃ多くて、多い時には秒間100万イベント以上処理したりしています。ここのパフォーマンスやサーバーの台数などは、うちのサービスの中でも多いですね。ただこの先はKafkaでできていて、この先も秒間2万イベントなどを処理していて、ここも量は多いのですが、この先のサーバー台数は、本当に限られたサーバーでイベントの順序や整合性を保証していて、バーッと送るような仕組みになっています。

Webhookというと、いろいろなBotサーバーへメッセージを送らないといけないので、けっこうどんな環境かわからないんですね。

Messaging APIのWebhookを送る先が、もしかするとユーザーがテレビなどを見て、その内容を大量にメッセージで送る環境だと、このWebhookのエンドポイントがすごく遅くなることがあります。こういう状況でも、確かにメッセージは詰まっていってしまいますが、その詰まっていった状況でも、うまく処理できるような仕組みがいろいろあって、このあたりの工夫もかなり入ったサーバー構成になっています。なので、けっこうパフォーマンスなどが重要なサーバーが多いです。

どういう人が楽しく働けるのか

では、どういう人が働いたらおもしろいのかということですが、超大量のイベントを、短時間に確実に送れるか。ユーザーからのイベントをロストしたり、配信するイベントをロストしたりすると大変なので、大量イベントを短時間に処理する必要があります。かつ、こちらもお金をもらって配信しているので、確実に分散処理するようなコードが必要です。そのようなコードを書きたいという人は、ぜひうちのチームで活躍していただきたいです。

あとは、やはりMessaging APIはいろいろなところで使われているし、多くの企業の方に使われているので、そういう身近に感じられるようなAPIに関われるのは、そういうことが好きな方にはかなり良いのではと思います。

あとは、開発者相手に仕事をすることはなかなかないと思いますが、Messaging APIを使うユーザーはほぼ開発者で、APIを叩く側の人たちなので、そういう開発者相手のプラットフォームで、いろいろ機能を追加したり、こういう改善ができるんじゃないかとかと提案したりをやっていきたい人は、向いているのではないかなと思っています。

これから何をするのか

先ほど技術課題を何度か説明しましたが、ではこれから何をやるんだということで、先ほど言ったように、Kafkaのメッセージキューのリプレースもありますが、その先それが置き換え終わると、今度はいろいろ新しくできたアーキテクチャでメッセージ機能強化ができるようになるので、もっとスマートに、費用対効果が高いような配信ができる機能拡張が準備されています。

Webhook側も、今はイベントの再送などを行っていませんが、そういう再送を行えるようにする機能強化も計画しています。あとは、サービスの現代化ですね。先ほども言ったように、Messaging APIはけっこう古くからあるので、LINE10年分の遺産が積み上がっています。

なので、これを時代にあったコードに書き換えて信頼性向上するとか、あとはやはり障害を起こしてはいけないので、安定的な運用ができるように、設計を日々見直して改善していきたいと思っています。なので、こういうものに興味がある場合には、ぜひBot Platform開発室に応募していただきたいと思います。

ありがとうございました。これで、僕の発表は終わりです。