http://speech.gundou-mirei.love/ の話です。

Elastic Beanstalk を使っていたが ECS にした。

eb で概ね上手くいってはいたが、金銭面で問題があった。
起動時にデカい辞書を読む都合で 2 GB のメモリでは足りず、 4 GB のメモリがある t3.medium を使っていた。
これは月 4200 円程度となって、趣味でマネタイズ無しで運用するのは無理じゃないけどちょっと気になる金額だった。

このアプリはアクセス数はさほど大きくならないはずなので、アクセスが無い間は課金されないようにされたい。
そういう課金体系 + 個人で気楽に管理できる範囲だと Lambda か ECS になると思う。
Lambda のメモリ使用量の制限は 3 GB までしかなく、ギリギリになる可能性があるため ECS を使うことにした。

まだ対応したばかりで本当に安くなるかどうかは分からないのでしばらくは様子見という状態。

デプロイは AWS CDK で行っている。 ほぼ cdk init して https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-ecs-patterns.ApplicationLoadBalancedFargateService.html のインスタンスを作るだけで終わりなので非常に簡単だった。

音声素材などの静的なデータの管理も考慮する必要がある。
これは事前にローカルで生成、 S3 にアップロードしておき、 CI 上では S3 からダウンロード、 Docker イメージにそれを含めるようにしている。

環境変数の類が多くて GitHub Actions の Secrets に一個ずつ登録するのが面倒だなあと思っていたが、 これは .env のファイルを丸ごと登録することにした。
ただし、そのままコピペしても上手くいかなくて、どうやら改行を含めてもスペースなどに置換されていそうだった。
これは改行込みのテキストを Base64 エンコードして登録し、 GitHub Actions 側でデコードすることによって対応した。

https://developer.github.com/v3/actions/secrets/ に Secrets を管理するための API があるので他の自動化もできると思う。 .env をバラして登録するようなツールが有るかと思ったがこれは見つけられなかった。割と単純なので自分で作るのも良いかもしれない。

デプロイがダルくて開発が停滞気味だったが、そこは乗り越えたので頑張って流暢に喋らせます。