汎用的なAPI基盤機能とインフラの構築セットをコード(IaC)で提供する #682
Description
内容
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 製品を盛り込むことも検討していきたいです。