Amazon Web Services ブログ

Category: Database

Oracle 自律型トランザクションを PostgreSQL に移行する

データベースを移行し稼働させるには、複雑な手順と細部にわたる計画が必要になります。Amazon RDS for PostgreSQL および Amazon Aurora は PostgreSQL と互換性があり、さまざまなユースケースの取扱いに役立ちます。Oracle から PostgreSQL への移行では、Oracle 自律型トランザクションというものがよく話題になります。このブログ記事では自律型トランザクションと、この機能を PostgreSQL で実現する方法について説明します。 永続データのユースケース データベースのトランザクションでは、すべてのステートメントがコミットまたはロールバックされるように SQL ステートメントをグループにしてまとめるメカニズムを提供します。たとえば、口座 A から口座 B へ資金を移動する場合は、以下のような手順を踏む必要があります。 口座 A から必要な金額を引く 口座 B に必要な金額を足す このシナリオでは、両方の手順が成功しているか、両方が失敗しているかのいずれかを確認する必要があります。これは、データベースのトランザクションで両方の SQL ステートメントを実行することで可能になります。これは非常に役に立つ機能です。また多くのユースケースで必要になります。ただし、アプリケーションによっては、トランザクションが失敗してもデータを保持する機能が必要なケースもあります。 PostgreSQL と Oracle はいずれも同じトランザクション原理に従っていますが、このユースケースに対応するために、Oracle では自律型トランザクションという機能を提供します。PostgreSQL には自律型トランザクションそのままの機能はありませんが、dblink を使用することで同様の結果を得られます。 自律型トランザクションとは何でしょうか。 Oracle は自律型トランザクション機能を提供しています。この機能では、メイントランザクションのコミットやロールバックを実行することなく、サブプログラムによる SQL オペレーションの実行、さらには各 SQL オペレーションのコミットまたはロールバックが可能です。 以下のようなシナリオを想定してください。 INSERT トリガーのビジネスロジックに従い、重要な情報を持つ 1 行をテーブルに追加する必要があるとします。 SQL の INSERT […]

Read More

SQL Server エージェントのジョブを AWS Step Functions に置き換える

Microsoft SQL Server から Amazon Aurora PostgreSQL への移行の場合に、SQL エージェントのジョブを簡単に移動できないことにお気づきかもしれません。Aurora PostgreSQL ではジョブエージェントツールがサポートされていません。この制限を克服するには、AWS Step Functions を使用して SQL エージェントのジョブを置き換えます。 このブログ記事では、ステップ関数を作成して、SQL ストアドプロシージャを実行する SQL エージェントのジョブを置き換える方法を示します。 ソリューションを実行するためのステップ このソリューションを実行するためのコードと AWS CloudFormation テンプレートは、この GitHub Amazon Repository にあります。 ソリューションを作成するために、CloudFormation テンプレートを使用して以下を準備します。 パブリックで利用可能なスナップショットからの SQL Server データベース用の Amazon RDS。 ステートマシン用の IAM ロール。 Step Functions アクティビティ。 Step Functions ステートマシン。 Step Functions ステートマシンを起動するための Amazon CloudWatch Events ルール。 CloudFormation テンプレートを使用して上記のリソースを準備した後に、以下の操作を実行します。 […]

Read More

Amazon RDS for SQL Server 上で SQL Server 2008 R2 から SQL Server 2016 にアップグレードする方法に関するベストプラクティス

 このブログ記事では、Microsoft SQL Server 2008 R2 のサポート終了に備えて、Amazon RDS for SQL Server 上で SQL Server 2008 R2 から SQL Server 2016 にアップグレードする方法を中心にご紹介します。また、ご紹介するプラクティスの多くは、SQL Server のすべてのバージョン、あるいは他の RDS のエンジンにも適用することができます。 注意: 現在、SQL Server 2008 R2 から RDS の SQL Server 2017 へのアップグレードパスはありません。SQL Server 2017 にアップグレードする場合は、2012、2014、または 2016 にアップグレードしておく必要があります。 自己管理型プラットフォームでは、最新のデータベースバージョンへのアップグレードに多くのリスクが伴います。多くの企業は「壊れてないものは直すな」をモットーとしています。 幸い、自己管理型プラットフォームでふだん直面する課題の多くは、Amazon RDS が提供する自動化によって軽減されます。 SQL Server DB インスタンスの場合、アップグレードには次の 2 種類があります。 メジャーバージョンのアップグレード (SQL Server […]

Read More

アプリケーションをオンプレミスの Oracle データベースから Amazon RDS for PostgreSQL に移行する方法

企業は長年、独自にローカルデータベースを設定し、ハードウェアを自社で管理する必要がありました。しかし、クラウドインフラストラクチャが向上し続けており、自社でハードウェアを所有・管理する必要が格段に少なくなっています。 Amazon では、所有している何百 (あるいは何千もの) オンプレミスのデータベースを、時間をかけてクラウドベースのソリューションに移行しました。このソリューションには、Amazon RDS のようなリレーショナルなものと、Amazon DynamoDB のような非リレーショナルなものの両方があります。リレーショナルなソリューションに移行したデータベースでは、無料で使用でき、Oracle データベースと類似の機能 (シーケンス、トリガー、パーティション) を持つデータベース技術を検討してコストを削減しようとも試みました。技術面でそれに最も近いものが、PostgreSQL です。 このブログ記事には 2 つのセクションがあります。まず、共通の Java アプリケーションと Hibernate のレイヤー (オブジェクトリレーショナルマッピング) における変更について述べます。その後、Java アプリケーションを Oracle から Amazon RDS for PostgreSQL に移行した際に明らかとなった、アプリケーション層を管理するためのベストプラクティスと方針について述べます。今回の提案と事例は、RDS および PostgreSQL と互換性のある Amazon Aurora の両方を基盤としたデータベースを対象とするものです。 Hibernate とアプリケーションレイヤーの変更およびベストプラクティス まず、お使いのアプリケーションを分析することから始めます。移行を成功させるために、移行予定のアプリケーションについて深く理解することをおすすめします。以下は開始するにあたり、全体についての質問です。 お使いのアプリケーションは、Hibernate のようなオブジェクトリレーショナルマッピング (ORM) を使用していますか? 使用している場合、アプリケーションでどの Hibernate データ型を使用していますか? お使いのアプリケーションには変換を必要とする可能性のあるプレーン SQL が今もありますか? この中からいくつかの質問を取り上げ、なぜそれが重要なのかを考えてみましょう。 お使いのアプリケーションは ORM を使用していますか? アプリケーションが ORM […]

Read More

Amazon DynamoDB ストリームを使用して、順序付けされたデータをアプリケーション間でレプリケーションする方法

AWS の顧客は、Amazon DynamoDB を使用してミッションクリティカルなデータを保存しています。このような顧客のアプリケーションから 1 秒に何百万ものリクエストが、何百テラバイトの項目を含む個々の DynamoDB テーブルに送られます。顧客は DynamoDB が瞬時に結果を返すことを頼りにしています。 多くの場合、これらのアプリケーションには特定のトランザクション、監査、またはアーカイブトランザクションについて他のシステムとユーザーに通知し、データを別のデータストアにほぼリアルタイムでレプリケートするという要件があります。これらの要件は、DynamoDB 内の項目への変更の順序を維持することで満たすことができます。このような機能を構築するには、DynamoDB 内の項目への変更が並列処理され、ほぼリアルタイムのパフォーマンスを達成することが必要です。 Amazon DynamoDB ストリーム を他の AWS サービスと統合して、順序付けられたほぼリアルタイムのデータ処理機能を構築することができます。DynamoDB ストリームは、DynamoDB テーブルの項目レベルの変更に対して時間順序のシーケンスをキャプチャし、その情報を最高 24 時間まで保存します。そしてアプリケーションからは、ほぼリアルタイムで DynamoDB ストリームからの一連のストリームレコードにアクセスすることができます。 この記事では、AWS サーバーレスコンピューティングの一部である複数の AWS サービスを使用して DynamoDB ストリームを処理するための複数のパターンを評価します。また、他のシステムやユーザーに通知し、トランザクションをアーカイブし、順序付けされた処理を維持しながらデータを別のデータストアにレプリケートするために、ほぼリアルタイムの DynamoDB ストリーム処理を実行できる最も信頼性の高いスケーラブルなパターンの詳細にも触れます。 AWS Lambda を使用した DynamoDB ストリームの処理 AWS Lambda は、サーバーをプロビジョニングまたは管理せずにコードを実行できるサービスです。たとえば Lambda は、DynamoDB ストリームのイベント (項目の挿入、更新、削除など) に基づいてコードを実行できます。Lambda は DynamoDB ストリームをポーリングし、新しいレコードを検出すると Lambda 関数を呼び出し、1 つ以上のイベントを実行します。 Lambda による DynamoDB […]

Read More

Performance Insights で Amazon RDS for MySQL をチューニングする

Amazon RDS Performance Insights は、Amazon RDS への直感的なチューニングインターフェイスを提供し、RDS データベースのパフォーマンスの問題を発見して調査するのに役立ちます。Performance Insights のルックアンドフィールは、RDS for MySQL、RDS for PostgreSQL、Amazon Aurora など、すべてのデータベースエンジンタイプで共通です。けれども、エンジンはどれも実装の点で少し異なります。 Performance Insights は、エンジンに関係なく常にデータベースの負荷と上位の SQL を表示できます。エンジンはどれも、拡張データの保持や Amazon CloudWatch との統合など、Performance Insights の機能をサポートしています。ただし、データベースエンジンの種類によっては、 Performance Insights はエンジンのネイティブパフォーマンス計測に基づいてわずかに異なる情報を表示します。 たとえば、PostgreSQL との互換性を持つ Aurora では、データベースの負荷が PostgreSQL 10 の待機イベントによって細分化されています。MySQL 互換性 と RDS MySQL を備えた Aurora では、 MySQL Performance Schema 待機イベントによって細分化された負荷が表示されます。Performance Insights は、各エンジンタイプのネイティブ待機イベント計測を待機イベント用に消費することにより、各エンジンのネイティブパフォーマンス計測に忠実でありながら、各エンジンタイプ間で同様のルックアンドフィールを維持することができます。 2018 年 8 月 28 日、バージョン […]

Read More

Apache Cassandra データベースから Amazon DynamoDB への移行を容易にする

お客様から、さまざまなデータベースエンジン間でのデータの移行 (異種間移行とも呼ばれています) は困難で時間がかかるという話を伺います。サムスンのような一部のお客様は、Apache Cassandra データベースを Amazon DynamoDB に移行する方法を自ら探らなければなりませんでした (「Moving a Galaxy into the Cloud: Best Practices from Samsung on Migrating to Amazon DynamoDB」をご覧ください)。NoSQL データベース間のこれらの移行は、データの規模と変更の速度のため、より困難になりえます。詳細については、この「Applied Live Migration to DynamoDB from Cassandra」テックトークをご覧ください。 AWS Database Migration Service (AWS DMS) と AWS Schema Conversion Tool (AWS SCT) により、AWS のお客様はデータベースを AWS クラウドに移行しやすくなりました。AWS DMS と AWS SCT を使用して、任意のサポート対象のソース (MongoDB など) から任意のサポート対象のターゲット […]

Read More

過去18ヶ月間で見逃した可能性のある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入門をご参照ください。 著者について […]

Read More

AWS GlueとAmazon Athenaを使用して、Amazon DynamoDBのデータ抽出と分析を簡素化

100,000人以上のAWSユーザーが、モバイル、Web、ゲーム、アドテック、IoT、その他多くのアプリケーション向けにAmazon DynamoDBを選択しました。たとえば、DuolingoはDynamoDBを使用して、1秒あたり24,000回の読み取り容量単位と3,300回の書き込み容量単位となるテーブルに、310億アイテムを格納しています。 DynamoDBは、あらゆる規模のアプリケーションやマイクロサービスに幅広く対応できます。また、DynamoDBの多くの顧客は、DynamoDBテーブルに格納されているデータに対して、分析とアドホッククエリを実行します。このプロセスには一般的に、Amazon S3などの大規模なデータ分析とクエリのために、DynamoDBテーブルのデータをデータストアにコピーまたはアーカイブすることが含まれます。AWS Glueと新しいDynamoDBのクロール、そして抽出機能を使用することで、分析のためにAmazon S3へデータを移動する作業を簡素化できます。 この記事には、AWS Glueを使用してDynamoDBテーブルをクロールし、Amazon S3にデータを抽出し、Amazon AthenaでSQLクエリを使用して分析を実行するという方法が載っています。これらのサービスは、AWS上で完全に管理され、スケーラブルで、サーバーレスなサービスを使用することにより、DynamoDBからのデータの移動と解析の作業を簡素化しています。また、実践的なチュートリアルと独自のAWSアカウントで、ワークフローをテストできるAWS CloudFormationテンプレートもご提供しています。 ソリューションの概要 この記事のソリューションは、次の図に示すように、AWS Glue、Amazon S3、Athenaを使用して、DynamoDBからのデータのクロール、抽出、および解析を実行しているということです。 AWS Glueは完全に管理されており、分析のために使うデータ準備時間のプロセスを自動化するpay-as-you-goや抽出、変換、そしてロード(ETL)サービスをご提供しています。AWS Glueは、AWS Glue Data CatalogおよびAWS Glueクローラを介してデータを自動的に検出し、プロファイルを作成します。ソースデータをターゲットスキーマに変換するためのETLコードを推奨して生成します。次に、完全に管理されたETLジョブを、スケールアウトされたApache Spark環境で実行し、データをその宛先にロードします。AWS Glueを使用すると、複雑なデータフローを設定、調整、監視することもできます。 また、AWS Glue ETLジョブを作成して、DynamoDBテーブルからAmazon S3やAmazon Redshiftなどのダウンストリーム分析用のサービスに、データを読み込んだり、変換、ロードすることもできます。 上の図に示すように、ソリューション例のアーキテクチャーの仕組みは次のとおりです。 AWS CloudFormationは、AWSアカウントにDynamoDBテーブルを作成し、ニューヨーク市タクシーアンドリムジン委員会(TLC)の運行記録データの一部を入力します。AWS Glueのクローラは、DynamoDBからスキーマを検出し、AWS Glue Data Catalogにメタデータを設定します。 AWS Glueジョブは、Apache Parquetファイル形式のDynamoDBテーブルからデータを抽出し、S3に格納します。Parquetは、Hadoopエコシステムのプロジェクトで使用できる円柱状のストレージファイル形式であり、Athenaでクエリを効率化します。 AWS Glue ETLジョブは、AWS Glue Data Catalogによって提供される、定義済みのスキーマに結果を格納します。 Athenaは、Amazon S3で新しく抽出されたデータの外部スキーマストアとしてAWS Glue Data Catalogを使用します。SQLを使用してAmazon S3を直接クエリするために、Athenaを利用することで、データ分析を実行できます。 大規模なDynamoDBテーブルのベストな演習 AWS Glue ETLジョブは、同時実行データ処理ユニット(DPUs)のコンセプトを使用して、ジョブ実行の計算能力を描きます。単一のDPUには、4つの仮想中央処理装置(vCPUs)と16 […]

Read More

Amazon DynamoDBの適応能力が不均一なデータアクセスパターンに対応する仕組み(または、なぜDynamoDBについて知っている情報が古くなっているのか)

Amazon DynamoDBは、あらゆる規模の高性能な非リレーショナルデータベースです。これは、組み込み式のセキュリティ、バックアップ、およびデータ保護を使用して、スループットニーズに適応する、十分に管理されたサービスです。10万人以上の開発者が、モバイル、Web、ゲーム、アドテック、IoT、および低レイテンシのデータアクセスを必要とするその他のアプリケーション向けのDynamoDBを選択しました。 しかし、以前は余分なスループットを提供することでアシストしていた不十分な容量、これに関連するエラーにより要求が失敗することを心配しているという声を、依然として顧客から聞きました。これらの顧客は通常、DynamoDBは、他のキーよりもいくつかのキーをより多く読み書きするクエリパターンなど、プライマリキー(ハッシュキーまたはパーティションキーとしても知られている)全体でトラフィックが均一でないワークロードに精通している、という印象を受けます。 この記事では、DynamoDBの容量とサービス提供の仕組みがもはや懸念事項ではないことについて説明しています。これを行うには最初に、DynamoDBがどのようにしてパーティションとサーバー間でデータを分割させるのかという基礎部分を説明します。次に、あなたが過去に経験したことがあるかもしれない不均一なワークロードの問題を修正する、適応能力と呼ばれる機能を強調したいと思います。最後に、適応能力を実証するために、独自のAWSアカウントで実行できるサンプルアプリケーションを紹介します。 スケーリングに対するDynamoDBのアプローチ 注意:すでにDynamoDBパーティショニングを理解していて、適応能力についてのみ知りたい場合は、次のセクションに進んでください。 DynamoDBがデータをどのように管理するのかを理解することから始めましょう。他の非リレーショナルデータベースと同様に、DynamoDBは、複数のサーバー間で1つまたは複数のパーティションに、テーブルを水平分割します。しかし、独自のNoSQLデータベースのホスティングからDynamoDBを使用することとの違いは何ですか? Amazon EC2が、サーバーハードウェアを仮想化して、規模、効率、低コストのメリットを兼ね備えたマルチテナントエクスペリエンスを作成するのと同じように、DynamoDBもデータベースハードウェアと同様に機能します。 DynamoDBは、次の例の図で示すように、物理サーバー間でテーブルのパーティションを透過的に分割します。テーブル1は、異なるサーバー上にある2つのパーティション(T1.p1とT1.p2)に分割されています。 DynamoDBを使い始めるには、テーブルを作成して読み書きを開始するだけです。データベースノードまたはクラスタのための適切なハードウェア(CPU、RAM、そしてストレージなど)の選択について、心配する必要はありません。DynamoDBはバックグラウンドでハードウェアリソースを処理します。DynamoDB Auto scalingでは、アプリケーションの要求レートに対応する適切な読み取りおよび書き込みスループットが自動的に設定されます。ワークロードが進化するにつれて、DynamoDBは、読み取りスループット、書き込みスループット、およびストレージの変化に応じて、パーティションを自動的に再共有し、動的に再配分します。 この場合、ストレージの拡張がトリガーとなるDynamoDBの再構築の仕組みの例を見てみましょう。パーティションA、B、Cに分割された1つのDynamoDBテーブルがあると仮定します。これらのパーティションは、次の図に示すように、3つに分かれた物理サーバー(サーバー1、サーバー2、およびサーバー3)に格納されます。 注意:DynamoDBは、実際には9つのソリッドステートドライブ(3つではありません)にこのテーブルのデータを格納します。これは、AWS Regionの3つの機能にデータの複製が自動生成され、サーバ障害やアベイラビリティーゾーンの中断時にフォールトトレランスをご提供するためです。しかし、この例では、単純化のために複製を割愛しています。 この場合、アプリケーションは、次の図に示すように、パーティションAへの書き込みのほとんどを行っています。つまり、パーティションAのストレージはほぼ満杯となります。 DynamoDBは、入力を必要とせずに、自動的にパーティションAを2つに分割します。パーティション1はサーバー1に、パーティション2はサーバー4に配置されます。この変更はアプリケーションにとって透過的で、DynamoDBは自動的に新しいパーティションにリクエストを送信します。 パーティションの仕組みを説明したので、DynamoDBの適応能力について詳しく説明します。 適応能力の仕組みはどのようなものか もし以前にDynamoDBを使用していた場合は、最適なパフォーマンスのために均等に分散されたトラフィックを配信するように、アプリケーションを構築することをDynamoDBがお薦めしているということを、おそらく知っているでしょう。つまり、リクエストは主要なキー全体に均等に分散する必要があります。これは、適応能力の前に、DynamoDBが読み書きのスループットをパーティション間で均等に割り当てるためのものです。例えば、4つのパーティションに分散された、1秒あたり400回の書き込み(つまり、400回の書き込み容量単位、または「WCUs」)が可能なテーブルがある場合、各パーティションには100 WCUが割り当てられます。1つのパーティションに1秒あたり100回を超える書き込み(ホットパーティション)を受信する不均一なワークロードがあった場合、これらのリクエストによってProvisionedThroughputExceededExceptionエラーを返信された可能性があります。 実際には、完全一律にアクセスすることは困難です。不均一なデータアクセスパターンに対処するために、DynamoDBの適応能力により、(もちろん、全体のテーブルレベルのスループットを超えていない限り)リクエストが失敗することなくホットパーティションへの読み書きを継続できます。適応能力は、より多くのトラフィックを受け取るパーティションのスループット能力を自動的に増加させることによって機能します。適応能力に関するさらに詳しい分析については、このAWS re:Invent 2017ブレークアウトセッションビデオ(63分)をご参照ください。 次の図は、適応能力の例を示しています。この一例のテーブルには、4つのパーティション間で均等に共有される400個のWCUが提供され、各パーティションで1秒あたり最大100個の書き込みを維持できます。ただし、パーティション1〜3は1秒あたり50回の書き込みしか受信しませんが、パーティション4では1秒あたり150回の書き込みを受信するため、アプリケーションは不均一なトラフィックを発生させます。DynamoDBの適応能力は、自動的にパーティション4に「ブースト」を適用し、100 WCU以上の割り当てを消費することができます。したがって、アプリケーションは不均一なトラフィックにもかかわらず、正常かつ無期限に動作し続けます。 適応能力は、デフォルトですべてのDynamoDBテーブルで使用できるため、明確に有効または無効にする必要はありません。これはDynamoDBによって完全に管理されるため、新しいAmazon CloudWatch測定基準を監視する必要はありません。DynamoDBがテーブル上の適応能力をアクティブにすると、ワークロードが不均衡のままであっても、テーブルは無期限にトラフィックの不均一を処理し続けます。 カナダの人口調査への適用 – 適応能力の実践 非一様なワークロードを引き起こす典型的なアプリケーションに、適応能力がどのように対応し、そしてどのようにホットパーティションによって引き起こされるProvisionedThroughputExceededExceptionエラーを排除するか調べてみよう。このセクションでは、ダウンロードして実行できるサンプルアプリケーションの結果について説明します。 シナリオ – カナダの人口調査 10の州と3つの地域にまたがるカナダの人口に対して、オンラインの国税調査アプリケーションを構築していると仮定しましょう。DynamoDBを使用し、次の画像に表されるスキーマを有するテーブルにアプリケーションのユーザー応答を保管します(Provinceはパーティションキーであり、ResponseIdはソートキーです)。 今、カナダについての知識を特に持っていないと仮定しましょう。具体的に、次の画像に現れるカナダの人口分布に関した雑学的なことは少ししか分かりませんでした。 残念ながら、人口が各地方において、均等に分布していないため、私たちのパーティションキーとソートキーは、スキーマの選択肢を貧弱にしています。つまり、私たちのDynamoDBのアクセスパターンでは、人口がより多く集まる地域は、より頻繁に書き込まれるため、トラフィックの分布が不均一になります。次のカナダの人口に関する円グラフでは、カナダ人の60%以上がオンタリオ州とケベック州という2つの州にしか住んでいないことを示しています。 人口調査アプリケーションのサンプルの概要 アプリケーションのサンプルは、カナダ人口調査のウェブアプリケーションを再現します。まず、このアプリケーションで、Province、ResponseIdをそれぞれ主要なキー、ソートキーとして、3,000 WCUと3,000回の読み取り容量ユニット(RCU)を持つDynamoDBテーブルを作成します。作成された4つのパーティションに多くのスループット能力の結果を提供します。その後、25 WCUを持つ4つのパーティションごとで書き込まれたスループットを100 WCUに減らします。次に、アプリケーションはカナダの実績人口分布に従って、エンドユーザーからの1秒あたり70件の人口調査に関する回答を再現します。各人口調査の回答ごとに、アプリケーションのサンプルによって作成されたDynamoDBテーブルに新しい項目を書き込みます。このアプリケーションは、10秒あたり一行のデータを作成し、各州ごとに成功した書き込み数を反映します。 アプリケーションのサンプルを自分で実行するには、このGitHubリポジトリにアクセスしてください。アプリケーションを実行する前に、次のことにご注意ください。 アプリケーションを実行するには、DynamoDBにアクセスするためのAWSアカウントと権限が必要です。 模擬実験を実行する時間と、毎月の無料リソースをすでに使い果たしているかどうかという状態によって、DynamoDBのわずかな費用(約10ドル)が発生する可能性があります。このアプリケーションには約4時間にあたり3,000 WCUと3,000 RCUが必要です。 模擬実験が完了した後でクリーンアップをするには、アプリケーションで使用されるDynamoDBテーブルを削減したり削除する必要があります。 アプリケーションのサンプルの実行とその結果の解釈 実際の人口分布に比例して、1秒あたり70回の書き込みをランダムに実行すると、各州がどのように運賃を支払うかを見てみましょう。次のグラフは、出力のプロットを示しています。青色のONライン(オンタリオ州)とオレンジ色のQCライン(ケベック州)の成功率は低下し、その後正常に戻ることに注意してください。 オンタリオ州とケベック州の文字列の値がランダムなチャンスで同じパーティションにマップされていたため、オンタリオ州とケベック州の書き込みは約13分後に終了しました。その結果、スループットの25%が提供されているに過ぎず、1つのパーティションがテーブルのトラフィックの60%以上を占めていました。デフォルトの5分のバースト容量が役立ちました(そのため、歪みはすぐには発生しませんでした)が、トラフィックの不均衡が持続するために最終的に疲弊してしまいました。適応能力の前に、これらのProvisionedThroughputExceededExceptionエラーに対する唯一の対応策は、提供されたスループットを向上させるか、より均一なデータアクセスのためにアプリケーションを再設計することでした。 しかし、次の図に示すように、約30分後に正常な書き込みが回復したことになります。これは、適応能力が回復したときということです。DynamoDBは介入を必要とせずに、不十分なパーティションレベルのスループットによってトリガーとなったリクエストの失敗を検出しました。次に、DynamoDBは不均衡をもっとうまく処理するためにテーブルを調整しました。通常、テーブルがリクエストの失敗に遭遇してから、適応能力が正常なパフォーマンスに復帰するまでに5〜30分かかります。 何が起こっているかをズームアウトしたビューについては、次のCloudWatchグラフをご参照ください。正常な書き込みリクエスト(青色の線)と抑制された書き込みリクエスト(オレンジ色の線)を表します。同じパターンが実行されることに注意してください。ワークロードが正常に実行され、パーティションレベルのアクティビティが不十分であるために調整が行われ、適応能力によって正常なパフォーマンスが回復します。 […]

Read More