gistfile1.md

A-4 LINE Platform Development Chronicle

11:50-12:30

LINEメッセージング基盤の進化

2011.06

• LINEリリース
• スマホで使いやすいチャットアプリ
• 本格的に開発開始してから2ヶ月でリリース

• アプリケーション Java, フレームワークはSpring

• Pollingを使ったメッセージ送受信

  • N秒待っている間にPUSH通信を入れる

• Polling + Pushの問題点

  • pushの遅延
  • 無駄なrequest-respons -> バッテリーの消耗

2011.09

• Push通知に変わる通知手段 long pollingに変えた
  • Gatewayという層を挟む
    • nginx+拡張moduleでGateway層を追加
  • 外部のpushに依存しなくてもリアルタイムにやりとりが可能に

2012.01

• segmentation fault地獄 * nginxのコアの部分をいじる必要があり、限界を感じた * Erlangを採用し、nginxの層を置き換える * 軽量Processを複数採用し、メッセージパッシングで同期を取る

2012.0X

• LINE Event Delivery Gatewayの導入(ErlangによるGateway層)
  • Erlangの良い所
    • 並行性
    • 分散
    • 高級
    • 無停止デプロイ（hotswap）

2012.07

• Connection地獄 : クライアントとサーバ間のコネクション数が多すぎる
  • Client <-> LEGY
    • Long pollingコネクション
    • その他のAPI用コネクション
    • 常に2本以上コネクションを持っていた状態

• HTTP(S)からSPDYへ変更
  • 1 TCP connection で複数のRequest / Responseをやりとりできる
  • multiplex
  • ヘッダ圧縮
    • 通信量の削減にもつながる
  • これをクライアントとLEGYへ適用

コネクション数が1/2から1/3へ減少

2012.10

海外でのパフォーマンス追求

• Global POPの追加
  • 最寄りのLEGYを探してそこへ接続する
  • 専用線とはいえ距離が遠いとレイテンシが増加する

• 非同期メッセージ送信
  • LEGYのほうで先にレスポンスを返し、クライアントはそのタイミングでUIを次のフェーズに変えてしまう
  • 次にクライアントがイベントを取りに行く時にレスポンスを取得し、エラーの場合は再送する

〜現在

• ストレージをMySQL -> HBaseへ置き換え

LINE流マイクロサービス

• 個々のサービスは独立した状態で動いている

• 全体としてはシンプルに、効率よく開発できる

• バックエンドサービス

  • 認証管理
  • Abusing
  • イベント処理
  • etc

• LINE流マイクロサービスを支える3要素

  • 組織：組織図、会社をまたぐアドホックなチーム構成。短期間でiterationを回し、目的を達成したら縮小 or 解散
  • プロトコル管理
    • Apache Thrift
    • Protobuf
    • REST
  • ファシリティ
    • Jenkins
    • Maren repository
    • PMC(deployツール。内製のもので、ポチポチするだけでリリース)
    • IMON(サービスのモニタリング。内製ツール。ブラウザでビジュアライズ)

今後の課題

• マルチデータセンター

  • ヨーロッパのユーザはヨーロッパのDCでサービスを提供されるべき

• Microservicesの発展

  • talk serverが機能が少ないように見えて実は巨大
    • 分割したい
  • あるサービスが落ちた時の他の影響がどうかという部分の管理ができていない