[レポート] LINEのメッセージングプラットフォームにおけるマイクロサービス化への長い道のり #linedevday_report

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

2019年11月20日（水）・21日（木）にグランドニッコー東京 台場でLINEのデベロッパーカンファレンス「LINE DEVELOPER DAY 2019」が開催されました。

• LINE DEVELOPER DAY 2019

本記事は、セッション「LINEのメッセージングプラットフォームにおけるマイクロサービス化への長い道のり」をレポートします。

スピーカー

井出 真広 氏（LINE Z Part Team）

サーバーサイドのソフトウェアエンジニア。LINEのスタンプショップや着せかえのバックエンドサービスの開発、運用に従事した後、現在はLINEのメッセージングプラットフォームの開発やRedis storageの運用を主に担当しています。非同期処理や分散システムが好き。

セッション概要

コミュニケーションアプリ「LINE」のサーバーアプリケーションは2011年に１つのアプリケーションサーバーから始まりました。それから8年の間、LINEの成長スピードに対応するため、マイクロサービスを採用しサービスの規模や開発スピードを高めてきました。しかしながら、このマイクロサービス化は全てが上手くいったわけではなく、未だにモノリシックなサービスも抱えながら、日々システム、開発組織、開発プロセスの改善を続けています。このセッションでは、メッセージングプラットフォームのマイクロサービス化を通じて我々が学んだこと、メリット、デメリットについてお話いたします。

スライド

レポート

• Messagingサービス開発を行っている
• 特にマイクロサービスアーキテクチャの取り組み
• メッセージサービスを最短でリリースするというミッションでスタートした
• スケールするとやりたいこと、やらなければいけないことなどたくさんのミッションが生まれ調整が必要になり1 teamではできなくなった
• コア機能とは別にFeatureに切り出したチームを作成しリリースできるような体制にしていった
• 相互にAPIやRPCを呼び出しあう状況で大きなマイクロサービスアーキテクチャーになった
• チーム・機能ごとにフォーカスしながら適度な粒度で管理している
• マイクロサービスによってコンフリクトは減ったが、1つの大きいサービスを分割することによってネットワーク量の増加、障害のリスクも増えた
• 3つのPoint
  • Connectivity
    • Armeria - クライアントサーバーライブラリ
      • ネットワーキングライブラリを使うことがメッセージングサービスを構築する上でメジャーになっている
      • ロギング、分散トレース、サーキットブレーカーなどが最初から提供されている
      • 自分や相手側の特性に合わせてクライアントを構成する
      • クライアントサイドのLBとして使っている
  • Directory Service
    • Central Dogma
      • サービス間の設定共有を容易にするレポジトリサービス
      • 登録された情報を中央集権的に管理しサービス自体から利用できる
  • Routing
    • LEGY
      • 適切なルーティングを行うゲートウェイ
      • Erlangで実装
      • クライアントから最寄りのデータセンターにアクセスしデータセンタ間は専用線で通信する（LEGYでルーティング）
      • nginxの設定が近い例
      • 正確なホスト名は書かずにCentral Dogmaから情報を取得する
• Case Study
  • スタンプ送信をした時
    • もともとトークサーバー上でやりとりしていたが、2017年で限界を迎えた
    • スタンプ数が激増、ユーザーの保持数も激増したため
    • トークサーバーの中でスタンプの保持者をRedisで保持していた。
    • 保持数が1万を超えるなどが見られたので、送信する度にRedisのスロークエリが投げられ一瞬トークサーバーが止まる
    • 一瞬止まることで様々なサービスへ影響が波及していく可能性もあった（cascading failure）
    • どう対応したか？
      • 責任範囲を分割して、問題が発生した時に波及しない仕組み化
      • コンポーネントのパフォーマンスが落ちる可能性があるが、ArmeriaやCentral Dogmaなどの組み合わせで分割ができるようになっていた。
      • スケール/スピードを犠牲にせずに行えるようになった
• Our Futures
  • サービスをFunction単位で分割するようにしていく

まとめ

高速にサービス提供し、かつスケールをするためのチーム・ツールの活用が見えました。特にCentral Dogmaにおける情報の中央集権管理はサービスがスケールすればするほど重要性があるように思います。