「AWS Black Belt Tech Webinar 2014 – AWS Data Pipeline -」レポート #jawsug

「AWS Black Belt Tech Webinar 2014 – AWS Data Pipeline -」レポート #jawsug

Clock Icon2014.11.26

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

2014年11月26日(水) 18:00 - 19:00に「AWS Black Belt Tech Webinar 2014 - AWS Data Pipeline -」がオンライン上で開催されました。AWS Data Pipelineはサービス自体興味を持っていたものの、実案件に導入・本格稼働するまでのフェーズには達していなかった部分もあったりしている現状がありましたので、その辺り現状どこまで実利用に踏み込めるものなのか、という観点を持ちながら1時間聴講していました。当エントリではその内容についてざっくりまとめとしてレポートしたいと思います。

講師はアマゾンデータサービスジャパンの今井 雄太さんです。

目次

1.ビッグデータを活用するために必要なこと

ビッグデータをゴミの山にしないために、これらのサービスを有効的に組み合わせて使う必要がある。ちなみに正直言うと、だいぶマイナーなサービスではある、との事(ちょw まぁ確かにビッグデータを扱うような環境で無ければ率先して触る事が無いのかも知れないですね...)

データ活用における『4つのステップ』

1.あつめる

  • クライアントマシンから/デバイスから/ログファイルから...と入力元は多岐に亘る。

2.ためる

3.処理する

  • データを利用するための前処理。ETLを経てWebアプリケーションや分析ツール等で利用する形に整える。
  • 『一次集計』を行うような処理もここに含まれる。

4.利用する

  • BIツールで利用するフェーズがこの部分。データをAPIで提供する事も

ETL

『ETL』は以下フレーズの略称。前述『4つのステップ』のうち『1.あつめる』『2.ためる』『3.処理する』の部分で用いられ、データ活用の側面で非常に大きな比重を占めている作業となる。

  • E:Extraction(抽出)
  • T:Transform(整形)
  • L:Load(ロード)
  • ETLはめんどくさい:
    • モノリシックなパイプラインは次第に『秘伝のタレ』へと変貌する羽目に...
    • 複数ホスト間での整合性の保証が求められる
    • エラーハンドリング
    • スクリプトやプログラムで条件・要素をハンドリングしていくのも状況やボリュームによっては辛くなる事も。出来ることならやめたいところ...
    • データのマイグレーションは重要な位置を占めるが、簡単なものでもない。
    • 依存処理が複雑:入力データの有無判定や前処理の正常終了に伴う判定等
    • 異常処理における各種制御(リトライ・タイムアウト・通知)も同様。

2.AWS Data Pipelineの紹介

  • そんなところに『AWS Data Pipeline』。
  • AWS Data Pipelineはサービス間のデータ統合・処理をスケジュールベースで自動化してくれるサービス。
  • 利用には以下の手順を踏む必要がある。
    • 1.データ:データソースや出力先の定義を行う
    • 2.アクティビティ:処理の内容を定義。
    • 3.スケジュールと依存関係:処理の依存関係と実行スケジュールを定義。
    • 4.通知:イベントの通知先定義。
  • AWS Data Pipelineはオンプレミス環境との連携も可能だったりする。

ワークフローを定義する為の登場人物

  • Data Nodes
    • データの場所、フォーマット。
    • Input/Outputデータの場所やタイプを定義する。フォーマットの指定はカスタマイズ可能。
    • データにアクセスしやすくする仕組みの一つとして、データとテーブルのステージングがある。
  • Activity
    • データ処理の実行単位。
    • データ移動や処理の全体を管理している。AWSとオンプレミスにて実行可能。
  • Scheduling Pipelines
    • 処理実行のスケジュール。
    • 処理を実行するタイミングとして、以下が選択可能。
      • Cronスタイル(指定した間隔のstart時点で起動)
      • Time Seriesスタイル(指定した間隔のend時点で起動)
    • 実行間隔の最短単位は15分、最長単位は3年。
    • Backfill(埋め戻し)タスクに対応。
    • タイムゾーンは任意の値に変更が可能。
  • Resources
    • 処理や条件チェックを行うリソース。
    • EC2-Classic及びEC2-VPC、EMRが対応。
    • マルチリージョンのリソース管理が可能。
    • アクティビティとリソースのスケジュール管理を別々に指定する事も出来る。リソーススケジュールを1時間間隔で、Activityスケジュールを20分間隔で設定する、というような形でリソースを最大限に利用する使い方が出来る。
  • Preconditions
    • 処理実行の条件。
    • 条件が成立した場合のみ、後継タスクを実行出来る。(以下例)
      • DynamoDBテーブルの有無
      • S3のキーが存在
      • S3のプレフィックスが存在
      • 独自のShellコマンド実行が成功
      • 依存しているPipelineタスクが成功
  • Actions
    • 通知を送る方法。
    • イベントは成功時・失敗時・遅れが発生した場合に起こる。
    • 設定可能なアクション:SNS通知、リソースの削除
    • 失敗時の自動リトライは初期値:3、変更は1〜6の範囲内であれば設定が可能。
  • 料金体系:
    • アクティビティ、または依存関係の従量課金。(1日1回以上の利用であれば高頻度、そうでない場合は低頻度料金となる)
    • 実際に利用したリソース(EC2やS3等)の課金。
  • AWS Data Pipelineがもたらしてくれるもの:
    • 分離
      • データ処理とリソースの分離
      • 処理リソースと処理ロジックの分離
      • 処理ロジックとスケジュールの分離
    • 統合
      • 分散環境での整合性
      • 一貫したエラー処理や処理のやり直しが可能に

3.AWS Data Pipelineの活用

  • ShellCommandActivityを使いこなそう
    • S3に配置したShellスクリプトを指定したリソース上で実行してくれるアクティビティ。
    • どこで使うか?
      • リソースへのライブラリ配布
      • 予め用意されているEC2やEMRのアクティビティだと設定に手の届かない作業に利用
      • 基本、ただのシェルなので利用用途は無限大に。
    • Task Runnerは既存EC2やオンプレミスサーバ上でも稼働可能。
  • ハマりどころ、使いどころ
    • Data Pipelineはスケジュールドリブンの処理を便利に実装・管理するためのサービス。
    • イベントドリブンの処理がやりたいのであれば、AWS Lambda等の検討を!AWS Lambda
  • まずは何より、始めてみよう。主だった作業については以下チュートリアルが用意されている。
  • AWS Data Pipelineのサードパーティ製ツールについて:

まとめ

  • データを活用するにはETLが重要。
  • モノリシックなデザインは避け、プラガブルなETLを目指すべき。
  • AWS Data Pipelineを使えば、ETLの実装や運用管理を省力化出来、プラガブルなものにしてくれる。

総括

以上、黒帯Webinarレポートでした。極論を言ってしまえば『ShellActivityを使えば何でも出来る』ので、その辺りどこまでと踏み込むか(シェルプログラムとData Pipelineの利用局面の判断)、またどういう粒度や条件でフローで管理するか等の見極めが肝になってくるのかなぁと思いました。S3に全てリソースを配備し、Data Pipelineから指定する管理方法を採る事でリソースの一括管理も行えるので、その点については(まとめにも記載があるように)だいぶ楽になる部分なのかな、とも思います。何はともあれ、実際に使ってみないと!ですね。使ってみたい局面は幾つか想定しているものがあるので、少しずつ適用させてみてその案配を確認してみたいと思います。こちらからは以上です。

2015/09/14 追記:

2015/09/14に以下のWebinarレポートが新たに投稿されました。当エントリの内容をアップデートした形となっておりますので、併せてお読み頂けますと幸いです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.