LINEの技術的負債を解消している話 ─ HTTP/2へのプロトコル変更やデータ同期の最適化での改善

• 通信プロトコルをSPDYからHTTP/2に移行
• 抽象化レイヤーを設置してプロトコル移行のリスクを低減
• Long PollingをPushへと切り替えて通信量を最適化
• アプリの利用状況に応じて最適なデータ同期の方法を
• アーキテクチャの改善でアプリの信頼性や拡張性が向上

長い歴史を持つアプリには「技術的負債をどのように解消するか」という課題が常につきまといます。2011年にサービスを開始したコミュニケーションアプリ「LINE」においても同様で、多機能化や、開発・運用の長期化に伴い、いくつもの負債が発生していました。

この課題を解決するため、LINE株式会社では「『LINE』の次なる10年のための改善」を目標とする、LINT（LINE Improvements for Next Ten years）という部署横断プロジェクトを立ち上げました。より利便性や信頼性の高いアプリを目指し、LINTのメンバーは地道なアーキテクチャ改善を続けています。

ここでは彼らの取り組みのなかから「SPDYからHTTP/2へのプロトコル変更」とそれに伴う「Long PollingからPushへの移行」、そして「イベントデリバリーメカニズムの改善」をピックアップし、事例とノウハウを解説してもらいました。

通信プロトコルをSPDYからHTTP/2に移行

──LINEの「イベントデリバリーのコア」と呼ばれる配信システムでは、通信プロトコルとしてSPDY^※が導入されているそうですね。各コンポーネントのうち、どの箇所でSPDYによる通信を行っているのですか？

※GoogleがWeb表示の高速化を意図して開発した通信プロトコル。TLS接続の上にセッション層を追加し、単一のSPDYセッションで複数のリクエストを送受信する。

中村　LINEのクライアントとアプリケーションサーバー（talk-server）間には、LEGY（LINE Event delivery GatewaY）と呼ばれる内製のゲートウェイサーバーが位置しています。このゲートウェイがSPDYをベースにした通信を行っており、「SPDYとHTTPとのプロトコルの変換」「リクエストのルーティングやコネクション・セッションの管理」などの役割を担っています。

──どういった意図で、SPDYを導入したのでしょうか？

大石　LINEアプリは非常に機能が豊富ですし、ユーザー数も膨大ですから、API呼び出しは非常に高頻度になります。さらに、ユーザーがトークルームを開いているときは、ほぼリアルタイムでやりとりできるレスポンス速度が必要です。そのためには、メッセージのPushやLong Pollingといった、オーバヘッドの少ない通信を行う必要があります。

SPDYは、こうした条件を満たす通信プロトコルとして適していました。ですが、現在のSPDYは課題を抱えていることもあり、私たちはHTTP/2に通信プロトコルの移行を進めています。

──課題とは、どのような？

大石　SPDYは、もともとGoogleによって独自に開発されていたプロトコルですが、それが標準化の過程においてHTTP/2へと置き換わっていったんですね。そして、Google自身も2016年の時点でChromeでのSPDYサポートを終了させましたし、各種オープンソースのライブラリもSPDY関連の機能はサポートしなくなってきました。社内で用いられている通信ライブラリのうち、SPDYに関連する機能は自社内でメンテナンスしています。ですが、自分たちでライブラリのメンテナンスを続けるのはなかなか大変な作業です。

できる限り、標準に沿ったプロトコルを使って、デファクトスタンダードのライブラリを使用できるようにしたい。私はAndroid版のLINEアプリの開発を担当しているのですが、もし標準的な通信プロトコルを使っていれば、OkHttpという通信ライブラリを導入でき、多くの利点が生じます。

▲ LINEのアーキテクチャにおけるSPDYの配置

──だからこそ、HTTP/2への切り替えを行いたいわけですね。

大石　さらに、このプロトコル変更を機に、既存コードの大幅なリファクタリングをしたかった、という意図もあります。

Android版のLINEアプリにおいて、通信に関する実装に技術的な負債が溜まっていました。レイヤ・バイオレーションが生じており、適切な責務の分解ができていない部分があったのです。そこで、プロトコルの移行と並行して、アプリケーションの基盤に関わるコードのリファクタリングも進めていきました。通信のような非同期的な処理に対してKotlinコルーチンを導入することによって、いわゆる「コールバック地獄」の解消を目指したりといったことです。

この詳細は、LINE DEVELOPER DAY 2019でも「LINE Androidアプリの開発をいかにモダン化していくか」と題して発表しています。

LINE Android アプリの開発をいかにモダン化していくか - LINE DEVELOPER DAY 2019

抽象化レイヤーを設置してプロトコル移行のリスクを低減

──SPDYからHTTP/2への移行にあたり、スイッチングの抽象化レイヤーを設けたとか。この移行プランを採用する利点とは何でしょうか？

朴　SPDYからHTTP/2への切り替えを行う際、何より優先しなければいけないのは「ユーザー影響を抑えながら、可能な限り安全に移行すること」です。切り替えやトラブル発生時の切り戻しのときに、何かのトラブルが起きることは絶対に避けなければいけません。

その観点で考えると、「全く抽象化レイヤーを設けず、あるタイミングでクライアントアプリとLEGY間の通信プロトコルを一気に切り替える」というプランは現実的でないことが分かります。

アプリをアップデートするタイミングはユーザーごとに違いますから、ある時点で「ユーザーAは最新バージョンを使っているが、ユーザーBは古いバージョンを使っている」ということが十分にあり得ます。この場合、プロトコルを一気に切り替えると、ユーザーBは通信そのものができなくなるおそれがあります。

また、アプリの通信まわりの処理にバグがあったときに、切り戻しも困難になります。アプリの再リリースを行うとき、iOSではAppleの審査が必要になるため、早くて数日から1週間程度の時間がかかってしまうからです。ユーザーがその期間にアプリを使えなくなれば、影響範囲は甚大なものになってしまいます。

▲ クライアントとLEGYの間に設置された抽象化レイヤー（LINE DEVELOPER DAY 2019におけるLINTの発表より）

──それらの前提条件をクリアするには、抽象化レイヤーを差し込んでおくのが最も都合がよかったわけですね。

大石　加えて、先ほどお話しした既存コードのリファクタリングを実施する上でも、SPDYとHTTP/2の両方を許容してくれる抽象化レイヤーの存在は重要でした。

特定の期間内で全ての機能を修正するのは無理があるため、各機能を五月雨式に修正していく必要があります。アプリ内で用いている通信プロトコルが混在する可能性があるわけです。その差分を吸収する上でも、抽象化レイヤーは非常に役に立っています。

Long PollingをPushへと切り替えて通信量を最適化