data pipelineを勢い任せに使ってみたけど無理だった話

# はじめに

以下の要求を満たしたものを使いたい。

- DynamoDBに保存されたデータを定期的にバックアップを行いたい。
- バックアップしたデータをリストアし、元の状態を復元できることを確認したい。
- それらをマネージドなサービスで動かしたい。
- バックアップに特化したスケジュールタスクのサービスであることが望ましい。
- バックアップに成功したか失敗したか、通知してほしい。
- 安い。

それっぽいサービスは以下の通りです。

- AWS Data Pipeline
- AWS Glue (未リリース)
- AWS Batch (未リリース)

Data Pipeline、GlueはETLを行なうものとして考えて作られたサービスのようなので純粋なバックアップのスケジュールタスクというわけではなさそう。
Batchはその名の通り、バッチ処理をマネージドで行なうもののようです。

この内、AWS Data Pipeline でバックアップを行なう流れはどんな感じになるのかを試してみました。

オンプレミスに対しても何かできるみたいだけど今回はAWS上のDynamoDBをバックアップするので、割愛します。

# 料金

2016年12月6日現在の月額料金は以下の通り。

| リージョン | 低頻度 | 高頻度 |
|---------|------|------|
| バージニア北部| $0.60 | $1.00 |
| オレゴン | $0.60 | $1.00 |
| アイルランド | $0.60 | $1.00 |
| アイルランド | $0.5715 | $0.9524 |
| アイルランド | $0.60 | $1.00 |

月額を日本円にすると低頻度は約60〜70円、高頻度は100円〜115円位になります。

- 月前半が低頻度・月後半が高頻度だった場合
- pipelineを作成・即時実行しpipelineを削除、を繰り返した場合

等はどのように課金されるのかはわかりませんでした。

※ 低頻度と高頻度の区別は、1日に1回以上実行するか否か。

## 無料枠
- AWS で実行する低頻度の前提条件 3つ
- AWS で実行する低頻度のアクティビティ 5つ

無料枠の繰越はなし。

# 前提知識
## 登場人物

以下はpipelineの説明に出てくる登場人物の概要です。

| 名前 | 概要 |
|---------|------|
| データノード | タスクの入力データの場所または出力データが保存される場所。 |
| アクティビティ | リソースとデータノードを使用して、スケジュールに従って実行する作業の定義。 |
| 前提条件 | アクションを実行する前に true である必要がある条件ステートメント。 |
| パイプラインのスケジューリング | アクティビティの実行など、予定されているイベントのタイミングの定義。 |
| リソース | パイプラインで定義する作業を実行するコンピューティングリソース。 |
| アクション | アクティビティの失敗など、指定された条件が満たされた場合にトリガーされるアクション。 |

## 事前準備 
### ロールの作成

初めてAWS Pipelineを作ろうとするとIAMに以下２つのロールができるようです。

- DataPipelineDefaultResourceRole

  AWS Data Pipeline が AWS リソースにアクセスすることを許可する。

- DataPipelineDefaultRole

  アプリケーションに AWS リソースへのアクセスを許可する。

### バックアップ用のバケットを作成

適当なバケットを作成しました。

### バックアップする対象のテーブル・テストデータの作成

DynamoDBに```Myuon.DataPipeline.BackupTarget``` というテーブルをバックアップ対象として作りました。

リージョンはバージニア北部、入っているデータはとりあえずの１レコード。以下のとおりです。


<img width="1425" alt="スクリーンショット 2016-12-06 21.34.22.png" src="https://qiita-image-store.s3.amazonaws.com/0/147387/b56b757f-f568-42f4-9f79-a640c8262654.png">

# 作ってみるの巻
## 利用するもの (想定)

- ノード
	- DynamoDBデータノード
	- S3データノード

- アクティビティ
	- 不明

- 前提条件
	- 不明

- アクション
	- 今回は割愛。

条件を設定してDynamoDBデータノードとS3データノードを作成し、それらをアクティビティでつなぐとバックアップされるのだろうか・・・。

## 実際の作業（現実）

最初はこんな感じの画面でモロモロ入力するようです。

<img width="1067" alt="スクリーンショット 2016-12-07 22.34.33.png" src="https://qiita-image-store.s3.amazonaws.com/0/147387/1fa2e75d-4f10-b208-c9d4-1c36c8c363d0.png">

### パイプライン作成

- 一番上セクション

| 項目名 | 値 |
|---------|------|
| Name | backup.dynamodb.Myuon.DataPipeline.BackupTarget |
| Description (optional) | Myuon.DataPipeline.BackupTarget のバックアップ |
| Source | Build using a template > Export DynamoDB table to S3 |

DynamoDBをS3にバックアップするpipelineのテンプレは用意されているようです。

<img width="425" alt="スクリーンショット 2016-12-06 21.38.51.png" src="https://qiita-image-store.s3.amazonaws.com/0/147387/f66d5279-5fb0-2bcd-2c71-9ba87e43b417.png">

- Parametersセクション

| 項目名 | 値 |
|---------|------|
| Source DynamoDB table name | Myuon.DataPipeline.BackupTarget |
| Output S3 folder | s3://xxxxxxx.dynamo.backup/ |
| DynamoDB read throughput ratio | 0.25 |
| Region of the DynamoDB table | us-east-1 |

raitoの部分は何を設定するのが適切なのか分からないため、デフォルトでセットされている値を採用しました。

- Scheduleセクション

| 項目名 | 値 |
|---------|------|
| Run | on pipeline activation |

取り急ぎ実行するため、on pipeline activationにしました。

- Pipeline Configurationセクション

| 項目名 | 値 |
|---------|------|
| Logging | Enabled |
| S3 location for logs | s3://xxxxxxx.dynamo.backup/logs/ |

ログを出力する場所を設定しました。

- Security/Accessセクション

| 項目名 | 値 |
|---------|------|
| IAM roles | Default |

これは良くわかりませんが誘われるまま。

- 一番下セクション

<img width="1037" alt="スクリーンショット 2016-12-06 23.04.27.png" src="https://qiita-image-store.s3.amazonaws.com/0/147387/f697713f-d07c-cf43-dc39-57a8b411fa9b.png">

え？EMRを使うよ、とかいってますね。

どうも、スケジュールしたタスクを実行するにはAWSの特定のリソース上にTaskRunnerというアプリをインストールする必要があるようです。

ざっと調べた感じだとEC2、EMRにタスクランナーがインストールできるようです。

ECSで必要な時に起動するようなタスクランナーをインストールするのがいいのでしょうか。
自分の想定やマニュアルと結構違いますが、進みます。


- Edit in Architect！

う・・・。

<img width="1450" alt="スクリーンショット 2016-12-06 23.13.31.png" src="https://qiita-image-store.s3.amazonaws.com/0/147387/bdc9c6c9-1988-d2c0-9faa-ff33cf780851.png">

いきなりワーニングがでてるオーサリング機能が表示されました。

<img width="757" alt="スクリーンショット 2016-12-06 22.36.51.png" src="https://qiita-image-store.s3.amazonaws.com/0/147387/b070939a-4220-60ce-f30c-1bad4f654218.png">


マニュアルが古いのでしょうか？全然画面が違います。
以下がマニュアルにある、画面です。

<img width="795" alt="スクリーンショット 2016-12-06 23.07.31.png" src="https://qiita-image-store.s3.amazonaws.com/0/147387/42483960-d456-b365-acec-7a9f9263df85.png">

とりあえずワーニングを解消します。

terminateAfterはよく調べてませんが、恐らくバッチ処理の終了を永遠に待たないように一定時間をすぎたら何かのリソースをterminateする設定なのだと思います。

<img width="648" alt="スクリーンショット 2016-12-06 23.15.30.png" src="https://qiita-image-store.s3.amazonaws.com/0/147387/3bfe20da-d9c7-9a8f-7279-27e92222d4ac.png">

default value is m1.small とかいってるわりに m3.xlarge とか設定されてます。

<img width="547" alt="スクリーンショット 2016-12-06 23.18.32.png" src="https://qiita-image-store.s3.amazonaws.com/0/147387/99b097ae-86dc-7b8e-8487-303c08fcef9e.png">

m1.smallに変えてsaveしたら今度は以下のエラーがでました。

<img width="403" alt="スクリーンショット 2016-12-06 23.16.42.png" src="https://qiita-image-store.s3.amazonaws.com/0/147387/569e4f02-4f1e-65a5-904b-483233eb2ca5.png">

m1.mediumに変えてsaveしたら通りました。

<img width="666" alt="スクリーンショット 2016-12-06 23.22.50.png" src="https://qiita-image-store.s3.amazonaws.com/0/147387/6015db94-aea8-f7ed-852e-5a1ef03d136e.png">

# なにはともあれ実行！

activateをクリックします。

```WAIT_FOR_RUNNER``` というステータスのままで、生気が感じられません。

<img width="1449" alt="スクリーンショット 2016-12-06 23.23.59.png" src="https://qiita-image-store.s3.amazonaws.com/0/147387/dedb5ccf-a1dc-4902-aa57-77ab7989285a.png">

もしやと思い、EMRのコンソールとEC2のコンソールを見たら案の定、出来てます。

うぉー。EC2に至ってはmasterがx1.mediumでslaveがナントカlarge(！！！)です。

このままほうっておくと、お金がどんどん掛かりそうなのでEC2を停止し、EMRも削除しました。

こうして、直感的にすすめたバックアップ作業はRTFMな失敗に終わりました。

次回、TaskRunnerの概念をもう少し学んで再挑戦します。