[登壇レポート]「DynamoDB でスロットリングが発生したとき」という内容で登壇してきました #cm_sapporo_study

コーヒーが好きな emi です。

2024/11/21 (木) にクラスメソッド札幌オフィスで行われた 「クラメソさっぽろIT勉強会 (仮) #6:パフォーマンスチューニング」にて 10 分枠で登壇の機会をいただきましたので、北の大地に飛んで登壇して参りました。
資料の公開と、当日回答できなかったご質問に回答します。

https://classmethod.connpass.com/event/333630/

登壇資料

▼当日登壇で使用した 55 ページのスライドはこちらです。

▼時間の都合で削った内容まで含む 70 ページのスライドはこちらです。

当日いただいた質問

当日 Slido でいただいたご質問に回答します。

Q. オンデマンドではなく、プロビジョニングを利用する時はどんなケース？

オンデマンドキャパシティモードでは突発的なスパイクの際スケーリングが間に合わないことがあります。

「全く初めて試すシステムのテスト版で、アクセス数が読めない」などのケースではオンデマンドキャパシティモードでまずはアクセスを見ます。
常に一定の頻度でアクセスが行われることが分かっている場合はプロビジョニングモードにします。
特定の時間にアクセスのスパイクが見込まれる場合はプロビジョンドモードであらかじめキャパシティを増やして確保しておくとスロットリングを防げます。

オンデマンドモードからプロビジョンドモードへは後からすぐに切り替えできますが、切り替えた後にまたオンデマンドモードに戻したい場合は 24 時間を空ける必要があります。
逆も同様で、プロビジョンドモードからオンデマンドモードへは後からすぐに切り替えできますが、切り替えた後にまたプロビジョンドモードに戻したい場合は 24 時間を空ける必要があります。
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/bp-switching-capacity-modes.html

オンデマンドモードで予想されるスパイクに対応したい場合は「事前ウォーミング」という操作を行うとスロットリングを防げます。こちらも要はプロビジョンドモードに一時的に変更して事前にキャパシティをプロビジョニングしておくというものです。
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/pre-warming-on-demand-capacity-mode.html

追記：
2024/11/13 に、テーブルとインデックスのウォームスループットが導入されています。
https://aws.amazon.com/about-aws/whats-new/2024/11/amazon-dynamodb-warm-throughput-ondemand-provisioned-tables/?nc1=h_ls

DynamoDB のテーブルが即座に対応できる読み書き操作の数を表していて、急激なスパイクなどに備えて設定できるものになっているようです。こちらもあわせてご確認ください。
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/warm-throughput.html

Q. 特定の時間帯、処理だけスロットリングが起こる場合はどのように対応すればいいですか？

その時間に何の処理が行われたか詳しく追います。
プロモーションがあったのか、ジョブが走ったのか…状況によって対応を考えます。

プロモーションなどで特定の時間に想定以上の処理が見込まれる場合は、その前に一時的にキャパシティを増やしておくなど工夫します。

監視の設定をしている場合は同時に何か別のメトリクスでアラートが出ていないかどうかも確認すると良いです。他の部分との関連性も重要です。

結果的に DynamoDB がスロットリングしているけど、その前段階の処理コードで時間がかかっているとか、リクエストの投げ方を変えた方が良いねとか、キューを挟んだ方がいいねとか、そういう対応になるかもしれません。

「そもそもその処理で何が達成できていればいいのか」、「その時間にその処理をしないと何がダメなのか」などを整理してみると、突破口が見つかることもあります。

Q. 削除の代わりに TTL を使う方法のイメージが湧きません。次回読み込み時には消えておいて欲しいレコードは TTL を使った方法で制御できるのでしょうか。

私が出会ったケースでは、未処理のレコードを DynamoDB に格納しておいて、後で一気に DynamoDB のレコードを処理しようとしていました。
未処理データを一時的に DynamoDB に入れておくとか、S3 内のデータについて格納場所とフラグだけは DynamoDB に入れておくとか、そういう使い方はたまに見かける印象です。

おわりに

今回のイベントのテーマはパフォーマンスチューニングで、私は DynamoDB の話をしましたが、他にもフロントエンドのチューニングや SQL Server のチューニング、システムのパフォーマンス監視の話など多岐に渡り面白かったです。
システムのチューニングはどんなシステムでも発生しますし、改善方法やよくある定石について学ぶのがすごく楽しいので、またパフォーマンスの勉強会があれば参加したいです。

正直言うと、普段ミドルウェアやフロントエンド開発に関わっておらず難しくて理解できなかった部分も多かったので、いろいろ勉強しないといけないなと思いました。