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年ごろからプロジェクトをスタートしました。

VerdaはLINEのさまざまなサービスで利用されている

ベースとなっているのは，クラウド基盤に必要な機能を実装したオープンソースソフトウェアである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％影響を受けます，たぶんうまくいくけれどもたまに失敗することもある，といった形は怖くてやりたくない。そこで，壊れたとしても影響を受ける範囲，いわゆるブラストラディウスを小さくしていくことができるようにしなければならないという問題意識がありました。