メモリ消費を削減する

[femshima]

追加辞書を含めるとvutd-shovelの辞書ファイル、特にsys.dicは453.3MBものサイズがある。 OpenJTalk(特にMeCab)に渡すためにはこれをメモリにロードする必要があるが、メモリが限られた環境では重荷になる。

さらに、事前に辞書をすべてロードしておいた場合も、音声合成時に60MBの使用量の増加がみられた。 この増加分60MBがv1.0.0での#42 の原因になった可能性がある。 (つまり、辞書など諸々が600MBを占有する中、二つの音声合成が同時に発生したことによりさらに60*2=120MBが占有され、限界に到達したのではないかということ)

postgresの設定や、辞書をロードするタイミングを調整することで、メモリ消費を削減できないだろうか。 アイデア募集中。

[femshima]

Google Cloud Functionsに音声合成部分を任せるという案が出ている。

メリット

• 複数メッセージが同時に来ても死なない
• 「一時的なメモリ使用量は多いが実行時間は長くない」という音声合成の特性にマッチする。

問題点

• 辞書をどうやって渡すのか？
• node-openjtalk-bindingが使えるか？
• GCEとのインターフェースはどうするのか？

[shundroid]

Firebase Cloud Functions時代にLINEのAPI呼び出しに使ったことがあります。

• 「一時的なメモリ使用量は多いが実行時間は長くない」という音声合成の特性にマッチする。

について

1,024 MB、0.5833 vCPUで動かした場合、一回の合成に5秒(←多めに見積もった)かかるとすると一か月あたり8万回呼び出せます。

とありますが、この5秒には辞書の読み込み時間とかも含まれていますかね(ずっと変数保持してくれなかった気がする)

• 辞書をどうやって渡すのか？

について

この辞書はどういうタイミングで変更されますか？

一番ありそうなのは、botが立っている側のサーバーで辞書を管理して、Cloud Functionsがそれにhttps経由でアクセスできるようにする感じですかね

オーソドックスなやり方ですが、アクセス回数を減らすために、Cloud Functions側でキャッシュとして持っておいて、botサーバー側から変更をcloud functionsに(urlアクセスなどによって)通知して、通知があったら辞書を取り直すみたいな感じでしょうか

[femshima]

辞書の読み込みといっても、結局のところストレージからメモリにコピーする処理なので音声合成本体に比べれば圧倒的に軽いのではと予測しています。 辞書が変更されるのは各バージョンのリリース時であり、頻繁には更新されませんので、Cloud Functions側でnpmパッケージとして持っておくのも手だと思います。

[shundroid]

辞書が変更されるのは各バージョンのリリース時であり、頻繁には更新されませんので、Cloud Functions側でnpmパッケージとして持っておくのも手だと思います。

あ、なんだ、それくらいならそうでもいいですし、ただそれだと bot本体のリリースに応じて Cloud Functions 側をアップデートする必要が出ちゃうので、botサーバーがhttpで辞書データをホストしてfetchしにいくみたいなのでもいい気はします

[femshima]

データ転送は無駄にCPU時間を食うのでそれは何とも言えませんね…

[shundroid]

グローバル変数を使うな！ということなので辞書をグローバル変数にしたりしないとなると辞書をrequireする手がよさそうです(githubからinstallするのもあり)

[femshima]

そもそもGoogleにビルドさせるんじゃなくて自前でコンテナを用意できないんですかね

[shundroid]

んー、FaaS?のレベルだからどうなのかなーという感じです、調べたらでてきたりするのかな

[femshima]

もしかして「辞書を保存する料金」がかかります？ https://cloud.google.com/artifact-registry/pricing

[shundroid]

おっと…？