LINE ITSC Verda Network Development Team シニアソフトウェアエンジニア 城倉弘樹（右）

LINEのプライベートクラウドである「Verda」のネットワーク開発を担うシニアソフトウェアエンジニアである城倉弘樹氏は、「⁠LINE DEVELOPER DAY 2020」において、「⁠Hyperscale distributed NAT system and software engineering」のタイトルで講演しました。そこで解説されたNATサービスを開発した背景や利用した技術、得られた知見などについて、城倉氏にお話を伺いました。

LINEがプライベートクラウドでサービスを運用する理由

――LINEで使われている「Verda」はどのようなインフラなのでしょうか。

城倉：LINEの多くのサービスは、Amazon Web Services（AWS）やGoogle Cloud Platform（GCP）といったパブリッククラウドサービスを使うのではなく、LINEの社内で構築したプライベートクラウドを利用して運用しています。そのプライベートクラウドの名称がVerdaで、2016年ごろからプロジェクトをスタートしました。

ベースとなっているのは、クラウド基盤に必要な機能を実装したオープンソースソフトウェアであるOpenStackです。このOpenStackには、仮想マシンやネットワーク、DNSなどの機能やメカニズムが搭載されていますが、それに我々が必要な機能を追加したり、あるいはLINEで求められるビジネスロジックをバンドルしたりして提供しています。

それに加えて、Kubernetesやデータベース、メッセージング、ファンクションサービスといった追加のサービスも同様に提供しています。こうした機能をマネージドに提供することも、プライベートクラウドの開発に携わる私のチームが中心となり対応しています。このように、OpenStackだけでなくさまざまな追加のサービスも提供しているプライベートクラウドがVerdaです。

また独自に開発している機能もあり、たとえばロードバランサやベアメタルサーバの機能などはVerdaチームの中で開発を行いました。また今回新たに提供を開始したNAT機能も内製です。このように、必要な機能を独自に開発していることもVerdaの特徴です。

――パブリッククラウドを使わず、プライベートクラウドを独自に構築した理由を教えてください。

城倉：まず費用的な面があります。AWSなどのクラウドサービスには数多くの機能がありますが、必要のない機能を省いてシンプルな形にすれば、低コストでクラウドを実現することができるという考え方からVerdaプロジェクトはスタートしています。

2つ目のポイントは、ユーザニーズへのきめ細かな対応です。内製であれば、サービスを開発しているエンジニアの声をダイレクトに聞くことができて、細かいニーズに合わせて機能を提供したり、カスタマイズすることが可能になります。こうしたエンジニアのニーズに基づいた開発を、より幅広く、かつ迅速に行えるのはプライベートクラウドの強みであると考えています。

数万台のVMが収容する大規模NATの開発

――NATサービスを開発することになった背景を聞かせてください。

城倉：当初、Verdaはすごくシンプルにインフラの機能を提供していました。このシンプルがゆえの課題があり、それに対処するためにNATを開発する必要性が生じました。

具体的に言うと、Verdaを使ってさまざまなサービスが運用されていますが、一方で強いアイソレーションは行っていません。パブリッククラウドであれば、テナントごとにネットワークが分離されていて、相互に接続できないようになっています。これに対してVerdaは、すべてのVMが1つのネットワーク上に存在しています。ネットワークを終端するような機器もなく、すべてのVMが直接インターネットにつながる構成になっていました。

このような構成であるため、インターネットに接続する際にはそれぞれのVMがパブリックIPアドレスを所持している必要があります。たとえば外部にデータをアップロードするサーバーが32台いれば、そのためにパブリックIPアドレスを32個も消費してしまうことになります。このように、現状の構成ではパブリックIPアドレスを大量に使ってしまうという問題がありました。

またファイアウォールのような機能を、特定のプロジェクトごとに提供するといったことが難しいことも課題でした。現状は1つのファイアウォールをすべてのサービスで共有するといったデザインになっているため、今後さらにサービスが増えていくと厳しくなるのではないかと考えていたこともポイントです。

これらの課題に対し、パブリックIPアドレスの枯渇を回避するためにNATサービスを提供しようということになり、さらにファイアウォールやアクセスコントロールの機能などを提供できるNATサービスがあれば、個別にファイアウォールの機能を提供するなど、今後のインフラにおける機能拡充にも対応することが可能になります。このような背景から、独自にNATサービスを開発することを決めました。

――今回のプロジェクトを進めるにあたって、意識したことはどういったことでしょうか。

城倉：パブリッククラウドやOpenStackのNATサービスは、アイソレートされたネットワークでNATが使えるようになっています。しかしVerdaはすべてのプロジェクトのVMが1つのネットワークを共有しています。そのVMはリージョンごとに数万台存在します。それだけの数を収容できるNATメカニズムを作る必要がありました。

ネットワークの文脈では、キャリアグレードNATと呼ばれる大規模NATもあります。これはネットワーク的に要求の高い技術であり、それを自分たちでクラウドに最適な状態で作らなければならないというのは、メカニズム的に難しい面があると感じていました。

こうした大規模NATは、グレイスフルなフェイルオーバー機能を持ったNATです。全体的に見てアクティブ－スタンバイで動作し、グレイスフルなフェイルオーバーが起きたときは100％のユーザーが影響を受けます。これはあまり嬉しくありません。

これに対し、クラウドなどモダンな仮想インフラは、壊れることを許容してシステムを構成できるようになっています。ただ、壊れることは許容しているけれど、壊れたときに100％影響を受けます、たぶんうまくいくけれどもたまに失敗することもある、といった形は怖くてやりたくない。そこで、壊れたとしても影響を受ける範囲、いわゆるブラストラディウスを小さくしていくことができるようにしなければならないという問題意識がありました。

強固なNATサービスを実現した宣言的な設定

――今回のNATサービスの開発では、分散KVSのetcdと、クラスタ管理ツールのConsulを使われています。これらを採用した理由は何だったのでしょうか。

城倉：etcdはVerdaのネットワーク開発チームでよく使っているソフトウェアであり、どう使えばいいのかなど、我々なりの知見がありました。そういった背景から、必要なデータを分散システムに効率的に届けることを考えたとき、etcdを使えばいいとすんなり決まりました。

Consulについても、我々の中ですでにロードバランサのチームが使っています。このロードバランサは内製のもので、大規模に使っている老舗のネットワークサービスになります。そこでConsulの活用例やうまく利用するためのポイントなどについて、チームのメンバーから情報を得られたことが決め手となりました。

今回のNATサービスのような分散システム的を開発するとき、大きく分けて2種類の方法があります。1つはリモートプロシージャコールを使って分散しているノードに対してこれを設定しなさいと通知するパターン。2つ目は設定を宣言的に記述し、それをどこかのデータベースに書き込んでおく。そして分散システムの各ノードはその宣言的な設定を自分で取得し、自律的に設定を行って動作するパターンです。

Kubernetesは後者の分散システム的なアーキテクチャを強く尊重したデザインになっています。そういったKubernetesのようなメカニズムを作るときに、本質的に必要な機能をきれいにカバーしてくれたのがConsulとetcdでした。

城倉：ネットワークとソフトウェアの2つの観点があります。まずネットワークの観点では、ブラストラディウスを小さくするNATルーティングの手法を自分たちで考えてサービスとして開発した点です。

ただ、これは素晴らしいメカニズムだと思っているわけではなく、試行錯誤しつつプロダクションサービスとして開発した、そのネットワークエンジニアとしてのチャレンジはアピールできるポイントかなと考えています。

ソフトウェアに関する部分でおもしろいと思うのは、やはりKubernetesのような宣言的な方式を採用し、ネットワークサービスを作ったという部分です。ネットワークやソフトウェアに興味がある人には、そういった部分に注目していただけると楽しめるのではないでしょうか。

――今回のプロジェクトで得られた知見としては、どういったものがありましたか。

城倉：やはり分散システムを宣言的なメカニズムで実現したことですね。ソフトウェアにトラブルが発生しても、そのノードで動いているソフトウェアを再起動すれば、宣言的な設定に応じて自律的に設定を行い、設定が変わっていても自分で設定するといった特徴が、そもそもの宣言的分散システムのメカニズムにはあります。

リモートプロシージャコールを使った場合、設定を送ろうとしたノードが再起動中の可能性があり、それをケアするメカニズムを新たに作らなければなりません。その意味で、Kubernetesの宣言的な概念を参照したのは、ある程度壊れながらでもサービスを提供できるポイントとしてよかったと思っています。

また、このデザインのためにetcdやConsulを使い、足りない部分をGo言語で書くといった仕事をしましたが、これはすべてKubernetesの上に載せられることがプロジェクトが終わるころに徐々にわかってきました。今回、宣言的設定のための分散システムメカニズムを構築しましたが、Kubernetesでもそういった機能をカスタムリソースとして提供していて、それをうまく活用することでもうちょっと簡単に作れたのかなと後から思ったんです。

現在はパブリッククラウドで提供されているVPC（Virtual Private Cloud）の機能を作っていて、その上でNATサービスと似たようなロジックを実現するためにKubernetesを利用し、開発コストを下げたいと考えています。実際に検証も行い、Kubernetesでも実現できそうだと確認しました。

このように、大きなエネルギーを注いでチャレンジし、その結果こうすればもっと良くなるかもしれないといった知見が蓄積されることは、チームとしてよいことだと思っています。

――Verdaの今後の開発について伺わせてください。

城倉：現状ではVerdaを使っていないサービスもありますが、LINEのすべてのサービスをVerda上で動かしたいと考えています。

ではVerdaがカバーできていないサービスはどのようなものかというと、FinTechやヘルスケアなど、アイソレーションに対する要求が高いサービスです。現在手がけているVPCもそのためのものであり、要求の高いサービスをサポートするためのインフラ機能の開発を積極的に進めています。

現在LINEには数多くのサービスがありますが、現状のVerdaではすべてのサービスが満足できる状態ではないため、もっと頑張らなくてはならないと考えています。そういった部分でチャレンジはまだまだ続けているので、ぜひ今後にも注目していただきたいと思います。

――本日はありがとうございました。