たしかに、ものすごいIOが来ることを想定して、あえて自動振り分けをOFFにしていた説はありますね。 ただ、そんなにWriteが多いサービスには見えない（少なくとも今のPVならば）ので、いったん自動振り分けONで良さそうに見えています。

鍵はGCP側で管理されており # GCPのデフォルト認証情報を設定 gcloud auth application-default login でkubesecが動くようになりましたm()m M2 Macだとkubesecがちゃんとインストールできなかったので、Docker側にkubesecからGoogle CLIの一式入れる必要ありでした。

古のcの時代のヘッダーファイルを思い出しました。なるほど。

これはまさにその通りなのですが、まさにコードの書き方で対応すべき問題と思っています。 フロントとバックが分離されている前提の上ですが（今の質問箱はそうなっていないですが） フロント側からPOSTをした時点で、フロント側にはすでに表示をしておくことでUXがよくなるという。（例：LINE）

SLAへの見方が人によって異なるのだなあと感じるこの頃。 SLAを設定している企業側は 「この数値は絶対に死守するし、この数値を割ったら会社の信頼に関わる」 と思って設定しています。 なぜならSLAは顧客とのAgreementだから。特にBtoBでは信頼が財産なので重いです。 ※外資も同じと信じたい

ですねえ。 昔やっていたWebSockerのチャットサービスを思い出して書いてしまいました。

Cloudflareの移行ができた説 Cloudflareはアカウントごとの譲渡が不可だったので以下の手順で移行 1. 設定情報を共有いただき 2. こちらでCloudflareを同じ設定で作り直し 3. ネームサーバ切り替え まだ、全体にネームサーバ浸透できてなそうだが、これが済むと、GKE Autopilotへの移行もできそう

GKE Standardから、GKE Autopilotへ移行しました。 1. Autopilotにてクラスタを作り直して、新しい静的IPを付与 2. CloudflareにてAレコードを切り替え という次第。 さすがに移行・デプロイをAIに任せるのは怖いので AIに手順書作らせる→確認しながら手動で実行 これで安くなると良いが・・・

webワーカー（Railsが稼働）が結構な数、動いているけど 300万PV/月だとこんなもんなんだっけな・・・最近toCのサービスをやっていないから感覚を忘れている。。。

■これからやる予定のこと ・DBの不要データを削除後にDB作り直し（4コア/8GB x 2台構成を想定） ・STG環境は使用時以外は停止（Autopilotの安定を確認後） 感覚的には、300万PV/月ならば、インフラは月15万以下くらいに収めたい。 ・GKE（App）：5万 ・DB：8万 ・S3（画像）：2万 くらいにしたいなあ

あとはそもそもGCP離れて ・Cloudflare（LB兼ねて） ・さくらVPS（さくらクラウドではなく） ・さくらDB ・S3 とかにした方がコストが下がる気がするけれども、全体をちゃんと理解していない中でちょっと手間すぎる sidekiq workerの挙動もよくわからんし

GKE Autopilotの Spot Pod cloud.google.com/kubernetes-eng… すぐ処理が完了するアプリケーションサーバならば、これで動かしても問題ない気がするが、本番環境で使ってよいのか悩む。。。