Category: Amazon DynamoDB*


Amazon DynamoDB からのデータストリームを AWS Lambda と Amazon Kinesis Firehose を活用して Amazon Aurora に格納する

Aravind Kodandaramaiah は AWS パートナープログラムのパートナーソリューションアーキテクトです。

はじめに

AWS ワークロードを実行するお客様は Amazon DynamoDBAmazon Aurora の両方を使用していることがよくあります。Amazon DynamoDB は、どのような規模でも、一貫した、数ミリ秒台にレイテンシーを抑える必要のあるアプリケーションに適した、高速で柔軟性の高い NoSQL データベースサービスです。データモデルの柔軟性が高く、パフォーマンスが信頼できるため、モバイル、ウェブ、ゲーム、広告、IoT、他の多くのアプリケーションに最適です。

Amazon Aurora は、MySQL と互換性のあるリレーショナルデータベースエンジンで、オープンソースデータベースのコスト効率性と簡素性を備えた、高性能の商用データベースの可用性とスピードをあわせもったエンジンです。Amazon Aurora は、MySQL よりも最大 5 倍のパフォーマンスを発揮するだけでなく、商用データベースのセキュリティ、可用性、および信頼性を 10 分の 1 のコストで実現します。

DynamoDB と Aurora を連携させるために、カスタムウェブ解析エンジンを構築して、毎秒数百万のウェブクリックが DynamoDB に登録されるようにしたとします。Amazon DynamoDB はこの規模で動作し、データを高速に取り込むことができます。また、このクリックストリームデータを Amazon Aurora などのリレーショナルデータベース管理システム (RDBMS) にレプリケートする必要があるとします。さらに、ストアドプロシージャまたは関数内で SQL の機能を使用して、このデータに対してスライスアンドダイスや、さまざまな方法でのプロジェクションを行ったり、他のトランザクション目的で使用したりするとします。

DynamoDB から Aurora に効率的にデータをレプリケートするには、信頼性の高いスケーラブルなデータレプリケーション (ETL) プロセスを構築する必要があります。この記事では、AWS Lambda Amazon Kinesis Firehose によるサーバーレスアーキテクチャを使用して、このようなプロセスを構築する方法について説明します。

ソリューションの概要

以下の図に示しているのは、このソリューションのアーキテクチャです。このアーキテクチャの背後には、次のような動機があります。

  1. サーバーレス – インフラストラクチャ管理を AWS にオフロードすることで、メンテナンスゼロのインフラストラクチャを実現します。ソリューションのセキュリティ管理を簡素化します。これは、キーやパスワードを使用する必要がないためです。また、コストを最適化します。さらに、DynamoDB Streams のシャードイテレーターに基づいた Lambda 関数の同時実行により、スケーリングを自動化します。
  2. エラー発生時に再試行可能 – データ移動プロセスには高い信頼性が必要であるため、プロセスは各ステップでエラーを処理し、エラーが発生したステップを再試行できる必要があります。このアーキテクチャではそれが可能です。
  3. 同時データベース接続の最適化 – 間隔またはバッファサイズに基づいてレコードをバッファすることで、Amazon Aurora への同時接続の数を減らすことができます。この方法は、接続タイムアウトを回避するのに役立ちます。
  4. 懸念部分の分離 – AWS Lambda を使用すると、データレプリケーションプロセスの各懸念部分を分離できます。たとえば、抽出フェーズを DynamoDB ストリームの処理として、変換フェーズを Firehose-Lambda 変換として、ロードフェーズを Aurora への一括挿入として分離できます。

以下に示しているのは、このソリューションのしくみです。

  1. DynamoDB Streams がデータソースです。DynamoDB Streams を使用すると、DynamoDB テーブル内の項目が変更されたときに、その変更を取得できます。AWS Lambda は、新しいストリームレコードを検出すると、Lambda 関数を同期的に呼び出します。
  2. Lambda 関数は、DynamoDB テーブルに新たに追加された項目をバッファし、これらの項目のバッチを Amazon Kinesis Firehose に送ります。
  3. Firehose は、受け取ったデータを Lambda 関数により変換して、Amazon S3 に配信します。Firehose に対してデータ変換を有効にしていると、Firehose は受け取ったデータをバッファし、バッファしたデータのバッチごとに、指定された Lambda 関数を非同期的に呼び出します。変換されたデータは Lambda から Firehose に返されてバッファされます。
  4. Firehose は変換されたすべてのレコードを S3 バケットに配信します。
  5. Firehose は変換されないすべてのレコードも S3 バケットに配信します。ステップ 4 と 5 は同時に実行されます。Amazon SNS トピックをこの S3 バケットに登録して、以降の通知、修復、再処理に使用できます (通知に関する詳細はこのブログ記事では取り上げません)。
  6. Firehose が変換されたデータを S3 に正常に配信するたびに、S3 はイベントを発行することで Lambda 関数を呼び出します。この Lambda 関数は VPC 内で実行されます。
  7. Lambda 関数は Aurora データベースに接続し、SQL 式を実行して、S3 から直接テキストファイルにデータをインポートします。
  8. Aurora (VPC プライベートサブネット内で実行) は、S3 VPC エンドポイントを使用して S3 からデータをインポートします。

ソリューションの実装とデプロイ
次に、このソリューションを機能させるために必要な手順について説明します。以下の手順では、AWS CloudFormation スタックを起動して一連の AWS CLI コマンドを実行することで、VPC 環境を作成する必要があります。

AWS サービスを使用してこれらの手順を実行している間、AWS サービスの料金が適用されることがあります。

ステップ 1: ソリューションのソースコードをダウンロードする
このブログ記事で概説したソリューションでは、多くの Lambda 関数を使用し、また、多くの AWS Identity and Access Management (IAM) ポリシーおよびロールを作成します。このソリューションのソースコードは以下の場所からダウンロードします。

git clone https://github.com/awslabs/dynamoDB-data-replication-to-aurora.git

このリポジトリには、以下のフォルダ構造があります。このブログ記事の後続の手順を実行するために、lambda_iam フォルダに移動します。

ステップ 2: Firehose 配信用の S3 バケットを作成する
Amazon Kinesis Firehose を使用すると、Amazon S3 にリアルタイムのストリーミングデータを配信できます。そのためには、まず S3 バケットを作成します。次に、レコードの処理に失敗した場合に備えて、変換された最終のレコードとデータバックアップを保存するフォルダを作成します。

aws s3api create-bucket --bucket bucket_name

aws s3api put-object \
--bucket bucket_name \
--key processed/

aws s3api put-object \
--bucket bucket_name
--key tranformation_failed_data_backup/

 

ステップ 3: IAM ポリシー、S3 イベント通知、Firehose-S3 配信設定ファイルを変更する
次に、以下のファイルで、プレースホルダー AWS_REGION、

AWS_ACCOUNT_NUMBER、BUCKET_NAME をそれぞれ、お客様の AWS リージョン ID、AWS アカウント番号、ステップ 2 で作成した S3 バケットの名前に置き換えます。

 

·         aurora-s3-access-Policy.json

·         DynamoDb-Stream-lambda-AccessPolicy.json

·         firehose_delivery_AccessPolicy.json

·         lambda-s3-notification-config.json

·         s3-destination-configuration.json

·         firehose_delivery_trust_policy.json

ステップ 4: CloudFormation を使用して Aurora クラスターを設定する
次に、[Launch Stack] ボタンをクリックして AWS CloudFormation スタックを起動します。CloudFormation テンプレートは、VPC を作成し、その VPC のパブリックおよびプライベートサブネットを設定します。また、このテンプレートは、プライベートサブネット内で Amazon Aurora データベースクラスターを起動し、パブリックサブネット内でパブリック IP を割り当てた踏み台ホストも起動します。


ステップ 5: Aurora DB クラスターを設定する
CloudFormation スタックが完成したら、S3 バケット内のテキストファイルから DB クラスターにデータをロードするように、Aurora クラスターを変更する必要があります。以下に示しているのは、そのための手順です。

Amazon Aurora が Amazon S3 にアクセスできるようにします。そのためには、IAM ロールを作成し、先ほど作成した信頼およびアクセスポリシーをそのロールにアタッチします。

auroraS3Arn=$(aws iam create-role \
    --role-name aurora_s3_access_role \
    --assume-role-policy-document file://aurora-s3-Trust-Policy.json \
    --query 'Role.Arn' \
    --output text)

aws iam put-role-policy \
    --role-name aurora_s3_access_role \
    --policy-name aurora-s3-access-Policy \
    --policy-document file://aurora-s3-access-Policy.json

 

その IAM ロールを Aurora DB クラスターに関連付けます。そのためには、新しい DB クラスターパラメータグループを作成し、その DB クラスターに関連付けます。

aws rds add-role-to-db-cluster \
    --db-cluster-identifier Output AuroraClusterId from CloudFormation Stack \
    --role-arn $auroraS3Arn

aws rds create-db-cluster-parameter-group \
    --db-cluster-parameter-group-name webAnayticsclusterParamGroup \
    --db-parameter-group-family aurora5.6 \
    --description 'Aurora cluster parameter group - Allow access to Amazon S3'

aws rds modify-db-cluster-parameter-group \
    --db-cluster-parameter-group-name webAnayticsclusterParamGroup \
    --parameters "ParameterName=aws_default_s3_role,ParameterValue= $auroraS3Arn,ApplyMethod=pending-reboot"

aws rds modify-db-cluster \
	--db-cluster-identifier Output AuroraClusterId from CloudFormation Stack \
	--db-cluster-parameter-group-name webAnayticsclusterParamGroup

 

プライマリ DB インスタンスを再起動します。

aws rds reboot-db-instance \
--db-instance-identifier Output PrimaryInstanceId from CloudFormationF Stack 

ステップ 6: DynamoDB ストリームと、そのストリームを処理する Lambda 関数を設定する

1.    ストリームを有効にして新しい DynamoDB テーブルを作成します。以降の手順では、AWS Lambda 関数をストリームに関連付けることで、トリガーを作成します。

aws dynamodb create-table \
    --table-name web_analytics \
    --attribute-definitions AttributeName=page_id,AttributeType=S AttributeName=activity_dt,AttributeType=S \
    --key-schema AttributeName=page_id,KeyType=HASH AttributeName=activity_dt,KeyType=RANGE \
    --provisioned-throughput ReadCapacityUnits=50,WriteCapacityUnits=50 \
    --stream-specification StreamEnabled=true,StreamViewType=NEW_IMAGE

2.    Lambda 実行ロールを作成します。

DdbStreamLambdaRole=$(aws iam create-role \
    --role-name DdbStreamLambdaRole \
    --assume-role-policy-document file://DynamoDB-Stream-lambda-Trust-Policy.json \
    --query 'Role.Arn' \
    --output text)


aws iam put-role-policy \
    --role-name DdbStreamLambdaRole \
    --policy-name DdbStreamProcessingAccessPolicy \
    --policy-document file://DynamoDb-Stream-lambda-AccessPolicy.json

3.  DynamoDB ストリームを処理する Lambda 関数を作成します。

aws lambda create-function \
    --function-name WebAnalyticsDdbStreamFunction \
    --zip-file fileb://ddbStreamProcessor.zip \
    --role $DdbStreamLambdaRole \
    --handler ddbStreamProcessor.handler \
    --timeout 300 \
    --runtime nodejs4.3

 

4.  その Lambda 関数を DynamoDB ストリームに関連付けることで、トリガーを作成します。

tableStreamArn=$(aws dynamodb describe-table --table-name web_analytics --query 'Table.LatestStreamArn' --output text)

aws lambda create-event-source-mapping \
    --function-name WebAnalyticsDdbStreamFunction \
    --event-source-arn $tableStreamArn \
    --batch-size 100 \
    --starting-position LATEST

ステップ 7: Firehose のデータ変換 Lambda 関数を作成して設定する

Lambda 実行ロールを作成します。

transRole=$(aws iam create-role \
            --role-name firehose_delivery_lambda_transformation_role \
            --assume-role-policy-document  file://firehose_lambda_transformation_trust_policy.json \
            --query 'Role.Arn' --output text)

aws iam put-role-policy \
        --role-name firehose_delivery_lambda_transformation_role \
        --policy-name firehose_lambda_transformation_AccessPolicy \
        --policy-document file://firehose_lambda_transformation_AccessPolicy.json

2.  データ変換 Lambda 関数を作成します。

aws lambda create-function \
    --function-name firehoseDeliveryTransformationFunction \
    --zip-file fileb://firehose_delivery_transformation.zip \
    --role $transRole \
    --handler firehose_delivery_transformation.handler \
    --timeout 300 \
    --runtime nodejs4.3 \
    --memory-size 1024

この関数は、受け取ったストリームのレコードを JSON スキーマに対して検証します。スキーマに一致したら、受け取った JSON レコードを解析し、カンマ区切り値 (CSV) 形式に変換します。

'use strict';

var jsonSchema = require('jsonschema');

var schema = { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "Hits": { "type": "integer" }, "device": { "type": "object", "properties": { "make": { "type": "string" }, "platform": { "type": "object", "properties": { "name": { "type": "string" }, "version": { "type": "string" } }, "required": ["name", "version"] }, "location": { "type": "object", "properties": { "latitude": { "type": "string" }, "longitude": { "type": "string" }, "country": { "type": "string" } }, "required": ["latitude", "longitude", "country"] } }, "required": ["make", "platform", "location"] }, "session": { "type": "object", "properties": { "session_id": { "type": "string" }, "start_timestamp": { "type": "string" }, "stop_timestamp": { "type": "string" } }, "required": ["session_id", "start_timestamp", "stop_timestamp"] } }, "required": ["Hits", "device", "session"] };

exports.handler = (event, context, callback) => {
    let success = 0; // Number of valid entries found
    let failure = 0; // Number of invalid entries found

    const output = event.records.map((record) => {

        const entry = (new Buffer(record.data, 'base64')).toString('utf8');

        var rec = JSON.parse(entry);
        console.log('Decoded payload:', entry);
        var milliseconds = new Date().getTime();

        var payl = JSON.parse(rec.payload.S);

        var jsonValidator = new jsonSchema.Validator();
        var validationResult = jsonValidator.validate(payl, schema);
        console.log('Json Schema Validation result = ' + validationResult.errors);

        if (validationResult.errors.length === 0) {

            const result = `${milliseconds},${rec.page_id.S},${payl.Hits},
				${payl.session.start_timestamp},
				${payl.session.stop_timestamp},${payl.device.location.country}` + "\n";

            const payload = (new Buffer(result, 'utf8')).toString('base64');
            console.log(payload);
            success++;

            return {
                recordId: record.recordId,
                result: 'Ok',
                data: payload,
            };
        }
        else {
            failure++;
            return {
                recordId: record.recordId,
                result: 'ProcessingFailed',
                data: record.data,
            }
        }

    });

    console.log(`Processing completed.  Successful records ${success}, Failed records ${failure}.`);
    callback(null, { records: output });

};

ステップ 8: Firehose 配信ストリームを作成し、S3 にデータを配信するように設定する

Amazon S3 ターゲットを使用するとき、Firehose は S3 バケットにデータを配信します。配信ストリームを作成するには、IAM ロールが必要です。Firehose はその IAM ロールを引き受けることで、指定したバケットとキーにアクセスする権限を取得します。Firehose はまた、その IAM ロールを使用することで、Amazon CloudWatch ロググループにアクセスし、データ変換 Lambda 関数を呼び出す権限を取得します。

1.    S3 バケット、キー、CloudWatch ロググループ、データ変換 Lambda 関数にアクセスする権限を付与する IAM ロールを作成します。

aws iam create-role \
    --role-name firehose_delivery_role \
    --assume-role-policy-document  file://firehose_delivery_trust_policy.json

aws iam put-role-policy \
    --role-name firehose_delivery_role \
    --policy-name firehose_delivery_AccessPolicy \
    --policy-document file://firehose_delivery_AccessPolicy.json

 

2.  S3 ターゲット設定を指定して、Firehose 配信ストリームを作成します。

aws firehose create-delivery-stream \
    --delivery-stream-name webAnalytics \
    --extended-s3-destination-configuration='CONTENTS OF s3-destination-configuration.json file' 

3.  AWS マネジメントコンソールにサインインし、Firehose コンソールに移動します。webAnalytics という名前の配信ストリームを選択します。[Details] タブで、[Edit] を選択します。[Data transformation][Enabled] を、[IAM role] [firehose_delivery_role] を選択します。[Lambda function] で、[firehoseDeliveryTransformationFunction] を選択します。次に、[Save] を選択してこの設定を保存します。

ステップ 8: Lambda 関数を作成して、VPC リソースにアクセスするように設定する
S3 バケットから Amazon Aurora にデータをインポートするには、VPC 内のリソースにアクセスするように Lambda 関数を設定します。

1.    Lambda 関数の IAM 実行ロールを作成します。

auroraLambdaRole=$(aws iam create-role \
                --role-name lambda_aurora_role \
                --assume-role-policy-document file://lambda-aurora-Trust-Policy.json \
                --query 'Role.Arn' --output text)

aws iam put-role-policy \
    --role-name lambda_aurora_role \
    --policy-name lambda-aurora-AccessPolicy \
    --policy-document file://lambda-aurora-AccessPolicy.json

2.  プライベートサブネットやセキュリティグループなどの VPC 設定を指定する Lambda 関数を作成します。CLI の実行中に渡される環境変数 AuroraEndpoint、dbUser (データベースユーザー)、dbPassword (データベースパスワード) に正しい値を設定していることを確認します。これらの値については、CloudFormation スタック出力を参照してください。

aws lambda create-function \
    --function-name AuroraDataManagementFunction \
    --zip-file fileb://AuroraDataMgr.zip \
    --role $auroraLambdaRole \
    --handler dbMgr.handler \
    --timeout 300 \
    --runtime python2.7 \
    --vpc-config SubnetIds='Output PrivateSubnets from CloudFormation stack',SecurityGroupIds='Output DefaultSecurityGroupId from CloudFormation stack' \
    --memory-size 1024 \    
    --environment='    
                    {
                        "Variables": {
                            "AuroraEndpoint": "Output AuroraEndpoint from CloudFormation stack",
                            "dbUser": "Database User Name",
                            "dbPassword": "Database Password"
                        }
                    }'

 

Lambda 関数は Aurora データベースに接続します。この関数は、LOAD DATA FROM S3 SQL コマンドを実行して、S3 バケット内のテキストファイルから Aurora DB クラスターにデータをロードします。

import logging import pymysql import boto3 import sys import os
# rds settings
db_name = "Demo"
dbUser = os.environ['dbUser']
dbPassword = os.environ['dbPassword']
AuroraEndpoint = os.environ['AuroraEndpoint']

logger = logging.getLogger()
logger.setLevel(logging.INFO)

s3_client = boto3.client('s3')
try:
    conn = pymysql.connect(AuroraEndpoint, user=dbUser, passwd=dbPassword, db=db_name, connect_timeout=5)
except:
    logger.error("ERROR: Unexpected error: Could not connect to Aurora instance.")
    sys.exit()

logger.info("SUCCESS: Connection to RDS Aurora instance succeeded")

def handler(event, context):

    for record in event['Records']:
        bucket = record['s3']['bucket']['name']
        key = record['s3']['object']['key']
        s3location = 's3://' + bucket + '/' + key
        logger.info(s3location)

        sql = "LOAD DATA FROM S3 '" + s3location + "' INTO TABLE Demo.WebAnalytics FIELDS TERMINATED BY ',' " \
              "LINES TERMINATED BY '\\n' (timestarted, page_id, hits, start_time, end_time, country_code);"

        logger.info(sql)

        with conn.cursor() as cur:
            cur.execute(sql)
            conn.commit()
            logger.info('Data loaded from S3 into Aurora')

ステップ 9: S3 イベント通知を設定する
最後に、S3 がイベントを発行することで、前のステップで作成した Lambda 関数を呼び出すように、その関数を設定します。このプロセスの最初の手順は、Lambda 関数を呼び出すアクセス権限を S3 に付与することです。

1.    Lambda 関数を呼び出すアクセス権限を S3 に付与します。

aws lambda add-permission \
    --function-name AuroraDataManagementFunction \
    --action “lambda:InvokeFunction” \
    --statement-id Demo1234 \
    --principal s3.amazonaws.com \
    --source-arn ‘ARN of S3 Bucket created in Step 2’ \
    --source-account ‘AWS Account Id

2.    S3 バケット通知を設定します。

aws s3api put-bucket-notification-configuration \
    --bucket 'Name of S3 Bucket created in step 2' \
    --notification-configuration=' CONTENTS OF lambda-s3-notification-config.json ' 

 

ステップ 10: ソリューションをテストする
最後のステップは、ソリューションをテストすることです。

  1. このブログ記事のソースコードの TestHarness フォルダには、テストハーネスがあります。このテストハーネスは DynamoDB テーブルにデータを読み込みます。まず、TestHarness フォルダに移動し、コマンドノード loadDataToDDb.js を実行します。
  2. Secure Shell (SSH) を使用して、踏み台ホストに接続します。SSH を使用した接続の詳細については、EC2 のドキュメントを参照してください。
  3. 踏み台ホストのブートストラッププロセス中に MySQL クライアントがインストールされたため、以下のコマンドを使用して Aurora データベースに接続できます。パラメータ値を適切に変更していることを確認します。
/usr/bin/mysql -h DatabaseEndpoint -u DatabaseUsername --password=DatabasePassword 

4.    コネクションが成功したら、以下のコマンドを実行します。

 mysql> select count(*) from Demo.WebAnalytics;

このコマンドを実行した後、テーブルにレコードが読み込まれています。

テーブルにレコードが読み込まれていない場合、Firehose はそれらのレコードを S3 に送信する前にバッファしている可能性があります。これを回避するには、1 分くらい後に同じ SQL コードを再試行してください。この間隔は、現在設定されている S3 バッファ間隔の値に基づきます。このコードを再試行した後、Amazon Aurora にレコードが挿入されています。

 

まとめ

DynamoDB Streams と、Amazon Kinesis Firehose のデータ変換関数を使用すると、DynamoDB から Amazon Aurora などのデータソースにデータをレプリケートする強力でスケーラブルな方法を得られます。このブログ記事では、DynamoDB から Aurora へのデータのレプリケートを取り上げましたが、同じ一般的なアーキテクチャパターンを使用すれば、他のストリーミングデータを変換して、Amazon Aurora に取り込むことができます。

さらに、以下の関連するブログ記事を参照してください。

 

新機能 – DynamoDB VPCエンドポイントが出ました

今日(翻訳元記事2017年8月16日)からAmazon Virtual Private Cloud(VPC)Amazon DynamoDB用エンドポイントがすべてのAWSのリージョンでご利用いただけます。AWS Management ConsoleまたはAWS Command Line Interface(CLI  コマンドラインインターフェイス)を使用して、すぐにエンドポイントをプロビジョニングできます。DynamoDBのVPCエンドポイントには追加費用はかかりません。

多くのAWSをお使い頂いているお客様は、セキュリティまたは分離の理由からAmazon Virtual Private Cloud(VPC)内でアプリケーションを実行します。以前は、VPC内のEC2インスタンスがDynamoDBにアクセスできるようにするには、2つのオプションがありました。インターネットゲートウェイ(NATゲートウェイを使用するかインスタンスの公開IPを割り当てる)を使用するか、すべてのトラフィックをVPNまたはAWS Direct Connect経由でローカルインフラストラクチャにルーティングしてからDynamoDBに戻すことができます。これらのソリューションには両方ともセキュリティとスループットの関係があり、NACLまたはセキュリティグループを構成してDynamoDBだけへのアクセスを制限することは困難でした。下の画像は上記のパターンのアーキテクチャです。

エンドポイントの作成
DynamoDBのVPCエンドポイントを作成しましょう。DescribeVpcEndpointServices APIコールを使用して、指定したリージョンでエンドポイントがサポートされていることを確認できます。

aws ec2 describe-vpc-endpoint-services --region us-east-1
{
    "ServiceNames": [
        "com.amazonaws.us-east-1.dynamodb",
        "com.amazonaws.us-east-1.s3"
    ]
}

上記の結果により、これらのエンドポイントをサポートしていることを確認出来ました。私は自分のVPCの1つを指定して、CLIまたはコンソールからの操作で簡単にエンドポイントをプロビジョニングできます。コンソールの使い方はこれから説明します。

最初に、VPCコンソールに移動し、サイドバーの[Endpoint]を選択します。そこから「Create Endpoint」をクリックして、この便利なコンソールに遷移します。

エンドポイントのAWS Identity and Access Management (IAM) ポリシーセクションに気づくでしょう。これは、通常のIAMポリシーでDynamoDBがサポートする詳細なアクセス制御をすべてサポートし、IAMポリシー条件に基づいてアクセスを制限できます。

今の例ではこのVPC内のインスタンスはフルアクセスし出来るようにして、「次のステップ」をクリックします。

これは私のVPC内のルートテーブルのリストに、これらのルートテーブルのどれに私のエンドポイントを割り当てるかを尋ねています。いずれかを選択して[Create Endpoint]をクリックします。

コンソールの警告メッセージに注意してください。パブリックIPアドレスに基づいてDynamoDBにソース制限がある場合、DynamoDBにアクセスするインスタンスのソースIPはプライベートIPアドレスになります。

DynamoDBのVPCエンドポイントをVPCに追加した後のアーキテクチャは次のようになります。

これでおしまいです!とても簡単で無料で利用する事ができます。是非利用してみて下さい。詳細が必要な場合は、ここでドキュメントを読むことができます。

(SA 成田が翻訳しました。元記事はこちら

DynamoDB Accelerator (DAX) が正式にサービス開始しました

今年の初め頃 Amazon DynamoDB AcceleratorDAX)について紹介をしました。DAXはフルマネージドのキャッシュサービスでDynamoDBテーブルの前段(論理的に)に置かれます。DAXはキャッシュされたデータに対するリクエストをマイクロ秒単位で返すため、読み込みワークロードに最適です。DAXはアプリケーションコード内ではDynamoDB APIと互換性を保つ様にサポートしており、シームレスで使いやすいようにデザインしています。管理することはDAXクラスタを作成して既存の読み取りと書き込みのターゲットとして使用するだけです。パッチ適用、クラスタメンテナンス、キャッシュデータの複製、または障害管理について心配する必要はありません。

本日から利用可能
今日DAXが正式に利用可能になったことをお知らせします。DAXが利用可能なAWSリージョンを追加拡張し、プレビューの期間にパフォーマンスと可用性をチューニングしました。

5つのリージョンで利用可能 – 現在 DAXはUS East (Northern Virginia)、EU (Ireland)、US West (Oregon)、Asia Pacific (Tokyo)、US West (Northern California) の5つの地域で利用可能です。

In Production – プレビュー期間内にDAXを本番で使用しているユーザーもおり、DAXをアプリケーションに追加するのが楽で今ではアプリケーションの速度が10倍速くなってたという声を頂いています。

Getting Started with DAX
以前の記事(翻訳版はこちら)で紹介したように、DAXを使用して既存のDynamoDBアプリケーションを高速化するのは簡単です。必要なリージョンにDAXクラスタを作成し、 DAX SDK for Javaを利用するようにアプリケーションを更新します(コード内の呼び出し方は同じですが、ライブラリの置き換えを行う事です)。SDKを構成してクラスタにエンドポイントを使用するようにします。リードスルー/ライトスルーキャッシュとして、DAXはすべてのDynamoDB読み取り/書き込みAPIをシームレスに処理します。

私たちは他の言語のSDKのサポートも取り組んでおり、利用可能になった時点で追加情報を共有します。

価格について

US East (Northern Virginia) と US West (Oregon) の各地域で、時間あたり$ 0.269から始まる料金
でクラスター内の各ノード(詳細については、 DynamoDBの価格を参照)を1時間単位でお支払いいただきます。DAXでは、クラスタ内の各ノードが高可用性のための読み取りターゲットおよびフェールオーバーターゲットとして機能します。DAX SDKはクラスタを認識しており、クラスタ内のすべてのノードに対してラウンドロビンで要求を発行し、クラスタのキャッシュリソースを最大限に活用できるようにします。

DAXは読み取りトラフィックの急激な急上昇を容易に処理できるため、テーブルのプロビジョニングされたスループットの量を減らすことができ、結果としてマイクロ秒で結果を返しながら全体のコストを削減できます。

最後にAmazon.comのCTOであるWerner Vogelsが書いたブログを紹介させて頂きます。

Amazon DynamoDB Accelerator (DAX): Speed Up DynamoDB Response Times from Milliseconds to Microseconds without Application Rewrite.

Tinder、Careem、そしてCanon INC. の事例についてもご紹介していますので、ぜひご覧ください。

Jeff;

(翻訳はSA成田が行いました。原文はこちら

新機能 – Auto Scaling for Amazon DynamoDBについて

Amazon DynamoDBには幅広い業界やユースケースを含む10万人以上の多くのお客様がいます。 お客様は世界中の16の地域で、DynamoDBの一貫性のあるパフォーマンスを利用する事が出来ます。 最近の傾向は、DynamoDBを使用してサーバレスアプリケーションと組み合わせるお客様です。 この使い方は非常にマッチします:DynamoDBでは、サーバーのプロビジョニング、OSとデータベースのソフトウェアパッチ適用、または高可用性を確保するためのAZゾーン間のレプリケーションの設定などを考える必要はありません。テーブルを作成してデータを追加するだけでDynamoDBが処理するようにします。

DynamoDBにはプロビジョニングキャパシティーユニットモデルが用意されており、アプリケーションで必要とされる読み書き容量を設定できます。 これによりサーバの考え方から解放され、簡単なAPIコールまたはAWS Management Consoleのボタンをクリックしてテーブルのプロビジョニングを変更できるようになりましたが、多くのお客様はDynamoDBの容量をさらに簡単に管理できるように望んでいました。

本日、DynamoDBのAuto Scalingを導入して、テーブルとグローバルセカンダリインデックス(GSI)の容量管理を自動化できるようになりました。 維持をしたい使用率を指定し、読み書き容量の上限と下限を指定するだけです。 DynamoDBは、Amazon CloudWatchアラームを使用して消費量を監視し、必要に応じてプロビジョニングされた容量を調整します。 Auto Scalingは、すべての新しいテーブルとインデックスに対してデフォルトでオンに出来ます(但しIAM権限の事前準備が必要です)。また、既存のテーブルやインデックスに対しても設定できます。

あなたが常にマネジメントコンソールに張り付いていなくても、DynamoDB Auto Scalingはテーブルとインデックスを監視して、アプリケーショントラフィックの変化に応じて自動的にスループットを調整します。 これによりDynamoDBデータの管理が容易になり、アプリケーションの可用性を最大化しDynamoDBのコストを削減するのに役立ちます。

どのような機能か早速御覧ください。

Using Auto Scaling

新しいテーブルを作成するときに、DynamoDB Consoleにデフォルトパラメータセットが提示されるようになりました。 あなたはそのまま利用する事も、「Use default settings」のチェックを外して独自のパラメータを入力することもできます

独自にパラメータを設定する方法は以下の通りです。

Target utilizationは、消費容量とプロビジョニングされた容量の比率で表されます。 上記のパラメータは、読み取りまたは書き込み要求が増えた時でも消費される容量の2倍になるように十分な空き容量を確保します(DynamoDBの読み書き操作とプロビジョニングされた容量の関係の詳細については容量単位の計算を参照してください)。 プロビジョニングされた容量の変更は、バックグラウンドで行われます。

Auto Scaling in Action

この重要な新機能が実際に動作するのを見るために、「Getting Started Guide」の指示に従いました。 私は、新しくEC2インスタンス起動し、AWS SDK for Pythonを設定(sudo pip install boto3)を実行し利用するための設定(aws configure)を行いました。 次に、PythonとDynamoDBのコードを使用していくつかのデータを含むテーブルを作成し、読み込みと書き込みの各容量を5ずつ手動で設定しました。

CloudWatchメトリクスで綺麗な直線を得るために私は急いで休憩を取ったので、AutoScalingの効果を示すことができました。 負荷を適用する前のメトリクスは次のとおりです。

私はステップ3のコードを変更して、1920年から2007年の範囲でランダムにクエリを発行し、1〜2分後に読み取りメトリクスを確認しました。

消費された容量はプロビジョニングされた容量よりも多く、その結果多くの読み込みリクエストに対してスロットルが発生します。 AutoScalingが実行される!

私はコンソールに戻ってテーブルのCapacityタブをクリックした。 Read capacityをクリックし、デフォルト値を受け入れ、Saveをクリックしました

DynamoDBは新しいIAMロール(DynamoDBAutoscaleRole)とCloudWatchアラームのペアを作成して、読み取り容量のAuto Scalingを設定しました。

DynamoDB Auto Scalingはアラームのしきい値を管理し、スケーリングプロセスの一部としてアラームのしきい値を上下に調整します。 最初のアラームがトリガーされ追加の読み取り容量がプロビジョニングされている間にテーブルの状態が[Updating]に変更されました。

この変更は、数分で読み取りメトリクスに表示されました。

私は変更されたクエリスクリプトをいくつか実行し、追加の容量がプロビジョニングされているのを見てみました。

私はすべてのスクリプトを停止しスケールダウンアラームが発生するのを待ちました。:

翌朝Scaling activitiesを確認し、アラームが夜の間に何度かトリガされたことを確認しました:

これはメトリクスにも表示されていました。

これまでは、あなたが期待した使用量についてプロビジョンキャパシティユニットを十分に設定し、余裕を持たせる設定(青い線と赤い線の間のスペース)を行うことで、このような状況に備えることができました。若しくはプロビジョンキャパシティユニットを少なくしすぎ、監視するのを忘れてトラフィックが増えた時に容量が使い果たされる可能性がありました。 Auto Scalingを使用すると、リクエストが増加し必要な場合は自動的に増やし、もう不要な時は自動的に下げる事が可能です。

Things to Know

DynamoDB Auto Scalingは、ある程度予測可能である程度定期的に変化する要求レートに対応するように設計されています。予期せぬバーストした読み取りアクティビティに対応する必要がある場合は、Auto ScalingをDAXと組み合わせて使用​​する必要があります(詳細は、Amazon DynamoDB Accelerator(DAX) – Read heavyなワークロード向けインメモリ型キャッシュクラスタを参照してください)。また、AWS SDKを利用したアプリケーションは、スロットリングされた読み込み要求と書き込み要求を検出し、適切な遅延の後に再試行します。

(補足:Auto Scaling実行され実際に使える容量が増えるまでにはどうしても時間が掛かります。その為瞬間的なリクエスト増加に対応するのは難しいケースがあります。その為、瞬間的なリクエスト増加に対応するにはDAXなどのソリューションと組み合わせる事や、瞬間的にスロットリングが発生してもリトライで処理を継続させる事により影響を最小限にする処理が必要です。)

 

私はDynamoDBAutoscaleRoleを先に述べました。このロールは、テーブルとインデックスのスケールを上下させるために必要な権限をAuto Scalingに提供します。このロールと権限の詳細については、「Grant User Permissions for DynamoDB Auto Scaling」を参照してください。

Auto ScalingにはAuto Scalingポリシーを有効または無効にする機能を含むCLIとAPIの完全なサポートがあります。トラフィックに予測可能な時間的なスパイクがある場合(ゲームなどであれば決まった時間に発生するイベントなど)は、プログラムによって自動スケーリングポリシーを無効にし、一定期間高いスループットをプロビジョニングしてから、後でAuto Scalingを再度有効にすることができます。

DynamoDBの制限ページに記載されているように、プロビジョニングされた容量は、必要に応じて必要なだけ増やすことができます(アカウントごとに設定されている上限内にて)。各テーブルまたはグローバルセカンダリインデックスごとに1日に最大9回まで容量を減らすことができます。(その為、あまり頻繁に容量を下げる設定にしてしまうとこの回数を使い切ってしまいその後下げる事が一時的に出来なくなる可能性があります。)

実際に実行された容量は通常のDynamoDBの価格が掛かります。さらに節約するためにDynamoDBのリザーブドキャパシティユニットを購入することもできます。

今すぐ利用可能
この機能は現在すべての地域で利用可能で、今すぐ使用することができます!

Jeff;

(この記事はSA 成田が翻訳しました。原文はこちら

 

 

 

Amazon DynamoDB Accelerator(DAX) – Read heavyなワークロード向けインメモリ型キャッシュクラスタ

既にAmazon DynamoDBの事はご存知の方が多いと思います。ご存じのように、必要なだけのテーブルスペース、読み込み容量、書き込み容量に対応できるように拡張されたフルマネージドのNoSQLデータベースです。応答時間は1桁のミリ秒単位で測定され、多くのお客様がadtechIoTゲームメディアオンライン学習、旅行、電子商取引、金融など、さまざまな種類のアプリケーションにDynamoDBを使用しています。一部のお客様では一つのDynamoDBテーブルに100TB以上のデータを格納し、1秒当たり何百万もの読み取りまたは書き込み要求を行います。 Amazonの小売サイトはDynamoDBに依存しており、Black Friday、Cyber​​ Monday、Prime Dayなどの短時間で高強度のイベントに関連するトラフィックの急増に耐えます。

DynamoDBは、あらゆるアプリケーションやワークロードに対して、高速で一貫性のあるパフォーマンスのメリットを提供することができますが、常に改善の余地があります。いくつかのワークロード(ゲームやadtechが代表的な例ですが、他にもたくさんあります)のビジネス価値は、低レイテンシかつ高性能な読み取り処理を行えるデータベースによってもたらされます。できるだけ早くDynamoDBからデータを取得する機能により、クリックスルー率が最も高いゲームや広告の反応が速くなります。

 

Amazon DynamoDB Accelerator

このような重い読み込み処理を必要とする方の為に我々はパブリックプレビューでAmazon DynamoDB Acceleatorをローンチしました。DAXとも呼びます。

DAXはフルマネージドのキャッシュサービスでDynamoDBテーブルの前段(論理的に)に置かれます。Write – throughモードで動作し、DynamoDBとAPI互換を持っています。キャッシュからレスポンスが返る時はマイクロセカンドのレスポンスを実現し、eventually – consistentなread heavyなワークロードに特に向きます。DAXはシームレスかつ簡単に使えます。シンプルにDAXクラスターを作成する事が出来、アプリケーション側に読み書きのエンドポイントのターゲットとしてDAXを指定するだけです。DAXにパッチを当てるオペレーションをしたり、クラスタのマネジメントやレプリケーション、障害について心配することはありません。

DAXクラスタは1~10ノードで構成されます。読み込み処理の量に応じてノードを追加する事が可能です。クラスタでキャッシュ出来るサイズ(working setとも呼ばれる)はベースとなるノードの大きさ(dax.r3.large から dax.r3.8xlargeまで選択出来ます)を選択してクラスタを作成します。クラスタはVPC内に作成されAvailabillty Zones毎に分割してノードを配置出来ます。

利用するにはDAX for Java SDKを必要とします。このSDKは作成したクラスタとlow – level TCPでのやりとりを行う事で低レイテンシかつ高スループットを実現するためにチューニングしてあります。(我々は今後他の言語向けSDKについても速やかに対応する方針です。)

DAX クラスタの作成

それではDAXクラスタをDynamoDB Consoleから作ってみましょう(APIやCLIでの操作も可能です)。マネジメントコンソールのCreate clusterをクリックして始めます。

まず名前と詳細を入力し次にノードタイプを選択します。そして初期のクラスタサイズを設定します。DAXに与えるIAM roleとpollicyとして私のDynamoDBテーブルにアクセス出来る権限を設定します。(必要な権限が設定されている既存の物を指定する事も可能です。)

例としてコンソールではポリシーとして一つのテーブルにアクセス出来る権限を許可します。アクセスするテーブルを追加したくなったらIAMのコンソール上からポリシーを編集する事で可能です。
次にDAXで使われるノードを配置するサブネットグループを作成します。グループ名とどのサブネットを使うか選択します。

デフォルト設定で起動する事を確認したらLaunch clusterをクリックします。

クラスタは数分で起動します。


次に私のアプリケーションをDAX SDKを使うようにしエンドポイントとして私のDAXクラスタのエンドポイントを指定します。(今回ではdax1.seut3.clustercfg.use1.cache.amazonaws.com:8111です)
アプリケーションを起動し実行、Metricsタブを選択するとキャッシュパフォーマンスに関係するメトリクスを見ることが出来ます。
Amazon CloudWatchメトリクスに含まれキャッシュヒットやキャッシュミス、リクエストカウント、エラーカウントなどが見れます。

Alarmsを選択する事でこのメトリクスを利用したCloud Watch Alarmを作る事が出来ます。

例えばキャッシュミスが異常な数になった物を検知する事が出来ます。

Nodesタグを選択する事でクラス内のノードリストを見ることが出来ます。新しいノードを追加したり削除する事が可能です。

DAXがどのように動いているか、DAXのサンプルアプリケーションをインストールして二回実行してみます。初めにDynamoDBにダイレクトアクセスし、キャッシュが無い状態で操作を行います。ベースラインパフォーマンスとしては以下の通りです。

出力内容の途中に処理グループ毎の結果を見ることが可能です。クエリが2.9~11.3ミリ秒で動作しています。二番目にDAXを使ってパフォーマンスにどのような影響があるかを表示します。


まず一回目はキャッシュが無いのでキャッシュミスをしている状態の結果が表示されています。次のサブシーケンスではキャッシュが働き非常に早く処理が行われている事が確認できます。

Thngs to Know

DAXを使ってアプリケーションが書き込みを行う場合に以下の点について注意下さい。

Java API – 先程お伝えしたように、我々がpublic previewとして公開した時にサポートしているのはJava SDKとなります。計画として他の言語のサポートもあります。DAXはDynamoDBとAPIインターフェイスで互換性を持っている為、コード上で独自のキャッシュロジックであったり大きな変更を必要としません。(すなわちロードするライブラリを変更する事でDynamoDBに対するread / write処理は同じコードで動きreadは自動的にキャッシュから取得出来ます。)

Consistency – eventually consistent readsを使用することでin-memory キャッシュからレスポンスを返す事でDAXで最高のパフォーマンスを引き出す事が出来ます。(DAXは強い一貫性の読み込みではDynamoDBに対して常にreadを実行します。すなわちキャシュを使わないという事です。)

Write-Throughs – DAXはwrite-through キャッシュです。ただし、読み込んだ内容と書き込む内容との間に弱い相関関係がある場合は、書き込みを直接DynamoDBに行う事が出来ます。これにより、DAXはあなたの読み込み処理に対してより大きく助けを出来ると思います(書き込みを直接DynamoDBに行う事でキャッシュ生存期間が終わるまでそのキャッシュを利用する事が出来る為、DynamoDBに対する読み込みを軽減出来るという形です。)

Deprovisionig – DAXをあなたの環境で使用する時、基になるテーブルに対する読み込みキャパシティユニットのプロビジョニングを軽減することでコストが大幅に削減する事が出来ます。(多くの場合は劇的に削減出来ます)また、DAXは読み込み処理の急激な伸びに対応する事が出来ます。

Available Now

DAXは本日からpublic previewとしてUS East(北ヴァージニアリージョン)、US West(オレゴンリージョン)、そしてEU(アイルランドリージョン)にて利用申込後に可能です。public previewでは費用は掛かりません。より詳細を知りたい場合はDAX Developer Guideを是非お読み下さい。

Jeff; (翻訳はSA 成田が担当しました。)

翻訳元blog

新機能 – TTL(Time to Live)機能を利用したDynamoDBアイテムの管理について

AWSを利用頂いている多くのお客様にDynamoDBは使用されています。速度と柔軟性がその理由で、Ad Tech( リファレンスアーキテクチャ )、Gaming( リファレンスアーキテクチャ )、IoT( リファレンスアーキテクチャ )、そして一貫した一桁のミリ秒のレイテンシを実現しアプリケーションを構築されています。また、DynamoDBはフルマネージドのデータベースで、テラバイトサイズのテーブルに対して毎秒何百万というリクエストを処理することができます。
多くのDynamoDBユーザーは、利用する時間が限られている、または時間の経過とともにアクセス頻度が低くなるデータを格納しています。 直近のログイン、試用版のサブスクリプション、アプリケーションのメトリックなどへの利用がそうです。 他にも保管できる期間に関する規制または契約上の制限の対象となるデータを保管します。 これまで、これらを実現するには独自の時間ベースのデータ管理を実装していました。 大規模なシステムでは、DynamoDBアイテムのスキャン、期間を管理するための日付属性の確認、および不要になったアイテムの削除要求を行う為のAmazon Elastic Compute Cloud(EC2)インスタンスを構築するなどの必要があり、これによりアプリケーションのコストと複雑さが増加していました。

新しいTime to Live(TTL)管理 について
この普及した重要なユースケースを合理化するため、新しくTTL(Time to Live)機能の提供を開始しました。 アイテムの有効期限を属性で指定する事により、テーブル単位でこの機能を有効にすることができます。
属性が指定され、TTL管理が有効になると(1回のAPI呼び出しで両方の操作が処理されます)、DynamoDBは期限切れのアイテムを見つけて削除します。 この処理は、自動的かつバックグラウンドで行われ、テーブルへの読み取りまたは書き込みトラフィックには影響しません。

DynamoDBストリームを使用することで(詳細は、「 DynamoDBアップデート – トリガ(Streams + Lambda)+クロスリージョンレプリケーションアプリケーション」を参照)。実際の削除を処理またはアーカイブすることができます。 ストリーム内の他の更新レコードと同様に、削除は24時間単位で行われます。 AWS LambdaおよびDynamoDB Triggersを使用して、期限切れのアイテムをコールドストレージに移動したり、ログに記録したり、他のテーブルを更新したりすることができます。

テーブルのTTLを有効にして、必要な属性を指定する方法は次のとおりです。

指定する属性はDynamoDBのNumber型かつ、 UNIX時間でTTLの指定を行います。
上のスクリーンショットからわかるように、DynamoDB Streamsを有効にすることもできます。また、TTLを有効にすると削除されるアイテムのプレビューを見ることもできます。

また、コードからUpdateTimeToLive関数を呼び出しテーブルにTTLの有効化設定することも、 AWSコマンドラインインターフェイス(CLI)からupdate-time-to-liveコマンドを使用しテーブルでTTLを有効化設定することもできます。

TTL の利用事例(TUNE様)

 AWSのお客様であるTUNEは既に、この機能をHasOffers製品の一部として活用しています。

HasOffersは、マーケティングキャンペーンの効果を分析し、大量の広告エンゲージメントデータをプロセスに保存するのに役立ちます。 キャンペーンの顧客定義の時間枠が過ぎると、データは不要になり、削除することができます。 TTL機能をTUNEで使用できるようにする前は手動で期限切れアイテムを識別し、古いデータを削除しました。 これは労力と激しく計算を必要とし、テーブルのプロビジョニングされたスループットの一部も消費する必要がありました。

今は各アイテムの有効期限を設定し、あとはDynamoDBに任せます。 失効したデータは自動的に消え、使用可能なスループットには影響しません。 その結果、TUNEは85テラバイトの古いデータを削除することができ、年間200,000ドル以上のコストを削減し、アプリケーションロジックも簡素化しました。

知っておくべきこと
あなたのアプリケーションにTTLを使用することを検討する際、留意すべきことがいくつかあります。

TTL属性 – TTL属性は索引付けまたは投影することができますが、JSONドキュメントの要素にすることはできません。 前述したように、Numberデータ型を持つ必要があります。 他の属性と同様に、IAMを使用してこの属性へのアクセスを制限することができます。 指定されたTTL属性を持たない項目は削除対象とはみなされません。 誤ったTTL値による誤った削除を避けるため、5年以上経過しているように見えるアイテムは削除されません。

テーブル – 新しいテーブルまたは既存のテーブルにTTLを適用できます。 テーブルのTTLを有効にするプロセスには最大1時間かかります。一度に1つのテーブルへの変更しか行うことはできません。

削除のバックグラウンド処理について – スキャンと削除はバックグラウンドで行われ、プロビジョニングされたスループットにはカウントされません。 削除時間は、期限切れアイテムの数と性質に応じて異なります。 期限切れの後、実際に削除が行われる前にはアイテムはまだテーブルに残り 、 読み取りとスキャンに表示されます。

インデックス – アイテムは、ローカルのセカンダリインデックスからすぐに削除され、グローバルセカンダリインデックスからは、最終的に一貫した方法で削除されます。

価格 – 内部スキャン操作、削除操作には費用は掛かりません。 アイテムが実際に削除されるまではストレージの支払いが発生します。

今すぐ利用可能
この機能は現在利用可能で、今すぐ使用することができます! 詳細は、「DynamoDBデベロッパーガイド」の「 TTL (訳注:翻訳時点では英語版のみです)」を参照してください。

 

Jeff; (翻訳は成田が担当しました。原文はこちら)

新機能 – Time to Live (TTL) を使用した DynamoDB 項目の管理

AWS のお客様は Amazon DynamoDB を十分に活用しています。お客様は、その速度と柔軟性を気に入り、一貫性がある数ミリ秒台のレイテンシーを活かした広告技術 (リファレンスアーキテクチャ)、ゲーム(リファレンスアーキテクチャ)、IoT (リファレンスアーキテクチャ)、およびその他のアプリケーションを構築しています。また、DynamoDB はマネージ型のサーバーレスデータベースとして、数テラバイトというサイズのテーブルに対する 1 秒あたり数百万件ものリクエストを処理するようにスケールできる点も好評です。多くの DynamoDB ユーザーは、有効期限があるデータや、時間とともにアクセス頻度が低くなるデータを保存している場合があります。最近のログイン、トライアルのサブスクリプション、またはアプリケーションのメトリクスを追跡する場合もあります。保存期間が規制または契約で制限されるデータを保存している場合もあります。このような場合、これまでは独自の時間ベースのデータ管理を導入していました。大規模なケースでは、DynamoDB 項目のスキャン、データ属性のチェック、不要になった項目の削除リクエストの発行などを行うためだけに、数個の Amazon Elastic Compute Cloud (EC2) インスタンスを実行することもありました。これに伴って、アプリケーションのコストと複雑さが増大しました。

新しい Time to Live (TTL) による管理
この一般的で重要なユースケースを効率化するため、当社は本日から、新しい Time to Live (TTL) 機能の提供を開始します。この機能をテーブルごとに有効にし、項目の有効期限を含む項目属性を指定できます。項目属性を指定して TTL 管理を有効にすると (1 回の API コールで両方のオペレーションを実行できます)、DynamoDB が、有効期限が切れた項目を見つけて削除します。この処理は自動的にバックグラウンドで実行され、テーブルに対する読み取りまたは書き込みトラフィックに影響を与えることはありません。DynamoDB ストリーム(詳細については、「Sneak Preview – DynamoDB Streams」を参照) を使用して、実際の削除を処理またはアーカイブできます。削除は、ストリームの他の更新レコードのように、ローリング期間の 24 時間ベースで使用できます。有効期限が切れた項目については、AWS Lambda および DynamoDB トリガーを使用してコールドストレージへの移動、ログへの記録、または他のテーブルの更新を行うことができます。テーブルに対して TTL を有効にし、必要な属性を指定する方法を次に示します。

属性は DynamoDB の数値データ型とする必要があり、UNIX エポック時間形式に従って秒数として解釈されます。上記のスクリーンショットからおわかりのように、DynamoDB ストリームを有効にして、TTL を有効にしたときに削除される項目のプレビューを表示することもできます。また、コードから UpdateTimeToLive 関数を呼び出すか、 update-time-to-live コマンドを AWS Command Line Interface (CLI) から使用することもできます。

TUNE での TTL
AWS のお客様である TUNE は、既にこの機能を自社製品である HasOffers の一部として十分に活用しています。

HasOffers-Dashboard-Phone

HasOffers を使用すると、顧客はマーケティングキャンペーンの効果を分析し、そのプロセスで大量の広告エンゲージメントデータを保存できます。顧客が定義したキャンペーンの時間枠が経過すると、データは必要なくなり、削除できます。当社が TUNE に対して TTL 機能を提供する前は、古くなったデータを手動で識別して削除していました。これは大量の作業と演算を伴う作業であり、テーブル用にプロビジョニングされたスループットの一部を消費していました。現在では、各項目の有効時間を設定するだけで、後は DynamoDB に任せることができます。古くなったデータは自動的に消え、利用可能なスループットに影響はありません。その結果、TUNE は古くなった 85 テラバイトのデータを消去し、アプリケーションロジックを簡略化しながら、年間 20 万 USD を超えるコストを節約しています。

主要事項 お客様のアプリケーションで TTL の利用を検討する際は、以下のことを念頭に置いてください。TTL 属性 – TTL 属性はインデックス化または射影できますが、JSON ドキュメントの要素とすることはできません。前に示したように、数値データ型が必要です。その他の属性と同様に、IAM を使用してこの属性へのアクセスを制御できます。TTL 属性が指定されていない項目は、削除対象とは見なされません。TTL の値が正しい形式ではないために誤って削除される可能性を避けるため、5 年より古いと思われる項目は削除されません。テーブル – 新しいテーブルまたは既存のテーブルに TTL を適用できます。テーブルに対して TTL を有効にするプロセスは最大で 1 時間かかり、一度にテーブルに対して行うことができる変更は 1 つのみです。バックグラウンド処理 – スキャンと削除はバックグランドで実行され、プロビジョニングされたスループットに対してはカウントされません。削除時間は、期限切れの項目の数と特性によって異なります。項目は、有効期限が切れてから実際に削除されるまでテーブルに残り、読み取りやスキャンで表示されます。インデックス – 項目はローカルセカンダリインデックスから直ちに削除され、グローバルセカンダリインデックスからは結果的に整合性のある形式で削除されます。料金 – 内部スキャンオペレーションまたは削除に対して料金は発生しません。項目が実際に削除されるまでのストレージ分のみ、お支払いいただくだけです。

今すぐ利用可能
この機能は今すぐ使い始めることができます。詳細については、DynamoDB 開発者ガイドの「Time to Live」を参照してください。

Jeff;

コストアロケーションタグがAmazon DynamoDBに対応しました

Amazon DynamoDBのテーブルにタグを設定可能になりました。タグは多くのAWSサービスでサポートしている、シンプルでユーザがカスタマイズ可能なキー・バリューのペアです。DynamoDBのタグ対応は DynamoDBの利用料金の可視化に有効です。テーブル毎にタグを設定でき、タグ毎に料金を参照出来ます。

様々な環境(development/staging/production)で複数のDynamoDBテーブルを持っているシナリオを例に上げてご説明します。DynamoDBテーブルにタグを設定出来ます。例として、keyにEnvironment、valueにDevelopment, Staging, Productionとそれぞれ設定します。

DynamoDBコンソールでどのように設定するか見ていきましょう。設定を行う前にListTagsOfResourceとTagResourceのAPI操作を行う適切な権限を持っているか確認をして下さい。

  1. AWS Management Consoleにサインインをし、https://console.aws.amazon.com/dynamodb/からDynamoDBコンソールを開きます
  2. Tablesを選択し、設定を行ないたいテーブルを選択します
  3. Settingsタブで、Tagsをナビゲーションメニューから選択します
  4. Add Tagsセクションで、KeyにEnvironment、ValueにDevelopmentを入力し、Apply Changesをクリックします

Settings

標準の動作では、新しく追加されたキーはbillingでは無効化されています。以下の手順でBilling Consoleよりアクティベートを行えます:

  1. AWS Management Consoleにサインインをし、https://console.aws.amazon.com/billing/からBilling consoleを開きます
  2. ナビゲーションメニューからCost Allocation Tagsを選択します
  3. User-Defined Cost Allocation Tagsセクションから、タグキー内の Environmentタグ横のチェックボックスを選択し、Activateをクリックします

CostAllocationTags

アクティベート済みのコストアロケーションタグがある場合、AWS Cost Explorerからタグ付けされたAWSリソースのコストを簡単にブレークダウンして閲覧出来ます:

  1. AWS Management Consoleにサインインをし、https://console.aws.amazon.com/billing/からBilling consoleを開きます
  2. ナビゲーションメニューからCost Explorerを選択し、Launch Cost Explorerを選択します
  3. 左上のメニューからMonthly costs by serviceを選択し、右のメニュー内の Time rangeから閲覧したいタイムレンジを指定します
  4. Filteringセクション内のFilter byからTagを選択します
  5. タグキーのオートコンプリートフィールドから Environmentを選択、Developmentをタグバリューのオートコンプリートセクションから選択し、Applyをクリックします

Filtering

指定したタグ(Environment=Development)でコストがフィルタリングされます。コストはタグをAWSリソースに指定した時点から表示されます

SaveReport

DynamoDB Management Console, AWS CLIやAWS SDKからDynamoDBテーブルに50個までタグを設定出来ます。DynamoDBテーブルに設定されている、Global secondary indexes (GSIs) と local secondary indexes (LSIs)にもDynamoDBテーブルで設定したタグが自動的に設定されます。DynamoDBのタグサポートは全てのAWSリージョンで利用可能です。

更に詳細な、AWSリソースでのタグの活用はこちらをご覧下さい。

— Nitin Sagar(product manager for DynamoDB) (翻訳は星野が担当しました。原文はこちら)