開発コスト・管理コストを縮小して、新しいチャレンジをエンジョイする　LINEのネットワーク開発チームが目指すところ

自己紹介

城倉弘樹氏（以下、城倉）：それでは私から発表を始めます。Verda Network Development Teamの紹介を行います。たぶんこれが今日の最後の発表なので、気合を入れていこうと思います。

最初に簡単な自己紹介です。Velda Platform室のネットワーク開発チームでシニアソフトウェアエンジニアをしている城倉と申します。LINEのネットワーク開発に関する仕事の企画とか、実際のシステムの開発・設計とか運用をリードする役割を持っていて、これらのロードマップの策定までやっています。

ネットワークに関することは、パケットのバイナリの処理、ソフトウェアデータパケット処理ぐらいのレイヤーから、SDN（Software Defined Networking）のプラットフォームまで、幅広く興味があっていろいろな仕事をしてきました。

セッションで説明する内容

本日話す内容は、先ほど弊社の白田より紹介した、ITサービスセンターのVelda Platform室、特にネットワーク開発チームというチームに関して紹介します。ここではLINEのプライベートクラウドのネットワークサービスのプロダクトだけでなく、それ以外のネットワーク開発にもフォーカスしていろいろやっています。

一般的にはネットワークファンクションサービスや、SDNエンジニアリングを横断的にやっていると思ってもらえればいいかと思います。具体的にはDNS、LB（Load Balancer）、NAT（Network Address Translation）、VPC（Virtual Private Cloud）、Closのオーケストレーターなどのプロダクトに責任を持っているチームです。

今日はまず、我々のチームで管理しているプロダクトを簡単に紹介しようと思います。最初に、具体的にやっていることから紹介します。

次に、これらのプロダクトの開発がどのようなトレンドに合わせて生み出されているかという背景や、我々のトレンドに関して紹介します。これは、より抽象的な話で、情勢に合わせて新しいプロダクトが生まれたり、プロジェクトが始まったりしていることがわかると思います。

最後に、そういったことをどのようなスタイルで処理しているのか。チームがどのように動いているかといった特徴について話します。

今日は時間がないので、一つひとつ細かく説明をすることは難しく、ざっくりと紹介するので、細かいことに関しては気になったポイントをメモしておいていただき、カジュアル面談でじっくりとお話ができたらと思います。

こういった時のために、今日話す内容のほとんどはブログや外部のテクニカルカンファレンスで講演しています。そのリンクも貼っているので、後ほどそちらも確認していただければと思います。

ネットワーク開発チームが管理しているプライベートクラウド

まずプライベートクラウドネットワークサービスに関して紹介します。先ほど説明が軽くあったとおり、Veldaはプライベートクラウドで、AWSやGCPなどと同様に専用のWeb UIがあります。LINEのサービスの開発者のみなさまは、このダッシュボード経由でサービスを利用してインフラや仮想インフラを構築します。

もちろん、WebのUIだけではなくREST APIもあるので、それを利用する人たちもいます。（スライドを示して）我々はその中で、赤く点線が引いてあるネットワークコンポーネントを開発・運用しています。

LINEの多くのサービスは、Veldaを用いてアプリケーションサービスを構築していて、Veldaのさまざまなサービスを使ってくれています。

ネットワークのサービスにフォーカスすると、サービスごとに必要に応じて使いたいネットワークサービスをオンデマンドに使うやり方で使ってくれています。そのため、DNSとL7 LBだけを使っているようなシンプルな人たちもいるし、L7とL4のロードバランサーの両方を使っている人もいるし、NATを使ったりより細かいことをやっているケースもたくさんあります。

先ほど1つ前のスライドで説明をしたダッシュボードについて説明します。赤い部分の裏側の話をこれからします。この中でも一番規模の大きな、アンダーレイネットワークのコントローラーに関するポイントをまずは説明します。

我々はこれを“Closネットワークコントローラー”と呼んでいます。簡単に説明すると、IP Closの経路フィルターやたくさん存在するスイッチを、SDNの力で設定したり管理するためのプラットフォームです。

こういったClosのネットワークを管理するツールは商用の製品でもありましたが、我々のニーズに合わせ、最小のエンジニアリングコストと柔軟性を発揮するために内製開発をするという挑戦を始めました。今動いているClosネットワークコントローラーは、バージョン2のClosネットワークコントローラーになります。

具体的にはベンダー非依存なデータモデルをSDNコントロールで管理するようにして、それらのモデルを活用して、データの投入をオペレーターやアフターレイヤーのシステムが行います。データモデルのインスタンスが変更されたり、ネットワークのインデントのようなものが変化したのを検知して、分散しているスイッチの上で動作しているエージェントがスイッチのコンフィグレーションを行うかたちをとっています。

（スライドを示して）我々のサービスではこういった宣言的なシステムを構築することが最近のトレンドになっているのですが、これもその1つになります。具体的なテクニカルスタックは書かれてあるとおりです。今はプロダクションインでAristaとCumulusを管理をしていて、これからSONiCを検証しつつ導入しようとしているところです。これに関しては、書かれているリンクが参考になると思います。

ここまではアンダーレイのネットワークでLINEのアプリケーション開発者の人たちが直接触るわけではなく、ネットワークサービスとかインフラコンポーネントが捌くシステムの話です。

プライベートクラウドのユーザーがコンフィグレーションするコンポーネント

ここから先は、プライベートクラウドのユーザーがコンフィグレーションするコンポーネントに関してです。

まずはロードバランサー。これは我々のネットワーク開発チームの中でもっとも古く、歴史のあるプロジェクトで2016年に開始をしています。はっきり言うと、これはプライベートクラウドが始まるちょっと前からすでに始まっていたプロジェクトです。

独自のソフトウェアベースのロードバランシングメカニズムをL4とL7で分けて、マルチレベルなロードバランシングを行いつつ、従来我々がインフラで導入していた2N構成を脱却して、N＋1構成でスケールアウトできるようにしている、ソフトウェアベースのロードバランサーです。

これもいろいろなところで発表しているので、詳しいところはそこを見てもらえればいいかなと思いますが、簡単に説明します。L4LBのデータプレーンはXDPでフルスクラッチで開発していて、L7LBのデータプレーンはHaproxyをKubernetes上に構築して、それらの設定をSDNで更新することで、L7LBとL4LBをマネージドに提供するようなシステムとなっています。

我々は、DNSでプライベートクラウドのレイヤーでマネージドなDNSサービスを同様に提供しています。これはとてもシンプルで、DNSのレコードテストを登録できるもので、ユーザーがロードバランサーのIPとかサーバーのIPに対して、直接FQDN（Fully Qualified Domain Name）を設定したい時に利用します。

そのバックエンドとしてDNSキャッシュサーバーとAuthサーバーのどちらも管理をしています。これもLINEが成長し始めた段階からずっとあったシステムでしたが、2019年から大規模な改修を始め、今は完全にリフレッシュされたバージョン2で動いています。これらに関してもJANOGで説明しています。

IP-Anycastを使ったN＋1構成でスケールアウトしやすく、かつとてもポータブルなアーキテクチャになっているので、これもより我々の中では先進的なデザインかなと思います。

次がNATサービス。インターネットゲートウェイですが、我々のデータセンターは最初はネットワークスライスみたいな概念がありませんでした。それぞれのVMが直接L3のネットワークに存在しており、重複ポイントがなかったので、外部アクセスをする時はパブリックIPをVMにアタッチして、それで大量のパブリックIPを消費してサービスを運用していました。

（NATサービスは）これらを削減したりIPアドレスを固定したり複数のサーバーで共有することで、より運用しやすくしたり、インフラの利用稼働効率を高めようというテーマで始めたプロダクトで、これが私がLINEに入って最初の大きな仕事になりました。

これに関してはSDNの開発を行っただけではなくて、FabricNATという、N＋1構成で多数のユーザーに対してスケールアウトできるルーティングアーキテクチャをよしなに構築して、それをもとにネットワークサービスを構築し、デプロイしたりしていました。これらに関してはLINE DEVELOPER DAYの資料や、gihyoさんの記事で取り上げていただいているので参考にしてください。

最後がVPC。“プライベートゾーン”と呼んでいますが、これが今の我々の1つのパラダイムシフトになっています。詳しい背景はこのあと説明しますが、簡単に言うと、我々は最近パブリッククラウドでいうVPCメカニズムみたいなものを開発して、一部のLINEのサービス向けにリリースしています。

これらは、ネットワークを分離することと、分離したネットワークと連携して動く、Site-to-Site VPNのような細かいネットワークサービス。あとは、外部とのネットワークとの接続をする、ネットワークゲートウェイの役割。現在はACL（Access Control List）やトラフィックミラーの細かい挙動みたいなものを開発したりしています。そういったメカニズムになっていて、我々のチームの中でも重要なプロダクトの1つになっています。

これに合わせてSDNプラットフォームのベースの部分からいろいろ一新しましたが、その内容は後から説明します。

ネットワーク開発チームのこれからのチャレンジ

ここまでが我々がすでに運用しているプロダクトです。こういったプロダクトがどのようなトレンドで生まれたのか、我々が今抱えているチャレンジに関して、簡単に説明します。

ここから言うことに従って、出てくるようなネクストアクションを我々がやることになるので、入社いただいた際にはこういった内容で仕事をしてもらうことになるかもしれません。

（スライドを示して）LINEのインフラストラクチャーを1つの円に見立てて配置をしています。グローバルに大きく分けて3つのリージョンを持っていて、これらのリージョンにインフラストラクチャーを構築しています。

LINE（には）、Verdaのようなプライベートクラウドだけじゃなくて、Dedicatedインフラストラクチャーが存在しています。これらは何かというと、比較的重要度の高いFinTechやヘルスケアサービスになります。

我々はすべてのアプリケーションサービスをプライベートクラウドに収容することはできておらず、サービスごとに都度構築するようなDedicatedインフラになっています。

実際のサイズ感に関しては、6月15日にあるInteropの講演で数字についても発表したいと思いますが、こういったDedicatedインフラがあります。

なぜDedicatedインフラを作らないといけないかというと、分離が足りていなかったからというのが結論になります。

例えば「1つのL3ネットワークを共有している」と先ほど言いましたが、それぞれ別のサービス間でIPでつながっています。もちろん、アプリケーションレイヤーで認証・認可をかけてフィルターをすることはできますが、より強固なサービスを構築する時に、IPの分離が必要になることは現実的に存在していて、そういったことが防げない状況になっている。

あとは、ネットワークが分離されていない分、ACLも大きなものを共有しなければいけなくなってしまっています。そのACLも何かしらのミスによって他のサービスの影響を受けることもあるし、内部でセキュリティインシデントが起きた時に自動的にACLが遮断されるようなメカニズムも存在しますが、その範囲が大きいことによって、本来起きるべきではない障害が起きることも存在します。

先ほど「VPCのサービスも作っている」と言いましたが、そういったこともあり、我々はわりと少ない人数でここまでたくさんのネットワーク開発をしてきて、そもそも人の手があまり足りていないと苦しんでいました。

今は5個以上のネットワークサービスを、だいたい8人、新卒の方が今日から入ってきたので10人ぐらいになりましたが、それぐらいでやっていて、これらの人数でプロダクトの発案やプロダクトオーナーを決めたり、設計、開発、運用までいろいろやらなきゃいけませんが、あまりスケールしない。

恐らく2021年ぐらいまでは、それぞれのコンポーネントを別々のソースツリー、別々の担当で開発していましたが、ここから先はすべてを1つのSDNプラットフォームに統一して、より少ないSDNアルゴリズムとSDNロジックのみをコンポーネントごとに開発して、開発コストやソフトウェアの管理コストを小さくして統一できるものは統一して、新しいチャレンジのところでエンジョイしていきたいというのが、我々BIG Unificationのチャレンジになります。

そういったこともあり、先ほど説明したようなNATサービスなどは比較的急いで開発してしまったこともあって、システムの堅牢性に問題があったり、出来が悪かったりするポイントもあります。（そのため、）こういった共通に使う統一的なプラットフォームとして、KloudNFVというSDNプラットフォームを用意し、それらに置き換えて技術的負債を回収しようとしています。

こういったSDNエンジニアリングは、ある原理に基づいて考えられています。私はSDNの成熟度にはレベルがあると考えていて、今、多くのSDNプロダクトはレベル2でコンフィグレーションを自動化するフェーズにありますが、これらをオペレーションしやすくするためにオペレーションステートを追加したり。

あとは、SDNでメンテナンスのレイヤーまで行ったり、システムを高速に開発できるようにしたりするレベルが存在すると私は考えていて。我々の共通のSDNプラットフォームは、そこを目指して今開発しているところです。

限りなく5に近付いてきているかもしれませんが、まだまだやることはたくさんあります。

そういった中で出てくる内容は、たくさんのオペレーションをオートメーションしないといけないというポイントで、先ほど説明したとおり、人に対してサービスがたくさんあり、しかもそれらのサービスにLINEのほとんどのトラフィックが乗るようなこともあるので、とても運用コストがかかってしまいます。

そういった運用にたくさんかかる時間を、より少ない時間で処理できるようにソフトウェアでがんばっていくというのが、我々の取り組みです。これは詳しくは説明できませんが、仮想ルータのクラスタを、SDNメカニズムを使って自動的にアップグレードするメカニズムで、我々は1歩進んだオートメーションまで適用するように、いろいろエンジニアリングチャレンジをしています。

​​ネットワーク開発チームの仕事の進めかた

最後に、簡単にそれらの仕事をどうしているのかを紹介します。これは、我々のチームの中でも強く安定して確立されたものではありませんが、我々はチームの構成を臨機応変にいろいろと実験しながら動いています。

先ほど説明したとおり、コンポーネントごとにユニットがあったり、複数のコンポーネントをまとめたユニットになったり、1つのチームでユニットも1つになっていたりとか、そういったものを半年ごとに繰り返し実験しながら、今は1チームの状態で動いています。

これらは、ネットワークサービスの数が増えたりネットワークサービスの上で動いているワークロードの数が増えても、我々が人の数を増やすことなくオペレーションできるようにするようなネットワークプラットフォームを作るために必要な、チームの分け方とか、ワークフローを考えるためにいろいろ実験しているところです。

システムのオペレーションやメンテナンス作業、カスタマーサポートも、我々が開発するだけではなく運用したりしています。そういったものにもいろいろコストがかかりますが、たくさんのマニュアルワークや、たくさんのカスタマーサポートマニュアルを読んでサポートするのではなく、そういったマニュアルワークをどんどん排除して、ソフトウェアエンジニアリングの力で負荷を減らすという原則を作ってやっています。

最後に、我々はこういった取り組みを日頃から外に出すようにしていて、オンボーディングの資料も資料を公開しています。あらかじめ外にどんどん情報を出すようにしているので、興味がある方はぜひ見てください。

以上になります。もしここまでザラッと説明しましたが、細かいポイントが気になるようであれば、カジュアル面談をしてもらえれば。我々は説明するのも楽しいですし、カジュアル面談からいろいろ新しいネタも出てきたりすることもあるので、興味があればぜひ参加・応募していただければ幸いです。以上で全部の説明になったと思います。