この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ようやく登場してくれたDynamoDBのOn-Demand BackupとRestore機能をお試しで使いました。
構成
DynamoDBのテーブルに5分毎にアイテムをPutするLambdaを配置。任意のタイミングでBackupを取り、正常にRestoreできるかを確認します。重いデータを作ることをスキップしたため、どこまで実用的かは分かりませんが、ひとまず正常動作することを確認します。
DynamoDB Table構成
| 項目 | 値 |
|---|---|
| テーブル名 | blog_backup |
| プライマリパーティションキー | hashid (文字列) |
| リージョン | (N. Virginia): 2017年11月30日 1:56:21 UTC-5 |
| Read Capcity Unit | 1 (Auto Scaling 有効) |
| Write Capcity Unit | 1 (Auto Scaling 有効) |
| ストレージ容量（バイト単位） | 0 バイト |
| 項目数 | 0 |
| リージョン | US East (N. Virginia) |
当然ながらTokyoリージョンにはまだお見えしてませんでしたので、 us-east-1 で試します。Backupオプションは勝手に有効になっていました。
タブを開いてみると、表示されなければまた後で表示してみよ、と書いてあります。しばらく反映に時間がかかるようです。
15分ほど作業した後に再度表示してみました。このテーブルのBackupが存在しないことが確認できます（当然）
リージョンごとの比較の様子
N.Virginiaリージョン
Tokyoリージョン
データを追加し続けるLambda
データの増分等が分からないとあまり意味が無いかと思ったので、以下のLambdaコードで5分毎にアイテムを一つずつ追加するようにしています。DynamoDBのテーブルはとても単純で Primary key一つだけにしてます（すいません）
from __future__ import print_function
import boto3
import json
import os
import uuid
TABLE = os.environ['table'] # DynamoDB Talbe Name
dynamodb_client = boto3.client('dynamodb')
def lambda_handler(event, context):
random_uuid = uuid.uuid4()
response = dynamodb_client.put_item(
TableName=str(TABLE),
Item={
'hashid': {
'S':str(random_uuid)
}
}
)
print('Successfully created %s.' % str(random_uuid))Backupを作成する
各種ドキュメントを確認すると更新されており create_backup() を確認することができます。
今回はCLIで実行します。こちらは当然ConsoleからもポチッとBackupの作成を押すだけで実行が可能です。
$ aws dynamodb create-backup --table-name blog_backup --backup-name 201711292345_LAS --profile
{
"BackupDetails": {
"BackupArn": "arn:aws:dynamodb:us-east-1:xxxxxxxxxxxxxx:table/blog_backup/backup/01234567890123-3bd4c9cc",
"BackupName": "201711292345_LAS",
"BackupStatus": "CREATING",
"BackupCreationDateTime": 1512027960.496
}
}--table-name, --backup-name いずれも必須です。
ほぼ遅延なくResponseがありましたが、 BackupStatus を見る通り当然非同期実行です。データの大きさによって作成時間は異なると思われます（テーブル構成の複雑度によっても変わる？？）。稼働しているテーブルへの影響はあるのか？、どれくらいのデータ数でどれくらいの時間がかかるのか等は、実際の現場で運用する際には事前に検証が必要です。
Restore
Restoreを実行してみます。
Backupから新たなテーブルを一つ作成します。一つ注意しなければならないのはドキュメントに記載があるように以下の項目はRestore後に、手動で更新する必要があるようです。
- Auto scaling policies
- IAM policies
- Cloudwatch metrics and alarms
- Tags
- Time to Live (TTL) settings
今回のテーブルではAutoscalingの設定を有効にしています。min:1, max:5で設定されているはずです。どのようにRestoreされてるのでしょうか。
$ aws dynamodb restore-table-from-backup --target-table-name blog_backup_20171129_snapshot --backup-arn arn:aws:dynamodb:us-east-1:xxxxxxxxxx:table/blog_backup/backup/0123456789012-3bd4c9cc --profile
{
"TableDescription": {
"AttributeDefinitions": [
{
"AttributeName": "hashid",
"AttributeType": "S"
}
],
"TableName": "blog_backup_20171129_snapshot",
"KeySchema": [
{
"AttributeName": "hashid",
"KeyType": "HASH"
}
],
"TableStatus": "CREATING",
"CreationDateTime": 1512030338.617,
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 1,
"WriteCapacityUnits": 1
},
"TableSizeBytes": 0,
"ItemCount": 0,
"TableArn": "arn:aws:dynamodb:us-east-1:xxxxxxxxxx:table/blog_backup_20171129_snapshot",
"TableId": "xxxxxx-xxx-4exxxdd-xxx-xxxxxxxx",
"RestoreSummary": {
"SourceBackupArn": "arn:aws:dynamodb:us-east-1:xxxxxxxxxx:table/blog_backup/backup/0123456789012-3bd4c9cc",
"SourceTableArn": "arn:aws:dynamodb:us-east-1:xxxxxxxxxx:table/blog_backup",
"RestoreDateTime": 1512027960.496,
"RestoreInProgress": true
}
}
}--target-table-name にはRestoreしたデータを復元するテーブル名。--backup-arn にはBackupデータのARNを入力します。
正常にRestore Requestが受理されたようです。
復元中。
15分ほどでRestoreが完了。Item数が2つ、かつ利用しているストレージ容量も限りなく0ですが思った以上に時間がかかりました。データ量によってこの時間がどのように変化するのかは、こちらも今後検証が必要かと思います。
注意書きにもあったようにAutoscaling Groupの設定は外れてしまうようです。こちらは必要であれば手動で再設定する必要があります。
気になるお値段
気になるのはBackupのお値段です。日本語のドキュメントの方にはまだ反映されていませんが（2017/11/30現在）、英語のほうに切り替えるとBackupの価格についての記載が確認できます。
N.Virginiaでは $0.10 per GB-month となるようです。データ数ではなく利用しているストレージの容量で価格が決まる模様。10GB/＄ ですね。恐らくItem数は多くとも文字列のドキュメントが多いと思われますので、1つのBackupの値段としては悪くないのではないでしょうか。
ただSnapshotのようにデイリーBackupを取り続けると、差分バックアップではなさそうなので料金がかさむような気がします。
On-Demand Backup allows you to create full backups of your DynamoDB table data and settings for data archival
またRestoreの際にも課金対象となります。
こちらはN.Virgniaで $0.15 per GB 1回のRequestにつきRestoreしたデータの容量によって金額が決まります。バックアップだけではなく復元の際にも料金がかかることをお忘れなく。
まとめ
ようやく待ちに待ったDynamoDBテーブルのBackup機能が追加されました。Full Backupとなるので使い所は考える必要がありますが、ある地点の状況へRestoreできるというのは非常に強力な機能だと思います。サービスを運用していると、どうしてもデータのサルベージやある地点への復元が必要になるケースが有ります。今までこういったユースケースに対応するためにS3へのバックアップの作成など様々な工夫を凝らしてきましたが、ストレージにBackupの機能がついたということで、ちょっとした煩わしさから脱却できるのではないかという期待ができるアップデートでした。早く東京リージョンへ！
3
