LINE Engineering
Blog

LINE Engineer Insights vol.1 「LINE BOT 育ての親に聞く、LINEの誕生と成長」

LINE Engineering Blog 2017.02.16

LINEで働くエンジニアに色々と話を聞いていく新コーナー「LINE Engineer Insights」をスタートいたします。インタビュアーにはLINEで働くエンジニア @tokuhirom を迎え、エンジニア同士でざっくばらんにお話を伺っていきます。LINEのエンジニアは一体どんな人達なのか、その内面に迫っていきたいと思います。

今回は、開発1センター LINE開発室 B Partチーム所属の熊井に、コミュニケーションアプリ「LINE」の誕生時のことや現在担当されているLINE BOTのバックエンドの話などを聞いてきました。

B Part のBはBOTのB?

―― tokuhirom
今日は宜しくお願いします。熊井さんとはBOT関連で一緒に働いていますが、LINE Engineering Blog向けということで気持ちも新たに色々と聞かせてください。最初に、入社されたのっていつ頃ですか?また、入社したきっかけなどあれば教えてください。

―― 熊井
入った当時はネイバージャパンでしたが、2011年の1月1日入社で今は7年目です。転職しようと思っていたタイミングでちょうどネイバージャパンが募集をしていて、知り合いとかもいなかったので普通に応募しました 。

―― tokuhirom
そうなんですね、今はどこの部署に所属されていますか?

―― 熊井
開発1センターの B Partチームというところで、LINE BOT関連をやっているチームです。開発1センターはLINE本体の開発をしている部署で、チーム名はおそらく「BOT」のBなんだと思います。

―― tokuhirom
LINEはカジュアルに組織変更があったりするので毎回不思議なんですけど、ほんとにBOTのBなんですかね?(笑) 噂では違う由来もあると聞きましたが。B Partではどのようなお仕事をされていますか?

―― 熊井
チームの名前についてはどうなんでしょう。あまり気にしたことがないですが、わかればいいかなと…。B Partでは、今はBOTおじさんなのでBOTの面倒をずっと見ています。Message配信や、ユーザーから受信するところの処理をやったりするサーバサイドを担当しています。

―― tokuhirom
今回、インタビュー企画をスタートするにあたって「誰が初回に向いているかな?」と企画の人が社内のエンジニアたちにヒアリングしてきたらしいんですけど、熊井さんが圧倒的に1位だったそうです。LINE 立ち上げ時の iOS エンジニアだったんですよね?

―― 熊井
なぜそんなに私が注目されているのかはわからないですが。そうですね、LINEリリースの時は iOS エンジニアです。LINEをリリースしてからはBOTの開発にすぐ着手して、翻訳BOTや天気BOTなど一方的に送るようなシンプルなものをLINE本体のリリースから数ヶ月で公開しました。翻訳BOTは社内のニーズが高かったので日韓の翻訳をしてくれるものは早めに出しました。

LINE 初期バージョン開発時の思いがけない障壁

―― tokuhirom
LINEリリース時はまだ私は関わっていなかったので知らないんですが、LINEの最初のリリースはどういう開発陣で作られたんでしょうか?インターネットの記事で見かけたのですがもう少し詳しく教えてください。

―― 熊井
リリース当時はiOS担当で4人いました。日本・中国・韓国・アメリカという多国籍なチームでしたね。サーバサイドは、ソクホさん(※編集部注:現在は上級執行役員の梁ソクホ)がメインで10名くらいのチームでやっていて、韓国からもサーバサイドやその他の機能担当がそれぞれ来て担当していたので、プロジェクトメンバーは多かったと思います。色々と記事なんかも出ているのでわりと有名だと思いますけど、かなり短期間で開発をしました。今思えばいい思い出だけど、かなりキツかったですね。

―― tokuhirom
同時に他のプロジェクトもやりながら新規でLINEも作ったんですか?

―― 熊井
いえ、他のプロジェクトは一切やらずに新規でLINEを作るだけでした。それまでiOSの開発をほとんどしたことがなかったし、思いがけない障壁というか困ったことがあったんですが、当時はMacをさわったことがなくて苦労しました。あまりにわからなくて「Mac コピペ」で検索しましたね。 Ctrl+Cでコピーできねーな?って…。Macを操作するのもままならない状態で開発を始めたというのは本邦初公開かもしれませんね(笑)

それまではサーバサイド開発のキャリアが長かったので「たまにはクライアントもやってみたいな」と思って、LINEの企画が立ち上がる少し前に別のプロジェクトがあって「iOS開発やりたい人ー」と募集があったので手を上げて、それをやろうと思ったらLINEの開発に投入されたという経緯です。

―― tokuhirom
LINEの最初のバージョンは2ヶ月くらいで作ったというのは本当ですか?リリースしてからの心境の変化などありました?

―― 熊井
2ヶ月か、それくらいだった気がしますね、今となってはわからないですが…。最初はユーザー数も「100万ユーザーくらいいけばいいね」と開発チームでは言っていたんですが、1000万ユーザーになり1億ユーザーになり、そんなに使ってくれるようになるとは思ってなかったです。

LINEの技術的な強み、BOTサーバの誕生から現在

―― tokuhirom
なるほど。ここからは具体的に技術っぽい話を聞いていこうと思います。まず、LINEの技術的な強みはどこにあると思いますか?

―― 熊井
同僚のほとんどがそうなんですが、ある一定のことは出来る人が多くて、それは結構強いかなと思っていて。それぞれ専門はあるんだけど、技術的なコミュニケーションが早くできることで開発などの対応の早さにもつながっていると思います。あとは、LINEのように大きいトラフィックがある規模感でやっているところはなかなか無いので、経験を持った優秀な人達がこういう環境を得てやっているのが強みかなと思いますね。

―― tokuhirom
LINEを今まで育ててきて、どうですか?プロダクトへの思いであるとか。

―― 熊井
LINEもそうですけど、BOTのシステムは最初から面倒をみているので愛着はありますよね、やっぱり。BOTはもう6年くらいやっているので、要件とか環境が変わったりとか色んなシステムの構成もそうだし、すごく変わってきてるのを自分でみてメンテナンスしてきてるので面白いというか、だいぶ変わったなあと思いますね。

―― tokuhirom
BOTの環境ってどう変わってきました?

―― 熊井
最初はBOTに関していうと、翻訳BOTのような自社でやっている特殊なケースだけだったのでそれ専用に全て処理を書いてたんですね。これをビジネス的にお客さんに提供することになって、もっと汎用的になっていかないといけなくなったんですね。アカウントも増えたし、翻訳BOTみたいな特殊な動きをするのがレアケースになっていって、BOT APIを公開するとそれがメインストリームになったりもしていきます。その後はシステム面の変更があったり、社外に提供しているものなのでビジネスの都合でどんどん変わっていっています。

―― tokuhirom
BOTの要件の変遷におけるシステム変更、規模感が変わっていったと。どのように変わっていきましたか?

―― 熊井
最初は、BOTのサーバはバックアップ含めて4台で動かしていたんですよ。もちろん翻訳BOTなどのエンジンは別サーバですけど。BOTそのものは2台で動いていて、2台がバックアップ。それが今は、周辺にあるものも入れると数百台規模くらいになっているのでだいぶ増えました。

BOTはシステム的には何回か作り直しているんですね。例えば、BOTがユーザーからメッセージを受信して処理をするところは最初のものがv1だとすると、今はv3なので2回作り直してます。理由としては、用途が特化したものだったんですけど汎用的なものにしていくとか、スケールが大きくなってくるとか、そういう理由で処理する量が増えると。そこにビジネス的な要件が入ってきて、そろそろ作り直したほうがいいんじゃないかということでv2に作り直したと。

ですが、今となっては境目が薄くなって来ているんですが当時は企業向けのオフィシャルアカウントというものと、小規模の店舗や個人が使えるLINE@というものがあって、最初はハッキリと要件が分かれていたんですね。それが段々と混ざってきて、LINE@だけどものすごく人気があって友達数が多いとか、オフィシャルアカウントなんだけど小規模だったりとか。今はインドネシアとかだとイベントの懸賞などで使われることも多くて、システムが壊れるんじゃないかってくらい皆が一気にメッセージを送ったりとかされても大丈夫になっています。

―― tokuhirom
最近はメッセージタイプも増えたし色々出来ることが増えていますよね。

―― 熊井
そうですね、めちゃくちゃ人気があるアカウントも多いですし、リッチメニューをすごく上手に使ってくれるアカウントもあったりして「あ!こうやって使うんだ!これ1枚の絵になってるの!?」みたいな(笑) テレビ番組とタイアップで「番組中に応募してね!」みたいな取り組みもよくありますし。「メッセージが何通きたら東京タワーにライトがつく」みたいな企画も過去にはあったりして「マジで!?」みたいな(笑) そういう大掛かりな規模だと多少トラブルになったりもするんだけど、トラブルを経て徐々に強くなっていっています。

昔は無かったけど今はある機能として、メッセージがアカウントに集中した時に自動でうまく処理する仕組みがあるんですね。全体に影響が出ないように一部だけをブレーカーが落ちるみたいにプチンと落とすみたいなのが実装されていて「おお、ちゃんと動いているな」と作っておいてなんですが感心します。

様々な機能が追加されている現在のLINEオフィシャルアカウント

大規模なトラブルで得た教訓

―― tokuhirom
トラブル系で印象に残っているものって何かありますか?

―― 熊井
うーん、そうですね。色々ありましたが…。何年か前ですけど、BOTのメッセージをBOT同士でループさせちゃってLINEのストレージが危険な状態になったことがあって、やらかしてしまったなと…。大変申し訳なかったです。普通のサービスには影響がなかったんですが、社内で色々と監視をしているのでアラートが出ていて。ストレージ側で対応をいくらしてもどんどん止まらないというか。それを隣で見ていたので「大変そうだな」と思って眺めていたら、やらかしてたの自分だったという。申し訳ありませんでしたという。

―― tokuhirom
いまは基本的にBOT同士のメッセージのやり取りは行われないですよね。

―― 熊井
そうですね、そういうトラウマがあるので絶対駄目だと言ってます。あとは、去年とかMessaging API 出た時とかに少しやらかしたことがあります。今までずっと使っていたもので少し修正が必要なものがあったんですけど、Messaging APIがやっと終わったのでさーて手をつけるかと思ったら、障害になっちゃったことがありました。

LINEのような大きな規模になると、やばいなと思っていたところは予め対処しておかないと、ちょっと流行るアカウントがポッと1つ出ただけでそこから障害になるみたいな、そういうことがあります。その時は、テレビでBOTがテーマになった番組があって、2時間くらいの放映だったんですけどその間ずっと大量にメッセージが届き続けて。少しの間ならもちろん問題ないんですけど、何時間に渡ってというのは今までになかったのでトラブルになってしまったという。問題を修正したコードはbeta環境まで適用されていて、来週リリースしようと思っていたらその前に障害になってしまったという。

―― tokuhirom
そういう、テレビに出るっていうのも毎回連絡があるわけじゃないですよね

―― 熊井
そうです、連絡が来なくて。障害になった時に「これからはわかる範囲で教えてください」って言いましたね(笑) LINEは早めに作ってリリースして、後からどんどんケアしていくというスタイルでもあるので。システムのメトリクスやアラートを見ながら、ここおかしいなと思ったところを潰していく地味な作業の時期が長いですね。今の仕事の半分くらいはそうなんで。

―― tokuhirom
結構マメにメトリクスはチェックしているんですか?

―― 熊井
そうですね、たまにしか来なくてサービス全体には影響がないんだけどこれはなぜだろう?みたいなアラートを調べたりというのはちょこちょこやったりしますね。

―― tokuhirom
アラートってどのくらいの頻度であがってくるんですか?

―― 熊井
ものによりますけど、やばい系はほとんど無いです。よく来るのは毎日来ますね。原因は様々なんですけど、そういう毎日アラートが来続ける中で「あれ?なんかこれ様子がおかしいな」みたいなのを自分の中で感じることはあります。いつもはもっと違うかんじのメールが来るんだけど、この時間帯でとか、この間隔で、とか。おかしいと気づくことはありますよね。

―― tokuhirom
最近なにか困ってることってありますか?

―― 熊井
最近困ってることですか…うーん。順風満帆ではないですけど、そんなに大きいものはないですね。全体としてはエンジニアが足りてないとか、そういうのはありますけど。一人で見てるものも多いですし、BOTはチームの変遷もあった関係で、当時のチームが別になってしまったんで「色んな自分の子供たちを連れて別の家に来た」みたいな状態で。一人しか見れないってのもよくないので、最近はまわりの人にもレビューをしてもらって、少しずつ見てもらうようにしてますね。

―― tokuhirom
社内はレビューをかなり綿密にやっているかんじですよね。

―― 熊井
レビューの文化はいいと思いますね。人に自分が扱っているサービスとかシステム を見てもらうきっかけとして。

「守らなければいけないもの」へのこだわり

―― tokuhirom
逆にBOTやってて楽しいところってどこですか?

―― 熊井
楽しいところはですね、なにかな…。今もLINEのなかでBOT用の処理ってあるんですけど、基本的には1LINEユーザーとして動いているんですよ。もちろんそれがBOTかという区別はつけられるんだけど、基本的な仕組みは普通のユーザーと変わらないんですね。基本的にLINEのコアな部分は一般ユーザーに特化しているんですけど、BOTの場合はメッセージのパターンが真逆なんです。一人のユーザーが沢山の人からものすごい大量のメッセージを一気にもらうことはまずないけど、BOTの場合はあるんですよね。そういう、メッセンジャーサービスなんだけどメッセンジャーっぽくないというか。そういう技術的な要件を求められるのが面白いですね。メッセージングなんでメッセージの順番を担保する工夫をしているところではあります。

―― tokuhirom
順序の工夫って具体的にいうとどんなかんじなんですか?

―― 熊井
1プロセス1スレッドで処理すればメッセージの順序は守れるんですけど、とてもスループットが低すぎるのでそれをどうやって並列化していくかっていうところですね。

実際にこう、例えばAさんとBさんがメッセージをくれていて、Aさんが先にメッセージを送ってきていてもBさんのを先に処理したとしてもAさんにはわからないっていう。そういう並列化はしていますね。一部並列化しているんですけど並列化出来ていない部分もまだあって、そこは今年の課題ですね。

―― tokuhirom
普通に使っている分には問題視されないと思いますけど、そこまで突き詰めて解決していく必要があるんですかね?

―― 熊井
ありますね。昔の話ですけど、最初に出した翻訳BOTのバージョンがあったんですけど、メッセージの処理が変わっちゃって翻訳の意味がわからなくなるってことがあったんですね。文脈がおかしいみたいな。順番は守らないといけないですね。ただ、順番を厳密に守らなくていいようなメッセージ、たとえば懸賞の応募とかですね。そういう、守らなくてもいいものと守らなきゃいけないものの兼ね合いがありますね。

―― tokuhirom
守らないほうがスケールはしますよね。

―― 熊井
そうですね(笑) そのほうが楽で、それがいらなければあのサーバもあのサーバもいらないみたいなのは結構ありますね。

―― tokuhirom
要件がどんどん違うBOTが出て来るみたいな。

―― 熊井
そうですね、そしてそれを併存させないといけない。メッセージの順番を守らないといけないBOTと、守らなくていいBOTと。だけどもっとスケールさせてくれ、とか。まとめて面倒みないといけないのが厄介なところだし、面白みなのかもれしれないですけど。

メッセージキューは RabbitMQ 使ってます

―― tokuhirom
去年、Messaging APIを公開してトラフィックがほぼないみたいなのも増えたじゃないですか。そのあたりでの問題とかってあったんですか?

―― 熊井
Messaging API に関していうと、問題はこっちから社外のサーバを呼び出している中でのレイテンシですよね。例えばサーバがアメリカにあるから物理的にネットワークのレイテンシがありますというケースもあるし、お作法のいいBOTばかりじゃないので webhook の処理が遅い場合も多いです。それをどうしていくかが問題ですね。結局、向こうの応答を待っているとこっちのリソースを消費するので、そこでどうするか。それは今もどんどん対策をしていくところではあるんですけど。

―― tokuhirom
具体的にどういう対策をとっているんですか?

―― 熊井
今は、ある程度待ちますけどそれ以上は待ちませんという形でやってます。とはいえ、あまりにも待たなすぎるのも問題があるので、少し待っている間にバッファを作ってちょこちょこためてあげる。そこも溢れたら捨てるしかないんですけど。BOTのシステムはメッセージキューを使ったバッファがとにかく色んなところにあるんですよ。

―― tokuhirom
今はメッセージキューは何を使っているんですか?複数あれば使い分けをとうしてるかとか。

―― 熊井
BOTはほぼ、RabbitMQ が多いですね。ちょっと Kafka も今後入ってくるかなというところです。使い分けはほぼ無くて、ずっと RabbitMQ 使ってたので「これでいいじゃん」となってたんですけど、Kafka も社内の別のサービスで使っていたりするので「Kafka もいいんじゃない?使ってみようか」と。


LINE は Java オンリーで書かれている?

―― tokuhirom
今ってBOTのシステムは基本的に Java で書いているんですか?

―― 熊井
そうですね基本は Java で、一部は Scala で書いてます。あとは Redis 使ったりとか。結構色々使ってますね。

―― tokuhirom
Redis は具体的に何につかっているんですか?

―― 熊井
短期間のストレージとして使っているところもあるし、分散ロックのために使ったりもしていますね。

―― tokuhirom
Scala ってなんのために導入したんですか?

―― 熊井
Scala が好きって人が多分いたんですね(笑) 僕自身は全然わかんないので Java で書きますけど。

―― tokuhirom
唐突に出てきますよね、システムさわってると

―― 熊井
そうそう「あれ?なんだこれ?」って(笑)

―― tokuhirom
社内的には「Scala で書きたいぞ!」っていう人がいたら Scala でかける?

―― 熊井
そうですね、あとはまわりの人を見回して僕みたいに「えー」ていう人がいると書けないかもしれないですけど(笑) Akka Actor で作りたいって事があった時も反対はしなかったので、そこだけ Scala です。あとメッセージの配信の方は完全に Scala の部分があったりします。メッセージの配信まわりも RabbitMQ を使っていて、色々な要件を実現しつつスロットリングもしつつでやっています。昔に比べると配信が速くなって、今は秒間何万とかいけるのかな。

―― tokuhirom
Java の部分て具体的にどういうものを使っているんですか?

―― 熊井
大体もう Spring が多いですかね。あとは RabbitMQ だったら RabbitMQ のクライアントライブラリとか。Spring に何か必要なものをちょっと組み合わせるみたいなものが多いですね。

―― tokuhirom
Spring の中でも Spring MQ とか、ああいう系統のライブラリは使わない方針なんですか?

―― 熊井
最初に配信側で Spring Rabbit 使っていたところがあったんですけど外しましたね。ライブラリ側で色々やっていて「simple なんとか」って書いてあるんですけど、全然simpleじゃなくてわかんない、みたいなことがあって。これそのまんま使っても全然いいんじゃない?っていうところが始まりですかね。そんなに難しくなるわけじゃないし、それでいいんじゃないかっていう。僕らが外した時は、接続が切れた場合の recconect まわりの処理だったと思うんですけど、ライブラリ側が結構勝手にハンドリングしていて、そこを自分たちで制御したいってところがあって外しましたね。

―― tokuhirom
そういう要件がシビアな時はライブラリのデフォルトの挙動だとイマイチってことですね。

―― 熊井
そうですね。やっぱり RabbitMQ いいですよ。良いところとして、ack と reject という概念があって、それが結構使いやすくて。さっき分散ロックを Redis でやってると言いましたけど、分散のセマフォを RabbitMQ の ack を利用しているんですね。なかなかよく出来たものだというかんじがありますね。

―― tokuhirom
ちょっと話題を変えて、最近やった新しい取り組みって何かありますか?

―― 熊井
そうですね… 新しいサービスで色々と試してはいるんですけど、まだ言えないですね(笑)

―― tokuhirom
なるほど!社外で取り組んでいるものとかってなにかありますか?

―― 熊井
外部は無いですね。会社の中でコツコツとやっています。

マイクロサービスの今

―― tokuhirom
7年目だともうわからないかも知れませんけど、LINEの開発体制で他の会社と違うなというところってどんなところですか?

―― 熊井
違うところですか…。LINEはタスクフォースというのが特徴的かもしれないですね。例えば、なにか解決するべき問題があったら専用の期間限定のチームを作って、それは組織図上でいうとどこの部署からでも集めるんですけど、それをタスクフォース(TF)と呼んでいて、解決したら解散するというやつですね。LINE@作るぞ!とか、そういう。ちなみに自分はBOTがメインなので、あまりTFには参加してないですけど。

それと、LINEの開発体制で特徴的だなと思うのは、障害レポートを毎回ちゃんと書いているっていうのがありますね。メトリクスみたいなものを貼って、この時間にこれがこうなってリクエストが増大して、この負荷がこうなって、としっかりレポートがまとまっています。社内がマイクロサービスなので、思わぬところが伝播してくるというか。DevDayでの那須さんが発表された LINEが乗り越えてきた困難な問題 でいうと、着せかえのデータ更新がトリガーになった事例でしたけど「え?そこから?」みたいな。

―― tokuhirom
着せかえ担当の人も自分のところだとは思わなかったんじゃないかと思いますよね。

―― 熊井
そうですね「これの何が問題なの?」みたいなところはありそうですよね。なので、自分の担当しているサービスのレイテンシってすごく大事で、自分のところが遅いと他のサービスのスレッドを一本専有するっていう意識がないといけない面がありますね。

―― tokuhirom
最近は、非同期に書いてない方が悪いみたいな雰囲気があるという噂を聞いたんですけど。

―― 熊井
何かあって処理するという時、コール自体は低いレイヤーでは非同期にしていても結局待たないと先に進めないとなったらもう意味がないので。たとえば認証とかそういう周辺サービスのレスポンスが遅くなると、busyスレッドの数がバンと上がってアラートがあがって、開発者のLINEグループで「どうなってますか」って共有されて確認するようなかんじですね。APIのレイテンシはかなり気にしますよね。

―― tokuhirom
マイクロサービスの呼び先が国内だけじゃなく、他の国のチームも関わってきてますよね。

―― 熊井
なかなかこのくらいの規模でサービスしているところもそんなに多くないと思うんですけど、そんなにマイクロサービスでAPIが乱立しているところも無いと思うので特徴的かもしれないですね。

BOT開発が盛んな世の中に

―― tokuhirom
最後に、もっとこうなればいいのになーという要望みたいなものってありますか?

―― 熊井
そうですね、わりと僕がやっている仕事は地味なものも多いので,そういうことも一緒にやってくれる人が増えると嬉しいなと思います。運用というか、そういうのが多いので。

BOTサービスでいうと、もっと流行ってほしいなという気持ちはありますね。2月末が締め切りですけど、賞金1000万円の LINE BOT AWARDSもありますし、いいですよね。BOT作るの自体は難しくないんですけど、どういうBOTを作ればいいかわからないというのはあるかもしれませんね。BOTを頑張って作ったんだけどトラフィックが全然ないっていうのも寂しいかなとは思いますけど。

Messaging APIを去年リリースした時に、モニタリングしてても「全然トラフィックこないな」っていうことがあったんですけど、その後かなり増えてきていて驚きがありますね。

LINE BOT AWARDS
―― tokuhirom
LINE BOT AWARDS の応募しているもので、友だち数が1万人超えているのもぼちぼち出てますしね。

―― 熊井
そうですね、BOTがもっと盛り上がっていくといいなと思います。サーバ側はなんとかしていきますので。

LINE Engineer Insights Bot

LINE Engineering Blog 2017.02.16

Add this entry to Hatena bookmark

リストへ戻る