SW BBANG J

DynamoDBで『このアイテムを注文日でも検索したい』と思った瞬間、テーブル設計を見直す羽目になった経験は少なくないはずだ。プライマリキー以外の属性でクエリを実行したいとき、LSI（ローカルセカンダリインデックス）とGSI（グローバルセカンダリインデックス）のどちらを選ぶかは、後から変更できない制約も絡むため、設計段階での判断が特に重要になる。 TL;DR: LSI vs GSI 早見表 項目 LSI（ローカルセカンダリインデックス） GSI（グローバルセカンダリインデックス） パーティションキー ベーステーブルと同一 任意の属性を指定可能 ソートキー 異なる属性を指定 任意の属性を指定可能（省略可） 作成タイミング テーブル作成時のみ テーブル作成後でも追加可能 整合性モデル 強整合性読み取り可能 結果整合性のみ ストレージ制限 パーティションあたり10GB上限 制限なし（テーブル全体と同様） スループット ベーステーブルと共有 独立したキャパシティ設定が可能 テーブルあたりの上限 最大5個 最大20個（デフォルト） DynamoDB セカンダリインデックスの仕組み DynamoDBのセカンダリインデックスは、ベーステーブルのデータを別のキースキーマで参照できるようにした、内部的には独立したデータ構造だ。インデックスへの書き込みはDynamoDBが自動的に管理する非同期プロセスで、ベーステーブルへの書き込みが成功した後にインデックスへ反映される。LSIの場合はこの反映が同一パーティション内で行われるため強整合性読み取りをサポートできるが、GSIは非同期レプリケーションのため結果整合性のみとなる。 インデックスに射影（Projection）する属性の選択も重要だ。 KEYS_ONLY 、 INCLUDE 、 ALL の3種類があり、射影する属性が多いほどストレージコストと書き込みコストが増加する。クエリで必要な属性だけを射影するのが基本的な最適化方針になる。 sequenceDiagram participant App as アプリケーション...

新しいサービスを立ち上げるとき、DynamoDBのキャパシティモード選択で迷うのはよくある話だ。トラフィックパターンが読めない段階でプロビジョニングモードを選ぶと、スロットリングで障害を起こすか、過剰なコストを払うかのどちらかになる。この記事では、 DynamoDBキャパシティモード の仕組みと、実際の運用判断基準を具体的に解説する。 TL;DR：DynamoDBキャパシティモード選択早見表 判断軸 オンデマンド プロビジョニング トラフィック予測可能性 不明・不規則 安定・予測可能 スロットリングリスク 低い（自動スケール） 設定次第で高い コスト特性 リクエスト単価が高い 安定負荷なら割安 Auto Scaling併用 不要（組み込み） 推奨（必須に近い） 切り替え頻度制限 24時間に1回まで 同左 向いているフェーズ 開発・ローンチ初期・突発トラフィック 成熟サービス・高スループット安定期 DynamoDBキャパシティモードの仕組みを理解する DynamoDBのスループットは、読み込みキャパシティユニット（RCU）と書き込みキャパシティユニット（WCU）という単位で管理される。1 RCUは最大4KBのアイテムに対する強整合性読み込み1回、1 WCUは最大1KBのアイテムへの書き込み1回に対応する。この前提を押さえた上で、2つのモードの動作を見ていく。 graph LR Client["クライアント"] --> Request["リクエスト"] Request --> ModeCheck{"キャパシティモード？"} ModeCheck -->|"オンデマンド"| OnDemand["自動キャパシティ割り当て （PAY_PER_REQUEST）"] ModeCheck -->|"プロビジョニング"| Provisioned["事前設定RCU/WCU"] OnDem...