ISSUEではこれまでフロントエンドはfirebasehosting+functionsというサーバ構成をとってきました。
しかし、SSRしたかったのでAppEngineに移行しました。

firebaseを使ってる時は、サーバ代はほとんど掛からなかったのですが、
AppEngineに移行した途端に高額な請求が届き始めました。

サービスもまだまだ小さいですし、払えないわけではないのですが、
明らかにサーバーの利用分に対する費用のバランスが合わなかったので、調査と調整をしました。
最終的には1/2にまで費用を抑えることができました。

## 最終的な費用は1/2まで押さえられた
4/15をご覧ください。
15日以前は倍以上費用がかかっています。
![image](https://user-images.githubusercontent.com/19757050/163662081-8993d87c-6b9f-4dcf-80e0-5b8c62ca3cbc.png)

## どうやったか
これはかなり簡単で app.yaml のmax_num_instancesを1にしました。
これはサービスによるのでアクセス数を考慮していただき調整必要です。

app.yaml
![img](/mosaic-code.jpg)


これがいいのかどうかはわかりませんが、
少なくとも必要以上にmax_num_instancesを挙げると余計に費用がかかってしまうことがわかりました。

ISSUEではこれまでフロントエンドはfirebasehosting+functionsというサーバ構成をとってきました。
しかし、SSRしたかったのでAppEngineに移行しました。

firebaseを使ってる時は、サーバ代はほとんど掛からなかったのですが、
AppEngineに移行した途端に高額な請求が届き始めました。

サービスもまだまだ小さいですし、払えないわけではないのですが、
明らかにサーバーの利用分に対する費用のバランスが合わなかったので、調査と調整をしました。
最終的には1/2にまで費用を抑えることができました。

## 最終的な費用は1/2まで押さえられた
4/15をご覧ください。
15日以前は倍以上費用がかかっています。
![image](https://user-images.githubusercontent.com/19757050/163662081-8993d87c-6b9f-4dcf-80e0-5b8c62ca3cbc.png)

## どうやったか
これはかなり簡単で app.yaml のmax_num_instancesを1にしました。
これはサービスによるのでアクセス数を考慮していただき調整必要です。

app.yaml
```js
env: flex
runtime: nodejs
resources:
  cpu: 2
  memory_gb: 4
  disk_size_gb: 20
automatic_scaling:
  min_num_instances: 1
  max_num_instances: 1
```


これがいいのかどうかはわかりませんが、
少なくとも必要以上にmax_num_instancesを挙げると余計に費用がかかってしまうことがわかりました。

続きを読むには単価診断を受けてください（30秒）