A-4 LINE Platform Development Chronicle

セッション名：A-4 LINE Platform Development Chronicle
登壇者：Tom.T氏

以下、メモと所感。 【メモ】

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

2011年6月　リリース

・スマートフォンで使いやすいチャットアプリ

・本格的に開発開始してから2ヶ月でリリース

アプリケーションサーバーはJava、フレームワークはSpring

ここは今も変わっていない


 

Polling+push通知によるメッセージングの問題点

・Pushの遅延

・無駄なrequest-responseによるバッテリー消費

→　long pollingによって解決

Gatewayが中継してクライアントとサーバーを接続

外部のPUSHに頼らなくてよくなった

1000万ユーザーくらいになると

nginxのゲートウェイがsegmentation faultが発生するようになった

 

2012年

nginxのコアな部分をいじらないといけなくなった

→ Erlangに置き換え

LINE Event Deliverry Gatewayの導入 

 




 

同じポーリングのセッションで既読やフレンドの更新なども処理している

2012.7

コネクションが多すぎる問題が発生

プロトコルレベルでコネクション数を減らす努力をした

HTTPからSPDYへ

SPDYだと1つのコネクションで複数のリクエストを処理できる

→　トータルのコネクション数が半分から1/3程度に





 

2012.10

海外でパフォーマンスが悪かった

→海外のデータセンターにPOPを置いた

専用線があってもレイテンシーはどうしても発生する

→　非同期メッセージ送信処理を追加

MySQLをHBaseに置き換え

 

2.LINE流マイクロサービス

 

LINEサービスの成長

・動画メッセージ

・音声、ビデオ通話

・スタンプ販売

・公式アカウント

など…

スピード、機能、品質全てが求められる

開発スタイル： micro service

システム全体を把握するのが難しいので

個々のサービスを個別に開発して、APIなどで連携している


 

チーム、デペロイメント、開発プロセスはプロジェクトごとにバラバラ

組織

・組織図や会社をまたぐアドホックなチーム形成

・短期間でイテレーションをまわし、目的を達成したら縮小あるいは解散

・誰が何を開発しているのかが分かるようになっていない


 

プロトコル管理

RESTだけでなくApache Thrift, プロトコルバッファも使っている

Thrift→各種言語

ファシリティ

PMCという内製ツールでデプロイ

IMONという内製ツールでデータをビジュアライズ

 

■今後の課題

・マルチデータセンター

海外のDCにはフロントエンドのみ

バックエンドのLINEサービスは別のDCにつながないといけない

拠点ごとに独立するようにする

・マイクロサービスの発展

トークサーバーが巨大化しているので分割する

1つのサービスが落ちると全体に影響する
 

【所感】
仕事上、スケーラビリティを求められるサービス開発が求められるようになってきたので、個人的には一番楽しみにしていたセッション。
LINEが今のような大規模サービスに至るまでに発生した問題と、それをどのように解決してきたかを説明してくれた。
最初はベーシックなアーキテクチャだったが、サービス利用者が拡大していくにつれて発生する課題に対処するため、アーキテクチャを徐々に変えていく様子を時系列的に説明してくれて分かりやすかった。

フロントエンドはErlangでマルチプロセス処理してるんですね。
そしてコネクション数が限界に達したので、APIのプロトコルをHTTPSからSPDYに変えたと。
ここはすごく参考になりました。勉強したいと思います。