Amazon Web Services ブログ

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分割テーブルパーティションの図表

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のストレージはほぼ満杯となります。

パーティションAのストレージがほぼ満杯であることを示す図

DynamoDBは、入力を必要とせずに、自動的にパーティションAを2つに分割します。パーティション1はサーバー1に、パーティション2はサーバー4に配置されます。この変更はアプリケーションにとって透過的で、DynamoDBは自動的に新しいパーティションにリクエストを送信します。

DynamoDBの図は、パーティションAをサーバー1に、パーティションDをサーバー4に自動的に分割します

パーティションの仕組みを説明したので、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つの州にしか住んでいないことを示しています。

カナダ人の60％以上がオンタリオ州とケベック州に住んでいることを表した円グラフ

人口調査アプリケーションのサンプルの概要

アプリケーションのサンプルは、カナダ人口調査のウェブアプリケーションを再現します。まず、このアプリケーションで、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分のバースト容量が役立ちました（そのため、歪みはすぐには発生しませんでした）が、トラフィックの不均衡が持続するために最終的に疲弊してしまいました。adaptive capacityの前に、これらのProvisionedThroughputExceededExceptionエラーに対する唯一の対応策は、提供されたスループットを向上させるか、より均一なデータアクセスのためにアプリケーションを再設計することでした。

しかし、次の図に示すように、約30分後に正常な書き込みが回復したことになります。これは、adaptive capacityが回復したときということです。DynamoDBは介入を必要とせずに、不十分なパーティションレベルのスループットによってトリガーとなったリクエストの失敗を検出しました。次に、DynamoDBは不均衡をもっとうまく処理するためにテーブルを調整しました。通常、テーブルがリクエストの失敗に遭遇してから、adaptive capacityが正常なパフォーマンスに復帰するまでに5〜30分かかります。

何が起こっているかをズームアウトしたビューについては、次のCloudWatchグラフをご参照ください。正常な書き込みリクエスト（青色の線）と抑制された書き込みリクエスト（オレンジ色の線）を表します。同じパターンが実行されることに注意してください。ワークロードが正常に実行され、パーティションレベルのアクティビティが不十分であるために調整が行われ、adaptive capacityによって正常なパフォーマンスが回復します。

成功した書き込みリクエス（青色の線）と抑制された書き込みリクエス（オレンジ色の線）を示すCloudWatchグラフ

まとめ

このブログの記事が、adaptive capacityによるDynamoDBの不均衡なワークロードに対応する方法を、明確にしてくれることを願っています。adaptive capacityにより、読み書きのスループットを過剰に提供する必要はありません。Auto scalingと組み合わせれば、必要なときに必要なスループットを得ることができ、トラフィックが減少するとダイアルダウンができます。

DynamoDBのadaptive capacityの詳細については、DynamoDB Adaptive Capacityと、このAWS re：Invent 2017ブレークアウトセッションのビデオ（63分）をご参照ください。

原文: How Amazon DynamoDB adaptive capacity accommodates uneven data access patterns (or, why what you know about DynamoDB might be outdated)

 

著者について

リチャード・クログの写真リチャード・クログはアマゾンウェブサービスにおけるシニアソフトウェア開発者です。

 

 

 

 

カイ・ザオの写真カイ・ザオは、アマゾン ウェブ サービスのシニアプロダクトマネージャです。