この記事の目的

公式ドキュメントが充実しているものの、AWSからGoogleCloudに手を広げた自分自身の経験として、MIGに最初に触れた際に少し混乱したり、混乱する人もいそうだなぁと感じたところを中心に、書き残しておきたいと思います。
誰かのお役に立てれば、これ幸い。

詳細については、公式ドキュメントを参照ください。

What is "MIG"

Management Instance Groupの略。
ロードバランサーの配下のインスタンス群を自動増減・復旧させたり、アップデートしたりする際に利用する。

Unmanaged Instance Groupというものもある。
こちらは、名前のとおり手動で操作する。
管理用サーバーが必要であったり、複数の種別のサーバー群を一纏めに取り扱う場合に利用する。

MIGは、以下の２種類がある。

ステートレスMIG
ステートフルMIG

以下にそれぞれの概要を示す。

ステートレスMIG

用途

webサーバーや、ACID特性を満たすようなバッチ処理サーバーのようなシステム向け。

特徴

サーバーの更新は、ベースイメージの定期的を更新（インスタンステンプレートの更新）または、最新コンテンツをGitやGCSのような外部ストレージから取得するなどで実現する。
オートスケーリングポリシーを元に、スケールイン/スケールアウトを自動的に行う。
オートヒーリングによるVMインスタンスの自動復旧も可能である。

ステートフルMIG

DBサーバーなどのような中断/再開のために処理が必要なシステム向け。

特徴

各サーバーごとに状態を持つ。
そのため、更新などの操作は複雑になる。
オートヒーリングによるVMインスタンスの自動復旧も可能であるが、オートスケーリングの機能はない。

更新

MIGの更新のために、ローリングアップデートの機構が提供されている。
自動ローリングアップデートを行うにはステートレスMIGである必要がある。
ステートフルMIGにてローリングアップデートを行うためには、ステートフルディスクにデータを保持する必要がある。

ローリングアップデートには、同時に複数のテンプレートを指定する、カナリアテストの指定もできる。

更新タイプには、PROACTIVE（自動先行更新、更新型）とOPPORTUNISTIC(日和見、選択更新、追従型)がある。
公式ドキュメントでは日本語表記でカッコに書いたような揺らぎがあるので注意！
前者がマネージド、後者が指定型といったイメージ。インスタンス名を指定したりする場合は後者を選ぶ必要がある。

maxSurgeとmaxUnavailable

ローリングアップデート時に指定するパラメータ。
以下の図のように更新されていく。

可用性を重視する場合は、maxSurgeを上げる。
一方、コストを優先したい場合は、許容される範囲までmaxUnavailableをあげる。

関連機能、リソース

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

イメージやインスタンスタイプの指定、ポート開放設定など、VMインスタンスを起動するためのパラメータ群を登録しておく。
イメージにはカスタムイメージも指定可能。ただし、マシンイメージは指定できない。

スナップショットとカスタムイメージとマシンイメージ

VMインスタンスの特定のディスクのバックアップがスナップショット。
ディスクのバックアップに加え、VMインスタンスを起動するために必要な情報を付与したものがカスタムイメージ（コンソール上は、「イメージ」と表記）。
複数のディスクで成立するVMインスタンスに対応するカスタムイメージが、マシンイメージ。

AWSでいうところの、スナップショットはEBS snap shot、カスタムイメージおよびマシンイメージがAMIのイメージが近そう。
ざっくりとスケッチするとこんな感じ。

マシンイメージは比較的新しいためか、インスタンステンプレートとかには対応していなかったりする。
インスタンステンプレート目線で見れば、当然な気もするが、AWSに慣れている人からは、混乱するところに思う。