Messaging Platform 開発室の下に3つのチーム
今井祐介氏（以下、今井）：本日は「Messaging Platform 開発室の紹介」をしたいと思います。今井です。よろしくお願いします。
まず今日のアジェンダですが、まず開発室の紹介と具体的にやっていること。あと今後やりたいことという部分と、現在のやりがいであったり求めている人物像を紹介します。最後に、現在使っている技術スタックに関しても紹介したいと思います。
最初に、私たちの開発室に関しての紹介ですが、大きく3つチームがあります。Messaging Platform 開発室の下にZ Part、N Part、IMF Partという3つのチームが現在ありまして、具体的にやっていることがそれぞれ違っています。
Z Partに関して言うと、ストレージ関連のレイヤー開発チームになりまして、N Partは、自身が所属しているチームになりますが、アプリケーションレイヤーの機能開発であったり運用をするチームとなっています。IMF Partは、現在社内のいろいろなところでKafkaが使われている中で、社内向けのKafkaをプラットフォーム化する運用をしているチームとなっています。
基本的にはLINEのバックエンド開発
Messaging Platform 開発室の主な担当範囲ですが、基本的にはLINEのバックエンド開発です。LINEのクライアントとの間にロードバランサであったり、LEGY（LINE Event delivery GatewaY）と私たちが呼んでいるHTTP2であったり、SPDYのリバースプロキシ的なものになるんですが、裏にtalk-serverと私たちが呼んでいるメッセージングのバックエンドサーバーがいます。
そのtalk-serverがストレージを使っていて、この2つのtalk-serverとストレージに関してが今の主な担当範囲となっています。その他コラボレーションしているサービスがいくつかありまして、そこに対しての開発サポートやAPI提供もやっています。
具体的にやっていることですが、直近数年間で担当した主な機能開発というところで、主にはメッセージ関連ですと、送信取り消し機能というところです。メッセージを送ったあとに間違って送信してしまったと気づいた状況で、そのメッセージを取り消したいなど、そういう時に使う機能を近年はリリースしています。
あとはメンション機能です。他のチャットサービスでも利用されている機能をLINEのユーザーニーズに沿った形で提供しています。また、資料内の一番右側に表示している画面のホームタブと呼ばれている画面に、これはフレンドリストと呼んでいて、この中で、今日が誕生日の友だちをお知らせしたり、そういう情報を通知として送る機能も開発しています。
それからチャット画面です。その画面内で、今は季節ごとに配信したりしていますが、例えばクリスマスであったりバレンタインであったり、そういう季節性のイベントの時に、チャット内で何かをトリガーとしてエフェクトを表示するような機能をサーバー経由でクライアントに配信する機能であったり、その他諸々コア機能に付随するような機能を開発しています。
クライアントとサーバーの情報の不一致の修正
2つ目は、これはどちらかというと改善系のタスクにはなるんですが、どうしてもすでに10年近く運用しているサービスなので、いろいろな問題が起きているところがあって、例えばその1つとして、クライアントとサーバーの情報の不一致があります。
具体的に例えばサーバー側では友だちの数が2人となっているのに、クライアントのストレージでは3人となっているとか。何が原因かわからないですが、過去にあった障害やバグが原因で、不一致が起きていることが多々あったので、それを解決するような施策として、定期的にAPIを呼んで、その人の誤差があった場合にはシンクしてもらう。
シンクと言っているのは、クライアントからサーバーに対して情報をすべて同期するような作業でその結果、不一致が解消されます。そういうものをリリースしたりもやっています。こちらは私たちはLINT（LINE Improvement for Next Ten years）と呼んでいまして、2019年のセッションで発表していますので、よかったらご覧ください。
リトライして最後までメッセージが確実に送信される仕組み
3つ目は、やはりこれも改善系のタスクにはなるんですが、昨今データセンターの障害や諸々の問題が起きている中で、メッセージの送信失敗時にリトライができる。要はクライアント側で失敗したりサーバー側で失敗したりした時に、内部的にストップしてしまうのではなくて、ちゃんとリトライして最後までメッセージが確実に送信される仕組みを考えたり。
そのメッセージを送信するのがもっとも重要なのですが、それに入らないような機能もたくさんありまして、そういう部分の性能を求められない機能に関して、今運用・開発・保守をしている同期サーバーから別のサーバーに移動するなどして非同期化対応をしたり、あとはCircuit Breakerを導入して、一時的にそのメインの機能に影響がないように、ある機能へのリクエストのブレーカーを落とすようなかたちにして、メインの機能を守るような対策を実施しています。
あとはどうしてもいろいろなユーザーがいる中で、悪意の持った方もいるんですね。そういう方の対策として、スパム検出の仕組みを導入したり、その一部のユーザーが非常にアクセスが多かったりする場合もあるので、そういう場合にも、HotSpot Issueと私たちは呼んでいますが、そういうボトルネックになっている部分に関してキャッシュを導入したり、RxJavaやKotlinのコルーチンを使ってノンブロッキング化を進めたりしています。
その他の開発
その他ですが、こちらはどちらかというと自身が所属していないZ PartやIMF Partでやっていることになるんですが、カオステスティングですね。実際に機能開発や新しい機能を追加する時に、実際に本番環境で問題が起きてみないとどうなるのかわからないことがありますので、1つノードを落としてみたりして、実際の影響を確かめてみるであったり、そういうこともやっています。
今は、どうしても1つのサーバーに集中してしまったり、ストレージ側に関しても1つのクラスタに多くのデータが混在してしまったりしているので、そういう単一障害リスクの低減を考えて、そのサーバーの分割を持つように進行しています。
こちらがもっとも重要になりますが、LINEはどうしても年末年始に発生するトラフィックが非常に多くて、その時にユーザーにも非常に多く使ってもらえるということで、私たちとしては非常に重要視しています。毎年年末前から始まりますが、サーバーの増強の準備をしたり、去年の結果を見直したり、毎年そういう改善を実施して、継続的に年末年始に影響がないように努力しています。
今後やりたいことその1：ストレージの統合・改善
こちらは、今後やりたいことで、すでにやっていたりするんですが、いくつか書いています。やはり10年運営している中で、ストレージの統合・改善であったり、機能の部分でも統合・改善が必要だなというのがありまして、そのバックエンドのシステムが同じような機能なのに、別々に点在していたりすることもあるので、それをコストであったり今後のメンテナンス性を向上するために、統合や改善を進めているところです。
そのストレージやサーバーまわりに関しても、1つのIDCが落ちた時でもちゃんとサービスが継続することは、LINEにおいては非常に重要ですので、Multi IDCやHA構成の推進も進めています。マイクロサービス化においては、今どうしても一極集中してしまっている、先ほどのメッセージングバックエンドをできるだけ分割して、他の部署でもできているようなマイクロサービス化を推進していきたいと思っています。
2019年に弊社の井出が、マイクロサービス化に関してのセッションをやっていますので、よかったらご覧ください。2019年から長い道のりということになっているんですが、今でもなかなか長い道のりとなっています。
今後やりたいことその2：Social Graphの改善
今後やりたいことその2は、Social Graphと言いまして、具体的には友だち関係を構成するシステムで、友だちと友だちの関係をSocial Graphと呼んでいます。そのバックエンドにシステムがあるんですが、こちらも非常に拡張性に問題がありまして、信頼性もさておき、新しい機能を追加する時であったり、何か問題が起きた時を考えると、現状では改善が必要だなというところがありまして。現在のチームでは注力しようとしているところです。
サーバー、クライアント間のプロトコルの改善に関しても、これは具体的に言うと、LINEクライアントとサーバー間で使っているプロトコルにThriftというものがありまして、これはオープンソースでもありますが、こちらをLINE社内において一部カスタマイズして使っていまして、この部分に関して、今後10年間見据えて本当にこのまま使っていいのかであったり、今のメンテナンス性のままでやっていけるのかの議論を始めています。
こういうところが、今の、どちらかというと自身が属しているN Partによった内容にはなりますが、今後やりたいこととなっています。
Messaging Platform 開発室のやりがい
次に、サーバーエンジニアとしてのやりがい、求める人物像ですが、サーバーチームと、クライアントチーム、企画チームがあって、開発する時というのは基本的にこの3つのチーム＋UI/UXを見ているところであったり、QAチームとコミュニケーションを取りながら開発していくことになります。
今のチームは開発のチームで、サーバーのみを見ているチームになるんですが、何か新しい機能開発が必要になった時に、プロジェクトが作られまして、それぞれのチームから何人かが選ばれて担当するようになっています。
やりがいというところなんですが、やはり社会的インフラになっていることで、インパクトが非常に高いので、そこの部分のプロダクト開発経験がやはり大きなやりがいになっているかなと思います。それに伴って、トラフィックに関しては非常に大きいので、1日数百億単位のメッセージを処理するようなサーバー開発ができるところが、なかなかできない経験だなと思います。
自分自身、何社か今まで経験していますが、なかなかこれぐらいの規模感で日本内で開発できることはないなと、日々実感しています。Z Partに関しては、メッセージングのサービスレベルの開発運用からストレージの奥深い所まで関われるため、エンジニアとして非常にやりがいを感じられると思います。
それ以外に、日本以外でも、LINE自体はグローバルにやっていまして、台湾、タイ、インドネシアでは非常にユーザーが多いので、そういう部分でグローバルなサービス開発にも参加できる、というところ。
現在の開発室の中では非常に多種多様なバックグラウンドを持つエンジニアが多くて、国籍もそうですし、そのそれぞれの経験が非常にバラエティに富んでいて、かつそれぞれでOSSのコミッターであったり、そういう貢献も多くあるようなメンバーも多く在籍しているので、そういう部分で刺激が多いのかなと思っています。
Messaging Platform 開発室に求める人物像
求める人物像ですが、やはり社会インフラとして使われていますので、そういうプロダクトを運営している責任感が重要なのかなと思っています。365日24時間運用していますので、深夜であってもやはりユーザーのために、責任を持って対応しないといけないこともあります。
そういうところと、今のチームですと、アーキテクトというポジションは特に持っていないので、エンジニア、サーバーエンジニアがそれぞれ開発に設計段階から開発して、企画チームとClientチームと話をしながら、イチからサービスを設計できるところもあります。
どちらかというと、今のN Partだと、APIの開発が主になりますので、APIの信頼性であったり、可能性、一貫性を、すでにあるものも含めて改善に興味がある方。それと、こちらはストレージに関して非常に思入れが深い方々が多いチームなので、特にHBase、Redis、Kafkaという部分への興味が非常に高い方が多く、分散ストレージまたはミドルウェア関連にすごい興味があれば、HBase、Redis、Kafkaに関係なく、いいのかなと思っています。
あとは、やはりネイティブアプリの開発になるので、ネイティブアプリの開発経験というところ。わりと担当範囲が広いチームなので、新しいものをイチから作る人であったり、すでにあるものを改善していくであったり、そういう部分の、わりと得意分野に合わせて活躍している人が多いのかなと思っています。
Messaging Platform 開発室の技術スタック
技術スタックです。基本的には他のチームと同じように、コアの部分ではKafka、Redis、HBaseとなっています。基本的には、オンプレでやっているので、監視システム自体もインターナルなものになっていますが、わりとOSSを使うことが多いのかなと思っています。Javaに関しても、今だいたい11になっているのと、直近は新しい部分に関しては、Kotlinのコルーチンを多用して、ノンブロッキングで作ることが多いです。
プロトコルに関しては、ThriftであったりgRPCを使うことが最近は多いです。以上となります。
Messaging Platform 開発室の募集ポジション
最後になりますが、Messaging Platform 開発室では、主に2つのポジションを絶賛募集しています。1つ目は、先ほどのN Part側の開発で、APIの開発をしたり新機能の開発をしたりすることが多いですが、そういうサーバーサイドエンジニアになります。
もう1つは、Z PartであったりIMF Partで、分散ストレージとかミドルウェア関連のポジションになりまして、こちらも非常におもしろいモチベーションを維持できるような仕事になっていますので、よろしくお願いします。
ご応募お待ちしています。以上となります。
