AWS Step Functionsの概要と使用例と感想をまとめました

1. AWS Step Functionsを使った
バックアップシステム
2017/6/2

2. 構想
・ S3にアップロードするにはファイル属性データの管理や圧縮するコストが必要
・バックアップ対象が多いとStorage Gatewayは使いづらい
・EC2 Instanceを立ててrsyncするのが一番よさそうだが、EBSの課金がかなり大きい
↓
・データソースはLVMのSnapshotを使う
・sc1タイプのEBSが使えればかなり費用が抑えられる $0.03/GiB
・Snapshotの料金がタイミングよく下がっていた $0.095/GiB → $0.05/GiB
・バックアップが終わると同時にきっちりinstanceを破棄して無駄なコストを抑える
・世代管理はEBSのスナップショットを使う
・オンプレミスで運用されているサーバーのデータをAWSにバックアップする仕組みの構築
・社内サーバーにある大量のバックアップデータのマイグレーション
・日次バックアップ処理が6時間以内で完了すること
・世代管理ができること & 30世代を保持しておきたい
・ファイルパーミッション・リンクの維持
解決したい課題と要件

3. 移行前のBackup構成図
OpenVZ server
rsync
データ領域の
LVMのsnapshot
を取る
rsync
rsync
Backup server
zfs領域にデータを受け
取り、zfsのsnapshotで
世代管理
約50TBのバックアップデータ
オフィス
データセンター
同期が終わった後は、
LVMのsnapshotは破棄
問題点
・Backup serverの運用コストが大きい
・DCが拡張した場合に対応が難しい

4. AWS Step Functions
アプリケーションのコンポーネントを一連のステップとしてコーディネートできる。
State Machine(マシン状態 )を定義し、ステップのワークフローを可視化できる。
State MachineにはStateと呼ばれる状態とトランザクションをセットで定義する。
Stateは直列や並列に定義することができ、並列のときは次に進む前に全てのStateが
完了している必要がある。
AWSのリソースだけでなくオンプレミスで稼働するアプリケーションとも連携できる。

5. State Machineの定義
１．インスタンス起動
２．並列でバックアップ実行
３．インスタンス終了
４．スナップショット取得
５．古いスナップショットの削除
６．Mattermostに通知

6. Parallel State
バックアップ処理の実行は並列で行われる
それを実現するのがParallel State
バックアップにかかる時間はそれぞれだが、
Parallel Stateでその差を吸収し、全ての並列タスクが
完了してから次のStateに遷移する。
それぞれのStateのoutputをリストにしたものが
次のStateにinputされる。

7. Activity Task
Task Stateには任意のLambda Functionまたは
Activityが指定できる。
右の図で囲まれている部分はActivityが指定されている
Task Stateである。
Activityを実装したワーカーはこのStateが実行
されている間にタスクを実行する。
State MachineとActivityのやり取りには task token
と呼ばれるトークンが使用される。

8. ・Fail State
−Fail Stateに遷移すると実行履歴に明示的に
「失敗」として記録される
−コンソールから失敗が確認しやすい
・Catchセクション
−State内でエラーが発生した時、
次に遷移する先を指定できる
−右の図の場合、CatchAllFallbackを指定している

9. WorkerとState Machineの関係
Workerの数だけActivityを用意し、割り当てる
1.WorkerからActivityの実行をポーリング
2.スケジュールされたLambda FunctionがState Machineを実行する
3.Activityが実行されトークンが発行される
4.StateはWorkerの完了をポーリングする
5.Workerのバックアップ処理が終わればトークンと実行結果を返却する
6.全てのWorkerがトークンを返却すると次のStateに進む
インスタンスの台数を増やす時はState Machineを分離する
スケジュールに沿って
State Machineを実行する
Send Token
Get Activity Task
State Machine
Worker
State
Activity Task
Next State
Backup
Input data
Event trigger execution

10. 各Stepの詳細
CatchAllFallBack
Mattermost alert
Pass State
Fail
Fail State
Error Handring
Main Step
Parallel State
Instance
Activity
Get Activity Task
rsync
Terminate instance
Wait 180s
Wait StateTask State
Attach volume
Create snapshot
snapshot
Delete snapshot
Oldest snapshot
Mattermost echo
webfook
Create instance
workers
webfook
LVM Snapshot
※WorkerとInstance間の通信はDX経由

11. State Machineのデプロイ
# cat config.yaml # State Machineとworkerの結び付きを定義しておく
---
- machine_name: backup_01
member:
- host01.example.jp
- host02.example.jp
- host03.example.jp
# rake # rakeのdefaultタスクで config.yaml を元に必要な設定ファイル群を生成する
I, [2017-04-17T10:05:14.378802 #23710] INFO -- : Created input.json
I, [2017-04-17T10:05:14.379042 #23710] INFO -- : Created machines.json
I, [2017-04-17T10:05:14.379340 #23710] INFO -- : Created definition.json
# rake prov # provタスクでState Machineと必要なActivityを作成し、設定ファイルとinputデータをS3に配置する。
I, [2017-04-17T10:05:20.460448 #23712] INFO -- : Create State Machine from definition.json
I, [2017-04-17T10:05:20.632556 #23712] INFO -- : #<struct Aws::States::Types::CreateStateMachineOutput state_machine_arn
="arn:aws:states:ap-northeast-1:xxxx:stateMachine:backup_01", creation_date=2017-04-17 10:05:20 +0000>
I, [2017-04-17T10:05:20.734137 #23712] INFO -- : #<struct Aws::States::Types::CreateActivityOutput activity_arn="arn:aws:stat
es:ap-northeast-1:xxx:activity:backup_01", creation_date=2017-04-17 10:05:20 +0000>
I, [2017-04-17T10:05:20.900066 #23712] INFO -- : Uploaded input.json
I, [2017-04-17T10:05:20.924153 #23712] INFO -- : Uploaded machines.json
・RakeとSDKで実装しましたが、CloudFormationを使ってもよかったと後から思いました

12. 課金予想(1ヶ月)
50TBの実データがあり、10TBのバックアップが可能なState Machineを6台稼働させる
EBS Snapshotの圧縮率はファイル形式に関わらず20%と仮定する
日々の増分データ量の合計は100GBとする
ほとんどinputになるのでデータ通信料は考えない
(0.05*((50000+1550)*0.8))+(0.03*10000)*6+(0.258*(5*30)/(24*30))*6
= $3862
30世代残し、バックアップに平均5時間かかる場合
LambdaとStep Functionsの料金は無料枠に収まるので
EBS VolumeとSnapshotの課金が大半をしめる。

13. 感想
・Paralell Stateの仕様が要件に合っていた
ー すべてのバックアップが完了したかどうかをチェックするような実装を考える必要がない
・Wait Stateが結構便利
ー インスタンスのTerminate待ちなどをLambdaで待つ前に仕込んでおくと良い
・複数のLambda Functionとオンプレのアプリケーションを簡単につなげられる
ー S3を介したりDynamoDBに状態を書き込んだりしなくて良い
・マネジメントコンソールからexecutionの成功・失敗が簡単に確認できる
ー State Machineの定義やLambdaで問題が起きているとすぐ気づける
ー 各サーバーのバックアップの実行状況が把握しやすい
・State Machineの定義はそれほど難しくない
ー 公式ドキュメントがかなり充実しているので、大体のことはドキュメントを読めば解決できる
・Lambdaを使うときは冪等性を意識する
ー executionを実行する関数でLambdaがリトライすると2個も3個もState Machineが作られた