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

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

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

3 ©MIXI 本⽇の内容第1章: データベースの基本概念第2章: リレーショナルデータベースの深掘り第3章: SQL⼊⾨第4章:
⾮リレーショナルデータベースの概観第5章: データウェアハウスとデータレイク第6章: クラウド上のデータベースサービス第7章: データベースの選定とアーキテクチャ第8章: セキュリティとデータガバナンス

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

自己紹介タイム

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

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

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

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

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

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

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

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

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

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

©MIXI 第2章: リレーショナルデータベースの深掘り

19 ©MIXI 第2章: リレーショナルデータベースの深掘り第2章ではリレーショナルデータベースを解説します。リレーショナルデータベースの歴史は古く、昔から多くのシステムで利⽤されています。現代の Web アプリケーションではそれ以外のデータベースの利⽤が増えていますが、それでもリレーショナルデータベースが完全に無くなる可能性は低いと考えます。
テーブルの正規化、トランザクション、ACID 特性、インデックス、ビューといったリレーショナルデータベースの特徴的な機能や設計⽅法を学びます。

20 ©MIXI テーブルテーブル列/属性⾏/レコードデータが格納されている構造的な領域です。⾏と列で構成されています。

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 ©MIXI リレーショナルそもそも「リレーショナル」データベースとは何でしょうか？ Edgar F. Codd ⽒は「⼤規模共有データ‧バンクのためのデータのリレーショナル‧モデル」というという論⽂のなかで、タプル（属性と値のペア）として意味のある関係に基づいてデータを配置することを提案しました。
リレーショナル‧モデルでは、共通の属性を使⽤して任意のテーブルを別のテーブルに関連付けることができます。また、リレーショナル‧モデルでは、論理データ構造（データテーブル、ビュー、およびインデックス）が物理記憶域構造とは別になっています。たとえば、データベースが保存されているファイル名を変更しても、そのファイルに格納されているテーブルには影響がありません。

23 ©MIXI 正規化リレーショナルデータベースにおけるテーブルの正規化は、データ構造を最適化し、冗⻑性を排除してデータの整合性を向上させるプロセスです。データの重複をなくして、データの整合性を保持します。挿⼊、更新、削除の操作で予期せぬデータの不整合が起こることを防ぎます。冗⻑なデータを減らすことで、検索‧処理のパフォーマンスを向上させます。

24 ©MIXI 正規化のステップ第1正規化（1NF）: 同じ⾏内での繰り返しを無くす、かつ、 Primary Key（主キー）を持つ第2正規化（2NF）: 1NF を満たし、かつ、完全関数従属が満たされた状態
第3正規化（3NF）: 2NF を満たし、かつ、推移的関数従属が解決された状態これ以降にも、ボイス＝コッド正規形 (BCNF)、4NF、5NF などがありますが割愛します。関係関数従属 A が決まると B が決まる状態（例）会社名→代表者、本社住所、連絡先 | 商品名→販売価格部分関数従属主キーの⼀部で⾮主キーの値が決まる状態（主キーが分割しきれていない）完全関数従属すべての⾮主キーの値が主キーによって決まる状態推移的関数従属 A が決まると B が、B が決まると C が決まる状態（例）⽣徒名→受講コース→講師名

25 ©MIXI 正規化されていないテーブル社員ID 名前受講コース講師名 100001 AAA 会社法、セキュリティ
XXX、WWW 100002 BBB Webデザイン、セキュリティ YYY、WWW 100003 CCC DB基礎、セキュリティ ZZZ、WWW 例）新卒研修テーブル

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 ©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 ©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 ©MIXI あえて正規化しないケース正規化プロセスは、冗⻑性の排除とデータの整合性の向上を⽬的としていますが、パフォーマンスや特定のアプリケーション要件に基づいて正規化をあえて⾏わないケースがいくつか存在します。 • パフォーマンスの最適化 ◦ 単⼀のクエリで必要なデータを取得したい
• 頻繁な JOIN の回避 ◦ DBMS にとって JOIN はコストが⾼いので JOIN 回数を抑えたい • 特定のアクセスパターン ◦ 特定のデータアクセスがパターン化されているので⾮正規化のほうが良い • リアルタイム処理 ◦ 限りなくリアルタイムに近い処理が必要

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

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

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 ©MIXI インデックスの種類インデックスには複数の種類があります。⽤途に合わせて使い分けましょう。 B ツリーインデックス: ソートされたデータを保持し、検索、挿⼊、削除がログ時間で効率的に⾏える主要な DBMS のデフォルトインデックス
⾼速な範囲検索が必要な場合に効果的ビットマップインデックス: 低カーディナリティ（特定のカラムの値の種類が少ない）のデータに適している AND、OR、NOTなどのビット単位の論理演算が⾼速データウェアハウスやデータ分析での使⽤が⼀般的で、集計クエリや複合クエリが多い場⾯で効果的テキストインデックス: 単語に基づく索引を作成し、テキスト内の特定の語句や単語の出現を迅速に検出できる⼤量の⾮構造化テキストデータを扱う場合に効率的キーワードベースの検索が必要な場合に使⽤（ニュースサイト、ブログ、ドキュメント管理など）

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

35 ©MIXI ビュービューは、それ⾃⾝はデータを持たない仮想テーブルです。⼀つまたは複数のテーブルに対するクエリ結果として定義され、実際のデータ複製を保存せずに、特定のデータセットへのアクセスを提供します。 ▪ ビューの特徴 • 抽象化
◦ 複雑な SELECT ⽂を打たずともユーザーが必要なデータを取得 • データアクセスの制限 ◦ テーブルの全データではなく、特定に列や⾏だけをユーザーに表⽰ • 便利性 ◦ 頻繁に使うクエリをビューで保存 • ロジックの中央化 ◦ ビジネスロジックが変更しても、ビューを変更すれば済む

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

©MIXI 第3章: SQL⼊⾨

38 ©MIXI 第3章: SQL⼊⾨第3章では SQL の基礎を学びます。 SQL の操作分類、基本的な使い⽅と例⽂を説明します。

39 ©MIXI SQL SQL はリレーショナルデータベースを操作するための⾔語として誕⽣しました。「エスキューエル」または「シークウェル」と発⾳します。操作内容によって⼤きく3つの種別に分類されます。 •
DDL（データ定義⾔語、Data Deﬁnition Language） • DML（データ操作⾔語、Data Manipulation Language） • DCL（データ制御⾔語、Data Control Language）

40 ©MIXI DDL データベースの構造を定義するための⾔語です。 • create ◦ 新しいデータベース、テーブル、ビュー、インデックスなどを作成 • drop
◦ 存在するデータベース、テーブル、ビュー、インデックスなどを削除 • alter ◦ 存在するデータベース、テーブル、ビュー、インデックスなどを変更 • truncate ◦ テーブルからデータを削除、取り消せない

41 ©MIXI DML データの検索‧新規登録‧更新‧削除を⾏う⾔語です。 • select ◦ 検索、クエリ。最も使われている SQL ⽂ではなかろうか
• insert ◦ 新規登録 • update ◦ 既存データの更新 • delete ◦ 既存データの削除

42 ©MIXI DCL データに対するアクセス制御を⾏う⾔語です。 • grant ◦ データベースユーザーに特定に操作（DDL、DML）権限を付与する • revoke
◦ データベースユーザーから権限を剥奪する

43 ©MIXI クエリ（select） DBMS への処理要求をクエリと呼びます。ほとんどのアプリケーションで最も頻繁に呼ばれるクエリは select ⽂です。 select ⽂はレコードを検索するための
SQL ⽂です。 select ⽂は複数の要素で構成されています。これらを活⽤して欲しいレコードを検索します。 select 検索するテーブルの列を決めます from 検索する対象のテーブルを指定します、結合の⽅法を決めます where データをフィルタリングします group by 共通の列の値に基づいて⾏をグループ化します having グループをフィルタリングします order by 列に基づいて⾏を並び替える

44 ©MIXI フィルタリングほとんどのクエリは特定の⾏に焦点をあてたものです。 SELECT ⽂も UPDATE ⽂も DELETE ⽂も、フィルタリングするための
WHERE 句を使えます。また、HAVING 句も同じくフィルタリング⽤途です。 WHERE 句は式と演算⼦を組み合わせて条件を作ります。 WHERE ﬁrst_name = ʻBob’ ﬁrst_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 ©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 ©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 ©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 ©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 ©MIXI ストアドプロシージャストアドプロシージャとは、クエリなどをデータベースに保存し、必要に応じて呼び出して実⾏することができるデータベースオブジェクトです。このプロシージャは事前コンパイルされ、パラメータ化も可能で、複雑な処理やビジネスロジックを効率的に実⾏させることができます。⾼速な実⾏が可能、アプリ側に複雑なロジックが不要、再利⽤が容易などのメリットが多くある反⾯、DBMS 間の互換性はほぼ無いのでロックインは避けられません。
TABLEs DBMS Stored Procedure - 複雑な処理 - ビジネスロジックアプリ呼び出す結果を返す

©MIXI ミニクイズ

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

52 ©MIXI ミニクイズ 2 以下の問に答えてください 1. テーブルの正規化はなぜ必要ですか？ 2. あるテーブルのあるレコードを検索するコードを書きましたが、レスポンスがとても遅いことに気が付きました。何をすべきでしょうか？
3. あるスーパーの1⽇の売上⾦額や在庫数の推移を集計したいと考えています。データベースで⾏う対策にはどのようなものがありますか？

©MIXI 第4章: ⾮リレーショナルデータベースの概観

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

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

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

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

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

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

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

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

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

©MIXI 第5章: データウェアハウスとデータレイク

65 ©MIXI 第5章: データウェアハウスとデータレイク現代は膨⼤なデータを扱わなければならない時代です。データを溜め込み、分析し、会社や組織に必要な情報だけを必要なタイミングで加⼯‧表⽰する技術が求められます。第5章ではその基本となるデータウェアハウスとデータレイクを解説します。

66 ©MIXI データレイクデータレイクは、様々なソースから収集された⽣の形式のデータを、⼤きなスケールで格納し、分析のために利⽤できるようにする、汎⽤性の⾼いデータストレージソリューションです。構造化（DB など）、半構造化（CSV、JSON など）、⾮構造化（テキスト、画像など）の多様なデータを格納できます。
⾮常に⼤規模なデータを格納できる設計となっています。⼀般的に低コストのストレージソリューションを⽤いて構成されているため、⾼いコスト効率が特徴です。データウェアハウスで分析を⾏う前のデータ保管場所に使われることもあります。

67 ©MIXI データウェアハウスデータウェアハウスは、組織の様々なシステムやソースから集められた⼤量のデータを統合、集約し、分析やレポーティングのために⻑期にわたって保管される中央集権型のデータストレージシステムです。 DWH と略して呼ばれることが⼀般的です。 DWH を提唱した
William H.Inmon ⽒は「意思決定のために、⽬的別ごとに編成され、統合化された時系列で、更新処理をしないデータの集まり」と定義しています。

68 ©MIXI データウェアハウスの特徴サブジェクト指向: データウェアハウスはテーマごとにデータを整理し、たとえば「販売」「⼈事」といったビジネスプロセスに基づいてデータを構築します。⾮揮発性: ⼀度データウェアハウスに取り込まれたデータは、主に読み取り専⽤であり、定期的に更新や変更を受けることはありません。時系列性:
データは時間を通じて記録され、時間の経過と共に変化するビジネスプロセスを分析するための歴史的データが含まれます。統合性: さまざまなソースからのデータを統⼀的なフォーマットや規約に整理して保管します。クエリの最適化: データは主に分析のためにアクセスされるため、⼤規模なクエリとレポートを効率的に実⾏するよう最適化されています。

69 ©MIXI データウェアハウスの活⽤事例 1. ビジネスインテリジェンス (BI) 2. 顧客関係管理 (CRM) 3.
サプライチェーン管理 4. 財務分析 5. マーケット分析

70 ©MIXI データマートデータマートは、特定のビジネスユニットや部署向けに特化され、必要なデータのみを集約するデータウェアハウスのサブセットです。これは、特定の主題領域や部⾨にフォーカスを当てたデータベースとして機能し、必要なビジネスインテリジェンス（BI）活動をサポートするために使われます。データウェアハウスで収集‧分析されたデータのうち、必要な情報だけをクエリし意思決定を促進するための重要なツールとして機能します。データウェアハウスに依存しない独⽴型データマートも存在します。

71 ©MIXI データカタログデータカタログは、組織内のさまざまなデータアセットに関する情報を収集し、インデックス付けし、カタログ化するツールやシステムです。データカタログはメタデータ管理を強化し、データの発⾒、理解、アクセスを容易にすることを⽬的としています。巨⼤な百貨店に⾏ったことを想像してください。⽬的の商品が何階のどのエリアにあるかは不明です。百貨店が⽤意しているショッピングカタログを⾒るとそれが判ります。
データカタログも同じ役割です。データウェアハウスやデータレイクの膨⼤なデータから欲しい情報までたどり着くためのツールだと思ってください。

72 ©MIXI データウェアハウスとデータレイク構成例 DB Files Images Movies IoT Social
データレイク⾮構造化データ半構造化データデータウェアハウス構造化データ変換、ロードデータマート or データカタログ AI BI

©MIXI 演習

74 ©MIXI 演習こちらのリポジトリをクローンしてください。 https://github.com/mixigroup/2024BeginnerTrainingDataBaseBasic

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 中締め

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

©MIXI ミニクイズ

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

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

©MIXI 演習

©MIXI 中締め

©MIXI

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

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

More Decks by MIXI ENGINEERS

Other Decks in Technology

Featured

Transcript