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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

自己紹介タイム

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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（重複は許容しない）の制約があります。

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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 や名前が決まらないと⾏を増やせない

Slide 27

Slide 27 text

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 受講コーステーブル困ること: 社員がいなくても新しい受講コースを増やせるようになったけど、将来のために講師だけ増やしたい（受講コーステーブルに講師名を⾜したい）ときに困る

Slide 28

Slide 28 text

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 講師テーブル

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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 を探すだけで済む

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

©MIXI 第3章: SQL⼊⾨

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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 の何れか

Slide 45

Slide 45 text

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’ ;

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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() : 集合内の値の個数

Slide 48

Slide 48 text

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 ) ; ※ハイライトした部分がサブクエリ

Slide 49

Slide 49 text

49 ©MIXI ストアドプロシージャストアドプロシージャとは、クエリなどをデータベースに保存し、必要に応じて呼び出して実⾏することができるデータベースオブジェクトです。このプロシージャは事前コンパイルされ、パラメータ化も可能で、複雑な処理やビジネスロジックを効率的に実⾏させることができます。⾼速な実⾏が可能、アプリ側に複雑なロジックが不要、再利⽤が容易などのメリットが多くある反⾯、DBMS 間の互換性はほぼ無いのでロックインは避けられません。 TABLEs DBMS Stored Procedure - 複雑な処理 - ビジネスロジックアプリ呼び出す結果を返す

Slide 50

Slide 50 text

©MIXI ミニクイズ

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

©MIXI 演習

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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)

Slide 79

Slide 79 text

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 既存の投資を活⽤

Slide 80

Slide 80 text

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 より

Slide 81

Slide 81 text

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 より

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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 より

Slide 89

Slide 89 text

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 を使って友達が購⼊したものからオススメを⽣成します。

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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 ## パラメータ ## レスポンス ### 成功時 ### 失敗時 ## リクエストサンプル ## レスポンスサンプル

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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 より

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

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

Slide 104

Slide 104 text

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 になってしまいログインされてしまう

Slide 105

Slide 105 text

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

Slide 106

Slide 106 text

©MIXI ミニクイズ

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

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

Slide 109

Slide 109 text

©MIXI 演習