Cloud Workstations のアーキテクチャ

Cloud Workstations は、Compute Engine VM永続ディスク(PD)などの Google Cloud リソースを管理し、可視性を高め、プロジェクトのリソース制御を提供します。 たとえば、すべてのワークステーションの PD にバックアップ ポリシーを適用する、スケジュール設定されたディスク スナップショット ポリシーを設定できます。同様に、プロジェクト内に VM を配置することで、VPC ネットワーク内のリソースにシームレスにアクセスして管理できます。

次の図は、Cloud Workstations のアーキテクチャを示しています。

アーキテクチャの図

図 1.
Cloud Workstations のアーキテクチャ

ワークステーション クラスタ

ワークステーション クラスタは、プロジェクト内の単一のクラウド リージョンVPC ネットワーク内のワークステーションの集合を格納し、管理します。各ワークステーション クラスタには、Google Cloud で管理される 2 つのコンポーネント(コントローラとゲートウェイ)があります。

  • コントローラ: プロジェクト内の VM インスタンスやその他のワークステーション リソースのライフサイクルを管理します。

    コントローラは、Compute Engine API を使用してリソースのライフサイクルを管理し、Private Service Connect を使用してワークステーションの VM にトラフィックをルーティングします。

  • ゲートウェイ: 特定のワークステーションにバインドされたクライアントからトラフィックを受信し、適切な VM インスタンスにトラフィックを転送します。各ワークステーション クラスタには一意のドメイン名があり、各ワークステーションにはワークステーション クラスタのドメインのサブドメイン($WORKSTATION_ID.$CLUSTER_ID.cloudworkstations.dev など)でアクセスできます。

ワークステーション クラスタのその他の機能は次のとおりです。

  • 管理者チームとプラットフォーム チームは、ワークステーション クラスタを作成して、特定のリージョンにあるワークステーションのグループと、接続先の VPC ネットワークを定義します。

  • ワークステーション クラスタは、Google Kubernetes Engine(GKE)クラスタとは関係ありません。

  • 各ワークステーション クラスタには、ワークステーションが Private Service Connect を備えた VPC に接続される専用コントローラがあります(これは VPC のピアリング上限には影響しません)。このコントローラは、ライフサイクル全体を通じてワークステーション リソースを管理し、パブリック クラスタ ゲートウェイを介してワークステーションへの下り(外向き)ネットワークと上り(内向き)ネットワークを提供します。

  • 各クラウド リージョンには少なくとも 1 つのワークステーション クラスタが必要です。

  • また、完全なプライベート ゲートウェイを有効にして、プライベート ネットワーク内のエンドポイントのみが Cloud Workstations にアクセスできるようにすることもできます。

VPC ネットワーク

ワークステーション クラスタを作成するときに、リソースをホストするプロジェクトと VPC ネットワークを指定します。Cloud Workstations は、次のリソースをプロジェクトにプロビジョニングします。

  • Private Service Connect: Cloud Workstations コントローラと VPC の間の接続を確立し、プロジェクト内でリソースを作成できるようにします。

  • VM インスタンス: ワークステーションの起動後に、Compute Engine VM がプロジェクトと VPC 内に動的に作成されます。この VM は、ユーザー セッションの終了時または構成可能なセッション タイムアウト後に自動的に削除されます。

    • VM ゲートウェイ: ワークステーション クラスタ ゲートウェイからクライアント トラフィックを pull し、認証および承認して、コンテナに転送します。

    • コンテナ: IDE やコードエディタなどのワークステーションにプリインストールされているツールと、ワークステーション構成で指定されているその他のプログラムや設定を定義します。

      Cloud Workstations には、一般的な IDE と言語ツールで事前に構成されたベースイメージがいくつか用意されています。また、管理者とプラットフォーム チームは、デベロッパーのニーズに対応するツールを含むカスタム コンテナ イメージを作成して、環境をカスタマイズできます。これらのコンテナ イメージは、Cloud Workstations ベースイメージを拡張することも、プラットフォーム チームによって作成された新しいカスタム Linux コンテナ イメージにすることもできます。

  • Persistent Disk: /home フォルダにマウントされたワークステーション VM に接続された永続ディスク。セッションの終了後にデータとファイルを保存できます。

リソースのライフサイクル

Cloud Workstations は、各ワークステーションのランタイム環境として使用する VM、コンテナ イメージ、永続ディスクを管理します。ワークステーション構成内で、これらのリソースの仕様を構成します。

ワークステーションが開始されると、Cloud Workstations は次の処理を行います。

  1. VM を作成します。
  2. ワークステーション コンテナ イメージを VM に pull します。
  3. ワークステーションを初めて開始したときに、ワークステーションの /home ディレクトリとして機能する永続ディスクが作成されます。
  4. 永続ディスクを VM に接続します。
  5. VM 上のコンテナを起動し、コンテナの /home ディレクトリに永続ディスクをマウントします。

セッションが終了すると、Cloud Workstations によって VM が削除されますが、永続ディスクは接続解除されて保持されます。これにより、将来のワークステーション セッションで使用できます。ワークステーション サービスは、ワークステーションが削除されるまでディスクを保持します。ワークステーションが削除されると、必要に応じて保持するように構成されていない限り、永続ディスクも削除されます。

リソースプール

管理者とプラットフォーム チームは、必要に応じて、poolSize ワークステーション構成オプションを使用して VM と永続ディスクをプールして、ワークステーションの起動を高速化できます。指定すると、サービスは指定された数の永続ディスクと VM をプールし、ワークステーションの割り当て前にコンテナ イメージを VM に事前 pull します。プール内の未割り当ての VM とディスクは 12 時間ごとに自動的に削除され再作成されます。これにより、VM を作成し、VM にコンテナ イメージを pull するための待機時間を削除することで、ワークステーションの起動時間を短縮できます。

プールが有効になっている場合、Cloud Workstations はワークステーションを起動するときに次の処理を行います。

  1. コンテナ イメージを事前 pull している VM をプールから選択します。
  2. ワークステーションを初めて開始したときに、プールから永続ディスクを選択します。
  3. 永続ディスクを VM に接続します。
  4. VM 上のコンテナ イメージを起動し、コンテナ イメージの /home ディレクトリに永続ディスクをマウントします。
  5. 新しい VM と永続ディスクを作成し、割り当てられたディスクを置き換えて、プールを補充します。

セッションが終了すると、Cloud Workstations によって VM が削除されますが、永続ディスクは接続解除されて保持されます。これにより、将来のワークステーション セッションで使用できます。ワークステーション サービスは、ワークステーションが削除されるまでディスクを保持します。ワークステーションが削除されると、必要に応じて保持するように構成されていない限り、永続ディスクも削除されます。

コンテナ イメージの更新

ワークステーション コンテナ イメージはプールされた VM に事前に pull されているため、同じイメージタグを使用してリモート イメージ リポジトリで行われたコンテナ イメージの更新は、プールされたすべての VM が割り当てられるか、12 時間後に削除されるまで取得されません。その時点で、プールを補充し更新されたコンテナ イメージを pull するための新しい VM が作成されます。

プールを強制的にリフレッシュしてコンテナ イメージの更新を即座に取得するには、管理者が pool_size0 に設定してから、それを目的の pool_size に戻します。Google Cloud コンソールからワークステーション構成のクイックスタート ワークステーション機能を無効化し、構成を保存して、目的の数に戻してから、もう一度保存します。

または、管理者とプラットフォーム チームがワークステーション構成の container.image フィールドのイメージタグを更新できます。これにより、新しいコンテナ イメージタグを取得するようにプールが強制的に更新されます。

イメージ ストリーミングでワークステーションの起動時間を短縮する

Cloud Workstations はイメージ ストリーミングをサポートしています。これにより、ワークステーション コンテナ イメージの pull 時間を短縮して、ワークステーションの起動時間を短縮できます。

Cloud Workstations のイメージ ストリーミングは通常、コンテナ イメージの pull 時間を数分から数秒に短縮します。通常、ワークステーション コンテナはイメージ全体のダウンロードを待たずに実行を開始します。

要件

Cloud Workstations でイメージ ストリーミングを使用するには、次の要件を満たす必要があります。

  • ワークステーションのホスト プロジェクトで Container File System API を有効にしている必要があります。

    Container File System API を有効にする

    または、次の gcloud CLI コマンドを実行して、ワークステーション ホスト プロジェクトで Container File System API を有効にすることもできます。

    gcloud services enable containerfilesystem.googleapis.com
    

  • コンテナ イメージは Artifact Registry に保存する必要があります。

  • Artifact Registry リポジトリは、Cloud Workstations リージョンと同じリージョンか、ワークステーションが実行されているリージョンに対応するマルチリージョンに存在する必要があります。

  • ワークステーション構成で使用するサービス アカウントを指定する必要があります。

  • クラスタが VPC Service Controls の境界内にある場合は、コンテナ イメージをホストするプロジェクトの Container File System API にサービス アカウントがアクセスできるようにする下り(外向き)ルールを追加する必要があります。事前構成された IDE を使用している場合は、cloud-workstations-images プロジェクト(プロジェクト番号 662288601415)を許可リストに追加する必要があります。

制限事項

  • 対象イメージを初めて pull する場合は、イメージ ストリーミングの利点に気づかない可能性があります。ただし、イメージ ストリーミングでイメージがキャッシュに保存された後は、ワークステーションでのイメージの pull でイメージ ストリーミングの利点を実感できます。

  • その他の GKE イメージ ストリーミングの制限が適用されます。