汎用的なAPI基盤機能とインフラの構築セットをコード(IaC)で提供する

[lawofcycles]

内容

voicecox_engineを用いたクラウド上でのAPIサービス基盤構築に必要な機能と、その土台となるインフラ一式を定義した効率的かつ拡張可能なIaC(Infrastructure as Code)を提供します。
これによってVOICEVOX API基盤をホストしたい人が、汎用的なAPI基盤を簡単に構築したり、個別要件に応じてカスタマイズして提供できるようになります。

例えば以下のようなユースケースを想定しています(#434 末尾の議論)

VOICEVOX公式スマホアプリ からの利用（未定）
web上で使えるVOICEVOXデモ（未定）
有料VOICEVOX APIの提供（未定）
VOICEVOX APIサーバーを建てる（音声合成を使いたいアプリ開発者など）

具体的な設計はこれからですが、例えば以下をIaCで生成できる仕組みを優先順位をつけて開発しつつ、E2Eで利用できるアーキテクチャセットを提供したいと考えています。

• すぐにVOICEVOX(のコンテナ)を利用できるGPUマシンイメージ
• 推論に適したGPUマシンのクラスタリングとオーケストレーション
• クラスタ間のロードバランス(キューイングも必要かも)
• 安価なマシン(SPOTインスタンス)の確保と中断のハンドリング
• 負荷状況に応じた動的スケールによるコストと性能の最適化
• 一定規模以上のAPI 提供に必要とされやすい一連の機能
  • スロットリング等の流量制御, 認証とアクセス権の管理, 利用状況のモニタリングなど
• これらの土台となるネットワークやストレージ、発見的/予防的セキュリティ、冗長構成などのインフラリソース及び運用機構

各機能は汎用性を考慮した最大公約数的な仕様を目指しつつ、各構成要素をコンポーネント化してカスタマイズしやすくします。

Pros 良くなる点

• 個々の開発者が簡単にVOICEVOXのAPI基盤を構築できるようになる
• 今後プロジェクト内でサーバサイドでのAPI提供が必要とされた際に利用できる

Cons 悪くなる点

（悪くなるわけではないものの）土台とするクラウドサービスプロバイダとしてAWSの利用を考えているため、人によってはそれ以外のGCPやAzure, OCIなどに対応して欲しい需要があるかもしれません。ただ、出来るだけ可搬性を意識した設計(OpenAPI準拠、コンテナオーケストレーションにk8s/EKSを用いるなど)に寄せることで、ある程度将来の不確実性(他クラウド版の提供やマルチクラウド対応の可能性など)に備えられると思っています。もっとも、本当にk8sがニーズに合うかは慎重に考えるべきですが...

実現方法

土台となるクラウドサービスとしてはAWSを使用し、IaCの実装にはCDKを用いる想定です。CDKの実装言語には最もCDKコミュニティが大きいTypeScriptを用いるのが良いと考えます。
AWSを利用するのがいいと思うのは、以下の理由からです(私が比較的AWSに詳しいので開発しやすい、というのを脇に置くとですが...)

• 利用シェアが大きいため、比較的多くの人の需要に応えられる可能性が高い
• (私が知る限り)主要クラウドプロバイダの中で特にIaCが成熟しており、アプリからインフラまでE2Eでコードで管理する用途に即している
• APIスロットリング機構など、欲しい機能をマネージドに提供してくれる仕組みが充実している(これは他もそうかも?)

設計は開発負荷軽減や運用の容易性などの観点でマネージドサービスを中心に組んでいく想定ですが、必要に応じてOSSや3rd party 製品を盛り込むことも検討していきたいです。

[Hiroshiba]

良いですね！！

クラウド上でAPI建てるコードをOSSとして、CtoCやCtoBに展開できたらなかなか前例もなくとてもおもしろいと思っています。
自分もAWS CDKはほんのすこしわかるので、やるとしたらAWS CDKが良いと思っています。

最終的には別リポジトリを作るのが良さそうですが、いったんエンジンのissueで･･･！

[github-actions]

本 Issue は直近 180 日間で活動がありません。今後の方針について VOICEVOX チームによる再検討がおこなわれる予定です。