LINEがプライベートクラウドをもつ理由　密接なコミュニケーションを求めて

Verda室ネットワーク開発チームとは

市原裕史氏（以下、市原）：LINEの市原です。よろしくお願いします。本日は、私たちネットワーク開発チームのプロジェクトについていくつか紹介していきたいと思います。

まずは自己紹介から。私は市原裕史と申します。LINEのVerda室ネットワーク開発チームというところで、ネットワークのソフトウェアデベロッパーをしています。主にSDNやNFV、またOpenStack NeutronやKubernetesのCNI、コンテナネットワークなどを開発しています。

アジェンダの説明をします。はじめに、私たちの利用しているプライベートクラウド、私たちはVerdaと呼んでいますが、そのVerdaの紹介と、その次に本日の本題であるネットワーク開発チームのプロジェクトについて、いくつか紹介したいと思います。

まず組織についてですが、LINEのインフラ全部を担っているITサービスセンターに属しています。その中でも、プライベートクラウドの開発運用を実施しているVerda室がありまして、その中で、主にプライベートクラウドに関連したネットワーク開発プロジェクトをリードしているのが、ネットワーク開発チームになります。

Verdaには主に2つのクラスタがあって、プロダクションサービスをホストするVerdaと、開発のリソースをホストするVerda Devと呼んでいるものの2つです。

私たちのインフラがどれくらいのスケールかを紹介します。LINE全体では、すべてのフィジカルサーバーを合わせると5万台以上になります。また、ピークのユーザートラフィックは3Tbps以上になっています。その中でも、Verdaが担っているサーバーリソースは、ベアメタルサーバーで2万台以上、またハイパーバイザーで言えば2000台以上、その上で現在バーチャルマシンが5万5000台以上動いています。

Verdaが提供するクラウドサービス

Verdaが提供するクラウドサービスは多岐に渡っています。まず図の一番下のIaaSですが、基本的にはOpenStackをベースとしたIaaSサービスになっていて、それにプラスして例えばオブジェクトストレージでしたらCephであったりとか。あとは独自にBaremetal as a Serviceを作っていたり、またLoadBalancer as a Serviceも作っています。

その上でPaaSが動いていまして、例えばみなさんご存知だと思いますが、Containerを動かすためにKubernetesを利用しています。そのKubernetesは、多くの会社がそうしているように、Kubernetes as a Serviceとして提供しており、各KubernetesクラスタはRancherを使ってホストしています。

あとはめずらしいところでは、FaaSもVerdaでホストしていて、KnativeをベースとしたFunction as a Serviceも、実際にプロダクションで動かしています。

こういったプライベートクラウドを私たちがもつ理由はなぜなのか、簡単に紹介しておきます。一番左側がLINEのユーザーだと思ってください。ユーザーからサービス要望などがLINEに対して行われます。そのとき、最初のフロントになるのは事業に関わっているアプリケーション開発者です。

アプリケーション開発者がユーザーの要望を受けて、例えばインフラでこういうものが足りないとか、こういう要件があるというものを、私たちインフラ開発者、Verdaに要望を上げてきます。

そこで、アプリケーション開発者とインフラ開発者との間でコミュニケーションを密接に行います。本当にこのインフラが必要なのか、ユーザーに価値を提供するために真に必要なインフラとは何か？　というコミュニケーションが行われて、インフラ開発者として新機能を提供して、アプリ開発者はその上でサービスをユーザーに提供します。

こういったコミュニケーションが密接にできることが、私たちがプライベートクラウドをホストしているメリットです。私たちは、サービスアプリケーションの要件に合わせて、インフラの開発に集中して、迅速にそれを提供可能です。こういったメリットのほかにも、コストの面であったりいろいろなメリットがあります。

Hyper-scale Internet Gateway

次に、ネットワーク開発チームのプロジェクトについて、いくつかピックアップして紹介します。まずはじめに、Hyper-scale Internet Gatewayと呼んでいるものです。元来、私たちのネットワークインフラの中には、NATの箱があります。それは物理的な箱で、物理的な箱がゆえに、どうしてもスケールの難しさがありました。

そこで、そのNATの箱をスケールできるような新しいアーキテクチャにしたいと思い、一からInternet Gatewayというサービスを立ち上げました。物理的な箱ではなくて、私たちはNATのサービスコンポーネントをNFVのようにVMの上にホストして運用しています。

このNFVの上に置いたNATサービスは、例えばNATとインターネットをつなぐところでもスケールアウトしますし、NATとサーバーをつなぐところでもL3でスケールアウトする構成になっています。その中では、ネットワークのいろいろなプロトコルであったり、カーネルで実装されている機能であったりを駆使してやっています。

Fine-grained end-to-end network quality monitoring

次にFine-grained end-to-end network quality monitoringを紹介します。このプロジェクトは、2015年にMicrosoftがPingmeshというプロジェクト名で論文を出していますが、それに近いものになっています。

サーバー間の通信を常に24時間365日モニタリングツールが監視していて、例えば遅延の増加や接続断を検知します。しかし、VerdaのネットワークはCLOSネットワーク構成になっているので、例えばこことここのサーバーが通信断しているからここのネットワークの機器がダメ、というのが非常に見つけづらいです。

ただ、単なる通信のモニタリングだけでは通信の問題を特定しづらい中で、通信の問題の原因箇所まで、例えばここのリンクに問題がある、このスイッチが問題になっているというところまで見つけ出すことを目指したプロジェクトになっています。

Multi-tenancy Networking with SRv6

次に、Multi-tenancy Networking with SRv6について紹介します。元来私たちのLINEのネットワークは、下図の左側のようにFull L3 CLOSネットワークの上に例えばLINEのメッセンジャーやLINEマンガなど、さまざまなサービスが載っています。

ただLINEのサービスの中で、そういったフラットなネットワーク上で動かすことが難しいサービスもいくつか出てきました。例えば右側に紹介しているFinancialのプロジェクトですね。LINE証券であったり、LINE Payであったり。

そういったサービスは、やっぱり独自に独立したネットワークが必要になりますので、SRv6プロトコルを使って仮想プライベートネットワークを作るプロジェクトになっています。

テクニカルには、ハイパーバイザーのあるサーバーの上で、仮想ネットワークごとに作ったLinux VRFでVMを終端して、そこからそのVMが接続する仮想ネットワークに属しているVMに向かって、SRv6のヘッダーを付けてパケットを投げています。このようにしてL3のオーバーレイを構築しているのが、このプロジェクトになっています。

LoadBalancer as a Service

最後にLoadBalancer as a Serviceについて紹介します。私たちのロードバランササービスは下図のようなアーキテクチャになっていて、左のクライアントからパケットがルーターに届くと、そのルーターからL3のECMPでロードバランシングされて、私たちが作っているXDPベースのL4LBに吸い込まれます。

そこでさらにL4のロードバランシングが行われて、KubernetesのPod上で動かしているL7LBのワークロードに吸い込まれて、そこでL7の処理がされて、サーバーにロードバランシングされる構成になっています。

このLayer 4 Load Balancerは、XDPを使っていて、特徴的なこととしてLinux Kernelの例えばTCP/IPのネットワークスタック処理のオーバーヘッドをなくすことができます。User landまでパケットを上にあげることなく、非常にNICに近い部分でネットワークの処理をしてパケットを返すことができる技術になっています。