Amazon Web Services ブログ

Elasticsearch チュートリアル: クイックスタートガイド

 Elasticsearch は、インデックス作成を含めたあらゆる目的に対応する REST API オペレーションを備えています。REST API に加えて、最も一般的な開発言語用に AWS SDK もあります。このガイドでは、REST API を使用して、言語にとらわれない方法で基礎となるテクノロジーについて学ぶことができます。 インデックス作成が Elasticsearch のコアです。数テラバイトのデータを超高速で検索することができます。しかし、存在していないデータを検索することはできません。そこでこの記事では、インデックスを作成し、データを Elasticsearch に入れ、Amazon Elasticsearch Service を使用して Elasticserach で検索する方法を説明します。 Amazon Elasticsearch Service ドメインの作成 まだ AWS アカウントを持っていなければ、AWS アカウントにサインアップしましょう。新規アカウントでサインアップした際、無料利用枠を使用すると Amazon Elasticsearch Service を 12 ヶ月間無料で利用できます。また Amazon Elasticsearch Service を始めるのはとても簡単です。 アカウントが準備できたら、Amazon Elasticsearch Service ドメイン (クラスターの設定あり) を作成します。1 つを取得するには (約 15 分かかります)、Amazon Elasticsearch Service ドメインの作成と設定の手順に従ってください。 Amazon […]

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

Amazon Kinesis および Amazon Athena を使用して VPC ネットワークのトラフィックを分析および視覚化する

ネットワークログの分析は多くの組織で一般的に実施されています。  ネットワークログを収集し、分析することにより、ネットワーク上のデバイスがそれぞれ、およびインターネットとどのように通信しているかを把握できます。  たとえば、監査、コンプライアンス、システムのトラブルシューティング、セキュリティフォレンジックなど、ログ分析を実行する理由は多数あります。  Amazon Virtual Private Cloud (VPC) では、VPC Flow Logs を使用してネットワークフローをキャプチャできます。  VPC、サブネット、ネットワークインターフェイス用のフローログを作成できます。  サブネットまたは VPC のフローログを作成した場合、VPC の各ネットワークインターフェイスまたはサブネットがモニタリングされます。フローログのデータは Amazon CloudWatch Logs のロググループに公開され、各ネットワークインターフェイスにはユニークなログストリームが作成されます。 CloudWatch Logs にはこのログデータの洞察を確保するうえで有用なツールがいくつか用意されています。  しかし、ほとんどの場合、ログデータを S3 に効率的にアーカイブし、SQL を使用してクエリ検索する手法が好まれます。  この手法ではログの保存に対しより大きな柔軟性と管理性が得られるとともに、必要な分析も実行できるようになります。  しかし同時に、分析を自動的に実行することでログデータが生成された直後にログデータの洞察をほぼリアルタイムで取得する機能もよく好まれる傾向にあります。  また、VPC 内のネットワークトラフィックをより明確に理解できるよう、ダッシュボードである程度のネットワークの特徴を視覚化することにも関心が集まっています。  つまり、S3 への効率的なログのアーカイブとリアルタイムのネットワーク分析、データの可視化のすべてを達成するにはどうすればよいでしょうか?  これは、CloudWatch、Amazon Kinesis、AWS Glue、Amazon Athena などの複数の機能を組み合わせることで達成自体は可能ですが、このソリューションをセットアップし、すべてのサービスを構成するのは容易ではありません。 このブログ記事では、VPC フローのログデータを収集、分析、資格するための完璧なソリューションについて解説します。  さらに、独自のアカウントにこのソリューションを効果的にデプロイできる 1 つの AWS CloudFormation テンプレートを作成しました。 ソリューションの概要 このセクションではアーキテクチャの概要とこのソリューションの各ステップについて解説します。 私たちは 1 回限り、またはアドホックでフローログデータをクエリする機能を必要としています。また、ほぼリアルタイムでそれを分析できる手立ても必要です。つまり、私たちのフローログデータはこのソリューションを通して 2 つのパスを取ることになります。  アドホッククエリには、Amazon […]

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のadaptive capacityが不均一なデータアクセスパターンに対応する仕組み(または、なぜDynamoDBについて知っている情報が古くなっているのか)

Amazon DynamoDBは、あらゆる規模の高性能な非リレーショナルデータベースです。これは、組み込み式のセキュリティ、バックアップ、およびデータ保護を使用して、スループットニーズに適応する、十分に管理されたサービスです。10万人以上の開発者が、モバイル、Web、ゲーム、アドテック、IoT、および低レイテンシのデータアクセスを必要とするその他のアプリケーション向けのDynamoDBを選択しました。 しかし、以前は余分なスループットを提供することでアシストしていた不十分な容量、これに関連するエラーにより要求が失敗することを心配しているという声を、依然として顧客から聞きました。これらの顧客は通常、DynamoDBは、他のキーよりもいくつかのキーをより多く読み書きするクエリパターンなど、プライマリキー(ハッシュキーまたはパーティションキーとしても知られている)全体でトラフィックが均一でないワークロードに精通している、という印象を受けます。 この記事では、DynamoDBの容量とサービス提供の仕組みがもはや懸念事項ではないことについて説明しています。これを行うには最初に、DynamoDBがどのようにしてパーティションとサーバー間でデータを分割させるのかという基礎部分を説明します。次に、あなたが過去に経験したことがあるかもしれない不均一なワークロードの問題を修正する、adaptive capacityと呼ばれる機能を強調したいと思います。最後に、adaptive capacityを実証するために、独自のAWSアカウントで実行できるサンプルアプリケーションを紹介します。 スケーリングに対するDynamoDBのアプローチ 注意:すでにDynamoDBパーティショニングを理解していて、adaptive capacityについてのみ知りたい場合は、次のセクションに進んでください。 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の適応能力について詳しく説明します。 adaptive capacityの仕組みはどのようなものか もし以前にDynamoDBを使用していた場合は、最適なパフォーマンスのために均等に分散されたトラフィックを配信するように、アプリケーションを構築することをDynamoDBがお薦めしているということを、おそらく知っているでしょう。つまり、リクエストは主要なキー全体に均等に分散する必要があります。これは、adaptive capacityの前に、DynamoDBが読み書きのスループットをパーティション間で均等に割り当てるためのものです。例えば、4つのパーティションに分散された、1秒あたり400回の書き込み(つまり、400回の書き込み容量単位、または「WCUs」)が可能なテーブルがある場合、各パーティションには100 WCUが割り当てられます。1つのパーティションに1秒あたり100回を超える書き込み(ホットパーティション)を受信する不均一なワークロードがあった場合、これらのリクエストによってProvisionedThroughputExceededExceptionエラーを返信された可能性があります。 実際には、完全一律にアクセスすることは困難です。不均一なデータアクセスパターンに対処するために、DynamoDBのadaptive capacityにより、(もちろん、全体のテーブルレベルのスループットを超えていない限り)リクエストが失敗することなくホットパーティションへの読み書きを継続できます。adaptive capacityは、より多くのトラフィックを受け取るパーティションのスループット能力を自動的に増加させることによって機能します。adaptive capacityに関するさらに詳しい分析については、このAWS re:Invent 2017ブレークアウトセッションビデオ(63分)をご参照ください。 次の図は、adaptive capacityの例を示しています。この一例のテーブルには、4つのパーティション間で均等に共有される400個のWCUが提供され、各パーティションで1秒あたり最大100個の書き込みを維持できます。ただし、パーティション1〜3は1秒あたり50回の書き込みしか受信しませんが、パーティション4では1秒あたり150回の書き込みを受信するため、アプリケーションは不均一なトラフィックを発生させます。DynamoDBのadaptive capacityは、自動的にパーティション4に「ブースト」を適用し、100 WCU以上の割り当てを消費することができます。したがって、アプリケーションは不均一なトラフィックにもかかわらず、正常かつ無期限に動作し続けます。 適応能力は、デフォルトですべてのDynamoDBテーブルで使用できるため、明確に有効または無効にする必要はありません。これはDynamoDBによって完全に管理されるため、新しいAmazon CloudWatchなどによる監視をする必要はありません。DynamoDBがテーブル上のadaptive capacityをアクティブにすると、ワークロードが不均衡のままであっても、テーブルは無期限にトラフィックの不均一を処理し続けます。 カナダの人口調査への適用 – adaptive capacityの実践 非一様なワークロードを引き起こす典型的なアプリケーションに、adaptive capacityがどのように対応し、そしてどのようにホットパーティションによって引き起こされるProvisionedThroughputExceededExceptionエラーを排除するか調べてみよう。このセクションでは、ダウンロードして実行できるサンプルアプリケーションの結果について説明します。 シナリオ – カナダの人口調査 10の州と3つの地域にまたがるカナダの人口に対して、オンラインの国税調査アプリケーションを構築していると仮定しましょう。DynamoDBを使用し、次の画像に表されるスキーマを有するテーブルにアプリケーションのユーザー応答を保管します(Provinceはパーティションキーであり、ResponseIdはソートキーです)。 今、カナダについての知識を特に持っていないと仮定しましょう。具体的に、次の画像に現れるカナダの人口分布に関した雑学的なことは少ししか分かりませんでした。 残念ながら、人口が各地方において、均等に分布していないため、私たちのパーティションキーとソートキーは、スキーマの選択肢を貧弱にしています。つまり、私たちのDynamoDBのアクセスパターンでは、人口がより多く集まる地域は、より頻繁に書き込まれるため、トラフィックの分布が不均一になります。次のカナダの人口に関する円グラフでは、カナダ人の60%以上がオンタリオ州とケベック州という2つの州にしか住んでいないことを示しています。 人口調査アプリケーションのサンプルの概要 アプリケーションのサンプルは、カナダ人口調査のウェブアプリケーションを再現します。まず、このアプリケーションで、Province、ResponseIdをそれぞれ主要なキー、ソートキーとして、3,000 WCUと3,000回の読み取り容量ユニット(RCU)を持つDynamoDBテーブルを作成します。作成された4つのパーティションに多くのスループット能力の結果を提供します。その後、25 […]

Read More