インメモリ ボリューム（サービス）

このページでは、ファイルの読み取りと書き込みに使用できる専用のインメモリ ボリュームを構成する方法について説明します。

Cloud Run が提供する組み込みのインメモリ ファイル システムでは、インメモリ ファイルの書き込みで消費されるメモリは制限されませんが、この機能は異なります。インメモリ ボリュームを使用すると、消費されるメモリ量を制限できます。

動作

Cloud Run サービスのインメモリ ボリュームを構成すると、起動した Cloud Run インスタンスごとに空のボリュームが作成されます。このボリュームは、そのインスタンスが実行されている限り存続します。インスタンスの実行が停止すると、ボリューム内のデータは完全に削除されます。

インメモリ ボリュームの上限を指定した場合、ボリュームへの書き込みでその上限を超えると、メモリ不足エラーが発生しますが、このエラーは対応可能で、インスタンスの実行が継続されます。ボリューム サイズの上限を指定していない場合、ボリュームへの書き込みでインスタンスのメモリ上限を超えると、インスタンスはクラッシュします。

ボリュームの所有権は実行環境とデプロイタイプによって異なる

ボリュームをマウントする場合、ファイルとディレクトリを所有する ID は、ワークロードの実行環境や、デプロイが 1 つまたは複数のコンテナで構成されているかどうかによって異なります。

単一のコンテナをデプロイする第 1 世代の実行環境の場合、コンテナに使用されている ID がボリュームを所有します。それ以外の場合はすべて、root がボリュームを所有します。以下に例を示します。

  • 複数のコンテナをデプロイする第 1 世代の実行環境
  • 第 2 世代の環境

ユースケース

インメモリ ボリュームは、クラッシュを防ぐためのスクラッチ スペースの割り当てや長い計算のチェックポイントなどのユースケースで使用されます。

インメモリ ボリュームを構成する

構成を変更すると、新しいリビジョンが作成されます。明示的に更新しない限り、以降のリビジョンでも、この構成が自動的に設定されます。

ボリュームのメモリサイズ上限を指定すると、そのボリュームにアクセスするインスタンス内のすべてのコンテナが個別に使用するメモリからメモリが割り当てられます。インメモリ ボリュームに、インスタンス内のコンテナが使用しているすべてのメモリの合計よりも大きいサイズを指定した場合、ボリュームは、デフォルトでコンテナが使用する合計サイズになります。

ボリュームにメモリサイズの上限を指定しない場合、インスタンスのメモリ上限を超過すると、インスタンスがクラッシュする可能性があります。

メモリサイズの上限を指定せずにマルチコンテナ デプロイでインメモリ ボリュームを共有ボリュームとして使用する場合、使用可能なインスタンスの合計メモリの半分が共有ボリュームに割り当てられます。たとえば、emptyDir ボリューム サイズ = [メモリ（コンテナ A） + メモリ（コンテナ B） + メモリ（コンテナ N）] ÷ 2 となります。

コンソール

  1. Cloud Run に移動します。

  2. 構成するサービスをクリックします。

  3. [YAML] タブをクリックします。

  4. 次に示すように、volumeMounts 属性と volumes 属性を構成します。

    apiVersion: serving.knative.dev/v1
  kind: Service
  metadata:
  annotations:
    run.googleapis.com/launch-stage: BETA
    name: SERVICE
  spec:
    template:
      metadata:
      spec:
        containers:
        - image: IMAGE_URL
          volumeMounts:
          - mountPath: PATH
            name: VOLUME_NAME
        volumes:
        - name: VOLUME_NAME
          emptyDir:
            sizeLimit: SIZE_LIMIT
            medium: Memory

    次のように置き換えます。

    • SERVICE は、Cloud Run サービスの名前に置き換えます。
    • IMAGE_URL: コンテナ イメージへの参照（us-docker.pkg.dev/cloudrun/container/hello:latest など）。Artifact Registry を使用する場合は、リポジトリ REPO_NAME がすでに作成されている必要があります。URL の形式は REGION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG です。
    • PATH は、ボリュームの相対パス（例: /cache）に置き換えます。
    • VOLUME_NAME は、インメモリ ボリュームの名前に置き換えます。
    • SIZE_LIMIT は、ボリュームに割り当てるメモリ上限を MiB または GiB 単位（Mi または Gi などで指定）に置き換えます（例: 500Mi）。この上限は、コンテナに指定された合計メモリより小さくする必要があります。

  5. [新しいリビジョンを保存してデプロイする] をクリックします。

YAML

既存のサービス構成をダウンロードして表示するには、gcloud run services describe --format export コマンドを使用します。読みやすく整えられた結果が YAML 形式で出力されます。次に、下記の手順でフィールドを変更し、gcloud run services replace コマンドを使用して変更後の YAML ファイルをアップロードします。必ず説明されているとおりにフィールドを変更してください。

  1. 次のコマンドで、構成を表示してダウンロードします。

    gcloud run services describe SERVICE --format export > service.yaml

  2. 次に示すように、volumeMounts 属性と volumes 属性を構成します。

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
 annotations:
  run.googleapis.com/launch-stage: BETA
  name: SERVICE
spec:
  template:
    metadata:
    spec:
      containers:
      - image: IMAGE_URL
        volumeMounts:
        - mountPath: PATH
          name: VOLUME_NAME
      volumes:
      - name: VOLUME_NAME
        emptyDir:
          sizeLimit: SIZE_LIMIT
          medium: Memory

    次のように置き換えます。

    • SERVICE は、Cloud Run サービスの名前に置き換えます。
    • IMAGE_URL: コンテナ イメージへの参照（us-docker.pkg.dev/cloudrun/container/hello:latest など）。Artifact Registry を使用する場合は、リポジトリ REPO_NAME がすでに作成されている必要があります。URL の形式は REGION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG です。
    • PATH は、ボリュームの相対パス（例: /cache）に置き換えます。
    • VOLUME_NAME は、インメモリ ボリュームの名前に置き換えます。
    • SIZE_LIMIT は、ボリュームに割り当てるメモリ上限を MiB または GiB 単位（Mi または Gi などで指定）に置き換えます（例: 500Mi）。この上限は、コンテナに指定された合計メモリより小さくする必要があります。

  3. 次のコマンドを使用して、サービスを新しい構成に置き換えます。

    gcloud run services replace service.yaml