[Kaizen]: Reduction of cold starts

[Ningensei848]

気になったこと（改善すべき点）

バックエンドのコールドスタートが大きく、そのせいで CPU 専有時間が長くなり、コスト増に繋がっている

どうあってほしいか（理想とする姿）

なるべく減らす

コストを下げたい

[Ningensei848]

--concurrency オプションも検討（デフォルトは１インスタンスにつき１ずつ実行）

cf. 同時実行  |  Google Cloud Functions に関するドキュメント

[Ningensei848]

総評

• 同時実行インスタンス数が 500 とかになっててアホ
• 実行に 1 min も掛かってたらそりゃあ CPU Allocation 多すぎって怒られる

/entries

/getHorseResult

追記

同時実行の値を 1 より大きい値に設定するには、1 つ以上の vCPU を持つ関数が必要です
cf. https://cloud.google.com/functions/docs/configuring/concurrency

なので、/getHorseResult の方は 1GiB まで設定を引き上げる必要がある

[Ningensei848]

現時点で想定しうるアプローチ

1. 本番リクエスト前に、テストリクエスト（？）を行ない、「火入れ」する
2. --concurrency を適切に設定（メモリ不足とかでコケないように）し、インスタンス数を減らす
3. ↑ の二つの合せ技

[Ningensei848]

結果

1. 着火スクリプト
2. concurrency を追加

してみたところ、パフォーマンスは上がってそう（コールドスタートは減ってそう）

/entries

• memory 2 GiB
• concurrency 4x

/getHorseResult

• memory 2 GiB
• concurrency 8x

講評

• 最大インスタンス数が減っててよい
• 実行時間は変わらない（処理それ自体は不変なのでそれはそう）
• entries はメモリも増やさないとこれ以上のパフォーマンスは厳しいか
• getHorseResult はまだ負荷上げても大丈夫そう

entries は 6x
getHorseResult は 24x まで増やしてみる

[Ningensei848]

結果

• entries は 6x でも大丈夫
• getHorseResult は まだまだ余裕がある、ぶっぱしてもいいかも

/entries

/getHorseResult

講評

• 最大インスタンス数が増えた？！

  • /getHorseResult 内部で /entries を呼ぶので、まぁそれはそう

• 増やしすぎないように増やす

• entries は 8x (+2) に変更

• getHorseResult は 48x (+24) に変更

[Ningensei848]

/entries

/getHorseResult

講評

一向にメモリ丸々使ってくれないので、ここは一気に負荷を増やしてみる

• /entries ... 64x
• /getHorseResult ... 256x

[Ningensei848]

データ取得が失敗する事案が発生

/entries がメモリエラーでコケると /getHorseResult も軒並み失敗する

64x でダメだったので、48x にしてリトライ

[Ningensei848]

48x だとメモリ使用量がヤバいかも

ので 36x に下げて、 getHorseResult も 180x に調整