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