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について書きます。
Autoscaling
GCEのAutoscalingは、AWSのそれとはかなり異なります。他のパブリッククラウドの知識は理解の妨げになるので、真っさらな頭でやりましょう。
ASの構造
この順番で成り立っている感じです。(Cloud MonitoringはCustom Metricsを使う場合)AWSの場合は
- AutoScaling Group launch config
- AutoScaling Group
- 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からみるとこんな感じです。
今回の変更で マルチゾーンが可能になりました。GCEのゾーンはAWSと異なり、2msのペナが無いので、使わない理由がありません。
ヘルスチェックについて
自分も誤解していたので、ヘルスチェックについて。まず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が出来ないので、
- Snapshot
- Snapshot -> Disk作成
- 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だと思います。
