データベースを統合すれば、運用は楽になるのか

データベースを統合すれば、運用は楽になるのか 専用DBの運用課題から考えるHTAPとデータ基盤の技術選定 【After Party】db tech showcase 2026 登壇者と語る、分散DBのリアル 2026年11月5日 1

自己紹介 山田顕人（Kento.Yamada） @ymd65536 By the wayの人、404ニキなど呼び方はさまざま 仕事：DevSecOps、Enterprise Architect コミュニティ運営：.NETラボ、AI運用、AI駆動開発 受賞歴 ● 初代PagerDutyアンバサダー 2

3

今日のテーマ：データベースを統合すべきか 1. 専用DBを使い分ける理由と運用の限界 2. 単一エンジン化の価値とトレードオフ 3. データ基盤選定に必要な評価軸 db tech showcaseで様々なDBが紹介されたこそ考えたい観点 4

つながることと、一つになることは違う。 ー Kento Yamada 5

データ基盤は統合すべきか - 分離 vs 統合 専用DB併用の運用課題、HTAP・レイク統合のトレードオフ、技術選定の評価軸 6

用途に応じてDBを分ける理由 用途に応じて専用DBを分けることそれ自体は悪いことではない。 7

複数DB運用の隠れた負債 専用DBの組み合わせ ● データ移動の依存関係が増加 ● 監視障害対応 ● 継続的な運用 8

障害時に問われること 障害時に難しいのはDB単体よりも境界をまたぐ整合性の回復 9

専用DBの併用が合理的な場合 分離した構成が必要な条件もある 分離は単なる運用負債ではなく、障害とリスクを隔離するための設計 10

単一エンジン化の価値 ※これは概念図です。 統合型アーキテクチャ データ移動や同期の経路を減らす可能性がある。 ● 重要な評価観点 ○ ストレージと計算資源の分離 11

統合による新しいトレードオフ 統合にも測定すべき負荷がある ● 統合によってデータ連携の負担を減らせる ○ 共有資源への依存が新しい課題 分散しているからこそ良い側面もある。 12

『統合できる』を分解する 「DBを統合する」という言葉を分解 ● 操作の統合 ○ 共通のAPIで動作するか ● データの統合 ○ Single Source Of Truth ● 整合性の統合 ○ データの一貫性 ● 運用の統合 ○ 監視、障害対応、バックアップ 13

評価軸はSLOから逆算する ※SLO以外のRPO・RTO・セキュリティ要件も含む 14

PoCで検証すべき実運用 この4段階を一連の検証として扱います。障害注入は負荷を与えた状態で実施する。負荷 試験と切り離さないことがポイント 運用を前提とした技術選定 ● データベースが壊れないことを期待しない ● 壊れたときにシステムがどう振る舞うのかを理解する 15

3つの選択肢を比較する 「統合できる」ことと「統合すべき」ことは違う。 16

まとめ 17

統合できることと、統合すべきことは違う ー Kento Yamada 18