カスタムコンピューティングクラスについて

Autopilot Standard

このページでは、カスタムコンピューティングクラスを使用して、クラスタの自動スケーリング時に Google Kubernetes Engine（GKE）がプロビジョニングするノードのプロパティを制御する方法について説明します。このドキュメントは、特定のワークロードが要件を満たすハードウェアで実行されるように、ノードに対して自動スケーリングプロファイルを宣言的に定義するプラットフォーム管理者を対象としています。

コンピューティングクラスの概要

GKE のコンピューティングクラスは、GKE がワークロードを実行するノードのプロビジョニングに使用する一連のノード属性で構成されるプロファイルです。コンピューティングクラスでは、高パフォーマンスノードのプロビジョニングや、運用コストを削減するための費用最適化構成の優先付けなど、特定の最適化をターゲットに設定できます。カスタムコンピューティングクラスを使用すると、GKE が特定のワークロードの要件に厳密に一致するノードをプロビジョニングするためのプロファイルを定義できます。

カスタムコンピューティングクラスは、バージョン 1.30.3-gke.1451000 以降の GKE Autopilot モードと GKE Standard モードで使用できます。また、ノード属性と自動スケーリングの優先度を宣言的に定義できます。デフォルトでは、カスタムコンピューティングクラスは対象となるすべての GKE クラスタに構成し、使用できます。

カスタムコンピューティングクラスのメリット

カスタムコンピューティングクラスには、次のようなメリットがあります。

フォールバックコンピューティングの優先度: GKE が優先順位を判断できるように、各コンピューティングクラスでノードの構成の階層を定義できます。最も優先される構成が使用できない場合、GKE は階層内の次の構成を自動的に選択します。このフォールバックモデルにより、コンピューティングリソースが使用できない場合でも、ワークロードは最適化されたハードウェアで実行され、スケジューリングの遅延を最小限に抑えることができます。
きめ細かい自動スケーリング制御: 特定のワークロードに最適なノード構成を定義できます。GKE は、スケーリングでノードを作成するときに、これらの構成を優先します。
宣言型インフラストラクチャ構成: インフラストラクチャ管理に宣言型アプローチを採用し、GKE が特定のワークロード要件に一致するノードを自動的に作成できるようにします。
アクティブな移行: 優先されるマシン構成のコンピューティングリソースがロケーションで利用可能になると、GKE は優先構成を使用する新しいノードにワークロードを自動的に移行します。
費用の最適化: Spot VM などの費用対効果の高いノードタイプが優先されます。これにより、クラスタの費用を削減できます。
Namespace のデフォルトのコンピューティングクラス: 各 Kubernetes Namespace にデフォルトのコンピューティングクラスを設定し、特定のコンピューティングクラスをリクエストしない場合でも、その Namespace 内のワークロードが最適化されたハードウェアで実行されるようにします。
カスタムノードの統合しきい値: ノードにカスタムリソース使用率のしきい値を定義します。特定ノードのリソース使用量がしきい値を下回ると、GKE はワークロードを使用可能な類似のノードに統合し、使用率の低いノードをスケールダウンします。

カスタムコンピューティングクラスのユースケース

次のようなシナリオでは、カスタムコンピューティングクラスの使用を検討してください。

特定の GPU 構成で AI / ML ワークロードを実行する。
特定のチームが実行するワークロードのデフォルトのハードウェア構成を設定し、アプリケーションオペレーターのオーバーヘッドを軽減する。
特定の Compute Engine マシンシリーズまたはハードウェア構成で最適に動作するワークロードを実行する。
高パフォーマンス、費用の最適化、高可用性など、特定のビジネス要件を満たすハードウェア構成を宣言する必要がある。
コンピューティングリソースが使用できない場合に、GKE が特定のハードウェア構成を使用するように階層的にフォールバックし、ワークロードが常に要件に合ったマシンで実行されるようにする。
企業のフリート全体で最適な構成を一元的に決定し、コストを予測可能にすることで、ワークロードをより確実に実行できるようにする。

制限事項

Autopilot モードまたは自動プロビジョニングされた Standard モードのノードプールでは、Compute Engine の容量予約でカスタムコンピューティングクラスを使用できません。手動で作成された Standard モードのノードプールは、容量予約をサポートしています。

カスタムコンピューティングクラスの仕組み

カスタムコンピューティングクラスは、Google Cloud インフラストラクチャをプロビジョニングする Kubernetes カスタムリソースです。クラスタで ComputeClass オブジェクトを定義し、ワークロードでそのコンピューティングクラスをリクエストするか、そのコンピューティングクラスを Kubernetes Namespace のデフォルトとして設定します。コンピューティングクラスをリクエストするワークロードをデプロイすると、GKE はコンピューティングクラスの要件を満たすノードに Pod を配置しようとします。

カスタムコンピューティングクラスをフリート用に最適化するには、次のガイドラインを考慮してください。

アプリケーション固有のハードウェア要件など、フリートのコンピューティング要件を把握します。
各コンピューティングクラスの設計指針となるテーマを決めます。たとえば、パフォーマンスが最適化されたコンピューティングクラスには、高 CPU マシンタイプのみを使用するようにフォールバック戦略を計画します。
ワークロードに最も適した Compute Engine マシンファミリーとマシンシリーズを決定します。詳しくは、マシンファミリーのリソースと比較ガイドをご覧ください。
常に類似したマシン構成を使用するノードでワークロードが実行されるように、各コンピューティングクラス内でフォールバック戦略を計画します。たとえば、N4 マシンシリーズを使用できない場合は、N2 マシンにフォールバックします。

完全なカスタムリソース定義を表示する

ComputeClass カスタムリソースの完全なカスタムリソース定義（CRD）を表示するには、次のコマンドを実行します。

kubectl describe crd computeclasses.cloud.google.com

出力には、サポートされているすべてのフィールドとフィールド間の関係を含む CRD 全体が表示されます。カスタムコンピューティングクラスをより深く理解するため、このドキュメントを読む際には、この定義を参照してください。

カスタムコンピューティングクラスを計画する

クラスタでカスタムコンピューティングクラスを効果的に計画、デプロイ、使用するには、次の操作を行います。

フォールバックのコンピューティングの優先度を選択する: GKE がコンピューティングクラスに作成するノードのプロパティを管理するために、一連のルールを定義します。
GKE Standard ノードプールとコンピューティングクラスを構成する: Standard モードのクラスタの場合は、必要な構成手順に沿って、ノードプールでコンピューティングクラスを使用します。
優先度ルールが適用されない場合のスケーリング動作を定義する: 必要に応じて、優先度ルールを満たすノードをプロビジョニングできない場合の処理を GKE に指示します。
ノード統合用に自動スケーリングパラメータを設定する: ワークロードを統合し、使用効率の低いノードを削除するタイミングを GKE に指示します。
優先度の高いノードへのアクティブ移行を構成する: ハードウェアが利用可能になったときに、ワークロードを優先ノードに移動するよう GKE に指示します。

フォールバックのコンピューティングの優先度を選択する

カスタムコンピューティングクラスを使用する主な利点は、リソースの枯渇や割り当ての制限などの要因により、優先ノードが使用できない場合のフォールバック戦略を制御できることです。

フォールバック戦略は、カスタムコンピューティングクラスで優先度ルールのリストを定義して作成します。クラスタをスケールアップする必要がある場合、GKE は最初の優先度ルールに一致するノードの作成を優先します。GKE がこれらのノードを作成できない場合は、次の優先度ルールにフォールバックします。GKE がクラスタを正常にスケールアップするか、適用可能なルールがなくなるまで、このプロセスが繰り返されます。適用可能なルールがなくなると、GKE は、優先度ルールが適用されない場合のスケーリング動作を定義するで説明されているデフォルトの動作または指定された動作に基づいてノードを作成します。

優先度ルール

優先度ルールは、ComputeClass カスタムリソースの spec.priorities フィールドで定義します。priorities フィールドの各ルールには、プロビジョニングするノードのプロパティを記述します。GKE は priorities フィールドを順番に処理します。つまり、フィールド内の最初の項目がノードプロビジョニングの優先度が最も高くなります。

優先度ルールのタイプに応じて、ノードをプロビジョニングするときに GKE が使用する追加のマシンプロパティ（Spot VM や最小 CPU 容量など）を指定できます。priorities フィールドは、次の優先度ルールのタイプをサポートしています。

machineFamily: n2 や c3 などの Compute Engine マシンシリーズを使用してノードを定義します。
machineType: n2-standard-4 などの事前定義された Compute Engine マシンタイプを使用してノードを定義します。
nodepools: GKE Standard クラスタで、GKE がノードをプロビジョニングするコンピューティングクラスに関連付けられている、手動作成のノードプールのリストを提供します。

machineFamily ルールタイプ

machineFamily フィールドには、n2 や c3 などの Compute Engine マシンシリーズを指定します。指定しない場合は、デフォルトの e2 が使用されます。machineFamily ルールタイプとともに、次のフィールドを使用できます。

spot: Spot VM。デフォルト値は false です。
minCores: ノードあたりの最小 vCPU。デフォルト値は 0 です。
minMemoryGb: ノードあたりの最小メモリ。デフォルト値は 0 です。
storage.bootDiskKMSKey: ブートディスクの暗号化に使用する Cloud Key Management Service 鍵のパス。

次の例は、machineFamily 優先度ルールを示しています。

priorities:
- machineFamily: n2
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1

machineType ルールタイプ

machineType フィールドには、Compute Engine の事前定義されたマシンタイプを指定します（n2-standard-32 など）。マシンタイプは、指定した GPU をサポートしている必要があります。

machineType ルールタイプとともに、次のフィールドを使用できます。

spot: Spot VM を使用します。デフォルトは false です。
storage: ノードストレージを構成します。
- storage.bootDiskType: ブートディスクの種類。
- storage.bootDiskKMSKey: ブートディスクの暗号化に使用する Cloud KMS 鍵のパスと名前。
- storage.bootDiskSize: ノードブートディスクのサイズ（GB）。
- storage.localSSDCount: ノードに接続するローカル SSD の数。指定する場合は、1 以上にする必要があります。
gpu: GPU を構成します。
- gpu.type: GPU タイプ（nvidia-l4 など）。詳細については、Autopilot で GPU ワークロードをデプロイするをご覧ください。
- gpu.count: 接続する GPU の数。GPU タイプでサポートされている数については、サポートされている GPU 数をご覧ください。

次の例は、n2-standard-32 マシンタイプの machineType ルールを示しています。

priorities:
- machineType: n2-standard-32
  spot: true
  storage:
    bootDiskType: pd-balanced
    bootDiskSize: 250
    localSSDCount: 2
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1

次の例は、GPU の machineType ルールを示しています。

priorities:
- machineType: g2-standard-16
  spot: false
  gpu:
    type: nvidia-l4
    count: 1

nodepools ルールタイプ

nodepools フィールドには、GKE が保留中の Pod の作成を試みる既存のノードプールのリストを指定します。GKE は、このフィールドの値を順番に処理しません。同じ優先度ルールの項目で、このフィールドとともに他のマシンプロパティを指定することはできません。このフィールドは、GKE Standard モードでのみサポートされます。使用方法の詳細については、コンピューティングクラス定義で特定のノードプールをターゲットに設定するをご覧ください。

GKE が優先度ルールを使用してノードを作成する方法

コンピューティングクラスをリクエストするワークロードをデプロイして、新しいノードが必要になると、GKE は ComputeClass 仕様の priorities フィールドのルールリストを順番に処理します。

たとえば、次の仕様について考えてみましょう。

spec:
  ...
  priorities:
  - machineFamily: n2
    spot: true
    minCores: 64
  - machineFamily: n2
    spot: true
  - machineFamily: n2
    spot: false

この優先度ルールに従ってコンピューティングクラスをリクエストするワークロードをデプロイすると、GKE は次のようにノードを照合します。

GKE は、このコンピューティングクラスに関連付けられている既存のノードに Pod を配置します。
既存のノードに Pod を収容できない場合、GKE は N2 マシンシリーズを使用する新しいノードをプロビジョニングします。このノードは Spot VM で、64 vCPU 以上です。
リージョンで 64 個以上の vCPU を備えた N2 Spot VM が使用できない場合、GKE はコア数に関係なく、Pod に適合する N2 Spot VM を使用する新しいノードをプロビジョニングします。
リージョンで使用可能な N2 Spot VM がない場合、GKE は新しいオンデマンド N2 VM をプロビジョニングします。
上記のルールを満たすことができない場合、GKE は優先度ルールが適用されない場合のスケーリング動作を定義するのロジックを適用します。

GKE Standard ノードプールとコンピューティングクラス

GKE Standard モードを使用する場合は、コンピューティングクラス Pod が想定どおりにスケジュールされるように、手動構成が必要になることがあります。

ノードの自動プロビジョニングによって管理されるノードプール: 手動構成は必要ありません。ノードの自動プロビジョニングでは、コンピューティングクラスの構成手順が自動的に実行されます。詳細については、ノードの自動プロビジョニングとコンピューティングクラスをご覧ください。
手動で作成したノードプール: 手動での構成が必要です。手動で作成したノードプールにノードラベルとノード taint を追加し、ノードを特定のコンピューティングクラスに関連付ける必要があります。詳細については、コンピューティングクラスで使用するために手動で作成したノードプールを構成するをご覧ください。

コンピューティングクラスで使用するために手動で作成したノードプールを構成する

GKE Standard クラスタに、ノードの自動プロビジョニングなしで手動で作成したノードプールがある場合は、特定のコンピューティングクラスに関連付けるように、これらのノードプールを構成する必要があります。GKE は、特定のコンピューティングクラスをリクエストする Pod のみを、そのコンピューティングクラスに関連付けられたノードプールのノードでスケジューリングします。ノードの自動プロビジョニングによって作成された GKE Autopilot モードと GKE Standard モードのノードプールは、この構成を自動的に実行します。

手動で作成したノードプールをコンピューティングクラスに関連付けるには、作成時または更新時に、次のように --node-labels フラグと --node-taints フラグを指定して、ノードプールにノードラベルとノード Taint を追加します。

ノードラベル: cloud.google.com/compute-class=COMPUTE_CLASS
Taint: cloud.google.com/compute-class=COMPUTE_CLASS:NoSchedule

これらの属性で、COMPUTE_CLASS はカスタムコンピューティングクラスの名前です。

たとえば、次のコマンドは既存のノードプールを更新し、dev-class コンピューティングクラスに関連付けます。

gcloud container node-pools update dev-pool \
    --cluster=example-cluster \
    --node-labels="cloud.google.com/compute-class=dev-class" \
    --node-taints="cloud.google.com/compute-class=dev-class:NoSchedule"

クラスタ内の各ノードプールを 1 つのカスタムコンピューティングクラスに関連付けることができます。手動で作成されたノードプールで GKE がスケジュールする Pod は、自動スケーリングイベント中にのみ、そのノードプール内でノードの作成をトリガーします。

ノードの自動プロビジョニングとコンピューティングクラス

カスタムコンピューティングクラスでノードの自動プロビジョニングを使用すると、優先度ルールに基づいてノードプールを自動的に作成および削除できます。

コンピューティングクラスでノードの自動プロビジョニングを使用するには、次の操作を行う必要があります。

クラスタでノードの自動プロビジョニングが有効になっていることを確認します。
enabled: true 値を持つ nodePoolAutoCreation フィールドを ComputeClass 仕様に追加します。

これにより、GKE は、ノードの自動プロビジョニングを構成するコンピューティングクラスを使用する Pod を新しいノードプールに配置します。GKE は、クラスタのサイズや Pod の要件などの要素に基づいて、既存のノードプールをスケールアップするか、新しいノードプールを作成するかを決定します。ノードの自動プロビジョニングを構成していないコンピューティングクラスを持つ Pod は、引き続き既存のノードプールのみをスケールアップします。

ノードの自動プロビジョニングとやり取りするコンピューティングクラスと、同じクラスタ内の手動で作成されたノードプールとやり取りするコンピューティングクラスを併用できます。

ノードの自動プロビジョニングとの次のやり取りを検討してください。

マシンファミリーまたは Spot VM ノードセレクタは、コンピューティングクラスの動作と競合するため使用できません。GKE は、コンピューティングクラスをリクエストし、Spot VM または特定のマシンシリーズもリクエストする Pod を拒否します。
nodepools フィールドを使用して既存のノードプールを参照するコンピューティングクラスにノードの自動プロビジョニングを構成できます。ノードの自動プロビジョニングは、優先度順に処理し、既存のノードプールをスケールして Pod を配置しようとします。

手動で作成したノードプールがあり、ノードの自動プロビジョニングが設定されているクラスタについて考えてみましょう。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - nodepools: [manually-created-pool]
  - machineFamily: n2
  - machineFamily: n2d
  nodePoolAutoCreation:
    enabled: true

この例では、GKE は次の処理を試みます。

manually-created-pool ノードプールに新しいノードを作成します。
既存の N2 ノードプールまたは新しく作成したノードプールに N2 ノードをプロビジョニングします。
GKE が N2 ノードを作成できない場合、既存の N2D ノードプールのスケールアップを行うか、新しい N2D ノードプールを作成します。

コンピューティングクラスの定義で特定のノードプールをターゲットにする

priorities.nodepools フィールドを使用すると、クラスタの自動スケーリングを使用する GKE Standard クラスタで GKE が Pod のスケジューリングを試みる、手動作成のノードプールのリストを指定できます。このフィールドはノードプールのリストのみをサポートします。同じ優先度ルールのマシンシリーズなどの追加のマシンプロパティを指定することはできません。名前付きノードプールのあるコンピューティングクラスをリクエストするワークロードをデプロイすると、GKE は保留中の Pod をこれらのノードプールでスケジュールしようとします。GKE は、Pod を配置するために、これらのノードプールに新しいノードを作成する場合があります。

priorities.nodepools フィールドで指定するノードプールは、コンピューティングクラス用に手動で作成したノードプールを構成するに記載されているように、ノードラベルとノード taint を使用して、そのコンピューティングクラスに関連付ける必要があります。

nodepools フィールドで指定するノードプールのリストには優先順位がありません。名前付きノードプールのフォールバック順序を構成するには、複数の個別の priorities.nodepools 項目を指定する必要があります。たとえば、次の仕様について考えてみましょう。

spec:
  ...
  priorities:
  - nodepools: [pool1, pool2]
  - nodepools: [pool3]

この例では、GKE はまず、このコンピューティングクラスをリクエストする保留中の Pod を、コンピューティングクラスのラベルが付いたノードプールの既存のノードに配置しようとします。既存のノードが使用できない場合、GKE は pool1 または pool2 に新しいノードをプロビジョニングしようとします。GKE がこれらのノードプールで新しいノードをプロビジョニングできない場合、GKE は pool3 に新しい Pod をプロビジョニングしようとします。

優先度ルールが適用されない場合のスケーリングの動作を定義する

ComputeClass カスタムリソースを使用すると、優先度ルールの条件を満たすノードがない場合に GKE が行う処理を指定できます。仕様の whenUnsatisfiable フィールドは、次の値をサポートしています。

ScaleUpAnyway: クラスタのデフォルトのマシン構成を使用する新しいノードを作成します。これはデフォルトの動作です。
- Autopilot クラスタでは、GKE はノードのマシン構成に関係なく、新しいノードまたは既存のノードに Pod を配置します。
- ノードの自動プロビジョニングを使用しない Standard クラスタの場合、GKE は、特定のコンピューティングクラスに一致するラベルと taint が定義された手動作成のノードプールをスケールアップしようとします。
- ノードの自動プロビジョニングを使用する Standard クラスタの場合、GKE が新しいノードプールを作成し、デフォルトの E2 マシンシリーズを使用して Pod を配置することがあります。
DoNotScaleUp: コンピューティングクラスの要件を満たすノードが使用可能になるまで、Pod を Pending ステータスにします。

ノード統合の自動スケーリングパラメータを設定する

デフォルトでは、GKE はワークロードの実行で使用率の低いノードを削除し、容量のある他のノードにワークロードを統合します。コンピューティングクラスを使用するすべてのクラスタは、クラスタオートスケーラーを使用するか、Autopilot クラスタにする必要があるため、すべてのコンピューティングクラスでこれがデフォルトの動作になります。ノードの統合中、GKE は使用率の低いノードをドレインし、別のノードでワークロードを再作成してから、ドレインされたノードを削除します。

ノードの削除のタイミングと基準は、自動スケーリングプロファイルによって異なります。カスタムコンピューティングクラスの定義で autoscalingPolicy セクションを使用すると、ノードの削除とワークロードの統合をトリガーするリソース未使用率のしきい値を微調整できます。次のパラメータを微調整できます。

consolidationDelayMinutes: GKE が未使用ノードを削除するまでの時間（分）
consolidationThreshold: CPU とメモリの使用率のしきい値（ノードの使用可能なリソースの割合）。リソース使用率がこのしきい値を下回ると、GKE はノードの削除を検討します。
gpuConsolidationThreshold: GPU の使用率しきい値（ノードの使用可能なリソースの割合）。リソース使用率がこのしきい値を下回ると、GKE はノードの削除を検討します。割り当てられた GPU の使用率が 100% に達していないノードが統合されるように、この値を 100 または 0 に設定することを検討してください。

次の例を考えてみます。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n2
  - machineFamily: n2d
  autoscalingPolicy:
    consolidationDelayMinutes: 5
    consolidationThreshold: 70

この構成では、GKE は 5 分後に未使用ノードを削除します。ノードは、CPU とメモリの使用率の両方が 70% 未満の場合にのみ、統合の候補になります。

優先度の高いノードへのアクティブな移行を構成する

アクティブな移行は、カスタムコンピューティングクラスの自動スケーリング機能のオプションです。コンピューティングクラスのフォールバック優先度リストで優先度が低い既存のノードは、フォールバック優先度リストで優先度が高い新しいノードに自動的に置き換えられます。これにより、GKE が最初にそれらの Pod を優先度の低いノードで実行する必要がある場合でも、最終的には、実行中のすべての Pod がそのコンピューティングクラスの最も優先度の高いノードで実行されます。

アクティブな移行が発生すると、GKE はコンピューティングクラスの優先度ルールに基づいて新しいノードを作成し、優先度の低い古いノードをドレインして削除します。ワークロードの中断を最小限に抑えるため、移行は段階的に行われます。アクティブな移行には次の考慮事項があります。

Standard クラスタでノード自動プロビジョニングを有効にしている場合、既存のノードプールがカスタムコンピューティングクラスで定義された優先度の高い条件を満たしていないと、アクティブな移行により、新しいノードプールの作成がトリガーされることがあります。
重要なワークロードの中断を回避するため、アクティブな移行では次の Pod は移行されません。
- PodDisruptionBudget を設定している Pod（移行により PodDisruptionBudget を超える場合）。
- cluster-autoscaler.kubernetes.io/safe-to-evict: "false" アノテーションが設定されている Pod。

N2D ノードよりも N2 ノードを優先するコンピューティングクラス仕様の例について考えてみましょう。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n2
  - machineFamily: n2d
  activeMigration:
    optimizeRulePriority: true

このコンピューティングクラスを使用して Pod をデプロイしたときに N2 ノードが使用できなかった場合、GKE はフォールバックオプションとして N2D ノードを使用します。割り当てが増加した場合や、ロケーションで N2 VM が利用可能になった場合など、後で N2 ノードをプロビジョニングできるようになると、GKE は新しい N2 ノードを作成し、既存の N2D ノードから新しい N2 ノードに Pod を段階的に移行します。その後、GKE は古い N2D ノードを削除します。

ワークロードでコンピューティングクラスをリクエストする

カスタムコンピューティングクラスの設計が完了したら、Pod 仕様でそのコンピューティングクラスを明示的にリクエストする必要があります。特定の Kubernetes Namespace でコンピューティングクラスをデフォルトとして設定することもできます。この場合、Pod が別のコンピューティングクラスをリクエストしない限り、その Namespace 内の Pod は設定したコンピューティングクラスを使用します。

GKE でコンピューティングクラスをリクエストして使用する手順については、カスタムコンピューティングクラスを使用して自動スケーリングされたノード属性を制御するをご覧ください。

次のステップ

GKE Autopilot の他のワークロードのデプロイに関する推奨事項について学習する

カスタム コンピューティング クラスについて

コンピューティング クラスの概要

カスタム コンピューティング クラスのメリット

カスタム コンピューティング クラスのユースケース