性質の異なるサービスを複数持つからこそ選んだ「マイクロサービス」　相互に与える影響の少なさが、開発を加速してくれた

小田川氏の自己紹介

小田川拓利氏：ご紹介にあずかりました、taqqnこと小田川拓利です。私からは「開発を加速するマイクロサービスデプロイ: EKS+Flux+Hasura」といったテーマで発表を行います。

まず自己紹介からします。小田川拓利と申します。Twitter（現X）のIDが気に入らなかったので、今変えたところですね（笑）。ちょうどいい感じにIDが取れたので変えました。

所属は燈株式会社のAI SaaS事業部で、VPoEです。最近は主にTypeScriptを書いていて、趣味はマーダーミステリーです。実はアプリ開発をしていました。

燈株式会社について

まず、燈株式会社について簡単に説明させてもらえたらと思います。燈株式会社ですが、2021年2月に創業してから、今で2年半の会社になっています。東京大学発のスタートアップで、本社は春日のビルです。現在、従業員数がちょうど100名を超えて、100名ほどのメンバーで活動しています。

私たちは最先端技術で建設DXに挑むということを行っています。

私たちの事業内容ですが、三重の円の構造になっています。まず、中心のアルゴリズム研究開発ですが、そこでは各種AIのアルゴリズムを開発していく、その技術力を高めていく。そしてですね、それをAIモジュールとして大きな会社さんと共同で開発して、実際に現場に持っていく。これがDXソリューション。

そして、そこで培ったAIのモジュールをより多くの会社さんに提供するのがAI SaaS です。今までは大きな会社さんでないとAIモジュールを共に開発することは難しかったんですが、そういったところで培った技術を活用して、AI SaaSとして、よりたくさんの企業さんに使ってもらう。

例えば「Microsoft Word」「Microsoft Excel」であれば、どのような会社さんでも使っていると思うんですが、（それと同じように）建設業界の会社だったらどこも使っているようなサービスを作っていこうというところで、AI SaaSを提供しようと思っています。

先ほど建設業界に特化しているという話をしましたが、ほかのAIスタートアップさんだと、どちらかというと画像が得意な会社さん、自然言語が得意な会社さんというように、技術特化でなにかを進めている会社さんがけっこう多くある、と。

弊社は建設業界に特化することで、建設業界の深い深い業界の悩みとか、業界独自の構造を知ることで、そこに対する知見をより得て、より本当の深い深い課題を解決していく。そういった事業を行っているような会社です。

資金的にも非常に良くて、AI SaaS事業部全体として、今まで無調達でやってきています。100人の規模にもかかわらずここまでうまくやっていけているというのは、日本でもなかなか少ないのではないかなと思っています。

また、AIのスタートアップなので、深層学習用の社内のKubernetesのクラスタがあります。これがおもしろくて。

（スライドを示して）多くの大学の研究室さんでも行われているんですが、計算機1つにSSHで接続して、従業員数名を割り当てて共同で使うみたいな、左半分のケースがけっこう多いんですが、それだとやはり効率が悪い。ユーザーの3人がまったく違うタイミングで稼働しているとは限らないし、やはりちょっとコミュニケーションコストがかかってしまう。

弊社ではそこをなんとかしたいと思い、独自のKubernetesのクラスタを立てています。空いたリソースから確保、要するに、ユーザーが必要な時にKubernetesのジョブを投げることで、空いたリソースから空いた順に実行されていくので、非常にリソースの効率が良く、スムーズに開発もできています。

そういったことをやっている会社ですが、SaaSのほうは建設業向けの請求書処理のDXサービスを行っています。「Digital Billder」という名前なんですが、6月にサービスリリースから1年を迎えて、導入企業数が100社、今は120社くらいを超えていて、導入企業数を非常に伸ばしています。

（スライドを示して）、見せられる会社だけでもこのぐらいなんですが、具体的にはこのように伸びている。

PMFからグロースに向かっていく途上なのが請求書のサービスです。請求書である程度うまくいっているので、そこから発注、経費精算とか別のプロダクトを伸ばしていこうと考えています。

本セッションの発表テーマ

発注と経費精算を最初のPMFからうまく、できるだけ早く進めなければいけないといったところで、どういった技術的な工夫があったり、どういうふうにできるだけ早くPMFしてグロースさせていくのか。そういったところを今回の発表のテーマとしたいと思います。

その説明をするために、（スライドに）「Microservices」「Hasura」「AWS」と書いてあるんですが、これらについて順々に説明できたらと思います。

このような順番で進めます。まず、なぜマイクロサービスを選定したのか、「Why Microservices?」。で、次に「Why Hasura?」、なぜHasuraを導入するのか。そして「How to deploy them with AWS?」、AWSを使ってそれらをどういうふうにデプロイしていく、リリースしていくのかといったところを順々に説明します。

「モノリシックなアーキテクチャ」と「マイクロサービス・アーキテクチャ」の違い

最初のところから説明します。みなさん知っているかもしれませんが、基本に立ち返って、そもそもモノリシックなアーキテクチャとマイクロサービスのアーキテクチャは、どういった違いがあったかを振り返っていきます。

まず、モノリシックなアーキテクチャですね。こっち側はかなりシンプルな構造なので、理解しやすいかなと思います。クライアントさんがいて、クライアントさんからサーバーにアクセスして、そのサーバーが1つのデータベースとかにアクセスして、そこでほぼほぼ完結するみたいな。そういったところがモノリシックなサービスです。

一方でマイクロサービスのほうは、1つの大きなサーバーではなく複数のサーバーに分かれていて、サーバー間が通信して、それらがそれぞれデータベースと接続するようなかたち。モノリシックに比べれば、ずっと複雑なアーキテクチャになっていると思います。

もちろん複雑さがあるからデメリットもあるし、それでもマイクロサービスがある程度一定の理論として定着しつつあるところだと思うので、メリットももちろんあります。

メリットは大きく分けて3つあります。1つ目が、開発期間を短縮できるところですね。マイクロサービスとしてサーバーが分かれていることによって、そもそもそのコードの大きさが小さく抑えられる。

サーバーにデプロイするコードが一つひとつ小さくなるので、ほかのサーバーへの影響を考えずに、どんどんコードを追加していける。そういう意味で開発の期間をどんどん短縮できるし、チームとしても分けていけます。

小さな機能に分割するので、コードを再利用することも可能である。マイクロサービスを作る過程でけっこうモジュールを作れたりするので、そういったこともできる。

直近で、発注、経費精算を発表しましたが、柔軟性・拡張性が高いため、その後の事業拡大する上でも、「ちょっと事業がうまくマーケットフィットしていないから違うところをやったほうがいいな」といった場合にも、無くしたり増やしたりが非常に柔軟にできるので、注目されています。

一方、デメリットもあります。インフラの運用コストです。要するにアーキテクチャ自体はけっこう複雑になり、接続する場所がたくさん増えるので、どこで障害が起こるかとか、どういうふうに全部把握するかとかの難しさがあります。

それから、データベースが分かれるので、データの一貫性の担保は当然難しくなります。1回そのサービスを切ってしまうと、サービスの境界を後から変更することがやはりコストになるところがどうしてもあります。そういう意味では柔軟性が失われることもあると思います。

「マイクロサービス・アーキテクチャ」を選んだ理由

そういったメリット、デメリットがある中で、弊社の開発ではマイクロサービスを選択しました。なぜなら、経費精算と発注・請求書では、前提としてかなりサービスの性質が異なるからです。

経費精算は企業内でのやり取りになるんですね。経費精算はある従業員さんが経費を提出して、その提出された経費に対して承認作業をするみたいな。要するに、企業内の従業員と上長であったり経理担当者の中でやり取りを行うようなものになっています。

一方で発注と請求書は企業間でのやり取りになっていく。要するに、発注・請求書だと発注元の会社さんがいて、発注元から発注先、協力会社さんに注文を送る。そこから「注文書が承認されました」「OKです」みたいなものが返ってくる。あるいは、請求書として協力会社さんから発注元に請求が行くみたいな、そういった企業間でのやり取りになるので、そもそもかなり性質が違います。

そして、データが疎結合になったり、ビジネスロジックもかなり異なる部分が多いところがあって、サービスの境界としても明確になるし、非常にやりやすいかなといったところで導入しました。

「マイクロサービスアーキテクチャ」を選んで感じたメリット

これまで開発してきた実際の感触に対して、先ほどのメリットとデメリットそれぞれに対してコメントします。

まず開発期間を短縮できるというところは、やはりそうでした。経費精算と発注・請求書で完全にコードが分かれている、分離されている状態になっているので、既存の機能に与える影響が小さい。

もうある程度既存で成功している請求書と、どんどん発注、経費精算の開発を進めていかなきゃいけない中で、請求書の影響をさほど考えずに新しい機能を追加でき、開発が加速できたなという実感があります。

それから、小さな機能に分割し、コードを再利用可能というところで、ちょうど最終的に分けるように進めていたので、共通のロジックはやはり多少出てくる。

共通のロジックのパッケージ化のリファクタがちょうどうまいこと促進されて、依存関係とかそういったところの把握が容易にできるようになりました。

今までモノリシックに、ある意味パッケージに分けずに管理していたんですがそれを変更しました。TypeScriptのMonorepoを用いているんですが、細かいnpmのパッケージみたいにして、それぞれお互いに参照するようにして、それでうまいことコード管理できるようになったので、非常に見通しが良くなったなと思っています。

柔軟性・拡張性の面でも、サービスを立ち上げるコストを下げられる。これから先の話ではありますが、発注、経費精算を増やすということは簡単にできましたし、これから新しいサービスを付ける際も、同様のやり方でやればいいだろうということが予想できます。

「マイクロサービスアーキテクチャ」を選んで感じたデメリット

これからマイクロサービス導入のデメリットをコメントしていきます。インフラの整備コストに関しては上がることはわかっていたので、IaCとかAWSのフルマネージドサービスでカバーしたいと思っています。

あと、データの一貫性の担保が難しくなるところは、サービスの性質上、厳密な一貫性は必ずしも必要ではないサービスになっていて。これから先、もしかしたら厳密に運用していく必要が出てくるかもしれないんですが、いったんは不要となっています。経費精算、発注で多少同期しなきゃいけないデータがあるにはあるんですが、そこまでコストではないかなと考えています。

実際、多少の連携はしていて、マイクロサービス間のgRPC通信で賄っているんですが、それぐらいをやれば問題ないかなといったところです。

サービスの境界を後から変更することが難しい点も、先ほどコメントしましたが、経費精算と発注・請求書の境界が明確というところで、さほど問題視せずにやったところです。

（スライドを示して）実際こういった構成でやっています。手前にHasuraを設けて、それぞれ発注・請求書のマイクロサービスと経費精算のマイクロサービスがある。発注と請求書は一緒ですが、こういうイメージでやっています。

（次回に続く）