Category: Amazon DynamoDB
DynamoDB Accelerator (DAX) が正式にサービス開始しました
今年の初め頃 Amazon DynamoDB Accelerator（DAX）について紹介をしました。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が書いたブログを紹介させて頂きます。
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桁のミリ秒単位で測定され、多くのお客様がadtech、IoT、ゲーム、メディア、オンライン学習、旅行、電子商取引、金融など、さまざまな種類のアプリケーションに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 成田が担当しました。）
新機能 – 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 （訳注：翻訳時点では英語版のみです)」を参照してください。
新機能 – 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 を使用すると、顧客はマーケティングキャンペーンの効果を分析し、そのプロセスで大量の広告エンゲージメントデータを保存できます。顧客が定義したキャンペーンの時間枠が経過すると、データは必要なくなり、削除できます。当社が 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操作を行う適切な権限を持っているか確認をして下さい。
- AWS Management Consoleにサインインをし、https://console.aws.amazon.com/dynamodb/からDynamoDBコンソールを開きます
- Tablesを選択し、設定を行ないたいテーブルを選択します
- Settingsタブで、Tagsをナビゲーションメニューから選択します
- Add Tagsセクションで、KeyにEnvironment、ValueにDevelopmentを入力し、Apply Changesをクリックします
標準の動作では、新しく追加されたキーはbillingでは無効化されています。以下の手順でBilling Consoleよりアクティベートを行えます:
- AWS Management Consoleにサインインをし、https://console.aws.amazon.com/billing/からBilling consoleを開きます
- ナビゲーションメニューからCost Allocation Tagsを選択します
- User-Defined Cost Allocation Tagsセクションから、タグキー内の Environmentタグ横のチェックボックスを選択し、Activateをクリックします
アクティベート済みのコストアロケーションタグがある場合、AWS Cost Explorerからタグ付けされたAWSリソースのコストを簡単にブレークダウンして閲覧出来ます:
- AWS Management Consoleにサインインをし、https://console.aws.amazon.com/billing/からBilling consoleを開きます
- ナビゲーションメニューからCost Explorerを選択し、Launch Cost Explorerを選択します
- 左上のメニューからMonthly costs by serviceを選択し、右のメニュー内の Time rangeから閲覧したいタイムレンジを指定します
- Filteringセクション内のFilter byからTagを選択します
- タグキーのオートコンプリートフィールドから Environmentを選択、Developmentをタグバリューのオートコンプリートセクションから選択し、Applyをクリックします
指定したタグ(Environment=Development)でコストがフィルタリングされます。コストはタグをAWSリソースに指定した時点から表示されます
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) (翻訳は星野が担当しました。原文はこちら)
