こんにちは、ソフトウェアエンジニアリングチームでチームリーダー兼テックリードを務めております中島です。
2023年11月にmyTOKYOGASの内製化を実現してから、1年以上が経ちました。
myTOKYOGASの内製化を実現してからは、お客さまにより良いサービスを提供するため、myTOKYOGASの改善を日々進めるとともに、新たな取り組みにも挑戦してきました。 今回は取り組みの一つである「myTOKYOGASのマイクロサービス化」についてお話ししたいと思います。
マイクロサービス化に取り組む背景
現在のmyTOKYOGAS
現在、myTOKYOGASではフロントエンドとBFFが内製化されており、バックエンドは東京ガスiネットに開発・運用をお願いしています。
バックエンドに関しては、レガシーな基幹システムとのプロキシとしての役割を担っている点や、東京ガス特有のドメイン知識が多く詰め込まれている点を考慮し、内製化の初期段階ではその内製化を見送る判断をしました。しかし、フロントエンドやBFF（Backend for Frontend）の内製化を進める中で、新たな課題が明らかになりました。 具体的には、「会員」、「料金」、「使用量」といった東京ガスにおける重要なドメインに関連するデータを扱う際に、バックエンドAPIの呼び出し元で複数のAPIを統合的に呼び出し、必要に応じてデータを整形して利用する必要が生じていました。このアプローチを各システムや利用箇所で個別に実装することは非効率であるばかりか、システム全体の保守性や一貫性の観点からも望ましいとは言えませんでした。
そのため、現在は複数のバックエンドAPIから取得したデータを統合・整形するドメイン層をBFF内部に構築し、その層を経由してデータの取得や登録の処理を行っています。
myTOKYOGASの次へ
現在我々はmyTOKYOGASの運用・改善を中心に取り組んでいますが、今後はさまざまなサービスの開発をしていくことを検討しています。また、東京ガスでは我々内製開発チームだけでなく、さまざまなところでデジタルを活用したサービス提供が検討されています。 myTOKYOGASで扱っているドメインは、「料金」、「使用量」、「ポイント」など、今後エネルギー会社としてサービス開発をしていく上でも利用できそうなものが多くあります。 myTOKYOGASを開発する中で、それらのドメインに関する知識を開発チームは獲得し、ソースコードへと詰め込んできました。これらのノウハウを再利用することができれば、新たなサービスの検討や開発を加速させることができます。 ですが、それらのノウハウが詰まった「ドメイン層」は現在myTOKYOGASのBFF内部に実装されており、myTOKYOGASに関連したサービス以外は利用できないようになっています。これらのノウハウを外部に利用してもらうには、BFFから切り出す必要がありました。 また、myTOKYOGASチーム内でもBFFに「ドメイン層」が実装されたことでBFFがファットになっており、チームやプロダクトが大きくなるに連れて保守性の面でも問題が出てきました。 myTOKYOGASチーム内部でのアーキテクチャの改善、そして、今後を見据えたときにBFFに実装された「ドメイン層」を切り出し、myTOKYOGASのみならず、「BtoCプロダクト開発を加速させ、事業に貢献する」ということ目的として、ドメイン層を切り出す取り組みを始めました。
マイクロサービス化の戦略と取り組み
myTOKYOGASの開発や運用を通じて、お客さまによく利用されるドメインが見えてくるようになりました。それらのドメインについては、データをキャッシュして高速化を図ったり、データベースなども含めて何らかの最適化や改修を行う必要があります。それらが密になっていると、他のドメインへの影響を意識して実装をせねばならないため、ドメイン毎にアーキテクチャを分離したいと考えました。これらを考慮した時に、疎結合でそれぞれのサービスが稼働するマイクロサービスは適切なアーキテクチャだと考えました。
一方で、マイクロサービスを採用することにおけるデメリットについても考慮が必要だと考えました。 マイクロサービスのメリットとしては、それぞれのサービスで技術を自由に採用できたり、疎結合に実装することで各マイクロサービスのチームが独立して開発していくことができるという点などが上げられると思います。ですが、個々のマイクロサービスで異なる技術選定を行ってしまったり、マイクロサービスの数に合わせてリポジトリやチームを増やしてしまうことは、開発者の認知負荷の問題やコミュニケーションの負荷の問題が高まるというデメリットの面もあると考えました。
それらの観点とmyTOKYOGASの開発を通じて得られた知見から当面はワンチームで管理が必要なマイクロサービスの規模に留まるであろうと考え、無理に完全な疎結合を目指さず、マイクロサービスのアーキテクチャとしての恩恵は受けつつデメリットの面を緩和できるモノレポでのマイクロサービス化を進め、ドメイン層を徐々に切り出していく方針としました。
モノレポ化の戦略
前述の通り、当面はワンチームでマイクロサービスの開発を進めていく方針としています。その時点でリポジトリを分けるメリットは薄いと考え、モノレポで開発する方針としました。 加えて、モノレポの中でドメインごとに技術スタックを変えてしまうと、学習コストや管理コストが増えてしまい、ワンチームかつモノレポのメリットが薄れてしまうと考えました。我々の目的は、マイクロサービスにして技術スタックに自由度を持たせることではなく、個別のドメインへの改修やデプロイを柔軟に行えるようにして、事業に追随できるシステムと開発体制を獲得することです。それらを最優先として、モノレポかつシングルモジュールでマイクロサービス化を進めています。また、フレームワークなどもマイクロサービス全体で統一するようにしました。そうすることで、パッケージのアップデートなどの対応コストを下げることができたり、エンジニアの認知負荷も下げることができると考えました。その分、完全分離のマイクロサービスに比べると、密結合になり考慮が必要な部分も出てきますが、テストコードをしっかり書いて担保することをチームとして目指しています。
マイクロサービスのリリースと今後
東京ガスのシステムは非常に巨大なモノリスでありマイクロサービス化は一気に行えるものではなく、分離すべきドメインを慎重に見極めながら段階的なマイクロサービス化を進めています。 そのため現在もマイクロサービス化を進めている最中ですが、すでにマイクロサービスが一部稼働しており、現在のところ大きな問題なく安定稼働しています。また、直近リリースしたマイクロサービスではTiDBなどの少し尖ったデータベースの採用もしています。 モノレポかつシングルモジュールの構成についても我々のような少数精鋭の内製部隊においては、現時点では有効に機能していると感じています。あくまで現時点であり、開発を続けていく中で適宜見直しを図っていきたいと考えています。
マイクロサービスの実行基盤については、SREチームによって構築されていますので、ご興味ある方はぜひご覧ください。
まとめ
マイクロサービス化についてはドメイン境界の見極めもかなり慎重に行う必要があり、見極めを誤れば逆に事業を阻害してしまうシステムになりかねません。 そのため、開発チームとしてもmyTOKYOGASの開発を通じて蓄えてきたドメイン知識を活用したり、既存システムに詳しい東京ガスiネットからも開発チームに参画していただき開発を進めています。
マイクロサービス化は、まだまだ始まったばかりの取り組みで、進めていく中で現在の構成がその時々の状況にマッチしないことも出てくると考えています。非常に巨大で運用負荷が高いドメインを扱うマイクロサービスが出てきた時には、そのマイクロサービスのリポジトリやチームのみ分離するなども検討が必要になるかもしれません。今後ぶつかるであろう問題については、適宜検討していきたいと考えているものの、「マイクロサービス化が目的ではなく、事業に貢献することが目的」ということを忘れず、どんな形であれ事業を支えるシステムを構築していく！という気持ちを持って開発に取り組みたいと思います。
当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！
アプリケーションエンジニアはこちらから！ www.wantedly.com
モバイルアプリエンジニアはこちらから！ www.wantedly.com
SRE はこちらから！ www.wantedly.com
