Category: Amazon DynamoDB

Amazon DynamoDB は、信頼性の高いパフォーマンスをあらゆる規模で提供できる非リレーショナルデータベースです。これは完全管理型マルチリージョンのマルチマスターデータベースで、レイテンシは一桁台のミリ秒単位の安定性です。また、ビルトインのセキュリティ、バックアップとリストア、およびメモリ内キャッシュを提供します。 このブログの投稿は、過去18ヶ月のDynamoDBハイライトを要約したものです。この記事を読んで、データベースの規模、パフォーマンス、そして可用性を改善させながら、所有者の総コスト（TCO）を削減してクラウド変革を促進する方法を学んでください。 1. DynamoDBなどのAWS独自のデータベースは、アプリケーションに理想的なツールを提供します ワークロードをクラウドに移行する際に、アプリケーション用に画一的なリレーショナルデータベースを実行するための、フリーサイズのすべてのアプローチが不要です。独自のデータベースを使用して、適切な仕事（アプリケーション）に適したツール（データベース）を選択し、非リレーショナルデータベースの基礎となるDynamoDBを選択できるようにします。 ワーナー・ヴォゲルス：AWS独自のデータベース（ブログ記事） AWS独自のデータベース戦略：適切な仕事に適したツール（ビデオ） AWS独自のデータベース戦略の適用 （ビデオ） 2. DynamoDBは過去18ヶ月間に多くの新機能を追加しました DynamoDBは、心配の無い暗号化、バックアップとリストア、Amazon DynamoDB Accelerator、Time To Live、そしてグローバルテーブルなどの機能を着実に開始しています。次のビデオを見るか、付属のプレゼンテーションのスライドを読んで、AmazonのDynamoDBの歴史と、皆さんが操作にではなくコードに集中することができるよう、私たちがどのように革新を続けて行くかを学んでください。 Amazon DynamoDBの新機能（ビデオ） Amazon DynamoDB の新機能 (デッキ) 3. DynamoDBは、99.999％のサービス水準合意（SLA）をご提供します。 AWSは稼働時間を考慮してDynamoDBを設計しました。2018年6月から、DynamoDBには99.999％の稼働率のSLAがあります。DynamoDB SLAの詳細をお読みください。 DynamoDBサービス水準合意（ウェブページ） 4. 適応能力により容量の計画がさらに簡単になります 不均一なアクセスパターンやワークロードに対して、DynamoDB適応能力により、アプリケーションは一貫したパフォーマンスで読み書きを継続できます。 Amazon DynamoDBの適応能力が不均一なデータアクセスパターンに対応する仕組み（または、なぜDynamoDBについて知っている情報が古くなっているのか）（ブログ記事） DynamoDB適応能力：入り組んだワークロードのためのスムーズなパフォーマンス（ビデオ） 5. ポイントインタイムリカバリーとオンデマンドバックアップを使用して、データベースのバックアップとリストアを自動化 DynamoDBは、今年初めに連続バックアップとポイントインタイムリカバリー（PITR）を開始しました。これらの機能を使用すると、過去35日間のデータベースを1秒あたりで自動的にバックアップおよびリストアすることができます。PITRを有効にするためのメンテナンスやコードは必要ありません。 Amazon DynamoDB連続バックアップとポイントインタイムリカバリー（ブログ記事） DynamoDBのオンデマンドバックアップとリストア（ドキュメンテーション） 6.グローバルテーブル：DynamoDBは、唯一のマルチリージョン、マルチマスターデータベースサービスです グローバルテーブルでは、DynamoDBは唯一のマルチリージョン、マルチマスターデータベースサービスです。グローバルテーブルを使用して、最も厳しいビジネスの継続性要件を満たすマルチレージンソリューションを実行できます。また、グローバルテーブルを使用して、世界中のどこからでもエンドユーザーに向けた低レイテンシのデータアクセスが可能になります。 Amazon DynamoDBアップデート – グローバルテーブルとオンデマンドバックアップ（ブログ記事） 7.顧客は、Cassandraなどの他のデータベースからDynamoDBに移行しています SamsungやGumGumなどの企業は、CassandraからDynamoDBに移行し、結果としてTCOを最大70％削減しました。おそらく、DynamoDBへの移行の最大のメリットは、データベースを稼動させ続けることではなく、ビジネス革新に集中できるようになることです。 Apache CassandraデータベースをAmazon DynamoDBに簡単に移行する（ブログ記事） SamsungはCassandraからDynamoDBへ1 PBを移行（ビデオ） Hosted CassandraからAmazon DynamoDBへの移行：年間60％のコスト削減へと飛躍（ブログ記事） 概要 この記事では、過去18ヶ月間の主要なDynamoDBのハイライトの一部が再度要約されています。DynamoDBの機能の詳細については、Amazon DynamoDBの機能をご参照ください。DynamoDBの使用を開始するには、DynamoDB入門をご参照ください。 著者について […]

Database フリークな皆様、こんにちは！AWS DevDay Tokyo 2018 Database トラックオーナーの江川です。 2018 年 10 月 29 日（月）〜 11 月 2 日（金）にかけて、AWS DevDay Tokyo 2018 が開催されました。本記事では、11/1(木)に実施された Database トラックのセッション資料をご紹介します。 セッション資料紹介に先立ち、お客様セッションとしてご登壇いただいた、Sansan株式会社間瀬様、株式会社ソラコム安川様、Amazon Pay 吉村様にお礼申し上げます。併せて、ご参加いただいた皆様、ストリーミング配信をご覧いただいた皆様ありがとうございました。   ●お客様セッション資料 AWSサービスで実現するEightの行動ログ活用基盤(Sansan株式会社 間瀬哲也様) AWSサービスで実現するEightの行動ログ活用基盤 from Tetsuya Mase DynamoDB Backed なテレコムコアシステムを構築・運用してる話(株式会社ソラコム 安川 健太様) AWS Dev Day Tokyo 2018 | Amazon DynamoDB Backed な テレコムコアシステムを構築・運用してる話 from SORACOM,INC DynamoDBとAmazon Pay で実現するキャッシュレス社会 […]

みなさん、こんにちわ。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング エバンジェリストの亀田です。   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を使用することを検討する際、留意すべきことがいくつかあります。 […]