GSIが複数キー対応したことで、俺達はいったい何が嬉しいのか？

2026/01/31（土）に開催された「JAWS-UG名古屋 あけましておめでとう！2025年お気に入りサービスアップデート祭り！」における私のLT「GSIが複数キー対応したことで、俺達はいったい何が嬉しいのか？」の発表資料になります。　#jawsug_nagoya

https://jawsug-nagoya.connpass.com/event/378364/

Transcript

1. GSIが複数キー対応したことで、俺達は いったい何が嬉しいのか？ 2026.01.31 JAWS-UG 名古屋 あけましておめでとう！2025年お気に入 りサービスアップデート祭り！ KDDIアジャイル開発センター 名古屋オフィス 鈴木 正樹
2. 1 KDDI Agile Development Center Corporation 自己紹介 ◼ 氏名：鈴木 正樹 ◼ 所属：KDDIアジャイル開発センター（KAG） 名古屋オフィス ◼ 役割：クラウドアーキテクト ＆ バックエンドエンジニア サーバーレス＆IaCが大好き。好きなサービスはAWS LambdaとAWS CDK 主にJAWS-UG 名古屋＆JAWS-UG CDK支部で活動 ◼ Certification： ◼ AWS Solution Architect Associate（2023） ◼ AWS Community Builder(serverless)（2023～） ◼ Scrum Inc. 認定スクラムマスター（2025～） ◼ : @makky12（SUZUKI Masaki@クラウドエンジニア） ◼ Blog：https://makky12.hatenablog.com/
3. 2 KDDI Agile Development Center Corporation 近状報告 波乱の年末年始 • 昨年末（12/30）にギックリ腰になり、楽しみにしていた「Burikaigi 2026」＆「JAWS-UG 福井 #1 リブート宣言LT会」に行けず… • 1/24（土）の「JAWS-UG 北陸新幹線 #5 in 群馬」が今年初のコミュニティ＆地方貢献活動 ◦ 発表資料はこちら → Lambda Durable FunctionsでStep Functionsの代わりはできるのかを試してみた
4. 3 KDDI Agile Development Center Corporation 本日のアジェンダ • 私のお気に入りサービスアップデート＆その詳細 • このアップデートの嬉しい点 • まとめ＆宣伝
5. 4 KDDI Agile Development Center Corporation 注意事項 い つ も の • DynamoDB関連用語の詳細説明は省略します ◦ 正式な情報は、AWS公式サイトをご確認ください • 発表資料・発言内容は、すべて個人の見解・知見になります • この資料は、下記URLで公開済みです ◦ この資料です • 本資料は、みのるん氏作の「#パワポ作るマン」では作ってません！ ◦ ちゃんと自分で書いてます
6. 5 KDDI Agile Development Center Corporation 私のお気に入りサービスアップデート ＆その詳細
7. 6 KDDI Agile Development Center Corporation 私のお気に入りアップデート：DynamoDB GSIの複数キー対応 DynamoDB GSIのプライマリキーにパーティションキーおよびソートキーを複数設定可能に • 2025/11/19に、DynamoDBのグローバルセカンダリインデックス（以下「GSI」）のプラ イマリキーに、最大8つまでキーを設定可能になるアップデートが発表（※1） • 詳細はこちら：https://aws.amazon.com/jp/blogs/database/multi-key-support-for-global-secondary-index- in-amazon-dynamodb/ ※1：なお、このアップデートはre:Invent2025 落選組です
8. 7 KDDI Agile Development Center Corporation 「DynamoDB GSIの複数キー対応」の詳細 プライマリキーにPKとSKをそれぞれ最大4つまで設定可能になった • プライマリキー（※1）を構成するパーティションキー（以下「PK」）およびソートキー （以下「SK」）について、今までは1つしか設定できなかった（以下のいずれか） ◦ パーティションキー1つ または ◦ パーティションキー1つ + ソートキー1つ • このアップデートで、プライマリキーのPK/SKをそれぞれ最大4つまで設定可能に（※1） ◦ パーティションキー1～4つ または ◦ パーティションキー1～4つ + ソートキー1～4つ ※1：テーブルの各データを一意に識別するキー（ただしGSI/LSIのプライマリキーには重複したデータも登録可能） 参考：Amazon DynamoDB で GSI や LSI のキーは重複や値なしが許容されるのか確認してみた（クラメソさんブロ グ）
9. 8 KDDI Agile Development Center Corporation このアップデートの嬉しい点
10. 9 KDDI Agile Development Center Corporation このアップデートの嬉しい点 主に2点 • 検索時にプライマリキーだけで必要なデータのみを抽出しやすくなった ◦ 合成キーの作成が不要に • データ取得時のコスト軽減 ◦ 「プライマリキーだけで必要なデータのみを抽出しやすくなった」ことで、検索時のコストを減らせる • 詳細は、次ページ以降に記載
11. 10 KDDI Agile Development Center Corporation 恩恵その1：検索時にプライマリキーだけで必要なデータのみを抽出し やすくなった • 今までは、最大2項目だけでデータを一意にする必要があった ◦ プライマリキーがPK1つ、またはPK1つ+SK1つのいずれかの構成のため • AWS公式の「単一テーブル設計（※1）」に従う場合、PKを「エンティティ名」にする必要 があるため、実質SKのみでデータを一意に特定する必要があった ◦ 「合成キー」という、複数キーの値を「#」でつなげた値を設定していたが、いろいろ不便な点も… • 今回のアップデートでプライマリキーに設定可能なPK/SKが増えたことで、プライマリキー だけで「データの一意化」「必要データのみの抽出」がしやすくなり、合成キーが不要に ※1：現在は「複数テーブル設計」という考え方もあります。 参考： Amazon DynamoDB におけるシングルテーブル vs マルチテーブル設計
12. 11 KDDI Agile Development Center Corporation 参考情報：合成キーとは ※合成キーの説明＆今回のアップデート前後で変わった点 • 今まではSKなどに複数項目を「#」でつなげた値（=構成キー）を入れて対応していた • 今回のアップデートでそれが不要に ※ 例）「the-tower-of-druaga（ドルアーガの塔）」テーブル（黄色のキーがプライマリキー） entity skey kind level name description enemy slime#1 slime 1 グリーンスライム スライムで最弱。動きも遅い enemy knight#1 knight 1 ブルーナイト ナイトで最弱。初期状態でも勝てる enemy knight#2 knight 2 ブラックナイト そこまで強くないが、最序盤は負ける事も entity kind level name description enemy slime 1 グリーンスライム スライムで最弱。動きも遅い enemy knight 1 ブルーナイト ナイトで最弱。初期状態でも勝てる enemy knight 2 ブラックナイト そこまで強くないが、最序盤は負ける事も
13. 12 KDDI Agile Development Center Corporation 恩恵その2：データ取得時のコスト削減 • データ取得時（Get,Queryなど）に課金対象となるのは「プライマリキーのフィルタ条件 （=KeyConditionExpression）に一致したデータ」の量 ◦ プライマリキー以外のフィルタ条件（=FilterExpression）との一致・不一致は課金には影響しません（※1） • 言い換えれば「プライマリキーの条件だけで不要なデータを除外すればするほど、コストが 安くなる」という事 • 今回のアップデートでプライマリキーの項目が増えたことで、プライマリキーの条件だけで より多くの不要データを除外可能になり、結果として取得時のコストを軽減可能に ◦ PK/SKにより多くのフィルタ条件を指定できるようになったため ※1：詳細は次ページ以降の「参考情報：なぜスキャン（Scan）は推奨されないのか」で説明します
14. 13 KDDI Agile Development Center Corporation 参考情報：なぜスキャン（Scan）は推奨されないのか ※AWS公式で「データ取得にはなるべくGetやQueryを使用してください」とアナウンスされる理由 • 先述の通り、検索時は「プライマリキーのフィルタ条件に一致したデータ」の量に応じて課 金される（=このフィルタ条件で不要データを除外できれば出来るほどコストが安い） • しかしスキャンではこの「プライマリキーのフィルタ条件」を指定できず、始めに必ず全 データを取得することになる（=課金対象のデータ量が多くなる） ※1MB制限は除く • 「プライマリキー以外のフィルタ条件」は指定可能だが、この結果は課金には一切影響しな い（あくまでも課金対象は「プライマリキーのフィルタ条件に一致したデータ」） • 結果としてより多くの「不要なデータ（=最終的に取得されないデータ）に対する課金」が発 生してしまうため、スキャンはあまり推奨されない
15. 14 KDDI Agile Development Center Corporation 参考情報：クエリとスキャンの実行結果＆課金の違い • スキャンでは「プライマリキーのフィルタ条件」が指定不可なので、始めに全データが取得される（=全データに対 して課金がされる）※下表の処理No.2（赤文字）のデータに対して課金が発生する • 最終的に「プライマリキー以外のフィルタ条件」に一致するデータのみが取得されるが、これに一致せず取得されな かったデータに対しても課金は発生する • なお「課金対象のデータ件数」および「最終的に取得したデータ件数」はそれぞれレスポンスオブジェクトの 「ScannedCount」および「Count」で確認可能 処理 順序 処理内容 取得 （クエリ） 取得 （スキャン） 備考 1 全データ取得 全データ 全データ 2 1からプライマリキーのフィルタ に一致するデータのみを取得 フィルタ後のデータ 全データ ※このデータに対 し課金が発生 3 2からプライマリキー以外のフィ ルタに一致するデータのみを取得 フィルタ後のデータ フィルタ後のデータ 4 最終的に取得されるデータ 3のデータ 3のデータ
16. 15 KDDI Agile Development Center Corporation まとめ＆宣伝
17. 16 KDDI Agile Development Center Corporation まとめ このセッションのまとめ • 今回紹介したアップデートで、DynamoDBのGSIのプライマリキーに、パーティションキー およびソートキーをそれぞれ最大4つまで（=合計最大8個まで）設定可能になった • それにより、検索時にプライマリキーだけで必要なデータのみを抽出しやすくなり「合成 キーが不要」「データ取得時のコスト軽減」などの恩恵を受けられるようになった • 最後に注意点として、このアップデートはあくまでGSIが対象であり、テーブルそのもののプ ライマリキー（=プライマリインデックス）は対象外なので注意！
18. 札幌オフィス SAPPORO OFFICE 秋田オフィス AKITA OFFICE 高崎オフィス TAKASAKI OFFICE 金沢オフィス KANAZAWA OFFICE 舞鶴オフィス MAIZURU OFFICE 広島オフィス HIROSHIMA OFFICE 福岡オフィス FUKUOKA OFFICE 那覇オフィス NAHA OFFICE 仙台オフィス SENDAI OFFICE 東京本社 TOKYO MAIN OFFICE 三島オフィス MISHIMA OFFICE 名古屋オフィス NAGOYA OFFICE 大阪オフィス OSAKA OFFICE
19. 採用募集中！ エンジニア・デザイナー
20. Be a Change Leader. アジャイルに力を与え 共に成長し続ける社会を創る