概要
ノートブック型 Spark サービス（主に Databricks）における DevOps の実践について説明する。Databricks と Azure DevOps の組み合わせにより、次ののような CIパイプラインにてテスト結果やコードカバレッジを継続的に管理するまでの考え方と実施方法を記述する。
成果物の一部を、Azure DevOps のパブリックプロジェクトとして公開しており、下記の URL にてパイプラインの実行結果を確認できる。
本記事のコードを含むノートブックを以下のリンクに保存してあり、Databricks 等の環境にインポートして実行が可能。
本記事の位置付け
次の開発ガイドシリーズにおけるDevOps分野の1記事であり、リンク先には記事にて記事の全体像を整理している。
| GroupID | 分野 |
|---|---|
| T10 | Spark概要 |
| T20 | データエンジニアリング |
| T30 | データ品質チェック |
| T40 | データサイエンス |
| T50 | メタデータデプロイ |
| T60 | テスト |
| T70 | DevOps |
ノートブック型 Spark サービスにおける DevOps の概要
ノートブック型 Spark サービスにおける CI/CD（Continuous Integration（継続的インテグレーション）/ Continuous Delivery（継続的デリバリー））の実施方法を説明する。CI/CD とは、コード開発から本番環境への統合までの品質の保証と期間の最小化を担保しつつ、変更点の統合を行いながらシステム運用を行うプロセスである。
CI/CD は次のようなプロセスを実施することが多い。CI にてリリース可能なリソース（一般的には main ブランチのコード）の準備を行い、 CD にて他リソースと統合した本番相当の環境で検証を行ったうえで本番環境へリリースする。リソースの管理は Git で行い、 Git の運用ルールは Git-flow と呼ぶ。Git-flow はチームのスキルセットに応じて方針を定める必要があり、Git の機能を多用するような複雑な設計を行うと運用コストが高くなる可能性がある。継続的な開発と運用を行えるように、シンプルな設計が望ましい。CI/CD の処理群を CI/CD パイプラインと呼び、Github Actions や Azure Pipelines などのサービスで実行する。
- CI
- Code
- Git レポジトリ（ main ブランチ）を準備。
- main ブランチから派生した開発用レポジトリー（フォークしたレポジトリ、あるいは、ブランチ）を準備。
- プログラムコードとテストコードを開発。
- 開発用レポジトリーへ変更内容をコミット。
- Main ブランチへ変更要求（Pull Requet）を実施。
- Build
- main ブランチをベースとして PR の変更内容を反映したコードを生成。
- ライブラリ等のビルド。
- テスト用環境の準備。
- テストを実行。
- リリースの実施有無を判断。
- Release
- 環境へデプロイ可能なリソースを生成。
- Code
- CD
- Deploy
- 環境へリソースを配布。
- Test
- 環境にてテスト実行（主に他システムとの連携テストやE2Eテストを実施）。
- Opeate
- システムの運用。
- Deploy
Code や Build では、開発支援の観点、及び、コードの品質管理の観点により、次のような項目の実施が求められる。
- Linter ツールによる静的解析
- Formatter ツールによるコード整形
- テスト結果の取得、及び、テスト結果の継続的な管理
- テストのコードカバレッジの取得、及び、テストのコードカバレッジの継続的な管理
参考リンク
Databricks での開発
Databricks の開発方針
Databricks Repos のファイル管理仕様、Databricks Workspace 上ではノートブックであるが Git 上では Python ファイルとして管理される仕様、を考慮して、次のような開発指針とする。
- 共通機能を保持したノートブックを
%runにより呼び出して開発を行うこと - テストケースを unittest で記載し、ノートブック上で正常終了することを確認すること
- ローカル環境での動作を考慮したコードを記載すること
ローカル環境での動作を行う目的は、ノートブック型環境で実施できないことを補うためである。ノートブック型環境には、Visual Studio Code (VS Code) などのローカル環境と比較すると、次のような特徴がある。ノートブック型環境の短所を克服するために、ノートブック型環境とローカル環境の併用がおすすめ。
- Pros
- 実行ノートブックにおけるコードと結果を合わせて保存できること
- 開発環境の準備が最小限となり、実行環境とコードの共有ができること
- 処理をセルごとに分割することで処理フローの解釈が容易となること
- Cons
- デバック実行が不可
- Linter（静的解析）ツールの利用不可
- Formatter （コード整形）ツールの利用不可
- テストのコードカバレッジの取得不可
ローカル環境（Visual Studio Code） 上での開発
ローカル環境での開発方針
ローカル環境（Visual Studio Code）の開発環境の構築方法として下記表の方法が考えられるが、ノートブック型環境の短所を補うための補足的な利用であるため、1 の方法を採用。CI/CD パイプラインの実行時 Databricks 上で実施するため、Databricks に近い環境を選択。
| # | 方法 | Pros | Cons |
|---|---|---|---|
| 1 | Databricks Connect により開発する方法 | - VS Code 上でテスト実施でき、コードカバレッジも取得可能 | - 一部機能を利用することができず、新機能の開発の計画がない |
| 2 | dbx by Databricks Labs により開発する方法 | - Databricks Workspace ローカル上のコードを、ローカル環境と同期が可能 | - ベンダーのサポートがない - コードカバレッジを取得する方法を確立できていない |
| 3 | ローカル環境の Spark 環境にて開発する方法 | - VS Code 上でテスト実施でき、コードカバレッジも取得可能 | - Spark プロバイダー固有機能のテストを実施できない |
Databricks Connect 環境の構築方法としては下記表の方法が考えられるが、１の方法を採用。ローカル環境の OS が Windows の場合には、Databricks で利用されている OS との仕様差異を最小限とするために、Databricks Runtime と同じバージョンの OS (Databricks Runtime 10.4 LTS を利用する場合には Ubuntu 20.04 LTS) を用いることを推奨。
| # | 方法 | Pros | Cons |
|---|---|---|---|
| 1 | Conda （無償：Miniconda、有償：Anaconda）を用いて構築する方法 | - 初期環境の統一ができ、環境を柔軟に切り替え可能 | - 環境の統一が困難 |
| 2 | Poetry を用いて構築する方法 | - 環境の統一が容易 | - Databricks Connect のバージョンを切り替えることができない |
| 3 | コンテナ（無償：Rancher Desktop、有償：Docker Desktop）を用いて構築するする方法 | - 初期環境の統一ができ、環境を柔軟に切り替え可能 | - コンテナーに関する知識が必要 |
| 4 | Python 仮想環境を用いずに直接構築する方法 | - 特になし | - Databricks Connect のバージョンを切り替えることができない |
Visual Studio Code の設定値を開発メンバーで共有するために、次のファイルを.vscodeディレクトリに配置。
| # | ファイル名 | 概要 |
|---|---|---|
| 1 | settings.json | Visual Studio Code の設定を保持。 |
| 2 | extensions.json | Visual Studio Code に追加推奨の拡張機能のリストを保持。 |
| 3 | launch.json | Visual Studio Code にてデバッグ実行する際のの設定を保持。 |
Python の Linter と Formatter として次のライブラリを利用。
| # | 分類 | ライブラリ名 | 目的 |
|---|---|---|---|
| 1 | Formatter | black | コードに対するフォーマットツール。 |
| 2 | Formatter | isort | import文に対するフォーマットツール。 |
| 3 | Linter | flake8 | コードに対する静的解析ツール。 |
| 4 | Linter | pydocstyle | Docstring に対する静的解析ツール。 |
| 5 | Linter | mypy | 型に対する静的解析ツール。 |
ライブラリの設定値は、次のファイルにて設定。
| # | ファイル名 | 概要 |
|---|---|---|
| 1 | pyproject.toml | 基本的な設定値を設定。 |
| 2 | .vscode/settings.json | ローカル環境でのみ有効な設定値を設定。テスト実行時の並列数の設定など。 |
| 3 | .vscode/launch.json | デバッグ時にのみ有効な設定値を設定。カバレッジレポートを取得しない設定など。 |
Conda 環境情報をenvironment.ymlに記述しており、Databricks Connect に対応した Python バージョンをベースにrequirements.txtを pip install する構成。requirements.txtでは、Databricks Connect や Linter などの開発時に必要なライブラリだけでなく、Databricks Runtime にインストールされている多くのライブラリを保持。
# Formatting libraries
black
isort
# Linter libraries
flake8
pydocstyle
mypy
# test libraries
pytest
coverage
pytest-cov
pytest-xdist
# Sphinx Libraries
sphinx
sphinx-markdown-builder
# databricks Connect
databricks-connect==10.4.*
Databricks Runtime インストールされているライブラリのバージョンを取得するために、次のような手順で requirements.txt を作成している。Conda 環境構築時にエラーとなったライブラリーを除外。
-
%pip freezeをノートブック上で実行することで、クラスターにインストールされているライブラリ一覧を取得 -
requirements.txtに、１の結果を貼り付け、不要なライブラリを削除 -
conda env create -f environment.ymlにより環境が構築できることを確認 -
.environmentsディレクトリ下に Databricks Connect のバージョンごとの環境情報を保存
ローカル環境の構築
詳細は、Databricks Connect（Python）環境を Windows Subsystem for Linux (WSL)上に特定の目的のみに利用する Linux 環境に構築する手順 - Qiita の記事にて記載。
Azure DevOps (Pipelines) による CI/CD パイプライン
Azure Pipelines 概要
Azure Pipelines とは、Azure DevOps の１機能であり、 CI/CD（Continuous Integration（継続的インテグレーション）/ Continuous Delivery（継続的デリバリー））を自動化させる pipeline を構築できるサービスである。pipeline は、stage -> job -> task の階層構造となってり、Trigger により実行され、 Stage により論理的境界線を定義し、 job にエージェントを紐づけて task で指定した処理を行う。
Azure Pipelines では、エージェントの並列実行数が主な課金対象であり、複数人での開発を行う際には無償で並列数に制限なく利用できるエージェントレスジョブを利用するなどのエージェントの利用方法が重要となる。処理が完了するまでの待機処理を、通常のジョブで実行した場合にはエージェントを占有してしまうが、エージェントレスジョブで実行することで他パイプライン（他ジョブ）がエージェントを利用することができる。
- Azure Pipelines エージェント - Azure Pipelines | Microsoft Learn
- エージェントレス ジョブでサポートされているタスク - Azure Pipelines | Microsoft Learn
Azure Pipelines では、YAML 形式で記述を行う。YAMLで記述できる項目は、Azure DevOps のドキュメントにて整理されており、タスク等の拡張機能をインストールすることも可能である。Command Line task ではscriptと記述できるなど、一部のタスクではシンタックスを利用することもできる。以前から Azure DevOps （Visual Studio Team Services） で利用できたクラシックパイプラインという開発方法もあるが、本記事では利用対象としない。クラシックパイプラインの機能をベースに解説されている記事もあるため、どちらの開発方法の記事であるかを確認する必要がある。
- YAML schema reference | Microsoft Learn
- Catalog of the built-in tasks for build-release and Azure Pipelines & TFS - Azure Pipelines | Microsoft Learn
- Azure Pipelines Extensions - Azure DevOps Services (visualstudio.com)
stages 、 jobs 、 tasks 、variables を別の YAML ファイルで定義し、テンプレートとして呼び出すことも可能。
機微な情報をパイプラインで利用する際には、シークレット変数とする方法、および、Azure Key Vault を利用する方法が推奨されており、YAML 上に直接記述するべきではない。
- シークレット変数を設定する - Azure Pipelines | Microsoft Learn
- Azure Pipelines で Azure Key Vault シークレットを使用する - Azure Pipelines | Microsoft Learn
パイプライン実行の承認（Approvals）や同時実行の制御（Exclusive lock）も実施できる。
ジョブが異なる場合には異なるエージェント環境となるため、変数の受け渡しを行う際には次の記事で記載されているような記述を行う。dependsOnにより変数取得元のジョブ間に依存関係を明示する必要がある。
ビルド番号などの定義済み変数については、次のドキュメントに記載されている。
Azure pipelins の実装方法を検討する際には、次のドキュメントの方法を試すことが参考になる。
- Python アプリのビルドとテスト - Azure Pipelines | Microsoft Docs
- Azure DevOps を使用した Azure Databricks での継続的インテグレーションとデリバリー - Azure Databricks | Microsoft Docs
Python アプリのビルドとテストのコードにて次の YAML により、 Python におけるシンプな CI パイプラインの構築が可能。
trigger: none
pr: none
jobs:
- job:
displayName: execute and publish test
pool:
vmImage: 'ubuntu-latest'
steps:
- task: UsePythonVersion@0
inputs:
versionSpec: '3.7'
- script: python -m pip install --upgrade pip setuptools wheel
displayName: 'Install tools'
- script: pip install -r requirements.txt
displayName: 'Install requirements'
- script: |
pip install pytest pytest-azurepipelines
pip install pytest-cov
pytest --doctest-modules --junitxml=junit/test-results.xml --cov=. --cov-report=xml
displayName: 'pytest'
- task: PublishTestResults@2
condition: succeededOrFailed()
inputs:
testResultsFiles: '**/test-*.xml'
testRunTitle: 'Publish test results for Python $(python.version)'
- task: PublishCodeCoverageResults@1
inputs:
codeCoverageTool: Cobertura
summaryFileLocation: '$(System.DefaultWorkingDirectory)/**/coverage.xml'
Databricks における CI/CD パイプラインの構築
詳細は、 Databricks の CI （Continuous Integration（継続的インテグレーション）） パイプラインを Azure DevOps (Pipelines) にて構築する手順 - Qiita の記事にて記載。