新卒エンジニアの仕事〜12月のインフラエンジニア編〜

こんにちは!2019年4月に新卒入社し、Verda室のネットワークの開発チームで業務を行なっている田口と申します。Verdaとは、社内サービス向けの大規模なプライベートクラウド基盤のことで、私はこのVerdaの業務のうち、ネットワークコンポーネントの開発を行っています。

LINEでは専用ハードウェア機器をベースとしたネットワーク運用はもちろん、XDPやDPDKをベースとした、ソフトウェアによるネットワークコンポーネントの開発にも力を入れています。このうち、Verdaのネットワーク開発チームでは、ソフトウェアを中心としたアプローチでVerdaを通したインフラの改善に取り組んでいます。

この記事では、新卒インフラエンジニアの仕事の一例として、ネットワークソフトウェアを対象にした性能計測と、品質維持というインフラ基盤を支える取り組みについて紹介します。

ソフトウェアベースのネットワーク基盤と性能維持

まず、私の業務の背景を説明するために、Verdaの状況と課題について軽く触れたいと思います。

Verdaは2017年のリリース以来、急速な成長を続けているプライベートクラウド基盤です。例えば、この一年間でVM数が2倍以上になり、LINEのメッセージングはじめ、多種多様なサービスがVerda上にデプロイされてきている状況です。そのため、サービスの開発速度に合わせて、基盤にも迅速性と柔軟性が求められています。

このような要求に対して、Verdaのネットワークではソフトウェアベースのアプローチを積極的に採用しています。

例えばVerdaでは、LBaaS (Load Balancer as a Service) の開発・運用をしていますが、特にそのうちLayer 4ロードバランサの部分はデータプレーン自体をネットワーク開発チームで独自に開発を行っています。また、データプレーンの実装は高速化のためにXDPと呼ばれるLinux Kernelの機能を活用しています。
他にも、LINEのサービスは多種多様であるため、マルチテナンシーを実現する必要がありますが、その実現にはSRv6という新しいルーティング技術を利用しています。SRv6は新しい技術なので他社での導入事例が少なく、ハードウェア機器もほとんど未対応の状況であったため、汎用サーバで動作するLinuxカーネル上のソフトウェア実装を利用しています。このように、ネットワーク開発チームでは、Verdaの重要な機能をソフトウェアで実現して、運用の柔軟性を向上させています。

もちろん、VerdaはLINEの大量のトラフィックを捌く基盤ですから、ソフトウェアの転送性能は非常に重要で、維持し続けなくてはなりません。そのためには、ベンチマークを定期的に行なってソフトウェアの実際のパフォーマンスを理解し続けることが必要となります。

しかし実際には、ベンチマークの度に何度もテスト環境を手動で構築していては、設定ミスや、そのときに用意できるリソースによる環境の差異が発生してしまいます。そうなっては、ベンチマーク結果同士を正しく比較できず、ソフトウェア開発の過程で性能低下が起きていても、それに気づけない可能性もあります。

私がチームに加わった時点では、統一的なベンチマークの仕組みが存在しておらず、上記の問題にうまく対処されているとは言えない状況でした。そこで、共通環境で宣言的なベンチマークをCI(Continuous Integration)的に行うことが重要だと考え、自動化システムを作成することになりました。

ロードバランサの自動テスト&ベンチマーク

私の最初の業務はロードバランサのユニットテスト(機能試験)とベンチマーク(性能試験)を自動的に実行してチーム内の別のロードバランサ開発担当者に分かり易く提示することでした。 Verdaのロードバランサはソフトウェアで実装されているため、ユニットテストは一般的なサーバアプリケーションと同様に、DroneというCIツール上で簡単に自動化することが出来ましたが、性能のベンチマークはそう単純ではありませんでした。

前提として、VerdaのロードバランサはXDPをベースに開発されており、物理NICのドライバのコンテキストでパケット処理が実行されるため、現状は物理環境上で動作させています。そのため、仮想環境ではなく、専用の物理環境でベンチマークを行う必要がありました。

他にも以下のように、考慮するべきことが複数ありました。

  1. どうやって高速にトラフィックを生成するか
  2. テスト環境をどうやってコンフィグするのか
  3. どんなベンチマークシナリオのテストをするのか

これらの問題に対しては、次のようなアプローチで問題解決を図りました。

  1. ソフトウェアベースの高速なトラフィックジェネレータを利用する
  2. 構成管理ツールを用いて自動化する
  3. ベースライン計測とロードバランサの特徴に合わせたベンチマークを実行

上記のアプローチを統合して、自動化システムを設計しました。このシステムでは、専用に構築した物理環境に対して、CIツールがAnsibleを利用してルーティング等のコンフィグを行います。その後、TRexという高速トラフィックジェネレータを利用することで、ベンチマークを実行します。

こちらが、完成したシステムの処理フローの概略図です。

ベンチマークシナリオの追加は、ロードバランサの開発者と相談しながら行いました。ちょうど、ロードバランサに加えられた新機能は特定のトラフィックパターンに対する性能低下が懸念されていたため、その状況を模したトラフィック生成プログラムを新たに追加し、開発者にフィードバックしました。このタスクのうち、実際のベンチマークシナリオ追加作業は、上記のベンチマーク環境が完成した後のタスクだったので、とてもに楽に行うことができました。 なぜなら、実際にやるべきことは、新しいトラフィック生成プログラムを作成してテスターに追加するだけで、その他の冗長なテスト実行タスクはすでに自動化されていたためです。

実際には、ベンチマークを設計する際、ロードバランサ固有の計測の難しさがありました。Verdaで用いているロードバランサーは仕様上、入力パケットと出力パケットの構造が変わる、IPIPトンネリング技術を用いているため、トラフィックジェネレータの受信側で期待するパケット構造とは異なるという問題があります。この問題に対しては、トラフィックジェネレータのプログラムを工夫して、意図しないパケットをNIC(Network Interface Card)のハードウェアではなく、ソフトウェアでカウントすることで対処しました。

現在では、ロードバランサのGitHubリポジトリに変更が加わると、自動的にベンチマークが専用環境で実行され、その結果がPull Request画面に投稿されます。

このシステムによって、ロードバランサの開発者は、開発途中のバージョンに関しても客観的な性能を知ることが可能になりました。しかし、改善点として「グラフ描画したい」、「過去との性能差を分かりやすくしたい」等の分かり易さに関する補助や、「どの処理にどの程度CPUコストを使ったか」といったパフォーマンス分析を補助する機能の追加も検討しています。更なる改良によって、チームの開発フローをより迅速で正確にしたいと思います。

ネットワーク開発をアジャイルに

実際にベンチマークを自動化してみて、そこには非常に多くの利点があることに気がつきました。 まず、Ansibleを利用して宣言的で自動化されたベンチマークは再現性が高いということです。性能に関連するパラメータを固定化できるため、誰がテストしても同じ結果を得ることが出来ます。 また、「このパラメータを変えたら性能がどう変わる?」といった検証を後から簡単に試せるようになりました。

その他にも、LBaaSの例のように、ネットワークソフトウェアもGitHubと連携することで、一般的なアプリケーションのように、性能の変化を開発フローに自然に組み込むことができ、意図しない性能低下を未然に防ぐことが可能になっています。

このようにネットワークソフトウェアの開発にも、一般的なソフトウェア開発で熟成されたテクニックを適用することで、単純に作業コストが減るだけではなく、副次的な利点が幾つもあります。

最近の事例としては、 XDPを利用したSRv6の新実装のベンチマーク自動化に取り組みました。

ここで言うSRv6の新実装とは、チーム内で現在取り組んでいるマルチテナンシー環境の高速化の一環で、当時インターン生だった斎藤さんが開発したものです。(この取り組みについては、過去にブログ記事がありますので、興味のある方はご参照ください。link: https://engineering.linecorp.com/ja/blog/intern2019-report-infra/

この自動ベンチマークシステムは、SRv6の新実装と既存実装を同じ環境でベンチマークして、性能の比較グラフまで生成できるものです。現在、このテストはオンデマンドで実行でき、ネットワーク機能の開発者に継続的にフィードバックをしています。これによって、開発者がフィードバックをもとに迅速に改善を行うことができています。

このシステムの作成過程でも、ネットワークソフトウェア固有の困難がありました。例えば、テストを実行するたびに測定結果にばらつきが生じるといった問題があります。割り込みが入るCPUコアの割り当てやキャッシュの状態など、原因はいくつか考えられますので、その都度原因を調査してテスト設定を見直す必要があります。このように、ベンチマーク自体も継続的にアップデートすることで、より信頼性の高いデータを計測できるように務めています。

この自動化システムによってSRv6データプレーン客観的な性能比較が可能になったことで、より多くのワークロードをVerda上で適用できるかどうかの判断が容易になりました。

Verda室での仕事

さて、これまでは私の具体的な取り組みについて紹介しました。次に、私の周りの環境に目を向けたいと思います。 Verda室は、ネットワーク開発チームの他に、OpenStackやKubernetesなどのクラウドプラットフォームを管理しているチームやストレージチーム、UIチームなどがあり、拠点も東京、福岡、京都、韓国と複数に分散しています。 メンバーが複数拠点にまたがっているチームもあり、母国語がバラバラなことが多いため、チームによって会話はほとんど英語の場合もあります。

私も、技術資料の作成やGitHubでのコミュニケーションはなるべく英語で行なっています。しかし、英語での会話に関しては今後の課題です。英語での直接的なコミュニケーションが出来ることでチーム外の人とスムーズにやり取りが進むことも多いため、今後チャレンジするべきだと思っています。

また、Verda室では技術カンファレンスやオープンコミュニティに積極的に参加しています。SRv6をはじめ、LINEで使用しているネットワーク技術は先進的なもので、機器ベンダーもサポート機能を実装したばかりであったり、まだテスト段階だったりします。 そのため、日々の業務で得られた知見はとても貴重で、発表内容には多くの注目が集まっています。

Verda室で採用している技術やアーキテクチャの情報は、可能な限り外部に対してオープンにしており、Verdaネットワークのデータプレーン・コントロールプレーン技術やLBaaS技術は既にJANOG等大規模なカンファレンスで発表が行われています。このように、チームの内部だけでなく外部からも、刺激の多い環境で働けていることを実感します。

おわりに

今回紹介した自動テスト・自動ベンチマークのシステムは新たなテスト対象を増やせるように柔軟に設計されているため、今後も新たな技術の性能検証に利用され、ネットワーク開発者の作業負担をずっと楽にしてくれると確信しています。

チーム配属から約半年間ですが、このような、クラウド基盤の品質を維持し続けるという重要な業務に関わることが出来て、大きなやりがいを感じています。

最後になりますが、これまで説明したVerda室での取り組みや、私の事例紹介を通して、Verdaのネットワーク開発に対して少しでも興味を持っていただければ嬉しいです。他の事例が知りたい場合は、技術カンファレンスでの資料が多数公開されています(最近の発表を以下に掲載しています)ので、調べてみてください。

ネットワーク開発チームの最近の発表