LINEのプラットフォームを支えるアーキテクチャと組織の作り方 #linedevday

LINEは4月28日、エンジニアを対象とした初の大規模技術カンファレンスとなる「LINE DEVELOPER DAY_2015 Tokyo」を、渋谷・ヒカリエホールにて開催した。本稿では、同イベントの午前中最後のセッション「A-4: LINE Platform Development Chronicle」についてレポートする。

同セッションでは、同社開発1センター LINE開発1室所属のTom Tsuruhara氏が、「LINEメッセージング基盤の進化」「LINE流マイクロサービス」という二つのテーマをもとに、LINEのプラットフォームを支えるアーキテクチャや組織、文化について解説した。

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

2011年6月にスマホ用チャットアプリとしてスタートしたLINEのアーキテクチャは当初、至ってシンプルで一般的なものだった。


LINE 開発1センター LINE開発1室 Tom Tsuruhara氏	LINE 最初期のアーキテクチャリバースプロキシはApache、アプリケーションサーバはTomcat、バックエンドにはRedisとMySQLを使用していた

メッセージの送受信にはPollingを使用していたが、無駄なrequest-responseが発生するため電池を消耗してしまうといった問題や、外部の仕組みに依存していたPush通知をコントロールできず、メッセージが遅延するなどといった問題があった。

そこで同社は、long pollingを実装することでこの問題を改善。ApacheのリバースプロキシをNginxと拡張モジュールに置き換えた。


Push通知に変わる通知手段 long polling クライアントとサーバの間にゲートウェイ層を導入	ApacheのリバースプロキシをNginx＋拡張モジュールへ

しかし、LINEのユーザー数が1,000万人を超えた2012年1月ごろ、メモリ上でのプロセス間の同期処理がうまくいかず、Segmentation Faultを起こすようになったという。

Nginx＋拡張モジュール実装の問題点

同期処理のデバッグを行えば安定化させることはできたが、同社はメッセージングのコアの部分でこういった不安定性を抱えていたことを問題視し、Nginxの層をErlangに置き換えるという選択をする。

Erlangを使えば、軽量プロセスを多数並べてメッセージパッシングで並行性を保つことができるため、「我々に合う感じだった」とTsuruhara氏。さらに、分散のしやすさ、高レイヤーのプログラミングができること、ホットスワップにより無停止デプロイが可能となることもErlang採用のポイントだ。

こうして同社は2012年の春から夏にかけてゲートウェイ層をErlangへと置き換え、LINE Event Delivery Gateway(LEGY)と名づけた。

LINE Event Delivery Gateway(LEGY)の導入

この問題とは別に、2012年7月ごろになると、クライアントとサーバ間のコネクション数が多くなるという問題が発生。同社はキャリアと協力しながらこの問題に対処していったが、プロトコルレベルでのコネクション数削減の対策として、HTTP(S)からSPDYへの変更を決めた。

当時、Googleから提唱されたドラフトのプロトコルであったSPDYだが、同社が直面した課題をほとんど解決するものであり、「迷うことなくLEGYとクライアントに実装した」(Tsuruhara氏)。その結果、全体のコネクション数を半分から1/3にまで減らすことができたという。

SPDYを使った最適化

また、2012年10月には、海外でのパフォーマンスを追求するため、海外の拠点に「Global POP」と呼ばれるデータセンタを置き、ロードバランサとLEGYを設置。Global POPのLEGYとメインデータセンタの間を専用線で接続した。さらに、バックエンドの応答を待たずにクライアントへレスポンスを返すという「非同期メッセージ送信」の導入により遅延を減らし、UXを向上させていった。

非同期メッセージ送信

同社はその他にも、アプリケーションサーバや既読のロジックの最適化など多くの施策を講じてきたが、メッセージ基盤については、初期のアーキテクチャを骨格として進化させてきているようだ。

LINE流マイクロサービス

LINEはメッセージングの機能以外にも、タイムラインやスタンプなど、サービスの成長に伴いさまざまな機能を追加してきた。これらのサービスは、スピード、機能、品質のすべてが求められるものであり、同社はこれを実現するためにマイクロサービスの考え方を採用した。

モノシリックなシステムでは、新しく優秀なエンジニアを採用したとしても、全体像を把握しなければ新しいサービス開発に着手することができない。そこで、サービス間をAPIなどでつなぐことによって、新しく参加したエンジニアもすぐに新機能の開発に着手できるようにしている。

たとえば、メッセージング基盤のアプリケーションサーバである「Talk-server」には、メッセージングとソーシャルグラフに関する機能しか実装されていない。それ以外の機能は別のサービスとして動いており、それぞれ独立したチームが開発を行っている。また、開発プロセスやデプロイのフローもそれぞれ独立しており、Talk-serverはJavaだが、アカウント管理はScalaといったように、開発言語やミドルウェアもバラバラなものを使ってよい。

これについてTsuruhara氏は、「複雑なシステムが出来上がっているように見えるが、個々のサービスの独立性が高いため、全体としてはシンプルで効率のよい開発ができている」とメリットを説明した。

別々に開発した各サービスをAPIでつないでいる

こういった開発環境を実現するために同社では、組織図や会社をまたいだアドホックなチーム形成を行い、短期間でイテレーションをまわし、目的を達成したらチームを縮小または解散するといったような組織作りをしている。

一方、こうした方法では多くの開発チームができるため、共通して必要になってくる部分ももちろんある。そこで、同社は、GitHub Enterpriseでコードを管理、JenkinsでCIをまわし、内製のツールを使ってデプロイやリリース後のモニタリングを行うなど、共通の開発フローに応じたファシリティを用意し、これをベースに開発を行っている。

LINE流マイクロサービスを支えるファシリティ

「まだマイクロサービスという言葉がない時代からはじめたスタイルなので、いびつなところはあるが、マイクロサービスのメリットとされているものは享受できている」とTsuruhara氏は自信を見せた一方で、今後の課題として、Talk-serverの巨大化による分割の必要性を挙げた。また障害設計の管理が不十分なところもあるため、今後はより整備を進めていく考えだ。