Google Cloud

Compute Engine インスタンスの起動を高速化する 3 つのステップ

2017年8月9日

Google Cloud Japan Team

Google Cloud Platform（GCP）の美点の 1 つは、何百万ものリクエストに対応して難なくスケーリングできることです。Compute Engine を使用すれば、インスタンスグループや負荷分散のような技術により、いとも簡単にスケーリングを行えます。ただし、VM ベースのアプリケーションでは、利用の急増に合わせてスケーリングを行うときにインスタンスの起動時間が問題となることがあります。

起動時間のせいでアプリケーションにトラブルが発生するのを避けるため、この投稿では 3 つのシンプルなステップを紹介します。これらのステップを踏めば、起動プロセスのどの部分が最も時間がかかるのか、どうすれば起動時間を短縮できるのかという問いの答えを見つけることができます。

どこに時間がかかるのか

起動時のパフォーマンスを最適化するうえで最も重要な最初のステップの 1 つは、起動の各段階について包括的なプロファイリングを行うことです。これにより、Compute Engine がインスタンスの作成に費やしている時間と、コードの実行にかかっている時間がわかります。

Google の正式なドキュメントでは、起動プロセスをプロビジョニング（provisioning）、ステージング（staging）、実行（running）の 3 段階に分けています。ですが、リクエスト（request）、プロビジョニング（provisioning）、ブート（booting）の 3 段階に分けてパフォーマンステストを行うほうが簡単です。各段階にかかる時間を外部（具体的には Cloud Shell）から測定できるからです。

リクエスト : VM を要求してから、Create Instance API からの「VM の要求を受けた」との応答を得るまでの時間です。この段階は、インスタンスを挿入する REST コマンドに GCP が応答する時間を測定することで直接プロファイリングできます。
プロビジョニング : Compute Engine が、要求された VM のスペースをアーキテクチャ上で見つけるのにかかる時間です。このスペースは、Get Instance API を定期的にポーリングすることで見つかります。見つかると、“status” フラグが “provisioning” から “running” に変わります。
ブート : スタートアップスクリプトなどのカスタムコードが実行され、インスタンスが利用可能になるまでの時間です。私の同僚で Google Cloud のデベロッパーアドボケートである Terry Ryan は、エンドポイントに繰り返しポーリングを行い、500、400、200 番台のステータスコードをそれぞれ受け取った場合の時間の違いを測定することで、この段階をプロファイリングすることを好みます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/rZyj8q6rj58zLVcwgk_bvrkhp-gvXKHMP70zLTi2lKKJ.max-700x700.PNG

リクエスト、プロビジョニング、ブートの各段階に要する時間の測定結果を示すグラフの例（測定回数 : 183 回）

スタートアップスクリプトのプロファイリング

予期せぬ状況を除けば、インスタンスの起動時間は通常、インスタンスがスタートアップスクリプトを実行するブート段階が全体の半分以上を占めています。そのため、どの段階がパフォーマンスのボトルネックになっているかを調べるうえでは、ブートスクリプトのプロファイリングを行うことが極めて有益です。

スタートアップスクリプトの実行時間を測定することは、一見するよりも少し厄介です。コードを非常に強力なツールシステム（Stackdriver Custom Metric API、statsd、brubeck など）に統合すれば、プロファイリングやパフォーマンス監視に役立つかもしれません。しかし、スタートアップスクリプトにこうしたツールを適用すると、複雑なやり取りが行われ、ブート時間のオーバーヘッドが発生することがあります。それがプロファイリング結果をゆがめるおそれがあり、そうなればテストが無意味になってしまいます。

気の利いたプロファイリングの 1 つのやり方は、スタートアップスクリプトの各セクションを SECONDS コマンドでラップして（Linux ビルドの場合）、各セクションにかかった時間をファイルに追記し、要求に応じてそのファイルを提供するように新しいエンドポイントをセットアップすることです。

こうすることで、外部の場所からエンドポイントをポーリングしてデータを得ることができ、大がかりな開発やサービスに対する変更は必要なくなります。また、スクリプトのどのセクションがブート時間の中で最も大きな割合を占めているかもわかります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/HYf_GoRISUMMfseG1u6l0VmbNsQVzs4k7wFghDtoDi.max-1100x1100.PNG

Linux スタートアップスクリプトの各セクションに要する時間の測定結果を示すグラフの例

カスタムイメージへの移行

ほとんどの開発者にとって、スタートアップスクリプトの中で最も実行時間が長いのは、サービスを適切に稼働させるためのパッケージの取得とアプリケーションのインストールです。これは、インスタンスの多くが公開イメージ（OS とブートローダの事前設定済みの組み合わせ）で作成されるためです。

これらのイメージは、迅速に立ち上げて運用したいときに重宝します。ですが、本番レベルのシステムを構築し始めると、ブート時間で大きな割合を占めるのは OS の起動ではなく、ユーザーが実行するスタートアップシーケンスで行われる、パッケージおよびバイナリの取得と初期化だということがわかります。

この問題には、インスタンスのカスタムイメージを作成することで対処できます。カスタムイメージを作成するには、ホストのディスク情報（起動およびインストール後）のスナップショットを作成し、配布場所に保存します。後でターゲットインスタンスが起動されると、このイメージ情報がハードドライブにコピーされます。これは、ルート永続ディスクを作成して特定の状態に変更し、その状態を保存して新規インスタンスで再利用したい場合に理想的です。また、大規模ライブラリやソフトウェア群のインストール（やコンパイル）がお客様のセットアップに多く含まれる場合にも適しています。