SDPFクラウド/サーバファイアウォールサービスのテストを高速化した話

この記事では、SDPFクラウド/サーバで提供しているファイアウォールサービスについて、数週間かかっていたコントローラのテストを一新し、開発効率/品質向上に繋がった事例を紹介します。

はじめに

みなさん、こんにちは。現在、SDPFクラウド/サーバで提供しているファイアウォール/ロードバランサーのサービス開発業務に携わっています、片貝です。この記事では、数週間かかっていたファイアウォールサービスのテストを一新し、開発効率/品質向上に繋がった事例を紹介させていただきます。

ファイアウォールサービスとは

ファイアウォールサービスでは、IaaS環境の上で利用できる仮想ファイアウォールアプライアンスを提供しています。お客さまからの申し込み(API call/GUI操作)に合わせて、我々で管理/開発するファイアウォールコントローラが基盤となる仮想サーバー作成、NW接続、ファイアウォールの設定投入といった、サービスの提供に必要な操作を実施し、デプロイまでの自動化を実現しています。

テストにおける課題

ファイアウォールサービスでは、リソースの作成や削除といった基本機能はすでに実装されており、現在はお客さまからのフィードバックに基づいた機能追加や改善が行われています。このような機能追加の開発やリリースにおいて、コントローラへのソフトウェアテスト時にたびたび問題が生じていました。

問題1: テスト時間が長い

1つの問題は、テストにかかる時間が長いことです。ファイアウォールサービスの開発では、サービスの正常動作を担保するためのテストに2,3週間もの時間がこれまでかかっていました。その結果以下のような問題が発生していました。

開発効率低下
- たった数行の変更でさえも1時間以上の手動確認が必要になるなど、開発時間の多くをテスト実行が占める非効率的な状態でした。また、それによってスケジュールへの影響が出てしまうこともありました。
品質低下
- 変更ごとに全てのテストを実施すると、時間がかかりすぎて現実的ではないため、必要なテストに絞って実施するしかない状態となっていました。その結果テスト漏れもしばしばありました。
開発者のモチベーション低下
- 待ち時間が長く確認作業も煩雑であること、待機後のコンテキストスイッチによるコスト増など、開発者にとってストレスが生じていました。

問題2: テストツールのEOL

もう1つの問題は、使用しているテストツールのEoLです。ファイアウォールサービスの開発では社内で独自開発されたテストツールが使用されていましたが、そのツールがEoLを迎えることでサポートが受けられなくなるという問題が生じました。さらに、既存のテスト実装者がすでにチームを離れており、テストがオーパーツ化していたことや、新規参入者が独自のテストツールの習熟に時間がかかるという問題も発生していました。

テスト環境の一新

上記の問題を解決するため、これまでのテストについての観点や環境を刷新することを決めました。改善についての過程や方法を含めてその流れを追っていきます。

問題の調査と整理

まずはじめに行ったのが既存テストの調査です。開発のどのフェーズに時間が掛かっているか、時間がかかる要因としてどんなものがあるか、アンケートを用いて調査し、チーム内で議論を重ねました。その結果、現在の開発においては機能の追加や改善よりも、その動作確認におけるテストに多く比重が掛かっていることがチーム全体の総意であることがわかりました。また、遅くなる要因として多く挙げられたのが既存テストの仕組みです。現行のテストは、ファイアウォールとの結合を含めて全テストが実環境で実行されていたため、外部サービス(仮想サーバーやネットワークを管理するIaaSコントローラー)との依存関係がある状態でした。そのことが原因で以下のような問題が発生していました。

① 外部サービスの計画メンテナンスや一時的なエラーなど、本来テストしたいファイアウォールウォールコントローラ以外が原因でテストが失敗、中断、やり直しになる。
②そもそも外部サービスのAPI call(仮想サーバの起動やファイアウォールの設定反映待ち)が長い。その結果、外部結合に伴う処理がテストの開発時間を引き延ばし、問題1で挙げたさまざまな課題を誘発していました。

外部サービスのmock化

上記の調査を通して、外部サービスに依存したテストが問題だとわかったため、解消する取り組みとして外部サービスのmock化を行いました。具体的には仮想サーバ、ネットワーク操作、ファイアウォールの設定投入などAPI callをhookし、それら動作を模擬する実装に切り替えました。ファイアウォールの特定通信の可否を確認するテストなどは、実体がなければ詳細なテストは難しいため、外部サービスとの依存が必要となります。しかし、既存テストのほとんどは構築ロジック(仮想サーバの作成/削除や、ユーザネットワークと繋ぎこむ部分)のテストであり、外部サービスの挙動を十分に理解し模擬できれば依存は必要ないものとなっていました。そのためテストの品質を大きく損なうことなく、mock化を通してテストにおける課題を緩和できるだろうと判断しています。

apiごとのテスト実装

mock化を完了させた後はAPIごとのテスト実装です。 mock化した外部サービスを通してテストが実行できるよう、APIごとに新規でテストを実装しました。ここでは、既存のテストツールのEOLや習熟コストを考え、ファイアウォールコントローラ開発のメイン言語であるPythonのテストツールpytestへの移行も同時に行っています。全APIで約1300個のテストを新規で単体テストとして作り直しました。その結果これまで数週間かかっていたテストが1時間以内で終了するようになりました。

	Before	After
テスト所要時間	2,3週間	1h以内
外部結合	あり	なし
テストツール	社内独自ツール(EoL済み)	pytest

CIの導入

新規テスト実装を通した時間短縮の結果、頻繁にテスト内容を確認できるようになり、テストも安定してきたため、CIも導入できるようになりました。開発者はPRの作成や更新のみを行い、それをトリガーとしてテスト環境の作成や実行、Slack通知までを自動化しました。チーム内で、この通知をマージのゲートとして利用することで、開発者やレビュワーはテストの確認に負担をかけることなく開発を進めることができるようにもなりました。

テスト環境を一新して

テスト時間の短縮によって開発効率はもちろん開発者の体験までもが大幅に向上したと感じています。さらにCIの導入で、バグの早期検出から修正までが容易になり、リリース時の不安やリスクの軽減、サービスの品質向上へ繋がりました。全ての項目を合わせると4人で半年という期間がかかっていますが、このテスト環境の一新を土台としてスムーズな開発プロセスが確立され、その時間を費やした価値は十分にあると感じています。ユーザに直接提供する機能の開発ではないですが、こういった開発環境改善はチーム全体の文化の改善や効率性の向上をもたらすものと感じており、今後も取り組みを継続し、より良いサービスの提供に努めていきたいと思っています。

さいごに

今回、SDPFクラウド/サーバのファイアウォールサービスについて、テストを一新し開発効率/品質向上に繋がった事例について紹介させていただきました。この記事のようにファイアウォールサービスの開発チームでは、新機能の開発/改善に加え、開発のサイクル向上といった取り組みも行い、ユーザへの利益提供のために日々努力しています。 2024年4月現在、一緒に開発を進めてくれるメンバーを募集していますので、興味を持ってくださった方、以下のリンクから是非詳細をご覧ください。

https://hrmos.co/pages/nttcom0033/jobs/1928706488764108838

皆さまのご応募お待ちしています！