Compute Engine のインスタンス グループを自在に更新できる Managed Instance Group Updater
Google Cloud Japan Team
マネージド インスタンス グループは Google Compute Engine の重要な機能の 1 つです。この機能を使って同じインスタンスのコレクションを 1 つの単位として管理すれば、新しい VM をすばやくデプロイし、統一的に構成、設定することができます。
私たち Google は先ごろ、Compute Engine VM をプログラムで大規模に更新できる新しい Managed Instance Group Updater をベータ リリースしました。この Updater はマネージド インスタンス グループに完全に統合されているため、インスタンス上のソフトウェアの更新、パッチの適用、ステージング / テスト デプロイのロールアウトが今までになく簡単になります。
新しい Updater は次の機能をサポートしています。
- 新旧のインスタンス テンプレートを用いたインスタンスの更新
- 同時に更新するインスタンス数（1 個、一部、全部）の指定
- インスタンスの置換中に処理能力を維持するため、追加インスタンスの一時的なデプロイ
- マネージド インスタンス グループに含まれる全インスタンスの再作成もしくは再起動（テンプレートの変更なし）
- インスタンス更新の間の一時休止設定によるデプロイ ペースの制御
機能を 1 つずつ説明するのではなく、上記のようにまとめて説明すると威圧的に感じられるかもしれないので、よくある 3 つのユース ケースを例に、Updater の機能について紹介します。
- 単純な更新
- カナリア テスト
- 全インスタンスの再作成
なお、この投稿では UI と gcloud コマンドラインの両方で Updater の使い方を説明しますが、Updater の機能は API 経由でも使用できます。
単純な更新（基本的なローリング更新）
まずは、一度に 1 インスタンスずつ更新して、マネージド インスタンス グループ全体にアップデートをデプロイするという初歩的なユース ケースから見ていきます。my-instance-group というインスタンス グループが、myapp-version-a というテンプレートを実行してすべてのインスタンスを起動しているとします。このグループに対してソフトウェアの新バージョンをデプロイするため、Updater を使って myapp-version-b というテンプレートをデプロイしましょう（OS のパッチ適用 / 更新でも同じ方法が使えます）。
上記操作により、my-instance-group は、myapp-version-a のインスタンスを削除し、同時に myapp-version-b のインスタンスを作成して、その新インスタンスが健全な状態になるのを待ってから次のインスタンスの作業に移ります。そしてそのサイクルを、全インスタンスが更新されるまで続けるという形で myapp-version-b をデプロイします。
更新をロールバックしたい場合は、ターゲットを myapp-version-a に変えて同じコマンドを実行します。
このようなローリング更新は Updater のデフォルト動作であり、通常のデプロイにおいて非常にうまく機能します。ただし、マネージド インスタンス グループが非常に大規模な場合は、一度に 1 インスタンスずつの更新には多くの時間がかかります。そこで次に、基本的には同じやり方ですが、一度に全体の 4 分の 1 のインスタンスを更新してみましょう。
max-unavailable という新しいパラメータを使っていることに注目してください。このパラメータは、同時にオフライン状態にできるインスタンスの数を Updater に指示します。インスタンス数が数十、数百、数千のいずれであれ、インスタンスの更新は指定された割合で進みます。
それなら、同時にすべてのインスタンスを更新できるのではないかと思われるかもしれません。答えはイエスです。max-unavailable に 100 % を指定すれば、マネージド インスタンス グループは全インスタンスをまとめて更新します。テスト環境やバッチ処理システムのように、安定したアップタイムの維持が必要とされない場合は、これがとても役に立ちます。
カナリア テスト
次は、もっと高度なユース ケースについて考えてみましょう。全面的な更新に踏み切る前に、インスタンスのサブセットに新ソフトウェアをデプロイすることはカナリア テストと呼ばれ、堅牢で可用性の高いシステムを構築するうえでベスト プラクティスとされています。これにより、新ソフトウェアの影響を最小限に抑えつつ、実際の環境で新ソフトウェアをテストできます。前述の「単純な更新」と同じ例のもとで、1 つのインスタンスだけに myapp-version-b をデプロイしてみましょう。
my-instance-group は、myapp-version-a のインスタンスを 1 つ削除し、myapp-version-b のインスタンスを 1 つ作成します。それ以上の更新は行いません。
インスタンス グループのスケーリングが必要になった場合は、myapp-version-b の 1 インスタンスを残してテストを続けつつ、スケーリングを行います。その後、myapp-version-b をもっと大きなグループ（ここでは全体の半分）にデプロイできる状態になったら、次のようにします。
my-instance-group は、両者が半々（50 % ずつ）になるまで myapp-version-a インスタンスを myapp-version-b インスタンスに置き換えていきます。自動スケーリング機能によってインスタンスを増減させるときも、my-instance-group はこの割合を保ち、設定された水準でのカナリア デプロイを維持します。
完全に移行できる状態になったら、全インスタンスで myapp-version-b を実行するよう Updater に指示します。これは、「単純な更新」のときと同じ処理です。
全インスタンスの再作成
新しいテンプレートを使わず、現在のテンプレートを使い続けながら全インスタンスを置き換えたい場合もあるでしょう。これは、イメージ ファミリーを使っていて、インスタンス全体にイメージの最新バージョンを使わせたいときによく見られるパターンです。全インスタンスのローリング置換の開始は、ローリング更新の開始と同じパターンを踏襲しています。
ここでは、オフラインにしてもよいインスタンスの割合を指定するために、「単純な更新」のときと同じ max-unavailable パラメータを使っていることに注意してください。
次のステップ
今回説明した 3 つのユース ケースは Managed Instance Group Updaterの最も一般的な使用例ですが、このツール全体から見れば、ほんの一部の機能を紹介したに過ぎません。max-unavailable や max-surge などによる柔軟な制御、カナリア更新のサポート、start-update、restart、recreate といった豊富なコマンドにより、さまざまな形でマネージド インスタンス グループを管理できるようになりました。
詳細はこちらのドキュメントをご覧ください。また、質問やフィードバックは GCE ディスカッション グループまでお寄せください。
Managed Instance Group Updater の試用は Cloud Console から可能です。Google Cloud Platform（GCP）をまだお使いでない方は、こちらからサインアップしていただければ、Compute Engine と Updater を試せる 300 ドル分のクレジットを自動的に入手できます。
* この投稿は米国時間 9 月 6 日、Product Manager である Pawel Siarkiewicz によって投稿されたもの（投稿はこちら）の抄訳です。
- By Pawel Siarkiewicz, Product Manager
