Google Compute Engineには「Live Migration」というユニークな技術が用意されており、ソフトウェアやハードウェアのアップデートなどでホストにダウンタイムが発生する場合でも、インスタンスを稼働させ続けることができます。稼働中のインスタンスを再起動させる代わりに、同じネットワークゾーン内の別の物理ホストへ移行させる仕組みです。
Live Migrationにより、Googleはインフラの保護と信頼性確保に欠かせないメンテナンスを、ユーザーのインスタンスを止めることなく実施できます。非常に優れた機能で、Googleは次のように説明しています。
「インスタンスのパフォーマンスが一時的に低下する可能性はあるものの、通常、ほとんどのインスタンスでは違いを感じることはありません。」
当然ながら、この主張を検証してみたくなりました ;-) 幸い、_gcloud_コマンドラインツールまたはAPI呼び出しを使えば、インスタンスのメンテナンスイベントを簡単にシミュレートできます。
gcloud beta compute instances simulate-maintenance-event [INSTANCE_NAME] \ --zone [ZONE]ORPOST https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instances/[INSTANCE_NAME]/simulateMaintenanceEventより実環境に近い条件で検証するため、テスト用インスタンスに負荷をかけた状態でLive Migrationイベントを発生させ、挙動を確認することにしました。
Cloud Launcherを使い、nginx（Bitnami製）を動かすn1-standard-1マシンを作成。負荷生成には、Goで書かれた開発者向けのオープンソース負荷テストツールK6を採用しました。結果はInfluxDBに保存し、Grafanaで可視化しています。
使用したスクリプトは次のとおりです。
K6は次のコマンドで実行し、負荷生成を開始しました。
k6 run — out influxdb=http://x.x.x.x:8086/myk6db — vus 50 — duration 10m — rps 6000 test.js開始から約60秒後に、メンテナンスイベントのシミュレーションを実行しました。
ご覧のとおり、約2秒間は応答時間が大幅に上昇し、その間インスタンスはリクエストを処理していません。ただしエラーは発生せず、移行中もクライアントへのレスポンスは継続されました。
同じテストをより大きなインスタンス（n1-standard-4）でも実施しました。
さらに、より大型のインスタンスで毎秒10,000リクエスト（これまでのテストでは6,000）をさばくテストも行いました。
グラフから読み取れるとおり、workloadsやインスタンスタイプが変わっても挙動は一貫しています。Live Migration中はおよそ2秒ほどインスタンスが応答しなくなりますが、コネクションが切れることはなく、今回のテストではエラーも一切観測されませんでした。
Live Migrationはパブリッククラウドにおける独自性の高い優れた機能で、Google Compute Engineでインスタンスを作成する際にはデフォルトで有効になっています。本記事の手順を使えば、Live Migration時にご自身のアプリがどう振る舞うかを実際に確認できます。
他の記事もぜひブログでご覧ください。AvivのTwitterのフォローもおすすめです。