【ITニュース解説】Migrating DolphinScheduler into K8s: A Field Report on Pitfalls and Lessons Learned from 900 Days of Qihoo 360’s Practice
2025年09月03日に「Dev.to」が公開したITニュース「Migrating DolphinScheduler into K8s: A Field Report on Pitfalls and Lessons Learned from 900 Days of Qihoo 360’s Practice」について初心者にもわかりやすいように丁寧に解説しています。
ITニュース概要
Qihoo 360がDolphinSchedulerをKubernetesへ移行した事例を紹介。移行の動機は、柔軟な拡張性、リソース分離、自動化。イメージ構築では、ベースイメージの肥大化、MySQLドライバの配置、不要な組み込みDBの無効化などに注意。Helm chart利用で構成管理を効率化。課題は、イメージ管理、設定ファイルの差異、バージョン間の変更差分。今後は標準化を進め、CI/CDを導入予定。
ITニュース解説
この記事は、Qihoo 360という会社が、Apache DolphinSchedulerというジョブスケジューラをKubernetes(K8s)というコンテナオーケストレーションシステムに移行した経験についてまとめたものだ。3年間の実践を通じて得られた、移行時の落とし穴や教訓が共有されている。
DolphinSchedulerは、ビッグデータ処理のジョブを効率的に実行するためのツールだ。以前は物理サーバー上で動かしていたが、リソースの柔軟な拡張やジョブ間の隔離、運用効率の面で課題があった。そこで、クラウドネイティブな戦略に合わせて、DolphinSchedulerをKubernetes上に移行することにした。
Kubernetesへの移行には、大きく分けてイメージの構築とデプロイの2つのステップがある。まず、DolphinSchedulerを動かすためのDockerイメージを作成する。ベースとなるイメージには、Hadoop、Hive、Spark、Flink、Pythonといった、ビッグデータ処理に必要なソフトウェアをあらかじめ含めておく。その上に、DolphinSchedulerのモジュールや、MySQLのドライバなどを追加していく。MySQLはDolphinSchedulerのメタデータを保存するために使用されるので、ドライバはすべてのモジュールに組み込む必要がある。イメージの構築には時間がかかるため、工夫が必要だ。例えば、共通のレイヤーを分割したり、キャッシュを活用したりすることで、ビルド時間を短縮できる。
次に、作成したイメージをKubernetesにデプロイする。初期の頃はYAMLファイルを手書きしていたが、設定が煩雑になり、アップグレードも大変だったため、公式のHelm chartを使うことにした。Helm chartを使うことで、設定を一元管理し、スムーズなアップグレードが可能になる。Helm chartの設定ファイル(values.yaml)では、イメージのレジストリやタグ、外部MySQLの設定、LDAP認証の設定、共有ストレージの設定、HDFSの設定、Zookeeperの設定などを指定する。特に重要なのは、共有ストレージの設定だ。複数のWorkerノードがストレージを共有できるように、ReadWriteMany(RWX)をサポートするストレージクラスを指定する必要がある。
移行作業では、様々な問題に直面した。イメージ関連では、ベースイメージが大きすぎてビルドに時間がかかったり、モジュールの依存関係が異なって重複インストールが発生したり、MySQLドライバのパスが間違っていたり、カスタムJARファイルが古いものを上書きできなかったり、ポートやスクリプトの設定がモジュール間で不整合を起こしたりといった問題があった。Helm chartの設定ファイル関連では、共有ストレージのストレージクラスがRWXに対応していなかったり、ストレージのサイズやマウントパスの設定に誤りがあったり、不要なデフォルト設定を無効化し忘れたり、バージョン要件を満たしていなかったりといった問題があった。
また、DolphinSchedulerの新しいリリースが出るたびに、カスタムパッチを適用し、すべてのモジュールイメージをリビルドし、再テストする必要があった。設定ファイルのキーが変更されると、アップグレードやロールバックがうまくいかなくなることもあり、リリースサイクルが長くなり、チームの負担が増えていた。
これらの課題を踏まえ、今後は以下の取り組みを進めていく予定だ。メタデータDBをMySQLからPostgreSQLに移行し、カスタムイメージではなく、コミュニティ版のイメージを使うようにする。残りの本番環境のワークロードをKubernetesに移行し、PrometheusとGrafanaを使って、CI/CD環境を構築する。
Kubernetesを使うことで、DolphinSchedulerは物理サーバーでは実現できなかった、優れた柔軟性、隔離性、可搬性を手に入れることができる。カスタムイメージや設定は苦労の種だったが、コミュニティ版のリリースに近づき、標準化された運用を進めることで、課題は解消され、開発速度は向上すると期待している。最終的な目標は、高可用性で拡張しやすく、統一されたスケジューリングプラットフォームを構築し、クラウドネイティブの価値を最大限に引き出すことだ。
この記事は、DolphinSchedulerをKubernetesに移行する際の具体的な手順や注意点、実際に直面した問題とその解決策について詳しく解説している。Kubernetesの基本的な知識があれば、記事の内容を理解し、自身のプロジェクトに役立てることができるだろう。特に、イメージの構築やHelm chartの設定に関する情報は、初心者にとって貴重な情報源となるはずだ。