Upgrade to Pro — share decks privately, control downloads, hide ads and more …

多様な最適化サービス開発をスケールさせる共通基盤とチーム構成

 多様な最適化サービス開発をスケールさせる共通基盤とチーム構成

Avatar for ALGO ARTIS

ALGO ARTIS

January 09, 2026
Tweet

More Decks by ALGO ARTIS

Other Decks in Technology

Transcript

  1. 藤原 秀平 • ソフトウェアエンジニア(プラットフォームチーム) • ALGO ARTIS ⼊社以前は機械学習屋 ◦ データサイエンティスト‧MLOps

    エンジニア • 学⽣時代は数理最適化が専⾨ • Google Developer Expert (Machine Learning, Google Cloud) ⾃⼰紹介
  2. • 会社紹介 • ALGO ARTIS のプラットフォーム ◦ Platform によって何を共通化したか ◦

    Platform によって開発‧運⽤はどう変わったか • プラットフォーム開発の難しいところ ⽬次
  3. とは⾔ったものの、簡単ではない • 最適な計画を作るサービスといっても分野は様々 ◦ 資材を運ぶための配船計画 ◦ ⼯場の⽣産計画 • それぞれ顧客の業務に合わせた細かい作り込みが必須 ◦

    最適化システムは開発をスケールさせるのが難しいと⾔われる所以 それでもチャレンジするという決断をした結果のプラットフォーム 事業をスケールさせることの難しさ
  4. データ永続化 最適化システムの典型的な構成 顧客に合わせた作り込みが重要になるのはどこか? Frontend Cloud Run Backend Cloud Run Algorithm

    Vertex AI Cloud Pub/Sub Database Cloud Firestore Cloud Storage • 個社別の作り込みが必須になるのはアルゴリズムとフロントエンド • 共通化が⾒込めそうなのはそれ以外 ◦ バックエンド‧インフラ‧認証認可‧etc...
  5. アーキテクチャ Frontend Cloud Run Backend Cloud Run Algorithm Vertex AI

    Cloud Pub/Sub Database Cloud Firestore Algorithm Image Container Registry Input / Output Cloud Storage Frontend Code Cloud Storage • アルゴリズムは Docker イメージ単位で差し替え • ⼊出⼒のスキーマが揃っていれば何でも OK Auth0 • テナントごとの UI を Cloud Storage 経由で配信 • データアクセスの I/F とローカル開発ツールも提供 • 社内では Frontend Addon と呼ばれる機能
  6. 個別案件の開発がアルゴリズムエンジニアと フロントエンドエンジニアで完結する体制へ • 個別案件 ◦ アルゴリズムエンジニア: 1~2 ⼈ ◦ フロントエンドエンジニア:

    1~2 ⼈ • プラットフォーム ◦ 現在は 6 ⼈ + 業務委託メンバー プラットフォームを活⽤するチーム構成 個別案件 アルゴリズム フロントエンド バックエンド プラットフォームチーム インフラ 個別案件チーム アルゴリズム フロントエンド フロントエンド バックエンド インフラ 案件が増えるほど効率が良くなっていく構成に!
  7. 当初の想定 • 計画の最適化‧評価は時間がかかるケースもあるので⾮同期ジョブが適切 • クライアント側で重い処理をやらせるべきではない • UI 実装とアルゴリズム実装を極⼒疎結合に 初期設計から変化したこと Backend

    Cloud Run Algorithm Vertex AI Cloud Pub/Sub 計画の最適化‧評価を実⾏すると ⾮同期のジョブが発⾏される 評価はレスポンスが命なのでクライアントで実⾏したい • 最近のアルゴリズムエンジニアは TypeScript 書けちゃうのでフロントで実装 • Wasm によるクライアントでの評価実⾏を促進 最適化‧評価の実⾏環境は適切に選択できるのが理想
  8. External Service 当初の想定 • 外部とのデータ連携をコンテナジョブに切り離す • 社内で Connect Addon と呼ばれる機能

    初期設計から変化したこと Backend Cloud Run Cloud Pub/Sub Connect Addon Cloud Run Jobs Email Input / Output Cloud Storage 実際の使われ⽅ • 任意の処理をコンテナジョブに切り離す • プラットフォームのコア部分を変えずに機能追加 ◦ 実装を各案件に委ねやすい ◦ 後戻りしやすい機能追加の仕組みを実現 Scheduled Trigger Cloud Scheduler External System
  9. ログやデータが⼀箇所に集約されて管理しやすいように思える? • 複数テナントのログが混在するので権限管理が煩雑になる • 特に ALGO ARTIS は担当案件以外の情報が⾒えてはいけないので⾮常に気を遣う ログ‧データの管理の課題 Log

    Collection Cloud Logging Log Streaming Cloud Pub/Sub Database Cloud Firestore On-Call Datadog Dashboard Looker Studio Tenant 1 Raw Logs BigQuery Table Backend Cloud Run Tenant 2 Tenant 3 Frontend Cloud Run Logs (Tenant1) BigQuery View Logs (Tenant2) BigQuery View Logs (Tenant3) BigQuery View
  10. 多様な領域をまとめて扱う以上ここは避けられない • 領域を絞れば SaaS 化できそうなものはある → 化学⽣産の領域では SaaS として Planium

    を提供 • UI を統⼀してアルゴリズムは簡易的なもので共通化 結局アルゴリズムと UI 開発がボトルネックになるのでは
  11. Optium, Planium の 2 種類のプランを顧客に合わせて提供 • Optium: UI とアルゴリズムを個別に作り込む従来の形 •

    Planium: SaaS として同じサービスを複数顧客に提供 いずれもプラットフォーム上で開発 Optium, Planium Platform Tenant (Optium) Planium Tenant Tenant (Optium) Tenant (Optium) Tenant Tenant