はじめに
こんにちは！FJCTエンジニアタスクフォース（ETF）の中井です。「FJCTQualityUp」連載2本目の本稿は、「富士通クラウドテクノロジーズ Advent Calendar 2022」24日目の記事でもあります。
前回の「FJCTQualityUp」の記事は「インフラの構築自動化ツール Ansible を通した運用の安定」です。気になる方はそちらもご覧ください！
また、「富士通クラウドテクノロジーズ Advent Calendar 2022」の昨日の記事は、@Authnsさんによる、 「TauriでSVGのグラフ描画・保存をしてくれるデスクトップアプリ作成」でした。練習課題代わりに同期が望むアプリケーションを作る世界って素敵ですよね。pakpieはまだ改善中とのことですが、いつか正式リリースされるのを楽しみにしたいと思います。
この記事ではIaaS基盤のテスト環境の構築とその運用方法をテーマにIaaS基盤周りを担当するエンジニアにインタビューした様子をお届けします♪
FJCTQualityUpについて
こちらの連載記事では「FJCTQualityUp」と題して、富士通クラウドテクノロジーズ株式会社（以降FJCT）のエンジニアに「FJCTのサービス品質向上のために何をしているのか」を様々なトピックを話題に社員にインタビューをしていきます。
エンジニアの生の声が、これからエンジニアを目指す方、今まさに課題解決に取り組んでいる同業者、その他大勢の方にとって参考になる、明日からの実践のきっかけになることを願っています。
第二回：IaaS基盤のテスト環境を構築する仕組みと取り組みについて
まずは自己紹介
中井：今回は、「IaaS基盤のテスト環境を構築する仕組みと取り組み」をテーマに、ニフクラのネットワーク周りを担当するチームに所属する二人にインタビューをさせていただければと思います。どうぞよろしくお願いいたします！
伊藤：よろしくお願いします。ネットワークサービス部）仮想ネットワークチーム の伊藤です。今関わっている業務は、ニフクラの仮想化基盤の面倒を見ることが中心です。具体的には、ニフクラの内部向けアプリケーションのデプロイ先の基盤を仮想マシンからコンテナベースに移行を推進させることで、Kubernetesクラスターの構築・運用周りを見るのがメインになります。後は仮想ネットワークチームのリーダー的な仕事もしております。
山口：同じく、仮想ネットワークチームに所属する山口です。自分は伊藤さんよりも年次が1つ下になります。自分の主な業務は、ネットワークサービスで利用している基盤のマイグレーションのためのプロジェクトを担当しています。具体的には、インフラの技術検証や既存のできていたことを新しい基盤でも実施できるかの確認と、基盤のためのAPIを開発しています。
IaaS基盤のテスト環境について
中井：まず、「IaaS基盤のテスト環境」が社内で運用されるようになった背景と、どういうものなのか教えてほしいです。
伊藤：弊社では、クラウドの開発・運用にVMware社の製品を利用しているため、VMware製品と連動するアプリケーションを内製することが多いです。そのため、VMware製品に関連したテストをすることや、アプリケーション開発のために検証するシーンが頻繫に発生します。ただ、必要に応じてテスト・検証環境を用意するのは大変なので、IaaS基盤のテスト環境を迅速に構築できる仕組みを作ったのがそもそもの背景になります。
伊藤：また、クリーンな(別件での操作による影響が残っていない)状態でテスト環境を用意できるようにもなっています。以前からテストや検証用途の環境は存在していましたが、共用環境だったため、個々の操作が干渉しあって問題が生じたり、テストを書いても環境の状況が変わってしまって、今まで動いていたものが上手く動かないということが起こりえます。なので、みんながテスト環境がほしいという中で、それぞれが独立して扱えるクリーンな環境を、都度構築するのではなく素早く入手できることを実現しています。
伊藤：VMwareの仮想基盤の主要なコンポーネントにESXiと呼ばれるハイパーバイザーがあります。通常はESXiを物理サーバーにインストールすることで、仮想マシンを作成・管理できるようになるのですが、このESXiを仮想マシン内にインストールするNested ESXiと呼ばれる再仮想化の手法があります。この手法を利用しつつ、ネットワークやストレージも仮想環境上で個々のテスト環境ごとに個別に作成することで、仮想マシンを複製する時と同じような感覚でVMware製品が既にデプロイされた環境を丸ごとコピーできるようにしたってイメージになります。
（エンジニア向けの補足：仮想化されたハイパーバイザーやストレージを含む複数のVMで環境を構築しておき、これらを複製して同じ環境を作成できるので、これを実現するCLIツールとVMイメージ群を作っています。Hashicorp社のVagrantやDocker社のDocker Composeに感覚的には近いものだと捉えていただけると、想像しやすいと思います。技術的な部分の詳細は、過去にテックブログで説明しているので、ぜひそちらもご覧ください！）
IaaS基盤のテスト環境構築の活用事例
中井：Nested ESXiという技術を使って、クリーンなテスト環境を迅速に用意できるような仕組みになっているんですね！では、その仕組みがどのように活用されているのか教えてください。
伊藤：VMware製品を利用するソフトウェアのテストで活用していて、例えば、ニフクラを支える裏側のアプリケーションをVMwareの仮想基盤上にデプロイする際のテストに使っています。他にも、VMwareの仮想基盤上でのKubernetesクラスター構築の自動化でも利用しています。後は、山口さんの担当業務の中でも使っていたりしますね。
山口：そうですね。自分の担当するマイグレーション業務において、必要に応じて毎回物理環境でマイグレーションの検証を実施するのはコストが高いです。なので、クリーンなテスト環境を用意し、その環境で事前に複数回マイグレーションを検証した後に、物理基盤でマイグレーションを実行して問題ないか確認を行っています。後は、基盤をマイグレーションし、バージョンなどが変わることで基盤に依存するアプリケーションも手を加えないといけないんですが、そのための開発環境として利用もしています。
山口：先ほどの話とは異なる活用方法だと、VMwareが提供しているVMware製品を試す環境のハンズオンラボのように、ニフクラの基盤に特化したハンズオンラボという形で利用しています。それを新しく仮想ネットワークチームに配属されてくる新人のオンボーディングに活用して、ニフクラの基盤のリファレンスデザインを教えたり、新人たちが自由に壊していい環境として使ったりしています。
仕組みを作った背景について
中井：Nested ESXiを活用して、テスト環境を構築するようになった背景を教えてください。
伊藤：ESXiと呼ばれるようなコンポーネントは、基本的に物理サーバーに直接インストールして使うのが一般的です。なので、環境を用意するごとに物理サーバーも用意する必要があるため、気軽に環境を用意するということが難しくなるかもしれません。加えて、環境を用意する度にVMware製品のインストールが必要となり、作業が大変になるので、取り組み始めたのが背景として挙げられます。
伊藤：また、Nested ESXiの仕組みを使うこと自体はもっと前から取り組んでいました。しかし、ネットワークやストレージ周りを共用にしてしまうと、環境間で互いに影響が出ないように環境ごとの設定が必要になり、単に環境をコピーすることができません。つまり、単に環境をコピーして消して…を繰り返せるような状態まで環境を分離できていなかったので、当時は気軽にテスト・開発用の環境を用意することはできない状態でした。その課題に対するアプローチが、Nested ESXiを活用したクリーンなテスト環境を迅速に用意する仕組み作りになります。
中井：なるほど。この取り組みの結果が高度なIaaS基盤運用に繋がっているんですね！
伊藤：テスト環境の構築・運用に限った話ではないですが、私はFJCTで働く上で、開発・テスト・デプロイといったDevOpsのサイクルをより高速にできるようにすることをテーマに取り組んでいます。その中で開発やテストをするための準備に時間がかかるとどうしてもサイクルが鈍化してしまうので、そこを解決したいという点を大きな問題意識として持っていました。
中井：そうすると、元々伊藤さんは、IaaS基盤運用にDevOpsの考え方を導入することを意識しており、その取り組みの1つとして、今回取り上げているIaaS基盤のテスト環境構築の話があるんですね！
副次的な成果について
中井：続いて、テスト環境の構築について、当初の目的とは違うところで、活用されるようになった事例はありますか？
伊藤：当初はテストコードの実行環境を用意するところにフォーカスして取り組んでいました。ただ、アプリケーションを開発する中では、その前段階として実際にVMware製品のAPIを叩いてどんな動きをするのか試したり、開発中のコードを試しに実行して確認してみたりするケースがあると思います。自動テストの実行に限らず、そういった実際に手を動かしている場面でも活用されるようになっています。
伊藤：後は、さっき山口くんが話していた新人のオンボーディングとして、トレーニングに使ってもらう環境を用意することにも利用しているのも当てはまると思います。
中井：色々な用途があるんですね・・・そういえば、採用活動でもインターンシップで学生に取り組んでもらうための環境を用意するのにも活用させていただきましたね。
山口：実は、テスト環境構築の仕組みは、内製で行っている新人研修でもかなり前から用いられていて、この仕組みがあるおかげでネットワークのトラブルシューティング演習をFJCTの新人たちに提供することができています。
伊藤：それもあったね。研修では、わざとネットワークの構成をミスっているような環境を用意して、それを複製することで、新人を5,6チームとかに分けてそれぞれに環境を用意してネットワークのトラブルシューティング演習に取り組んでもらうことができているんですよね。
現在、課題として認識していることについて
中井：テスト用の環境を用意するためだけでなく、開発業務や採用・人材育成などFJCT内で広く活用されている一方で、課題に感じられていることはあるのでしょうか？
伊藤：広く使われるようになったんですが、そうなるとより便利に使いたくなってしまい、作成されるテスト環境に色々なコンポーネントを含めたいという要望が社内で出てくるようになりました。テストしたいソフトウェアが直接的または間接的に依存するコンポーネントを欲しがったり、究極的には「全部入り」と言えるようなものが欲しいという内容です。
伊藤：Nested ESXiを利用したテスト環境にあらかじめ依存コンポーネントを用意しておくことは可能ですし、実際にそのようにしている部分もあるんですが、テスト環境に含めるコンポーネントが増えるほどCPU・メモリー・ストレージのリソース消費も増えてしまうので、どうしても限界がある点に課題を感じています。
伊藤：ただ、そこに関してはテスト環境を構築する仕組みで頑張るというよりは、限られたコンポーネントで回せるようにテストを作る部分を工夫していくことで解決するのが良いのではと考えています。Nested ESXiを活用したテスト環境で賄う範囲は限定して、全体的には依存コンポーネントが無くても動作するようにテスト自体を工夫していくことが大事だと思ってます。
伊藤：ただ、この辺は実体験を強く伴っている山口くんの意見も聞いてみたいですね。
山口：うーん、自分はテスト環境の構築・運用面で特に困ったことは無いですね。なので、別の視点から課題について意見すると、このテスト環境を用意するためには、当然理解しておかないといけない技術があります。例えば、VMware製品の理解、インフラの一般的な知識、DevOpsのセオリーやAnsible、GitLab等の利用ツールの知識も必要で・・・つまり、色んな要素技術を知っている必要があります。そのメンバーが社内からどんどん増えてくれればいいんですが、この記事を読んで興味を持ってくれる方がFJCTの一員に加わって一緒に仕事ができるのも嬉しいですね。
中井：ありがとうございます。ぜひ今回の記事を読んで興味を持っていただいた方はぜひ連絡していてだけると嬉しいですね。（ということで、本記事の末尾にキャリア採用の求人ページを載せておきますので、よければご確認くださいｗ）
中井：（話を戻して）つまり、山口さんはIaaS基盤のテスト環境を簡単に活用できるようにする点に課題意識があり、人材育成やスキルを持った人材の獲得で解決していきたいと考えているということでしょうか？
山口：そうですね。なぜなら、この仕組みは仮想基盤よりも上の要素が全て詰め込まれて成り立っているので、上手く運用していくのであれば、その方がよいかなと思っていますが、伊藤さんはその辺りどう思いますか？
伊藤：属人化っぽい話はとても耳が痛いですね(笑) 必要となる知識をそれぞれ個別に理解している人たちで分担して運用していけるような状態にはなっていないので、山口くんの言った通り、色んな要素技術を総合的に理解している人がいてほしいとは思いますね。
今後への取り組み
中井：最後に、今後実現したいことを教えてください！
伊藤：背景でもお伝えした通り、根本的に実現したいことはIaaS基盤運用に取り入れているDevOpsのサイクルを高速化していくことなので、あくまでもこの仕組みはその手段の1つとしてとらえています。なので、便利に使えるようにしていきたいとは思いますが、あまり固執するつもりはないです。ここまで話をしておいてあれですが(笑)
伊藤：なので、この仕組みの有無にかかわらずインフラ関連においてもテストの自動化を推進できればいいなという思いと、後はさっき山口くんの話に関連しますがNested ESXiを活用したテスト環境をより簡単に活用できるようにしたい気持ちがあります。
中井：山口さんはどうですか？
山口：この仕組みは仮想ネットワークチーム発祥で、現在他の部署でも活用してもらってはいますが、まだ社内に浸透しきっているという状況ではないです。仮想ネットワークチームの身からすると、この仕組みがないと開発できないと思っているのですが、ニフクラの開発・運用に携わっている全体でみるとまだまだ浸透する余地はあると思っていて、この仕組みをもっと便利に使ってもらってニフクラのサービス品質向上に貢献できるようになってほしいですね。
伊藤：そうですね。まだまだ、この仕組みを使って既存の業務を改善できる点が多くあると思うので、その辺りに伸びしろがあると思います。
ここまで読んでくれた方へ！
伊藤：インフラやプロプライエタリ製品に依存したソフトウェアをテスト・開発する話ってどうしても難しい部分はあると思うのですが、工夫次第で改善できる部分はあると思っています。そういったテストは難しいからやらない・手を動かしてできる範囲で確認するという選択ではなく、技術的なところを駆使することで上手く扱えるようにすることが大事だと伝わってくれると嬉しいです。
山口：トラブルが起きづらいインフラを提供するって考えたときに、構えているところに問題は来なくて、構えていないところに問題が来るものなので、FJCTではこの仕組みを使って構えているポイントを増やしていくことで、ニフクラの品質向上に取り組んでいるっているのを知ってほしいです。
おわりに
今回、連載2回目のインタビューとして、FJCTのIaaS基盤のテスト環境を構築する仕組みと事例について、業務に携わっているお二人に聞くことができました。
今後も様々なトピックでニフクラのサービス品質を維持向上するためにどのような取り組みが実施されているかをエンジニアさんの現場視点でお届けしていきますのでブログのチェックを是非よろしくお願いいたします！
また、明日は富士通クラウドテクノロジーズAdvent Calendar 2022の25日目（最終日）でもあります！最後はFJCT エンジニアタスクフォース フォース長 @ConHumi さんによる「FJCT エンジニアタスクフォース 2022 レポート」です。お楽しみに～