Amazon Web Services ブログ

Amazon DynamoDB レイテンシの理解

Amazon DynamoDB は水平分割を使用しほとんどのテーブルサイズに対応することができます。水平分割の例とし、DynamoDB は全てのワークロードサイズに対して数ミリ秒での性能を提供します。Amazon.comなどリテールサイトではDynamoDBをショッピングカードのワークフローエンジンに使用しています。注文プロセスでレスポンスが遅いのはカスタマの不満だけではなく、ビジネスコストの問題にもなります。注文プロセスでの遅延は収益、顧客体験、ビジネスの成長に直接、影響を与えます。

本記事では DynamoDB のレイテンシと DynamoDB を使用するアプリケーションで通常よりも高いレイテンシに対応する手法を詳しく解説します。

(本記事は 2023/04/12に投稿された Understanding Amazon DynamoDB latency を翻訳した記事です。)

DynamoDB のレイテンシとは？


DynamoDB API レイテンシはクエリが DynamoDB インフラストラクチャーが入力された時からユーザにレスポンスされるまでの間に発生します。レイテンシには「サービスサイドレイテンシ」、「クライアントサイドレイテンシ」の２種類があります。

エンドツーエンド (end-to-end) レイテンシは責任共有モデルであり、サービスサイドレイテンシは DynamoDB サービスが、クライアントサイドレイテンシはユーザがアプリケーションのシナリオ及び環境を適切に構成する責任があります。

サービスサイドレイテンシとは？


サービスサイドレイテンシは DynamoDB に API リクエストが到達、 DynamoDB がレスポンスをユーザアプリケーションに返すまでの処理時間を指します。サービスサイドレイテンシはアプリケーションタスクが DynamoDB パブリックエンドポイントに接続、或いは処理結果( result )をダウンロードするまでの時間を含めておりません。

Amazon CloudWatch SucessfulRequestLatenc メトリクスでサービスサイドレイテンシを分析することができます。レイテンシメトリクスに断続的なスパイクがある場合は心配することではありません。ただし、 SucessfulRequestLatenc メトリクスは平均的なレイテンシを分析するベストプラクティスなため、平均的なレイテンシが持続的に高い場合、レイテンシに影響を与える根本的な問題がある可能性があります。

一般的なサービスサイドレイテンシより高いレイテンシに対応する方法

DynamoDB を使用する一つのメリットは DynamoDB が完全マネージドサービスであることです。 これは貴方がパッチ、セキュリティー、レプリケーション、データ安全性、スケールインスタンスのセットアップ、バックアップやリカバリーを気にしなくても良いということを指します。同様にサービスサイドレイテンシも DynamoDB の責任になります。もし継続的に高いサービスサイドレイテンシがある場合、 AWS Support にサポートケースを作成してください。サポートから DynamoDB サービスチームに問題の解決方法を確認します。

クライアントサイドレイテンシとは？


SucessfulRequestLatenc メトリクスが高くないにもかかわらずアプリケーションが一般的なケースよりレイテンシが高い場合は、クライアントサイドレイテンシが高い可能性があります。

次の「図１」にはアプリケーションと DynamoDB エンドポイント間の流れが描いています。流れがユーザからインターネットを通して DynamoDB エンドポイントに向かっています。リクエストは処理され、レスポンスが DynamoDB エンドポイントからインターネットを通してユーザに戻ります。

図１：アプリケーションと DynamoDB エンドポイント間の流れのアーキテクチャダイヤグラム

一般的に普通のクライアントサイドレイテンシより高いレイテンシが発生する原因は

  • クライアントから DynamoDB パブリックエンドポイントへのネットワークレイテンシ
  • DynamoDB パブリックエンドポイントからクライアントへのネットワークレイテンシ
  • DynamoDB パブリックエンドポイントから得た結果を処理する時間が平均より長い時間を必要とするクライアントアプリケーション

クライアントサイドから上記の課題を識別するには SDK metrics をお勧めします。これらのメトリクスはレイテンシを増加するソースを識別するのに役に立てます。AWS SDK を使用しレイテンシメトリクスをロギングするためより詳しい情報を確認したい場合は Amazon DynamoDB で高レイテンシをトラブルシューティングする方法(英語)をご覧ください。

AWS SDK メトリクスを使用することでどの API が最も時間を消費しているかを把握することができます。これらの機能はデフォルトではありません。 AWS SDK for Java を使用する例では貴方はシステムプロパティを貴方の AWS セキュリティー認証情報ファイル( security credential file ) に指定、アプリケーションに起動する際にメトリクスを活性化することができます。次の Java SDK コマンドはデフォルトメトリクスを活性化します。

-Dcom.amazonaws.sdk.enableDefaultMetrics=credentialFile=/path/aws.properties

注：構成と一致するように /path/aws.properties を変更する必要があります。

boto3 SDKでメトリクスを活性化するには環境変数に下記のコードを追記してください。

export AWS_CSM_ENABLED=true

SDK メトリクス で使用可能な他の構成設定を確認してください。

「図２」では DynamoDB の PutItemRequest を使用し書き込みを行った場合のクライアントサイド HTTP レスポンスタイム ( HttpClientReceiveResponseTime ) とクライアントサイドトータルリクエスト完了タイムを比較しています。このクラフは例で、貴方のレイテンシと完全に一致するものではありません。

図２： SDK クライアントサイドメトリクスグラフ

上記の内容でサービスサイドレイテンシとクライアントサイドレイテンシ、またそれらをどう扱うかを学習しました。それ以外に DynamoDB のレイテンシを確認するのに役に立てる重要な機能を解説します。

DynamoDB クライアントレジリエンシー

一つのシステムが他のシステムを呼び出す際、接続エラーが発生する可能性があります。これらのエラーはサーバ、ネットワーク、ロードバランサー、ソフトウェア、オペレーションシステムなど多様なソースから発生します。 AWS のシステムは障害の発生可能性を減らし、障害が発生した場合には復元力をもつように設計されて、お客様にも自らのシステムにも同様な設計をすることをお勧めしています。リトライ、タイムアウト、バックオフのエラスティックなシステムを構築するための３つの戦略があります。

タイムアウト、リトライ

システム接続エラー状態でレイテンシを復元する場合、バックオフアルゴリズムを使用しないためにはフェイルファスト( fail fast )し、リトライをするのが最も良い方法です。フェイルファストするには DynamoDB API 呼び出しに対して短いリクエストタイムアウトを設定する必要があります。そうすると DynamoDB が結果を返すまで無限に待つのではなく、リクストタイムアウトが発生し AWS SDK が自動でリトライを行います。 DynamoDB の分散特性( distributed nature )により新しいアプリケーションリトライをリクエストしたら2回目以降に早めに結果を返す可能性があります。 AWS SDK for Java でレジリエンシーをチューニングするにはこちら(英語)をご覧ください。useTcpKeepAlive 設定を使用するとコネクションあたりにより多くのリクエストを発生、 DynamoDB クライアントのレイテンシを減らせることが可能です。

リトライ、バックオフ

リトライアルゴリズムを指定しない場合は AWS SDK はエクスポネンシャルバックオフ( exponential backoff ) を使用します。この場合、アプリケーションロジックで長い待機時間を発生するリトライを防ぐため SDK の構成を修正するのはユーザ側の責任になります。

エクスポンシャルバックオフの基本的なアイディアは連続的なエラーレスポンスに対するリトライに対して少しずつ長い待機時間を適用することです。最大遅延の間隔と最大リトライ回数は必ず固定された値ではなく、実行中の作業及びネットワークレイテンシなど他のローカル的な要因を考慮して設定する必要があります。ほとんどの AWS SDK は連続的な衝突を防ぐため、 jitter ( reandomized delay ) を使用してエクスポネンシャルバックオフアルゴリズムを実装しています。詳細はこちら(英語)をご覧ください。

DynamoDB global tablesの利用

DynamoDB global tablesをお勧めする２つの理由があります。

  1.  高速、ローカルライズされた読み込み、書き込み性能を提供、ユーザ体験を向上します。
  2.  ビジネスの連続性、災害復旧

低レイテンシでユーザ体験を改善する

モーダンアプリケーションの成功はネットワークレイテンシ及びネットワークの処理量に直接的な関係があります。ネットワークレイテンシを腹し、処理量を改善するためコンテンツ提供者は Amazon CloudFront コンテンツデリバリネットワーク( CDN ) を使用し静的コンテンツをユーザの違いところでデリバリします。これはレイテンシを減らし、ユーザ体験を改善します。

しかし、 CloudFront が静的コンテンツのデリバリ問題を解決するとしても、動的コールはバックエンドで必要になり、バックエンドサーバが遠いところにある可能性もあるので処理には時間がかかるケースがあります。これらの遅延は多くの有名なゲーム、e – commerce プラットフォーム、インタレクティブなアプリケーションには受け入れないことでしょう。DynamoDB global tables を使うと、分散されているグローバルユーザの近くにデータを保持することができます。データのレプリケーションは DynamoDB の内部的に処理されます。アプリケーションはいつでも近いグローバルテーブルレプリカからリクエストを処理します。

「図３」はグローバルアプリ及び全世界に分散されているユーザに対する DynamoDB グローバルテーブル アーキテクチャを表現しています。

図３： DynamoDB global tables アーキテクチャ

ビジネス連続性、災害復旧

ミッションクリティカルなワークロードを設計する際にはリソースの障害可能性を考慮しなければなりません。リソースの障害は必然的であり、障害が発生した場合はレイテンシが増加、顧客体験が低下します。従って、リソースの障害を耐えて、迅速に自動復旧が可能なアプリケーションをデザインする必要があります。

global tablesを使用するとシングール AWS リージョンが隔離されたり、性能が低下、正常より高レイテンシが発生した場合にアプリケーションが別のリージョンにリダイレクトされ他のレプリカテーブルに対して書き込み、読み込みすることができます。カスタムビジネスロジックを追加しリクエストがリダイレクトされるタイミングを定義することが可能です。詳細はブログの Amazon DynamoDB で復元性があるアプリケーションを構築(英語)をご覧ください。

リージョンが隔離されたり、性能が低下した場合は DynamoDB は実行された書き込みで全てのレプリカテーブルに連携されてないものを追跡します。リージョンが再度、オンライン状態になると DynamoDB は対象リージョンに保留中の書き込みを連携します。また、他のリージョンから隔離されていたリージョンに隔離中に実行された書き込みを連携します。詳しい内容は Global tables の動作をご覧ください。

DynamoDB Accelerator ( DAX )

アプリケーションの読み込みが多い場合、 DynamoDB Accelerator ( DAX ) を使用しよく使われるアイテムをキャッシングすることをお勧めします。 DAX はフルーマネージド、高可用性のインメモリキャッシュで秒単位で数百万のリクエストがあった場合にもミリセカンド以下のレイテンシでリクエストを処理します。 DAXを使用すると呼び込みディストリビューションの考慮は必要ありません。最初のリクエストは DynamoDB table に転送されますが、今後の結果整合性読み込みはメモリで処理されます。これは DAX を使うとレイテンシ性能の改善及び DAX が DynamoDB テーブルに転送される読み込みリクエストを減らし、結果的に DynamoDB のコストをを減らせることを意味します。

まとめ


本記事では DynamoDB で作業する際に発生する２つのレイテンシタイプ (サービスサイドレイテンシ、クライアントサイドレイテンシ) を説明しました。レイテンシを減らせる提案事項は以下となります。
・ AWS SDK metrics を活性化しクライアントサイドレイテンシをトラブルシューティングする
・コネクションタイムアウトを減らす
・ Global tables を使用しレイテンシを減らす、さらに災害復旧が可能にする
・ DAX を使用しよく使われるアイテムをキャッシングする
本ブログに記載された方法を試した後にもレイテンシが高い場合は AWS support に問い合わせし、追加の問題解決方法及びサポートを確認してください。

本記事の内容に質問及びフィードバックがある場合はコメントをお願いします。

元作者情報


Sandip Gangdhar は Amazon Web Service のクラウドアーキテクト、 DynamoDB 専門家です。彼はクラウド技術分野に 10 年以上の経験があります。 AWS では主に戦略的な技術選択で革新的なビジネス成果にフォーカス、お客様を次のレベルに案内しています。プライベートでは家族と時間を過ごすのが好きです。