AWSのデータの選び方

Transcript

1. 2026年08月 AWSのデータベースの選び方 15個の中から、3つの問いで決める 赤神青空
2. ▪比較表を何枚読んでも決まらない 毎回ここで止まる RDS か Aurora か DynamoDB か。 機能の違いは分かるのに、どれを選ぶかが決まらない。 比較表が教えること 各サービスが「何を持っているか」 の一覧。 今ココ はじめに 教えてくれないこと 目の前の要件で「どれを選ぶか」の 順番。 今日やること 先に問いを3つ立てて、そこに 並べ直す。 2/13
3. ▪そもそも、なぜこんなに種類があるのか 一つで全部やらない AWSは「万能のDBを1つ作る」のではなく、 アクセスパターンごとに専用DBを並べる方針を採っている。 一昔前 とりあえずRDBに全部入れ、 遅くなったら殴る。 今ココ 全体像 いまの前提 データの形に合った道具を、 用途ごとに選ぶ。 副作用 選択肢が増え、選ぶ側の負荷が 上がった。 3/13
4. ▪まずこの8分類を頭に入れる 役割で並べた全体像 【上段】リレーショナル（SQLが使える） RDS Aurora SLS v2 DSQL MySQL等をお任せ運用 ストレージ層を再設計 ACU単位の従量課金 複数リージョン同時書込 普通のRDB 高性能RDB 【下段】非リレーショナル（用途特化） 伸縮する 分散SQL DynamoDB インメモリ DocumentDB Neptune 事前設計で無限拡張 ElastiCache/MemoryDB MongoDB互換 関係そのものを辿る キー値 今ココ 全体像 一瞬で読む 文書 グラフ 4/13
5. ▪「こういうデータ」→「これ」の対応 データの形から引く表 表と関係／JOINしたい RDS・Aurora・Aurora Serverless v2 キーで引ければ十分 DynamoDB（アクセスパターンを先に設計） 一瞬で読みたい ElastiCache（キャッシュ）／MemoryDB（本体） JSON中心・ DocumentDB（MongoDB互換） スキーマ可変 つながりを辿る Neptune（グラフ） 時系列・書き込み偏重 Timestream for InfluxDB／Keyspaces 複数リージョンで同時に Aurora DSQL／DynamoDB グローバルテーブル 書く 今ココ 全体像 5/13
6. ▪教材には載っているが、もう選べないもの 現役かどうかを先に見る ✕ 新規では選べない QLDB … 2025/7/31 でサポート終了 移行先は Aurora PostgreSQL Timestream for LiveAnalytics 2025/6/20 に新規受付を停止 ◯ いま選べるもの 台帳用途 → Aurora PostgreSQL 時系列 → Timestream for InfluxDB RDS for Db2 が2023年に追加 Aurora DSQL が2025/5にGA 古い比較記事はこの2つを現役として載せています。 今ココ 全体像 6/13
7. ▪比較表を作る前に、この順で聞く 判断は3問に落ちる データ 形は？ 関係を辿るのか、 キー引きか 1問目で大分類 リレーショナルか否か。ここを 間違えると作り直しになります。 → 種類が決まる 負荷 形は？ 定常か、変動か、 アイドルか 2問目で課金方式 → 課金方式が決まる プロビジョンドか従量か。金額差は ここで一番大きく開きます。 運用 重さは？ 可用性・レプリカ・ 接続経路 3問目で構成 Multi-AZ、レプリカ、接続経路。ここは 後から足せます。 迷ったら「データの形」に戻る。ここだけが後戻りしにくい 今ココ 3つの問い 7/13
8. ▪上から順に降りていくだけ 3問を1枚にする ① データの形は？ ここを外すと作り直し 表と関係で持つなら ② 負荷の形は？ 課⾦⽅式がここで決まる 定常で⾼く稼働するなら ③ 運⽤の重さは？ ここは後からでも⾜せる DynamoDB キーで引ければ⼗分なとき ⽤途特化のDB ⽂書‧グラフ‧時系列など Aurora Serverless v 変動が激しい‧アイドルが⻑い Aurora Limitless 書き込みが1台に収まらない Aurora DSQL 複数リージョンで同時に書く DocumentDB / Neptune / Keyspaces ほか RDS 普通の可⽤性で⾜りる Aurora 多レプリカ‧⾼可⽤が要る ①だけが後戻りしにくい ②は課⾦設定、③は構成。どちらも後から変えられる。分かれた先で、以降の問いは不要になる。 左の問いに答えると、右の答えが1つ決まる 今ココ 3つの問い 8/13
9. ▪年1500件・平日昼に集中・審査ワークフロー ケース1 社内の申請システム 規模は小さいが形はリレーショナル。判断はスケールではなく書きやすさで 決まる。 答 理 注 t4g級で十分。Auroraは過剰 審査・評点・状態遷移はSQL向き Lambda併用ならProxyかData API RDSの小型 今ココ 判断の練習 形が関係型 接続だけ注意 9/13
10. ▪追記しかしない・引くのはIDと時刻レンジ ケース2 AI機能の実行ログ 引き方がIDと時刻レンジに固定されていて、書いた後に更新もしない。 RDBである必要がない。 答 理 注 追記専用でキー引きに徹する 負荷も運用も聞くまでもない 1項目400KBの上限。長文はS3へ DynamoDB 今ココ 判断の練習 1問目で決まる 本文は逃がす 10/13
11. ▪3リージョンで同時に書く・強整合が要る ケース3 グローバルなゲーム 「どこでも書ける」が要件に入った瞬間、候補が2つに絞られる。 答 理 注 SQLならDSQL、キー引きなら DynamoDB Aurora Global Databaseは書き手が1つ MRSCは3リージョン・同一セット 候補は2つ 今ココ 判断の練習 Globalでは不足 強整合は既定外 11/13
12. ▪迷ったときに、どちらへ倒すか 移行の非対称性 DynamoDB → RDB はデータモデルの作り直しになる。 RDS → Aurora はほぼ載せ替えで済む。 高くつく向き キー設計前提のデータを、後から 関係型へ組み直す。 今ココ 判断の練習 安く済む向き 同じSQLのまま、器の性能だけを 上げていく。 だから 迷ったらRDBから始めるほうが、 選択肢が残る。 12/13
13. ▪覚えるのは表ではなく、順番のほう まとめ 01 比較表より先に、3つの問いを立てる データの形 → 負荷の形 → 運用の重さ。順番も含めてこの通り。 02 現役かどうかを最初に確認する 教材に載っていても、いま新規では選べないものがある。 03 迷ったら選択肢が残る側から始める 移行コストは向きによって違う。後戻りしにくいのは1問目だけ。 今ココ まとめ 13/13