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

本スライドは、MIXIの2024年度新卒向け技術研修で使用された資料です。

＜科目名＞
データベース研修 DB基礎

＜関連リンク＞
動画▶
リポジトリ▶ https://github.com/mixigroup/2024BeginnerTrainingDataBaseBasic

※お願い※ 〜 資料・動画・リポジトリのご利用について〜
公開している資料や動画は、是非、勉強会や社内の研修などにご自由にお使いいただければと思いますが、以下のような場でのご利用はご遠慮ください。
- 受講者から参加費や授業料など金銭を集めるような場での利用
（会場費や飲食費など勉強会の運営に必要な実費を集める場合は問題ありません）
- 出典を削除または改変しての利用

Transcript

1. ©MIXI 24新卒技術研修 データベース研修 DB基礎
2. 2 ©MIXI 本講義の⽬的 ▪ ⽬的 正式配属後の開発タスクを担当するにあたり、 データベース（DB） に関する必要最低限の知識習得を⽬的とします。 複数ある DB 種類のそれぞれの特性を知り、 最適な DB を選択‧利⽤できる初期段階まで到達することを⽬的とします。 ▪ 背景 あらゆるプロダクト開発で DB は必須といってよいスキルです。 クラウドと相性が良い DB がサービス化しており、モダンなシステム開発には 基本的かつ広い知識が必要となっています。
3. 3 ©MIXI 本⽇の内容 第1章: データベースの基本概念 第2章: リレーショナルデータベースの深掘り 第3章: SQL⼊⾨ 第4章: ⾮リレーショナルデータベースの概観 第5章: データウェアハウスとデータレイク 第6章: クラウド上のデータベースサービス 第7章: データベースの選定とアーキテクチャ 第8章: セキュリティとデータガバナンス
4. 4 ©MIXI 時間割 10:30〜10:45 ⾃⼰紹介（お互い） 10:45〜11:35 1〜3章 11:35〜11:45 休憩 11:45〜12:45 4〜5章 12:45〜13:45 ランチ休憩 13:45〜14:45 6〜8章 14:45〜14:50 中締め
5. 5 ©MIXI 講義中のふるまい • スマホは⾳が出ないモードでお願いします。 • 急なトイレ等は遠慮なくどうぞ。断る必要はありません。 • 質問したい場合は挙⼿してください。 • 相槌とか感嘆とかのリアクション歓迎です。 • 飲⾷ OK です。ただ、周囲への配慮はお願いします。
6. 自己紹介タイム
7. 7 ©MIXI ⾃⼰紹介 吉井 亮 (YOSHII RYO) • 経歴 HWエンジニア → 中⼩SIer → ERPコンサル → AWS パートナー → 株式会社MIXI（2023年7⽉⼊社） • Community OpsJAWS (AWS Community Builder) • 好きな⾔葉 No human labor is no human error. Follow Me https://my.prairie.cards/u/YoshiiRyo1
8. 8 ©MIXI 3つ選んで⾃⼰紹介をお願いします お名前 （必須） 趣味 出⾝地 最近⾏った 旅⾏ 休みにすること 好きな⾷べ物 ペットの話 私の宝物 将来の夢 好きなテック 気になる 出来事 MIXI で やりたいこと
9. ©MIXI 第1章: データベースの基本概念
10. 10 ©MIXI データベースとは データベースは構造化された情報の集合体であり、膨⼤なデータを体系的に格納、検索、 更新ができるように設計されたシステムです。 データベースを操作するためには、専⽤のソフトウェアである データベース管理システム（DBMS）を使⽤します。 DBMS はデータの整合性を維持するための機能を提供し、 複数ユーザーが同時にデータにアクセスしたり、 データを安全に保持するためのセキュリティ機能も備えています。 1980年代にリレーショナルデータベース（RDB）が普及しました。 これは SQL を使って DB へアクセス‧管理‧操作をします。 近年ではニーズの多様化により NoSQL データベースが台頭しています。
11. 11 ©MIXI DBMS の役割 データの格納: データを効率的に格納します。 データの検索: クエリ⾔語を使⽤して、ユーザーが要求するデータを検索します。 データの更新: データの挿⼊、削除、編集を⾏います。 バックアップとリカバリ: データ損失防⽌のためのバックアップ機能と、障害からの復旧を ⽀援するリカバリ機能を提供します。 セキュリティ: データへのアクセスを制御し、不正アクセスや機密情報の漏洩を防ぎます。 マルチユーザーサポート: 複数のユーザーが同時にデータベースにアクセスし作業できるよ うに、競合と整合性の問題を管理します。
12. 12 ©MIXI DBMS の役割 パフォーマンス監視: DB のパフォーマンスを最適化し、効率的な運⽤ができるように⽀援 します。 データの整合性保持: 変更が DB 全体にわたる⼀貫した状態を保つように、制約とルールを 適⽤します。 トランザクション管理: 複数の DB 操作を⼀つの単位として管理し、ACID特性を適⽤して データの整合性を確保します。 データの抽象化: 複雑な内部構造を隠蔽し、ユーザーがより簡単にデータベースと対話でき るようにします。
13. 13 ©MIXI DBMS 処理別の分類 データベースがどのように使⽤されるか、どのタイプのワークロードに最適化されている かを分類することが可能です。 多くの場合、システムを設計し選択する際の重要な基準となります。 HTAPは最新のアプローチです。 • オンライントランザクション処理（OLTP） • オンライン分析処理（OLAP） • ハイブリットトランザクション/分析処理（HTAP）
14. 14 ©MIXI オンライントランザクション処理（OLTP） 定義: リアルタイムトランザクション処理に焦点を当てたデータベースシステム。 特徴: ⾼速のクエリ処理、データの挿⼊、更新、削除などの基本的な操作をサポート。 ⼩規模なトランザクションを多数、かつ迅速に処理することに適しています。 ⽤途: 銀⾏の取引システム、POSシステム、予約システムなど、実際のビジネス運⽤に おいてリアルタイムでデータの整合性と可⽤性を維持する必要がある場合に 使⽤されます。
15. 15 ©MIXI オンライン分析処理（OLAP） 定義: 複雑な分析、レポート作成、意思決定⽀援のために設計された DBMS。 特徴: マルチ次元のデータ分析と複雑なクエリ処理に対応。 データは多次元の形式で格納されることが多く、 時間がかかるクエリでも⾼度な分析に適しています。 ⽤途: データウェアハウスに典型的であり、企業の意思決定、市場分析、 財務報告などの分析作業に利⽤されます。
16. 16 ©MIXI ハイブリットトランザクション/分析処理（HTAP） ビジネス要求の複雑化によって OLTP と OLAP の境界があいまいになってきています。 定義: 1つのプラットフォームで OLTP と OLAP の両⽅を扱える DBMS。 特徴: 即時性のあるデータ駆動型の意思決定が可能です。 ⽤途: リアルタイムでのデータ分析がビジネスの成功に直結する状況、 例えば⾦融市場のモニタリングやフラウド検知など、 迅速なデータ分析とアクションが要求されるシナリオに適しています。
17. 17 ©MIXI ⾏指向と列指向 ディスク上でデータがどのように格納されるか、によって分類する⽅法もあります。 ⾏指向 列指向 商品ID 商品名 価格 1 シャーペン 200 2 消しゴム 130 3 メモ帳 500 1 シャーペン 200 2 消しゴム 130 3 メモ帳500 ブロックには⾏ごとのデータが格納されている ディスクブロック 1 2 3 シャーペン 消しゴム メモ帳 200 130 500 ブロックには列ごとのデータが格納されている ディスクブロック ⼀意のキーで識別されていて、⾏単位のデータが 必要なケースに向いています。 トレンドの把握や平均の計算など集計処理を ⾏う分析的なケースに向いています。
18. ©MIXI 第2章: リレーショナルデータベースの深掘り
19. 19 ©MIXI 第2章: リレーショナルデータベースの深掘り 第2章ではリレーショナルデータベースを解説します。 リレーショナルデータベースの歴史は古く、昔から多くのシステムで利⽤されています。 現代の Web アプリケーションではそれ以外のデータベースの利⽤が増えていますが、 それでもリレーショナルデータベースが完全に無くなる可能性は低いと考えます。 テーブルの正規化、トランザクション、ACID 特性、インデックス、ビューといった リレーショナルデータベースの特徴的な機能や設計⽅法を学びます。
20. 20 ©MIXI テーブル テーブル 列/属性 ⾏/レコード データが格納されている構造的な領域です。 ⾏と列で構成されています。
21. 21 ©MIXI 制約 社員ID 名前 部⾨ID 100001 J0001 100002 S0002 100003 K0001 Primary Key 部⾨ID 部署名 J0001 ⼈事部採⽤課 S0002 総務部設備課 K0001 開発部第1課 社員テーブル 部⾨テーブル Foreign Key ⼀意、かつ、 NULL は許容しない 部⾨テーブルに 無い部⾨IDは 社員テーブルに 登録できない 他には、 • NOT NULL（NULL は許容しない） • CHECK（任意の条件、0以上など） • UNIQUE（重複は許容しない） の制約があります。
22. 22 ©MIXI リレーショナル EmpID Name DeptID 100001 A J0001 100002 B S0002 100003 C K0001 DeptID DeptName J0001 ⼈事部採⽤課 S0002 総務部設備課 K0001 開発部第1課 employee dept そもそも「リレーショナル」データベースとは何でしょうか？ 前ページの例のようにテーブル同⼠が関係を持っているので「リレーショナル」です。 社員テーブルと部⾨テーブルが部⾨IDによって関係付けられていることで、 ある社員の所属部署を特定することが可能になっています。 SELECT d.DeptName FROM employee e JOIN dept d ON e.DeptID = d.DeptID WHERE e.Name = 'A';
23. 23 ©MIXI 正規化 リレーショナルデータベースにおけるテーブルの正規化は、データ構造を最適化し、 冗⻑性を排除してデータの整合性を向上させるプロセスです。 データの重複をなくして、データの整合性を保持します。 挿⼊、更新、削除の操作で予期せぬデータの不整合が起こることを防ぎます。 冗⻑なデータを減らすことで、検索‧処理のパフォーマンスを向上させます。
24. 24 ©MIXI 正規化のステップ 第1正規化（1NF）: 同じ⾏内での繰り返しを無くす、かつ、 Primary Key（主キー）を持つ 第2正規化（2NF）: 1NF を満たし、かつ、完全関数従属が満たされた状態 第3正規化（3NF）: 2NF を満たし、かつ、推移的関数従属が解決された状態 これ以降にも、ボイス＝コッド正規形 (BCNF)、4NF、5NF などがありますが割愛します。 関係関数従属 A が決まると B が決まる状態 （例）会社名→代表者、本社住所、連絡先 | 商品名→販売価格 部分関数従属 主キーの⼀部で⾮主キーの値が決まる状態（主キーが分割しきれていない） 完全関数従属 すべての⾮主キーの値が主キーによって決まる状態 推移的関数従属 A が決まると B が、B が決まると C が決まる状態 （例）⽣徒名→受講コース→講師名
25. 25 ©MIXI 正規化されていないテーブル 社員ID 名前 受講コース 講師名 100001 AAA 会社法、セキュリティ XXX、WWW 100002 BBB Webデザイン、セキュリティ YYY、WWW 100003 CCC DB基礎、セキュリティ ZZZ、WWW 例）新卒研修テーブル
26. 26 ©MIXI 第1正規化 ⾏内の繰り返しを無くします。 社員ID 名前 受講コース 講師名 100001 AAA 会社法 XXX 100001 AAA セキュリティ WWW 100002 BBB Webデザイン YYY 100002 BBB セキュリティ WWW 100003 CCC DB基礎 ZZZ 100003 CCC セキュリティ WWW 新卒研修テーブル 困ること: 新しい受講コースを増やしたい時に、社員ID や名前が決まらないと⾏を増やせない
27. 27 ©MIXI 第2正規化 完全関係従属（すべての⾮主キーの値が主キーによって決まる状態）にします。 社員ID 名前 コースID 100001 AAA C101 100001 AAA C001 100002 BBB C201 100002 BBB C001 100003 CCC C301 100003 CCC C001 受講社員テーブル コースID 受講コース 講師名 C001 セキュリティ WWW C101 会社法 XXX C201 Webデザイン YYY C301 DB基礎 ZZZ 受講コーステーブル 困ること: 社員がいなくても新しい受講コースを増やせるようになったけど、 将来のために講師だけ増やしたい（受講コーステーブルに講師名を⾜したい）ときに困る
28. 28 ©MIXI 第3正規化 推移的関数従属（受講コース→講師名）が解決された状態にします。 社員ID 名前 コースID 100001 AAA C101 100001 AAA C001 100002 BBB C201 100002 BBB C001 100003 CCC C301 100003 CCC C001 受講社員テーブル コースID 受講コース 講師ID C001 セキュリティ T001 C101 会社法 T002 C201 Webデザイン T003 C301 DB基礎 T004 受講コーステーブル 講師ID 講師名 T001 WWW T002 XXX T003 YYY T004 ZZZ 講師テーブル
29. 29 ©MIXI あえて正規化しないケース 正規化プロセスは、冗⻑性の排除とデータの整合性の向上を⽬的としていますが、 パフォーマンスや特定のアプリケーション要件に基づいて正規化をあえて⾏わないケース がいくつか存在します。 • パフォーマンスの最適化 ◦ 単⼀のクエリで必要なデータを取得したい • 頻繁な JOIN の回避 ◦ DBMS にとって JOIN はコストが⾼いので JOIN 回数を抑えたい • 特定のアクセスパターン ◦ 特定のデータアクセスがパターン化されているので⾮正規化のほうが良い • リアルタイム処理 ◦ 限りなくリアルタイムに近い処理が必要
30. 30 ©MIXI トランザクション データベースのトランザクションとは、データベースに対する⼀つ以上の変更 （データの挿⼊、更新、削除など）を含む⼀連の操作をまとめた単位です。 トランザクションの流れは以下の通りです。 1. 開始: このステップでトランザクションが開始されます。 2. 実⾏: データに対する⼀連の変更が⾏われます。 3. コミットまたはロールバック: 全ての操作が成功した場合、変更がデータベースに保存されます。（コミット） 操作が失敗した場合は、トランザクション開始前の状態に戻ります。（ロールバック） トランザクションはデータベースの信頼性と整合性を守るために不可⽋であり、 データベースを利⽤する様々な⽤途で重要な役割を担います。
31. 31 ©MIXI ACID 特性 トランザクションは、ACID 特性に従います。 原⼦性（Atomicity）: トランザクション内の全操作は、ひとつの単位として扱われます。 すべて成功するか、あるいはすべて無かったことにするか、です。 部分的な完了は認められません。 ⼀貫性（Consistency）: トランザクションは、データベースのルールに従い、 正しいデータの状態でのみ変更を適⽤します。 独⽴性（Isolation）: 同時に複数実⾏されるトランザクションは、互いに独⽴しており、 他のトランザクションの途中の操作結果に影響を受けません。 耐久性（Durability）: トランザクションが完了し、コミットが⾏われると、その結果は 永続的にデータベースに記録され、システム障害が発⽣しても保持されます。
32. 32 ©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 を探すだけで済む
33. 33 ©MIXI インデックスの種類 インデックスには複数の種類があります。⽤途に合わせて使い分けましょう。 B ツリーインデックス: ソートされたデータを保持し、検索、挿⼊、削除がログ時間で効率的に⾏える 主要な DBMS のデフォルトインデックス ⾼速な範囲検索が必要な場合に効果的 ビットマップインデックス: 低カーディナリティ（特定のカラムの値の種類が少ない）のデータに適している AND、OR、NOTなどのビット単位の論理演算が⾼速 データウェアハウスやデータ分析での使⽤が⼀般的で、集計クエリや複合クエリが多い場⾯で効果的 テキストインデックス: 単語に基づく索引を作成し、テキスト内の特定の語句や単語の出現を迅速に検出できる ⼤量の⾮構造化テキストデータを扱う場合に効率的 キーワードベースの検索が必要な場合に使⽤（ニュースサイト、ブログ、ドキュメント管理など）
34. 34 ©MIXI インデックスの⽋点 インデックスは検索時に有効な機能ですが、インデックスを作り過ぎると DBMS にとって負荷になります。 インデックスはテーブルとは別の特殊なテーブルに索引情報を格納しています。 テーブル内のレコードを追加‧削除するたびにインデックスを最新化しています。 インデックス最新化はコンピュートリソースを使うので、DBMS 全体のパフォーマンスに 影響を与える可能性があります。 また、インデックスもディスクスペースを消費することになります。 必要なインデックスだけを作る、使わなくなったインデックスは削除する、 ⽉に1度、半年に1度しか使わないインデックスなら使う前に作成、終わったら削除などの ⼯夫をすることをお勧めします。
35. 35 ©MIXI ビュー ビューは、それ⾃⾝はデータを持たない仮想テーブルです。 ⼀つまたは複数のテーブルに対するクエリ結果として定義され、実際のデータ複製を 保存せずに、特定のデータセットへのアクセスを提供します。 ▪ ビューの特徴 • 抽象化 ◦ 複雑な SELECT ⽂を打たずともユーザーが必要なデータを取得 • データアクセスの制限 ◦ テーブルの全データではなく、特定に列や⾏だけをユーザーに表⽰ • 便利性 ◦ 頻繁に使うクエリをビューで保存 • ロジックの中央化 ◦ ビジネスロジックが変更しても、ビューを変更すれば済む
36. 36 ©MIXI ビュー例 CREATE VIEW employee_department AS SELECT e.employee_name, d.department_name FROM employees e JOIN departments d ON e.department_id = d.department_id; SELECT * FROM employee_department; employee_name department_name Alice 営業部 Bob 開発部 Charlie 営業部 ビュー: employee_department department_id department_name D001 営業部 D002 開発部 テーブル: department employee_id employee_name department_id 1 Alice D001 2 Bob D002 3 Charlie D001 テーブル: employee
37. ©MIXI 第3章: SQL⼊⾨
38. 38 ©MIXI 第3章: SQL⼊⾨ 第3章では SQL の基礎を学びます。 SQL の操作分類、基本的な使い⽅と例⽂を説明します。
39. 39 ©MIXI SQL SQL はリレーショナルデータベースを操作するための⾔語として誕⽣しました。 「エス キュー エル」または「シークウェル」と発⾳します。 操作内容によって⼤きく3つの種別に分類されます。 • DDL（データ定義⾔語、Data Definition Language） • DML（データ操作⾔語、Data Manipulation Language） • DCL（データ制御⾔語、Data Control Language）
40. 40 ©MIXI DDL データベースの構造を定義するための⾔語です。 • create ◦ 新しいデータベース、テーブル、ビュー、インデックスなどを作成 • drop ◦ 存在するデータベース、テーブル、ビュー、インデックスなどを削除 • alter ◦ 存在するデータベース、テーブル、ビュー、インデックスなどを変更 • truncate ◦ テーブルからデータを削除、取り消せない
41. 41 ©MIXI DML データの検索‧新規登録‧更新‧削除を⾏う⾔語です。 • select ◦ 検索、クエリ。最も使われている SQL ⽂ではなかろうか • insert ◦ 新規登録 • update ◦ 既存データの更新 • delete ◦ 既存データの削除
42. 42 ©MIXI DCL データに対するアクセス制御を⾏う⾔語です。 • grant ◦ データベースユーザーに特定に操作（DDL、DML）権限を付与する • revoke ◦ データベースユーザーから権限を剥奪する
43. 43 ©MIXI クエリ（select） DBMS への処理要求をクエリと呼びます。 ほとんどのアプリケーションで最も頻繁に呼ばれるクエリは select ⽂です。 select ⽂はレコードを検索するための SQL ⽂です。 select ⽂は複数の要素で構成されています。これらを活⽤して欲しいレコードを検索します。 select 検索するテーブルの列を決めます from 検索する対象のテーブルを指定します、結合の⽅法を決めます where データをフィルタリングします group by 共通の列の値に基づいて⾏をグループ化します having グループをフィルタリングします order by 列に基づいて⾏を並び替える
44. 44 ©MIXI フィルタリング ほとんどのクエリは特定の⾏に焦点をあてたものです。 SELECT ⽂も UPDATE ⽂も DELETE ⽂も、フィルタリングするための WHERE 句を使えま す。 また、HAVING 句も同じくフィルタリング⽤途です。 WHERE 句は式と演算⼦を組み合わせて条件を作ります。 WHERE first_name = ʻBob’ first_name が Bob WHERE age > 20 20歳より上 WHERE age BETWEEN 40 AND 65 40歳から65歳 WHERE last_name LIKE ʻA%’ last_name が A で始まる WHERE city IN (ʻTokyo’, ʻChiba’, ʻKanagawa’) city が Tokyo,Chiba,Kanagawa の何れか
45. 45 ©MIXI 結合 第1章で正規化の説明をしました。複数に分解されたテーブルを再び1つにまとめるクエリ が結合です。 テーブル同⼠をリンクさせる共有の列を ON 句で指定します。 下の例は、よく使われる内部結合です。 EmployeeID Name CourseID 100001 AAA C101 100001 AAA C001 100002 BBB C201 100002 BBB C001 100003 CCC C301 100003 CCC C001 training CourseID CourseName TeacherID C001 セキュリティ T001 C101 会社法 T002 C201 Webデザイン T003 C301 DB基礎 T004 course Name CourseName AAA 会社法 AAA セキュリティ SELECT t.Name, c.CourseName FROM training t JOIN course c ON t.CourseID = c.CourseID WHERE t.NAME = ʻAAA’ ;
46. 46 ©MIXI 集合 UNION 句、INTERSECT 句、EXCEPT 句を使って複数のテーブルの集合を得ます。 A B C Table1 UNION Table2 → A,B,C Table1 INTERSECT Table2 → C Table1 EXCEPT Table2 → A (Table1 UNION Table2) EXCEPT (Table1 INTERSECT Table2) → A,B Table1 Table2
47. 47 ©MIXI グループ化と集計 データをビジネスで効率的に使⽤するためには、グループ化と集計が⽋かせません。 SQL にはそれらを⾏うためのクエリや関数が⽤意されています。 特定の列に基づいてグループ化するには GROUP BY 句を使います。 CustomerID AgeRange BuyUnit 1 20 100 2 30 150 3 40 300 4 20 200 5 50 150 6 30 400 CustomerBuy ▪ 年代別 来場者数 SELECT AgeRange, count(*) FROM CustomerBuy GROUP BY AgeRange ORDER BY AgeRange ; ▪ 平均購⼊額 SELECT AVG(BuyUnit) FROM CustomerBuy ; ※ 集計関数 MAX() : 集合内の最⼤値 MIX() : 集合内の最⼩値 AVG() : 集合内の平均値 SUM() : 集合内の合計 COUNT() : 集合内の値の個数
48. 48 ©MIXI サブクエリ 別のSQLクエリの中に埋め込まれたSQLクエリのことを、サブクエリと呼びます。 サブクエリは通常⼩括弧「()」で囲まれています。サブクエリを使うことで、 複雑なデータ抽出条件や分析を実現できます。 サブクエリを適切に⽤いることで、SQLの検索や分析をより強⼒かつ柔軟に実⾏できるよ うになります。 CustomerID AgeRange BuyUnit 1 20 100 2 30 150 3 40 300 4 20 200 5 50 150 6 30 400 CustomerBuy ▪ 平均購⼊⾦額を上回った CustomerID SELECT CustomerID FROM CustomerBuy WHERE BuyUnit > ( SELECT AVG(BuyUnit) FROM CustomerBuy ) ; ※ハイライトした部分がサブクエリ
49. 49 ©MIXI ストアドプロシージャ ストアドプロシージャとは、クエリなどをデータベースに保存し、必要に応じて呼び出し て実⾏することができるデータベースオブジェクトです。 このプロシージャは事前コンパイルされ、パラメータ化も可能で、複雑な処理や ビジネスロジックを効率的に実⾏させることができます。 ⾼速な実⾏が可能、アプリ側に複雑なロジックが不要、再利⽤が容易などのメリットが 多くある反⾯、DBMS 間の互換性はほぼ無いのでロックインは避けられません。 TABLEs DBMS Stored Procedure - 複雑な処理 - ビジネスロジック アプリ 呼び出す 結果を返す
50. ©MIXI ミニクイズ
51. 51 ©MIXI ミニクイズ 1 ACID 特性の正しい組み合わせを選んでください。 原⼦性（Atomicity） ⼀貫性（Consistency） 独⽴性（Isolation） 耐久性（Durability） トランザクションはお互いに独⽴しており 同時並⾏実⾏される他のトランザクションの影響を受けない トランザクション内の操作は⼀つの単位として扱われ ”全て成功” か ”全てなかったこと” の何れかです トランザクションは、データベースのルールに従い 正しいデータの状態でのみ変更を適⽤する コミットが⾏われるとトランザクションは 永続的に保存される
52. 52 ©MIXI ミニクイズ 2 以下の問に答えてください 1. テーブルの正規化はなぜ必要ですか？ 2. あるテーブルのあるレコードを検索するコードを書きましたが、 レスポンスがとても遅いことに気が付きました。何をすべきでしょうか？ 3. あるスーパーの1⽇の売上⾦額や在庫数の推移を集計したいと考えています。 データベースで⾏う対策にはどのようなものがありますか？
53. ©MIXI 第4章: ⾮リレーショナルデータベースの概観
54. 54 ©MIXI 前提知識 〜 スケールアップとスケールアウト 第4章に⼊る前に「スケール」という⾔葉だけ頭の⽚隅に置いてください。 以下はデータベースでの例です。 スケールアップ（垂直スケール） スケールアウト（水平スケール） 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
55. 55 ©MIXI NoSQL IoT や AI の急速な進歩によるビックデータ需要の⾼まり、SNS によるよりリアルタイムな データ処理などを受け、NoSQL の利⽤が広まっています。 ⾮リレーショナルなデータベースを NoSQL と呼んでいます。 第2章で⽰したような正規化や ACID 特性は、NoSQL では存在が薄くなります。 テーブル同⼠の関係をもって整合性などの優位点を発揮していた RDB と違い、 NoSQL の柔軟なスキーマは迅速で反復的な開発を可能とします。 NoSQL は⽔平⽅向へのスケールアウトが可能で、スパイクアクセスに対応しやすい設計に なっています。
56. 56 ©MIXI キーバリューストア キーとバリューのペアでデータが格納されるスキーマレスなデータベースです。 キーに直接アクセスすることで⾼速な読み書きを実現しています。 ⻑所 • シンプルな操作 ◦ API がシンプルで扱いやすい • パフォーマンス ◦ ⾼速なデータ構造 • 柔軟性 ◦ データモデルの変更が容易 • 拡張性 ◦ 分散アーキテクチャで⾼拡張性 短所 • 複雑なクエリが苦⼿ ◦ 複雑なクエリや JOIN は避ける • 弱い⼀貫性 ◦ 分散アーキテクチャのトレードオフ • トランザクション管理 ◦ 複雑なトランザクションなら RDB 代表的な製品 Redis, Memcached, etcd, Amazon DynamoDB, Cloud Datastore ユースケース セッション管理、キャッシュ、ショッピングカート、チャットなどのリアルタイム処理、など
57. 57 ©MIXI ドキュメント データはドキュメント（JSON、XML など）として格納されます。 ドキュメントが⼀纏めに格納されているため、⾼速な読み書きを実現します。 ⻑所 • 開発の効率化 ◦ アプリケーションのオブジェクトと似た データ構造 • スケーラビリティ ◦ 分散アーキテクチャで拡張性が⾼い • データ表現の豊かさ ◦ 複雑なデータ型やネスト構成が可能 • スキーマ変更の容易さ ◦ スキーマフリー 短所 • 集約操作が苦⼿ ◦ JOIN するような⽤途には向かない • トランザクションが限定的 ◦ トランザクション前提な⽤途ではない • 弱い⼀貫性 ◦ 分散アーキテクチャのトレードオフ 代表的な製品 MongoDB, Couchbase, Amazon DocumentDB, Cloud Firestore ユースケース CMS、商品カタログ、ユーザープロファイル、多様なデバイスから多様なデータを受信するケース
58. 58 ©MIXI ワイドカラム データはカラムファミリーまたはスーパーカラムと呼ばれる列の集合として格納されます。 カラムへの効率的なアクセスが可能で、⼤量のデータ書き込みと分析が得意です。 ⻑所 • ⼤規模データ運⽤ ◦ ペタバイト規模の分散処理 • 柔軟なデータモデル ◦ 動的なスキーマ変更が可能 • 能率的なストレージ活⽤ ◦ 使⽤されるカラムのみ保存される • ⾼速なクエリ ◦ カラムへのアクセスや集計が⾼速 短所 • 設計が複雑になりがち ◦ RDB とは異なるアプローチが必要 • 整合性が苦⼿ ◦ ⼀貫性はアプリで保証（したほうが良い） • 独⾃のクエリ ◦ 複雑なクエリや JOIN は苦⼿ 代表的な製品 Cassandra, Google Bigtable, Amazon Keyspaces, ScyllaDB ユースケース ビッグデータのリアルタイム処理、リコメンデーションエンジン、⼤量のイベントログ管理
59. 59 ©MIXI インメモリ データをメモリ上に配置し⾼速な読み書きを提供します。 ⻑所 • 処理速度の向上 ◦ ⾼スループット、低レイテンシー • スケーラビリティ ◦ ⽔平スケーリングに対応 短所 • コスト ◦ RAM はディスクに⽐べて⾼額 • データの揮発性 ◦ 電源喪失でデータは消える ◦ データ永続化処理が別途必要 • リソース制約 ◦ ディスクに⽐べるとリソース増が難しい 代表的な製品 Redis, Memcached, SAP HANA, Apache Ignite ユースケース キャッシュ、セッションストア、ゲームバックエンド、チャット
60. 60 ©MIXI タイムシリーズ 時系列データの扱いに特化したデータベースです。 時系列クエリの⾼速処理やリアルタイム分析を⾏います。 ⻑所 • 時系列処理のパフォーマンス ◦ 時系列の収集‧保存‧分析に特化 • データの洞察⼒ ◦ ⾼度な分析機能を有していることがほとんど • スケーラビリティ ◦ 分散アーキテクチャの利点 短所 • 汎⽤性は無い ◦ ⾮時系列データには向かない • クエリの制限 ◦ JOIN などの複雑なクエリは不向き • 特殊性 ◦ ニーズを満たすには条件がある 代表的な製品 InfluxDB, TimescaleDB, Amazon Timestream, Google Bigtable ユースケース IoT デバイスデータの収集、⾦融マーケット、メトリクス、ログ
61. 61 ©MIXI グラフ データエンティティがネットワーク状の関係を持ったデータの集まりです。 A は B の友達、B は C の友達、C は A の友達の友達、のようなイメージです。 ⻑所 • 関係性の深掘り ◦ ネットワーク状関係の探索が速い ◦ 深い関係でも把握しやすい • クエリの最適化 ◦ RDB の JOIN に⽐べてパフォーマンスが良い • 柔軟性と拡張性 ◦ 関係の追加が容易 短所 • ユースケースが限定的 • 運⽤の難易度 ◦ グラフが⼤きくなると維持管理が⼤変 • 学習の難易度 ◦ 専⾨的な知識が必要なことも 代表的な製品 Neo4j, Amazon Neptune, OrientDB ユースケース ソーシャルネットワーク、リコメンデーションエンジン、ナレッジマネジメント、⽣物学的ネットワークモデル
62. 62 ©MIXI NewSQL 古くから広く使われてきた RDB ですが、⽔平スケールに難点がありました。 モダンなアプリケーションは、短時間でアクセスが増えることが当たり前に発⽣し、 スケーラビリティの問題が頭痛の種でした。 Google が RDBMS の特性を維持しつつ、スケーラビリティも兼ね備える Google Spanner をリリースしました。 これに影響‧刺激を受けるように TiDB、CockroachDB などの製品がリリースされまし た。
63. 63 ©MIXI NewSQL NewSQLは、リレーショナルデータベースの利点を維持しつつ、モダンな分散システムアーキテクチャ のスケーラビリティとパフォーマンスを兼ね備えたソリューションです。 ⻑所 • スケーラビリティ ◦ 分散アーキテクチャの利点 • ⾼いトランザクション性能 ◦ トランザクション処理の実現 • 強⼒なデータ整合性 ◦ ACID 特性の維持 • リレーショナルデータモデル ◦ 既存データモデルの活⽤ 短所 • 複雑性 ◦ DBMS の管理が難しくなりがち • 成熟度 ◦ まだ新しい技術 • 既存からの移⾏ ◦ 移⾏にかかるコストは無視できない 代表的な製品 Google Spanner, TiDB, CockroachDB ユースケース ⾦融取引、eコマース、ゲーム、ソーシャルネットワーク
64. ©MIXI 第5章: データウェアハウスとデータレイク
65. 65 ©MIXI 第5章: データウェアハウスとデータレイク 現代は膨⼤なデータを扱わなければならない時代です。 データを溜め込み、分析し、会社や組織に必要な情報だけを必要なタイミングで 加⼯‧表⽰する技術が求められます。 第5章ではその基本となるデータウェアハウスとデータレイクを解説します。
66. 66 ©MIXI データレイク データレイクは、様々なソースから収集された⽣の形式のデータを、 ⼤きなスケールで格納し、分析のために利⽤できるようにする、 汎⽤性の⾼いデータストレージソリューションです。 構造化（DB など）、半構造化（CSV、JSON など）、⾮構造化（テキスト、画像など）の 多様なデータを格納できます。 ⾮常に⼤規模なデータを格納できる設計となっています。 ⼀般的に低コストのストレージソリューションを⽤いて構成されているため、 ⾼いコスト効率が特徴です。 データウェアハウスで分析を⾏う前のデータ保管場所に使われることもあります。
67. 67 ©MIXI データウェアハウス データウェアハウスは、組織の様々なシステムやソースから集められた⼤量のデータを 統合、集約し、分析やレポーティングのために⻑期にわたって保管される中央集権型の データストレージシステムです。 DWH と略して呼ばれることが⼀般的です。 DWH を提唱した William H.Inmon ⽒は 「意思決定のために、⽬的別ごとに編成され、統合化された時系列で、更新処理をしない データの集まり」 と定義しています。
68. 68 ©MIXI データウェアハウスの特徴 サブジェクト指向: データウェアハウスはテーマごとにデータを整理し、たとえば「販売」「⼈事」といったビジネスプロセスに 基づいてデータを構築します。 ⾮揮発性: ⼀度データウェアハウスに取り込まれたデータは、主に読み取り専⽤であり、定期的に更新や変更を 受けることはありません。 時系列性: データは時間を通じて記録され、時間の経過と共に変化するビジネスプロセスを分析するための歴史的データ が含まれます。 統合性: さまざまなソースからのデータを統⼀的なフォーマットや規約に整理して保管します。 クエリの最適化: データは主に分析のためにアクセスされるため、⼤規模なクエリとレポートを効率的に実⾏するよう 最適化されています。
69. 69 ©MIXI データウェアハウスの活⽤事例 1. ビジネスインテリジェンス (BI) 2. 顧客関係管理 (CRM) 3. サプライチェーン管理 4. 財務分析 5. マーケット分析
70. 70 ©MIXI データマート データマートは、特定のビジネスユニットや部署向けに特化され、必要なデータのみを 集約するデータウェアハウスのサブセットです。 これは、特定の主題領域や部⾨にフォーカスを当てたデータベースとして機能し、 必要なビジネスインテリジェンス（BI）活動をサポートするために使われます。 データウェアハウスで収集‧分析されたデータのうち、必要な情報だけをクエリし 意思決定を促進するための重要なツールとして機能します。 データウェアハウスに依存しない独⽴型データマートも存在します。
71. 71 ©MIXI データカタログ データカタログは、組織内のさまざまなデータアセットに関する情報を収集し、 インデックス付けし、カタログ化するツールやシステムです。 データカタログはメタデータ管理を強化し、データの発⾒、理解、アクセスを容易にする ことを⽬的としています。 巨⼤な百貨店に⾏ったことを想像してください。 ⽬的の商品が何階のどのエリアにあるかは不明です。 百貨店が⽤意しているショッピングカタログを⾒るとそれが判ります。 データカタログも同じ役割です。データウェアハウスやデータレイクの膨⼤なデータから 欲しい情報までたどり着くためのツールだと思ってください。
72. 72 ©MIXI データウェアハウスとデータレイク 構成例 DB Files Images Movies IoT Social データレイク ⾮構造化データ 半構造化データ データウェアハウス 構造化データ 変換、ロード データマート or データカタログ AI BI
73. ©MIXI 演習
74. 74 ©MIXI 演習 こちらのリポジトリをクローンしてください。 https://github.com/mixigroup/2024BeginnerTrainingDataBaseBasic
75. 75 ©MIXI 時間割 10:30〜10:45 ⾃⼰紹介（お互い） 10:45〜11:35 1〜3章 11:35〜11:45 休憩 11:45〜12:45 4〜5章 12:45〜13:45 休憩 13:45〜14:45 6〜8章 14:45〜14:50 中締め
76. ©MIXI 第6章: クラウド上のデータベースサービス
77. 77 ©MIXI 第6章: クラウド上のデータベースサービス 主要なクラウドベンダーはマネージドなデータベースサービスを提供しています。 今までに紹介したようなリレーショナル、NoSQL、NewSQL も使うことが可能です。 それらデータベースサービスを紹介しつつ、特性についても解説します。
78. 78 ©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 for Redis ドキュメント コンテンツ管理、カタログ、ユーザープロファイル Amazon DocumentDB (MongoDB 互換) ワイドカラム ⾼スケールの業界アプリケーション、設備のメンテナンス、多数の装置の管理、ルートの最適化 Amazon Keyspaces グラフ 不正検出、ソーシャルネットワーク、レコメンデーションエンジン Amazon Neptune タイムシリーズ モノのインターネット (IoT) アプリケーション、DevOps、産業⽤テレメトリ Amazon Timestream レジャー 記録システム、サプライチェーン、銀⾏トランザクション Amazon 台帳データベースサービス (QLDB)
79. 79 ©MIXI Google Cloud データベース https://cloud.google.com/products/databases?hl=ja より データベースの種類 GOOGLE CLOUD サービス ユースケースの例 リレーショナル Cloud SQL CRM、ERP、e コマースとウェブ、SaaS アプリケーション AlloyDB for PostgreSQL 異種環境間の移⾏、レガシー アプリケーション、エンタープライズ ワークロード、 ハイブリッド クラウド、マルチクラウド、エッジ Spanner ゲーム、⼩売、グローバルの財務元帳、サプライ チェーン / 在庫管理 Oracle 向け Bare Metal Solution マルチクラウド分析、リアルタイム処理、組み込みの ML Key-Value Bigtable パーソナライズ、アドテック、レコメンデーション エンジン、不正⾏為の検出 ドキュメント Firestore モバイル / ウェブ / IoT アプリケーション、リアルタイム同期、オフライン同期 Firebase Realtime Database モバイル ログイン、パーソナライズしたアプリケーションと広告、アプリ内チャット インメモリ Memorystore キャッシュ、ゲーム、リーダーボード、ソーシャル チャットまたはニュース フィード その他の NoSQL MongoDB Atlas モバイル / ウェブ / IoT アプリケーション、ゲーム、コンテンツ管理、シングルビュー Google Cloud Partner Services 既存の投資を活⽤
80. 80 ©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 より
81. 81 ©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 より
82. 82 ©MIXI グローバル展開 グローバル展開しやすいこともクラウドデータベースの特徴です。 世界中のユーザー ⽇本 北⽶ App DB ⽇本のリージョン App DB 北⽶のリージョン スマホとサーバーは 距離的、NW 的に 近いほうが ユーザー体験が良い グローバルスマホアプリの省略図 App と DB も 近いほうが パフォーマンスが良い DB のレプリケーションが必要 - マネージドサービスを使う - ⾃前でレプリケーションする - スキーマ設計を⼯夫する ※ 参考資料：『家族アルバム みてね』 AWSマルチリージョン構成における データベース運用
83. 83 ©MIXI スケーラビリティ 第4章で紹介したスケールアップ/スケールアウトでは、インスタンスのサイズや数を 増やすことで性能を向上させていました。 クラウドデータベースのなかには、スループットに応じて性能を変化するサービスがあります。 ユーザーアクセスを予測しにくい Web サービスに最適な⽅式です。 Amazon DynamoDB の場合 https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/CostOptimization_TableCapacityMode.html より オンデマンドキャパシティモード テーブルへのリクエスト量に応じて性能が変わります。 次のようなケースで使います。 • リクエストの増減が予測できない • リクエスト量が流動的、波が激しい プロビジョンドキャパシティモード 性能を管理者が決めます。または、AutoScaling を使います。 次のようなケースで使います。 • リクエスト予測が可能、周期的 • リクエスト増減が限定的
84. 84 ©MIXI 料⾦ 商⽤サービスを開発していくにあたり、”コストへの考慮” は避けて通れません。 パフォーマンスが悪いからといってスケールアウト/アップを単純に⾏うと請求で苦しむことになります。 クラウドデータベースの料⾦特性を理解して使うようにしましょう。 料⾦発⽣要素 例 (AWS) ▪ Aurora （リレーショナル） インスタンスサイズと台数 ストレージ容量 I/O 発⽣量 バックアップストレージ容量 データ転送量 その他オプションの選択 ▪ DynamoDB （Key-Value） ※ オンデマンドモード 書き込みリクエスト量 読み込みリクエスト量 ストレージ容量 バックアップストレージ容量 リストアしたテーブル容量 データ転送量 その他オプションの選択 ▪ ElastiCache （インメモリ） ※ オンデマンド ノードサイズと台数 バックアップ容量 データ転送量 その他オプションの選択
85. 85 ©MIXI クラウドデータベースサービスの注意点 モダンな開発ではクラウドデータベースの利⽤が当たり前ですが、注意点もあります。 • コントロールできないクラウドベンダーによるメンテナンス ◦ 機器⽼朽化の対応による再起動 ◦ セキュリティパッチの適⽤による再起動 ◦ マイナーバージョンアップによる再起動 • DBMS バージョンのサポート ◦ 古いバージョンはサポートが終わると使えなくなる ◦ 新しいバージョンへのアップグレードを計画 • 何事も100%ではない ◦ 予期しないフェールオーバー（障害でインスタンスが切り替わること） ◦ 瞬間的なエラー ◦ トレンド⼊りするような⼤規模障害
86. ©MIXI 第7章: データベースの選定とアーキテクチャ
87. 87 ©MIXI データベース選定⽅法 まず⼀番に考えるのは⽬的やビジネス要件に合致しているかどうかです。 第4章では NoSQL、NewSQL を紹介しました。第6章ではクラウドデータベースを 紹介しました。そこでユースケースや⻑所短所を解説しています。 振り返ってみて選定⽅法を考えてみましょう。 次のページには選択に役⽴つ質問を引⽤しました。選定に迷った際に参考になります。 それでも判断がつかない場合は、PoC を実施します。 本番以外の環境で候補のデータベースを構築し、実施にアプリケーションを動作しながら テストと計測を⾏います。
88. 88 ©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 より
89. 89 ©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 を使って 友達が購⼊したものからオススメを⽣成します。
90. 90 ©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
91. 91 ©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 ## パラメータ ## レスポンス ### 成功時 ### 失敗時 ## リクエストサンプル ## レスポンスサンプル
92. 92 ©MIXI コネクションと RDS Proxy アプリケーションから RDB へクエリを発⾏するためにコネクションを張ります。 サーバーレスアプリケーションの場合、多数並列的に起動されるファンクション数だけコネクションが 必要となります。 DBMS 観点だとコネクションはリソースを消費します。過剰なコネクションはそれだけでDBMS の負荷と なり、全体的なレスポンスを遅くする可能性があります。 RDS Proxy はアプリケーションと DBMS の間に⼊り、コネクションプーリングの役割を果たします。 DB Cluster RDS Proxy 無し ファンクション数の コネクションが必要 RDS Proxy 有り DB Cluster Many Functions Many Functions ファンクションは 多数並列的に起動 プールしている コネクションのうち Available のものを使う Proxy がコネクションを 肩代わりするイメージ
93. 93 ©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 より
94. 94 ©MIXI シャーディング アーキテクチャの話を少しずれるかもしれませんが、⼤事なテクニックを紹介します。 シャーディングは、⼤規模なデータベースを⼩さな、扱いやすい部分に分割するプロセスです。 これにより、データベースのスケーラビリティとパフォーマンスが向上し、特に書き込みや読み込みの多い アプリケーションにおいて、データ管理の効率を⾼めます。 ⾏No. 名前 1 Alice ‧‧‧ ‧‧‧ 100万 Bob 名前が A〜I 名前が J〜S 名前が T〜Z ▪ 主なシャーティングの種類 □ 範囲ベース 値の範囲に基づいて分割します。（左の例） □ ハッシュ ハッシュ関数を使って⾏にシャードキーを付与 シャードキーで分割します。 □ ディレクトリ ルックアップテーブルを使⽤して、 どのシャードにデータが存在するかを追跡します。
95. 95 ©MIXI 分散システムでのトランザクション 単⼀ DBMS のコミット‧ロールバックはそこまで難しくありません。 ただ、現在のシステムはほとんどが分散システムとなっています。 各マイクロサービスが他と連携しながらロールバックをするような実装にします。 トランザクション 決済App ポイントApp 発送App ポイントDB 発送DB 決済API ECサイトで 買い物をする 在庫App 在庫DB
96. 96 ©MIXI 分散システムでのロールバック トランザクション 決済App ポイントApp 発送App ポイントDB 発送DB 決済API ECサイトで 買い物をする 在庫App 在庫DB 在庫引当 クレカ 決済 ポイント 付与 エラー！！ ロールバック 決済App ポイントApp 在庫App ポイント 減算 クレカ 返⾦ 補充
97. ©MIXI 第8章: セキュリティとデータガバナンス
98. 98 ©MIXI データベースのセキュリティ 第8章ではデータベース内のデータを不正アクセス、損傷、盗難、漏えいから保護するための 対策を紹介します。 ⼀般的にデータベースに格納しているデータの多くは機密性が⾼く、 個⼈情報や財務情報などのデータを含んでいることが多いので、 データベースのセキュリティは極めて重要です。 セキュリティは継続的なプロセスであり、全員参加です。 新たな脅威に対応するために定期的に⾒直しと強化が必要です。 また、データ保護規制や業界基準に準拠することも、データベースセキュリティの 重要な側⾯です。
99. 99 ©MIXI データベースセキュリティの主要概念 • 認証 ◦ ユーザーがデータベースにアクセスする前に、正しい認証資格を持っていることを 要求します。パスワード認証などが代表です。 • 認可 ◦ 認証されたユーザーに対して、特定リソースへのアクセスを許可‧拒否します。 • アクセス制御 ◦ ユーザーが実⾏できる操作の種類（読み取り、書き込み、更新、削除など）を定義します。 • 暗号化 ◦ 通信時、保管時にデータを暗号化し、不正な盗聴⾏為を防⽌します。 • 監査 ◦ データベースのアクセスログや操作ログを監視し、不審な活動やポリシー違反を検知します。 • データマスキング ◦ 本番環境以外でデータを使う際には、機密データを隠蔽（ダミーに変える）します。 • バックアップ‧リストア ◦ データ損失やデータ損害時に早期の回復をするためにバックアップを取得します。
100. 100 ©MIXI クラウドの認証 古くからデータベースの認証はパスワードが利⽤されてきました。 ただ、アプリケーションに何らかの形でパスワードを持たす⽅式は、漏洩の可能性を排除できません。 クラウドではシークレットストアを使ってパスワードを保管するようにしましょう。 DB App Secrets Store (1) App から Secrets Store にパスワード問い合わせ (2) 許可された App から許可された操作だった場合、 Secrets Store はパスワードを返す (3) App は返されたパスワードでデータベース認証を⾏う ▪ メリット - 開発者がパスワードを知る必要が無い - パスワードの保護をクラウドの IAM で⼀元管理できる - 定期的なパスワード変更を容易に実装できる - パスワード管理をクラウドベンダーにオフロードできる (1) (3) (2)
101. 101 ©MIXI ネットワークの制限 データベースは機密データの集まりです。 データベースにアクセスできるアプリケーション、ユーザーをネットワーク的に制限します。 クラウド データベースサブネット 管理サブネット パブリックサブネット DB App-A App-B Management クラウド外からのアクセスは拒否 App-A からのアクセスは許可 App-B からのアクセスは拒否 Management からのアクセスは許可 社内管理者
102. 102 ©MIXI 最⼩権限の原則 ネットワーク的な制限はかけました。次はデータベースの権限を制限します。 DBMS の権限では、どのテーブルに対してどの操作（INSERT、DELETE、UPDATE など）を 許可するか、という設定を⾏います。 この権限設定は少しだけ難しいので、アプリケーションユーザーに強い権限（全テーブルに全操作OK）を 付与してしまうことが残念ながら多くあります。それはアンチパターンです。 必要な権限だけを付与するようにしましょう。 クラウド データベースサブネット 管理サブネット パブリックサブネット DB App-A Management App-A にはアプリケーションで使うテーブルに INSERT,UPDATE,DELETE,SELECT を付与 アプリケーションに関係ないテーブルには アクセスさせない 社内管理者 管理者が強い権限を使う場合は 社内ワークフローで承認をもらう 作業時は複数⼈で⾏う
103. 103 ©MIXI セキュリティパッチの適⽤ セキュリティパッチは、ソフトウェアやシステムのセキュリティ上の脆弱性を修正するアップデートです。 セキュリティパッチを定期的に適⽤することは、サイバーセキュリティ戦略の基本的かつ重要な部分であり、 攻撃者がシステムを侵害する⼿段を最⼩限に抑えるために必須の習慣です。 そのためには、セキュリティパッチがリリースされ次第、迅速に適⽤することが勧められます。 また、それらの適⽤を継続的に監視し、セキュリティ対策を最新の状態に保つためのパッチ管理ポリシーを 確⽴することが重要です。 クラウドベンダーのマネージドデータベースを使っている場合、セキュリティパッチはクラウドベンダーに よって管理されます。適⽤の内容やタイミングは事前に通知されます。 その通知を⾒て適⽤タイミングを決定し、決⾏します。 セキュリティパッチはデータベースクライアント（アプリケーションなど）にも提供されるケースがありま す。その際には、データベースクライアントにも同じ様に適⽤しましょう。
104. 104 ©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 になってしまいログインされてしまう
105. 105 ©MIXI SQL インジェクションの対策 SQL インジェクションは対策⽅法が開⽰されています。 アプリケーションで必ず対策を⾏いましょう。 • SQL⽂の組み⽴ては全てプレースホルダで実装する。 • SQL⽂の組み⽴てを⽂字列連結により⾏う場合は、 エスケープ処理等を⾏うデータベースエンジンのAPIを⽤いて、SQL⽂のリテラルを正しく構成する。 • ウェブアプリケーションに渡されるパラメータにSQL⽂を直接指定しない。 • SQL インジェクションに対応したフレームワークを使う。 • 前段のロードバランサー等に WAF を設置する。 https://www.ipa.go.jp/security/vuln/websecurity/sql.html より
106. ©MIXI ミニクイズ
107. 107 ©MIXI ミニクイズ 3 次の問に答えてください。 1. データベースへの書き込みより読み込みが多いシステムがあります。 クラウドデータベースで実施できる対策を教えてください。 2. ゲーム内で当⽇の成績 Top10 を表⽰するスコアボードを作ろうとしています。 採⽤するデータベースとデータの更新⽅法を考えてください。 3. 新しいプロダクトの⽴ち上げに参加しました。アーキテクチャを検討した結果、 データベースの採⽤に2つの選択肢があります。 最終決定を下すためにすることは何でしょう？
108. 108 ©MIXI ミニクイズ 4 次の問に 正 or 誤 で答えてください。理由も説明してください。 1. ソースコードは厳重に管理しており安⼼なので、 データベースパスワードはコード内に書いた。 2. どうしても動かないロジックがあり、デバッグ⽬的で管理者権限を使って データベースを操作した。 3. セキュリティチェックはセキュリティチームの仕事なので、彼らを信頼し、 とにかく動くことを優先してコードを書いた。 4. プログラム開発で使っているツールに脆弱性が⾒つかりパッチが公開された。 セキュリティチームの案内に従ってツールにパッチを適⽤した。
109. ©MIXI 演習
110. 110 ©MIXI 演習 こちらのリポジトリをクローンしてください。（第4章と同じです） https://github.com/mixigroup/2024BeginnerTrainingDataBaseBasic
111. ©MIXI 中締め
112. 112 ©MIXI お疲れ様でした ご清聴ありがとうございました
113. ©MIXI