- TOMU TSURUHARA
- 11:50-12:26
- A-5
- http://linedevday.linecorp.com/jp/2015/#t1s4
- LINE全体のアーキテクチャの話
- 2011年6月 LINEリリース
- スマートフォンで使いやすいチャットを
- 早くリリースしようということで2ヶ月程度の開発期間
- 通常のWebサービスと同様のアーキテクチャ
- Java/Spring, Redis/MySQL
- クライアントからのポーリング
- サーバからのpush通知も利用
- pushは外部システムなのでコントロールできない。場合によっては遅延する
- 無駄なポーリングが多いので、致命的に電池を食う
- push通知に変わりlong pollingを実装
- クライアントによってはずっとコネクションを持っていることがむずかしいので、その場合は従来通りpush通知
- Gateway層の導入
- nginx + 拡張モジュールでlong pollingを実装
- nginx が segmemntation falt で落ちることが頻発してくる
- メッセージパブリッシュのための共有メモリの同期処理に問題があった
- nginx のコアをいじらなくていけない
- Erlang に移行
- 並行性、分散、抽象度が高い、無停止ホットスワップ
- 元々通信会社で開発された言語なのでメッセージングと相性が良い
- Gateway 層を Erlang に置き換え
- LEGY (LINE Event Delivery Gateway) と名付けた
- 2012年7月頃にクライアント/サーバ間のコネクションが多すぎる問題が発生
- Long Polling 用のコネクションを貼り続け、API コール用に別コネクションを利用
- スピードを稼ぐために割りと富豪的にコネクションを貼っていた
- SPDY を利用して1コネクションにまとめて多重化した
- コネクションを減らしつつパフォーマンスを上げれる
- ヘッダ圧縮によって地道な通信量の削減
- コネクション数が半分から1/3へ
- 2012年末ごろ 海外でのパフォーマンス改善
- サーバはメインのデータセンターにあった
- 海外拠点に GLobal POP を置く。
- POP には LEGY が置かれる
- LEGY と Gateway は専用線で接続
- 非同期メッセージ送信
- 専用線とはいえ遅延は発生する
- LEGY はバックエンド応答を待たずにクライアントに ACK を返す
- もしエラーが起きたら次のリクエストの際にエラーを返す
- ストレージをMySQLからHBase に変更
- アーキテクチャ的には現在も変わっていない
- サービスメニューが増えるに連れて開発スピードも上げなければいけない
- マイクロサービス的に個々の機能を独立させて開発
- API でつなぐ
- Talk-serverはメッセージングとソーシャルグラフだけを受け持つ
- その他のサービスはそれぞれ独立に開発されている
- 言語、ミドルウェアはそれぞれ別で構わない
- 個々のサービスの独立性が高いので、新しいサービスをシンプルに開発できる
- 開発するチームも独立して存在しなければいけない
- 組織図上では誰が何を作っているかは分からない
- アドホックにチームを形成して短期間に開発を行う
- サービスプロトコル管理
- Apache Thrift, Protobuf で管理している (一部 REST)
- インターフェース定義言語 (IDL)
- IDL はテキストベースなので github 上で議論ができる
- 微妙なインターフェースを乱立させるとサービスがいびつになるので、議論は大事
- ファシリティ
- 各チームで共通して必要なインフラはきっちり準備する
- github enterprise
- Jenkins,
- Maven Repository (Javaの場合)
- PMC (独自デプロイツール)
- IMON (独自モニタリングツール)
- 今後の課題
- マルチデータセンター
- 現在は海外データセンターにはフロントサーバしか無い
- その地域のサーバだけでサービスを運用できるようにしたい
- マイクロサービスの発展
- TalkServer は実は結構巨大なので分割したい
- あるサービスに障害が起きた時に全体がどうなるか
- マルチデータセンター
- 午後のセッションで掘り下げます。