高速なアプリケーション起動と自動スケーリングのための GKE イメージ ストリーミングの導入

※この投稿は米国時間 2021 年 11 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Kubernetes Engine（GKE）の新機能であるイメージ ストリーミングが一般提供されることを発表いたします。この革新的な GKE 機能には、アプリケーション スケールアップ時間を劇的に改善させる可能性があり、これを利用するとユーザーからの要求の増加に対してより迅速に応答し、予備容量のプロビジョニングを減らして費用を削減できます。これを可能にするのは、コンテナのイメージ pull 時間を数分（大きなイメージの場合）から（コンテナサイズを問わず）わずか 2～3 秒に削減する能力です。こうしてアプリケーションは直ちに起動でき、その間、GKE がコンテナデータを並行してストリーミングします。

アプリケーションをスケールアップする際、従来の Kubernetes の方法では、アプリケーションが起動するにはその前にコンテナ イメージ全体がノードにダウンロードされる必要があります。コンテナ イメージが大きくなるほど、これには時間がかかります。しかし実際には、起動のためにコンテナ イメージの全データの全バイトを必要とするアプリケーションはごく少数です（そして一度も使われないデータがコンテナに含まれる場合もあります）。たとえば、コンテナ イメージのデータがほとんど必要とされないにもかかわらず、アプリケーションが外部データベースとの接続にかなりの時間を費やす場合があります。イメージ ストリーミングの導入に向けて Google ではこう自問しました。余分なデータがすべて最初にダウンロードされるのを待つよりも、アプリケーションに実際に必要なデータだけを必要な時点で提供できるようにしたらどうだろう？

イメージ ストリーミングの仕組みはこうです。洗練されたネットワーク マウントを使用して containerd でコンテナ データレイヤをマウントし、ネットワーク上、メモリ内、およびディスク上の複数のキャッシュ レイヤでそれを補強します。イメージ ストリーミング マウントの準備が完了すると、（コンテナサイズを問わず）2～3 秒でコンテナのステータスが [ImagePulling] から [Running] に変化します。こうして、コンテナ イメージに必要なデータの転送とアプリケーションの起動とが実質的に同時に行われます。結果として、従来よりもかなり高速なコンテナ起動と機敏な自動スケーリングが行われることになります。

イメージ ストリーミングのパフォーマンスはアプリケーションのプロファイルに大きく左右されます。とはいえ一般的に、イメージが大きいほど大きな効果が得られるでしょう。Google Cloud パートナーの Databricks 社では、ノード起動時間を含むアプリケーション コールド スタート時間が全体的に劇的に短縮されました。

「GKE のイメージ ストリーミングのおかげでアプリケーション起動時間が 3 倍も改善されました。結果としてお客様のワークロードがより迅速に実行され、お客様はスタンバイ容量を減らすことでコスト低減を達成しています。」- Databricks 社シニア エンジニアリング マネージャー Ihor Leshko 氏

並行的なデータ供給に加えて、GKE イメージ ストリーミングでは複数レベルのキャッシング システムを実装しています。まずノード上のメモリ内およびディスク上のキャッシュから始まり、次にリージョンで複製される Artifact Registry キャッシュに移ります。後者は、Cloud Spanner と同じテクノロジーを内部的に使用する、イメージ ストリーミングに特化したキャッシュです。

コンテナ化されたアプリケーションの観点からは、イメージ ストリーミングは完全に透過的です。コンテナが読み取るデータはディスクではなくネットワークから最初にストリーミングされるので、イメージ ストリーミングの場合、イメージ全体をディスクに置くよりも正味の読み取りパフォーマンスがわずかに低速になります。しかし並行的な設計のおかげで、この劣化を補って余りある効果がコンテナ起動時に見られます。つまり、コンテナはイメージ全体を pull する長々しいプロセスをスキップして有利なスタートを切ることができるのです。一方、アプリケーションの稼働開始後に同等の読み取りパフォーマンスを達成できるように、GKE は従来とまったく同じ方法でコンテナ イメージ全体を並行的にダウンロードします。言い換えると、GKE がコンテナ イメージをダウンロードしている間はイメージ ストリーミングの並行機能が役立ちます。ダウンロードが完了した後は、以前と同じディスク読み取りパフォーマンスが得られ、両方の長所が発揮されます。

GKE イメージ ストリーミングを使い始める

本日より、GKE の Standard オペレーション モードをご利用のユーザーはイメージ ストリーミングを追加コストなしでご利用になれます（Artifact Registry（コンテナ イメージその他のアーティファクト向けの高度な Google Cloud レジストリ）にあるイメージを使用する場合）。Container Registry および外部コンテナ レジストリにあるイメージは、イメージ ストリーミングによる最適化に対応していません（これらのイメージはイメージ ストリーミングを使用せずに引き続き機能します）。したがって、Artifact Registry への移行がまだお済みでない場合は今が大きなチャンスです。

新規と既存のどちらの GKE クラスタでもイメージ ストリーミングを使用できます。必ず Container Filesystem API を有効にして、COS containerd ノードイメージ バリアントを使用し、Artifact Registry でホストされるコンテナ イメージを参照する必要があります。UI 操作では、単にクラスタ作成ページで [イメージ ストリーミングを有効にする] チェックボックスをオンにするだけです。

あるいは、CLI からも次のようにイメージ ストリーミング クラスタを作成できます。

さらに、既存のクラスタをアップグレードしてイメージ ストリーミングを有効にすることもできます。そうするには UI を使用するか、以下を実行します。

その後、Artifact Registry にあるイメージを参照してワークロードをデプロイします。すべてが正常に機能すれば、コンテナのステータスが [ContainerCreating] になった後、1 秒ほどで [Running] と表示されるはずです。

イメージ ストリーミングが正常に有効化されたことを検証するには、以下を実行します。

上記の出力例にある ImageStreaming イベントは、このイメージ pull でイメージ ストリーミングが有効になったことを示しています。

イメージ ストリーミングは、イメージ全体がディスクにダウンロードされる時点までに限り使用されるので、効果を完全に確かめるには新規ノードでこれをテストする必要があります。重要な点を復習すると、イメージ ストリーミングを使用するには、API を有効にすること、クラスタでイメージ ストリーミングをオンにすること、COS containerd イメージを使用すること、Artifact Registry にあるイメージを参照することが必要です。イメージ ストリーミングでは、キャッシュ保存システムを提供する目的でノード上に追加的なメモリ予約が発生します。このため、これらのノードではワークロードに使用できるメモリが減ります。テストやデバッグに関する情報を含む詳細情報については、イメージ ストリーミングのドキュメントを参照してください。さまざまな機能について学ぶには、11 月 18 日のライブイベント「クラウド ネイティブ アプリを構築/実行するための Kubernetes のヒントと手法」への参加をご登録ください。

- GKE: Google Kubernetes Engine プロダクト マネージャー William Denniss