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 と永続ディスクに代わる新しい 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 イメージ ストリーミングの制限事項が適用されます。