Google Cloud Platform Japan 公式ブログ: GCE ユーザーに高可用性を提供する Regional Managed Instance Groups がベータに 最近 Regional Managed Instance Groups という機能がβになりました。Regional とはなんぞや？ということですが、

この機能のもとでマルチゾーンの設定を行うと、Compute Engine が自動的に VM インスタンスを同一リージョン内の 3 つのゾーンに均等に分散させます。こうしておけば、1 つのゾーンの機能停止といった稀な障害が発生した場合でも、残る 2 つのゾーンに配置された VM インスタンスはサービスの提供を続けることができます。

ということです。逆に言うと今まではゾーン毎にManaged Instance Group (長いので MIGと略)を作る必要があったのですが、本機能でだいぶ楽になります。この機能とAutoscalingについて書きます。

20160807111047

Autoscaling

GCEのAutoscalingは、AWSのそれとはかなり異なります。他のパブリッククラウドの知識は理解の妨げになるので、真っさらな頭でやりましょう。

ASの構造

1.インスタンステンプレート
2.インスタンスグループ
3.(Cloud Monitoring)
4.AutoScaler

この順番で成り立っている感じです。(Cloud MonitoringはCustom Metricsを使う場合)AWSの場合は

1.AutoScaling Group launch config
2.AutoScaling Group
3.CloudWatch

です。GCEのAutoScalerはそれ自身が閾値基準によるScale-out/in判定を行っている感じです。一個ずつ軽く説明

個ずつ軽く説明

インスタンステンプレート

AWS launch config 相当です。ようは Scale-out時に立ち上がってくるインスタンスの設定 (Network, Tag, Image, MetaData等) を指定しておく物です。インスタンステンプレートでは リージョンは指定しません。

また、Image (OSイメージ)ですが、これはかなり楽できます。まず、AWSと異なり、Imageは全リージョン共通ですので、1イメージを全世界に撒く必要すらありません。さらにImageにはfamilyという属性があり、これを一致させてImage作成すると、 familyでイメージを指定した場合、そのfamilyの中の常に最新版のImageを指す 事ができます。
つまり、AWSだと、AMI作成してから Launch Config のイメージ差し替えが必須でしたが、その1手が全く不要になります。というより、API的にImageだけ差し替えとか出来ないので、これを使わないとかなり面倒な話になります。

なお、family で Imageを指定する方法は、残念ながら Developers Consoleでは存在しないようです。gcloud 必須です。下記の –image-family を指定します。

gcloud compute instance-templates create | Cloud SDK | Google Cloud Platform

インスタンスグループ

タイトルに出てきた Regional Managed Instance Groupsの話です。インスタンスグループは、インスタンステンプレートを参照します。また AotoScalerも参照？しているはずです。Developers Consoleからみるとこんな感じです。

20160807111156

今回の変更で マルチゾーンが可能になりました。GCEのゾーンはAWSと異なり、2msのペナが無いので、使わない理由がありません。

20160807111221

ヘルスチェックについて

自分も誤解していたので、ヘルスチェックについて。まずAWS識者の為の一言ですが
ELBベースのヘルスチェックは、GCEには存在しません。またヘルスチェックを行うのはLBではありません。

GCEのヘルスチェックはそれ単体で独立しています。HTTPの場合は、ローカルリンクアドレス (169.254,169.254) から飛んで来ます。 よって、ヘルスチェックを使い回すことが出来ます。

AutoScaler

驚くほど少ないパラメータしか指定出来ません。まず現状では出来ないこと

gcloud compute instance-groups managed set-autoscaling | Cloud SDK | Google Cloud Platform

  • スケール Out/In のルールを分離出来ない
  • スケール Inしないという戦略はとれない
  • 閾値超過したとき、何台追加するかを指定できない (step)

出来ることは

  • インスタンス最大/最小台数指定
  • CoolDown期間の指定 (AS発動間隔)
  • CPUベースのAS発動
  • カスタムメトリックスベースの発動
  • LB利用率ベースの..

次に、それらをGCEはどうさばいているか。

  • スケール Out/In のターゲットとして CPU 60% とだけ指定する
  • CPU 60% を超えた場合、上昇速度に応じて Setpを決める ( 緩やかな上昇なら1台、急激に上昇したら一気に5台とか多分そんな実装っぽい)
  • CPU 60% を下回ったら即座に スケール Inとか、そんなにバカじゃない。ある程度余裕をもって勝手にスケールIn

一言でいうと こまけぇこたぁいいんだよ！！ いい感じにやっとくから

デプロイのやり方

Image差し替えの方法です。

新規Image作成

Image作成は結構面倒です。GCEは動いているDisk -> Imageが出来ないので、

1.Snapshot
2.Snapshot -> Disk作成
3.Disk -> Image作成

という結構な面倒なことになります。この時、前述の Family を指定していれば、インスタンステンプレートの差し替え不要。

デプロイ前の AutoScaling Stop

他所でも言及されていますが、 Stopは出来ますが、再開は出来ません。set-autoscaling で再設定が必要です。

まとめ

  • GCEのAutoScalingは細かくユーザーが指定出来ないが、動かしてみたところかなり賢い。正に こまけぇこたぁいいんだよ！！
  • Regional Managed Instance GroupsでZone毎にいちいち作らなくても良くなった。
  • Image の Familyは使うべき。でもgcloudでのみ指定可能。

今回のアップデートでかなり使いやすくなりました。また、AutoScaling自体、かなり大きな変更が入っているはずなので、他所の古い記事とは整合しない部分が多数あります。あとは、AWSのようにLifeCycle-Hookなどが現状存在せす、Shutdown-ScriptというOS外で指定できる機能があります(SLAは無い、走る保証は無い)。細かい色々不足している機能はありますが、ユーザーがいじれる部分を極限まで減らし、本当に必要なものだけを高いレベルで実現出来ているのは、さすがGoogleだと思います。

元記事はこちら

「GCE Autoscaling in 2016夏 」