いかにネットワークを効率よく運用するか　LINEが取り組むネットワークオーケストレーション

LINEのネットワークオーケストレーション

土屋俊貴氏（以下、土屋）：ではLINEの土屋が、現在取り組んでいる「LINEのネットワークオーケストレーション」について紹介したいと思います。

まず自己紹介します。土屋俊貴と言います。2017年にLINEに新卒で入社して、最初はデータセンターネットワークの設計や構築、運用に携わっていました。また、運用に使うネットワーク関係のツールやアプリケーションの開発にも関わっていました。現在は、Verda室のネットワーク開発チームに所属していて、今日お話しするネットワークオーケストレーションのシステム設計や開発に携わっています。今日はよろしくお願いいたします。

LINEのネットワーク

それでは、今回の話はこのような流れで説明をしていきたいと思います。まずオーケストレーションの話に入る前に、LINEのネットワークについて簡単に概要を紹介したいと思います。

LINEのネットワーク、とくにデータセンターネットワークに関しては、ここ数年構築しているものは、CLOSネットワークというアーキテクチャを採用しています。CLOSネットワークは、East-West Trafficのネットワーク、サーバー間通信のトラフィックの増大に対応でき、またスイッチを横に並べていくことでスケールできるアーキテクチャになっています。

また一般的にこのCLOSネットワークでは、スイッチ間をBGPなどを使ってL3で接続することがよく行われていますが、LINEではこのBGPをスイッチ間だけではなく、スイッチとサーバーとの間もL3接続して、一番上のスイッチから一番下のサーバーまですべてL3でつながっている、フルL3のCLOSネットワークを構築しています。

このようにすることで、今まで運用してきたL2のネットワークで出てきた課題の解決であったり、L3を採用したことによるスケーラビリティの確保などができるようになっています。また、このCLOSネットワークのネットワークスイッチとして採用しているのは、ホワイトボックススイッチとして「Mellanox」、そしてその上にLinuxベースのOSとして「Cumulus Linux」を搭載した組み合わせで構築しています。

このような構成にすることで、Linuxのツールなどが利用できるようになって、構築の自動化や運用の自動化などを進められるようになっています。

今日はこのデータセンターネットワーク上で、今まで取り組んできたネットワーク運用自動化であったり、現在取り組んでいるネットワークオーケストレーションについて紹介していきたいと思います。

ネットワーク構築の自動化

それではまず、これまで取り組んできたものとして、ネットワーク運用自動化はどのようなことをしてきたかを紹介します。

まずネットワーク構築の自動化に関してです。このネットワーク構築に関しては、既に行っている方も多いのかと思いますが、Zero Touch ProvisioningやAnsibleを使って、構築の自動化を進めています。

例えば簡単に処理の流れを説明しますと、ネットワークを構築する際、スイッチの電源を入れるとスイッチが起動してきて、まずZTPのサーバーに対して、ZTPのスクリプトの取得と実行を行います。LINEではこのZTPの処理は、OSのインストールやライセンスのインストールなど最低限スイッチが動く部分までの処理を行っています。

そしてこのZTPの処理が終わった後、Ansibleサーバーからスイッチに対してインターフェースの設定やルーティングの設定、監視の設定などを行います。そして、このZTPとAnsibleの設定がそれぞれ完了すると、もう既にスイッチはサービスインできるような状態になります。

このような仕組みを作ることで、ネットワーク構築にかかる時間を短縮できます。またこのZTPやAnsibleの処理の流れは、障害が発生したときにも同様に使えます。例えばあるスイッチで障害が発生して、機器交換をしたいときにも、このスイッチを新しいスイッチに交換して、ZTPが行われた後にAnsibleで設定をすると、すぐにネットワークが復旧できる流れになります。

このような仕組みを作って、運用を効率化しています。

経路フィルタの自動設定

もう1つ、これまで行ってきたものとして、経路フィルタの自動設定があります。先ほど説明した通り、LINEではサーバーからもBGPを使って経路広報できます。そのため、本来経路広報すべきでない経路であっても、広報されてしまう可能性があります。

例えば右下の図で言うと、ServerAが、本来広報するべき10.1.1.1という経路を、本来広報するべきではないServerBからも広報されてきてしまうことが起こります。こうした問題をとくに何も制限していないと、本来ServerAに届くべき通信がServerBに届いてしまって、通信障害が発生する問題があります。

こうした問題を解決するために、LINEのネットワークでは、このToRスイッチに経路フィルタを設定して、本来意図していない経路は受信しないようにフィルタを設定しています。またこういった処理は、新しくサーバーが構築された場合に、このToRスイッチの経路フィルタを更新する必要があります。

サーバーはプライベートクラウド上でいつでも構築できるので、こうしたサーバーの構築に合わせてToRスイッチの設定を人手で実行するのは難しいです。そのため、このToRスイッチの経路フィルタを自動で設定する仕組みを作っています。

これが全体の流れになります。ここでは、右下のserverXが新しく構築されたときの処理の流れを説明していきます。このserverXが広報したい経路は、10.x.x.xというIPアドレスになります。まず準備段階として、Topology dataというコンポーネントがあります。このTopology dataにはどういった情報が入っているかというと、あるスイッチにどのサーバーが接続されているかという情報を保持しています。

この情報は、定期的にスイッチから取得して、保存データが更新されるようにしています。そしてこの状態でserverXが構築されると、このserverXを管理しているコントローラーがCLOSネットワークを管理しているコントローラーに対して「serverXというサーバーが10.x.x.xというIPを使います」というようなリクエストを投げます。

それを受けたコントローラーは、このserverXがどのスイッチにつながっているかを調べるために、Topology dataに対して問い合わせを投げます。その結果、serverXはSwitch-Aにつながっていることがわかるので、コントローラーからSwitch-Aに対して10.x.x.xというIPのフィルタを開けるよう設定を入れます。

最終的に、このスイッチのフィルタが更新されて、serverXから10.x.x.xのIPが受信できるようになります。このような流れでサーバーが構築されてからフィルタが更新され、サーバーが通信できるようになるまで、人の手を介さずに動くような仕組みを作っています。

ネットワーク運用自動化の課題

以上が、これまで進めてきたネットワーク運用自動化の大きな部分になるのですが、この運用自動化は、だんだんと運用を進めるにつれて、課題が見えてきました。

まず1つ目として、プライベートクラウドや他のサービスとの連携機能不足という問題があります。これは、当初このCLOSネットワークの運用はネットワーク運用者が変更して行うという想定で作っていたため、先ほどの経路フィルタの自動更新のような特定ケースのみ連携機能を提供していました。

ただ最近になって、プライベートクラウドの方針であったり、新しいネットワークサービスの開発によって、他のサービスとネットワーク自体を連携したいケースも多く出てきています。

例えば、先ほどの経路フィルタの自動更新でいうと、これまでは物理サーバーが構築されたときに経路フィルタを更新することを考えていればよかったのですが、新しいケースとして、VM自体がハイパーバイザーとBGPのピアを張って経路広報できるようになりました。

こうしたケースに、この経路フィルタの自動更新が対応していなかったので、現状はあらかじめIPのレンジを予約しておいてスイッチに設定しておくような対応をしている状況になっています。

またQoS設定に関してですが、これまでLINEのCLOSネットワークはノンブロッキングの構成を取っていたため、QoSの設定を行っていませんでした。最近では、構成の変更などを考えていて、それに伴ってQoSの設定を入れる必要が出てきています。そうした状況で、例えばモニタリングシステムなどと連携して、特定のアップリンクが輻輳してきたので、ダウンリンクを少し絞るといったような、QoSの自動設定などを行いたいということも出てきており、こうした連携機能を作っていく必要が出てきています。

もう1つの課題として、運用台数が増加してきたことによって、Ansibleで設定変更する時間がかなり長くなってしまっている問題があります。現在LINEで運用しているCLOSネットワークのネットワーク機器の台数は、2,000台を超えてきています。この状態で、例えば複数のサーバールームを同時に更新する場合、かなり時間がかかってしまいます。

もちろんAnsibleを使っているので、Ansibleを実行して、あとは放っておけば設定変更ができるわけですが、そのAnsibleを実行したあとに続く作業などもあるので、そういった部分で、Ansibleの実行時間が長くなると、そのあとの作業効率も低下してしまう課題があります。

また先ほどの1つ目の課題のサービス連携の中には、リクエストを送ってからすぐにスイッチ自体の設定を変更したいというようなケースも出てきています。そのため、リクエストを投げてからスイッチの反映がすぐにできるような構成を考える必要があります。

3つ目の課題として、ネットワーク機器やOSのマルチベンダー対応という課題があります。現状はMellanoxのホワイトボックススイッチとCumulus Linuxの組み合わせ1種類で運用をしている状況です。こうした状況のため、自動化の仕組みに関してもこの組み合わせを対象にした設計を行っています。

ですが最近、この組み合わせ以外にも対応できるようにしていきたいというニーズが出てきており、複数のOSやネットワーク機器に対応できるような仕組みを作っていく必要があります。

ただ、このようなマルチベンダーを対応するために、それぞれのOSごとに実装していったらとても対応しきれなくなるので、こうしたベンダー間の差は自動化を考える上ではなるべく考慮したくありません。もし考慮するにしても、できるだけ狭い範囲だけベンダー間の差を考慮するような仕組みにしたいという課題があり、その辺りを考えて対応していく必要があります。

以上がこれまでの運用自動化で出てきた3つの課題になるのですが、こうした課題を解決するために現在ネットワークオーケストレーションとして取り組んでいます。

ネットワークオーケストレーション

ではここから、ネットワークオーケストレーションの話に入っていきます。ネットワークオーケストレーションでは、この3つの課題をそれぞれ解決していきます。まず1つ目として、プライベートクラウドや他のサービスとの連携機能不足に関する部分ですが、これに関してはAPI経由で機器の設定変更がすべて行えるような仕組みを作っていきます。

また、2つ目の設定変更の長時間化という部分は後述しますが、設定変更を行うエージェントとして「Sync Agent」を開発していて、これをそれぞれのスイッチに配置して、スイッチが独立して設定変更を行うような構成にすることで、設定変更にかかる時間の短縮とスケール性をとっています。

そして3つ目のマルチベンダー対応に関してですが、ここではNAPALMという自動化ツールの出力結果をベースにしたデータモデルを使用しています。これによって、それぞれのOSごとの差などを考えなくていいような抽象化したデータを構成しています。そしてSync Agentで実際にスイッチを設定するときに、抽象化されたデータから設定すべきOSのデータに合わせて変換することで、マルチベンダー対応を行っています。

4つのアーキテクチャ

次に、現在取り組んでいるオーケストレーションについて全体のアーキテクチャを紹介します。このオーケストレータでは、主に4つのコンポーネントで構成をしています。

左上からZTP Server、API Server、etcd、Sync Agentの4種類です。ここでリージョンが2つ、RegionA、RegionBとありますが、LINEでは複数のリージョンでデータセンターを運用しています。そのため複数のリージョンに対応したかたちでアーキテクチャも検討をしています。

ZTPの処理

それではこれらのコンポーネントがどのような役割をもっているのか、処理の流れと合わせて説明していきたいと思います。

まずZTPの処理です。ZTPでは先ほど紹介したときと同じで、初期構築のときの設定を行う部分になります。ですので、先ほどと基本的にやっていることは変わらず、スイッチが起動したときにOSのインストールや初期設定を行うものになります。

またここでは、新しくSync Agentというスイッチに置くエージェントが増えたので、エージェントのデプロイも、このZTPのシステムで行っています。また、基本的にここだけ見ると先ほどと変更がないように見えますが、実際の処理は少し変わってきています。

先ほどと同様、スイッチが起動してきてZTPのスクリプトを取って実行する部分までは同じですが、ZTPのスクリプトを実行している最中に、ZTP Serverに対して設定のリクエストを投げます。そしてZTP Serverは、リクエストを受けるとこのスイッチに対してAnsibleを実行して、Sync Agentのデプロイや初期設定を行います。

これまではZTP Scriptですべての設定を行っていましたが、新しいZTPのシステムではAnsibleを使っています。その理由として、まず1つ目はZTP Scriptで複雑な処理をしたくないということがあります。ZTP Scriptは基本的にはシェルスクリプトであったり、Python Scriptのようなスクリプトです。

この1枚のスクリプトで複雑な処理をしてしまうと、デバッグなども難しくなってしまいますし、問題が起きたときに対応がしづらくなります。そのため、こうした複雑な処理は、なるべく適したものを使うべきという考えでAnsibleを使っています。

もう1つの理由として、ここで使っているAnsibleはZTP以外にも使うことがあります。例えばエージェントを更新したときに、スイッチ内のエージェントを更新するといったような処理にも、このAnsibleを使います。そのためこの初期設定やSync Agentのデプロイの処理を統一するために、Ansible経由で設定する構成を取っています。以上がZTPの処理の流れになります。

スイッチの設定変更

次にスイッチの設定を変更するときの処理の流れを紹介します。最初の準備段階として、Sync Agentは、スイッチの設定を保存しているetcdやスイッチ自身の情報を監視しています。そして、これらに変更があったときに、それをトリガーにしてエージェントが動作する仕組みになっています。

ここではあるサービスがスイッチの設定変更したいというケースの流れを紹介します。

まずServiceがAPI Serverに対してスイッチの変更をリクエストします。するとそのリクエストを受けたAPI Serverはetcdに保存されているスイッチの設定を更新します。このときetcdに保存されるのは、先ほど紹介したNAPALMをベースにしたデータモデルの形式のデータです。そのため、etcdに保存されているデータはOSごとの差は意識しないような形式になっています。

そして、Sync Agentがetcdのスイッチデータの変更を検知すると、そのデータを取得してきてスイッチに設定します。ここでスイッチに設定するときに、etcdに保存されているデータはそのままスイッチに設定できる形式になっていないので、スイッチに設定できる形式に変換したあと、実際のスイッチに変更する流れで動いていきます。

ここで、Sync Agentがスイッチに設定を入れる部分ですが、CumulusではAnsibleを使って設定を変更しています。そのため、Sync Agentはetcdから取ってきたデータをAnsibleのインベントリに変換します。ここでCumulusでの設定変更にAnsibleを使っているのは、Cumulusの設定変更する手段としてAnsibleが一番使いやすい手段だったからです。

ですので、もし他のOSを使った際に他の手段、例えばNETCONFなどが設定変更の手段として適しているのであれば、Sync Agentはそういった手段で設定をできるような実装をします。

経由フィルタの自動更新事例

以上が設定変更の流れになりますが、もう少し具体的なケースで処理の流れを説明していきたいと思います。ここでは、これまでの取り組みの部分でも紹介した経路フィルタの自動更新のときの処理の流れを紹介します。

ここに、Switch1、Switch2の2台のスイッチがあるとして、新しくSwitch1のInterface1にServerAが構築されたとします。ここでServerAが経路広報してくるべきIPは10.0.0.1になります。

ServerAを構築するとき、右上のServer ControllerからAPI Serverに対して、「ServerAが10.0.0.1というIPを使います」というリクエストを投げます。そして、API Serverはetcdにデータの保存をします。etcdはキーバリューストアですので、そのときのキーは”/servers/config/ホスト名”となります。

ここでSwitch1側に戻ると、ServerAとSwitch1の間はLLDPで情報を交換しています。ですので、Switch1から見ると、Interface1にServerAが接続されたことはわかっています。このLLDPの情報はSync Agentでも監視をしているので、Switch1にServerAが接続されたというのはSync Agentも検知します。そしてSync Agentがこの変更を検知すると、etcdに対してServerAの情報を取りに行きます。

その結果、ServerAは10.0.0.1というIPを使うことがわかるので、その10.0.0.1が受信できるように、Interface1に設定してあるprefix filterを更新する処理を行います。以上のような流れで、サーバーが構築されてから実際にスイッチが受信できるまでの処理が行われます。

これまでの取り組みの部分では、CLOSコントローラがスイッチに対してAnsibleを実行していたのでその部分で少しラグがあったのですが、新しい構成では、ServerAが接続されたことをすぐにSync Agentが検知して設定変更を行うので、実際にサーバーが構築されてからprefix filterが更新されるまで、即時に反映できるような構成を取っています。

以上が、ネットワークオーケストレーションのアーキテクチャと主な処理の流れになっています。

ネットワークオーケストレーションは開発中

まとめとして、今回はLINEで行ってきたネットワーク運用自動化について紹介しました。これまでの取り組みとして、ZTPやAnsibleを使ってどのように自動化をしていたかというものであったり、その運用を進めるにつれて出てきた自動化に関する課題なども紹介しました。そして、この課題に対して現在取り組んでいるネットワークオーケストレーションについてアーキテクチャやシステムを紹介しました。

このネットワークオーケストレーションは現在開発している最中となっていまして、これからどんどん出てくるであろうさまざまなネットワークサービスと連携して、ネットワーク自体も柔軟に変更できるようなシステムも開発しています。

以上が私からのLINEのネットワークオーケストレーションについての紹介となります。ありがとうございました。