データベース研修 DB基礎【MIXI 25新卒技術研修】

©MIXI 25新卒技術研修データベース研修 DB基礎

2 ©MIXI 本講義の⽬的 ▪ ⽬的正式配属後の開発タスクを担当するにあたり、データベース（DB）に関する必要最低限の知識習得を⽬的とします。複数ある DB
種類のそれぞれの特性を知り、最適な DB を選択‧利⽤できる初期段階まで到達することを⽬的とします。 ▪ 背景あらゆるプロダクト開発で DB は必須といってよいスキルです。クラウドと相性が良い DB がサービス化しており、モダンなシステム開発には基本的かつ広い知識が必要となっています。

3 ©MIXI 本⽇の内容第1章: データベースの基本概念第2章: 様々なデータベース第3章: クラウド上のデータベースサービス第4章:
データベースの選定とアーキテクチャ第5章: セキュリティとデータガバナンス第6章: データベースとAI

4 ©MIXI 時間割 10:30〜10:45 ⾃⼰紹介（お互い） 10:45〜11:50 1〜3章 11:50〜12:00 休憩 12:00〜13:00
4〜6章 13:00〜14:00 ランチ休憩 14:00〜18:30 データ分析基盤編

5 ©MIXI 講義中のふるまい • スマホは⾳が出ないモードでお願いします。 • 急なトイレ等は遠慮なくどうぞ。断る必要はありません。 • 質問したい場合は挙⼿してください。 •
相槌とか感嘆とかのリアクション歓迎です。 • 飲⾷ OK です。ただ、周囲への配慮はお願いします。

自己紹介タイム

7 ©MIXI ⾃⼰紹介吉井亮 (YOSHII RYO) • 経歴 HWエンジニア
→ 中⼩SIer → ERPコンサル → AWS パートナー → 株式会社MIXI（2023年7⽉⼊社） • Community Ops-JAWS (AWS Community Builder) • 好きな⾔葉 No human labor is no human error.

8 ©MIXI ⾃⼰紹介北島祥伍 (KITAJIMA SHOGO) • 経歴 2019年4⽉新卒⼊社、⼊社以来モンストを中⼼としたデータ基盤の⾯倒を⾒ています。
BigQueryの重いクエリのチューニングが好き • 最近の悩み毎⽉課⾦したいAIのツールが変わること • 近況去年、気象予報⼠の資格を取得してみたものの、特に使い道がない

9 ©MIXI ⾃⼰紹介吉村健⽮ (YOSHIMURA TAKUYA) • 経歴 2022年中途⼊社、モンストを中⼼としたデータ基盤を⾒ています。
• 趣味スポーツ観戦、旅⾏、サウナ

10 ©MIXI ⾃⼰紹介渡辺⼤貴 (WATANABE TAIKI) • 経歴 2020年新卒⼊社。以来モンストのデータ解析基盤の運⽤、新規事業系のデータ基盤構築など担当。
• 出⾝地仙台出⾝⼤学は岩⼿の(元)村にある⼤学へ通っていました。 • 最近⾏った旅⾏ 2⽇前まで RubyKaigi 2025 参加のために愛媛県に⾏っていました。

11 ©MIXI 3つ選んで⾃⼰紹介をお願いしますお名前（必須）趣味出⾝地最近⾏った旅⾏休みにすること
好きな⾷べ物ペットの話私の宝物将来の夢好きなテック気になる出来事 MIXI でやりたいこと

©MIXI 第1章: データベースの基本概念

13 ©MIXI データベースとはデータベースは構造化された情報の集合体であり、膨⼤なデータを体系的に格納、検索、更新ができるように設計されたシステムです。データベースを操作するためには、専⽤のソフトウェアであるデータベース管理システム（DBMS）を使⽤します。 DBMS はデータの整合性を維持するための機能を提供し、複数ユーザーが同時にデータにアクセスしたり、
データを安全に保持するためのセキュリティ機能も備えています。 1980年代にリレーショナルデータベース（RDB）が普及しました。これは SQL を使って DB へアクセス‧管理‧操作をします。近年ではニーズの多様化により NoSQL データベースが台頭しています。

14 ©MIXI DBMS の役割データの格納: データを効率的に格納します。データの検索: クエリ⾔語を使⽤して、ユーザーが要求するデータを検索します。データの更新: データの挿⼊、削除、編集を⾏います。
バックアップとリカバリ: データ損失防⽌のためのバックアップ機能と、障害からの復旧を⽀援するリカバリ機能を提供します。セキュリティ: データへのアクセスを制御し、不正アクセスや機密情報の漏洩を防ぎます。マルチユーザーサポート: 複数のユーザーが同時にデータベースにアクセスし作業できるように、競合と整合性の問題を管理します。

15 ©MIXI DBMS の役割パフォーマンス監視: DB のパフォーマンスを最適化し、効率的な運⽤ができるように⽀援します。データの整合性保持: 変更が
DB 全体にわたる⼀貫した状態を保つように、制約とルールを適⽤します。トランザクション管理: 複数の DB 操作を⼀つの単位として管理し、ACID特性を適⽤してデータの整合性を確保します。データの抽象化: 複雑な内部構造を隠蔽し、ユーザーがより簡単にデータベースと対話できるようにします。

16 ©MIXI DBMS 処理別の分類データベースがどのように使⽤されるか、どのタイプのワークロードに最適化されているかを分類することが可能です。多くの場合、システムを設計し選択する際の重要な基準となります。 HTAPは新しいアプローチです。 • オンライントランザクション処理（OLTP）
• オンライン分析処理（OLAP） • ハイブリットトランザクション/分析処理（HTAP）

17 ©MIXI オンライントランザクション処理（OLTP）定義: リアルタイムトランザクション処理に焦点を当てたデータベースシステム。特徴: ⾼速のクエリ処理、データの挿⼊、更新、削除などの基本的な操作をサポート。⼩規模なトランザクションを多数、かつ迅速に処理することに適しています。⽤途: 銀⾏の取引システム、POSシステム、予約システムなど、実際のビジネス運⽤に
おいてリアルタイムでデータの整合性と可⽤性を維持する必要がある場合に使⽤されます。

18 ©MIXI オンライン分析処理（OLAP）定義: 複雑な分析、レポート作成、意思決定⽀援のために設計された DBMS。特徴: マルチ次元のデータ分析と複雑なクエリ処理に対応。データは多次元の形式で格納されることが多く、時間がかかるクエリでも⾼度な分析に適しています。
⽤途: データウェアハウスに典型的であり、企業の意思決定、市場分析、財務報告などの分析作業に利⽤されます。

19 ©MIXI ハイブリットトランザクション/分析処理（HTAP）ビジネス要求の複雑化によって OLTP と OLAP の境界があいまいになってきています。定義: 1つのプラットフォームで
OLTP と OLAP の両⽅を扱える DBMS。特徴: 即時性のあるデータ駆動型の意思決定が可能です。⽤途: リアルタイムでのデータ分析がビジネスの成功に直結する状況、例えば⾦融市場のモニタリングやフラウド検知など、迅速なデータ分析とアクションが要求されるシナリオに適しています。

20 ©MIXI トランザクションデータベースのトランザクションとは、データベースに対する⼀つ以上の変更（データの挿⼊、更新、削除など）を含む⼀連の操作をまとめた単位です。トランザクションの流れは以下の通りです。 1. 開始: このステップでトランザクションが開始されます。 2.
実⾏: データに対する⼀連の変更が⾏われます。 3. コミットまたはロールバック: 全ての操作が成功した場合、変更がデータベースに保存されます。（コミット）操作が失敗した場合は、トランザクション開始前の状態に戻ります。（ロールバック）トランザクションはデータベースの信頼性と整合性を守るために不可⽋であり、データベースを利⽤する様々な⽤途で重要な役割を担います。

21 ©MIXI ACID 特性トランザクションは、ACID 特性に従います。原⼦性（Atomicity）: トランザクション内の全操作は、ひとつの単位として扱われます。すべて成功するか、あるいはすべて無かったことにするか、です。部分的な完了は認められません。
⼀貫性（Consistency）: トランザクションは、データベースのルールに従い、正しいデータの状態でのみ変更を適⽤します。独⽴性（Isolation）: 同時に複数実⾏されるトランザクションは、互いに独⽴しており、他のトランザクションの途中の操作結果に影響を受けません。耐久性（Durability）: トランザクションが完了し、コミットが⾏われると、その結果は永続的にデータベースに記録され、システム障害が発⽣しても保持されます。

22 ©MIXI CAP 定理（ブリュワーの定理）データを格納する複数のノードで構成される分散システムでは、次の 3 つ全てを同時に提供することはできない（1つ諦める）という考え⽅です。 • Consistency（⼀貫性）
◦ どのノードに接続しても、最新のデータ、もしくは、エラーが返る • Availability（可⽤性） ◦ 1つ以上のノードがダウンしても、他のノードが応答を返す • Partition-tolerance（分断耐性） ◦ ノード間の通信が切断されても動作し続ける OLTP → CA 型（⼀貫性と多様性）が多い OLAP → AP 型（可⽤性と分断耐性）が多い

23 ©MIXI インデックス、索引インデックスは、書籍の⽬次や付箋、ドッグイヤーのようなものです。データベース内の⼤量データから⽬的のレコードを効率よく取得するための仕組みです。⾏No. 名前 1 Alice 100万
Bob インデックスの無いテーブル 100万⾏を総取得して John を探すインデックスのあるテーブル A-M N-Z (100万⾏) N-P Q-S T-V W-Z Yoshii (more) Tyler (more) Smith (more) Portman (more) A-C D-F G-I J-M John (more) George (more) David (more) Alice (more) J-M のなかから John を探すだけで済む

24 ©MIXI インデックスの⽋点インデックスは検索時に有効な機能ですが、インデックスを作り過ぎると DBMS にとって負荷になります。インデックスはテーブルとは別の特殊なテーブルに索引情報を格納しています。テーブル内のレコードを追加‧削除するたびにインデックスを最新化しています。インデックス最新化はコンピュートリソースを使うので、DBMS 全体のパフォーマンスに
影響を与える可能性があります。また、インデックスもディスクスペースを消費することになります。必要なインデックスだけを作る、使わなくなったインデックスは削除する、⽉に1度、半年に1度しか使わないインデックスなら使う前に作成、終わったら削除などの⼯夫をすることをお勧めします。

25 ©MIXI ⾏指向と列指向ディスク上でデータがどのように格納されるか、によって分類する⽅法もあります。⾏指向列指向商品ID 商品名価格 1
シャーペン 200 2 消しゴム 130 3 メモ帳 500 1 シャーペン 200 2 消しゴム 130 3 メモ帳500 ブロックには⾏ごとのデータが格納されているディスクブロック 1 2 3 シャーペン消しゴムメモ帳 200 130 500 ブロックには列ごとのデータが格納されているディスクブロック⼀意のキーで識別されていて、⾏単位のデータが必要なケースに向いています。トレンドの把握や平均の計算など集計処理を⾏う分析的なケースに向いています。

©MIXI 第2章: 様々なデータベース

27 ©MIXI 前提知識〜スケールアップとスケールアウト第2章に⼊る前に「スケール」という⾔葉だけ頭の⽚隅に置いてください。以下はデータベースでの例です。スケールアップ（垂直スケール）スケールアウト（水平スケール） 4
vCPU 16 GiB Mem 8 vCPU 32 GiB Mem インスタンススペックを増やす（大きくする）こと。リソースが余っていれば比較的容易にアップ可能。 DBMS のパラメータも一緒に変える必要あり。動的な変更が難しい。システム停止を伴うのが基本。（工夫して停止時間を最小にする） 4 vCPU 16 GiB Mem 4 vCPU 16 GiB Mem 4 vCPU 16 GiB Mem 4 vCPU 16 GiB Mem インスタンス自体を増やすこと。仕組みができていれば、インスタンス追加だけでスケールするので急激なアクセス増に対応可能。インスタンス間の同期や整合性が必要。 Disk Disk Disk

28 ©MIXI リレーショナルデータベース (RDBMS) RDBMSは1970年代に登場して以来、企業や組織のデータ管理基盤として広く利⽤されています。データは⾏と列で構成されるテーブルとして管理され、テーブル間の関連付けにより、データの重複を避け、⼀貫性のあるデータ管理が可能です。標準化されたデータベース⾔語 SQL
を使⽤して、データの検索‧追加‧削除‧保存を⾏います。リレーショナルデータベースの歴史は古く、昔から多くのシステムで利⽤されています。現代の Web アプリケーションではそれ以外のデータベースの利⽤が増えていますが、それでもリレーショナルデータベースが完全に無くなる可能性は低いと考えます。

29 ©MIXI RDBMS ACID 特性によりデータの信頼性と⼀貫性を提供していることが RDBMS の特徴です。⻑所 • ACID
特性をサポート ◦ 信頼性が⾼いトランザクション • 複数ユーザーアクセスが可能 ◦ ロック機構により整合性を保つ • データ冗⻑の防⽌ ◦ 適切なテーブル設計が前提 ◦ ストレージスペースの節約短所 • スケーラビリティに難しさ ◦ スケールアップに依存 • データベース構造が複雑になりがち ◦ スキーマ変更が柔軟ではない • メンテナンスの難易度 ◦ データ量に⽐例して難易度も上がる代表的な製品 Amazon Aurora, Cloud SQL, MySQL, PostgreSQL, Oracle Database, Microsoft SQL Server ユースケースオンライン決済、銀⾏取引、在庫管理、CRM、⼈事給与、ECサイト、旅⾏予約サイト、医療システムなど多数

30 ©MIXI NoSQL IoT や AI の急速な進歩によるビックデータ需要の⾼まり、SNS によるよりリアルタイムなデータ処理などを受け、NoSQL の利⽤が広まっています。
⾮リレーショナルなデータベースを NoSQL と呼んでいます。テーブル同⼠の関係をもって整合性などの優位点を発揮していた RDB と違い、 NoSQL の柔軟なスキーマは迅速で反復的な開発を可能とします。 NoSQL は⽔平⽅向へのスケールアウトが可能で、スパイクアクセスに対応しやすい設計になっています。

31 ©MIXI キーバリューストアキーとバリューのペアでデータが格納されるスキーマレスなデータベースです。キーに直接アクセスすることで⾼速な読み書きを実現しています。⻑所 • シンプルな操作 ◦ API
がシンプルで扱いやすい • パフォーマンス ◦ ⾼速なデータ構造 • 柔軟性 ◦ データモデルの変更が容易 • 拡張性 ◦ 分散アーキテクチャで⾼拡張性短所 • 複雑なクエリが苦⼿ ◦ 複雑なクエリや JOIN は避ける • 弱い⼀貫性 ◦ 分散アーキテクチャのトレードオフ • トランザクション管理 ◦ 複雑なトランザクションなら RDB 代表的な製品 Redis, Memcached, etcd, Amazon DynamoDB, Cloud Datastore ユースケースセッション管理、キャッシュ、ショッピングカート、チャットなどのリアルタイム処理、など

32 ©MIXI ドキュメントデータはドキュメント（JSON、XML など）として格納されます。ドキュメントが⼀纏めに格納されているため、⾼速な読み書きを実現します。⻑所 • 開発の効率化 ◦
アプリケーションのオブジェクトと似たデータ構造 • スケーラビリティ ◦ 分散アーキテクチャで拡張性が⾼い • データ表現の豊かさ ◦ 複雑なデータ型やネスト構成が可能 • スキーマ変更の容易さ ◦ スキーマフリー短所 • 集約操作が苦⼿ ◦ JOIN するような⽤途には向かない • トランザクションが限定的 ◦ トランザクション前提な⽤途ではない • 弱い⼀貫性 ◦ 分散アーキテクチャのトレードオフ代表的な製品 MongoDB, Couchbase, Amazon DocumentDB, Cloud Firestore ユースケース CMS、商品カタログ、ユーザープロファイル、多様なデバイスから多様なデータを受信するケース

33 ©MIXI ワイドカラムデータはカラムファミリーまたはスーパーカラムと呼ばれる列の集合として格納されます。カラムへの効率的なアクセスが可能で、⼤量のデータ書き込みと分析が得意です。⻑所 • ⼤規模データ運⽤ ◦ ペタバイト規模の分散処理
• 柔軟なデータモデル ◦ 動的なスキーマ変更が可能 • 能率的なストレージ活⽤ ◦ 使⽤されるカラムのみ保存される • ⾼速なクエリ ◦ カラムへのアクセスや集計が⾼速短所 • 設計が複雑になりがち ◦ RDB とは異なるアプローチが必要 • 整合性が苦⼿ ◦ ⼀貫性はアプリで保証（したほうが良い） • 独⾃のクエリ ◦ 複雑なクエリや JOIN は苦⼿代表的な製品 Cassandra, Google Bigtable, Amazon Keyspaces, ScyllaDB ユースケースビッグデータのリアルタイム処理、リコメンデーションエンジン、⼤量のイベントログ管理

34 ©MIXI インメモリデータをメモリ上に配置し⾼速な読み書きを提供します。⻑所 • 処理速度の向上 ◦ ⾼スループット、低レイテンシー •
スケーラビリティ ◦ ⽔平スケーリングに対応短所 • コスト ◦ RAM はディスクに⽐べて⾼額 • データの揮発性 ◦ 電源喪失でデータは消える ◦ データ永続化処理が別途必要 • リソース制約 ◦ ディスクに⽐べるとリソース増が難しい代表的な製品 Redis, Memcached, SAP HANA, Apache Ignite ユースケースキャッシュ、セッションストア、ゲームバックエンド、チャット

35 ©MIXI タイムシリーズ時系列データの扱いに特化したデータベースです。時系列クエリの⾼速処理やリアルタイム分析を⾏います。⻑所 • 時系列処理のパフォーマンス ◦ 時系列の収集‧保存‧分析に特化
• データの洞察⼒ ◦ ⾼度な分析機能を有していることがほとんど • スケーラビリティ ◦ 分散アーキテクチャの利点短所 • 汎⽤性は無い ◦ ⾮時系列データには向かない • クエリの制限 ◦ JOIN などの複雑なクエリは不向き • 特殊性 ◦ ニーズを満たすには条件がある代表的な製品 InﬂuxDB, TimescaleDB, Amazon Timestream, Google Bigtable ユースケース IoT デバイスデータの収集、⾦融マーケット、メトリクス、ログ

36 ©MIXI グラフデータエンティティがネットワーク状の関係を持ったデータの集まりです。 A は B の友達、B は C
の友達、C は A の友達の友達、のようなイメージです。⻑所 • 関係性の深掘り ◦ ネットワーク状関係の探索が速い ◦ 深い関係でも把握しやすい • クエリの最適化 ◦ RDB の JOIN に⽐べてパフォーマンスが良い • 柔軟性と拡張性 ◦ 関係の追加が容易短所 • ユースケースが限定的 • 運⽤の難易度 ◦ グラフが⼤きくなると維持管理が⼤変 • 学習の難易度 ◦ 専⾨的な知識が必要なことも代表的な製品 Neo4j, Amazon Neptune, OrientDB ユースケースソーシャルネットワーク、リコメンデーションエンジン、ナレッジマネジメント、⽣物学的ネットワークモデル

37 ©MIXI NewSQL 古くから広く使われてきた RDB ですが、⽔平スケールに難点がありました。モダンなアプリケーションは、短時間でアクセスが増えることが当たり前に発⽣し、スケーラビリティの問題が頭痛の種でした。 Google が
RDBMS の特性を維持しつつ、スケーラビリティも兼ね備える Google Spanner をリリースしました。これに影響‧刺激を受けるように TiDB、CockroachDB などの製品がリリースされました。

38 ©MIXI NewSQL NewSQLは、リレーショナルデータベースの利点を維持しつつ、モダンな分散システムアーキテクチャのスケーラビリティとパフォーマンスを兼ね備えたソリューションです。⻑所 • スケーラビリティ ◦ 分散アーキテクチャの利点
• ⾼いトランザクション性能 ◦ トランザクション処理の実現 • 強⼒なデータ整合性 ◦ ACID 特性の維持 • リレーショナルデータモデル ◦ 既存データモデルの活⽤短所 • 複雑性 ◦ DBMS の管理が難しくなりがち • 成熟度 ◦ まだ新しい技術 • 既存からの移⾏ ◦ 移⾏にかかるコストは無視できない代表的な製品 Google Spanner, TiDB, CockroachDB ユースケース⾦融取引、eコマース、ゲーム、ソーシャルネットワーク

©MIXI 第3章: クラウド上のデータベースサービス

40 ©MIXI 第3章: クラウド上のデータベースサービス主要なクラウドベンダーはマネージドなデータベースサービスを提供しています。今までに紹介したようなリレーショナル、NoSQL、NewSQL も使うことが可能です。それらデータベースサービスを紹介しつつ、特性についても解説します。

41 ©MIXI AWS が提供するクラウドデータベース https://aws.amazon.com/jp/products/databases/ よりデータベースのタイプ例 AWS のサービス
リレーショナル従来のアプリケーション、エンタープライズリソースプランニング (ERP)、カスタマーリレーションシップマネジメント (CRM)、e コマース Amazon Aurora , Amazon RDS, Amazon Redshift Key-Value トラフィックの多いウェブアプリケーション、e コマースシステム、ゲームアプリケーション Amazon DynamoDB インメモリキャッシュ、セッション管理、ゲームのリーダーボード、地理空間アプリケーション Amazon ElastiCache, Amazon MemoryDB ドキュメントコンテンツ管理、カタログ、ユーザープロファイル Amazon DocumentDB (MongoDB 互換) グラフ不正検出、ソーシャルネットワーク、レコメンデーションエンジン Amazon Neptune ワイドカラム⾼スケールの業界アプリケーション、設備のメンテナンス、多数の装置の管理、ルートの最適化 Amazon Keyspaces タイムシリーズモノのインターネット (IoT) アプリケーション、DevOps、産業⽤テレメトリ Amazon Timestream

42 ©MIXI Google Cloud データベース https://cloud.google.com/products/databases?hl=ja よりデータベースの種類 GOOGLE CLOUD
サービス説明リレーショナル Cloud SQL 最も柔軟なフルマネージドデータベースサービス AlloyDB for PostgreSQL 優れたパフォーマンス、可⽤性、拡張性を提供する、100% PostgreSQL 互換のデータベース Spanner 常時稼働、グローバルに⼀貫性のある、マルチモデル、事実上無制限のスケールのデータベース NoSQL Bigtable ⼤規模な⾼スループット、低レイテンシのアプリケーションに最適最も柔軟な NoSQL データベース Spanner Graph 事実上無制限にスケールする Graph データベース Memorystore 完全に管理されたインメモリデータベースサービスベクターデータベース AlloyDB AI モデル推論⽤のVertex AIなどの AI ツールや、pgvectorや LangChain などのオープンな標準テクノロジーと統合 Cloud SQL モデル推論のためにVertex AIと統合され、gen AI アプリを迅速に構築するためのオープンソースの pgvectorをサポート Spanner 正確な最近傍 (KNN) 検索または近似最近傍 (ANN) 検索を使⽤した検索をサポート

43 ©MIXI マネージドサービスとは？クラウドベンダーのデータベースサービスの最も分かりやすい特徴はマネージドサービスだということです。⼿間がかかる維持管理タスクをクラウドベンダーが実施してくれます。 https://pages.awscloud.com/rs/112-TZM-766/images/01_Amazon%20Aurora%20%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E6%A6%82%E8%A6%81.pdf より

44 ©MIXI ⾼い拡張性、耐久性、可⽤性インスタンスとストレージが分離していることで、⾼い拡張性/耐久性/可⽤性を実現しています。 https://pages.awscloud.com/rs/112-TZM-766/images/01_Amazon%20Aurora%20%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E6%A6%82%E8%A6%81.pdf より

45 ©MIXI グローバル展開グローバル展開しやすいこともクラウドデータベースの特徴です。世界中のユーザー⽇本北⽶ App DB ⽇本のリージョン
App DB 北⽶のリージョンスマホとサーバーは距離的、NW 的に近いほうがユーザー体験が良いグローバルスマホアプリの省略図 App と DB も近いほうがパフォーマンスが良い DB のレプリケーションが必要 - マネージドサービスを使う - ⾃前でレプリケーションする - スキーマ設計を⼯夫する ※ 参考資料：『家族アルバムみてね』 AWSマルチリージョン構成におけるデータベース運用

46 ©MIXI スケーラビリティ第2章で紹介したスケールアップ/スケールアウトでは、インスタンスのサイズや数を増やすことで性能を向上させていました。クラウドデータベースのなかには、スループットに応じて性能を変化するサービスがあります。ユーザーアクセスを予測しにくい Web サービスに最適な⽅式です。 Amazon
DynamoDB の場合 https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/CostOptimization_TableCapacityMode.html よりオンデマンドキャパシティモードテーブルへのリクエスト量に応じて性能が変わります。次のようなケースで使います。 • リクエストの増減が予測できない • リクエスト量が流動的、波が激しいプロビジョンドキャパシティモード性能を管理者が決めます。または、AutoScaling を使います。次のようなケースで使います。 • リクエスト予測が可能、周期的 • リクエスト増減が限定的

47 ©MIXI 料⾦商⽤サービスを開発していくにあたり、”コストへの考慮” は避けて通れません。パフォーマンスが悪いからといってスケールアウト/アップを単純に⾏うと請求で苦しむことになります。クラウドデータベースの料⾦特性を理解して使うようにしましょう。料⾦発⽣要素例 (AWS)
▪ Aurora （リレーショナル）インスタンスサイズと台数ストレージ容量 I/O 発⽣量バックアップストレージ容量データ転送量その他オプションの選択 ▪ DynamoDB （Key-Value） ※ オンデマンドモード書き込みリクエスト量読み込みリクエスト量ストレージ容量バックアップストレージ容量リストアしたテーブル容量データ転送量その他オプションの選択 ▪ ElastiCache （インメモリ） ※ オンデマンドノードサイズと台数バックアップ容量データ転送量その他オプションの選択

48 ©MIXI クラウドデータベースサービスの注意点モダンな開発ではクラウドデータベースの利⽤が当たり前ですが、注意点もあります。 • コントロールできないクラウドベンダーによるメンテナンス ◦ 機器⽼朽化の対応による再起動 ◦ セキュリティパッチの適⽤による再起動
◦ マイナーバージョンアップによる再起動 • DBMS バージョンのサポート ◦ 古いバージョンはサポートが終わると使えなくなる ◦ 新しいバージョンへのアップグレードを計画 • 何事も100%ではない ◦ 予期しないフェールオーバー（障害でインスタンスが切り替わること） ◦ 瞬間的なエラー ◦ トレンド⼊りするような⼤規模障害

©MIXI ミニクイズ

50 ©MIXI ミニクイズ 1 ACID 特性の正しい組み合わせを選んでください。原⼦性（Atomicity）⼀貫性（Consistency）独⽴性（Isolation）耐久性（Durability）
トランザクションはお互いに独⽴しており同時並⾏実⾏される他のトランザクションの影響を受けないトランザクション内の操作は⼀つの単位として扱われ ”全て成功” か ”全てなかったこと” の何れかですトランザクションは、データベースのルールに従い正しいデータの状態でのみ変更を適⽤するコミットが⾏われるとトランザクションは永続的に保存される

51 ©MIXI ミニクイズ2 ❏ CAP 定理に照らし合わせた場合、OLTP、OLAP それぞれで多く⾒られるパターンは何でしょうか？ ❏ データの信頼性と⼀貫性を重視したアプリケーションを構築する計画があります。
データベースは何を選べば良いでしょうか？ ❏ 永続性が必要ではないデータに対して⾼速に読み書きをしたい要件があります。データベースは何を選べば良いでしょうか？ ❏ 先輩社員が「クラウドのマネージドデータベースを使っていれば何もしなくていいから楽だよ」と⾔っていました。本当でしょうか？注意点があれば教えてください。

52 ©MIXI 休憩第1章: データベースの基本概念第2章: 様々なデータベース第3章: クラウド上のデータベースサービス第4章:
データベースの選定とアーキテクチャ第5章: セキュリティとデータガバナンス第6章: データベースとAI

©MIXI 第4章: データベースの選定とアーキテクチャ

54 ©MIXI データベース選定⽅法まず⼀番に考えるのは⽬的やビジネス要件に合致しているかどうかです。第2章では NoSQL、NewSQL を紹介しました。第3章ではクラウドデータベースを紹介しました。そこでユースケースや⻑所短所を解説しています。振り返ってみて選定⽅法を考えてみましょう。次のページには選択に役⽴つ質問を引⽤しました。選定に迷った際に参考になります。
それでも判断がつかない場合は、PoC を実施します。本番以外の環境で候補のデータベースを構築し、実施にアプリケーションを動作しながらテストと計測を⾏います。

55 ©MIXI 選択に役⽴つ質問 • データはどのように構造化されていますか。 • どのレベルの参照整合性が必要ですか。 • ACID への準拠は必要ですか。
• ストレージ要件は時間の経過とともにどのように変化しますか。これにより、スケーラビリティにどのような影響がありますか。 • 書き込みクエリに対する読み取りクエリの割合はどのくらいですか。キャッシングによってパフォーマンスが向上する可能性はありますか。 • OLTP - オンライントランザクション処理または OLAP - オンライン分析処理のどちらが優先されますか。 • データにはどのレベルの耐久性が必要ですか。 • 商⽤データベースエンジンやライセンスコストから離れたいという希望はありますか。 • データベースには運⽤上どのようなことが期待されますか。マネージドサービスへの移⾏は主な懸念事項ですか。 • データベースへのアクセスは現在どのように⾏われていますか。アプリケーションアクセスのみですか、それともビジネスインテリジェンス (BI) ユーザーやその他の接続された既製アプリケーションが存在しますか。 https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/performance-efficiency-pillar/perf_data_use_purpose_built_data_store.html より

56 ©MIXI データベース選定例 AWS 社が公開しているブログからデータベース選定例を学びます。 https://aws.amazon.com/jp/blogs/database/building-a-modern-application-with-purpose-built-aws-databases/?dbd_mod4 使⽤例1 キーバリュー: 製品カタログの使⽤例です。通常、製品には⼀意の識別⼦と製品名、価格などの属性が含まれています。
⼀意のキー検索に強い Amazon DynamoDB を選定しました。使⽤例2 全⽂検索: 顧客が製品カタログを検索するシステムです。キーワード検索を効率的に⾏える Amazon OpenSearch Service を選定します。（図中は Amazon Elasticsearch）使⽤例1 の DynamoDB と同期しています。使⽤例3 インメモリ: ユーザーが購⼊された書籍の「トップ 20」を確認できるベストセラーリストです。ユーザーに検索結果を素早く返すために Amazon ElastiCache を使⽤します。注⽂が⼊るたびに注⽂テーブルからリアルタイムで更新が⼊ります。使⽤例4 グラフ: ソーシャルレコメンデーションです。Amazon Neptune を使って友達が購⼊したものからオススメを⽣成します。

57 ©MIXI マイクロサービスとデータベースマイクロサービス毎にデータベースを持ちます。データベース製品はマイクロサービスに合わせて選択します。サービス間の疎結合と独⽴性を確保します。ユーザー Front UI Identity Identity
DB Cart Cart DB Inventory Inventory DB Shipping Shipping DB その他たくさん BI/分析 BI/分析 DB DB間のデータは API で取得 KVS RDB KVS WideColumn ECサイトの省略図 Session InMemory

58 ©MIXI API 構成例前のページで「DB間のデータは API で取得」と書きました。 API でデータを操作するアーキテクチャのシンプルな構成例を紹介します。 API
Gateway Sales DB Order DB User DB User Microservice Sales Microservice Order Microservice API リクエストを受け付けるサービス。 URI ごとに捌く。 API キャッシュも可能。 /user /sales /order Container, Serverless クエリを代⾏してレスポンスを返す # API仕様書 ## 概要 ## パス /user/v1/search ## メソッド GET ## パラメータ ## レスポンス ### 成功時 ### 失敗時 ## リクエストサンプル ## レスポンスサンプル

59 ©MIXI コネクションと RDS Proxy アプリケーションから RDB へクエリを発⾏するためにコネクションを張ります。サーバーレスアプリケーションの場合、多数並列的に起動されるファンクション数だけコネクションが必要となります。
DBMS 観点だとコネクションはリソースを消費します。過剰なコネクションはそれだけでDBMS の負荷となり、全体的なレスポンスを遅くする可能性があります。 RDS Proxy はアプリケーションと DBMS の間に⼊り、コネクションプーリングの役割を果たします。 DB Cluster RDS Proxy 無しファンクション数のコネクションが必要 RDS Proxy 有り DB Cluster Many Functions Many Functions ファンクションは多数並列的に起動プールしているコネクションのうち Available のものを使う Proxy がコネクションを肩代わりするイメージ

60 ©MIXI Write と Read を使い分けようクラウドデータベースサービスの多くは、Write と Read のインスタンスを分離可能です。
アプリケーションロジックで、更新処理は Writer インスタンスへ、読み取り処理はReader インスタンスへと振り分けます。インスタンスの負荷が分散‧軽減され、全体のスループットが改善します。 https://pages.awscloud.com/rs/112-TZM-766/images/01_Amazon%20Aurora%20%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E6%A6%82%E8%A6%81.pdf より

61 ©MIXI シャーディングアーキテクチャの話を少しずれるかもしれませんが、⼤事なテクニックを紹介します。シャーディングは、⼤規模なデータベースを⼩さな、扱いやすい部分に分割するプロセスです。これにより、データベースのスケーラビリティとパフォーマンスが向上し、特に書き込みや読み込みの多いアプリケーションにおいて、データ管理の効率を⾼めます。⾏No. 名前 1
Alice ‧‧‧ ‧‧‧ 100万 Bob 名前が A〜I 名前が J〜S 名前が T〜Z ▪ 主なシャーティングの種類 □ 範囲ベース値の範囲に基づいて分割します。（左の例） □ ハッシュハッシュ関数を使って⾏にシャードキーを付与シャードキーで分割します。 □ ディレクトリルックアップテーブルを使⽤して、どのシャードにデータが存在するかを追跡します。

62 ©MIXI 分散システムでのトランザクション単⼀ DBMS のコミット‧ロールバックはそこまで難しくありません。ただ、現在のシステムはほとんどが分散システムとなっています。各マイクロサービスが他と連携しながらロールバックをするような実装にします。トランザクション決済App
ポイントApp 発送App ポイントDB 発送DB 決済API ECサイトで買い物をする在庫App 在庫DB

63 ©MIXI 分散システムでのロールバックトランザクション決済App ポイントApp 発送App ポイントDB 発送DB 決済API
ECサイトで買い物をする在庫App 在庫DB 在庫引当クレカ決済ポイント付与エラー！！ロールバック決済App ポイントApp 在庫App ポイント減算クレカ返⾦補充

65 ©MIXI データベースのセキュリティ第5章ではデータベース内のデータを不正アクセス、損傷、盗難、漏えいから保護するための対策を紹介します。⼀般的にデータベースに格納しているデータの多くは機密性が⾼く、個⼈情報や財務情報などのデータを含んでいることが多いので、データベースのセキュリティは極めて重要です。セキュリティは継続的なプロセスであり、全員参加です。新たな脅威に対応するために定期的に⾒直しと強化が必要です。
また、データ保護規制や業界基準に準拠することも、データベースセキュリティの重要な側⾯です。

66 ©MIXI データベースセキュリティの主要概念 • 認証 ◦ ユーザーがデータベースにアクセスする前に、正しい認証資格を持っていることを要求します。パスワード認証などが代表です。 • 認可
◦ 認証されたユーザーに対して、特定リソースへのアクセスを許可‧拒否します。 • アクセス制御 ◦ ユーザーが実⾏できる操作の種類（読み取り、書き込み、更新、削除など）を定義します。 • 暗号化 ◦ 通信時、保管時にデータを暗号化し、不正な盗聴⾏為を防⽌します。 • 監査 ◦ データベースのアクセスログや操作ログを監視し、不審な活動やポリシー違反を検知します。 • データマスキング ◦ 本番環境以外でデータを使う際には、機密データを隠蔽（ダミーに変える）します。 • バックアップ‧リストア ◦ データ損失やデータ損害時に早期の回復をするためにバックアップを取得します。

67 ©MIXI クラウドの認証古くからデータベースの認証はパスワードが利⽤されてきました。ただ、アプリケーションに何らかの形でパスワードを持たす⽅式は、漏洩の可能性を排除できません。クラウドではシークレットストアを使ってパスワードを保管するようにしましょう。 DB App Secrets Store
(1) App から Secrets Store にパスワード問い合わせ (2) 許可された App から許可された操作だった場合、 Secrets Store はパスワードを返す (3) App は返されたパスワードでデータベース認証を⾏う ▪ メリット - 開発者がパスワードを知る必要が無い - パスワードの保護をクラウドの IAM で⼀元管理できる - 定期的なパスワード変更を容易に実装できる - パスワード管理をクラウドベンダーにオフロードできる (1) (3) (2)

68 ©MIXI ネットワークの制限データベースは機密データの集まりです。データベースにアクセスできるアプリケーション、ユーザーをネットワーク的に制限します。クラウドデータベースサブネット管理サブネットパブリックサブネット DB
App-A App-B Management クラウド外からのアクセスは拒否 App-A からのアクセスは許可 App-B からのアクセスは拒否 Management からのアクセスは許可社内管理者

69 ©MIXI 最⼩権限の原則ネットワーク的な制限はかけました。次はデータベースの権限を制限します。 DBMS の権限では、どのテーブルに対してどの操作（INSERT、DELETE、UPDATE など）を許可するか、という設定を⾏います。この権限設定は少しだけ難しいので、アプリケーションユーザーに強い権限（全テーブルに全操作OK）を付与してしまうことが残念ながら多くあります。それはアンチパターンです。
必要な権限だけを付与するようにしましょう。クラウドデータベースサブネット管理サブネットパブリックサブネット DB App-A Management App-A にはアプリケーションで使うテーブルに INSERT,UPDATE,DELETE,SELECT を付与アプリケーションに関係ないテーブルにはアクセスさせない社内管理者管理者が強い権限を使う場合は社内ワークフローで承認をもらう作業時は複数⼈で⾏う

70 ©MIXI セキュリティパッチの適⽤セキュリティパッチは、ソフトウェアやシステムのセキュリティ上の脆弱性を修正するアップデートです。セキュリティパッチを定期的に適⽤することは、サイバーセキュリティ戦略の基本的かつ重要な部分であり、攻撃者がシステムを侵害する⼿段を最⼩限に抑えるために必須の習慣です。そのためには、セキュリティパッチがリリースされ次第、迅速に適⽤することが勧められます。また、それらの適⽤を継続的に監視し、セキュリティ対策を最新の状態に保つためのパッチ管理ポリシーを確⽴することが重要です。クラウドベンダーのマネージドデータベースを使っている場合、セキュリティパッチはクラウドベンダーに
よって管理されます。適⽤の内容やタイミングは事前に通知されます。その通知を⾒て適⽤タイミングを決定し、決⾏します。セキュリティパッチはデータベースクライアント（アプリケーションなど）にも提供されるケースがあります。その際には、データベースクライアントにも同じ様に適⽤しましょう。

71 ©MIXI SQL インジェクション SQL インジェクションは、アプリケーションの脆弱性をついて不正な SQL ⽂を混⼊させ、本来アクセスできないはずのデータにアクセスし、内部侵⼊する攻撃⼿法です。 ID
PW Login ▪ 本来の挙動 SELECT id FROM USER_TABLE WHERE id = $ID and password = $PW; id と password が⼀致すると TRUE になってログイン成功 ID に⼊⼒した値が $ID、 PW に⼊⼒した値が $PW の変数で SQL ⽂に渡される ▪ SQL インジェクション Web 画⾯の ID に「1′ OR 1=1;」と⼊⼒すると、 SELECT id FROM USER_TABLE WHERE id = 1 OR 1=1; and password = $PW; 必ず TRUE になってしまいログインされてしまう

72 ©MIXI SQL インジェクションの対策 SQL インジェクションは対策⽅法が開⽰されています。アプリケーションで必ず対策を⾏いましょう。 • SQL⽂の組み⽴ては全てプレースホルダで実装する。 •
SQL⽂の組み⽴てを⽂字列連結により⾏う場合は、エスケープ処理等を⾏うデータベースエンジンのAPIを⽤いて、SQL⽂のリテラルを正しく構成する。 • ウェブアプリケーションに渡されるパラメータにSQL⽂を直接指定しない。 • SQL インジェクションに対応したフレームワークを使う。 • 前段のロードバランサー等に WAF を設置する。 https://www.ipa.go.jp/security/vuln/websecurity/sql.html より

74 ©MIXI データベースとAI 第6章ではデータベースと AI の関わりについて話します。データベースと AI の統合がもたらす可能性について理解を深めます。世の中の
IT システムには既に AI を活⽤したものが数多く存在します。それらがデータベースをどのように使っているのかは、興味深い題材です。また、DBMS（データベースマネジメントシステム）⾃体にも AI が組み込まています。それらの製品を知り、今後のシステム開発に活かしてもらえれば嬉しいです。

75 ©MIXI ベクトルデータベースベクトルデータベースは、画像、テキスト、⾳声などの⾮構造化データを、数値のベクトルとして保存‧検索することに特化したデータベースです。ベクトルデータベースは、AI の進化に伴い、特に重要な役割を果たしています。データはベクトルと呼ばれる数値の配列として表現されます。このベクトルは、多次元空間におけるデータの位置を⽰し、意味的類似性を持つデータ同⼠が近くに配置されるように設計されています
⾮構造化データ Embedding Model Vector Store App ベクトルデータベースの利⽤パターンベクトルに変換インデックス⽣成検索 / レスポンス

76 ©MIXI ベクトルデータベースの実践的ユースケースベクトルデータベースのユースケースを紹介します。 • パーソナライズされたレコメンデーション ◦ 顧客の閲覧履歴や購買データなどのデータをベクトル化し、リアルタイムでユーザーに最適な商品を推薦します。 •
⾼度なセマンティック検索： ◦ ⽂書データや画像をベクトル化し、意味的に類似した情報を検索します。 • RAG（検索拡張⽣成） ◦ ドメイン固有の知識を活⽤し、ハルシネーションを減少させます。 • リアルタイム分析 ◦ IoTセンサーデータのような複雑なデータをリアルタイムで分析し、異常検知や詐欺防⽌に役⽴てます。 • 不正検知 ◦ データのつながりから⽭盾を発⾒し、不正リスクを軽減します。

77 ©MIXI NoSQLデータベースとAI NoSQLデータベースは、その設計思想と特性により、AI に特に適しています。 • 柔軟なデータ構造とスキーマレス設計 ◦ スキーマレスの特性により、AI で必要な多様なデータを扱えます。
• 多様なデータ形式の処理能⼒ ◦ ⾮構造化、半構造化データに対応 • 優れたスケーラビリティと分散処理 ◦ ⼤量のリクエストを処理するために NoSQL のスケーラビリティが必須 • ⾼速データ処理、リアルタイムデータ処理の対応 ◦ NoSQL の低レイテンシーと⾼スループットは AI と相性が良い

78 ©MIXI データベース管理の⾃動化とAI DBMS にも AI が組み込まれている製品があり、管理タスクの効率化を実現しています。【例】 • データベースのプロビジョニング、パッチ適⽤、トラブルシューティングなどの
管理タスクに関するガイダンスをチャットボットで提供 • データベースから SQL でデータを抽出、抽出されたデータを基に機械学習を実施、⽣成されたモデルを使った推論が可能 • Text-to-SQL: ⾃然⾔語で表現されたクエリを SQL ⽂へ変換「先⽉の◯◯と△△の売上を教えて」 → 「SELECT …」

©MIXI ミニクイズ

80 ©MIXI ミニクイズ 3 次の問に答えてください。 1. データベースへの書き込みより読み込みが多いシステムがあります。クラウドデータベースで実施できる対策を教えてください。 2. ゲーム内で当⽇の成績
Top10 を表⽰するスコアボードを作ろうとしています。採⽤するデータベースとデータの更新⽅法を考えてください。 3. 新しいプロダクトの⽴ち上げに参加しました。アーキテクチャを検討した結果、データベースの採⽤に2つの選択肢があります。最終決定を下すためにすることは何でしょう？

81 ©MIXI ミニクイズ 4 次の問に正 or 誤で答えてください。理由も説明してください。 1.
ソースコードは厳重に管理しており安⼼なので、データベースパスワードはコード内に書いた。 2. どうしても動かないロジックがあり、デバッグ⽬的で管理者権限を使ってデータベースを操作した。 3. セキュリティチェックはセキュリティチームの仕事なので、彼らを信頼し、とにかく動くことを優先してコードを書いた。 4. プログラム開発で使っているツールに脆弱性が⾒つかりパッチが公開された。セキュリティチームの案内に従ってツールにパッチを適⽤した。

©MIXI 中締め

©MIXI

データベース研修 DB基礎【MIXI 25新卒技術研修】

データベース研修 DB基礎【MIXI 25新卒技術研修】

Video

More Decks by MIXI ENGINEERS

Other Decks in Technology

Featured

Transcript