Contenu connexe Similaire à LiBRA 02.2019 / インフラとプラットフォーム (20) Plus de Masanori Saito (20) LiBRA 02.2019 / インフラとプラットフォーム4. クライアント (=PC) の誕生
メインフレーム クライアントサーバー
巨大な計算機に全てのリソースを持たせ、
全ての処理を実行する。
クライアントは文字の入力と結果の表示
をするだけのダム・ターミナル。
一定の計算能力と記憶能力を持った高
機能なクライアント (PC) が中規模の
サーバーと処理を分担し、高度なUIと操
作性を実現。
クライアント≒Windows PC
22. ユビキタスからアンビエントへ
ユビキタス アンビエント
ケータイ スマホ
テレビ スマホ/音声認識デバイス
M2M IoT
様々なモノがシステムに接続
され、人間からそれらに働き
かけ、情報を得る
システムが人間を見えない
形で取り巻き、必要に応じて
情報を提供
2G/電灯線ネットワーク 4G/5G/WiFi/光
クラウド無し クラウド前提
電話
ゲートウェイ
機械間通信
特徴
ネットワーク
クラウド
27. PC/AT Mac
Windows Linux MacOS
クライアント毎に専用のプログラム (ネイティブアプリ) を用意する必要があり、開発効率が良くない
クライアント・プラットフォームの変遷
PC/AT Mac
Windows Linux MacOS
RIA/Ajax
ひとつのプログラムコードで全てのプラットフォームに対応、コストを最少化して売上を最大化できる
40. HTMLの歴史と現状
HTML 1.0 (1993年)
HTML 2.0 (1995年)
HTML 3.2 (1997年)
HTML 4.0 (1997年)
HTML 4.01 (1999年)
HTML 5 (2014年)
HTML は元々インターネット上の情報をレイアウトして見やすい
ようにするために考案されたもので、静的なコンテンツを前提に
している。
HTML は1999年の4.01以降アップデートされておらず、マルチ
メディアやWebアプリケーションへの対応が難しい状態が続いて
きた。
このためプラグインを使ってブラウザの機能を拡張する方法がと
られ、Flashなどが普及した。
MicrosoftはIE5/6でHTMLに独自の拡張を行い、ブラウザの機能
を拡張したが、インターネットコミュニティからは反発を受けた。
15年ぶりの新バージョン
民間ベンダーが共同でHTMLの拡張を行い、 W3CにHTML5とし
て採用するよう働きかけた。
44. HTML5 ネイティブ
開発コスト ○ △
マルチプラットフォーム対応 ◎ ×
UX/UI △ ◎
機能・速度 △ ◎
アプリ配信の容易さ ◎ ○
収益化 △ ○
ユーザーの囲い込み × ◎
Web(HTML5)アプリとネイティブ(各社独自)アプリ
HTML5の進化により今後改
善されていく可能性がある
45. Windows Phone Xbox OS ?Windows WindowsRT
Windows Kernel
Windows10
Mac OS iOS
Macintosh iPhone/iPad AppleTV
AppleTV Software (iOS)
Smart Phone Xbox TVPC ARM Tablet
Chrome
Windows/Mac/Linux Android Chromebook
MacOSアプリ iOSアプリ TVアプリ
Windowsアプリ RTアプリ WPアプリ
Webサービス (HTML5)
ユニバーサルWindowsアプリ
各社が目指すクライアントプラットフォーム
Continuity
プラットフォーム毎の
ネイティブアプリ
データとUXを共有
Windowsプラットフォー
ム共通の
ネイティブアプリ
Web (HTML5) アプリ
46. Windows Phone Xbox OS ?Windows WindowsRT
Windows Kernel
Windows10
Mac OS iOS
Macintosh iPhone/iPad AppleTV
AppleTV Software (iOS)
Smart Phone Xbox TV
Continuity
PC ARM Tablet
Chrome
Windows/Mac/Linux Android Chromebook
Webサービス (HTML5)
ユニバーサルWindowsアプリ
各社が目指すクライアントプラットフォーム
Webサービスなら、Webブ
ラウザさえあればあらゆる
デバイスに対応可能
MacOSアプリ iOSアプリ TVアプリ
Windowsアプリ RTアプリ WPアプリ
49. Microsoftの新戦略
Microsoft技術のオープンソース化 (.Net, VisualStudio)
Active Directory
クラウドへのシフト
ハードウェア事業の強化 (Surface, Xbox, Mobile)
Windowsの無償化 (小型デバイス, Win10アップグレード)
Microsoftの強みを生かしたクラウドサービス
Office (Office365, マルチデバイス対応)
ビジネスモデル
新たな差別化
ポイント
オープン化
AzureでのOSSサポート (Linux, Hadoop, Docker)
Linuxとの歴史的和解
Windows サーバーからモバイル/ゲームまでを統合
61. 仮想化の役割
61
必要とされるシステム(機能)構成A 必要とされるシステム(機能)構成B 必要とされるシステム(機能)構成C
分割 集約 模倣
仮想化
実質的機能
使用目的に応じて必
要とされるシステム
を調達・構成する。
物理的な設置・据え付
け作業を必要とせず、
ソフトウエアの設定だ
けで、必要とするシス
テム構成を調達・変更で
きる。
柔軟性とスピード
演算 データ管理 ネットワーキング
サーバー ストレージ
システム資源
ネットワーク機器
物理的実態
ハードウェア
プラットフォーム
設備
標準化されたハード
ウェアやソフトウエア
を大量に調達してシス
テムを構成し、運用を
自動化・一元化する。
コスト・パフォーマンス
物理時実態から
実質的な機能や
性能を取り出す
65. 仮想化の歴史
HW HW HW
分 散
~1964
HW HW HW
OS OS OS
AP AP AP
分 散
1980年代~
安価なハード
運用負担の増大
TCOの増大
高価なハード
運用負担の増大
コストの増大
AP: Application / OS: Operating System / VM: Virtual Machine / HV: Hypervisor / HW: Hardware
HW
OS
AP AP AP
集 中
1964~
高価なハード
資源の制約・競合
障害時の影響拡大
IBM S/360
HW
HV
OS OS OS
AP AP AP
VM VM VM
分割を目的とした
集 中
1967~
高価なハード
自由度の制約
コストの増大
S/360 CP-40/67
HW
HV
OS OS OS
AP AP AP
VM VM VM
集約を目的とした
集 中
1999~
ハードの高性能化
管理対象の増大
インフラ負担の増大
VMware
OS
AP
専用
SW
OS
AP
専用
SW
OS
AP
専用
SW
66. 利用形態の歴史的変遷
66
OS
OS
AP AP AP
AP AP AP
3 2 1
OS
AP AP AP
OS OS
VM VM VMOS
AP AP AP
OS OS
OS
AP AP AP
OS OS
VM VM VM OS
AP
設定
AP
設定
AP
設定
コンテナ コンテナ コンテナ
1950年代~/バッチ
1960年代~/タイムシェアリング 1970年代~/仮想化(仮想マシン)
1980年代~/分散化 2000年代~/仮想化(仮想マシン)
2015~/コンテナ
メインフレーム
メインフレーム
ミニコン
メインフレーム
ミニコン
ミニコン
PCサーバー
PCサーバー
クラウド
(IaaS)
PCサーバー
クラウド
(PaaS)
69. SDI(Software-Defined Infrastructure)
69
WAN高速化装置 ファイヤウォールスイッチ ロードバランサ ルーター
SDI(Software Defined Infrastructure)
仮想化
物理的なシステム資源
システム構成や構築には設置や接続などの物理的な作業が必要
ソフトウェアによる操作や設定でシステム構成や構築を実現する
ソフトウェアによる操作や設定でシステム構成や構築を実現する
物理的な構成や機能を理解し、そこから「仮想的=実質的」にシス
テムを構成して必要な性能や機能を調達する。
物理的な構成や機能を理解していなくても、「ポリシー=目標値・
制約事項」を設定すれば必要な性能や機能を調達する。
物理的システムイメージ
利用目的・利用イメージ
70. SDI(Software-Defined Infrastructure)
70
WAN高速化装置 ファイヤウォールスイッチ ロードバランサ ルーター
組織・企業 組織・企業 組織・企業
ポリシーで機能や性能を管理
処理能力、対障害性能、セキュリティなど
SDI(Software Defined Infrastructure)
「抽象化」とは、思考に
おける手法のひとつで、
対象から注目すべき要素
を重点的に抜き出して他
は無視する方法である。
仮想化されたシステム資源
物理的なシステム資源
システム資源
機能や性能
抽象化
抽象化
仮装化されたシステム資源で構
成や運用を管理
物理的なシステム資源で構成や
運用を管理
72. DMZ FWスイッチ 負荷分散装置 ルーターネットワーク仮想化
サーバー仮想化 ストレージ仮想化
SDI(Software-Defined Infrastructure)/仮想システム
72
組織・企業 組織・企業 組織・企業 組織・企業
仮想化されたシステム資源から、ユーザーの要望に応じて運用管理者が個別に構成・調達
運用管理者が個別にシステム資源を構成・調達
物理的なシステム資源をプール(リソース・プール)
73. SDI(Software-Defined Infrastructure)
73
DMZ FWスイッチ 負荷分散装置 ルーター
物理的なシステム資源をプール(リソース・プール)
組織・企業 組織・企業 組織・企業 組織・企業
仮想化されたシステム資源から、ユーザーの要望に応じて自動で構成・調達
ポリシー
• 処理能力
• 対障害性能
• セキュリティ
ポリシー
• 処理能力
• 対障害性能
• セキュリティ
ポリシー
• 処理能力
• 対障害性能
• セキュリティ
ポリシー
• 処理能力
• 対障害性能
• セキュリティ
SDIを構築し運用するソフトウエア
プロビジョニング
Provisioning
ネットワーク仮想化
サーバー仮想化 ストレージ仮想化
74. 仮想化されたシステムの構成
74
物理システム
製品ベースでの調達・運用
物理性能・物理構成・物理作業
仮想システム
実質ベースでの調達・運用
実質性能・実質構成・ソフトウェア設定
サーバー ストレージ ネットワーク
メモリ容量
CPU性能
ディスク容量
ネットワーク機能
ネットワーク接続
仮想サーバー 仮想ストレージ 仮想ネットワーク
オーケストレーション
ポリシーベースでの調達・運用
規則・条件・基準による設定
ポリシー
• 処理能力
• 対障害性能
• セキュリティ
システム構成
01
ポリシー
• 処理能力
• 対障害性能
• セキュリティ
システム構成
02
ポリシー
• 処理能力
• 対障害性能
• セキュリティ
システム構成
03
コントロール
パターンやルール・ベースでの運用管理・調達管理
構成管理・稼働管理・問題解決
監視
自動/自律制御
制
御
81. Infrastructure as Codeの特徴(1)
81
環境構築手順書
① AをBする。
② CをDにする。
③ FをGにする。
・・・
+#!/bin/sh+yum
install -y httpd httpd-
devel php php-
mbstring php-pdo
php-mysql mysql-
インフラ設定インフラ構築手順作成
環境構築手順書 1
① AをBする。
② CをDにする。
③ FをZにする。
・・・
環境構築手順書 2
① AをBXする。
② CをDYにする。
③ FをZにする。
・・・
環境構築手順書 3
① AをBXする。
② CをDYにする。
③ FをGZにする。
・・・
+#!/bin/sh+yum
install -y httpd httpd-
devel php php-
mbstring php-pdo
php-mysql mysql-
手作業で作業ミスが心配
変更を繰り返すと管理が大変
実際の環境と履歴が一致しない
対象が増えると管理しきれない
設定に手間がかかる
テスト・確認が複雑
82. Infrastructure as Codeの特徴(2)
82
変更履歴
① XXXXXXXXX
② XXXXXXXXX
③ XXXXXXXXX
・・・
クラウド個別システム
×
×
システム資源が物理的に固定さ
れるので、インフラ構築はその
制約の下で行われる。
物理サーバーを構成変更しなが
ら使い続ける。
システム資源が仮想化されるの
で、インフラ構築に物理的な制
約をうけることはない。
仮想サーバーの追加・破棄を頻
繁に繰り返すことができる。
変更履歴を管理 動作している状態を管理
構成は不変
Imutable Infrastructure構成は変化し続ける
83. Infrastructure as Codeを実現するソフトウェア
83
仮想マシン 仮想マシン 仮想マシン
Orchestration: 複数サーバーの管理を自動化
Configuration: OSやミドルウェアの設定を自動化
Bootstrapping: OSの起動を自動化
OS OS OS
Virturization: 仮想マシンの構築・起動
ミドルウェア
アプリケーション
OSや仮想化ソフトウェアのインストール/設定作業を自動化
データベースサーバ/Webサーバ/監視エージェントなどのミドル
ウエアのインストールやバージョン管理、OSやミドルウエアの設定
ファイルや、OSのファイアウォール機能などの設定などを自動化
複数台のサーバ群を監視し、新しいサーバをシステムに登録したり、
障害のノードをシステムから取り除いたり、サーバへのアプリケー
ションのデプロイをサポート
KickStart
91. Chromebook
91
インターネット
データ
文書作成 表計算
プレゼン ・・・ ブラウザ
画面表示・入出力操作
通信
画面表示・入出力操作
通信
オフィス・アプリ
データ
文書作成 表計算
プレゼン ・・・
オフィス・アプリ
クラウドサービス Google Apps for workなど
ブラウザ
文書作成 表計算
プレゼン ・・・
PC / Windows・Mac OS など Chromebook / Chrome OS
93. ストレージ仮想化
ストレージの業界団体であるSNIA(Storage Network Industry Association)
による
「ストレージ仮想化技術の分類」
Disk Virtualization (ディスクの仮想化)
Block Virtualization (ブロックの仮想化)
File System Virtualization (ファイル・システムの仮想化)
File Virtualization (ファイルの仮想化)
Tape Virtualization(テープの仮想化)
96. SD-WAN(Software-Defined Wide Area Network)
96
IP-VPN インターネットVPN
(IPsec VPN) 4G LTE専用回線
ソフトウェアによって統合・一括管理された仮想的なWAN
負荷分散、セキュリティ管理、アプリケーションによるネットワークの振り分けなど
一括管理
コントロール
オーケストレーション
SD-WANソリューション
拠点LAN 拠点LAN 拠点LAN 拠点LAN 拠点LAN 拠点LAN
エッジ端末 エッジ端末 エッジ端末 エッジ端末 エッジ端末 エッジ端末
GUI
103. サーバーの仮想化 / BCP対策・仮想マシン・レプリケーション
VM A VM B
物理
マシン
仮想化ソフトウェア
データ
AP AP
仮想マシン・イメージ
のレプリケーション
データの
レプリケーション
ネットワーク
VM A VM B
物理
マシン
仮想化ソフトウェア
データ
AP AP
クラウド基盤へのレプリケーション
VM A VM B
物理
マシン
仮想化ソフトウェア
データ
AP AP
個別基盤へのレプリケーション
107. ビジネスとしてのランサムウェア
107
ボットネットレンタル : 60ドル/日、400ドル/週
ランサムウェアキット : 1,000ドル/月
サーバー侵入代行 : 3~5ドル(コマンドインターフェイス)、
10~25ドル(リモートデスクトップ接続)
エクスプロイトキット(リース) : 50ドル/日~1,800ドル/月
クレジットカード番号(所有者詳細情報つき): 30ドル
ヘルスケア情報(米国医療保障制度番号10件): 4,700ドル
DARKReading:Cybercrime: A Black Market Price List From The Dark Web
Ransomware as a Service 利用料金
クラウド・サービス
として取引されている
サイバー犯罪の多くは金銭目的
オンラインバンキングではアカ
ウント情報を窃取し不正送金を
行い、ランサムウェアはWebマ
ネーやビットコインを要求する。
個人のスキルに依存したビジ
ネスから組織的ビジネスある
いは分業化されたビジネスへ
113. 何を評価するのか
113
ルール通りに作業はできている。しかし・・・
このやり方でビジネス・スピードに追従できているか?
生産性は向上しているのか?
だれかが「遅くまで仕事をする」ことで、効率の悪さが帳消しに
なっていないか?
締め切りを遅らせる「コミュニケーション」が多すぎないか?
無駄な会議、無駄なメールのやり取りなど・・・
確かに「作業」はしている。しかし・・・
評価の「指標」が明確になっているか?
「目的」は何か
その目的を達成するための「目標」は明確か
「目標」達成にはどれだけのことをやらなければならないのか
誰がやればどれくらいで終わらせることができるか
全体の作業工数は明確になっているか
「目的」は達成されたか?
118. リスクマネージメントの相関図
118
事故の発生 事故の影響 受容
脅威 ぜい弱性 機密性
完全性
可用性対策
受容レベル
保証×説明
コスト 影響
どこまでやればよいのかを?
対策コスト負担
3項目への影響
業務の受容レベル
最適な組合せ
情報セキュリティの3項目
機密性:情報を盗まれない。
完全性:情報をデタラメな内容に書き換えられない。
可用性:システムを停止・破壊され業務継続を妨げられない。
121. こんなことになってはいないだろうか?
121
情報セキュリティ対策が効率や利便性の向上の障害に
なっていないか?
ノートPCを購入した → 危ないので持ち出し禁止
Office 365を契約した → 危ないので外部からの利用禁止
当初の導入目的は何だったのか。それが満たされているか
利用者に負担をかけない対策を行っているか?
不審なメールは開かない → 開いた人の責任
複雑なパスワードを定期変更する → パスワードをつけた人の責任
IT利用によってビジネスは成長しているか?
導入前と導入後で業績は変わらない
期待していた効果が得られない
業務効率は低下している
突発的な損失が起こる可能性を想定しているか?
セキュリティ事故や社内不正によって突発的な事故が起きた時の影響
について分からない、検討していない
事故対応(インシデントレスポンス)の準備はしていない
127. サイバー・セキュリティ対策の目的
127
どのような「心配事」があるかをリストアップする。
「リスク需要レベル」を明確にし、関係者と合意する。
重要度・緊急度を明確にして優先順位を決め対策する。
ITを最大限に活用するための最小限のセキュリティ
ITを活用する上での心配事を解消し業務の効率や利便性を高めること
サイバー・セキュリティの目的は「情報資産の保護」ではない。
リスクを適正に管理し業務の効率や利便性を高めること。
機密性:情報を盗まれないようにすること。
完全性:情報をデタラメな内容に書き換えられないようにすること。
可用性:システムを停止・破壊され業務継続を妨げられないようにすること。
安心・安全に、便利に効率よく仕事ができるようにする取り組み
問題を回避する対策:USBメモリー使用禁止
目的を達成する対策:安心・安全なファイル共有・交換サービスを提供
ファイルを受け渡したい
138. Hyper-Converged System
高い拡張性
簡単に導入
構成や運用の自動化
NXシリーズ
Evo:RAIL
VxRACK
VSPEX BLUE
HyperFlex System
コンバージド・システムとハイパーコンバージド・システム
標準化されたモジュール
サーバー、ネットワーク、ストレージで1単位のモジュール構成
全てをソフトウエアで設定・構成
システム全体の構成をソフトウエアの設定で行える
自己修復
障害の検知、切り分け、分散処理で自動的に修復
データとサービスを分散
データの管理とアプリケーション・サービスを分散処理
APIと自動化
アプリケーションや管理ツールと連携して運用や調達を自動化
150. リレーショナル・データベースの系譜
1961年 IMS(Information Management System)/IBM
階層型データベース。NASAのアポロ計画で、最終製品を構成するBOM(Bill of
Materials)を管理
1970年 Edgar F. Codd(IBMの研究者)が論文を発表
A Relational Model of Data for Large Shared Data Banks(大規模共有デー
タバンク用データのリレーショナル・モデル)
1973年 Michael StonebrakerらがIngresの開発に着手
後にPostgreSQL前身、Postgresを開発者(PostgreS=Post+Ingres)
1983年 IBMがDB2をリリース
1979年 Lawrence J. EllisonがOracleをリリース
1984年 Robert EpsteinらがSybaseを設立
Ingressの開発に参加したひとり
1987年 SybaseがSQL Serverをリリース
1980年 Informix設立
2001年IBMが買収
1979年 Teradata設立
1989年 MicrosoftがSQL Serverをリリース
1988年から1993年までIngresがマイクロソフト社と技術提携
1989年 カリフォルニア大学がPostgresをリリース
1997年 PostgreSQLへ改名
1995年 MySQL ABがMySQLをリリース
2008年サンマイクロ → 2010年オラクルに買収
151. リレーショナル・データベースの革新性
151
SELECT 社員名 FROM 社員 WHERE 年齢 < 30;
使いやすいデータ構造
テーブル
使いやすいユーザー・インターフェイス
SQL
データを格納する方法が直観的にイメージしやす
い。こうした二次元表によるデータ管理は、
Excelなどのソフトが登場する前から一般的な方
法だったため、RDBが登場した当時の人々にとっ
ても受け入れやすいものだった。
「データの位置」という概念を一切排除した。あ
るデータが何行目であるとか何列目であるという
アドレスやポインタといった扱いの難しい位置表
現を使わなくてもデータを操作できる。
SQLは英語に似せた構文を持っているため、特に英
語を母国語とする人々にとっては、日常言語でデー
タを操作できるような感覚を持つ。
ループを排除し、記述の難しさやトラブルを無くす
よう工夫されている。データのアドレスをポインタ
や配列の添え字で操作したり、ループ処理を記述す
ることにともなうバグを引き起こしやすいといった
弊害を無くすように考えられている。
154. 多様化するデータベース
RDBMS
NoSQL
クラウド
DB
IaaS
Cassandra, HBASE, redis, memCached, mongoDB, Couchbase/CouchDB, Neo4j,
Oracle NoSQL
マ
ネ
ー
ジ
ド
Amazon Azure Google
商用
Oracle, DB2, SQL Server
OSS
MySQL, Postgres, MariaDB
IBM
RDBMS RDS SQL Database Cloud SQL DB2
Aurora Compose
NoSQL DynamoDB DocumentDB Cloud Datastore Cloudant
Table Storage Cloud Bigtable Graph
BigData Redshift SQL DataWarehouse BigQuery DashDB
オンプレミスDBをIaaS上でサポート
サーバーレス AWS Lambda
Azure Functions
Azure Service Fabric
Google App Engine
Google Cloud Functions
156. リレーショナルデータベース (RDBMS)
社員番号 氏名 住所コード 通勤手段
S001 大越 章司 J101 鉄道
S002 斎藤 昌義 J302 鉄道
S003 山田 太郎 J201 バス
S004 山本 次郎 J401 鉄道
住所コード 乗車駅 通勤手当
J101 柏 38,000
J201 浅草 12,000
J302 国立 34,000
J401 横浜 43,000
社員通勤表 通勤手当表
テーブル (リレーション)
社員番号 氏名 通勤手当
S001 大越 章司 38,000
S002 斎藤 昌義 34,000
S004 山本 次郎 43,000
鉄道通勤者の通勤手当表
関連づけ(リレーションシップ)
IBMのエドガー・F・コッドが1969年に発表したデータ関係モ
デルについての論文が元になっている
扱うデータは正規化された定型
データ
複数のテーブルを関連付けする
ことができる
テーブルを横断してデータを検
索したり操作できる
複数のテーブルから見たい列と行を取り出して新たな
テーブルを作成(クエリー)
165. 列指向(カラム指向/カラム型) RDBMS
カラム型
RDBMS
RDBMS+
カラム処理
SybaseIQ, Netezza, Verticaなど
SQL Server ColmunStore Index, Oracle 12c,
Oracle Exadata Hybrid Columnar
Compression, HANAなど
DWH向け
集計・分析処
理を高速に
実行
通常のRDBMSが取り扱う「行」単位ではなく、「列」単位で処理
顧客名 住所(県) 住所(市町村) 売上金額
「列」指向の特長
・蓄積したデータから特定の列を高速に読込む
・データの追加、削除、更新には向かない
・BI/DHW (OLAP) 向け
「行」指向(通常のRDBMS)の特長
・行毎にデータを追加、削除、更新
・ランダムアクセス、頻繁な更新に向く
・トランザクション処理 (OLTP) 向け
行
列
166. 列指向RDBMSの得意分野 ~ 集計
顧客名 住所(県) 住所(市町村) 売上金額 顧客名 住所(県) 住所(市町村) 売上金額
売上金額の集計
行指向 列指向
1レコードずつ読み出して集計 売上金額の列のみを読み出して集計
167. 列指向RDBMSの得意分野 ~ 分析
顧客名 住所(県) 住所(市町村) 売上金額 顧客名 住所(県) 住所(市町村) 売上金額
顧客の都道府県分布の分析
行指向 列指向
1レコードずつ読み出して集計 都道府県の列のみを読み出して集計
データの圧縮率を上げられる
171. RDBMSとKey Value Store (KVS)
RDBMS KVS
データ形式 テーブル キー+バリュー (値)
データ構造 正規化・構造化データ 構造化/非構造化データ
設計の柔軟性 事前にスキーマを定義 スキーマレス (変更が容易)
処理の柔軟性 複雑な検索や集計が可能 シンプルな操作のみ
データの整合性確保 ◎ (ACID) △ (BASE)
分散処理 △ ◎
トランザクション処理 ◎ △
SQLサポート ◎ △
RDBMS KVS
172. ACIDからBASEへ
BASE
Basically Available 「基本的に」利用可能
Soft-state 状態の厳密性を追求しない
Eventually consistent 最終的に一貫性が保たれれば良い
厳密な一貫性やデータの即時反映などをあきらめる代わりに、
スケーラビリティや柔軟性を得ることができる
ACID
Atomicity 処理を一部残すなど、中途半端な状態を許さない
Consistency データの整合性を保証
Isolation 一連の処理を他の処理から隔離
Durability 処理が完了した時点で結果は保存され失われない
絶対確実
概ね確実
CAP定理 = 分散システムではACIDを達成できない
173. ワイドカラムストア型
Amazon DynamoDB Apache Cassandra
Amazonが提供するフ
ルマネージドのNoSQL
サービス
DynamoDBをベースに
Facebookが開発し、
オープンソースとして
公開
大規模にスケールアウト可能。ノードを増やすとリニアに性能を向上させることができる。
データの一貫性を保証
Google BigTable Apache HBase
Googleが開発した拡張
KVS
Googleの論文を元に
Javaで実装し直した
オープンソース
結果整合性
(遅延とのトレードオフで一貫性レベルを設定可能)
可用性は保証されない
(3つのノードにレプリカを作成)
可用性を保証
柔軟なデータモデル (スキーマレス)
174. 様々なNoSQL
キーバリュー型
(KVS)
ワイドカラム
ストア型
(列指向)
ドキュメント型 グラフ型
Riak
Redis
Google BigTable
Apache Hbase
Amazon DynamoDB
Apache Cassandra
Couchbase
MongoDB
Neo4j
キー (Key) と値 (Value)
のみのシンプルなデー
タ構造
KVSを拡張して複数の
バリューを持たせたも
の
KVSよりも柔軟で複雑
なデータ構造に対応で
きる
グラフ理論にデータ同
士の関係をグラフとし
て表す
「元祖」NoSQL KVS以外でもキーとバリューを使うDBは多く、広い意味では全てKVSとも言える
Key Value
001 山田太郎
002 中村一郎
Key Value
001 山田太郎
002
管理部
中村一郎
財務部
係長
氏名
所属
氏名
所属
役職
管理部
財務部顔写真
係長
顔写真
中村一郎山田太郎
Document 1 Document 2
182. クラウドデータベース (マネージド/DBaaS)
Amazon Azure Google IBM
Graph Graph
BigData Redshift SQL DataWarehouse BigQuery DashDB
Document DynamoDB DocumentDB
KVS DynamoDB Table Storage Cloud Datastore Cloudant
Cloud Bigtable
RDBMS RDS SQL Database Cloud SQL DB2
Aurora
Cache ElastiCache Redis Cache
* Amazon RDSはAurora, MySQL, MariaDB, Postgres, Oracle, SQL Serverをサポート