Kestra 1.x のワーカーがDB直結で塞がれる問題とKestra 2.0の解決策

ワークフローオーケストレーションツール Kestra（データパイプラインやジョブのスケジューリング・実行を管理するオープンソース基盤）を1.x系で運用している、もしくは導入を検討しているSRE・インフラ担当者に向けた内容です。マルチクラウドやオンプレとクラウドの混在環境でジョブを動かそうとして、ネットワーク要件で詰まった経験がある方の参考になれば幸いです。

Kestra は2022年の初期バージョンではKafkaとElasticsearchを土台にした構成で紹介されていましたが、その後JDBCバックエンド（PostgreSQLやMySQLのような通常のリレーショナルDBをキューと状態管理の両方に使う方式）に切り替わった経緯があります。今回取り上げる2.0では、さらに大きな設計変更としてワーカーの配置制約が撤廃されました。1.x系を使っているなら、まずこの制約が自分たちの環境に影響しているかを確認する価値があります。

何が起きるか: ワーカーが「どこにでも置けない」問題

Kestra 1.x系のアーキテクチャでは、ジョブを実際に実行する「ワーカー」プロセスが、中央のデータベース（PostgreSQLやMySQL、あるいはKafka+Elasticsearch構成）へ直接コネクションを張る設計になっていました。

これはつまり、ワーカーを動かす場所は「DBに到達できるネットワーク」に限定される、ということです。

たとえば、セキュリティチームが管理する別クラウドやオンプレのデータセンターにワーカーを置きたい場合、そこから中央のPostgresへの経路をファイアウォールで開けてもらう必要があります。この経路開放が承認されないケースは珍しくありません。

選択肢は実質2つしかありませんでした。サイトごとにKestra一式(コントロールプレーンとDBも含めて)をまるごと複製してデプロイするか、オーケストレーションを諦めてcronと素のスクリプトに戻るかです。後者を選ぶチームが実際にいたことも報告されています。

なぜ起きるか: 段階的に見る設計上の原因

原因1: コントロールプレーンとデータプレーンが未分離だった

1.x系では、ジョブのスケジューリングやUI表示を担う「頭脳」部分(エグゼキューター・スケジューラー・Webサーバー)と、実際にユーザーのコードを実行する「手足」部分(ワーカー)が、同じデータベース接続を前提に設計されていました。分散システムの一般的な設計パターンである「制御用のプレーン」と「データを処理するプレーン」の分離が徹底されていなかったことになります。

原因2: 接続の向きがワーカー側から選べなかった

ワーカーがDBに接続する方式では、ネットワーク的に「ワーカー側からDBへ到達可能」という条件が必須です。閉域網やアウトバウンドのみ許可されたネットワーク(多くの金融機関や医療機関のセキュリティポリシーで一般的)では、この条件自体が満たせません。

原因3: キューとリポジトリの実装が固定ペアだった

Kafka+ElasticsearchかJDBCか、という二択の内部実装が並存していたため、バグ修正やバランス調整が二重に必要になっていました。これは直接ワーカー配置の問題ではありませんが、エンジン全体の複雑さを増し、改修を遅らせる要因になっていたとされています。

自分のプロジェクトが該当するか確認する方法

以下の観点で、自分の環境がこの制約の影響を受けているか確認できます。

バージョン確認: 管理画面の「About」やヘルムチャートの values.yaml 内の image.tag、もしくはコンテナイメージのタグで kestra:1.x 系か kestra:2.x 系かを確認する

ネットワーク構成の棚卸し: ワーカーを配置したいクラウド・拠点から、中央DB(PostgresやMySQL)への経路がインバウンドで許可されているかをネットワーク図で確認する

デプロイ構成ファイルの確認: docker-compose.yml やKubernetesマニフェスト内で、ワーカーのPodやコンテナに KESTRA_CONFIGURATION としてDB接続文字列(JDBC URL)が直接渡されているかを見る。渡されていれば1.x系のDB直結モデルに該当する

要件との照合: マルチクラウド、オンプレ+クラウドのハイブリッド、あるいは「アウトバウンドのみ許可」というセキュリティポリシーが社内にあるかを確認する。該当する場合、1.x系のままでは拠点ごとのKestraフル複製が必要になっている可能性が高い

これらに1つでも当てはまるなら、2.0への移行検討が現実的な選択肢になります。

対策の手順

2.0では、コントロールプレーンとデータプレーンが明確に分離されました。エグゼキューター・スケジューラー・Webサーバー・インデクサー・ワーカーコントローラーがコントロールプレーン側に残り、ユーザーコードは一切実行しません。実際のジョブ実行はワーカー(データプレーン)が担い、こちらだけをリモート拠点に置けます。

接続方式も変わり、ワーカーからワーカーコントローラーへ、gRPC(Googleが開発したRPCフレームワーク)の永続ストリームを1本張るだけになりました。接続は常にワーカー側から開始され、逆方向の接続は発生しません。ジョブ投入・ログ・メトリクスの往復がすべてこの1本のストリームで完結します。

移行を検討する場合の具体的な手順は次のとおりです。

# 1. 現行バージョンの確認
docker exec <kestra-container> kestra --version

# 2. 2.0のコントロールプレーン用設定でTLS/認証を確認する
#    (client certificate または JWT をワーカー接続の前提にできるか)
# values.yaml や application.yaml 内の worker 関連セクションを確認

# 3. 段階移行の検討: まずステージング環境でワーカーのみを
#    別ネットワークに配置し、gRPCストリームの疎通を確認する

ワーカー側にはDB認証情報を一切持たせない構成に変更できるか確認する
TLS暗号化とクライアント証明書またはJWTによる認証をワーカー接続に設定する
拠点ごとのKestraフル複製をやめ、コントロールプレーンを1箇所に集約できるか検討する
併せて追加された Quotas(フローやネームスペース単位での実行数上限)を設定し、1チームのミスが全体障害に波及しない仕組みを入れる

Quotas の設定は、SRE観点でのSLO設計(サービスレベル目標の達成度を可用性やエラーバジェットで管理する考え方)とも相性がよく、特定フローの暴走がクラスタ全体のエグゼキューターを巻き込む事故(1.x系のForEachループで実際に発生していた)を未然に防ぐ効果が期待できます。

まとめ

Kestra 1.x系の「ワーカーがDBに直結する」設計は、マルチクラウドや閉域網環境でのオーケストレーション導入における実務上の障壁になっていました。

2.0ではコントロールプレーンとデータプレーンの分離、gRPCによる単一方向接続、TLS/証明書認証への対応によって、この制約が構造的に解消されています。

まず自分の環境のバージョンとネットワーク構成を棚卸しし、DB直結が要件と衝突していないかを確認してみてください。該当する場合は、ステージング環境でワーカーだけをリモート拠点に切り出し、gRPC接続とQuotas設定を試すところから始めるのが現実的な一歩になります。