はじめに
こんにちは！FJCTエンジニアタスクフォース（ETF）の中井です。「FJCTQualityUp」連載3本目の本稿は、「マイクロサービス開発への取り組み」のテーマでインタビューした記事になります。
前回の「FJCTQualityUp」の記事は「IaaS基盤のテスト環境を構築する仕組みと事例について」です。気になる方はそちらもご覧ください！
FJCTQualityUpについて
こちらの連載記事では「FJCTQualityUp」と題して、富士通クラウドテクノロジーズ株式会社（以降FJCT）のエンジニアに「FJCTのサービス品質向上のために何をしているのか」をインタビューしていきます。
エンジニアの生の声が、これからエンジニアを目指す方、今まさに課題解決に取り組んでいる同業者、その他大勢の方にとって参考になる、明日からの実践のきっかけになることを願っています。
第3回：マイクロサービス開発への取り組みについて
自己紹介
中井：今回は、「マイクロサービス開発への取り組み」をテーマに、ニフクラのコンピューティングサービス開発を担当するIaaS API開発チーム所属の4人にインタビューをさせていただければと思います。まずは、自己紹介をお願いします！
浅見：じゃあ、五十音順に私から。プラットフォームサービス部、IaaS API開発チームの入社5年目の浅見です。IaaS一筋で、プライベートブリッジのリリースや、Liveマイグレーションの開発等にも携わっていました。
市川：入社1年目の市川です。2022年の10月に今のチームに配属されました。ドメイン駆動設計や、マイクロサービス開発に携われる点に惹かれて、配属を希望しました。まだ1年目ではありますが、自分のできる範囲を広げて、チームの仕事を回せるように日々精進しています。
小川：チームでスクラムマスターを担当している入社4年目の小川です。自分も浅見さんと同じくプライベートブリッジの開発等に携わっていました。今後はIaaSチームとして新規のマイクロサービス開発に注力しようということで、若手中心で今のチームを発足し、開発に取り組んでいます。
高田：入社3年目の高田です。私はちょうど今のチームが発足した年に入社したので、振り返ると自分自身学びながらチームの発展についてきたのかなと思います。。
マイクロサービスについて
中井：初歩的なところからなのですが、「マイクロサービス」が何なのか？教えてほしいです！
浅見：ソフトウェア開発における技法の1つです。例えばニフクラで言うならサーバーやネットワーク機能の改修をしたい要件があったときに、サーバー関連のとあるコードを少し変えたらネットワーク機能に影響が出てしまった…みたいなことが起こりうると思います。そういう１ヶ所を修正して影響範囲が大きくなってしまうのをなるべく抑えるために、改修範囲そのものを小さくする開発技法がマイクロサービスになります。
小川：私たちが提供するニフクラには、コンピューティングというサービスが表向きにはあります。サーバーが作成できたり、お客さまの課金のデータを扱ったり、操作ログを提供したり…といろいろな機能があります。それらをマイクロじゃないサービスとして作ると、コンピューティングというただ一つのサービスとして作ることになります。
小川：複数チームでたった1つのサービスを同時に開発すると、実装が衝突したり開発ごとにリリース時期が異なることによりモジュールの作成が複雑になったりします。その際に他のチームとやり取りして都度問題を解消する必要があったりします。
高田：また機能の裏側のインフラコンポーネントの仕様が変わった場合に、それをマイクロなサービス内での修正にとどめるようなことも実現できるようになります。
浅見：それらの課題を解消するために私たちのチームではVMwareのコンポーネントを扱う部分だけ、マイクロに取り出したサービスを抱えています。私たちのサービスは課金情報やログの情報を扱っていないので、その辺りの改修をしたい場合に我々へ連絡をしなくても完全に別軸で開発が進められます。
浅見：我々としては、スピード感を持って開発していくために少しずつ役割を細かくしていくというような考えから、マイクロサービスに取り組みだしたと思っています。
FJCTでマイクロサービスに取り組みだした背景
中井：マイクロサービスを取り組み始めたきっかけってありますか？
浅見：正確には覚えていないんですが…きっかけの1つは2019年にリリースしたプライベートブリッジの立ち上げ時ですかね。当時のニフクラでは、コンピューティングという１つの大きなサービス群があったのですが、そこにプライベートブリッジというある程度独立したサービスを加えたいとなったときに、コンピューティングの中に入れるのは難しいよねという話があがりました。
浅見：なので、プライベートブリッジはコンピューティングとは少し別の方向でやってみましょうか？という経緯で、それらを分けて開発してみようというのが、私たちのチームとしてのマイクロサービスの入り口だと思います。その前にもいくつか取り組んではいましたけどね。
マイクロサービス化を推進する理由は？
中井：マイクロサービス開発に取り組む理由は？
小川：今まで社内では元々別言語でコンピューティングを開発していました。しかしGoやRustなどのコンテナ技術とも親和性が高い言語を使いたいと考えている人もいるかと思います。新しい言語を使おうとなると全部を別の言語に置き換えるという話になると思いますが、数十万行はあるようなコードをいきなりすべて置き換えることはできません。そんな中、新規のサービス開発の話があがり、その際に機能の一部をマイクロサービスとして開発しようという話がでました。
小川：マイクロサービスのサービス間はHTTPで通信するため、各々が何言語であってもサービスとしては成り立たせることができます。つまり、コンピューティングと新しいマイクロサービスが同じ言語で開発される必要はなくなります。私たちとしては、GoやKubernetes等、新しく挑戦をしたい技術分野で開発をやっていこうという思いがあって、マイクロサービスとして作り始めたのが根本にあると思っています。
現在、課題として認識していることについて
中井：マイクロサービス開発に取り組むうえで、課題に感じていることはありますか？
小川：そうですね…市川君はチームに配属されてもうすぐ半年ですけど、マイクロサービスやKubernetesなどを触ってみて難しいと感じる部分はありますか？
市川：そうですね。自分は最初、VMに関連するサービスとネットワークに関連するサービスが、どういう風に連携をとっているか、つまり、マイクロに切り取ったサービス同士が通信し関連していることを理解することが難しかった印象ですね。
小川：たしかに市川君の話すとおりで、機能というのは何かしら入力があって出力があるものなんですが、マイクロに分けたことで1つの機能を実現するためのサービスが増えてしまいます。入力から出力までに登場するサービスが多くなることにより、全体把握が難しくなるかと思います。
中井：機能の全体把握を難しく感じないようにするために、取り組んでいることってありますか？市川君のトレーナーの高田君はどうやってそこを教えていますとかあれば！
高田：技術的な話ではありませんが、まずは各サービスの役割を知ってもらったり、都度サービスの関係を図などで共有したりして一緒に考えています。あとは、チーム内専用のStack Overflow（Q&Aページ）みたいなものを作っています。わからないことがあった際に書いておくと誰かが答えてくれる掲示板のようなもので、その瞬間にも疑問が解消しますし、後で同じような疑問を持った人が見返すこともできます。
中井：なるほど。FAQをログとして残すことで辞書としても活用できるようにしているんですね。
マイクロに切り分けたサービスの管理について
衞藤：品質の観点から、マイクロサービス化することで管理するサービスは増えていくイメージですがどのように対応しているのか教えてください。
小川：まずサービス全体のテストは、IaaSのどんな機能をリリースする場合でも、マイクロサービスかどうかは関係なく、サービス全体として検証をしています。あとはE2E（End to End）テストを定期的にサービス全体に流していて、お客さまに提供しているAPIへリクエストするテストを流して動作確認をしています。結合の部分に関してはそんな感じです。
小川：マイクロサービス内に関しては、例えばサーバー機能のサーバーとしての振る舞いのテストをしたいのに、テストに関連しない課金まわりのロジックのためのテスト準備も必要でした。しかし、マイクロに切り分けて機能が閉じたことによってサーバー部分に特化したテストが可能になり、細かいテストケースを簡単に増やすことができています。
小川：ただ、結合テストの一番上であるE2Eテストに関しては正直、まだ課題があると思っています。マイクロサービスではサービスごとに開発スピードが異なります。そのため全部出来上がった段階でないとE2Eなテストができません。しかし、全部でき上がったときに初めてわかるような問題もあります。それを見つけるのに時間がかかることもある点はまだまだ課題かなと思っています。
小川：FJCTでは仕様に関する認識を合わせるため、マイクロサービス間はAPI仕様書(OAS)としてまとめているチームが多いです。
浅見：実際の開発ではこのAPI仕様書を元にモックやSDKを生成し、開発を進めます。こうした取り組みは複数チーム間をまたぐ開発でも並行して進めやすくなっています。
今後の取り組み
中井：今後実現したいことを教えてください！
小川：従来のコンピューティングが持っているサーバーのVMwareに関する役割を私たちのサービスに分離させることが目標です。欲を言えば、チームメンバー増やしたいとか、細々したものもありますが。
浅見：コンピューティング全体としては、ちょっと古くなっているコードベースを新しいものに変えるというのも大きなミッションかと思っています。なので、今後も分野を広げるよりは、最初の目的を完遂できるように、開発サイクルとスピードを上げていきたいと思っています。
小川：立ち上げ時期からいたメンバーの私としては、浅見さんや市川君、そしてこれから加わってくれる方にもチームのことを理解して欲しいと思っています。なので、わかりやすい設計の検討やそのためのエンハンスをしていくつもりですし、ドキュメントが足りないのであれば作るつもりもあります。
高田：そうですね。設計を見ることにより仕様が一目でわかるようにすることは意識していきたいですね！
小川：あとはチームの開発者以外の方にも、もっと興味を持ってほしいなっと思って今回のインタビューを受けたところもあるので、社内外いろいろな方に興味持ってほしいなあと思ってます！
小川：ちなみに市川君は、チームに加わって半年経ちましたけど楽しいと感じてくれていますかね…？
市川：楽しいですよ！自分は設計とかに興味、関心を惹かれていて、タスクをこなす中でできるようになったことや、イレギュラーな対応があった際にこれも考えなきゃなみたいなことがあるのがすごく楽しいって思ってます！
ここまで読んでくれた方へ！
市川：そうですね。インタビュー内で少し触れた開発スピードを上げるっていう点で、マイクロサービスをやっているだけでなく、アジャイル開発にも取り組んでいるので、興味ある人はぜひ来てほしいですね。
小川：あと、私たちのチームはVMwareの仮想化部分をお客さまのクラウドとして提供するうえで抽象化するサービスを開発しているのですが、FJCTに来る方って、クラウドを使うより作る側を日本でやりたいんだって人も多いかと思います。そのような方からすると私たちのチームはやりがいを感じてもらえるかなと思っています。
おわりに
今回、連載3回目のインタビューとしてFJCTのマイクロサービス開発への取り組みについて、IaaS API開発チームのみなさんに聞くことができました。
今後も様々なトピックでニフクラのサービス品質を維持向上するための取り組みをエンジニアの現場視点でお届けしていきますので、ブログのチェックを是非よろしくお願いいたします！