Category: Amazon DynamoDB

従来のオンプレミスデータベースのライセンスコストとインフラストラクチャコストは増えつづけ、データベースのスケーリングが大きな課題になっています。このような場合には何ができるでしょうか? このブログ記事では、AWS クラウドに移行するときにデータベースコストを削減し、可用性を向上させる戦略について説明します。

AWS ではこの 2019 年、DynamoDB での作業時にミッションクリティカルなワークロードのパフォーマンスを最大化して、コストを最適化するために役立つ Amazon DynamoDB のベストプラクティスに従うことをお勧めします。この記事は、このような抱負の維持を助ける DynamoDB のコンテンツに焦点を当てて行きます。

このブログ記事では、リソースをひとつ、または複数のタグに基づいてグループ化し、スケーリングプランを使用することによって AWS Auto Scaling ポリシーを集約、設定、および管理する方法をご紹介します。スケーリングプランを使用すると、タグを用いることによって AWS Auto Scaling ポリシーの作成を自動化し、これらのポリシーを簡単に変更できます。

先日 (2018/12/25) 開催しました AWS Black Belt Online Seminar「Amazon DynamoDB Advanced Design Pattern」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. 「時系列データが必要なアプリケーション」のスライドで GSIKey Rand(0-N) というのがありましたが、これはどのような目的がありますか？ A. こちらにあるような形で、書き込み後の検索効率向上の為のテクニックになります。 今後の AWS Webinar スケジュール 直近で以下のオンラインセミナーを予定しています。各オンラインセミナーの詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております！ AWS Black Belt Online Seminar 1月分申込先 ≫ Redshift Recently Features Update 2019 年 […]

この記事では、私たちが 2018 年に掲載した AWS データブログ記事で、最もよく読まれた10本を紹介しています。このリストをガイドとして使って、まだ読んでいないデータベースブログに目を通す、または特に有益だと思った記事を読み返すことができます。

このブログ記事では、データを保護する一般的なデータセキュリティパターンとそれに対応する AWS セキュリティコントロールに焦点を当てます。クラウド内の機密データを保護するための効果的な戦略を立てるには、一般的なデータセキュリティパターンをよく理解し、これらのパターンを明確にマッピングしてクラウドセキュリティコントロールに活かすことが必要です。

この記事では、Amazon DynamoDB を使用して、複数の AWS リージョンにデプロイされたグローバルバックエンドのデータベースを強化する方法について説明します。ここでは DynamoDB グローバルテーブルを使用します。これは完全マネージド、マルチリージョンかつマルチマスターのデータベースを提供するもので、世界中のどこにいても低レイテンシーのデータアクセスをユーザーに提供できます。

この記事では、グローバルセカンダリインデックスを使用してデータを照会し、アプリケーションのパフォーマンスを向上させ、毎月の DynamoDB 請求金額を削減する方法をいくつかご紹介します。最近、テーブルあたりのグローバルセカンダリインデックスの最大数が 5 から 20 に、制限が引き上げられました。そのため、今が DynamoDB の使用を最適化するためのグローバルセカンダリインデックスの使用方法を学ぶ恰好のタイミングです。

最もアクセスしたデータベース項目のグラフとダッシュボードを表示することを可能にする Amazon DynamoDB キー診断ライブラリを公開しました。このブログ記事では、主要な診断ライブラリを設定する方法を説明します。次に、ライブラリの視覚化を使用して、映画データベースの例で、不均一なアクセス分布のキーを特定する方法を説明します。

少し前まで、あなたのビジネスに合わせていつでもスケールし安定した低いレイテンシを提供するデータベースを作成することは困難でした。2012年にWerner VogelsがpostしたブログでAmazon DynamoDBがアナウンスされました。（これは私がAWSに入る数ヶ月前の事でした。）DynamoDBは2007年にAmazonが公表したDynamoの論文に基づいて設計されています。それから数年、多くの新機能がAWSの顧客が利用するデータベースを更に簡略化するために導入されました。今、フルマネージドかつマルチリージョン、マルチマスターデータベースとencryption at rest、point-in-time recovery、in-memory cachingなどの機能、そして99.99%のuptime SLAを提供しています。 Amazon DynamoDB On-Demand 今日我々はAmazon DynamoDB on-demand、事前のキャパシティプランニングが不要で1秒あたり数千リクエストのトラフィックにも対応が出来るフレキシブルな課金を実現する新しいオプションを案内します。DynamoDB on-demandはシンプルなpay-per-request課金モデルを提供しreadリクエストとwriteリクエストを使った分に応じて支払うだけになります。これによりシンプルなコスト計算とパフォーマンス管理を実現します。例えばtableにon-demanmd modeを適用すると、DynamoDBは即座に対応しワークロードに応じて以前に観測されたトラフィックレベルまで処理できるようにパフォーマンスを調整します。また新たなピークトラフィックが観測されたときはDynamoDBはワークロードに対応するために迅速に適応します。（翻訳者注: DynamoDBは内部的にパーテーションという概念で負荷を分散します。そのため一度拡張されたテーブルは内部的に何もしなくても拡張された状態を維持している事と、新たな負荷が発生したときも自動的に拡張して対応します。） DynamoDBのコンソールを見るとon-demand read/wriite capacity modeが新規テーブル作成時と既存テーブルのCapacityタブに追加されている事が確認出来ます。 on-demand modeを適用したTableは全てのDynamoDBの機能がサポートされ（例としてencryption at rest、point-in-time recovery、global tablesなど）、例外としてauto scalingはこのmodeでは無効になります。 on-demand modeが有効な状態でセカンダリインデックスを構築した場合も同じスケーラビリティと課金モデルが適用されます。セカンダリインデックスへも使った分だけお支払い頂き事前にキャパシティプロビジョニングする必要はありません。もしon-demand modeが有効なtableでread/writeリクエストが発生しなかった場合、支払う必要があるのはストレージ課金のみになります。 DynamoDBは予測困難なアプリケーショントラフィックへの対応や短期間で大きなスパイクが発生するワークロード、もしくはあなたのテーブルの使用率が平均では低い場合にとても有効です。例えば以下のようなユースケースです。 新たなアプリケーション開発時、もしくはワークロードが複雑で予測が困難な場合 pay-per-use な課金モデルのサーバレスサービスとの組み合わせ SaaSプロバイダやソフトウェアベンダーでシンプルかつリソース分離を必要とするようなアプリケーションを開発している on-demand modeへの変更は1日1回可能です。on-demandからprovisioned modeへの変更も可能です。 簡単にパフォーマンステストをやってみましょう では早速新たに作ったDynamoDB on-demand modeのtableに対して負荷テストを実施してみましょう。 私は2つのサーバレスアプリケーションを作ってみました。 1つ目のアプリケーションはAmazon API GatewayとAWS LambdaでHTTPインターフェイスによるDynamoDBに対してread/writeする処理を実装しています。 2つ目のアプリケーションはLambdaで1000個の並行に同時実行でランダムにHTTPメソッドを生成しendpointに各Itemに操作リクエストを生成するファンクションです。 全てのファンクションは同時実行数100でリクエストを実行し、終了するとすぐにまた別の100同時実行がスタートする処理を一分間行います。ランプアップするために必要な時間は無く、負荷の生成はフルスピードで実行されます！！ DynamoDB コンソールのメトリクス tabから、ピーク時には5000request/secの負荷が流れていることとスロットリングが発生しないことをメトリクスから確認ができます。 サーバレスアプリケーションがscalingするか、API GatewayとLambdaとDynamoDBはフルマネージドで対応が出来ています。スループットやアプリケーションロジックに寄る課金の仕組みを計画する事はなく実現出来ました。 […]