AWS再入門 AWS Data Pipeline編

AWS Data Pipeline

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

当エントリはDevelopers.IOで弊社AWSチームによる2015年アドベントカレンダー 『AWS サービス別 再入門アドベントカレンダー 2015』の24日目のエントリです。昨日23日目のエントリはせーのの『Amazon Simple Workflow Service』でした。

このアドベントカレンダーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

本日24日目のテーマは『AWS Data Pipeline』です。Data Pipelineって名前は聞いたことあるし、なんかデータ連携するサービスってことは知っているけど・・・的な方々に、具体的にどのような仕組みでどんなことができるのかをサクッとご説明したいと思います。
正直、すべての機能を使いこなすには、ETL処理用のプログラム開発やEMRの利用方法等を理解する必要があるため、それなりに奥深いものがありますが、そもそもあまり利用されていないのが現状かと思いますので、まずは触ってもらえるように今回のエントリーを書いてみたいと思います。

目次

サービスの基本的な説明

まず、Data Pipelineに関するAWSの公式な説明は以下の通りです。

AWS Data Pipeline は、指定された間隔で、信頼性のあるデータ処理やデータ移動(AWS のコンピューティングサービスやストレージサービス、ならびにオンプレミスのデータソース間)を行うことができるウェブサービスです。AWS Data Pipeline を使用すると、保存場所にあるお客様のデータに定期的にアクセスし、そのスケールで変換と処理を行い、その結果を Amazon S3、Amazon RDS、Amazon DynamoDB、Amazon Elastic MapReduce(EMR)のような AWS サービスに効率的に転送できます。

AWS Data Pipeline により、耐障害性があり、繰り返し可能で、高可用性を備えた、複雑なデータ処理ワークロードを簡単に作成できます。リソースの可用性の保証、タスク間の依存関係の管理、タスクごとの一時的な失敗による再試行やタイムアウト、失敗通知システムの作成などについて心配する必要はありません。また、AWS Data Pipeline により、オンプレミスのデータ格納庫に保管されていたデータの移動および処理も可能です。

引用元:Amazon Data Pipeline (データワークフローオーケストレーションサービス) | アマゾン ウェブ サービス(AWS 日本語)

Data Pipelineというネーミングだけあって、データ移行に関するサービスであろうことは上記の説明でも十分イメージは掴めると思います。
そんな中、あえて簡単にまとめると以下がポイントかと思います。

  • AWSのマネージドサービスである
  • ノード間でのデータ移行やETL処理を実行することができる
  • 一般的なスケジューラの機能を持っている(時間指定やサイクリック、依存関係設定など)
  • オンプレの処理にも使える

ここで一点覚えておく必要があることとして、Data Pipelineはあくまでデータ移行に関するベースの機能を提供してくれるものだということです。
データの変換と加工については、別途プログラミングが必要になってきます。サードパーティーの同様なプロダクトでは、データ変換や加工の処理について汎用的なものは標準機能として備わっていることが多いですが、Data Pipelineではそこはほぼ作り込みが必要だと考えてもらった方がいいと思います。

AWS Data Pipelineの特徴

AWSのマネージドサービスである

もし仮に、データ移行やETL処理を自前で行おうとした場合、実現までにはいくつかのステップを踏む必要があります。
まずは処理を実行するための基盤が必要になります。次に実行環境のソフトウェアを準備します。スケジュール実行もしたいので、スケジューラーも必要です。そして、それらの管理、保守も・・・。処理ロジックの設計をする前に、考えなければいけないことは山ほどあります。
これらをAWSが肩代わりして、Data Pipelineというマネージドなサービスとして提供してくれることで、やりたいことの中身を検討することに集中できます。マネージドサービスって素敵ですね!

データ移行やETL処理を実行することができる

Data Pipelineでは、開発用のGUIが提供されており、AWSサービス間の単純なデータ移行くらいであれば、簡単なマウスとキーボードの操作だけで処理を作り、実行することができます。
また、一方で、複雑な変換や加工の処理を実行したい場合でも、自前で開発したプログラムをData Pipelineで実行させることができ、それなりの自由度も兼ね備えています。

一般的なスケジューラの機能を持っている

Data Pipelineでは、複数に分割されたデータ移行やETL処理を連携して実行することができます。また、それらを意図した時間に実行することができます。もちろんサイクリック実行も可能です。
処理がエラーになった場合のアクションも設定することができ、アベンドの検知も可能です。

オンプレの処理にも使える

Data PipelineはAWSのクラウドサービスでありながら、オンプレの処理も実行することができます。
Task RunnerというJavaのプログラムをインストールするだけで、オンプレのサーバだとしてもData Pipelineで扱うことができるようになります。

ユースケース

ここまでの説明でなんとなくData Pipelineのイメージが掴めてきたのではないかと思いますので、簡単なユースケースを挙げてみます。

datapipeline_usecase

データ分析のために、既存のRDBからRedshiftにデータを投入したい場合の利用パターンです。
既存のRDBからはS3に対してソースデータをエクスポートし、Redshiftのテーブルに合わせて変換と加工を加え、最終的にRedshiftにインポートします。これは割とよくある処理フローだと思いますが、Data Pipelineを効果的に利用できるユースケースだと思います。

基本知識

では、さっそく具体的な操作ですが、まずは以下のスライドでサラッと用語等を確認してみてください。


なんだかピンとこないキーワードがたくさん出てくると思いますが、GUIを操作した時にキーワードが頭に入っていないと、理解がしにくいと思うので、ここは少し我慢してください。
(実際に操作しながら調べるのもいいですが、インプットしてからの経験の方が学習効率がよかったりしますよ)

以下の弊社ブログエントリーも用語を理解するのを助けてくれると思いますので、ぜひ読んでみてください。

はじめてみよう

それでは早速始めてみましょう。
・・・といっても、もうすでに操作に関する情報は弊社ブログエントリーで紹介させてもらっています。

古いエントリーも含まれていますが、実はData Pipelineはそこまで大きなアップデートは少なく、上記の情報でも十分参考にはなると思います。

なので、私の経験から、初めて触る時に覚えておいた方がいいポイントをいくつか紹介したいと思います。

まずは1回だけ実行するスケジュールを

最初にパイプラインを作成する際に、デフォルトでサイクリックのスケジュールになっていると思いますが、まずはonce on pipeline activationをお薦めします。

dp_01

理由としては、実際に処理を作り始めてみると分かるのですが、慣れるまではいろいろな理由で処理が失敗します。その際に、例えば15分のサイクリック等にしていた場合、前の処理が失敗で終わっていて、原因を調査している間に次の処理が走り始めてしまい、ややこしいことになるからです。

リソースの設定は慎重に

リソースでは、Ec2ResourceEmrClusterのどちらかを選択することになりますが、オプション設定をあまりせず、デフォルトの状態で実行すると思いがけない動作をすることがあります。といっても、仕様通りの挙動なのでそれ自体は問題ないのですが、imageIdinstanceTyperegionなど、意識した方がいいオプションが多いので、注意しましょう。

実行の詳細情報を確認する時はフィルターとタイムラグに注意

Execution Detailsの画面を確認する際は、まずフィルター設定に注意してください。
表示期間とコンポーネントの項目は、最低限見たい情報が表示されるように調整する必要があります。

dp_02

そして、ステータスの状態やログの出力については、少しタイムラグがあります。
Data Pipelineでは、バックグラウンドでいろいろな処理が走っているようなので、あれっと思ったら少し待ってみてください。情報がワンテンポ遅れて出てくることがあります。

パイプラインの状態が分からなくなったら複製して再作成

上記でも記載しましたが、Data Pipelineはバックグラウンドでいろいろな処理が走っています。そのため、処理が失敗した場合や思い通りにならなかった場合、パイプラインの状態がどうなっているのか分からなくなってしまうことがあります(経験談)。
そうなった場合は、潔くそのパイプラインは無効化(処理もキャンセル)し、そこから複製してもう一度別パイプラインとして作り直しましょう。もちろん原因調査も重要だとは思いますが、経験上、そこは割り切った方が効率的だと思います(深追いはあまりお薦めしません)。

まとめ

さて、今回は、最適な情報かどうかは怪しいところもありますが、経験談を入れてみました。
個人的に、Data Pipelineは少し癖があるサービスかなーと思っていますので、使い慣れるまでは苦労するかもしれません。が、自由度が高いサービスなので、使いこなせればかなり強力なツールになってくれると思います(信じてます!)。

さいごに

以上、『AWS サービス別 再入門アドベントカレンダー 2015』の24日目のエントリ『AWS Data Pipeline編』でした。

明日12/25(金)のクリスマスは、再度せーののAWS IoTです。メリークリスマス&お楽しみに!