クラシック コンピューティングからサーバーレス コンピューティングへの移行

クラシック コンピューティングからサーバーレス コンピューティングにワークロードを移行します。 サーバーレス コンピューティングは、プロビジョニング、スケーリング、ランタイムアップグレード、最適化を自動的に処理します。

ほとんどのクラシック ワークロードは、コードの変更を最小限に抑えるか、まったく変更なしで移行できます。 このページでは、これらのワークロードに焦点を当てます。 df.cacheなどの一部の機能は、サーバーレスではまだサポートされていませんが、一度使用可能になるとコードを変更する必要はありません。 R または Scala ノートブックに依存する特定のワークロードでは、クラシック コンピューティングが必要であり、サーバーレスに移行することはできません。 現在の制限事項の完全な一覧については、「 サーバーレス コンピューティングの制限事項」を参照してください。

移行エージェントで移行する

Important

この機能は ベータ版です。 ワークスペース管理者は、Previews ページで Compute Agent プレビューにオプトインすることで、これを有効にできます。 Manage Azure Databricks プレビューを参照してください。

単一のノートブックやジョブをサーバーレスコンピュートに移行するには、移行エージェントを使うことができます。 エージェントはワークロードの環境、ライブラリ、Sparkの設定、タグ、コードをレビューし、各変更を個別の提案として提案し、あなたに受け入れるか拒否するかを選びます。 承認された変更はその場で適用され、ロールバック可能です。

エージェントが確認し変更する内容

Area エージェントの機能
環境とライブラリ ライブラリのインストールをサーバーレス環境仕様に変換し、 %pip インストール、クラスターinitスクリプト、ジョブ上のクラスタライブラリ、プライベートパッケージインデックスへの参照などが含まれます。
環境変数 クラスタ環境変数をサーバーレスの変数に変換し、ワークスペースの秘密参照を保持し、プラットフォーム管理の値を省略します。
データとストレージアクセス ローカルディスク、 dbfs:/、マウントパスなどのサーバーレス互換性のないパスをUnity Catalogボリュームに書き換えます。 エージェントは自動的に明確な書き換えを適用し、ターゲットが曖昧な場合はボリュームの選択を求めます。
Spark の構成 各Spark構成を分類し、削除しても安全な構成をコメントアウトし、サーバーレスがサポートしない設定をフラグ付け・削除します。 クラスターアタッチ型とノートブック内型の両方の構成に対応しています。
ワークロードコード サーバーレスがサポートしないコードを、RDD操作をDataFrame操作に書き換えるなど、互換性のある同等物に書き換えたり、サーバーレス上でANSIモードSQLの動作に合わせてコードを調整します。
Tags コストセンタータグなどのカスタムクラスタタグをサーバーレス版に変換します。
パフォーマンスモード クラスタの設定に基づくパフォーマンスモードを提案します。 パフォーマンス モードの選択を参照してください。

Requirements

  • 完全な移行を確実にするために、ワークスペース管理者権限の確保が推奨されます。 これは、エージェントがターゲットワークロードを超えたワークスペースレベルのグローバルinitスクリプトも検査するためです。 ワークロードに権限があれば CAN MANAGE 移行は可能かもしれませんが、管理者権限がなければライブラリや環境設定、タグが抜けてしまうことがあります。

  • エージェントにアクセスできるか確認してください。 ジーニーコードで入力 /compute 。 /compute オートコンプリートメニューに表示されるはずです。 表示されない場合は、ワークスペース管理者があなたのワークスペースでプレビューを有効にする必要があります。

    /compute が入力された Genie Code パネル。オートコンプリートメニューに /compute コマンドと「ジョブをサーバーレスコンピューティングに移行」という説明が表示されている

ノートブックの移行

  1. 移行したいノートを開いてください。
  2. Genie Codeを開いて、/コマンドパレットから/compute migrate to serverlessを実行します。
  3. エージェントの調査結果を確認しましょう。 エージェントはノートブックの環境、ライブラリ、コードをスキャンし、必要な項目ごとに変更を提案します。例えば、ライブラリのインストールを環境仕様に移行したり、サーバーレスで動作するコードセルの書き換えなどです。
  4. 提案された変更を受け入れるか拒否するかを判断してください。
  5. 受け入れた変更を適用してください。 それらはノートブックに直接書き込まれます。
  6. ノートブックをサーバーレスに接続して実行し、期待通りに動作するか確認してください。 「 移行されたワークロードの検証」を参照してください。

仕事の移行

  1. 移行したい仕事を募集しましょう。
  2. Genie Codeを開いて、/コマンドパレットから/compute migrate to serverlessを実行します。
  3. エージェントはあなたのジョブを複製し、複製したジョブのサーバーレスへの移行を試みます。
  4. エージェントの調査結果を確認しましょう。 マルチタスクジョブの場合、エージェントはすべてのタスクとそのタスクごとのクラスタ構成を列挙し、ジョブのスケジュールを保持しながら各タスクの変更を提案します。
  5. 移行サーフェス全体で提案された変更(環境やライブラリ、Sparkの設定、変更が必要なワークロードコード)を受け入れるか拒否するかを決めます。
  6. 受け入れた変更を適用してください。 ジョブのコンピュートはサーバーレスに切り替わります。
  7. サーバーレスでジョブを実行し、結果を確認してください。 「 移行されたワークロードの検証」を参照してください。
  8. オプションとして、最終ステップとしてエージェントは移行したクローンをプロモートします。 クローンの設定やノートブックを元のジョブにコピーし(同じジョブID、スケジュール、権限は保持)、その後クローンを削除します。 昇格をスキップして両方のジョブを保持する場合は、実行していないほうのジョブのスケジュールを一時停止してください。そうしないと、同じトリガーによって両方のジョブが実行され、書き込みの重複やその他の副作用を引き起こす可能性があります。

移行したワークロードの検証

エージェントは変更を提案し適用しますが、ワークロードを実行したり出力を検証したりはしません。 移行したワークロードは必ずサーバーレス上で実行し、結果を確認してから依存してください。特に本番テーブルに書き込みするワークロードの場合はなおさらです。 もしエージェントが提案した変更がおかしければ、それを却下し、フィードバックを送ってエージェントの改善を図ってください。 製品フィードバックの送信を参照してください。

Tip

移行したワークロードを検証する間は、パフォーマンス最適化モードで実行してください。 標準モードよりも早く始まるので、結果を確認するとフィードバックが早く受け取れます。 本番環境で実行する前に、ワークロードに最も合ったモードに切り替えてください。 パフォーマンス モードの選択を参照してください。

エージェントが安全に移行できないものを見つけた場合、ブロッカーを報告し、デフォルトで停止します。 明示的に互換性や依存関係のブロッカーを通過するように指示することはできますが、そうすると依存関係やコスト帰属、ランタイム動作が引き継がれず、サーバーレスでワークロードが失敗するリスクを受け入れることになります。

移行の変更をロールバック

エージェントが適用する変化は可逆的です。

ノートの場合は、移行直前の修正を開いて復元してください。 Databricks ノートブックのバージョン履歴を参照してください。

ジョブの場合、もし移行したクローンを昇格しなかった場合、元のジョブは変更されませんでした。以前通り実行し、クローンを削除してください。 クローンを昇格させた場合は、エージェントが変更を加える前に書いたバックアップから復元してください:

  1. ワークスペースのホームにあるバックアップフォルダを開いてください: /Workspace/Users/<your-username>/serverless-migration/backups/job-<job-id>/<timestamp>/。 エージェントは移動中にこの経路を示しました。 複数のタイムスタンプがある場合は、移行直前のものを選びましょう。
  2. 移行前のジョブ設定が保存されている job.yaml を開き、POST /api/2.2/jobs/reset リクエストを使用して、それらの設定を同じジョブに再適用します。このリクエストは、指定した設定でそのジョブの設定を上書きします。 また、UIのジョブのJSON定義に貼り付けることもできます。 これにより、ジョブがクラシック コンピュートに戻されます。
  3. mapping.yamlを開くと、バックアップ済みファイルとその元の経路が一覧表示されます。 各バックアップファイルを元のパスにコピーしてコードの書き換えを解除します。
  4. ジョブを実行して、移行前と同じ動作をしているか確認してください。

移行ではこのバックアップは削除されません。 エージェントが変更していないタスク(git-sourced、SQL、dbtなど)は job.yaml に記録されますが、そのファイルはバックアップにコピーされません。必要に応じてソースから復元してください。

既知の制限

  • 以下はブロッカーとして報告されています:カスタムイメージ、MLランタイムのバリアント、13以前のDatabricksランタイムバージョン、サーバーレスで安全に無視できないSpark構成、そしてeggs、JAR、Mavenライブラリなどの依存関係です。 ブロッカーとは、エージェントがそのアイテムを移動せずに停止することを意味します。 自分で解決して再度移行を実行するか、エージェントに移行を指示しても、その項目は解決されず、サーバーレスでワークロードが失敗する可能性があります。
  • エージェントはワークスペースファイルやUnity Catalogボリュームに保存されたinitスクリプトを読み込みます。 ABFSSまたはDBFSに保存されたinitスクリプトは読み取れず、ブロッカーとして報告されます。
  • エージェントはすべてのクラシックな計算属性を検査するわけではありません。 クラスターログの配信やSSHキーはモデル化されておらず、ワークロードコードから多くのDBFSマウント依存関係を検出しますが、すべてのマウントを列挙または解決するわけではありません。
  • キャッシュおよびチェックポイントAPI、グローバル一時ビュー、DBFSのマウント管理コール、ScalaやRコードはデフォルトでハードブロッカーです。 エージェントに指示はできますが、未解決機能は変更されず、サーバーレスでは失敗する可能性があります。
  • 10以上の移動可能なタスクを持つジョブは現在移行できません。
  • エージェントは一度に1つのワークロードを移行します。 フリート全体のディスカバリー、大量移行、管理者承認のワークフローはありません。
  • エージェントは変更を提案し、あなたが受け入れた変更を適用しますが、ワークロードを実行したり出力の正確性を検証したりはしません。 本番データに依存する前に、移行したワークロードを必ず確認してください。
  • もしあなたのワークロードの真実のソースがDatabricksのAsset BundleやGitフォルダであれば、エージェントはワークスペースオブジェクトに変更を適用します。 これらの変更をバンドルやリポジトリと照合し、後のデプロイで移行が上書きされないようにしましょう。

手動でサーバーレスに移行する

クラシック コンピューティングからサーバーレス コンピューティングにワークロードを移行するには、次の手順に従います。

  1. 前提条件を確認する: ワークスペース、ネットワーク、クラウド ストレージへのアクセスが要件を満たしていることを確認します。 「前提条件」を参照してください。
  2. コードの更新: 必要なコードと構成の変更を行います。 「 コードを更新する」を参照してください。
  3. ワークロードをテストする: 移行する前に互換性と正確性を確認します。 ワークロードのテストを参照してください。
  4. パフォーマンス モードの選択: ワークロードの要件に最も適したパフォーマンス モードを選択します。 パフォーマンス モードの選択を参照してください。
  5. 段階的な移行: 新しい低リスクのワークロードから始めて、サーバーレスを段階的にロールアウトします。 段階的な移行を参照してください。
  6. コストの監視: サーバーレス DBU の使用量を追跡し、アラートを設定します。 コストの監視を参照してください。

Prerequisites

移行を開始する前に、ワークスペース内のいくつかのレガシ構成を更新することが必要になる場合があります。

前提条件 アクション 詳細情報
Unity カタログでワークスペースが有効になっている 必要に応じて Hive Metastore から移行する Azure Databricks ワークスペースを Unity カタログにアップグレードします
構成されたネットワーク VPC ピアリングを NCC、Private Link、またはファイアウォール規則に置き換える サーバーレス コンピューティング プレーン ネットワーク
クラウド ストレージ へのアクセス 従来のデータ アクセス パターンを Unity カタログの外部の場所に置き換える Unity カタログを使用してクラウド オブジェクト ストレージに接続する

ワークスペースが サポートされているリージョンであることを確認します。

コードを更新する

次のセクションでは、ワークロードをサーバーレスと互換性させるために必要なコードと構成の変更を示します。

データアクセス

従来のデータ アクセス パターンは、サーバーレスではサポートされていません。 代わりに Unity カタログを使用するようにコードを更新します。

クラシック パターン サーバーレス置換 詳細情報
DBFS パス (dbfs:/...) Unity のカタログボリューム Unity Catalog ボリュームとは?
Hive メタストア テーブル Unity カタログ テーブル (または HMS フェデレーション) Azure Databricks ワークスペースを Unity カタログにアップグレードします
ストレージ アカウントの資格情報 Unity カタログの外部の場所 Unity カタログを使用してクラウド オブジェクト ストレージに接続する
カスタム JDBC JAR レイクハウスフェデレーション クエリフェデレーションとは

Warnung

DBFS アクセスはサーバーレスで制限されます。 移行する前に、すべての dbfs:/ パスを Unity カタログ ボリュームに更新します。 詳細については、「 DBFS に格納されているファイルを移行する」を参照してください。

例: DBFS パスと Hive メタストア参照を置き換える
# Classic
df = spark.read.csv("dbfs:/mnt/datalake/data.csv", header=True)
df.write.parquet("dbfs:/mnt/output/results")
df = spark.table("my_database.my_table")

# Serverless
df = spark.read.csv("/Volumes/main/sales/raw_data/data.csv", header=True)
df.write.parquet("/Volumes/main/analytics/output/results")
df = spark.table("main.my_database.my_table")  # three-level namespace

API とコード

特定の API とコード パターンは、サーバーレスではサポートされていません。 コードを更新する必要があるかどうかを確認するには、この表を参照してください。

クラシック パターン サーバーレス置換 詳細情報
RDD API (sc.parallelize、 rdd.map) DataFrame API Spark Connect と Spark クラシックの比較
df.cache()、df.persist() キャッシュ呼び出しを削除する サーバーレス コンピューティングの制限事項
spark.sparkContext、sqlContext spark (SparkSession) を直接使用する Spark Connect と Spark クラシックの比較
Hive 変数 (${var}) SQL DECLARE VARIABLE または Pythonのf文字列 DECLARE VARIABLE
サポートされていない Spark 構成 サポートされていない構成を削除します。 サーバーレスでは、ほとんどの設定が自動チューニングされます。 サーバーレス ノートブックとジョブの Spark プロパティを構成する
例: RDD 操作を DataFrames に置き換える
from pyspark.sql import functions as F

# sc.parallelize + rdd.map
# Classic:  rdd = sc.parallelize([1, 2, 3]); rdd.map(lambda x: x * 2).collect()
df = spark.createDataFrame([(1,), (2,), (3,)], ["value"])
result = df.select((F.col("value") * 2).alias("value")).collect()

# rdd.flatMap
# Classic:  sc.parallelize(["hello world"]).flatMap(lambda l: l.split(" ")).collect()
df = spark.createDataFrame([("hello world",)], ["line"])
words = df.select(F.explode(F.split("line", " ")).alias("word")).collect()

# rdd.groupByKey
# Classic:  rdd.groupByKey().mapValues(list).collect()
df = spark.createDataFrame([("a", 1), ("b", 2), ("a", 3)], ["key", "value"])
grouped = df.groupBy("key").agg(F.collect_list("value").alias("values")).collect()

# rdd.mapPartitions → applyInPandas
import pandas as pd
def process_group(pdf: pd.DataFrame) -> pd.DataFrame:
    return pd.DataFrame({"total": [pdf["id"].sum()]})
result = (spark.range(100).repartition(4)
    .groupBy(F.spark_partition_id())
    .applyInPandas(process_group, schema="total long").collect())

# sc.textFile → spark.read.text
df = spark.read.text("/Volumes/catalog/schema/volume/file.txt")
例: SparkContext とキャッシュを置き換える
from pyspark.sql.functions import broadcast

# sc.broadcast → broadcast join
result = main_df.join(broadcast(lookup_df), "key")

# sc.accumulator → DataFrame aggregation
total = df.agg(F.sum("amount")).collect()[0][0]

# sqlContext.sql → spark.sql
result = spark.sql("SELECT * FROM main.db.table")

# df.cache() → remove caching calls
# Materialize expensive intermediate results to Delta as a workaround:
df = spark.read.parquet(path)
result = df.filter("status = 'active'")
expensive_df.write.format("delta").mode("overwrite").saveAsTable("main.scratch.temp")
result = spark.table("main.scratch.temp")

SQLの挙動の違い

サーバーレスコンピュートはデフォルトでANSIモードを有効にします。 Databricks Runtimeはバージョン17.0以降でANSIモードをデフォルトで有効化します。 もしクラシックのコンピュートが古いバージョンを動かしている場合、そこで成功する一部のクエリは、サーバーレスではランタイム エラーになります。

移行エージェントはANSIモードの動作に合わせてコードを自動的に調整します。 手動で移行する場合は、動作が変わることが最も多い以下の処理を確認してください:

Operation ANSIモードを無効にしたクラシックコンピュート サーバーレス コンピューティング
たとえば CAST('abc' AS INT) のような無効なキャスト NULL を返します。 CAST_INVALID_INPUT が発生する
整数の算術オーバーフロー 回り込む。 たとえば、2147483647 + 1 は -2147483648を返します。 ARITHMETIC_OVERFLOW が発生します
十進算術オーバーフロー NULL を返します。 NUMERIC_VALUE_OUT_OF_RANGE を発生させる
0 で除算しました NULL を返します。 DIVIDE_BY_ZERO を発生させる
parse_url内の不正なURL NULL を返します。 昇給 INVALID_URL

エラーを発生させる代わりに NULL を返すには、その操作を 相当の操作 (たとえば try_cast、try_add、try_parse_url、または try_*) に置き換えます。 DatabricksはANSIモードを無効にする代わりにこの方法を推奨しています。なぜなら、ANSIモードは暗黙的な NULL が隠してしまうデータ品質の問題を浮き彫りにするからです。

キャスト、算術、解析で ANSI モードを無効にするには、spark.sql.ansi.enabled を false に設定してください。 サーバーレス計算は、この設定に関わらずテーブル挿入の暗黙のキャストにANSIルールを適用します。なぜなら、サーバーレス計算では spark.sql.storeAssignmentPolicy 変更できないからです。 ANSIの動作の詳細については、 Databricks RuntimeのANSI準拠を参照してください。

ライブラリと環境

ライブラリと環境は、 基本 環境を使用してワークスペース レベルで管理し、ノートブックの サーバーレス環境を使用してノートブック レベルで管理できます。

クラシック パターン サーバーレス置換 詳細情報
初期化スクリプト サーバーレス環境 サーバーレス環境を構成する
クラスター-スコープ ライブラリ ノートブック スコープまたは環境ライブラリ サーバーレス環境を構成する
Maven/JAR ライブラリ ジョブ向けの JAR タスクサポート、ノートブック用 PyPI ジョブ用 JAR タスク
Docker コンテナー ライブラリのニーズに対応するサーバーレス環境 サーバーレス環境を構成する

Python パッケージを requirements.txt にピン留めして、再現可能な環境に対応します。 Specify Python パッケージのバージョンを参照してください。

ストリーミング

ストリーミング ワークロードはサーバーレスでサポートされていますが、特定のトリガーはサポートされていません。 サポートされているトリガーを使用するようにコードを更新します。

スパーク トリガー サポートされている メモ
Trigger.AvailableNow() はい 推奨
Trigger.Once() はい 非推奨です。 Trigger.AvailableNow() を代わりに使用します。
Trigger.ProcessingTime(interval) いいえ INFINITE_STREAMING_TRIGGER_NOT_SUPPORTED を返します。
Trigger.Continuous(interval) いいえ 代わりに Lakeflow パイプラインの連続モードを使用する
既定値 ( .trigger()を設定しない) いいえ .trigger()省略すると、既定で ProcessingTime("0 seconds") になります。サーバーレスではサポートされていません。 .trigger(availableNow=True)は常に明示的に設定してください。

継続的ストリーミングの場合は、継続的モードで Spark 宣言パイプラインに移行するか、でAvailableNowを使用します。 大きなソースの場合は、メモリ不足エラーを防ぐために maxFilesPerTrigger または maxBytesPerTrigger を設定します。

例: ストリーミング トリガーを修正する
# Classic (not supported on serverless — default trigger is ProcessingTime)
query = df.writeStream.format("delta").outputMode("append").start()

# Serverless (explicit AvailableNow trigger)
query = (df.writeStream.format("delta").outputMode("append")
    .trigger(availableNow=True)
    .option("checkpointLocation", checkpoint_path)
    .start(output_path))
query.awaitTermination()

# With OOM prevention for large sources
query = (spark.readStream.format("delta")
    .option("maxFilesPerTrigger", 100)
    .option("maxBytesPerTrigger", "10g")
    .load(input_path)
    .writeStream.format("delta")
    .trigger(availableNow=True)
    .option("checkpointLocation", checkpoint_path)
    .start(output_path))

ワークロードをテストする

  1. クイック互換性テスト: Standard アクセス モードと Databricks Runtime 14.3 以降を使用して、クラシック コンピューティングでワークロードを実行します。 実行が成功した場合、ワークロードはコードを変更することなくサーバーレスに移行できます。
  2. A/B 比較 (運用環境に推奨): クラシック (制御) とサーバーレス (実験) で同じワークロードを実行します。 出力テーブルを差分し、正確性を確認します。 出力が一致するまで反復処理します。
  3. 一時的な構成: テスト中に、サポートされている Spark 構成を一時的に設定できます。 安定したら削除します。

パフォーマンス モードを選択する

サーバーレス ジョブとパイプラインでは、標準とパフォーマンス最適化の 2 つのパフォーマンス モードがサポートされます。 選択するパフォーマンス モードは、ワークロードの要件によって異なります。

モード 在庫状況 Startup 最適な用途
Standard ジョブ、Lakeflow パイプライン 4 ~ 6 分 コストセンシティブなバッチ
パフォーマンス最適化 Notebooks、ジョブ、Lakeflow パイプライン 秒数 対話型、待機時間の影響を受けやすい

段階的に移行する

  1. 新しいワークロード: サーバーレスですべての新しいノートブックとジョブを開始します。
  2. リスクの低いワークロード: 標準アクセス モードと Databricks Runtime 14.3 以降で既に PySpark/SQL ワークロードを移行します。
  3. 複雑なワークロード: コードの変更が必要なワークロード (RDD の書き換え、DBFS の更新、トリガーの修正) を移行します。
  4. 残りのワークロード: 機能の拡張に合わせて定期的に確認します。

コストを監視する

サーバーレス課金は、クラスターのアップタイムではなく、DBU の使用量に基づいています。 大規模に移行する前に、代表的なワークロードでコストの期待を検証します。 サーバーレス コストを監視するためのツールと戦略については、「 サーバーレス コンピューティングのコストの監視」を参照してください。

その他のリソース

詳細については、次のブログ記事を参照することもできます。