嬉ション大放出です。
昨日から GCP の負荷分散時のバックエンドの更新でとても便利な「ローリング更新」がアルファ版で使えるようになりました。
一昨日まではバックエンドの VM を更新する際に、手動で古いイメージで起動された VM を落としていたんですよ。それが自動化されました。
細かい設定が出来て、更新するための新しい VM を叩き起こす数(最大サージ)と、今上がっている VM を叩き落とす数(オフライン上限)を指定できます(台数とパーセンテージで指定できます)。
どう言うことかと言うと、例えば今 VM が 3台上がっていて、こいつら全てを新しいものに更新したい、とします。
最大サージを 1、オフライン上限を 1 とすると、新しい VM が 1 ずつ発起動して、古い VM が 1 台ずつ落とされて行きます。
最大サージを 3、オフライン上限を 1 とすると、新しい VM が 3 発起動して、古い VM が 1 台ずつ落とされていきます。
最大サージを 3、オフライン上限を 2 とすると、新しい VM が 3 発起動して、古い VM が 2 台落とされ、1台落とされます。
最大サージを 3、オフライン上限を 3 とすると、起動している VM が全くいなくなって落ちそうですが落ちない雰囲気があります。新しい VM が 3 台立ち上がって、古い VM が 3台落とされて UI 上でグルグルしているんですが、起動した新しい VM のグルグルの方がほぼ同時に先に止まって、一気に切り替わりました。ブラウザでページにアクセスしながらやっていたんですが、何もエラーは出ませんでした。
最大サージを増やすと、新しく切り替えるための VM が最初から大量に上がるんで、切り替えは早くなるけれども、余計に VM を起動するので、古い VM が落ちるまでは VM の起動料金が重複してかかります。設定している最大インスタンス数を無視して起動しますんで。
オフライン上限を上げると、立ち上がった新しい VM を一気に反映させることが出来ます。
やばいバグの Fix や UI がガラッと変わってしまうような変更の場合、最大サージもオフライン上限も上げまくった方が良いでしょうね。まぁ、IP や Cookie で同じ VM に向ける機能があるのでそれを使っていれば UI の変更で同じユーザーがリロードしたら画面がチョロチョロ変わってしまうってことは無いですけどね。
しょうもないパッチなんかだとどっちも低くて良いと思います。
カナリアテストもできます。Google はカナリア大好きですね。
炭鉱で毒ガスが発生していないかを確かめるためにまずカナリアを特攻させると言うなんともアレな行為から来ているカナリアテストですが、Chrome も Stable -> Beta -> Dev -> Canary と右に行くにつれアグレッシブな開発版になっていきます。この Canary がカナリアです。
GCP のカナリアテストは、複数分散されたマシンのうち、何台か新しいイメージに変えてみる、ってなことが簡単にできる機能です。変えてみてやばかったら速攻戻す事ができます。設定は、割合と台数で可能です。やり方によっては AB テストみたいなこともできますね。
設定の仕方は UI 見れば一発でわかると思いますが、ちょっとわかりにくいところがあるので一応書いておきます。
インスタンスグループの画面の上に、ローリング更新、再起動/置換のローリングと言う2種類がありますが、前者はカナリア更新です。
更新モードにプロアクティブと日和見がありますが、プロアクティブは最大サージ、オフライン上限を指定するやつです。なんとも日本人的には良い響きの名称である「日和見」はオートスケールで増えたり減ったりした時に新しいインスタンステンプレートに切り替えます。ものすごくどうでも良いパッチなどの反映にしか使わないでしょうね、これ。
で、カナリアテストで追加したテンプレートの切り替えが終わったら、その設定がそのまま残ってしまいます。アルファだからかもしれませんが。手で消して、現在のテンプレートにさっき指定した新しいテンプレートを指定してやると良いです。
再起動/置換のローリングは、インスタンスグループの編集から直接テンプレートを変更した場合に使います。ちょっと前まで手でインスタンスを切り替えていたのが自動化できるるというわけです。
再起動とありますが、これで新しく設定したテンプレートにインスタンスが逐次変わっていきます。オフライン上限のみを指定して VM のテンプレートを切り替えていきます。
置換はオーバープロビジョニングと書いてありますが、最大サージを指定することができるようになるだけです。
ここらあたりの文言がさすがアルファ版だけあってだいぶ混沌としてはいますが、その内いい感じになるでしょう。
後、ここまで読んでもらった GCP を知っている人に向けて、追加のナレッジ。
LB で 502 エラー がでちゃった場合は、メニューのロギングからログが閲覧できます。一番左のセレクトボックスで Cloud HTTP記法 ロードバランサの中から対象の LB の rule を選択すれば見れます。セレクトボックスでステータスを絞れるので警告を選択すると 502 のエラー内容が出てきます。エラーは JSON になっています。jsonPayload の tatusDetails を見ればエラーの原因がわかります。
statusDetails: "failed_to_pick_backend"
健全なバックエンドを拾えなかったぜ、と言うこのエラー。これは、オートスケールでサーバが増えている最中にアクセスが来ちゃっている場合やパンクしている状態の時に出ます。負荷テスト中やバーストが来る際にこれが出まくります。そういう場合はインスタンスの最小数を大きくしておくと良いですよ。
Keepalive の時間を伸ばせばいい、なんて事がどこぞのサイトで書いてあったりしますが、全く意味が無いのでヤメましょう。
