2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
小田川拓利氏:ご紹介にあずかりました、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を設けて、それぞれ発注・請求書のマイクロサービスと経費精算のマイクロサービスがある。発注と請求書は一緒ですが、こういうイメージでやっています。
(次回に続く)
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには