DynamoDB コスト最適化っぽいことの基本 with Terraform

AWS10分LT会 - vol.4でLTをした時の資料です。

参考リンクは以下です。
DynamoDBテーブルのコスト最適化(https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/bp-cost-optimization.html)
DynamoDB Auto Scaling によるスループットキャパシティの自動管理(https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/AutoScaling.html)
Amazon DynamoDBにおけるコスト最適化に向けたリザーブドキャパシティの算出方法(https://aws.amazon.com/jp/blogs/news/calculate-amazon-dynamodb-reserved-capacity-recommendations-to-optimize-costs/)
DynamoDBのインフラコストの構造と削減策 - ゆううきブログ(https://blog.yuuk.io/entry/2018/dynamodb-cost-points)
DynamoDBはバッチ処理よりストリーム処理との相性が良いという話 - Zenn(
https://zenn.dev/hsaki/articles/aws-dynamodb-stream-suited)

Transcript

1. DynamoDB コスト最適化っ ぽいことの基本 with Terraform 2024/07/17 AWS10分LT会 - vol.4 kuro 1
2. 1. Cost Explorerの活用 # Cost Explorerのデータを基に、以下のようなタグ付けを行う resource "aws_dynamodb_table" "example" { # ... その他の設定 ... tags = { CostCenter = "ProjectA" Environment = "Production" } } 2
3. 1. Cost Explorerの活用 Cost Explorerを使用してテーブル別のコストを 分析。 デフォルトでは、DynamoDBでまとめられてし まう。 テーブルごとのコスト傾向を把握し、最適化の 優先順位を決定。 プロジェクトや環境ごとのコスト配分が可能に なり、予算管理を改善。 3
4. 2. キャパシティモードの選択 resource "aws_dynamodb_table" "example" { name = "cost-optimized-table" billing_mode = "PAY_PER_REQUEST" # オンデマンドモード hash_key = "id" attribute { name = "id" type = "S" } } 4
5. 2.キャパシティモードの選択 billing_mode : "PAY_PER_REQUEST"（オンデマ ンド）または "PROVISIONED"（プロビジョン ド）を選択。 オンデマンドモード：使用した分だけ支払 い、キャパシティ管理が不要。 プロビジョンドモード：事前にキャパシティ を設定し、超過時に追加料金。 基本的には24時間ごとに1回変更できる。 5
6. 2.キャパシティモードの選択 オンデマンドモード リクエストのタイミングが予測できない場 合。 リクエストの量が変動する場合。 リクエストが一定期間0になる場合。 プロビジョンドモード 特定の時間やパターンでリクエストが発生す る場合。 トラフィックの急増が一時的かつ限定的に発 生する場合。 6
7. 3. テーブルクラスの最適化 resource "aws_dynamodb_table" "example_ia" { name = "infrequent-access-table" billing_mode = "PAY_PER_REQUEST" table_class = "STANDARD_INFREQUENT_ACCESS" hash_key = "id" attribute { name = "id" type = "S" } } 7
8. 3. テーブルクラスの最適化 table_class : "STANDARD"（デフォルト）また は "STANDARD_INFREQUENT_ACCESS"（IA） を選択。 IAとは、アクセス頻度の低いデータに適した低 コストのストレージオプション(最大60%削減可 能) ただし、読み込み書き込みはStandardよりも最 大25%高くなる。 30日間に2回まで変更できる。 8
9. 4. Auto Scaling設定 resource "aws_appautoscaling_target" "dynamodb_table_read_target" { max_capacity = 100 min_capacity = 5 resource_id = "table/${aws_dynamodb_table.example.name}" scalable_dimension = "dynamodb:table:ReadCapacityUnits" service_namespace = "dynamodb" } resource "aws_appautoscaling_policy" "dynamodb_table_read_policy" { name = "DynamoDBReadCapacityUtilization:${aws_appautoscaling_target.dynamodb_table_read_target.resource_id}" policy_type = "TargetTrackingScaling" resource_id = aws_appautoscaling_target.dynamodb_table_read_target.resource_id scalable_dimension = aws_appautoscaling_target.dynamodb_table_read_target.scalable_dimension service_namespace = aws_appautoscaling_target.dynamodb_table_read_target.service_namespace target_tracking_scaling_policy_configuration { predefined_metric_specification { predefined_metric_type = "DynamoDBReadCapacityUtilization" } target_value = 70 } } 9
10. 4. Auto Scaling設定 max_capacity と min_capacity : スケーリングに よるキャパシティーユニットの最大値と最小 値。 target_value : 目標使用率（ここでは読み取り キャパシティが70%になるようにスケーリング を行う） 10
11. 4. Auto Scaling設定 読み取り、書き込みともに設定できる。 トラフィックの量に応じて動的にキャパシティ ーユニットを調整できる。 トラフィックが少ないときには、読み取りキ ャパシティーユニットをmin値に抑えること で、コスト削減。 トラフィックが増加した場合には、max値ま で自動的にスケーリングすることで、パフォ ーマンスを維持しつつ、必要なリソースを確 保。 11
12. 5. TTL（Time to Live）の活用 resource "aws_dynamodb_table" "example_with_ttl" { name = "table-with-ttl" billing_mode = "PAY_PER_REQUEST" hash_key = "id" attribute { name = "id" type = "S" } ttl { attribute_name = "ExpirationTime" enabled = true } } 12
13. 5. TTL（Time to Live）の活用 ttl : 有効期限切れのアイテムを自動的に削除す る機能。 attribute_name : TTLのための属性名を指定。通 常アイテムの有効期限を示すタイムスタンプが 格納される。 古いまたは不要なデータを自動的に削除し、ス トレージコストを削減。 テーブルから不要なデータがなくなるため、ク エリのパフォーマンスも上がる。 13
14. 6. インデックス最適化 resource "aws_dynamodb_table" "example_with_gsi" { name = "table-with-optimized-gsi" billing_mode = "PAY_PER_REQUEST" hash_key = "id" attribute { name = "id" type = "S" } attribute { name = "email" type = "S" } global_secondary_index { name = "EmailIndex" hash_key = "email" projection_type = "INCLUDE" non_key_attributes = ["username", "last_login"] } } 14
15. 6. インデックス最適化 global_secondary_index : GSI（グローバルセカ ンダリインデックス）を設定。 projection_type : "INCLUDE" はKEY+指定した 項目を取得できる。non_key_attributesで指定 した項目をインデックスに含める。 non_key_attributes : インデックスに含める追加 の属性を指定。 15
16. 6. インデックス最適化 インデックスの効率的な使用により、クエリの パフォーマンスを向上。 必要な非キー属性のみをインデックスに含める ことで、インデックスのサイズを最小限に抑え る。 インデックスのストレージコストを削減でき る。 16
17. 7. DAXの活用 resource "aws_dax_cluster" "example" { cluster_name = "example-dax-cluster" node_type = "dax.t3.small" replication_factor = 3 iam_role_arn = aws_iam_role.dax_role.arn } 17
18. 7. DAXの活用 DynamoDB Accelerator (DAX) を使用してキャ ッシュレイヤーを追加。 DynamoDBの読み取りリクエスト数が減少し、 読み取りキャパシティーユニット（RCU）のコ ストを削減。 スケーリングの必要性を減らし、関連コストを 抑制。 18
19. 8. DynamoDB Streamsの最適化 resource "aws_dynamodb_table" "example_with_stream" { name = "table-with-optimized-stream" billing_mode = "PAY_PER_REQUEST" hash_key = "id" attribute { name = "id" type = "S" } stream_enabled = true stream_view_type = "NEW_IMAGE" } 19
20. ８. DynamoDB Streamsの最適化 stream_enabled : DynamoDB Streamsを有効 化。 stream_view_type : ストリームに含めるテーブル のビューを指定。 （NEW_IMAGE, OLD_IMAGE, NEW_AND_OLD_IMAGES, KEYS_ONLY） 20
21. 8. DynamoDB Streamsの最適化 DynamoDB Streamsは、テーブルの変更をリア ルタイムでキャプチャし、他のシステムやサー ビスに対してイベントドリブンな処理を行う。 必要最小限の情報のみをストリームに含めるこ とでコストを削減。(NEW_IMAGE) DynamoDBをバッチ処理的に使うのもありだ が、リアルタイム処理やストリーミング処理に も使える。 21
22. ９. データ圧縮 大きな属性値を圧縮してから一つのアイテムに まとめてDynamoDBに保存。 圧縮や解凍する処理をアプリケーションに実 装。 ストレージコストの削減。 データ量減少によるネットワーク転送コスト削 減。 1回の読み書き操作で処理できるデータ量が増 え、必要なRCU/WCUを削減。 22
23. 10. リザーブドキャパシティの活用 特定のキャパシティーユニットを事前に予約す る。 プロビジョンドキャパシティモードと組み合わ せて使用。(現在はオンデマンドモードには対応 していない) 読み込みまたは書き込み、期間は1年または3 年。 予測可能な負荷に対して最大50-75%のコスト削 減が可能。 23
24. 11. 強力な整合性のある読み込みの削減 結果整合性のある読み込み: 0.5 RCU/4KB 強力な整合性のある読み込み: 1 RCU/4KB ワークロードを評価し、強力な整合性が本当に 必要な場合のみ使用。 24
25. 12. 読み込みトランザクション数の最小化 通常の読み込み: 0.5 RCU/4KB トランザクション読み込み: 2 RCU/4KB CloudWatchメトリクスを確認し、トランザク ションAPIの使用状況を分析。 必要な場合のみトランザクションを使用するよ う設計を見直す。 25
26. 13. 書き込みトランザクション数の最小化 通常の書き込み: 1 WCU/1KB トランザクション書き込み: 2 WCU/1KB 必要な場合のみトランザクションを使用するよ う設計を見直す。 26
27. 14. Scanオペレーションの削減 Scanオペレーションは、テーブル全体を読み取 るため、コストが高い。 Scanの頻度はSuccessfulRequestLatencyメトリ クスを監視。 アクセスパターンとデータモデルを再評価。 27
28. 15. 属性名の短縮 DynamoDB のItemの合計サイズは、属性名と属 性値の長さの合計。 属性名が長いと、ストレージコストだけでな く、RCU/WCU の消費量も増加。 28
29. 参考 DynamoDBテーブルのコスト最適化 DynamoDB Auto Scaling によるスループットキ ャパシティの自動管理 Amazon DynamoDBにおけるコスト最適化に向 けたリザーブドキャパシティの算出方法 DynamoDBのインフラコストの構造と削減策 - ゆううきブログ DynamoDBはバッチ処理よりストリーム処理と の相性が良いという話 - Zenn 29