GAミント至上主義

Web Monomaniacal Developer.

GKEのコスト節約を考える インスタンスをスケールアップしてノード数を5以下にする

2017/12/5追記

cloudplatform-jp.googleblog.com

クラスタ料金が無料になったため、5ノード以下は考えなくてよくなりました。

ただノード数を抑えることで、kubeシステム系の数は減らせるので、そちらはまだ有効そう。

uyamazak.hatenablog.com

2017/12/5追記ここまで


oceanusはGKEで本番運用を行っているけど、Kubernetesのバージョンを上げるたびに、CPUの消費が上がって、ノードが必要になっている気がする。

アプリケーションは大して変更していないし、アクセスも急増しているわけではない。

そこで、なるべくコストを抑える方法を考えた。


GKEの料金は2017/11/18現在下記のようになっている

Google Kubernetes Engine の料金と割り当て  |  Kubernetes Engine ドキュメント  |  Google Cloud Platform

f:id:uyamazak:20171108164828p:plain

なるべく5ノード以下にする

デフォルトでは1時間単位になっているけど、今のサービスはそんなピークのある使用ではないので、1か月で考えた。

東京リージョンでは、無料枠である5ノードを超えると、それまで無料だったのに一気に146ドル増えてしまう。

※個人的な解釈だけど、GKEのノード ≒ GCEのVMインスタンスと考えて今のところ問題ない。


n1-standard-1を東京で1か月借りると約31ドルとなるので、4台以上追加できることとなる。

5ノード以下に抑えれば、n1-standard-1×4相当のリソースを増やせると考えると、ここは可能な限りリソースに振りたいところ。

これはCloud Console上でも下記のようにメッセージで注意してくれる

4ノードの時
f:id:uyamazak:20171108165720p:plain

6ノードにしたとき
f:id:uyamazak:20171108170147p:plain

1インスタンスのリソースを増せば、ノード数は減らせる

ここで注目したいのは、ノード数(≒VMインスタンス数)であって、vCPUやメモリではないところ。

つまりvCPUが8個必要な場合、vCPUが1つ付いているn1-standard-1(もしくは同等のカスタムインスタンス)を8つとしてしまうと、3個オーバーしてしまうが、vCPUが4付いたn1-standard-1を2つにすればvCPUは8あるけど、ノード数は2になるので、無料枠で収まる計算。

もちろんn1-standard-8を一つでもいい。

VMインスタンスを分ける必要がなく、単純にCPU数が必要であれば、ノード数を増やすスケールアウトではなく、スケールアップを行いなるべくノード数を抑える方がいいと今のところ考えている。

見積もり

下記ツールで上記の条件で計算してみた

cloud.google.com

f:id:uyamazak:20171108171816p:plain

上記の通り、同じCPU数、同じメモリでありインスタンス料金は同じ$249.37/月だけど、n1-standard-1を8つの場合 Container Engine Cost: $146.00が余計にかかってしまう。

オートスケールをうまく使う

まだノードの自動スケールはベータ版だけど、これがちゃんと使えるのであれば、普段はノード数を5以下に収まるようになるべく性能のいいインスタンスを使い、急激な負荷のときだけノード数が増えるようにしておけば、GKEは1時間$0.20なので、数時間であれば大した負担にはならないのでいいと思う。

最後に

1年以上GKEで本番運用をし、新規サービスもすべてGKEで出しているものの、まだ大きな負荷で困ったことがないので、もっとユーザーがたくさん来てくれるサービスを作りたいと思った(小並感)

公開するサービス名とプロジェクト名を分けててよかった話

現在、ビズオーシャンでは、新しいサービスの開発と公開に向けて動いています。

サービスの公開が近づき、サービス名も部内の投票を参考に責任者によって決められ、ロゴも作って、サブドメインも登録して、SSL証明書(Let's Encrypt)も作って、Djangoの設定も変えて、
いよいよ!な時、念のためサービス名を商標登録しよう、ということになり、担当の人を通して弁理士?さんに確認したところNGが来てしまいました。

そしてもう一回、ちょっと英語の綴りを変えたりして、これなら大丈夫だろうと思って同様な作業を繰り返していたところ、読みが既存のものと一緒だと厳しいと、またNG。

商標取得の難しさを痛感。


でも、よかったこととして、内部的なプロジェクト名は全然別のものにしていたので、GCPのプロジェクト名とかソースコードのフォルダ名とか、Gitのレポジトリ名とかそういう開発に関わるところにはサービス名を使っていなかったので、それは非常に良かったと思います。


特にプロジェクト名は、公開しない前提で、世界の神話から神の名前を付けたり中二病を意識して付けていたので、恥ずかしくてサービス名には使えず、そもそもサービス名の候補にすらならないため、余計な手間も減りました。

今後も新規開発時は、中二病な名前で攻めようと思いました。

GKEでKubernetes 1.8が使えるようになったのでCron Jobsを使う

cron的なバッチ処理をKubernetesで行えるCron Jobsが1.8から使えるようになって、ちょうど他のメンバーの新規プロジェクトで必要になったので使ってもらった。


kubernetes.io

Prerequisites
You need a working Kubernetes cluster at version >= 1.8 (for CronJob). 


gcloudのkubectlも11/1時点ではまだ1.7だったけど、11/2でupdateをかけたら1.8になった。