「あけおめLINE」の負荷に耐えるインフラを作った話。LINEのインフラ設計を中の人に聞いた
国内外で展開する膨大なメッセージを処理する、LINEアプリのインフラってどうなっているの？ こんな素朴な質問をサーバー、ネットワークなど、中の人に聞いてみました。
2011年6月のリリース以来、右肩上がりの成長を続けるコミュニケーションアプリ「LINE」。主要4カ国（日本・タイ・台湾・インドネシア）の月間アクティブユーザー数は1億6,400万人を超えており、多くの人々にとって必要不可欠な社会的インフラにも等しいアプリになっています。
そして、多数のユーザーを抱えるアプリでは、膨大な量のトラフィックやデータを前提としてインフラアーキテクチャを設計する必要があり、インフラエンジニアの技術力がアプリの使い勝手に大きな影響を与えます。
本稿では、LINE株式会社のサーバーサイドエンジニア 中村俊介さん、サーバーインフラエンジニア 木村智洋さん、ネットワークエンジニア 小林正幸さんに、「LINE」の黎明期から現在にいたるまで、同サービスのインフラアーキテクチャがどのように構築されてきたかを伺いました。
- サービスネットワークチーム 小林正幸さん（写真左）
- 2017年8月入社。ネットワークエンジニアとして「LINE」のプロダクションネットワーク全般の設計・構築を担当する。
- Z Partチーム 中村俊介さん（写真中央）
- 2011年10月、新卒で入社。サーバーサイドのソフトウェアエンジニアとして、「LINE」のメッセージングサーバー及びストレージに関する設計や開発をリードする。
- システムエンジニアリングチーム マネージャー 木村智洋さん（写真右）
- 2015年1月入社。サーバーインフラエンジニア。Linux OSインストーラの開発・運用や物理サーバの管理、サーバーハードウェアの評価などを担当。
オーソドックスな構成だった、初期インフラアーキテクチャ
——まずは「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を活用して、ネットワーク機器を自動設定する仕組みを整備しました。
サーバーを安定的に供給するために自動化ツールを自作する
——木村さんの部署ではサーバーの管理などを行っているそうですが、どのような工夫を行っていますか。
木村 「LINE」で用いられているサーバーの90%以上がオンプレミス環境で動いているのですが、私の部署ではそれらのサーバーの購入や評価、セットアップといった業務を担当しています。とにかくサーバー台数が多いですから、セットアップにおいては「OSインストールをどう効率化するか？」が重要なテーマです。
以前は、OSSのツールをいくつか組み合わせて、不足しているところはツールを内製する形で自動化していました。けれど、RAIDの設定などが手動になっている部分があって非効率的だったんです。そこで、完全自動化するために自社の業務フローに合わせたOSインストーラーを内製しました。
——運用効率化のためには、自動化を推進することがキモになると感じます。他に、自動化を試みている箇所はありますか。
木村 これ以外の自動化の例として、LINEではPMCと呼ばれるアプリケーション用のデプロイツールも内製しています。これはデプロイやホストの管理などを行うツールです。各部署が膨大な量のサーバを持っているので、可能な限り運用を自動化して省力化する文化は強いですね。
——自社でDCを持って物理サーバーを立てているのもLINEの特徴です。クラウドではなく、自社でサーバーを持つメリットは何だと思いますか。
木村 いくつかありますが、一番は「実はコストが低い」ということです。LINEのように管理するサーバーが数千台の規模になってくると、人件費などを含めてもクラウドよりも安価になってくるんです。さらにLINEでは、どんなサービスでも汎用的に使えるようなスペックのサーバーを大量に発注することで、購入コストをかなり下げています。
小林 ネットワークエンジニアの観点からいうと、自社でDCを持つことによってトラフィックのコントロールがしやすいという利点があります。トラフィックの特性や宛先に応じた制御ができるんです。クラウドを利用する場合、そのコントロールを自分たちで行うことは難しいでしょう。
それに、クラウド上に大量のトラフィックがあるサービスを載せると、通信量が膨大なので課金額もかなり膨らんでしまいます。そうしたさまざまな点から、自社でDCを持つことは利点が大きいんです。
木村 とはいえクラウドの利便性の高さは魅力なので、LINEでは2016年からプライベートクラウドの構築も始めています。API・WebUIを経由して、開発者が簡単にサーバーを調達できる仕組みをつくっているんです。2017年からはプロダクション環境にも投入され、現在では新規のインフラに関しては、ほぼ100％プライベートクラウド上で提供されています。
書き込みが多すぎて捌ききれない。「あけおめLINE」の舞台裏
——「LINE」といえば、年末年始にトラフィックが増える、いわゆる「あけおめLINE」が有名です。この裏では、どのようなオペレーションが行われているのでしょうか？
小林 「あけおめ」のタイミングでは、ネットワークのトラフィック量が平常時の2～3倍くらいになります。以前は帯域に十分な余裕がなく、回線を増強しなければならないこともありました。ここで重要なのが、自社のデータセンター内だけではなく、携帯キャリア各社など、外部のネットワークとの接続部分も増強対象だということです。
しかし、「来週にあけおめLINEが大量に流れるので、これから対応をお願いします」と連絡をしても、絶対に間に合いません。事前の綿密な調整が非常に大事になります。LINEの場合は、3～4か月前くらいから準備しているんです。
——「どの回線にどれくらいのトラフィックを流すか」まで考慮して、プロジェクトを進めていくのですね。
小林 年末年始のタイミングでもトラフィックを監視していて、溢れそうになった場合には、ルーターの設定を変更して余裕のある回線に何％かトラフィックを移すようなオペレーションも行っていました。
ただ、2018年までに外部・内部向けの回線を大幅に増強したので、2019年の年始の「あけおめ」のタイミングでは、私たちの部署は当日のオペレーションを実施せずに済みました。ネットワークが安定したんです。
——LINEインフラの進化を感じます。初期の頃は、大変なオペレーションもあったのでは。
中村 昔はピンチの局面が何度もありました。年末年始のトラフィックには特徴があって、ユーザーの多い日本や台湾、タイなどの各国には時差があるため新年になるタイミングが１時間毎に異なり、「あけおめ」の連絡が増える時間帯にそれぞれのピークがあります。そのため、日本が年始を迎えたタイミングで障害が発生した場合は、1時間後に控えた次のピークまでに復旧させなければなりません。
例えば、日本が新年を迎えたときに一部の端末で利用されるmessageBoxというHBase tableへの書き込みが多すぎて捌ききれなくなり、キューにデータが蓄積するという障害が起きたことがあります。その際には、キューの内容をすべてパージした上で台湾やタイなどの、後から来るピークをしのぎ、翌朝までに他のデータから復旧させるバッチをMapReduceで書いてデータを復旧しました。
——本番環境のデータをパージしてから復旧とは……。大変な局面を乗り越えてきたのですね。
中村 かなり泥臭い対応でしたね。非常に印象に残っています。ですが、通常ピークの3倍以上の「あけおめ」のトラフィック対応で発生した負荷問題に向き合うことで、どの箇所がメッセージングサービス全体のボトルネックになるか、どういった対応をとるべきか明らかにできます。実際に問題のあった、messageBox tableもserver APIの使い方をよく分析した上で、より書き込みIOコストが低い形でストレージを再設計することで、翌年には負荷問題を解決できました。このように「あけおめ」で発生した負荷問題を真摯に解消し続けることで、「LINE」のアーキテクチャやサーバーの運用体制などが徐々に洗練されていきました。
大規模サービスに携わるからこその楽しさ
——今後、より良いアーキテクチャにするために、改善していきたいことなどはありますか。
中村 山ほどあります。例えばデータベースひとつをとってみても課題は多いです。現在、メッセージなどのイミュータブルなデータは複数のサーバーに冗長化できています。しかし、冗長化の難しいミュータブルなデータには初期と同様に、シンプルなマスタースレーブ構成のshardから成るRedis cluster上でまだ運用されています。
数百から千ノード規模のRedis clusterの中で、もしもマスターが1ノード落ちてしまうと、スレーブがマスターに昇格するまで最大1分程度の部分的なダウンタイムが発生してしまいます。任意のデータベースサーバーが落ちたとしても無停止で運用できるように、データの一貫性を維持しつつロバストな構成に変えていきたいです。
もうひとつ、「LINE」のバックエンドでもマイクロサービスを推進しており、様々な種類のサーバーが連携して動作しています。しかし、肝心の本体であるtalk-serverがまだモノリシックなつくりになっていて、メッセージ、ソーシャルグラフ、グループ管理など様々な機能が動いています。これを徐々にマイクロサービスとして切り分けて、KafkaベースのメッセージパイプラインとArmeriaという非同期ライブラリを用いたアーキテクチャに刷新していきたいです。
小林 ネットワークもまだまだ改善したい点があります。例えば、ネットワーク運用の自動化・効率化や、ネットワークの状況監視や正常性チェックなどを実現させたいです。
従来のネットワーク監視手法では、障害原因を検出しきれないようなケースがありました。ですが、ネットワークスイッチをホワイトボックススイッチに切り替えたことで、Linuxサーバーで行っていたプロセス監視やリソース状況の監視などの仕組みをスイッチにも組み込めるのではないかと考えています。
木村 「サーバーハードウェアの抽象化」を高い次元で実現していきたいと考えています。サーバーは当然ながら、不具合が出たり壊れたりすることもあります。直接ベアメタルサーバー上にアプリケーションが展開されている場合、サーバーに問題が発生するとサービス開発者側で「サーバーの状態の変化に応じたアプリケーション運用」が必要になってきます。サービス開発者に一つひとつのサーバーの状態を意識させない仕組みを整えていきたいのです。
そういった仕組みを整えても、開発者にとって使いづらい仕組みだと意味がないので、世の中に広まっている標準的な技術を使って実現をしようとしています。具体的にはKubernetesを利用したハードウェアの抽象化の実現のために、「LINE」のPrivate Cloud上で「Kubernetes as a service」の提供という試みを開始しています。
現在はまだ一部の開発者にテストをしてもらっている段階ですが、今年の6月を目標にしてプロダクション環境でも使えるマネージドKubernetes Clusterの提供に向けて開発を進めています。
——それを実現した将来が楽しみです。最後に、LINEという企業でインフラに携わる醍醐味について教えてください。
小林 これほど大きな規模でネットワークのアーキテクチャを考えてトライ＆エラーできる企業は、日本国内に数えるほどしかありません。その環境で日々チャレンジできるのは、非常に価値のあることだと思っています。
中村 私は2011年にLINEに入社してから、サービスのユーザー数が縦方向にどんどん伸びていくフェーズを経験できました。そしていまは、LINEがプラットフォームとして多種多様なサービスを横方向にスケールさせていくフェーズへと変化しています。それに伴い、インフラ構築において重視すべき点も変化し続けているのが、非常に面白いです。 私は主にデータベースまわりを担当しているので、処理が高速であることや、動作が安定していることに責任を持たなければいけません。でも、だからこそ「何事もなくシステムが動いていること」に大きなやりがいを感じています。
木村 私がLINEという会社を選んだ理由は、「大規模サービスを運営していて、大量・多種多様なサーバーがあるから」でした。中村からもお話ししたとおり、「LINE」は本当に認知度の高いサービスですし、そのプラットフォームのなかで機械学習や分散処理などさまざまなワークロードのサーバーが必要とされています。
その環境のなかで、自分自身が多種多様なモデルやスペックのサーバーに触れられることは、本当に面白い。もちろん、学ぶべきこともたくさんあるので大変な部分もありますが、だからこそ取り組む意義があると思っています。
取材・執筆：中薗昴
