ネットワークの運用の取り組み
安藤格也氏：「ネットワークの運用の取り組み」について発表させていただきます。
最初に自己紹介をさせていただきます。
自分は2011年新卒で入社し、決済チームで開発と運用を実施してきました。そのあと、ネットワークの勉強がしたかったため、弊社の特徴である「ジョブチェン」というシステムにより、今はデータセンターネットワークで自動化周りを担当しています。最近ではGolangやPythonをふだんの仕事で利用しています。
今回は、どちらかというとネットワークの構成ではなく、「ネットワークの運用」についてのお話です。
まず、ネットワークの取り組みについてお話しさせてください。
最初に、Yahoo! JAPANのネットワークの規模は年々拡大するビジネスに伴い、今では9,000台ほどになりました。また、ネットワーク機器のベンダー数はだいたい10数社ほどで、大手のネットワーク機器ベンダーなどを利用しています。
また、ネットワークの種類も年々増加しています。本番環境や開発環境以外にセキュア環境、プロダクションでありながら社外では使えないネットワークや子会社のものを作ったりと、さまざまな要件に従ってネットワークの種類が増えています。
ネットワークの種類が増えるにつれ、ネットワークの複雑化が課題となります。1ヶ月あたりのネットワークの作業依頼数は4,000件ほどで、ネットワーク以外にDNSやNTPなども担当しています。
それを今は開発・運用者で30名ほどでやっていて、構築・運用・障害対応・検証などをすべて実施しています。
オペレーションの種類は、ネットワーク機器の構築では実際にデータセンターに行って、機器を設置し、配線を行い、設定を入れるといった最初の物理作業も実施しています。
こちらの右側の図は、FacebookのBackpackを実際に設置している図です。 他に、ロードバランサーなども構築していて、こちらに関しても実際にデータセンターで設置しています。
設置したロードバランサーのVIPの作成・削除を行い、そのたびに細かい初期設定や手順書を作っています。
このようにネットワークの種類が増えたり、機器の種類が増えたり、オペレーションがあったりと年々複雑化してきていることへの対処として、弊社は利用するネットワークの種類やネットワーク機器の種類を減らそうといった取り組みや自動化を推進してきました。今回、そのうちの「運用の自動化」についてお話をさせていただきます。
ネットワークの構造
自動化と言っても、まずネットワークがどうなっているかについてのお話です。
こちらは概略図です。
実際にインターネットからこちらに入ってきたものがBorder Routerのところに行き、そのあとに枠線で囲ってあるところのデータセンター内のネットワークに入ってきます。今回はその部分に関してお話します。
先ほど神尾から少し話がありましたが、トラフィックの流れが今と昔で変わってきています。昔はユーザーからリクエストがあり、サーバから返して終わる縦の通信が重要でした。
今では、実際にストレージのアクセスはもちろん、サーバ間・API間の通信が非常に増えていて、横の通信が増えているのが現状です。
それに対するネットワーク構成がこちらの図にも書いてあるとおり、Clos Networkです。
こちらはGoogle、Facebook、AmazonなどといったOTTなどが実際に使っているネットワーク構成で、弊社は現在こちらに移行中です。
先ほどとなにが大きく変わったかというと、L3のレイヤーがトップオブラックのLeaf Switchのところまで降りてきているのが特徴です。古いネットワークではCore SwitchのところがL3の境界だったのですが、CLOS NetworkトップオブラックであるLeaf Switchのところまで降りてきています。これにより、L2ループを考える必要がなくなりUPLINKをフル活用できるようになっています。
この詳細に関しては、弊社の村越がJANOG38で発表しましたので、そちらをご参照いただけると幸いです。
弊社の自動化戦略に関しては、まず古いネットワークと新しいネットワークとで戦略を変えようという方針で進めています。なぜかといいますと、古いネットワークでは古い機器がとても多く、実際に利用できるAPIの数が少ないからです。それに対しClos Networkでは新しい機器を使っているので、今の時代にあったAPIを利用できます。
そのため、「古いネットワークは自分たちで内製して努力して進めていこう。新しいものに関してはOSSの自動化ツールなどを使っていこう」ということで進めていきました。
自動化にもコストがかかるため、古いネットワークでは自動化を諦めた方がいいんじゃないかという話もありました。ただ、古いネットワークのオペレーションも数多くあるため、そちらもがんばってみました。
内製ツールのしくみ
最初に話をさせていただきましたが、マルチベンダーを利用していることに起因する問題点がございます。まず簡単に実装しようと思っても、抽象化を進めなければいけない点です。
こちらがその自動化をしていこうと決めたときの、OSごとのAPIをまとめた表です。例えばCiscoさんのIOSではSSHでCLIから情報を取得する以外のすべがありませんでした。
右側の黒い画面は実際にCLIで取っている情報です。ご覧のとおり、構造化されている情報ではないので人が見るには見やすいのですが、プログラムから見るとするとすごく扱いづらい情報です。
NXOSだとAPIはNetconfでとれます。NetconfはSSHのサブシステムを利用し、そこにXMLを流して情報を取得するプロトコルです。
Juniper JUNOSもNetconfが使えます。Arista EOSはAPIで取得して、Brocade NetIronはCLI。といった形で進めていました。しかし、実際にネットワークを抽象化していった中で変わったのが右下となります。
結局、NetconfはXMLの情報を扱えますが、XMLの中身が右上の方に、CLIでそのまま叩いたものとまるっきり同じような形で取れてしまい「なんのためのXMLなのか？」みたいな話もあり、いろいろ試行錯誤がありました。
その結果、「結局XMLで取っても構造化されないんだったら、もう最初からXMLで取るのはやめよう」といった話も出たため、CLIで取るものをベースに作っていきました。
それぞれの機器に対して情報取得方法が決まったので、そこから取れる情報を共通モデルとして定義できました。
左側のSphinxのドキュメントに関しては、先ほどの結果を実際にオブジェクト化したものです。
このようにコアとなる考え方のみ定義していて、できるだけすべてのOSで扱えるものを吟味してきました。それで重要なのが、元々のデータ構造を厳密に意識しすぎず、自分たちの処理で必要ものだけに抑えるようにしました。
そうして作っていったものを利用し、実際にオペレーションを自動化していきました。
運用者がコマンドを実際に実行してネットワーク機器に設定を入れたり、Jenkinsからコマンドを実行して設定を入れています。どちらかというと運用者がやるのではなく、Jenkinsに処理させています。
こちらの詳しいことに関してはJANOG40で発表しましたので、そちらを参照していただけますと幸いです。また、監視でPrometheusをフルに活用している話もありますので、Prometheusに興味がある方はぜひこちらをご覧ください。
これは最初にお伝えしたオペレーションの種類です。
これらの内製ツール推進後は、このように赤く塗ったところが実際に自動化ができるようになったところとなります。
また、今回説明していないZTP（ゼロ・タッチ・プロビジョニング）というものでも自動化を進めているため、ネットワーク機器の構築についても自動化されています。
右側は、JenkinsのPrometheusプラグインで数字をとり、Jenkinsで実際に動いているビルド数を図で示したものです。多く自動化することができました。ここまでが内製ツールの説明です。
Clos Networkの自動化
次はClos Networkの自動化の話に移ります。Clos NetworkではAnsible・Cumulus・RFC5549を組み合わせた話です。
まず用語の説明をさせていただきます。Cumulusとは、ホワイトボックススイッチ向けのLinuxディストリビューションです。ほかのネットワークベンダーでもLinuxベースに動いているものはありますが、よりLinuxを使っているように利用できるのがCumulusの特徴です。
RFC5549は、IPv6のリンクローカルアドレスを使用し、IPv4の経路を広報することができます。
CumulusLinuxは、よりシンプルに設定を記載することができ、AS番号も省略することができるため、ノードごとのneighborのアドレス、リモートASを記載する必要がありましたが、それが不要になりました。結果として、機器ごとの設定がとても削減され、設定が容易になりました。
こちらがAnsibleのPlaybookになっていて、ご覧のとおりとてもシンプルなんですね。インターフェースの設定は/etc/network/interfacesで設定できて、そのあとにネットワーキングをリロードします。
ルーティング設定に関しても、/etc/frr/frr.confで設定できるので、テンプレートをコピーするというとてもシンプルなPlaybookで済みました。
また、Playbookでの設定が正しいことを保証することとして、CIを回しました。
Cumulusでは、試しに利用したり、テストで利用することができるCumulusVXというVirtual Applianceがあり、ネットワークを作ります。そこにAnsibleで設定を流して、設定が正しいことを検証できます。
これを実行してみて悪かった点は、ネットワークを1から作っていくため、テストの速度が少し遅かったかなというところでした。
良かった点は、今までのネットワーク機器においてなかなかCIを回せない環境でした。というのは、ハードウェアが必要になってくるからですが、そこができるようになったのはとても良かったと思います。
また、Ansibleでyamlファイルを作るだけなので、プログラミングが苦手なネットワークエンジニアでも自動化に参加しやすくなったと言えるでしょう。
また、機器ごとの変数が減ることによって設定がとてもシンプルになるため、構造理解が容易になりました。
Apstraについて
次はアプライアンスツールのApstraについてです。
こちらはインテントベースのネットワークシステムで、オペレーターが意図したネットワークをシンプルに作ることができます。また、マルチベンダーをサポートしていて、Cisco、Arista、Cumulusなども対応しています。
また、ネットワークのテレメトリーをサポートしているため、そのテレメトリー情報で取れたデータをGUI上で表示でき、そこからアラートをあげることができます。
また、gRPCでエクスポートもできるため、Telegrafを介してInfluxDBやPrometheusのPushgatewayにExportすることが可能です。
Apstraを利用するためには、AOSエージェントをネットワーク機器上にインストールする必要がありますが、ApstraではZTPのソリューションとしてApstra ZTPというものがあります。
それを利用して機器のmgmtインターフェースをマネジメントネットワークに接続するだけで、実際に数分後〜十数分後にはAOSが運用できるようになり、設定が利用可能な状態となります。
Apstraの良かった点としては、マルチベンダーなのでOSを意識する必要性がなくなったことが良かったです。
また、GUI上のみでデプロイまでできるため、慣れてしまえば簡単に利用できます。
あとテレメトリー情報は、自分でgRPCを受け取るプログラムを書くといった必要がなく、実際にApstraを通してエクスポートできるため、テレメトリー情報の連携ができました。
悪かった点は、インテントベースに慣れるまでなかなか時間がかかったところかなと思います。
巨大インフラを提供し続けるために
まとめです。より良いネットワークを作るのはもちろん、運用の自動化にも力を入れています。Legacy NetworkではOSSを組み合わせた内製ツールを利用しています。Clos NetworkではOSSや製品を組み合わせて利用しています。
プライベートクラウド、クラウドストレージ、ネットワークなど、扱うコンポーネントは異なっても、実際の課題は非常に大規模かつ多様な環境が存在していることに起因しています。このようなインフラ環境を提供し管理するために、我々サイトオペレーション本部は常に改善を続けています。
サイトオペレーション本部は、Yahoo! JAPANの巨大インフラを支えるプロフェッショナル集団として、今後もYahoo! JAPANのインフラをUPDATEしていきます。ご清聴ありがとうございました。
（会場拍手）
