Category: Amazon DynamoDB

みなさん、こんにちわ。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング エバンジェリストの亀田です。   Amazon DynamoDBのグローバルテーブル機能が東京リージョンに対応しましたのでお知らせいたします。 DynamoDBはどのような規模でも信頼性が高いパフォーマンスを維持できる、完全マネージド型の非リレーショナルデータベースです。グローバルテーブルの機能により、マルチリージョン、マルチマスターのデータベースを構築することが可能となり、そのレイテンシーを 10 ミリ秒未満に維持できるようになります。選択した AWS リージョンにテーブルの更新内容を自動的にレプリケーションすることができ、また、グローバルテーブルを使用して、DynamoDB テーブルデータを他の AWS リージョンにレプリケーションすることで可用性を高めることもできます。   作成済のDynamoDBテーブルを選択すると、「グローバルテーブル」のタブが出てきます。設定作業はテーブル作成後に行うこととなりますが、テーブルが空である必要があるのでご注意ください。 ここから、機能を有効にすることができます。機能を使うためにはDynamoDB Streamsの機能をオンにする必要があります。DynamoDB Streamsは、テーブルに対して発生した変更をキャプチャし、例えばAWS Lambdaを実行させるなどに機能をつかさどります。グローバルテーブルはこの機能を用います。 そして対象リージョンを指定すると、レプリカテーブルが指定したリージョンに作成されます。 DynamoDBは今年の5月に継続的バックアップとPITR（ポイントインタイムリカバリ）に対応しより使いやすくなっています。今回のグローバルテーブル対応で、より高度な耐障害性とリージョンワイドのアプリケーションへのより高速な対応性能を備えることなりました。 – プロダクトマーケティング エバンジェリスト 亀田

Amazon DynamoDBチームはencryption at restに引き続き新しい機能を発表しました。AWS re:Invent 2017 では、グローバルテーブルの作成と DynamoDBテーブルのオンデマンドバックアップとリストアを発表しました。そして今日、継続的バックアップとしてPITR（ポイントインタイムリカバリ）を利用出来るようになりました。 AWS Management Consoleからワンクリックするか、簡単なAPIコール、またはAWSコマンドラインインターフェイス（CLI）を使用して継続的バックアップを有効にすることができます。DynamoDBはPITRが有効になってから35日以内であれば1秒単位でデータをバックアップし、1秒単位でリストアできます。誤った書き込みや削除を防ぐためにこの機能を構築しました。開発者がステージングではなくプロダクションに対してスクリプトを実行した場合や誤ったDeleteItemを実行した場合はPITRでカバー出来ます。その為予測できないようなシナリオにも利用出来ます。オンデマンドバックアップはアーカイブ目的のために必要なタイミングを指定できますが、PITRは偶発的なデータ消失に対する追加の保険として機能します。これがどのように機能するか見てみましょう。 継続的バックアップ マネジメントコンソールでこの機能を有効にするには、テーブルに移動して[ バックアップ ]タブを選択します。そこから、Enableをクリックするだけで有効になります。また、UpdateContinuousBackups API呼び出しを使用して継続的バックアップを有効にすることもできます。 継続的バックアップを有効にした後、最も遠い復元日と最新の復元日時を確認出来ます。 削除したい古いユーザーデータがたくさんある、というシナリオを例にとってみます。 私はlast_updateに格納されている日付に基づいてアクティブなユーザーだけに通知を送信したいと考えました。そしてサービスを使用していないユーザーを削除するために簡単なPythonスクリプトを書くことに決めました。 import boto3 table = boto3.resource(“dynamodb”).Table(“VerySuperImportantTable”) items = table.scan( FilterExpression=”last_update >= :date”, ExpressionAttributeValues={“:date”: “2014-01-01T00:00:00″}, ProjectionExpression=”ImportantId” )[‘Items’] print(“Deleting {} Items! Dangerous.”.format(len(items))) with table.batch_writer() as batch: for item in items: batch.delete_item(Key=item) すばらしい！これでサービスに2013年以来ログインしていない厄介な非アクティブユーザをすべて削除するはず・・・CTRL + C CTRL + C CTRL + […]

Aravind Kodandaramaiah は AWS パートナープログラムのパートナーソリューションアーキテクトです。 はじめに AWS ワークロードを実行するお客様は Amazon DynamoDB と Amazon 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 […]

今日（翻訳元記事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 成田が翻訳しました。元記事はこちら）

今年の初め頃 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が書いたブログを紹介させて頂きます。 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が実行される！ […]

既に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にダイレクトアクセスし、キャッシュが無い状態で操作を行います。ベースラインパフォーマンスとしては以下の通りです。 […]

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を使用することを検討する際、留意すべきことがいくつかあります。 […]

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

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 […]