Tweet
Tweet

Slide 1

Slide 1 text

変化と挑戦：NoSQLとNewSQL Serverless Databaseの技術革新とマルチテナンシーの秘密 KOITABASHI Yoshitaka 1

Slide 2

Slide 2 text

“The best way to predict the future is to invent it.” ~未来を予測する最良の方法は、それを発明すること~ Alan Kay 2

Slide 3

Slide 3 text

アジェンダ • データベース技術の変遷 • NoSQL / NewSQL • e.g., NoSQL Service Architecture • e.g., NewSQL Service Architecture • Conclusions 3

Slide 4

Slide 4 text

4

Slide 5

Slide 5 text

5 データベース技術の変遷

Slide 6

Slide 6 text

スケーラビリティが求められる背景 • 1990年以降、インターネット人口が急増 • 書き込みの負荷に対しマシン性能が必要 => 誕生したのがNoSQL • 2006年にGoogleが論文を発表 ”A Distributed Storage System for Structured Data” => カラム指向DB: “BigTable” • 2008年にFacebookが”Cassandra”を発表 • 2012年にAWSが”DynamoDB”をLaunch 6 https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h10/html/98wp2-3-1f.html

Slide 7

Slide 7 text

データベース技術の変化 7 データ量 時間 データサイズ クエリ

Slide 8

Slide 8 text

データベース技術の発展 8 データモデル リレーショナル オブジェクト Key-Value ドキュメント グラフ 分散技術 共有ディスク オブジェクトストア Primary - Replica パーティショニング シャーディング 分散ストリーム Quorum 分散合意 高精度時刻同期 https://speakerdeck.com/frsyuki/dbakitekutiyanobi-jiao-toxuan-ze データ構造 B+Tree LSM Tree Bitcask Hash Table Bitmap Index AVL Tree Graph ストレージ HDD SSD NVMe

Slide 9

Slide 9 text

CNCFが定義する分散システム • ネットワークを介して接続された自律的な コンピューティング要素の集合 • ユーザーには単一の一貫したシステムとして表示 9

Slide 10

Slide 10 text

分散システムが解決する課題 • システムは垂直に拡張されるも限界がある • そこで水平スケーリングによる仕組みが設計 10

Slide 11

Slide 11 text

NoSQL • 非リレーショナルデータモデルで設計 • SQLインターフェースを持たない • 水平スケールを意識 • 複数のデータモデルによる機能性 11 RDBMS NoSQL ・・・ Primary Replica Replica Primary 1 Primary 2 Primary N

Slide 12

Slide 12 text

RDBMS / NoSQL 12 Product Database Products Videos Actor Videos Albums Tracks Books ID Type Price ID Autor Title ID Artist Title ID Title Category ActorID VideoID ID AlbumID Title A1 (Partition Key) A1 (Partition Key) A1 (Partition Key) A2 (Sort Key) A2 (Sort Key) A2 (Sort Key) A3 Value A4 Value A5 Value A3 Value A4 Value A6 Value Primary Key Table Items Product Table Partition key ProductId = bob ProductId = fred Attributes ProductType = videos, Price=$200 ProductType = Book, Price=$200

Slide 13

Slide 13 text

NoSQL / NewSQLを知る上で重要なこと 1. RDBMS + Shardingに対する課題 2. データモデル 3. 分散システムの仕組み 13

Slide 14

Slide 14 text

Sharding 14 Key Name Stock LastOrdered ARC1 Arc welder 10 2013-08-18 03:26:28 BRK8 Bracket 23 2013-08-18 03:26:28 BRK9 Bracket 56 2013-08-18 03:26:28 HOS8 Hose 48 2013-08-18 03:26:28 WGT1 Widget 12 2013-08-18 03:26:28 WGT5 Widget 2 2013-08-18 03:26:28 Key Name Stock LastOrdered ARC1 Arc welder 10 2013-08-18 03:26:28 BRK8 Bracket 23 2013-08-18 03:26:28 BRK9 Bracket 56 2013-08-18 03:26:28 Key Name Stock LastOrdered HOS8 Hose 48 2013-08-18 03:26:28 WGT1 Widget 12 2013-08-18 03:26:28 WGT5 Widget 2 2013-08-18 03:26:28

Slide 15

Slide 15 text

①: RDBMS + Shardingに対する課題 • 設計によってはパフォーマンス低下に繋がる • 分散トランザクションへの考慮 15

Slide 16

Slide 16 text

パフォーマンス低下に繋がる恐れ • RDBMSにおいてテーブルの正規化を実施 • 複数テーブルにまたがりレコードの操作(JOIN等)が発生 • テーブル結合がストレージをまたぐ場合、パフォーマンス低下が発生 16 shard_id company_id 1 1 1 2 2 3 2 4 company_id name 1 company A 2 company B company_id name 3 company C 4 company D company_id invoce_id 1 6100 2 6200 2 6200 company_id invoce_id 3 6300 3 6300 4 6400 ストレージノード 1 ストレージノード 2

Slide 17

Slide 17 text

分散トランザクションへの考慮 [やりたいこと] 複数のストレージノードにまたがるトランザクション処理 [必要なこと] 各ストレージエンジンで実行されるトランザクション管理の仕組みが必要 [実装方法] • アプリ側で実装 • トランザクションルータ的なものを用意 17

Slide 18

Slide 18 text

②: NoSQLのデータモデル 18 Key-Value • データをキーとバリューのペアで保存 • Partition Key + Sort Keyを組み合わせて一意のPrimary Keyを形成できる • 水平方向に拡張。データをサーバー全体に自動的に分散し、単一サーバーの障害を軽減 ドキュメント • データを JSON オブジェクトのようなドキュメントとして格納 • 直感的なI/Fに加えて水平方向の拡張が可 グラフ • グラフ理論に基づき、”ノード”を使用してデータオブジェクトを格納し、 エッジはノード間のリレーションシップを格納 • データとリレーション、関係性に対するクエリで威力を発揮

Slide 19

Slide 19 text

データモデルと課題 19 • RDBMSは一般的に静的なテーブル構造を持つ • スキーマの変更が保存データ全体に影響を与える可能性がある • NoSQLでは構造化データを表現しやすくしている (現在では、RDBMSもJSON対応したことで柔軟な設計も可能) • SQLのボトルネック 1: 一貫性を重視し、ストレージを共有する設計 2: クエリ次第で性能が大きく変わる (どうしても複雑に組み上げられSubQueryによって高負荷がかかるケースも珍しくない)

Slide 20

Slide 20 text

③: 分散システムの仕組み 20

Slide 21

Slide 21 text

分散データベースにおける整合性 • 分散ストレージが流行ったことに伴いWriteを対象とした 水平分散、シャーディングが注目 => システムのスケーラビリティとパフォーマンスが向上 • 書き込みの分散観点で重要なのは”一貫性” 21 強整合性 データベースシステムが任意の クライアントから見た時に常に 最新のデータを提供することを保証 結果整合性 データベースシステムが 時間の経過とともに最終的に 一貫した状態になることを保証

Slide 22

Slide 22 text

CAP定理とConsistent hashing • NoSQL: スケーラビリティとのトレードオフの”一貫性” => スケーラビリティを高めるために一貫性を諦めた • ACIDに対抗しBASEや、CAP定理においてAとPを、CとPと採用みたいな 22 CAP定理 一貫性 (Consistency) 全てのノードが同じデータを保持し、 参照できる 可用性 (Availability) 常にデータの読み書きが可能 分断耐性 (Partition Tolerance) ネットワーク分断が発生しても システムが動作し続ける 3 75 55 25 Consistent hashing (ハッシュ関数を使いながら データとノードのIDを マッピング) ・Memcached ・Dynamo (パーティショニング コンポーネントで利用 )

Slide 23

Slide 23 text

Replication / Sharding 23

Slide 24

Slide 24 text

Replication - 分散システムにおける負荷分散 24 App Read / Write ‧‧‧ Read Only Primary Read Replica よくある構性: Primary/replica PrimaryからReplicaに対するレプリケーション方法 • 同期レプリケーション (強整合性) • Primaryのデータと同じものが得られる(冗長性) • Replicaに問題が発生したり、ネットワーク分断が起きると 同期できなくなる • 非同期レプリケーション (結果整合性) • Replicaの問題やネットワーク分断に関係なく、データ更新可 • Primaryに障害が起きると同期できなくなる • 準同期レプリケーション (結果整合性) 特定のFollowerにデータを同期レプリケーションし、 他のnodeに対しては非同期レプリケーション 同じデータを複数のストレージノードに保持

Slide 25

Slide 25 text

Sharding - 分散システムにおける負荷分散 25 Consistent Hash Sharding Range Sharding DynamoDB, Cassandra, etc… Google Spanner, Apache HBase, TiDB, etc… 3 75 55 25 TxnID Paint Color Amount 1324 3024 $500 1567 2023 $20 1598 1022 $33 1621 1022 $1961 1765 2023 $70 TxnID Paint Color Amount 1598 1022 $33 1621 1022 $1961 TxnID Paint Color Amount 1567 2023 $20 1765 2023 $70 TxnID Paint Color Amount 1324 3024 $500 1000~1999 2000~2999 3000~3999

Slide 26

Slide 26 text

分散合意形成アルゴリズムと一貫性 分散データベース: Consensus(合意)形成は重要 • 与える命令の順序を制御し、 異なるReplicaを作り出さないようにする • リーダーの決定や分散トランザクションに利用 一貫性を保つ合意アルゴリズム • Paxos • Raft 26 https://lamport.azurewebsites.net/pubs/lamport-paxos.pdf https://research.google/pubs/paxos-made-live-an-engineering-perspective-2006-invited-talk/ https://raft.github.io/ 札幌! 沖縄! 福岡! 仙台! 京都! 石川! どれか1つに 旅行どこ行く？

Slide 27

Slide 27 text

分散システムの観点と課題 27

Slide 28

Slide 28 text

分散システムにおける各観点と課題 • Writerの観点 Replicaという構成: Writeスケールに課題 • Shardingの観点 テーブルリレーションを持つ: 水平スケールに課題 • 分散トランザクションの観点 分散トランザクション制御 : コーディネータのスケールに課題 28

Slide 29

Slide 29 text

NewSQL 歴史 • 2012年にGoogle Cloud Spannerの論文が公開 • その後、生まれたのがTiDB、CockroachDB、YugaByteDB 特徴 • SQLインターフェースを持つ • 強整合性 • スケーラビリティ 29 https://research.google/pubs/spanner-googles-globally-distributed-database/

Slide 30

Slide 30 text

なぜNewSQLが必要だったのか • 従来のRDBMSにおけるスケーラビリティの限界 Primary/replica(複数Primaryの構成は除く)では 書き込みのスケールができない • NoSQLは、一貫性の観点と複雑なアプリケーションでは 利用することが難しい 整合性の担保はDB側ではなく、アプリ側で実装が必要だったりする 30

Slide 31

Slide 31 text

NewSQL Architecture 31 Product Database Products Videos Actor Videos Albums Tracks Books ID Type Price ID Autor Title ID Artist Title ID Title Category ActorID VideoID ID AlbumID Title App Leader: Read/ Write Follower: backup Role Read / Write Node A Computing Nodes Node B Node C [Table Design] [Architecture Design]

Slide 32

Slide 32 text

e.g., NoSQL Service Architecture 32

Slide 33

Slide 33 text

Key-Valueのデータモデルで、 スケールするShardingアルゴリズムを採用し、 結果整合を採用したのが”Amazon DynamoDB” 33

Slide 34

Slide 34 text

Amazon DynamoDB SimpleDB(AmazonのNoSQL) + Dynamoを組み合わせたNoSQL 34 https://www.allthingsdistributed.com/2012/01/amazon-dynamodb.html Id: 1 Title: “AAA” Category: “horror” Id: 2 Title: “BBB” Category: “comedy” Id: 3 Title: “CCC” Category: “action” Partition Key Hash(1) = 7B Hash(2) = 48 Hash(3) = CD DynamoDB テーブル構成 (Videos) Hash.MIN = 0 Hash.MAX = FF Partition A Partition B Partition C 00 55 AA FF

Slide 35

Slide 35 text

Replication 35 Id: 1 Title: “AAA” Category: “horror” 3多重なReplication • 常に3AZ(Availability Zorn)でReplication • I/Oも3AZで実行 Hash(1) = 7B Hash(1) = 7B Availability Zone 1 Availability Zone 2 Availability Zone 3 Host 1 Host 2 Host 3 Host 4 Host 5 Host 6 Host 7 Host 8 Host 9

Slide 36

Slide 36 text

Architecture 36 https://www.usenix.org/system/files/atc22-elhemali.pdf User Network Request Router Global Admission Control Authentication System Partition Metadata System Storage Node (AZ1) Storage Node (AZ2) Storage Node (AZ3) SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD

Slide 37

Slide 37 text

System Management 37 Partition Metadata System Auto Admin SSD SSD SSD SSD SSD SSD B+Tree Storage Node Put Put Put Delete ・・・ Replication log SSD SSD SSD SSD SSD SSD B+Tree Storage Node Put Put Put Delete ・・・ Replication log SSD SSD SSD SSD SSD SSD B+Tree Storage Node Put Put Put Delete ・・・ Replication log ・テーブルとインデックスの作成 ・テーブルとインデックスのプロビジョニング ・パーティションの分割 ・パーティションの修復

Slide 38

Slide 38 text

Multi-tenancy Metadata System テーブルやインデックスに関するルーティング情報を保存 Request Router 認証と認可を行った後、メタデータ情報を利用し、 各リクエストを適切なストレージノードにルーティング Auto Admin ヘルスチェック、スケーリングなどの実行を担当 38

Slide 39

Slide 39 text

e.g., NewSQL Service Architecture 39

Slide 40

Slide 40 text

KVSをストレージとして利用 MySQLの互換性を備えた コンピューティングレイヤを搭載したNewSQLが”TiDB” 40

Slide 41

Slide 41 text

41 TiDB Architecture

Slide 42

Slide 42 text

TiDB Serverless 42 数十秒で起動し、自動でスケールする 従量課金のサーバレスデータベース サーバの管理不要 拡張が自動 ⾃動拡張 Pay as you go 従量課⾦ 自動フェイルオーバーと自 己回復 ゼロ ダウンタイム + HTAP機能も使用可能 リアルタイム分析 パフォーマンス改善 日本語によるSQL 生成支援 AI アシスタント MySQL driverやORM ツールからも利⽤可能 MySQL互換 https://aws.amazon.com/jp/blogs/storage/how-pingcap-transformed-tidb-into-a-serverless-dbaas-using-amazon-s3-and-amazon-ebs/

Slide 43

Slide 43 text

CNCFが定義するServerless • 物理マシン処理/VMのプロビジョニング/運用管理などは サービスプロバイダーが担う • 料金は従量課金 • コンピューティング/ ストレージ/ネットワークのスケーリング: ユーザの介入なしでアプリケーション側の需要に基づき自動調整 • 動的にリソースが割り当てられ、未使用のサービスにかかるコストが削減 43 サーバレスコンピューティング: ユーザからサーバを抽象化

Slide 44

Slide 44 text

Architecture 44 ● 全体としてマルチテナントアーキテクチャ ● 負荷に応じて専⽤のTiDBがアサイン Shared Gateway Isolated SQL Layer Shared Storage Layer Gateway Gateway Gateway Virtual Cluster - Tenant 1 TiDB MPP Row Engine Row Engine Row Engine Virtual Cluster - Tenant 2 Resource Pool TiDB TiDB MPP Worker Columnar Engine Columnar Engine Columnar Engine TiDB MPP Virtual Cluster - Tenant n TiDB MPP MPP MPP TiDB ・・・ EBS EBS EBS EBS EBS EBS Shared Storage Pool Amazon S3 Shared Service Compaction Checksum Analyze Coprocessor Import Export DDL PD TSO Scheduling API Server

Slide 45

Slide 45 text

重要なポイント 45 ● コンピューティング層とストレージ層が分離 => コンポーネントを柔軟に拡張可能 ● リソースプールからコンピューティングノードを追加 ● 徹底的なデータ信頼性を実現する多層ストレージアーキテクチャを採用 ● Amazon EBSがローカルストレージの補足機能を担当 ● 最終的なデータスストレージがAmazon S3 なぜ、ストレージを 使い分けているのでしょう？

Slide 46

Slide 46 text

Serverless設計の課題① • NewSQLであるの特徴であるストレージノードにデータを 自動でシャーディングする動作 => ストレージリソースを拡張する場合、 既存ノードから新ノードにデータ転送する必要がある • データ転送とレプリケーションに大量のCPUとI/Oリソースが消費 サーバーレスに重要な予測不可能なスケーリング要件に自動対応できない 46

Slide 47

Slide 47 text

Serverless設計の課題② データの永続性 / 整合性 / パフォーマンスが求められる 47

Slide 48

Slide 48 text

Serverlessを実現し、課題を解決するための方法 高信頼のShared Diskを利用すること 48

Slide 49

Slide 49 text

Amazon S3 / Amazon EBS オブジェクトストレージ: (Amazon S3) • 転送されたデータによるパフォーマンスの干渉を回避を目的に、 ノード間の共有ストレージとして採用 • TiKVとTiFlashのストレージ レイヤーを Amazon S3 に直接書き込む => スケールアウト時に新ノードは、Amazon S3 に接続するだけで済む 永続的なSSDストレージ(Amazon EBS) • Raftアルゴリズムにも対応でき、低レイテンシーの パフォーマンスプロファイルを備えた永続的なSSDストレージが必要 • メタデータやWALなど、レイテンシの影響を受けやすい情報を保存 49

Slide 50

Slide 50 text

各コンポーネントの使い分け 1. データファイル(WAL/メタデータを除く) を 揮発性ブロックストレージ(EC2インスタンスストア)にキャッシュ 2. メタデータや WAL などを永続的なSSDストレージ(EBS)に保存 ・各トランザクションの読み取りおよび書き込み操作に優れたパフォーマンスを発揮 ・ インスタンス障害に対する永続性も担保 3. データ永続性のレイヤーにオブジェクトストレージ(S3)を利用 ・ 耐久性と、事実上無制限のスケーラビリティおよび読み取り/書き込み帯域幅を享受 50

Slide 51

Slide 51 text

Storage architecture data workflow 51 1. TiDBノードがTiKVへプッシュダウン 2. 最初にリーダーレプリカが存在するノードのEBSに WALとRaft ログが書き込まれる 3. Raft ログが残りのフォロワーレプリカに伝播 4. データをEC2インスタンスストアに キャッシュした後、TiDBは変更を S3に非同期的に書き込み 5. TiDB は他の2つのフォロワーレプリカに データ読み込み信号を送信し、 信号を受信すると、フォロワーレプリカは S3からデータを読み込み、 マルチレプリカレプリケーションが完了 Leader EBS TiKV Follower EBS TiKV Follower EBS TiKV Amazon S3 1: Write Data 2: Write log / Metadata 3: Sync Raft Logs 4: Upload Data 5: Download Data New TiKV New TiKV New TiKV DDL Compaction Fast Scale-out off-Loaded Operations

Slide 52

Slide 52 text

Conclusions • NoSQL / NewSQLの歴史的背景と技術的挑戦 (分散システムやServerless設計)についてを見てきました。 • 時代の流れの中で生まれた課題を解決するための技術革新は 開発者によって常に行われています。 • 本セッションが、皆さんが携われている人々を支える サービスの”変化と挑戦”の参考になれば幸いです。 52