はじめに
みなさん、はじめまして。
MI-6株式会社でエンジニアリングマネージャーをしています @_oliverSI です。MI-6株式会社では AI を用いて素材メーカーの研究開発を効率化する SaaS プロダクト「miHub」を開発しています。
初期のプロトタイプは2019年8月から開発を開始し、その後ユーザー数の増加もありインフラ刷新を経て現在の形に至っています。本記事では、miHub で使用している技術について、その選定経緯および変遷を紹介させていただきます。
システム構成
まずざっくりとした現状のシステム構成ですが、以下のようになっています。フロントエンドと API サーバーは分離していて、SPAの構成となっております。開発スピードを優先して、モノリシックにした方が良いという意見もありましたが、プロダクトの方針として、使いやすさは重視したいということもあり、最終的に SPA の採用を決定しました。また、 API サーバーとは別に解析ワーカーを用意していて、時間のかかる解析処理を解析ワーカーで行うようにしています。
フロントエンド
React + TypeScript で開発しています。開発を始めたのが2019年でしたので、フレームワークについては React もしくは Vue の２択で考えていました。型定義をしっかりやっていきたいという思いがありましたので、TypeScript との相性を考えて React を最終的に選択しました。私が React の使用経験があったという点も大きい要素です。状態管理には Hooks 、UI フレームワークには Bootstrap を使用しています。現在 UI 改善のプロジェクトが動いており、UI フレームワークについてはオーバーライドのしやすい Chakra UI への変更を予定しています。
API サーバー
API サーバーのフレームワークについては正直何でも良いと考えていました。速度が求められることもなく、負荷が高くなることもそこまで想定されないためです。そのため、フロントエンドに合わせて Node.js にするか、解析ワーカーに合わせて Python の Web フレームワークにするかという議論もありました。しかし、最終的に Ruby on Rails を採用しました。理由の一つとして、アドバイザーとして参画いただいている @masuidrive さんが Ruby on Rails が得意であったというものがあります。また、エンジニア採用の観点で考えたときに、Node.js や Python が得意なWebエンジニアを探すよりは、Rails エンジニアの方が容易に見つけられそうといった理由もあります。Ruby on Rails に強いこだわりがあるわけではないので、今後技術選定の機会があれば、また違った結果になるのではないかと思っています。
解析ワーカー
解析ワーカーでは、SQS 経由でAPI サーバーからの解析実行指示を受け取り、解析結果を API サーバーに返しています。解析の内容としては、「ベイズ最適化」を用いて次に実施すべき実験条件を提案するものです。ベイズ最適化のアルゴリズムは OSS で公開されているものもあるのですが、機械学習のハイパーパラメータ調整用途に開発されているため、miHubの要件には合わず、自前で実装をしています。材料の研究開発向けにベイズ最適化を適用する際の特徴としては、多目的解析であること、制約条件が複雑であることといった点が挙げられます。多目的解析の例としては、強度を高めたい、かつ耐熱性も高めたいといったものです。制約条件の例としては、説明変数A、説明変数B、説明変数Cがあったとして説明変数A + 説明変数B + 説明変数C = 100 とするという条件であったり、説明変数A、説明変数B、説明変数Cのうち２つしか使いたくないといった条件があります。その他にも材料開発に向いた設定をできるように開発を進めています。
インフラ
現状では AWS を用いており、フロントエンドは CloudFront + S3、API サーバーと解析ワーカーは ECS となっています。解析ワーカーでの解析処理は数分〜数時間と幅があり、現状の構成ではインフラコストが高くなってしまうため、試行錯誤を続けています。
初期フェーズでは開発スピードを優先してインフラには Heroku を採用していました。その際には、簡単にセキュリティを強化できる方法として、シングルテナント形式を採用していました。ただ、運用コストの観点からあくまで一時的な採用としており、ユーザー数の増加後はAWS への移行と共にマルチテナント化を実施しました。その際にデータベースも MySQL から PostgreSQL への移行を行なっています。PostgreSQL の Row Level Security 機能を使うことでマルチテナント形式でもテナント間の情報漏洩が起きる可能性を低くするためです。同時に認証基盤も Auth0 へ移行しています。ユーザーからのセキュリティに関する要望は非常に強いのですが、要件を満たしながらも開発コストを抑えるためです。
おわりに
MI-6株式会社では AI を用いて素材メーカーの研究開発を効率化する SaaS プロダクト「miHub」を一緒に開発してくれる仲間を広く募集しています！
この記事を読んで、MI-6に少しでも興味を持っていただけた方がいましたら、是非ご連絡ください。カジュアル面談をセットさせていただきます。