はじめに
データパイプラインの運用負荷削減とセキュリティ向上を目指し、
Google Cloud のマネージド型ワークフローオーケストレーションサービスである
Cloud Composer（以下「Composer」）の導入検証を行いました。
「マネージドになれば、これまで苦労していた運用保守から解放されるはずだ」
「Google Cloud の堅牢な基盤に乗ることで、セキュリティレベルも一段上がるはずだ」
そんな期待を胸に検証をスタートしましたが、実際に手を動かしてみるとドキュメントからは見えてこなかった「現場レベルの制約」や「運用の手応え」が次々と明らかになりました。
本記事では私たちが Composer の検証を通じて得た知見を、忖度なしの「リアルな振り返り」として共有します。
想定読者
- オンプレの Airflow を Composer へ移行することを検討している人
- Composer について、実際に検証したからこそ分かる現場レベルの具体的な課題や制約を知りたい人
検証の背景と当初の期待
現在、私たちのチームでは社内サーバーの仮想環境で Airflow を運用しています。[1]
しかし、長年の運用に伴い、以下のような課題が顕在化していました。
-
ホストOSやミドルウェアのメンテナンス:
セキュリティパッチの適用や、Docker/Git 等のバージョンアップ作業が定期的に発生し、本来の「データパイプライン構築」に割くべき工数が削られていた。 -
Airflowのアップデート:
バージョンアップに伴う依存関係の解消や、DB移行の心理的ハードルが高い。 -
セキュリティの不透明性:
外部通信の制御やアクセスログの管理を、すべて自分たちで設定・維持し続けるコスト。
これらを解決するため、Composer に以下の期待を寄せていました。
-
運用負荷の削減:
- ホストマシンのバージョンアップ不要
- Docker, Git 等ホストで利用する機能のバージョンアップ不要
- コンテナ内の Airflow のバージョンアップ不要
-
セキュリティの向上:
- アクセスログの自動保存
- 通信制御をクラウド側に任せられる
-
コスト:
- クラウド移行に伴い一定の費用が発生することは承知の上で、上記のメリットで十分にペイできる
期待1. 運用負荷の削減について
できたこと
Composer に移行することで、以下のメンテナンス作業は確かに不要になりました。
-
ホスト OS のバージョンアップ:
Google が管理してくれるので、OS レベルのアップグレードを意識する必要がなくなります。 -
Docker / Git 等ミドルウェアのバージョンアップ:
Composer の環境として一体で管理されるため、個別にバージョンを管理しなくてよくなります。
上記の部分については、「マネージドサービスに任せる」という当初の期待通りの効果が得られました。
できなかったこと
一方で、以下の点は期待通りの効果が得られませんでした。
「自動バージョンアップ」の甘い罠
Airflow そのもののアップデートに関しては、想像していたほど楽ではありませんでした。
パッチバージョンの更新はある程度自動化されますが、マイナー・メジャーバージョンの更新は依然として手動操作が必要です。
さらに、バージョンを上げる際には dbt などのライブラリとの互換性チェック、既存の DAG（ワークフロー）が壊れないかの動作確認が必須となります。
結局「開発環境で動作確認をしてから本番に適用する」というフロー自体は、オンプレミス運用と変わらなさそうでした。
むしろ自動アップデートが有効になっていると、「意図しないタイミングで環境が変わり、原因不明の失敗が発生する」というリスクを管理する必要が生じます。
カスタマイズの制限（Embulk の壁）
私たちのパイプラインでは、データ転送の一部に Embulk を利用しています。
しかし、Composer 環境に Embulk を組み込むのは一筋縄ではいきません。
Composer はあくまで Python ベースの Airflow 環境に特化しており、独自のバイナリや複雑な依存関係を持つツールを相乗りさせるのには向いていません。
KubernetesPodOperator を利用するという解決策もありますが、そのためには別途 GKE の管理コストやイメージビルドのパイプラインが必要になります。
これだと、当初の「苦労していた運用保守からの解放」という目的から遠ざかってしまいます。
謎のエラーとの戦い
検証中、DAG が「特に理由もなく失敗し、リトライすると成功する」という挙動に何度か遭遇しました。
ネットワークかそれ以外の裏側のところに原因がありそうですが、特定には至りませんでした
期待2. セキュリティの向上について
Composer に移行することで、「アクセスログが自動で残る」「通信制御をクラウド側に任せられる」といったセキュリティ上のメリットを期待していました。
しかし、検証の結果、現時点の私たちの環境ではそのメリットが十分に活きないことが分かりました。
できたこと
Composer に移行することで、当初期待していたセキュリティ上のメリットは確かに得られました。
-
アクセスログの自動保存:
Cloud Logging により、「誰がいつ何をしたか」の監査ログが自動的に記録されます。
オンプレ環境のように自分たちで設定・運用する必要がなくなりました。 -
通信制御のクラウド委任:
インバウンド・アウトバウンドの通信制御を Google Cloud 側の仕組み（VPC やファイアウォールルール等）で行えるようになり、自分たちで直接サーバーの設定を管理する負担がなくなりました。
オンプレでもよさそうと思ったこと
上記の通り「できたこと」自体は期待通りでしたが、検証を通じて 現時点の私たちの環境ではそのメリットが十分に活きない ことが分かりました。
例えばアクセスログについて言えば、たしかに自動保存は魅力的な機能です。
しかし、そもそも現在のオンプレ環境は社内ネットワーク経由でしかアクセスできない構成になっています。
外部からの不正アクセスリスクが限定的であるため、監査ログを詳細に残す優先度はそれほど高くないと判断しました。
通信制御の観点でも同様に、現時点で追加コストをかけてまで Composer で実現すべきかと言われると、オンプレのままでも許容できる という結論に至りました。
期待3. コストについて
クラウドへの移行に伴い一定の費用が発生することは織り込み済みでしたが、検証してみると想定以上に費用がかかることが分かりました。
基本費用
Composer はオートスケーリングが売りですが、環境を維持するための最低限の料金（環境料金 ＋ 通信費用 ＋ 常に稼働するワーカーのコスト）が意外と嵩みます。
追加費用
実際に検証してみてわかったことですが、オンプレミス環境に比べて全体的に動作がもっさりしていました。
パフォーマンスを求めて CPU やメモリを増強するとダイレクトに利用料へ跳ね返るため、コストパフォーマンスの最適化にはかなりシビアな調整が求められそうです。
コスト面の総括
前章までに述べた通り、運用負荷の削減やセキュリティ向上のメリットが当初の期待ほど大きくなかったため、このコストを正当化するのは現時点では難しいと判断しました。
結論とネクストアクション
結論
上記の検証結果から、私たちのチームは現時点では Composer 導入を見送る こととしました。
ネクストアクション
今後もワークフロー管理をより良くしていくために、以下を検討しています。
- Azure Local（旧 Azure Stack HCI） 上にオンプレミスとして Airflow 環境を再構築する
（データパイプラインの最下流に Power BI レポートが存在し、社内全体のシステムとしても MS 製品との親和性が高い） - バージョンアップなどの作業について、ハードルを下げられるように確認方法を簡易化する（自動テストなど）
おわりに
Composer は強力なサービスですが、自分たちの運用実態や期待する効果と照らし合わせて慎重に導入を検討する必要がありそうです。
特に運用コストを「ゼロ」にできると期待しすぎると、思わぬギャップに苦しむことになるかもしれません。
今回は導入を見送る結果となりましたが、自分たちのメンテナンス工数やセキュリティ管理を見直し、既存の構成を再検討する良い機会になりました。
この記事が、Composer 導入を検討している方の参考になれば幸いです。
Discussion