脱ベンダー依存！Composer でデータ連携を自動化するメリット、デメリット（2年間で障害ゼロ）

数年前、Google Cloud の Composer を使って、あるお客様のデータ連携プラットフォームを構築しました。
結論から言うと、Composer によるデータ連携の自動化は全く問題なく、稼働からこれまで一度も障害は起きていません。
実際使ってみて、以下のような悩みや課題を解決するには、うってつけのサービスだと思います。

• 特定のベンダーに依存したくない
• データ連携の手動・属人的な部分を無くしたい
• 既存のデータ連携システムが古く、障害や遅延が多く発生しているため刷新したい
• ハイブリッド/マルチクラウド環境にまたがるデータ連携パイプラインを作成したい
• スケジューリング機能やリトライ処理が充実したツールが良い

ただ、構築時やその後の運用で課題もあったので、その辺も含めメリット、デメリットをまとめてみました。
データ連携の自動化を検討されている方に、参考にしていただければと思います。

Composer とは

Composer とは、Google Cloud 上で ワークフロー管理ツール「Apache Airflow」を使うためのサービスです。ワークフローとは、データの操作タスク（取り込む、加工する、流し込む）を組み合わせて、DAG（有向非巡回グラフ）として定義します。

要するに、Composer を使えば、Google Cloud 上に、データを自由に操作＆完全自動化できるサービスを作れる、ということです。

Apache Airflow は UI が比較的親切で、慣れていない人でも直感的に操作しやすいと思います。スケジューリング機能やリトライ処理も充実しています。

DAGを開くと、タスクの流れ、ステータスなどをみることができる

※上のスクショはComposer1のものなので少し古いです。Composer2 からは Airflow UIがガラッと変わってもう少し良い感じになっています。

データの入出力については、Google Cloud 内外問わず、タイムリーにデータを連携することができますが、弊社では管理のしやすさ、構築のしやすさもあり、基幹システムからの連携ファイルを一旦 Cloud Storage に置いてもらい、それを取り込んで加工して BigQuery に流し込むよう実装しました。

Cloud Composer メリット、デメリット

メリット① 基本、一度作ってしまえばあとは基本放置でOK
Composer はモニタリング、スケジューリング機能が充実しており、データを取り込み、DBに流し込む、バックアップを取る、などの処理を DAG として定義しておけば、あとは自動で動き続けてくれます。また、仕様や作りによるかもしれませんが、弊社では障害もゼロで、リリース後は全く手のかからないサービスになりました。
（はるか昔、まだ人も神も地上で共存していた頃は、割と頻繁にハードウェアが原因の障害が起きて、データセンターまで駆けつけたり、なんてことをしていました。クラウド最高です涙）

担当者が手動でデータを自分のPCにダウンロードして、エクセルで加工して、サーバーにアップロードする（あるいは DB に入力する）、という作業が丸っと自動化できます。連携タイミングの変更やIF仕様の変更なども、DAG を修正することで即時対応が可能です。

メリット② 負荷に応じてコスト削減が可能（Composer2 から）
ワーカー数を負荷に応じて自動でスケールさせられるようになったため、何もせずとも、低負荷時のコストを削減できます。

メリット③ 拡張性、安定性、互換性は抜群（Composer2 から）
Composer は GKE Standard 上に構築されています。そのため、Kubernetes の Node を実行する vCPU やメモリーをマシンタイプの中から選ぶことで、いつでも拡張が可能です。
なお、このような環境構築後のマシンスペック変更が出来るようになったのは Composer2 からで、Composer1 では環境構築後は変更不可なのでご注意ください。まぁこれから構築する場合は Composer1 は選択できないので、あまり意識する必要はないかも。

デメリット① 非エンジニアにはちょっとハードルが高い、かも
これは Composer に限った話ではなくどんなシステムでも言えることですが、完全自動化した代わりに、移動や退職などで「わかる人」が少しずついなくなってしまう可能性があります。
Composer2 になって直感的に使いやすくなったとはいえ、裏の仕組み自体は GKE、GAE、BigQuery、Storage、Dataflow と様々なサービスが絡んでいて複雑ですし、DAG（ワークフローの定義）にも Python を使用しており、非エンジニアにはハードルが高いかもしれません。

Composer まわりの構成例

何かあった時、一度もComposerを触ったことがない人が対応しなければならない、という事態も考えられなくはないので、引き継ぎ資料だけでは不安が残ります。

弊社では、データ連携プラットフォームを Composer で構築した後、保守運用の一環として勉強会を定期開催し、お客様の担当部署の方々のスキル・知識の底上げもサポートさせていただきましたが、やはり他の Google Cloud サービスと比べて取っ付きにくそうでした。公式ページの「特定のベンダーに依存しない」「使用も簡単」は嘘ではないですが、誰でも簡単に使える、という感じではないのかなというのが正直な感想です。

デメリット② ジョブの失敗の通知、Composer のアップデート通知がデフォルトでは来ない
失敗したらメール通知、はジョブ内で実装する必要があります。ちなみに、親切にコードサンプルが公式ドキュメントに載っているので、参考にできます。

また、Composer のアップデート通知はデフォルトでは来ないので、定期的（少なくとも年１回くらいは）に担当者がチェックする必要があります。自動アップデートもないです。なので、気づいたらサポートが切れていた、ということもあるので注意したいところ。
ちなみに、Composer アップデート自体はワンクリックでできるので、特に心配する必要はないです。アップデートしたら動かなくなった、というのは弊社では今のところ起きていません。

Composer1 から Composer2 への移行はできる？

できます。

こちらはワンクリックで、という訳には流石に行きませんでしたが、Composer2 で新規に作成した環境に、Composer1 で使っていたファイル群（DAGファイル※、BigQueryスキーマ定義ファイル、データ加工定義ファイル）を移すだけで、問題なく動きました。
※DAGファイルは数行直す必要がありましたが、基本はそのまま使えました。

AireFlow UI で表示されるタイムスタンプが、Composer1 の時は協定世界時（UTC）しか対応しておらず、9 時間を足して日本標準時（JST）に読み替えるのが地味に面倒でしたが、Composer2 からは JST への切り替えもできるようになりました。

数年前、Composer1 で構築してて微妙だなと思っていた点が、Composer2 ではほぼ改善されていて日進月歩、すごいなとー思いました。

まとめ

• Composer を使えば、特定のベンダーに依存せずにデータ連携を自動化できる
• 負荷に応じてコスト削減ができたり、拡張ができたりする
• 非エンジニアだけでの構築や運用はハードルが高い