主要4カ国で1億6500万人のユーザーを抱えるLINEのインフラの課題とは
三枝氏は2005年に入社（当時の社名はNHN JAPAN）。以後、10年以上にわたりネットワークとデータセンターなどのインフラに携わってきた人物だ。
「LINEがリリースされてから7年以上が経過し、その間、インフラにおいては規模の拡大に伴い次のような課題が起こってきた」と三枝氏は語る。
- キャパシティの限度
- アーキテクチャの非効率性
- 運用コストの増大
なぜ、このような課題が起こってきたのか。その背景の第一がネットワークの問題である。ユーザー向けのトラフィックは1Tbpsを超えるが、それよりも「実際にはデータセンター間で発生するデータ間通信のトラフィックの規模が大きい」と三枝氏。そこでデータセンターとサーバ間通信をどう裁くかを主眼に置いてネットワーク設計をしてきた。
従来の設計では1つのネットワークPOD（Point of Delivery：コンピュータやシステム・システムモジュール等が提供されるかたまり）で1台あたり10Gbpsのネットワークインターフェースを持つサーバーを3200台収容できるようにしており、ネットワーク全体のPODでは1万6000Gbpsのキャパシティを実現。そしてそれを2Nの冗長構成でインフラを提供していた。
だがこのような構成だと、10Gbpsを使い切るサーバが増えると、ネットワークにボトルネットワークが発生し、通信が不安定になってしまう。「トラフィックを処理するサーバをネットワークの近いところに置くという運用でカバーしていたが、サーバ数が増えるに従い、このような運用が難しくなってきた」と三枝氏は説明する。
第二に2Nの冗長化方式の効率の悪化も問題だった。1万6000Gbpsのネットワークのキャパシティを提供するには、3万2000Gbpsのネットワークのインフラを組む必要がある。「Nの数が増えると、どんどん効率が悪化していく一方だった」と三枝氏。
第三はコネクション数の問題である。LINEが主に使われている日本、台湾、タイ、インドネシアの月間のアクティブユーザーの合計が1億6500万人。デイリーのアクティブユーザー比率は77％なので、LINEのインフラは常にユーザーの何千万というTCPコネクションを同時に取り扱う必要がある。そのTCPコネクションはロードバランサーを通じて、メッセージングゲートウェイというサーバに振り分けられる。一つのTCPコネクションは同じサーバに振り分けないと通信は実現しない。そのためロードバランサーは、TCPコネクションをセッションテーブルで管理するのだが、セッションテーブルのサイズは、ロードバランサーの各ノードのメモリのサイズに依存するため、キャパシティ不足とならないようにロードバランサーを複数並べることで対応してきた。
ロードバランシングの方式として採用したのはDSR（Direct Server Return）だ。DSRでは、クライアントからサーバに向かう通信だけがロードバランサー経由となり、サーバからクライアントに向かう通信はロードバランサーを経由しない。「クライアントからサーバに向かうトラフィックの方が、サーバからクライアントに向かうトラフィックに比べて、容量が小さい。小さなトラフィックに合わせてロードバランサーのキャパシティを設計できるというメリットがあったため」と三枝氏は語る。
しかしこの方式にはデメリットもある。それはセッションテーブルに関するきめ細やかなコントロールが難しいことだ。
「LINEのユーザーを多数抱える通信事業者側で大きな障害があった場合やLINEのインフラ自体に問題があった場合に、LINEのクライアントがサーバと通信しようとすると、TCPレベルでのリトライが多数発生する。このようなリトライの通信の一つ一つが、セッションテーブルに乗るため、その状況が続くとセッションテーブルがあふれてしまうことが起こってしまう。セッションテーブルのスケールの課題とロードバランサーの2N方式という冗長方式の悪化が大きな課題となっていた」（三枝氏）
第四に開発者と開発拠点の増加による運用コストの増大も問題だった。LINEでは開発者がアプリケーションをデプロイするためのインフラリソースを手配する場合、インフラレイヤー毎の専門チームに依頼を出す形で対応していた。「開発者の数や拠点数が少ないときは対応できていたが、すべての開発者がどのインフラチームにどのような依頼を出せば、自分が欲しいインフラリソースが手に入るのか理解するのは難しい。そのための学習コストが負担になっていた。またそれに対応するインフラチームの側も負担が増えていた。相互の負担を軽減するため、根本的な改善が不可欠だった」と三枝氏は話す。
課題を解決するためアーキテクチャレベルから改善
これらの課題を解決する上で、大事にしたのは次の2つの原則だ。
- 課題を根本的に解決すること
- 運用負荷が下げられるものであること
この原則の下、「3つの基本的要件を定めた」と三枝氏は説明する。
- 圧倒的に大きなパフォーマンスを提供すること
- N＋1でスケールアウトが可能なアーキテクチャを構築すること
- 運用のコストを下げること
ネットワークが抱える課題を解決するためには、「アーキテクチャレベルでの改善が必要だった」と三枝氏。そこで採用したのが、他社の大規模データセンターネットワークにも採用されている「CLOSネットワーク」である。
CLOSネットワークとは、すべてのネットワークレイヤーでN＋1でスケールアウトが可能な構成だ。そして運用の負荷を下げるために、ホワイトボックススイッチを使って実現できないかと検討した。ホワイトボックススイッチは、LinuxベースのOSで動作させることができるので「これまでのスイッチの管理の手法を、サーバを管理するような手法に切り替えられる。LINEでは数万台のサーバを運用する手法がすでに確立されているので、その恩恵も受けられると考えた」（三枝氏）
だが、最後まで「サーバを収容しているToRのスイッチと、サーバのネットワークの構成に頭を悩ませた」と吐露する。LINEではToRのスイッチを二重化しており、従来はL2でサーバとToRを接続していたという。だが、L2接続の場合は、ToRのスイッチをグレースフルに切り替えることができず、必ず切り替えの際にパケットロスが発生するのが問題だった。そこでL3での接続を検討。L3であればルーティングの技術を使えるため、スイッチ側の操作だけで、グレースフルフェイルオーバが実現する。メンテナンス性のしやすさに魅力を感じ、L3で接続するパターンで検討することになったという。
すでにこの構成で動作しているサイトがあり、一つのPODあたり7200台のサーバを収容、すべて10Gbpsのトラフィックでもボトルネックのないネットワークが実現しているという。「これぐらいの規模のインフラであってもCLOSネットワークアーキテクチャーであれば十分、スケールするモノが作れる」と三枝氏。
冗長化方式、ロードバランサーの課題についてもアーキテクチャレベルでの改善を実施。基本的なアーキテクチャはL3、L4、L7のマルチティア構成を採用し、各レイヤーでN+1でスケールアウトができるようにした。例えばL3はAnycastやECMPというルーティングの技術を使ってN+1分散を実現。「悩んだのはL4」と三枝氏は続ける。従来通りステートフルの方式で進めると、仮にL4ノード一つ当たりの障害やメンテナンスをする場合に、ユーザー影響を少なくするためにはすべてのL4ノードが同じセッション情報を持たないといけない。「セッションテーブルのサイズが有限だと言うことを考えると現実的ではない」ため、セッションテーブルを管理しないステートレスな方式で改善できる方法を検討したという。
一つのTCPフローを判別するには、「ソースIPアドレスの情報」「ディストネーションIPアドレスの情報」「ソースポート番号」「ディストネーションポート番号」「プロトコル番号」が必要になる。この5つの情報を使って、ハッシュを計算、それに基づいて振り分ける先のサーバを決めれば、セッションテーブルを管理せずに同じTCPフローを同じサーバへ振り分けることができる。全部のL4ノードが同じハッシュアルゴリズムで動作すれば、L4ノード一つ当たりの障害やメンテナンスやユーザー影響を少なくすることができるというわけだ。
「残る課題はL4ノード一つ当たりのパフォーマンスだった」と三枝氏。圧倒的に大きなパフォーマンスを提供する要件を満たすため、L4ノード一つあたり、秒間700万パケットを処理できる能力に設定。L4ノードはコストや運用性を考えて、Linux上で動くソフトウエアとして実装を進めた。だが、通常のLinuxカーネルのネットワークスタックだと、秒間700万パケットはオーバーヘッドが大きすぎて実現が難しい。
そんな悩みを抱えていたとき、タイミング良くLinuxカーネルにXDP（eXpress Data Path：高速パケット処理基盤）が追加された。テストを実施すると、なんなく秒間700万パケットの処理能力を達成したという。XDPを使ったステートレスなロードバランサーの開発を行い、今年の8月からプロダクション環境に適用、「LINEの広告プラットフォームもこの上で動作している」と三枝氏は満足そうに語る。
開発者数と拠点数の拡大に伴うコスト増に対応するためプライベートクラウドを開発
開発者数と拠点数の増大の課題には、LINEのインフラを利用する側の利用コストと、インフラを運用する側の運用コストという2つの課題がある。これらの課題を解決するために、インフラプラットフォームというレイヤーを追加し、インフラに対する自動化を実施するようにしたという。また開発者にはインフラを必要以上に意識させない仕組みとして、APIやWeb UIを経由してインフラをオペレーションするアプローチを採用。「端的に言えばこれはLINEのインフラのプライベートクラウド化。この仕組みが『Verda』だ」と三枝氏。
従来、開発者が複数のVMが必要なときには、インフラ運用担当者に依頼をし、インフラ運用担当者はその依頼内容を見て単一障害点が発生しないように、VMの配置先を決めるというオペレーションだった。しかしVerdaであれば、そのオペレーションがVerda上のシステムロジックとして実装されているため、開発者はインフラをまったく意識をすることなく適切に配置されたインフラリソースを手に入れられるようになっている。VMだけではない。ロードバランサーもネットワークの設定も、意識することなく設定ができるようになっている。
「必要以上にインフラを意識して欲しいとは思っていないが、意識してほしいところはしっかり意識させるプラットフォームになっている」と三枝氏。例えば外部にサービスを公開する場合などは、これに当たる。ロードバランサーの仮想アドレス（VIP）をパブリックIPで設定をするだけでは、外部にサービスが公開されず、利用者側で「このサービスは外部に公開する」という依頼を出して、しかるべき承認が行われてはじめて、外部に公開されるようになっているという。
これらの課題解決の背景には、苦労が多々あったという。「一番苦労したのは、課題解決に伴う変化にいかに対応してもらうか。トップダウンで頭ごなしに進めることもできるが、そういうやり方ではいずれ反動が来て反発を招いてしまう。大きな変化を進めるときはゴールを明確にし、みんなに共感してもらって一つ一つ進めていくことが大事だ」（三枝氏）
もう一つ苦労したのが時間だという。アーキテクチャレベルの改善を進める場合は、ライフサイクルを合わせて導入することが重要になる。特にインフラはハードウェアのライフサイクルに影響される。
「一度改善のタイミングを逃すと次に実施できるタイミングは遙か先になる。タイミングを逃さないために、普段から新しい技術、アプローチを適用できるよう、要素技術の研究、必要な人材の育成・採用など、下地を整備する努力が大事だと痛感した」（三枝氏）
さらにLINEのインフラチームでは新しい取り組みも行われている。まず、1つのインフラの上でさまざまな要件を達成することができる要素技術の研究開発である。「私たちが注目しているのがSRv6の技術。これはソースルーティングの技術のひとつで、IPv6だけの転送のメカニズムで利用できるようになる。ソースルーティングの柔軟なパス選択ができるだけではなく、ネットワークにいろいろな機能を付加できる。私たちはこのSRv6をネットワークのマルチテナンシーやサービスチェイニングなどに適用して、ビジネスニーズに合わせて迅速に対応できるよう取り組んでいる」（三枝氏）
またKubernetesを使った取り組みも行われている。その一つがVerda上でマネージドなKubernetesクラスタを提供するというもの。「来年の春ごろにはプロダクション環境で提供する予定だ」と三枝氏。もう一つKubernetesを使った取り組みが、社内で「EVENT HANDLER」と呼んでいるインフラやアプリケーションの運用をサポートするプラットフォームの開発プロジェクトだ。任意のイベントに対して任意のアクションを紐づけることができ、そのアクションをファンクションとして登録し、実行できるようにするFaaS（Function as a Service）のようなサービスだ。例えば、特定のログが発生した際に自分が好きな方法や条件による柔軟な通知を送るといったことが実現可能になる。
「EVENT HANDLER」は、GoogleがOSSで提供するKnative（Kubernetes上でサーバレスを実現するプロダクト）をベースに開発している。
「これで終わりではない。まだ解決しなければならない課題はあるが、このようにして私たちは大規模サービスを可能にするインフラプラットフォームを実現している」最後に三枝氏はこう語り、セッションを締めた。
開発者とインフラ運用者にとってよりよい課題解決を目指す
スピーカーの三枝氏に、開発者目線で気になるインフラの特徴や取り組みについて、追加インタビューを実施した。
――セッションでは、大きなアーキテクチャの刷新において「まわりにいかに共感してもらうかが重要だ」というお話がありました。具体的にはどのような取り組みを行ったのでしょうか？
三枝 一番力を入れたのは、解決が必要な課題に対する認識をあわせるということです。この認識がメンバーの間で共有されていない状況では、アーキテクチャーの刷新をいくら提唱してもなかなか受け入れてもらえません。インフラが抱えている問題点をきちんと分析をして、それを客観的に示すことで、「これらインフラに関する問題点は解決な必要な課題である」という共感が生まれます。
ただし、アーキテクチャーのレベルで課題の解決を試みるというのは簡単なことではありませんので、一度得られた共感がプロジェクトの途中でしぼんでしまうこともあります。要所要所で課題解決に対する重要性を訴えかけるということを意識して、共感が続くような取り組みを行っていました。
――プライベートクラウド「Verda」の概要を教えてください。また、Verdaの登場で、開発者のインフラへの意識はどのように変わりましたか？
三枝 VerdaはLINEのインフラをサービス化するためのプラットフォームとして作られました。サーバーやストレージ、DNS、ロードバランサーといった基本的なIaaSコンポーネントから、MySQLやRedisなどのマネージドサービス、そしてHerokuのようなPaaSサービスまで幅広く提供をしています。
Verdaを提供する前までは、オンプレミスに対するネガティブな印象もありました。今では、Verdaを実際に使ってもらうことにより、オンプレミスの良さを実感してもらっています。
Verdaでは、オンプレミスの良さであるコスト面まで含めたITインフラの統制が可能なこと、WebUI/APIのインターフェースでインフラをサービスとして提供できることなどにより、Verdaはオンデマンドかつシステム間連携が可能な柔軟なインフラとして認識されています。
――セッションではKubernetesを使った新しい取り組みの紹介がありました。これらのリリース後にはLINEのなかでどのように活用していきたいですか？
三枝 セッションの中でもメインのテーマとして触れましたが、Kubernetesを活用した新しい取り組みも、開発者インフラ運用者双方の負担を減らすという方向性の取り組みという点では変わりありません。
既にアプリケーションをKubernetes上にデプロイするということが当たり前のようになってきていますので、まずは安定したKubernetesクラスタを提供するということと、そのクラスタ管理の自動化に焦点をあてた取り組みを続けています。その次にはKubernetesクラスタをLINEのサービスのさまざまなワークロードに対応できるような機能拡張をいくつか計画しています。
そして同時にKuberentesを活用したプラットフォームとして、オペレーションを自動化する汎用プラットフォームとしてのEvent Handlerプロジェクトにも力を入れています。イベントをトリガーとするオペレーションはアプリケーションの開発者、そしてインフラの運用者に共通したものになりますので、これが実現できれば非常に汎用性の高いプラットフォームになると考えています。
――三枝さんの今後チャレンジしていきたい課題について教えてください。
三枝 今後のインフラプラットフォームの課題解決の方向性としては現在と変わりありませんが、より開発者とインフラ運用者の深い領域まで踏み込んだ課題解決を目指そうと考えています。
LINEでもアプリケーションのマイクロサービス化が速いスピードで進んでいますので、それを可能にするCI/CDツールとインフラプラットフォームとの連携は、今後避けては通れない道です。アプリケーション開発者との密接な連携によって、Verdaに最適なCI/CDパイプラインを一緒に作っていきたいです。
そして、Kubernetesの取り組みを加速させてインフラをより一層抽象化することでインフラの利用効率と運用性の向上を実現したいと考えています。具体的にはKubernetesをLINEのサービスの中で普及させることによって、それまではワークロードの特性によって必要なハードウェアを用意していたところを、より汎用的なハードウェアで統一をして、プロビジョニングとオペレーションに関わるコストを劇的に下げる取り組みをしたいと思っています。
――大幅なアーキテクチャの刷新から、新しいチャレンジに至るまで、開発者、インフラ運用者双方とってよりよいインフラを提供するための知見を数多くシェアいただきました。ありがとうございました。
