「あけおめLINE」の負荷に耐えるインフラを作った話。LINEのインフラ設計を中の人に聞いた

2011年6月のリリース以来、右肩上がりの成長を続けるコミュニケーションアプリ「LINE」。主要4カ国（日本・タイ・台湾・インドネシア）の月間アクティブユーザー数は1億6,400万人を超えており、多くの人々にとって必要不可欠な社会的インフラにも等しいアプリになっています。

そして、多数のユーザーを抱えるアプリでは、膨大な量のトラフィックやデータを前提としてインフラアーキテクチャを設計する必要があり、インフラエンジニアの技術力がアプリの使い勝手に大きな影響を与えます。

本稿では、LINE株式会社のサーバーサイドエンジニア 中村俊介さん、サーバーインフラエンジニア 木村智洋さん、ネットワークエンジニア 小林正幸さんに、「LINE」の黎明期から現在にいたるまで、同サービスのインフラアーキテクチャがどのように構築されてきたかを伺いました。

オーソドックスな構成だった、初期インフラアーキテクチャ

——まずは「LINE」の過去のアーキテクチャについて教えてください。サービス開始当初のインフラは、どのような構成になっていたのでしょうか？

中村　当時のアーキテクチャは、典型的なWebの3層構造になっていました。クライアントからのリクエストをロードバランサーで受けつけ、リバースプロキシーサーバーでSSLクライアント認証を行い、後段のアプリケーションサーバーで処理を行うベーシックな構成です。

メインのデータベースとしてRedisが採用されていました。「LINE」のサービス特性上、処理スピードが速いデータベースである必要があったためです。メッセージングに依存しない、統計用途のユーザー情報のバックアップや、「友だち」のリコメンデーションデータなど、処理性能がそれほど求められない部分については、MySQLが用いられていました。

——オーソドックスな構成だったのですね。

中村　ユーザー数が少ないうちは、このアーキテクチャでも問題はありませんでした。しかし、2011年10月上旬に無料通話とスタンプ機能などがリリースされた後、200万ダウンロードを突破しました。11月に最初のTV CMを放送すると認知度はさらに上がって、年末までに一挙に1,000万ダウンロードに届いたんです。予想をはるかに上回っていました。

——すさまじい増加量ですね。それだけユーザーが増えると、いたる所にボトルネックが発生しそうに感じます。

中村　その通りです。そのため、インフラアーキテクチャを改善していく必要に迫られました。まずは、クライアント・サーバー間のコネクション接続に用いているリバースプロキシを変更しました。

初期の実装ではクライアントからサーバーに対して、定期なポーリングとサーバーからのpush通知を組み合わせたつくりでした。でも、この仕組みではクライアント数が増えるにつれてスケールしづらくなりますし、クライアント端末のバッテリー消費も激しくなるというデメリットがあります。こうした課題を解決するため、間にゲートウェイサーバーとしてNginxを導入し、クライアントへの頻繁なpush通知の代わりにlong pollingを導入したんです。さらには、NginxをSPDYベースの「LEGY」というLINEで内製したものに入れ替え、multiplexやヘッダ圧縮などの工夫によって、コネクション数や通信コストを削減する対応を行いました。

——データベースのトラブルなどは発生しましたか。

中村　ユーザー登録リクエストの突発的な増加に伴って、MySQLへの書き込み処理がサチるようになりました。間にRedisのキューを使った遅延処理を入れていましたが、そのRedisがメモリ不足になってしまうほど、処理が詰まることがよく起こっていました。

——MySQLの書き込みが詰まるとは、想像もできないほどのデータ量ですね！ その課題をどのように解決していったのですか。

中村　当時のMySQLは水平分散が難しい、という課題がありました。そこで、サーバーを足すことで書き込み性能を柔軟にスケールさせられるHBaseを導入したんです。ユーザー数増加に伴ってHBase clusterを2倍に、次は3倍に……と拡張していきました。ただ、HBaseを導入するだけではガベージコレクションや、H/W故障による部分障害、Hadoop1 NameNodeが単一故障点になってしまうといった問題があり、実際のサービスの可用性に、まだ影響がありました。そこで「LINE」では、重要なメッセージングのデータを2つのHBase clusterに冗長化することで、こうした可用性の問題を緩和させています。

より良いサーバー間通信のため、ネットワークアーキテクチャにCLOS Networkを採用

——小林さんは2017年に入社されたそうですが、過去にどのようなプロジェクトを担当されたのですか。

小林　データセンター間ネットワークの設計や、データセンター内のネットワークアーキテクチャの刷新です。「LINE」でもともと用いられていたネットワークは、サーバーからクライアントへの通信には強いものの、データセンターのサーバー同士の通信をそれほど捌けないという欠点を持っていました。

「LINE」では各サーバー上で動いているコンポーネントも相当な数になっているので、サーバー同士の通信量も非常に多くなっています。そのため、現状の運用に適したネットワークアーキテクチャに改善することを決めました。

——どのようにアーキテクチャを変更したのでしょうか。

小林　変更前は、ネットワーク機器を「2N」と呼ばれる2台1セットの冗長構成で配置していました。図版を見ていただいたほうが分かりやすいですね。

これが古い構成です。この構成では、ネットワーク機器が性能のボトルネックになった場合、上位の機種に入れ替えるスケールアップの方式でしか対応ができません。スケーリングに制限があるんです。そのため、ネットワーク構成を以下の図のようなCLOS Networkというアーキテクチャに刷新しました。これは水平スケールできるネットワークアーキテクチャで、同じネットワーク機器を大量に横に並べ、ネットワーク全体の流量を増やせる構成になっています。また、2N構成の場合は機器の故障で縮退率が50％になってしまいます。

しかし、CLOS Network（N+1）の場合、例えば4台でN+1を構成した場合の縮退率は25％になります。つまり、N+1を構成するノード数が多ければ多いほど、縮退率を小さくすることができます。仮に数台壊れたとしてもサービスに影響しないような設計です。

さらに、CLOS Networkへの変更を行う際、ホワイトボックススイッチを採用しました。ホワイトボックススイッチとは、OSなどのソフトウェアを含まず、ハードウェアだけで提供されるネットワークスイッチです。その上でどんなOSを動かすかを運用者が選べます。

ホワイトボックススイッチ上でLinuxベースのOSを動かし、パケット処理に強いLinuxサーバーのように扱うことで、既存のサーバー運用ノウハウを流用できると考えたんです。

また、ネットワーク機器がこれほど大量にあると、環境構築を手作業で行うのは現実的ではありません。新しいアーキテクチャになってからは構成管理ツールのAnsibleを活用して、ネットワーク機器を自動設定する仕組みを整備しました。

サーバーを安定的に供給するために自動化ツールを自作する