課題を解決するためアーキテクチャレベルから改善
これらの課題を解決する上で、大事にしたのは次の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上でサーバレスを実現するプロダクト）をベースに開発している。
「これで終わりではない。まだ解決しなければならない課題はあるが、このようにして私たちは大規模サービスを可能にするインフラプラットフォームを実現している」最後に三枝氏はこう語り、セッションを締めた。
