はじめに

こんにちは、マイクロアドでサーバーサイドエンジニアをしている澤田です。主にDigdag¹とPythonを使用したETL/ELT処理²を行うバッチを開発しています。

今回はバッチ処理で使用しているPythonを3.7から3.11にバージョンアップした際の取り組みについてです。

バージョンアップの背景から実際に取り組んだ中で出た課題とその対応を共有します。

経緯

マイクロアドのバッチ開発ユニットではETL/ELT処理を行うために、メインのプログラム言語としてPythonを使用しています。メインバージョンとしてはPython 3.7を長らく使用していました。 Python 3.7は2018年6月に提供が開始され、サポート期限(EOL)が2023年6月になっています。一方でPython 3.11は2022年10月に提供が開始され、サポート期限(EOL)が2027年10月になっています。

プログラミング言語をバージョンアップするメリットは多岐にわたります。

プロダクトの保守性を高める
セキュリティリスクを回避する
新機能が使える

中でも今回私たちがPython 3.11へ引き上げるに至った一番の要因はパフォーマンスの向上になります。

Python 3.11が登場した際のリリースハイライトには以下のような記述がありました。

Python 3.11 は Python 3.10 とくらべて 10-60% 高速です。平均的には、標準ベンチマークスイートでは 1.25倍の高速化を計測しました。

(「What's New In Python 3.11」から引用 https://docs.python.org/ja/3.11/whatsnew/3.11.html )

2022年にPyConへ参加した際にも、3.11の新機能やパフォーマンス改善に関して多くのセッションが開かれていました。

（当時の参加レポートは以下の記事を参照してください。） developers.microad.co.jp

そういった背景からパフォーマンス懸念が上がる前にバージョンアップに対しての準備を始めました。

バージョンアップまでのフロー

実際にバージョンアップに向けて準備した内容を紹介します。内容は検証からツールの選定理由など、大きく分けて以下の3つそれぞれ紹介していきます。

使用しているライブラリの動作確認
バージョンアップに伴った、ツールの導入
パフォーマンス検証

使用しているライブラリの動作確認

今回特に時間をかけた箇所がこの部分になります。バージョンアップに際してバッチ毎で使用しているライブラリをリストアップして、それぞれがPython 3.11に対応しているか、上手く動作するかを検証しました。

具体的には以下のような手順での調査をしました。

バッチ内で使用しているライブラリをリストアップ
使用頻度順に優先度を決め、Python 3.11に対応しているか調査
1. ライブラリのドキュメントに対応済みの記述があるか
2. ユニットテストが実装されている場合、Python 3.11環境下で動作するか
3. ETL処理の中でよく使用される形での動作に問題がないか
4. 個別にバッチを動かし単体で動作するか

このステップを踏むことで、時間はかかりましたがシステムの信頼性は担保することができます。バッチそれぞれでコンテナを使った運用をしているため、バッチ単位での調査がスムーズに進んだことは追い風になった部分でした。バッチの構成が気になる方は以下の記事をご一読下さい。 developers.microad.co.jp

バージョンアップに伴った、ツールの導入

バージョンアップに際し、ツールの刷新も同時に進めました。これまではパッケージ管理ツールとして pip を使用していましたが、利便性を向上させるツールが他にもあるということで見直しを行いました。

選定の段階で、Pipenv, Poetry, Ryeなどが候補に上がりましたが最終的には以下のメリット・デメリットから総合的に判断し、Poetryの導入に至りました。

Pipenv
- PyPA開発なので、長期的なサポートが望める
- 依存環境構築にrequirements.txtを使える
- 依存関係の管理や仮想環境の機能がPipfileによって一元化されている
Poetry
- パッケージの依存関係の解決がPipenvより早い
- PEP 518で規定されたファイルpyproject.tomlを使って管理ができる
- Github StarがPipenvより多い
- 個人開発であるため、将来的に自社メンテが必要になる可能性がある
Rye
- Rust製なので動作が早い
- pyproject.tomlを使って管理ができる
- Pythonバージョンの管理が可能(今回対象とするバッチ開発では過剰)

実際にPoetryを使用して、pyproject.tomlに設定やバージョンを記述できることが特に便利と感じています。 pip環境ではツール毎に設定ファイルが必要になっていましたが、Poetry環境ではpyproject.tomlに実行時の設定を予め記載しておくことができます。

パフォーマンス検証

バージョンアップのモチベーションにもなったパフォーマンス検証をしました。既存のgRPC APIに対しGatling³を使用して検証をしました。

詳しい数値は割愛しますが、単なるPythonのバージョンアップでAPIの応答時間の改善が確認できました。

終わりに

今回でバージョンアップに対する知見と経験値が貯まったので、今後は一層スピーディーにバージョンアップできる体制を整えたいです。ここまで読んでいただきありがとうございました。

Digdagとはマイクロアドで採用しているワークフローエンジンです。
詳しくは過去記事を参照ください。https://developers.microad.co.jp/archive/category/Digdag ↩
いずれもExtract, Transform, Loadの頭文字をフローにしたがって並べたもので、データを利用しやすい形へと変換する一連の処理。↩
負荷、パフォーマンステストフレームワーク https://gatling.io/products ↩