Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DynamoDB でスロットリングが発生したとき/when_throttling_occurs...

emi
November 20, 2024

DynamoDB でスロットリングが発生したとき/when_throttling_occurs_in_dynamodb_short

2024/11/21(木)
クラメソさっぽろIT勉強会 (仮) #6:パフォーマンスチューニング
https://classmethod.connpass.com/event/333630/

で登壇する際の資料です。

emi

November 20, 2024
Tweet

More Decks by emi

Other Decks in Technology

Transcript

  1. 2 目次 • Purpose Built Database • DynamoDB とは •

    DynamoDB でパフォーマンスが出ない! • スロットリングの原因と対応策 • おわりに
  2. 3 Purpose Built Database • Purpose Built Database • DynamoDB

    とは • DynamoDB でパフォーマンスが出ない! • スロットリングの原因と対応策 • おわりに
  3. 6 Purpose Built Database • 最新のアプリケーション要件 • より多くのパフォーマンス、 拡張性、可用性が必要 •

    アプリのアーキテクチャと パターンも進化 同時アクセス メディアストリーミング オンラインゲーム 電子商取引 医療 : クライアント・サーバー Web 3 層 マイクロサービスアーキテクチャ :
  4. 7 Purpose Built Database • Purpose-built databases(目的特化型データベース) • 特定のユースケースやワークロードに最適化されたデータベース •

    汎用的なデータベースで全ての要件を満たそうとするのではなく、用途に 応じて最適なデータベースを選択する • より良いパフォーマンス、スケーラビリティ、コスト効率を実現
  5. 8 Purpose Built Database • 例えば… • DynamoDB は高スループットが必要なワークロード向け •

    DocumentDB は半構造化データの管理向け • Timestream は IoT センサーデータなどの時系列データ向け など
  6. 9 DynamoDB とは • Purpose Built Database • DynamoDB とは

    • DynamoDB でパフォーマンスが出ない! • スロットリングの原因と対応策 • おわりに
  7. 11 DynamoDB とは • AWS で提供されているフルマネージドの NoSQL データベース • 1

    つ、もしくは 2 つのキーで構成される Key-Value Store • 高速なレスポンス(1 桁ミリ秒単位) • データ量が増えても自動的にスケール • Key に使っているもの以外はスキーマレスなため 柔軟なデータ構造を持つことができる • RDB のような複雑な結合操作はできない、検索が苦手
  8. 13 DynamoDB とは • DynamoDB で設定できるキーの種類 • プライマリキー • パーティションキー(旧ハッシュキー)※必須

    • ソートキー(旧レンジキー)※オプション • セカンダリインデックス ※オプション • ローカルセカンダリインデックス(LSI) • グローバルセカンダリインデックス(GSI) 本 LT では 詳細は省きます
  9. 17 DynamoDB とは - キャパシティユニット • 読み込みキャパシティユニット (Read Capacity Unit、RCU)

    • 最大サイズが 4KB のアイテムについて • 1 秒あたり 1 回の強力な整合性のある読み込み = 1RCU 消費 • 1 秒あたり 2 回の結果整合性のある読み込み = 1RCU 消費
  10. 18 DynamoDB とは - キャパシティユニット • 書き込みキャパシティユニット (Write Capacity Unit、WCU)

    • 最大サイズが 1 KB の項目について、 • 1 秒あたり 1 回の書き込み = 1WCU 消費
  11. 20 DynamoDB とは - キャパシティモード • 用途に合わせて以下 2 種類のキャパシティモードから設定 •

    プロビジョンド (キャパシティ) モード • DynamoDB のテーブルにあらかじめキャパシティユニットを割り当てておく • 常にプロビジョニングした分の料金を支払う • オンデマンド (キャパシティ) モード • システムの書き込み・読み込みリクエストに応じて自動で キャパシティユニットを増減する • 発生した読み込み、書き込みに応じて支払う • ユーザーは「最大キャパシティユニット」を指定するだけ
  12. 22 DynamoDB とは - パーティショニング • DynamoDB では大量データを高速処理するため、 パーティショニングによる分散処理を行っている •

    「パーティション」と呼ばれる分割された小さな領域(ストレージ)に、 アイテムを分散して格納
  13. 23 DynamoDB とは - パーティショニング • DynamoDB に格納されたアイテムはパーティションキーによって決められた パーティションに分散して格納される •

    パーティションキーにハッシュ関数をかけたハッシュ値に基づいて アイテムが格納されるパーティションが決まる
  14. 24 DynamoDB とは - パーティショニング • パーティション分割は AWS の内部的に行われるため、 ユーザーが指定したり管理したりできない

    • つまり、パーティションをユーザーが増やしたり減らしたり、 パーティション数を直接指定したりできない • 現在のパーティション数をユーザーが把握することはできないが、 2017 年の古い BlackBelt 資料 PDF 35 ページ以降に パーティション数の計算方法が記載されているため 机上である程度割り出すことは可能 • 2017/08/09 AWS Black Belt Online Seminar 2017 Amazon DynamoDB
  15. 25 DynamoDB でパフォーマンスが出ない! • Purpose Built Database • DynamoDB とは

    • DynamoDB でパフォーマンスが出ない! • スロットリングの原因と対応策 • おわりに
  16. 27 DynamoDB でパフォーマンスが出ない! • 構成によって原因は様々考えられるが、DynamoDB としてはまず スロットリングが発生していないか確認する • スロットリング (throttling)

    とは • システムの過負荷や特定のアクセスによるリソース独占を回避するため、 一定の制限値を超えた場合に意図的に性能を低下させたり、 要求を一時的に拒否したりする制御のこと
  17. 30 スロットリングの原因と対応策 • Purpose Built Database • DynamoDB とは •

    DynamoDB でパフォーマンスが出ない! • スロットリングの原因と対応策 • おわりに
  18. 37 スロットリングの原因と対応策 • データ処理後、1 件 1 件削除している場合 • DynamoDB でデータを

    1 件1 件削除するのは Bad Practic • 「DeleteItem」オペレーションは書き込みキャパシティを消費する • データの TTL が設定できるので自然に削除されるのを待つ (書き込みキャパシティを消費しない) • DynamoDB で有効期限 (TTL) を設定する | AWS re:Post • どうしても削除したい場合は DynamoDB の複数レコードを まとめて削除する BatchWriteItem API を利用して 一気に削除する • 1 件ずつ削除するより性能が良くなる可能性あり • BatchWriteItem - Amazon DynamoDB
  19. 40 スロットリングの原因と対応策 • スループット (単位時間当たりの処理量) が 1 分あたりでは平均未満でも 1 秒あたりでは使用可能な量を超えている場合に

    スロットリングする可能性がある • 対応方法 • DynamoDB への書き込み・読み込み API 呼び出し時に エクスポネンシャルバックオフとジッターを実装する プロビジョンドモードのスロットリングの問題のトラブルシューティング - Amazon DynamoDB
  20. 41 スロットリングの原因と対応策 • Exponential Backoff(エクスポネンシャルバックオフ) • 待機時間を指数関数的に増やしていく • wait_time =

    base_delay * (2 ** retry) で retry を増やしていくなど Exponential Backoff And Jitter - AWS Architecture Blog DynamoDB うまくいかない リトライ リトライ リトライ リトライ 待ってくれ~ DynamoDB うまくいかない リトライ 2秒置く リトライ 4秒置く ゆっくり処理できる リトライ 8秒置く リトライ 16秒置く :
  21. 42 スロットリングの原因と対応策 • Jitter(ジッター) • ランダム性を追加することでリトライタイミングを分散させる • max_wait_time = base_delay

    * (2 ** retry) で retry を増やしていく (エクスポネンシャルバックオフ) • wait_time = random.uniform(0, max_wait_time) のように 0 ~ max_wait_timeまでのランダムな値を生成 • リトライ回数が増えると max_wait_time が大きくなるため、ランダムに選ばれる 待機時間も自動的に増加 Exponential Backoff And Jitter - AWS Architecture Blog DynamoDB 4秒 + ランダム秒数置いてリトライ 同時ではなくバラバラにアクセスが来るので 順番にゆっくり処理できる 4秒 + ランダム秒数置いてリトライ 4秒 + ランダム秒数置いてリトライ
  22. 45 スロットリングの原因と対応策 • 各パーティションの最大値は以下 • 1 つのパーティションが持てる最大 RCU:3000 • 1

    つのパーティションが持てる最大 WCU:1000 • 1 つのパーティションの最大サイズ: 10 GB • 各パーティションのスループットは同じように分散され均等になっている パーティションキーを設計してワークロードを DynamoDB で分散する - Amazon DynamoDB Amazon DynamoDB のサービス、アカウント、およびテーブルのクォータ - パーティションキーおよびソートキー
  23. 47 スロットリングの原因と対応策 • ホットパーティションを防ぐため、データアクセスが均等に分散するようなキー設計が必要 • カーディナリティ(Cardinality) • 特定の集合や列に含まれる異なる値の数(種類の数) のこと •

    例:「都道府県」という列があったとすると、カーディナリティは 47 種類 • キー設計をする際はカーディナリティを検討し、アクセスが均等に分散されるようにする パーティションキーを設計してワークロードを DynamoDB で分散する - Amazon DynamoDB
  24. 48 スロットリングの原因と対応策 • パーティションは増えるが、減らない • ※ドキュメントに記載が見当たらないので見つけたら教えてください • 例えば… • 一時的に大きなサイズの大量データを書き込むと、パーティションが増える

    • その後データを削除しても、パーティションは減らず、 一つ一つのパーティションのスループットが下がる • データ移行や負荷試験などで一時的に大量のデータを書き込んで削除したり、 プロビジョンドキャパシティを大きく増やしてから減らしたりした際、 スループットが落ちたように感じたらこれが原因かも • 基本的には「キャパシティの追加」か「テーブルの作り直し」で対処 AWS Black Belt Online Seminar 2017 Amazon DynamoDB
  25. 50 おわりに • Purpose Built Database • DynamoDB とは •

    DynamoDB でパフォーマンスが出ない! • スロットリングの原因と対応策 • おわりに
  26. 52 おわりに • AWS で提供されているフルマネージドの NoSQL データベース • 1 つ、もしくは

    2 つのキーで構成される Key-Value Store • DynamoDB でパフォーマンスが出ない場合はまずスロットリングが発生して いないか確認する • キャパシティが足りているか足りていないかで対応方法を検討 • パーティションの仕組みを把握しておくと良い • 一気に処理するとスロットリングが発生しがちなのでなるべく処理を穏やかにする • エクスポネンシャルバックオフやジッターで工夫する • 書き切れなかった機能や仕様がまだまだあるのでまたの機会に!
  27. 53 おわりに • 参考 • DynamoDBを使ってみませんか? #cm_odyssey - YouTube •

    Purpose-built Database へのいざない • DynamoDB のキャパシティユニット、テーブル構造、パーティション分 割について図解でおさらい | DevelopersIO
  28. 55