こんにちは。
最近仕事でAWS Data Pipelineを使う機会があったので、その機能についてまとめます。
AWS Data Pipelineとは
AWS Data Pipelineとは、一言で言うとAWSが提供するAirflow、みたいな感じになると思います。
AWSのS3やDynamoDB、Redshiftなどといった代表的なデータソースとも連携ができ、cronのようなジョブスケジューリング機能や、ジョブの依存関係や実行環境の定義、ジョブの実行のためのリソース(EC2・EMR)の起動と停止、コンソール上から処理実行のStatusの確認・リトライができます*1。
もちろんフルマネージドなので、cronの監視みたいな、「ジョブの監視の監視」みたいなこともしなくていいです。笑
典型的なユースケースに対しては、すぐに試せるようにTemplateも用意されていて、例えばRDSからS3にデータをコピーしたい場合などは、いくつかの設定をするだけで、実現することができます。
利用シーン(Airflowとかとの違い)
ここまでの話だけ聞くと、「じゃあAirflowと何が違うの？Airflowじゃダメなの？」ってことになると思うのですが、使っている所感としては、「使っているクラウドがAWSに閉じていて、且つ小規模にデータパイプラインを作りたい場合」には、AWS Data Pipelineはいいかなと思います。また、Pythonなどがチームのメインの言語ではない場合も、定義ファイルはJsonでコードはほぼSQLとシェルから好きな言語を使うとかができるので、Airflowなどに代表されるPythonでDAGを定義するなどもなく、有効です。
利用シーンとしては、以下の記事にあるように、データがRDSに入っていて、RDSからS3にData Pipelineでデータを定常的に持ってきて、そこからAthenaで分析するといった場合は有効かなと思います。
そのほかにも、例えば以下のようなシチュエーションが考えられます。
- 複数のデータソースにあるデータを「労力をかけずに」まとめて、定常的に分析したい場合
- AWS Data PipelineのTemplateで用意されているような典型的なデータパイプラインに加えて、プラスαの処理内容で済みそうな場合
- 複雑なデータパイプラインを作るまでの規模ではなく、ごくごく少人数でデータパイプラインの構築・運用をする必要がある場合
使っている感覚ですが、条件に応じた動的なパイプラインの制御や、タスクの依存関係が大きくなった場合などにおいては、自前でAirflowなどを立てて運用するなどが良いと思います。大規模になっていくと、ジョブの依存関係などを把握するのがツライと思います*2。
ちょっと癖があるのも事実ですが、1人〜2人でメインで運用しないといけなくて、データソースがそれほど多くならず、とりあえずパイプラインを作れればいいみたいなシチュエーションにおいては、Data Pipelineは有効かなと思います。
料金
料金は以下より。例えば東京リージョンで、1日に一回くらいの頻度であれば、約0.57$なので、めちゃめちゃ安いです。これに加えて、実行時に使用するEC2やEMRの代金は別でかかります。
実際にやってみる
0. 今回作るパイプライン
今回は、RDSにあるデータベースのテーブルをS3にコピーするパイプラインを実際に作ってみたいと思います。
1. データパイプラインの初期設定をする
それでは、実際にデータパイプラインを作ってみます。まずは、コンソール上から、data pipelineのサービスのところに飛びます。初めて作る場合は、以下のようなページになると思います。
「Get started now」からPipelineの初期設定ページに飛びます。すると、以下のような画面が出てきます。
ここで、「Source」のところから、以下の三つのうちのどれからPipelineを作成するかを選びます。
- Build using a template：あらかじめ用意されているTemplateから作成する場合
- Import a definition：JSONによる定義ファイルから作成する場合
- Build using Architect：AWSのコンソールから編集する場合
今回は、「Build using a template」に今回作りたいパイプラインのものがあるので、これを使います*3。他には、以下のようなTemplateが用意されています。
このtemplateと似ているけどちょっと違うとかであれば、templateから作るのが最初はいいと思います*4。作ったパイプラインの定義は、「Architect」からExportすることができるので、コードベースで差分を管理したい場合などは、これを利用するのがいいと思います。既存のパイプラインに読み込みをさせることはできないみたいですが。。。
次に、実行のスケジュールやログをS3のどのバケットにおくか、IAM Rolesの設定をします。実行環境によっては、この設定をちゃんとする必要があるのですが、それについては少し長くなるので別の記事で書きたいと思います。ここまできたら、「Edit in Architect」を押します。
すると、以下のような画面が出てきます。左側にパイプラインの各コンポーネントとフローが描かれ、右側に各コンポーネントの詳細な設定を行うことができる画面があり、下にパイプラインの設定に関するWarningやErrorがでるコンソールがあります。各コンポーネントの詳細や設定方法については、下の「使い方の参考」のところにいくつかリンクを貼っておきますので、そちらをご参考ください。
これらを設定して、うまくできたと思ったら、「Activate」ボタンを押して、実際に動かします。ボタンを押すと、以下のようにどのActivityが今どの状態かがわかる画面に遷移します。ここでジョブの状態やキャンセル、再実行などをすることができます。
使い方の参考
Data Pipelineの構成要素
上の「実際にやってみる」のところでいくつか出てきた構成要素については、以下の記事が参考になると思います。
terraformの対応状況とコードの管理方法
terraformを使ってインフラの管理をしている人はきになる対応状況ですが、以下のリンク先にあるように、現時点では外側の箱だけ作ることができるようです。
なので、terraformを使って箱だけ作って、あとはjsonでpipelineのフローを管理しつつ、aws cli経由でpipelineのアップデートをするようにするか、jsonとcliだけでやるかの感じが今の所思いついているものです。
コードをファイルから実行したい場合などは、S3に置くのがdata pipelineだとルールなので、コードとかもjsonと一緒にセットでgitとかで管理するようなイメージになると思います。
参考
以上になります。それでは。
