Ryu's blog

アウトプットしていきたい

LINE DEV DAY 2019 にちょっとだけ参加しました

linedevday.linecorp.com

LINE社が主催&他社スポンサーなしで開催された Developer 向けのカンファレンスです。

数年前から開催されているみたいで、今年は初めての2日間開催らしいです。(自分は今年初参加でした)

とてもお金と人員コストがかかっており、社員の方が言うには2ヶ月ほどこのカンファレンスのために時間をかけて用意したらしいです。(納得できるほどの規模のカンファレンスでした!)

午前中から開催されているのですが、自分は初日のみの参加 + 16時頃からカンファレンス会場に到着して見て回ったので、共有できる情報がとても少ないですが、書き残しておきます。

公開可能な発表資料は下記のリンク先にあるので、参考に。

Presentations by LINE DevDay 2019 - Speaker Deck

セッション・ショートトラックの発表

LINE DEV DAY 2019 では、大きなホールでの発表となるセッションとホールなどを使わずに一区画を使用したショートトラックがありました。

自分の聞いた発表は全部で3つほどですが、簡単に紹介します。

Kotlinによるシンプルかつモダンなサーバーサイドエンジニアリング(short track)

19新卒エンジニアの方の発表でした。同じ新卒エンジニアとは思えないほどハキハキとした発表をしていました。

基本的に社内で開発しているシステムはSpringBootなどを用いてJava製。
全体の社内リポジトリの割合を調べるとJavaは90%で残りの10%はKotlinで作成されているとのこと。
新しい機能はKotlinで開発するという部署もあるそうです。

Kotlinのメリットに関して
* Javaと相互併用できる(JVM) * 学習コストが小さい * 定義の時点で Nullable と NonNull を決めることができる

開発環境としては
言語:Java・Kotlin
フレームワーク:Spring Boot
ORMapper:Mybatis

上記を使用しているとのことでした。自分が今開発しているプロダクトと全く同じ構成でした。

また、Kotlinでは拡張関数が使えるのがメリットであり、実際にプロダクトで拡張関数を実装した実例を話してくれました。
自分もKotlinを用いた実装で、拡張関数を実装したことがあるのでとても同意できる点でした。

他のKotlinのメリットとして、プロダクトの低いレイヤーで定義部分から NonNull と Nullable の設定をすることでヌルポが防げるという話でした。
Javaであれば、ヌルポを防ぐために Null チェックを実装しないといけない + ヌルポが発生した時に Null の発生箇所を探し出すのに苦労しますが、Kotlinでこれを防ぐことが出来る点があるという話でした。
Kotlinの大きなメリットの1つですね。

Spring Bootを使用しているプロダクトでKotlinの導入する懸念点として、KotlinとLombokの併用にはアノテーションの兼ね合いでエラーが起こる可能性があり、そのエラーが起きた時に原因を見つけるのがなかなか難しくなるということで、この点の考慮は必要だと感じました。

エンタープライズレベルのGradleマルチプロジェクトへの過程 - Gradle構築レシピ(short track)

マルチプロジェクトで開発されているプロダクトで、Gradleによりライブラリ管理が二重管理になるというのが手間となるというので、2重管理にならないようなGradleプラグインを開発したというお話でした。
新しいライブラリを導入するときに複数のGradleに同じ記述を書かなくてよいのは便利だと思います。
他にも、ライブラリを追加・変更した場合、その影響がどのレイヤー、クラスまで影響があるのかをログ出力するというプラグインを作成したお話でした。

実際に開発されたプラグインはOSS化されて公開されているとのことなので、どのプラグインかわすれてしまったので調べて見つけたら、改めてリンクを貼り付けようと思います。

LINEのメッセージングプラットフォームにおけるマイクロサービス化への長い道のり(session)

speakerdeck.com

最初はモノリシックなサービスでサービス開発をしていて、TalkServer なるものがすべてのサービスを提供していたそうです。
新規のサービスを作ろうとしたときに、今までのサービスの成長させるか、新たなサービスをするのか などの開発に関して様々な観点で考慮しなければならない点が増えて大変なことが多かった。

60万行越えるほどのモノリシックな状態だったそうです。

今ではそれぞれのサービスで開発を行っていて、1つの大きなTalkServerを分割していったそうです。

そのために、LINEが独自に開発したものが大きく3つあり、RPCのArmeria、ConfigurationツールのCentral Dogma、RoutingツールのLEGYというものがあるそうです。

Armeria
LINEが開発した RPC/REST ライブラリのArmeria
クライアントサイドのロードバランサーだったり、サーキットブレーカーやリクエストに関するロギングなどを組み合わせたものみたいです。
OSS化されているので詳細はライブラリを御覧ください。

GitHub - line/armeria: Asynchronous RPC/REST library built on top of Java 8, Netty, HTTP/2, Thrift and gRPC

Central Dogma
Textual Configuration で YAMLやJSONなどのテキスト形式で設定を行うことが出来るものみたいです。
障害に関する仕組みづくりや設定に関してロングポーリングなどでPullやPushなどでコンフィグレーションが見れるそうです。
こちらもOSS化されておりますので、詳しくはリポジトリを見てもらうと良いかもしれません。

GitHub - line/centraldogma: Highly-available version-controlled service configuration repository based on Git, ZooKeeper and HTTP/2

Hostsなどのエンドポイント情報をそれぞれのサービスを簡単に結びつけてくれたりなどをしてくれるようです。

LEGY(Line Event Gateway)
LINE者が開発した API Gateway で Erlangで開発されている。 SPDYを使用して独自で開発している。
どのURL(パス)に対して、どのサービスを結びつけるのかなどの Routing 機能を持ち、nginxに近いみたいです。

以上の3つの大きなプロダクトを使用して、モノリシックな状態からマイクロサービスアーキテクチャ化していったそうです。

ブースでの発表

セッションなどのLT発表以外にも色んなサービスを紹介するブースが用意されており、色んな内容を見聞きすることが出来ました。

全部は回ってないですが、訪問したブースの話を載せておきます。

LINE PAY

LINEのサービスはPrivate Cloudですべてのトラフィックやデータを所持している。
LINEPAYはサービス停止などになったことはなく、全部が落ちたことはほぼない。
なので、メンテナンスとかで夜中に起こされることなどがない。(とても羨ましいですね)

自社の持つクラウドがすべてのトラフィックを捌ききれるので、メンテナンス状態にすることもほとんどないそうです。凄いですね!

LINEにおけるObservabilityプラクティス

大規模なサービスを提供しているLINEのサービスで用いている監視ツールのお話です。

ログツールも基本的にPrometheusやMicrometer、Zipkinなどを使用していて、Saasは基本的に使用していない(Datadogなど)。

その理由として、他の会社にデータを渡さずに会社自身がデータを保持できる。
ログツールごとに専属のエンジニアがいるので、サービスを全部統一してログ出力することができるということを上げていました。

LINE UIテスト自動化

UIテストの自動化は自分たちの部署でもあるので、LINEの話を伺いに行きました。

LINEのサービスでUI自動テストを実施してるのは5サービスほど。
基本的にはQA社員が手動でテストを行っているみたいです。その数なんと約200人!
ほとんどは手動テストで動作検証しているそうです。

UIテストの自動化をしている各サービスには、UI自動テスト専属のエンジニアがいて、QAの非エンジニアの方にもわかるようにログの可視化ツールなども内製している。
実際にそのレポート作成ツールを見せてもらいました。
UIテスト専属エンジニアの方は、機能開発のミーティングなどにも参加してどんな機能が出るのかなどの確認も一緒にするそうです。
基本的に新しいサービスは手動で行い、古いサービスを自動テストしているとのことでした。

店舗とポイント還元 - 台湾のLINEショッピングにおけるパーソナライズされた購入体験

台湾のLINEからのブース出展でパーソナライゼーションに関する展示がありました。
LINEショッピングなどのレコメンドでいいねや購入した商品、クリックなどから商品のレコメンドを行っている話でした。

このパーソナライズのおかげで +100%(2倍) に購入する人が増えたみたいです。

このシステムではレガシーな部分が残っているみたいで PHP だったり、Node.js だったり、DBもMysqlやMongoDBだったりと色んな開発言語、ツール、フレームワークが使用されていました。

LINE Front-end Framework v2 新機能を使ったウェブアプリケーション開発プラクティス

LIFFというOSS化しているWEBフレームワークがあるらしく、実際にLINEアプリで導入されている物があるみたいです。(乗換案内ジョルダンやGIFアニメーションの選択画面)
LINEアプリにあるサービスの半分ほどはWEBで出来ているみたいで、LINEニュースもWEBで出来ているそうです。

LINE Front-end Framework

LINEのサービスや開発について

LINEの全体的なサービスについて、人事やエンジニアの方とお話しました。

基本的にJavaほぼ100%で最近Kotlinが増えているそうです。
ほとんどのサービスは、Springフレームワークを使用して開発しているみたいで、JAVAのコミッターなどもいるそうです。
新しいJAVAバージョンが出たときには、社内の勉強会を開いて、要点だけを教えてくれたりするそうです。(すごい)

社員数はグローバル全体で6000人。日本の社員数は約2000人だそうです。
エンジニアファーストで役員がログの出力に関して口を出すほどで、執行役員の方がブースで来訪者にサービスの詳細説明を行っていました。

すでに書きましたが、AWSなどの他社クラウドサービスは使わず、OpenStackでプライベートクラウドですべてのサービスを運用しているみたいです。

サービスごとにそれぞれチームが組まれているので、あまり開発のスピードが遅くなることはないそう。
逆に、周りの部署がどんなことしているのかの把握が出来ないみたいです。

メッセージングのサービスも障害などで落ちてはいますが、数秒〜数分で復旧するような仕組みが出来ており、ユーザーからすると「ちょっと電波が悪いのかな?端末再起動してみよう。直った!」というレベルなので障害だと認識されることがほとんどないそうです。

まとめ

LINEの規模が自分の想像より遥かに大きく、エンジニアの数も想像の何倍もの人数が働いてるということでした。
弊社との状況(規模やエンジニアの数など)がかなり違うので、開発などの参考にするには難しい感じでした。ツールとか何から何まで内製でサービスを運用するのは本当にすごいことだと思います。
システムとしては完成形に近いのかなと感じました。障害の仕組みづくりやグローバルな組織づくり、エンジニアファーストなサービス開発などとても良いなと感じる部分がありました。

ただ、悪い部分や課題な部分がほとんど内容として話していなかった部分が多いので、ちょっとどんな課題が今あるのかとかは知りたいなと感じました。
聞いた課題の1つとしては、LINEはサービス開発してから7年以上経っているそうで、改善はしていますがまだまだレガシーな部分があるそうです。

あと、開発言語やフレームワークがどのサービスも同じもの(基本的にJava制でSpringフレームワーク)を扱っているのは結構意外でした。
ちょっとしか参加出来ませんでしたが、行けて色々なお話聞けて良かったです。