Comments
Description
Transcript
DB2 pureScale, クラウド時代のDB基盤へ テクニカルナイト
テクニカルナイト
®
IBM Software Group
DB2 pureScale, クラウド時代のDB基盤へ
～遂に登場するプライベート・クラウド・データベースの本流～
2010年2月5日
日本アイ・ビー・エム株式会社
ソフトウェア事業 技術理事
菅原香代子
© IBM Corporation
アジェンダ
プライベート・クラウドの位置づけ
クラウド時代の企業データ・モデル
DB2 pureScale の発表
DB2 pureScale: スケーラビリティ
DB2 pureScale: ノンストップ・データベース
DB2 pureScaleと他社クラスタとの違い
DB2 pureScale: 導入と構成
ストリーム・コンピューティング（オプション）
2
プライベート・クラウドの位置づけ
3
プライベート・クラウドの位置づけ
革新的サービス展開モデルへの進化
クライアント／お客様
革新的なビジネス・モデル (with financial viability)
データ・センターのイノベーション
Connect
イノベーション・サービス
統合されたサービス
企業のIT基盤
プライベート
クラウド
ハイブリッド
クラウド
ダイナミック・データセンターに向けたデータセンターの進化
クラウド・コンピューティング技術を活用し、抜本的な効率化と
企業内・グループ内での革新的なサービス展開を実現
統合されたサービス
パブリック
クラウド
多様なクラウド・サービス
4
プライベート・クラウドの位置づけ
プライベート・クラウド
パブリック・クラウド
共通の技術
NFR充足率
NFR充足率
企業事業部門ユーザー
クラウドサービス・デリバリー
アプリのクラウド・サービス化
開発環境の効率化
マルチ・テナント
• Software as a Service
• Platform as a Service
• Infrastructure as a Service
クラウド・サービス
企業IT部門 /
SO, SI事業者
サービス・コンシューマー
既存システム仮想化
コンポーネント・ベンダー /
SI、ソフトウェア配付業者
新しいSW構造
クラウド・プラットフォーム
データセンター
データセンター
インフラストラクチャ
インフラストラクチャ
運用環境の効率化
規模の共用
クラウド事業者
リソースの運用・管理
add
スケールアウト・クラウド
サーバー・クラウド
IT システム・ベンダー
NFR: Non Functional Requirement
JEANS & eCloud研究会
5
HW買い付けコストとＴＣＯ
HW買い付け
コスト
$$$$
TCO
TCO : Total Cost of Ownership
6
サーバー・デザインが変わっていく
• パブリック・クラウド ⇒ 大量サーバー群をコンテナーにパッキング、ネットワーク機器で結合 ⇒ KVS
• プライベート・クラウド ⇒ 大型SMPサーバー + クラスター化 ⇒ 仮想化とスケーラブルDB(SQL)
Intel x86 サーバーもチップ内スケールアウトにより大型SMPサーバーにシフト（サーバー数減）
レイテンシーのバンド幅に対する改善遅れ
マルチコア／マルチスレッド化
10000
Processor
チップ内スケールアウト
1000
Network
Relative
Memory
BW
100
Improve
ment
Disk
10
(Latency improvement
= Bandwidth improvement)
1
1
10
100
Relative Latency Improvement
David A. Patterson, UC Berkeley, March 2004
JEANS & eCloud研究会
7
サーバー・デザインが変わっていく
JEANS & eCloud研究会
8
サーバー・クラウドとスケールアウト・クラウド
サーバー・クラウド
スケールアウト・クラウド
ワークロードの
小さい。サーバーの一部を利用
大きさ
極めて大きい。数十から数千のサーバー
にまたがる
パーティショニング
ソフトウェアの
比較的小規模に分割されたシングルイ
アーキテクチャ
ンスタンスのアプリケーション群
マルチテナント
スケールを出せるアプリケーションフレー
ムワークで複数のインスタンスを実行
耐障害性
インフラ／ハードウェア内
アプリケーションのアーキテクチャに作り
こむ
ステート管理
伝統的なアプリケーション中心のデータ
ベース・トランザクション処理。データは
１カ所に保存
アプリケーションは状態を保存しない。複
数のコンテンツストレージで冗長性を確
保
サーバー
仮想化の利用
サーバーのハードウェアを共有し、利用
効率を最大化
オプション的。柔軟かつ迅速なセットアッ
プを支援するプロビジョニングに適用
出展：NIKKEI COMPUTER 2009.1.15 （原典フォレスター・リサーチ）
に追加変更
JEANS & eCloud研究会
9
クラウド・サービスとクラウド・プラットフォームの関係
プライベート・クラウド
既存互換重視
新規API採用
パブリック・クラウド
Amazon
Amazon.com
Google
SFDC
salesforce.com
SaaS
“Software
as a Service”
Application
API
Python
アプリケーション
SFDC CRM
アプリケーショ
ン
PaaS
“Platform
as a Service”
Middleware
API
Google API
GoogleAppEngine
Force.com
独自スクリプト
言語とサービス
IaaS
“Infrastructure
as a Service”
Hardware
Interface
仮想サーバー
AmazonEC2
仮想化
プロビジョニング
ハイパーバイザ
プロビジョニング
ハイパーバイザ
プロビジョニング
ハイパーバイザ
ビッグテーブル
仮想化はなし
マルチテナント
仮想化はなし
スケーラビリティ
信頼性
スケールイン
HW, MWで構成
スケールアウト
MWで構成
スケールアウト
99.5%
スケールアウト
MWで構成
スケールアップ
HWで構成
データ
SQL, DB
SQL, DB, KVS
SQL, DB, KVS
KVS
SQL, DB
サーバー
クラウド
スケールアウト・クラウド
サーバー
クラウド
KVS: Key Value Store
10
サーバー・クラウドとスケールアウト・クラウド
分割された比較的
小さなワークロード
スケール・イン
スケール・イン
モノリシックで
大きなワークロード
大型SMP型
データは
ACID／SQL型
App
App
App
App
App
Mid
Mid
Mid
Mid
Mid
OS
OS
OS
OS
OS
サーバー・クラウド
サーバー・クラウド
仮想化
Hypervisor
100K Users
HW
。。。
Hypervisor
HW
アンサンブル
HW系によるスケーラビリティ、信頼性の実現
スケール・アップ
スケール・アップ
スケールアウト・クラウド
スケールアウト・クラウド
HW系によるスケーラビリティ、信頼性の実現
1 Billion Users
データは
コンテンツ／KVS型
超大規模なワークロード
マルチ・テナント
サポート
SW系によるスケーラビリティ、信頼性の実現
マルチコア
マルチスレッド化
安価なプロセッサーを
大量に利用
ブレード / モジュラー型
スケール・アウト
スケール・アウト
KVS: Key Value Store
JEANS & eCloud研究会
One Size Fits All ?
11
“Scale In” が プライベート・クラウドへのステップ
Linux & Oracle
1
5.1 X
Space
Power
People Cost
Software
Maint
Software
Maint
Hardware
0.9
3.9 X
エネルギー効率
⇒
エネルギー効率
⇒ システム使用率。
システム使用率。 エコがイデオロギーに。
エコがイデオロギーに。
0.8
Intel系サーバーの低使用率
Intel系サーバーの低使用率 ⇒
⇒ $140B分の未使用サーバー・アッセット
$140B分の未使用サーバー・アッセット
80% Savings
Cost Per Image
0.7
Savings 74%
0.6
1.0 X
0.5
0.4
K
$
VMware, Hyper V
Xen on Intel
0.3
0.2
760 x86 CPs
304 x86 CPs
x86 w/o
Virtualization
26 z10 EC IFLs
x86
Virtualization
z/VM Linux on
System z10 EC
System z
Power Systems
0.1
0
0
5
10
15 20
NÆ
NFR Æ
25 30
35 40
45 50
55 60
65 70
75 80
85 90
95 100
Servers ⇒ Ensembles
zz 単体でMTBF
単体でMTBF == 35年以上
35年以上
NFR: Non Functional Requirement
JEANS & eCloud研究会
Back to the Future
12
アンサンブル・コンポーネント
サーバー・アンサンブルの例
ワークロード
モビリティ
OS
OS
OS
OS
Hypervisor
Server
OS
OS
Hypervisor
アンサンブル
マネージャ
アンサンブルの定義:
単一システムとして管理可能な
同類システムのプール
Server
アンサンブルは通常以下のコンポーネントから構成される:
• 互換性のあるシステム・ノードのプール(例., N 物理サーバー; 均質である必要はない)
• アンサンブル内および互換性のあるアンサンブル間での仮想資源のモビリティ
• アンサンブル・ノードを結合するネットワーク(ローカル接続あるいは最適化接続)
• リソースのバーチャライザー(hypervisors, I/O virtualizers, storage virtualizers, …)
• アンサンブル構成の実・仮想リソースのプラットフォーム管理を提供するアンサンブル・マネージャ アプライアンス
• 計画、アンサンブル作成、P2Vマイグレーション、イメージ管理と組み立て等のツール類
• パーフォーマンス、アベイラビリティ、エネルギー消費、セキュリティ等のインテリジェント・デフォルトなアンサンブル
固有の自動最適化 ソフトウェア
• マルチシステム・サービス (locking, caching, message queuing, …) の統合（オプション）
⇒
pureScale
JEANS & eCloud研究会
13
サーバー・アンサンブルの価値
個別のサーバー群
サーバー・アンサンブル
ワークロード
モビリティ
OS
OS
OS
OS
OS
OS
OS
OS
OS
Hypervisor
Hypervisor
Hypervisor
Server
Server
Server
OS
OS
OS
Hypervisor
アンサンブル
マネージャ
Server
管理対象の数
N 仮想サーバー; M 物理サーバー
N 仮想サーバー; １物理アンサンブル
作成、テスト、
メンテナンス
DIY(自作); バラバラの構成
標準の “off the shelf” アセンブリ
管理の自動化
アドオン・ソフト、 カスタム・スクリプト、 …
ビルトイン最適化;インテリジェント・デフォルト
管理
インターフェース
多数の個別ノブと変数
選択可能な標準動作のメニュー
コンソール数
バラバラの物理&仮想コンソール
単一コンソール; 文脈による機能性
データセンタ管理
アーキテクチャ
モノリシック; DC間でのヘテロな拡散
階層化; プール層でのモジュール化
アンサンブルはIT資源管理の複雑さを著しく削減し、IT機能性を強化する
JEANS & eCloud研究会
14
Workload Mobility (Live Partition Mobility)
•
•
POWER6 からの搭載サーバーの機能
1 号機上で稼動中の OS区画 が 2 号機へと移動
• HMC 上の操作員指示によって、Live Partition Mobility を開始
• 移動に先立ち、ディスクに書き込まれていないメモリー上のデータが、ネットワーク経由で
転送される
• SAN 上のディスク・イメージ (LUN) への接続が引き継がれる
• OS区画 移動の完了（OS 及びアプリケーションは稼動を続けたまま）
Power #1
Power #2
VIOS
区画
区画
#A
#B
VIOS
POWER Hypervisor
POWER Hypervisor
SAN
HMC
15
プライベート・クラウドによる新エンタプライズ・システムの構築へ
•アンサンブルは IBM System z, Power Systems, System x のそれぞれに構築される
• Power Systems は超スケーラブルなミッション・クリティカル・システムの要へ
Down
load
ETL file
Transaction
File
Down
load
file
ETL
ETL
Screen
scrape
Message
Queue
Apps
ETL
DB
Replica
Transaction
File
ORB
ｱﾌﾟﾘ Apps
• HAソリューションの簡素化
• SW投資保護の改善
• ソフトウェア・アプライアンス化
Apps
Apps
Apps
• 複雑さとスケールの切り離し
• 統合化された自律管理系（スクリプト化）
• 動的な省エネルギー管理
• データセンタ・セキュリティ基盤
Transaction
File
Apps
Apps
Message
Queue
Apps
• ハードウェア使用率の改善
• IT俊敏さの改善
• 省エネルギー構成
プライベート
クラウド
Mobility
ｱﾌﾟﾘ
ｱﾌﾟﾘ
ｱﾌﾟﾘ
アプリ
アプリ
アプリ
SW
OS
SW
OS
SW
OS
Software
•テスト機
•スタンバイ
Operating System
Virtual Server Virtual Server Virtual Server
Virtualization
Compute Memory Storage
Compute Memory Storage Network
Scale In
サーバー
占有・密結合
JEANS & eCloud研究会
Network
仮想化サーバー
最適化.
• 可用性
• パフォーマンス
• 電力
アンサンブル
ダイナミック・インフラストラクチャ
16
超スケーラブル可能なミッションクリティカル・システム
ミッションクリティカルの特性
特に信頼性などの充足
smarter NFR
状況に対応したNFR
プライベート・クラウド
クラウドの進化
クラウドの進化
l IT
a
ion
t
i
d
Tra
ing
t
pu
m
Co
d
u
Clo
パブリック・クラウド
• IT Infrastructure
• Business Infrastructure
• Social Infrastructure
スケーラビリティ
HW系資源の仮想化、スケールアウト化などによる動的な活用
NFR: Non Functional Requirements
JEANS & eCloud研究会
17
クラウド時代の企業データ・モデル
18
データベース技術の全体像 エンタープライズ・データ
BAO（Business Analytics and Optimization)
スケーラビリティ
スケーラビリティ
アベーラビリティ
アベーラビリティ
コンシステンシー
コンシステンシー
BAO
クラウド
コンピューティング
sharding
リアルタイムで稼動中の
情報分析により、
ビジネスの応答性を改善
ストリーム
コンピューティング
200８ COGNOS
IT Appliance
2003
“System S”
KVS
(Key Value Store)
最新データの分析による
ビジネス取引改善
オブジェクト
グリッド
インメモリー
solidDB
XML
データベース
Sysplex
RDBMS
レプリケーション/ ETL
1970
リレーショナル・
データベース
NFS / DFS / GPFS
ファイル
JEANS & eCloud研究会
データベース：
アプリケーション
からの独立
Yr. 2
DB2 PE
実行環境の
データベース群
コンテンツ
マネージメント
Yr. 3
DB2 PureScale
Yr. 1
OLAP
時系列データの
レポーティングと
データ
人間による分析 ウェアハウジング
1968
階層型
データベース
19
クラウド時代のデータ・モデル
クラウド時代におけるデータのシステム属性
コンシステンシー
Scale-Up
Cluster DB
Stream
Computing
計算処理量
ACID
Schema
BAOでは低レイテンシーなデータ供給と
柔軟で超高速な演算加工処理が鍵
Business
Intelligence
In Memory
低レイテンシー
Object-Grid
BAO
一般ＤＢでは３要件の充足の方法が鍵
•コンシステンシー
•アベーラビリティ
•スケーラビリティ
クラウド性
（スケーラビリティ）
互換性
SQL
（コンシステンシー）
KVS
Scale-Out
BASE
スケーラビリティ
スケーラビリティ
スケーラビリティ
KVS: Key Value Store
ACID: Atomicity, Consistency, Isolation, Durability
BASE: Basically Available, Soft state, Eventually consistent
JEANS & eCloud研究会
アベーラビリティ
アベーラビリティ
コンシステンシー
コンシステンシー
BAO: Business Analytics and Optimization
20
ACID+スケーラビリティ追求の、クラスター型DBモデル
通常の非同期型のロック制御 (Oracle RAC)
system 1 snd task switch
system 2
int task switch rcv
int task switch rcv work snd task switch
•通常のサーバー間通信
•TCP/IPスタック・オーバーヘッド
•コンテクスト・スイッチ・オバーヘッド
“三角形型” アーキテクチャ
Web
Web
Web
VRU
VRU
Call Center
Call Center
Call Center
アプリケーション互換のまま
スケーラビリティを達成
Service
Service
Service
超高速のロック制御が
スケーラビリティの鍵
同期型グローバル・ロック制御 (DB2 pureScale)
xx μsec round trip
system 1 snd
wait (poll)
rcv
• 256 Bytes message
System 2
rcv work snd
CF
JEANS & eCloud研究会
• CFは仮想イメージで実装
• 実資源はPHYPで共有
21
超高速トランザクション処理指向の、低レイテンシー型DBモデル
インメモリーDB
solidDB
Universal Cache
データベース
能力
アプリ
インメモリーDB
高度な検索
solidDB
Universal Cache
Cache
組み合わせ
120,000 TPS
データの柔軟さ
オブジェクトグリッド
WebSphere eXtreme Scale
単純な
OLTP
オブジェクトグリッド
“四角形型” アーキテクチャ
高速の
インメモリー
アクセス
JEANS & eCloud研究会
POJOs
リニアな
Scale Out
としての
データ・アクセス
データグリッド
能力
Web
Web
Web
VRU
VRU
Call Center
Call Center
Call Center
Service
Service
Service
Service
Service
Service
DB
DB
DB
DB
DB
DB
永続化
スケールアウトな
超高速データ処理
22
大量イベント処理 / ストリーム処理
イベント
分析時間
大量イベント処理の能力
1ミリ秒
プログラム
売買
10 ミリ秒
100 ミリ秒
Complex
Event
Processor
コール
センター
JEANS & eCloud研究会
1,
00
0,
00
0
リスク
分析
10
0,
00
0
1,
00
0
10
10
0
輸送車両管理
1分
10
,0
00
1秒
イベント・スループット
(メッセージ/秒)
23
• 複雑さの削減と利便性の追求
ITアプライアンスとソフトウェア・アプライアンス
• HWとは仮想化層で隔離
Appliance
Appliance
電化製品：Household Appliance
SWスタック
Cognos BI
IT
IT Appliance
Appliance
• ターンキー製品
• スイッチオンで使える装置・器具
• 中の構造は考えなくていい
Apps.
Apps.
DB
Linux
ネットワーク
OS,MWを1ファイルに
Compute
パッケージング
Windows
VMware
Memory Storage
Network
Ent
erp
MW
Windows
rise
環
Apps.
VMware社が提唱
VMware社が提唱
OSとMWを１ファイルイメージでまとめる
OSとMWを１ファイルイメージでまとめる
仮想化環境にイメージを展開
仮想化環境にイメージを展開
DMTF OVF: Open Virtual Machine Format
境へ
適
Image
用
Virtual
Virtual Appliance
Appliance
JEANS & eCloud研究会
クラウド
単機能サーバー
スイッチオンで使える
SWにAp
plianceの
概念を適
用
SWベンダー、ディストリビューター
MW
OS
ストリーム
コンピューティング
Enterprise
Enterprise class
class virtual
virtual Appliances
Appliances
（JEANSで提唱）
OS,MWを隠蔽
VAC
EA EA
App App
s.
s.
Image
Repository
VAC VAC
Router/
Hub
WebAp
p Srv
WebAp
p Srv
DB
OS
OS
OS
OS
DB
HA
OS
仮想化層 VM/LPAR/ハイパーバイザー/ Ensemble
Compute
Memory
Storage
Network
24
KVS(Key Value Store)のデータ・モデル (BigTableなど)
row
key
col col
name value
row 1
k127
type: capacitor farads: 12mf cost: $1.05
row 2
k187 type: resistor ohms: 8k
row 3
k217
…
…
Google
App
Engine
• Row Keyでソート
• Raw Keyノ範囲でスキャン
label: banded cost: $.25
Application
MapReduce
BigTable
• Map
• Reduce
Google File System
KVSとはキーにデータ(値）を関連付けてストア（格納）し、キ
ーを指定することでデータ(値)を検索するデータモデル
分散型KVSでは各種アルゴリズムでキーに従って担当サー
バーを決定
キーによる自動的な分割
partitioning（垂直） / sharding(水平．行データを分散）
RDBMSに似せたテーブル形式を取っているがより自由度が
大きい、
9事前のスキーマは不要
9新しい列は何時でも追加出来る
9列は各行で異なっていてもよい
列の名前や値の実質的な解釈はしない
9解釈はアプリケーションや上位レイヤーに任される
9異なったフレームワークやオビジェクト・モデルに解放
JSON, Redis, Django, JDO, JPA,など
少なくとも10 のopen source のアプローチが行われている
Apache
Django
Cassandra
Node
Apache
JDO
Django for Python
JDO for Java
Cassandra Cassandra
… Node
Node
JEANS & eCloud研究会
先頭を走っているのが次の２つ
9Cassandra (JavaベースのAmazon Dynamo クローン)
9HBase (JavaベースのGoogle BigTable クローン)
9その他、Voldemort, Eucalyptus, など多くある
Web 2.0アプリケーションで多くのアプローチがなされている
9Google AppEngine (GAE) Pythonをベースにしたもの
9Apache HTTP server, memcached, 多くのRDBMSエンジンの
統合アプローチ(MySQL, Postgres, Oracle, SqlServer, DB2)
25
クラウド・アーキテクチャ：HW資源の仮想化とvmイメージ(アプライアン
ス）
クラウド・サービス
VAC / PaaS
Persistence
Persistence
App
App
Mid
App Srvr
Memory
MemoryTables
Tables
(ObjectGrid
,
SolidDB
,,)
(ObjectGrid ,SolidDB,,)
App
….
Files
Files(HDFS,
(HDFS,GPFS,,)
GPFS,,)
KVS
)
KVS(Cassandra,
(Cassandra,HBase
HBase)
OS
J2EE Env
Image
RRDB
DB(DB2,
(DB2,ORACLE,
ORACLE,etc)
etc)
VAC / PaaS
プロキシー
プロキシー
EA / IaaS
セキュリティ
セキュリティ
SaaS / PaaS
コネクティビティ
コネクティビティ
仮想サーバー
…
仮想化 / 仮想アプライアンス
クラウド・プラットフォーム
クラウド・プラットフォーム
イメージ管理
プロビジョニング
アンサンブル管理
Etc.
EA: Enterprise class virtual Appliances
VAC: Value Add Capability
JEANS & eCloud研究会
26
DB2 pureScale
DB2 pureScale の発表
27
2009年大きなターニング・ポイントを迎えたDB2
IBMメインフレームのテクノロジーを吸収し進化をしつづけるオープン系DB2
他社DBMSのアーキテクチャーを大きく上回るシェアード型 pureScaleを発表
DB2 pureScale
発表
pureScale発表
2009年11月12日
2009年5月21日
DB2 9.7発表
V9.5
2007年
V9
2004年 V8.2
2006年
大規模DB対応強化
データ・ガバナンス強化
高可用性の強化、H/W連携
トランザクショナルXML
pureXML Support
オートノミック機能の強化
開発生産性の向上
IT投資の8割を占める
インフラ運用管理をより低コストに
他社DBユーザーからの移行を促進
Enterprise Linux
高可用性の強化
オートノミック機能の強化
2002年
1993年
V1
V8
・
・
・ V1.0～V4.0
オートノミック（自律型）機能実装開始
高度な情報統合への発展
マルチプラットフォームへの対応
汎用システムの世界からＰＣの世界へ
28
企業にとってアドバンテージとなるIT要素
１
爆発的なトランザクション増加への備え
2
サービスレベルを落とさない運用
3
スピーディかつ低コストなサービス拡張
4
シェアードアーキテクチャーの限界をBreakthrough
「ノンストップ」、「スケーラビリティ」、「スピード」を追求した
新しいデータベース・インフラ技術
29
DB2 pureScale
1
クラウド基盤にも適する超大規模スケール
9
9
2
アプリケーション
サーバーを追加した分、パフォーマンスが向上する
初期は必要なキャパシティだけ購入しビジネスの成長にあわせて拡張
アプリケーション変更の無い即時拡張
9
アプリケーションの変更と停止をせずに容易に拡張できる
9
クラスター構成のためのアプリケーション変更のリスクとコストを低減
3 障害時、メンテナンス時もノンストップ
9
障害時・メンテナンス時も稼動し続ける
9
安定したパフォーマンスで連続的なデータアクセスを提供
シングルデータベース
DB2
DB2
DB2
ノード間通信
CF
データシェア
業界をリードするIBMメインフレームのデザインをオープン系プラットフォームで踏襲
他社のHAクラスター、スケールアウト・ソリューションの限界を超えるデザイン
スケールアウトソリューションの管理コストを大幅に削減
30
DB2 pureScaleは何をモデルに？
DB2 for z/OSデータシェアリング 他社の尊敬を集めるアーキテクチャー
スケーラビリティと高可用性におけるゴールド・スタンダードとして、DB2 for z/OS は
だれもが認めています。
Oracleも尊敬しています
Oracle社のCEO ラリー・エリソン
Why?
「わたしは、いろいろなデータベースをけなしている。
ただし、メインフレーム版のDB2を除いて。メインフ
レーム版のDB2は、第一級の技術のひとつだ。」
– カップリング・ファシリティ!
• ロックとキャッシュの集中管理により、優れたスケーラビリティと可用性を実現しています
– z/OSシステム全体でカップリング・ファシリティを使っています
• CICS, MQ, IMS, ワークロード管理、など
31
DB2 pureScale テクノロジー・オーバービュー
クライアントはどこにでも接続、
一つのデータベースとして利用
自動的なワークロードバランス
クライアント
シングル・データベース・ビュー
DB2エンジンはそれぞれのコンピューターで稼動
Member
Member
–
データベースアクセスの一貫性を提供するように連携
–
2009年出荷時点はAIX 6.1 on p550 or p595限定
Member
Member
統合されたクラスター・サービス
CS
CS
CS
CS
–
障害検知, 自動リカバリー, クラスター・ファイルシステム
–
Tivoli System Automation, GPFS
超高速ノード間通信
Cluster Interconnect
–
CS
2nd-ary
CS
Log
Log
Log
Shared Storage Access
Database
Log
Primary
RDMAノード間通信を最大限に活用 (Infiniband)
PowerHA pureScale テクノロジー
–
効率的なグローバル・ロッキングとバッファー管理
–
セカンダリーへの同期２重化により可用性を確保
データシェアリング・アーキテクチャー
–
データベースへの共有アクセス
–
GPFS
32
pureScaleの構成 メンバーとは ?
DB2エンジン
–
メンバー毎に所有
–
バッファープール
–
メモリー区画
–
ログファイル
すべてのメンバーは同じ共有データベースにア
クセス
Member 1
db2sysc process
db2 agents & other
threads
db2sysc process
db2 agents & other
threads
log buffer,
dbheap, &
other heaps
log buffer,
dbheap, &
other heaps
メンバーはデータを共有
–
db2syscプロセスやスレッド
Member 0
bufferpool(s)
bufferpool(s)
メンバーは論理的で、以下のような構成
も可能
–
マシンかLPARあたり、1メンバー (推奨）
–
マシンかLPARあたり、1つ以上のメンバー (非
推奨)
Log
Log
Shared database
(Single database partition)
33
pureScaleの構成 PowerHA pureScaleとは ?
グローバル・バッファーの一元管理とグ
ローバル・ロッキングを実現するソフト
ウェア・テクノロジー
–
–
db2 agents & other
threads
System z 並列シスプレックスとカップリ
ングファシリティのテクノロジーに由来
–
グローバル・バッファープール (GBP)
–
グローバル・ロック・マネージメント (GLM)
–
シェアード・コミュニケーション・エリア (SCA)
log buffer,
dbheap, &
other heaps
log buffer,
dbheap, &
other heaps
ソフトウェア・ベース
以下のサービスを提供
db2 agents & other
threads
bufferpool(s)
bufferpool(s)
Primary
メンバーはGBP, GLM, SCAをプライマ
リーとセカンダリーの両方に反映
–
同期的に実施
–
二重化はオプションだが、推奨される
–
標準で自動的に設定される
Log
Log
GBP GLM SCA
Secondary
Shared database
(Single database partition)
34
DB2 pureScale
スケーラビリティ
35
pureScale スケーラビリティ実証
トランザクションは受発注処理と集計処理
の混在環境
–
更新トランザクションは全体の20%で典型的な
OLTPの比率
アプリケーションはクラスター環境を意識
しない
–
–
–
Clients (2-way x345)
アフィニティなし
パーティショニングなし
トランザクションからメンバーの指定なし
構成
–
64 GB, 5 GHz
Two 4Gb FC
Switches
DS8300 storage
•
–
20Gb IB
pureScale
Interconnect
7874-024
Switch
64 GB, 5 GHz
PowerHA pureScaleサーバー8-core p550 2台
•
–
p550
powerHA pureScale
データサーバー 8core p550 12台
•
–
p550
members
1Gb Ethernet
Client
Connectivity
576 15K disks, Two 4Gb FC Switches
IBM 20Gb/s IB HCAs
•
7874-024 IB Switch
DS8300
Storage
36
スループットの比率
OLTP アプリケーションのスケーラビリティ実証結果
8 member
95% のスケーラ
ビリティ
12
11
10
9
8
7
6
5
4
3
2
1
0
4 member
97.5% のスケー
ラビリティ
10.4x @ 12 members
7.6x @ 8 members
3.9x @ 4 members
1.98x @ 2 members
0
5
10
15
サーバー数
37
効率的なスケールアウトを実現するためのデザインポイント
低レイテンシーなRDMA/uDAPL を
採用
– 往復レスポンスタイムを10-15 マイクロ
秒以下で実現
Lock Mgr
Lock Mgr
Lock Mgr
Lock Mgr
Buffer Mgr
古いページを高速に無効に
か
?
転
を
送
GBP
ペー
ジを
い
ジ
ー
更新ページはディスクI/Oなしでグ
ローバルバッファーから検索
リク
エス
ト
よ
して
得
取
を
うぞ
ック
ど
ペ
新
– クラスターの拡張に応じて重要となるテ
クノロジー
更
– インターラプトや他のメッセージ処理は
不要
ロ
– ページ更新をメンバーに知らせる処理に
メンバーのCPUサイクルを必要としない
GLM
SCA
– RDMA専用のスレッドは検索処理を10
マイクロ秒以下で実現
38
pureScaleの優位性 RDMAによるノード間通信
1.
データノード1のdb2agentはCFのメモリーに直接書き込む:
–
読み取りたいページ番号
–
該当ページを格納したい自ノードのバッファープール・スロット
2.
CFはメンバー1のメモリーに直接書き込むことで返答する:
–
CFが該当ページをもっている場合はそのデータを返答する
–
CFが該当ページをもっていない場合はその旨返答する
上記の処理全体でマイクロ秒のオーダーで行う
割り込みがなく処理が高速なため、処理の間db2agentはCPUに残り続ける
データノード1
リクエストをダイレクトに
メモリーに書き込む
CF
db2agent
CF スレッド
1, Eaton, 10210, SW
2, Smith, 10111, NE
3, Jones, 11251, NW
501のページがほしい.
バッファのスロット42 に
データがほしい
返答をダイレクトに
メモリーに書き込む
ローカルのメモリーコピーと同様にリモートと通信
39
DB2 pureScale
ノンストップ・データベース
40
pureScale アプリケーションの変更と停止を低減
スケーラビリティのための配慮は不要
– データ配置やアプリケーション上の配慮は不
要
メンテナンスのための配慮は不要
– アプリケーションの変更や停止を伴わずに、ノード
拡張が可能
– クラスター構成の動的な変更が、アプリケーション
に与える影響はなし
負荷分散のための配慮は不要
– ノード間での自動ロードバランシングを実現
– アプリケーションは、どのノードに接続しても、
自動的に最適なノードで処理を行える
管理者は、再チューニングや再テストをすることなく処理能力を追加可能
開発者はクラスター構成であることを意識する必要なし
41
pureScale 計画停止の影響の最小化
1) 稼動中のシステム
ターゲットノードの認識
2) “Drain” 実行
3) メンテナンスの実行
Drainが完了後
HW、SWパッチの適用
計画停止
新しいトランザクションを他ノー
ドに配分
既存のトランザクション完了
DB2
DB2
DB2
DB2
DB2
DB2
DB2
DB2
DB2
システムは連続稼動
実行中のワークロードの強制終了やロールバックはなし
42
pureScale 計画外停止のリカバリー処理
DB2 pureScale の設計の要は、障害
が発生した際、リカバリー処理中の可
用性を最大化することである
– 上記以外の全データ・ノードは全
面的にアクセスが可能
障害が発生したノードで実行中のトラ
ンザクションも、問題の検知も含めて
短時間で復旧させることが目標
Log
CF
DB2
Log
DB2
Log
共有データ
DB2
Log
CF
データベースノードの障害
利用できるデータの割合(%)
データベース・ノードに障害が発生し
た際、リカバリーが完了するまで、障
害ノードの更新中(インフライト)の
データだけをロックする
DB2
回復中にはインフライトデータののみを
ロック
100
50
Time (~seconds)
43
メンバーのHW障害 : 他ノードでメンバー回復処理
アクシデントで電源コードがぬけた
DB2クラスター・サービスのハートビートが途絶えたこと
により、メンバーのダウンを検知
–
他のメンバーやPowerHA pureScaleサーバーに伝える
–
障害メンバーからログやデータをブロックする
–
自動メンバー回復処理を別のホスト（ゲストホスト）で始め
る
–
メンバーのリスタートは高速
•
PowerHA pureScaleのメモリ上のページを読み込めばよいた
めRedo処理も高速
ロードバランシングによる自動化(デフォルト)、または
指定したペアのメンバー
DB2
CS
他のメンバーはリカバリー中も完全に利用可能
–
DB2
CS
DB2
CS
障害メンバーが更新中でなかった大半のデータを他のメン
バーが参照、更新可能
DB2
CS
Fe
nc
e
DB2
メンバー回復処理が完了
Lo
g
Single Database View
クライアント接続は、透過的に正常なメンバーへリルー
トされる
–
–
Clients
R
Log
Log
Log
Secondary
Log
Pa
ge
s
CS
Updated Pages
Global Locks
s
障害メンバーが保持していたロックが解放され全データが
完全にアクセス可能になる
ec
–
Shared Data
CS
Updated Pages
Global Locks
Primary
44
メンバーの復旧
電源が入り、システムがリブート
Clients
DB2クラスター・サービスがシステムが使
えることを自動検知
– 他のメンバーやPowerHA pureScale
サーバーに伝える
– I/Oのブロックを解放する
– 元のホストでメンバーが起動する
Single Database View
DB2
CS
クライアントは使用可能となったメーバーに
自動的に接続される
DB2
CS
DB2
DB2
CS
CS
DB2
Log
Log
Log
CS
CS
Updated Pages
Global Locks
Secondary
Log
Shared Data
Updated Pages
Global Locks
Primary
45
プライマリーPowerHA pureScaleの障害
アクシデントで電源コードがぬけた
DB2クラスター・サービスのハートビート
が途絶えたことにより、プライマリーのダ
ウンを検知
Clients
Single Database View
– メンバーとセカンダリーに通知
– PowerHA pureScaleサービスは瞬間的
にブロックされる
– 全ての他DBアクティビティは通常通り
•
Eg. バッファープール内のページアクセス, 既に
取得済みロック, ソート処理, 集約, etc
DB2
CS
セカンダリーは、プライマリーデータとの
誤差分をメンバーから取得
DB2
CS
DB2
DB2
CS
CS
– Eg.読み取り専用ロック
セカンダリーがプライマリーになる
– PowerHA pureScale サービスを中断し
たところから継続する
– DB2メンバーにはエラーは戻らない
Log
Log
Log
CS
CS
Updated Pages
Global Locks
Secondary
Primary
Log
Shared Data
Updated Pages
Global Locks
Primary
46
PowerHA pureScale の復旧
電源が入り、システムがリブート
DB2クラスター・サービスがシステムが使
えることを自動検知
Clients
– 他のメンバーやプライマリーに伝える
Single Database View
新しいシステムは‘キャッチアップ’状態の
セカンダリーとなる
– メンバーはPowerHA pureScale2重化を
再開する
– メンバーは、ロックやその他の情報をセカ
ンダリーに非同期に送る
DB2
CS
キャッチアップが完了
– セカンダリーがピアー状態になる (プライ
マリーと同じロックやページ状態をもって
いる。)
Log
DB2
CS
Log
DB2
Log
Primary
CS
Log
CS
CS
Updated Pages
Global Locks
DB2
CS
Shared Data
Updated Pages
Global Locks
Secondary
(Catchup
(Peer state)
state)
47
クライアントの接続性とワークロードバランシング
実行中の負荷情報はクラスターをまたがった自動ワークロードバランスに使用される(System z のシスプレックスの
ように)
–
–
–
–
全てのメンバーの負荷情報を各メンバーがそれぞれ所有
定期的にクライアントに通知
次の接続 (または任意の次のトランザクション) は負荷が最小のメンバーにルート
ルーティングは自動的に実行 (アプリケーションに透過的)
フェイルオーバー
– 障害が発生したメンバーの負荷は、自動的に障害が発生していないメンバーに均等に分配
フェイルバック
– 障害が発生したメンバーがオンラインに戻ると、逆の動きを実行
クライアント
クライアント
48
pureScale ノード障害時の対応
障害ノード
メンバー
DB2
DB2
他のメンバーは
稼動し続けるか
DB2
DB2
CF
プライマリ
PowerHA
pureScale
CF
DB2
DB2
DB2
CF
DB2
CF
メンバーの役割は透過的に他のメンバーに引
き継がれる
DB2
CF
セカンダリ
PowerHA
pureScale
自動復旧できるか
DB2
DB2
DB2
CF
49
pureScale ノード障害時の対応
障害ノード
DB2
DB2
DB2
CF
DB2
DB2
CF
CF
DB2
DB2
メンバーの役割は透過的に他のメンバーに引
き継がれる
DB2
CF
DB2
自動復旧できるか
DB2
CF
DB2
他のメンバーは
稼動し続けるか
メンバーの役割は透過的に他のメンバーに引
き継がれる
DB2
CF
メンバーの役割は透過的に他のメンバーに引
き継がれる
50
DB2 pureScale
導入・構成
51
pureScale 簡単に開発・構築
DB2 pureScaleのノード追加は、
アプリケーションに影響を与えない
管理者、開発者はキャパシティ変
更の要件に対して容易に対応可能
すべてのコンポーネントの一括導入
Optimツールによる統合監視
Fixpaksやパッチの一括導入
シンプルなコマンドによるノードの追加・削除
52
pureScale 必要なコンポーネントをパッケージング
クライアント
単一データベースとして見える
DB2 pureScale はソフトウェアによ
る完全なソリューション
メンバー
CS
メンバー
メンバー
メンバー
CS
– 統合されたサブコンポーネントで構
成
CS
共通のインストール作業
CS
– 指定したホストを経由して全てのコン
ポーネントをインストール
クラスターノード間通信
CS
CS
ログ
ログ
ログ
共有ストレージアクセス
データベース
ログ
– ベスト・プラクティスに基づいて自動的に
設定
クラスターマネージャーのスクリプト
記述や設定作業は不要
– インストール時に自動的にセットアップ
53
pureScale インスタンスと稼動状況
Clients
> db2start
08/24/2008 00:52:59
0 0
SQL1063N DB2START
08/24/2008 00:53:00
1 0
SQL1063N DB2START
08/24/2008 00:53:01
2 0
SQL1063N DB2START
08/24/2008 00:53:01
3 0
SQL1063N DB2START
SQL1063N DB2START processing was successful.
Single Database View
processing
processing
processing
processing
was
was
was
was
successful.
successful.
successful.
successful.
> db2instance -list
host0
host1
host2
host3
DB2
DB2
DB2
DB2
host5
host4
Shared Data
db2nodes.cfg
0
1
2
3
4
5
host0
host1
host2
host3
host4
host5
0
0
0
0
0
0
host0ib
host1ib
host2ib
host3ib
host4ib
host5ib
MEMBER
MEMBER
MEMBER
MEMBER
CF
CF
ID TYPE
STATE
0
1
2
3
4
5
STARTED
STARTED
STARTED
STARTED
PRIMARY
PEER
MEMBER
MEMBER
MEMBER
MEMBER
CF
CF
HOST_NAME
STATE
host0
host1
host2
host3
host4
host5
ACTIVE
ACTIVE
ACTIVE
ACTIVE
ACTIVE
ACTIVE
HOME_HOST CURRENT_HOST ALERT
host0
host1
host2
host3
host4
host5
host0
host1
host2
host3
host4
host5
INSTANCE_STOPPED
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
ALERT
NO
NO
NO
NO
NO
NO
54
pureScale ストレージ構成
55
pureScale サンプル構成
前提
– POWER590 or 550, CFのメモリーはMember合計サイズの40%, AIX 6.1 TL03(SP02以上),
– サーバー:DB2 9.7以上, クライアント:DB2 9.7 FP1以上
クライアント通信用(Ethernet)
ノード間通信用(InfiniBand)
Power 550
InfiniBand
Power 550
InfiniBand
member1
member2
POWER6 4.2GHz
CPU:4core
Mem:25GB
AIX6.1 TL03 SP02
DB2 9.7 pureScale
POWER6 4.2GHz
CPU:4core
Mem:25GB
AIX6.1 TL03 SP02
DB2 9.7 pureScale
InfiniBand
CF1
RAID5
5GB(RAID5)
RAID5
POWER6 4.2GHz
CPU:4core
CF Mem:20GB
AIX6.1 TL03 SP02
DB2 9.7 pureScale
Power 550
For DATA SD
RAID5
Power 550
CF2
POWER6 4.2GHz
CPU:4core
CF Mem:20GB
AIX6.1 TL03 SP02
DB2 9.7 pureScale
DS8300
RAID5
InfiniBand
LUN1 for DATA
hdisk2
LUN2 for DATA
hdisk3
LUN3 for DATA
hdisk4
LUN4 for LOG
hdisk5
for TieBreaker
hsidk6
For Tie Breaker
56
IBM DB製品のクラスター
製品
DB2 pureScale
Infosphere
Warehouse
DB2 HADR, HA構成
構成
1:1
対象
中・大規模OLTP
データウェアハウス
小・中規模OLTP
特徴
シェアードデータ
シェアードナッシング
アクティブホットスタンバイ
DB2 pureScale:
中・大規模OLTPの可用性/拡張性強化
Infosphere Warehouse: 大容量データウェアハウスの高速処理/拡張性強化
DB2 HADR:
小・中規模OLTPの可用性強化
57
サマリー DB2 pureScale
より高度なスケーラビリティと、優れた可用性を提供
通常運用における連続稼動性の向上
サーバーの障害発生時における連続稼動性の向上
スケーラビリティ確保に向けたアプリケーション再設計と再構築の減少
SLA達成の改善
高いトランザクションのパフォーマンスと、
極めて高い可用性を必要とするアプリケーションにおける
全体的なコストの低減
58
ストリーム・コンピューティング
59
Stream Computing
Template Documentation
60
より早く知り、より多くを発見するためには新しい手段が必要です
2005年のRFIDタグの利用は13億個。
2010年までには300億個。
資本市場のデータ量は2003年から
2006年にかけて17.5倍も増加
2007年に携帯電話の
利用者は33億人
世界中の総情報量は
2年ごとに2倍になる
2011年までにインターネット
の利用者は20億人に達する
政府、国防組織
61
これらに共通する課題は何でしょうか?
• 大量のデータ： データベースが処理できるよりも速い
• 複雑な分析： 複数の情報ソースや信号、ビデオ、音声、または他の
非構造化データの関連付け
• 時間に敏感： ミリ秒以内でのレスポンスが必要
62
イベントの爆発は劇的なイノベーションを必要とします
伝統的なコンピューティング
ストリーム・コンピューティング
動かないデータから
過去の(ヒストリカルな)事実を発見
動いているデータをリアルタイムに分析
バッチ方式、プル型モデル
動いている構造化データや非構造化データのス
トリーム
クエリー駆動
静的データに対しクエリーを投げる
データベースやデータウェアハウスに依存
ストリーミング・データ
ストリーム・コンピューティング
ストリーミング・データに対しリアルタイムに分析・
操作
データ
Data
クエリー
Queries
Data
データ
結果
Results
Queries
クエリー
Results
結果
b) ストリーミング・データ
a)a)静的データ
static data
b) streaming data
63
利用例: メキシコ湾の危険と機会
緊急ニュース:
緊急ニュース:
¾
¾ ハリケーン
ハリケーン ”ディーン”
”ディーン” がカテゴリー5にアップグレード
がカテゴリー5にアップグレード
同様の記事を2時間後に
しました
• あなたは主要な情報源によりハリケーンの接近を知ることが
しました
見たものです。
できました…
¾
¾ 予想進路はメキシコ湾を通過する見込み
予想進路はメキシコ湾を通過する見込み
ストーリーは同じですが、し
¾
• 例えば NOAA
によるハリケーン進路予報
¾ 石油関連銘柄は一斉に下落
石油関連銘柄は一斉に下落
かし…
• それとも気象衛星や/またはセンサーからのデータかも
しれません
• 進路上と見られる企業資産の位置（と価値）の情報を集計
することができれば……時価速報は別のスト
ーリーを示しています
• もしもそのような分析を一連のニュースより先に適用できれ
ば…
• あなたはメリットを享受することができます – 双方向で…
石油会社の銘柄は下
落(早期警戒に基づく)
影響を受ける企業がさ
らに見つかっています
(少し遅いですよね?)
進路上の重要な資産
の設備は引き続き
下落
他の銘柄は上昇、嵐の
上陸前にもかかわらず
回復を示す
64
ハリケーンの予測を基にしたリコメンデーション
予測経路上の施設へのリス
クアセスメントの状況が次々
と更新される
売り・買いを薦めるためにリスクと
取引のVWAPを関連付ける
ハリケーンの予測経路はリ
アルタイムに変化
市場データの監視
（ハイボリューム）
ポートフォーリオを示
す数値の監視
（低レイテンシー）
気象センサー，ハリケーン経路予測情報の監視
System S platform
ポートフォー
リオへの影
響の予測
リコメンデーション
を生成し，通知
DHTMLによる結果
の表示
WebSphere Smash
65
InfoSphere Streams プラットフォーム
開発環境
SPADE
Eclipse IDE
入力源を定義、オペレータを
ザ
ユ
れ
か
書
で
+
C
は
た
vま
Ja
終
最
び
よ
お
ク
ン
シ
間
中
用
適
タ
ー
レ
ペ
オ
、
義
定
を
源
力
入
適用、中間シンクおよび最終シンク
Java または C++ で書かれたユー
ザー定義オペレーター
ランタイム環境
InfoSphere Streams
ランタイム
最適化コンパイラーは配置
と接続を自動化
小さい遅延
最大125ノードのクラスター
ツールキット＆
アダプター
ツールキット
StreamSight
アウトプット・アダプター &
ソース・アダプター
Cognos Now
WebSphere MQ
Mashup Center
WebSphere Front Office
RSS フィード
66
SPADE: Stream Processing Application Declarative Engine
– 高パフォーマンス・ストリーム・コンピューティングに最適化
主な特徴
プログラミング言語とコンパイル基盤
SPADE を使ってアプリケーションを記述
クエリー
オプティマイザー
コンパイラー
コード
ジェネレータ
高パフォーマンス・ストリーミング・システムを念頭にお
いた設計
幅広いバリエーションのターゲット･アーキテクチャへの
効率的なマッピング
主なコンポーネント
ストリーム・プロセッシング演算子および実行ディレク
ティブのツールキット
Stream
プロセッシング
グラフ
ストリーム関係型演算子
ユーザー定義演算子
エッジ・ストリーム・アダプター
Streams
プロセッシング・
コア
効果的な配置、パーティショニング等を行う管理機能
主な利点
ストリーム・プロセッシングに最適化
デプロイメントまでの時間短縮
67
プログラミング・モデル
ソース・アダプター
演算子リポジトリ
シンク・アダプター
アプリケーション・プログラミング (SPADE/INQ)
プラットフォーム最適化コンパイル
使いやすい
再利用可能な演算子群
外部の静的データソース
またはストリーミング・
データソースおよびシン
ク群
68
シンプルな例
[Application] アプリケーション
SourceSink trace
[Typedefs] 型定義
typespace sourcesink
typedef id_t Integer
typedef timestamp_t Long
Source
Aggregate Functor
Sink
[Program] プログラム
// 仮想スキーマ定義
vstream Sensor (id : id_t, location : Double, light : Float, temperature : Float, timestamp : timestamp_t)
// ソース･ストリームは source 演算子が生成 – この場合タプルは入力ファイルから投入される
stream SenSource ( schemaof(Sensor) )
:= Source( ) [ “file:///SenSource.dat” ] {}
// この中間ストリームは Aggregate 演算子がSenSourceストリームを入力に使って生成。
stream SenAggregator ( schemaof(Sensor) )
:= Aggregate( SenSource <count(100),count(1)> ) [ id . location ]
{ Any(id), Any(location), Max(light), Min(temperature), Avg(timestamp) }
// この中間ストリームは functor 演算子が生成
stream SenFunctor ( id: Integer, location: Double, message: String )
:= Functor( SenAggregator ) [ log(temperature,2.0)>6.0 ]
{ id, location, “Node ”+toString(id)+ “ at location ”+toString(location) }
// リザルト管理は sink 演算子が実施 – この場合生成されたタプル群はソケット宛てに送られる
Null := Sink( SenFunctor ) [ “udp://192.168.0.144:5500/” ] {}
69
7
0
Streams ランタイム
最適化スケジューラーは演算子を処理ノード
へ割り付け、資源配分を継続的に行う
市販ハードウェアで稼働 – 単一ノードから
BladeCenter から高パフォーマンス・マル
チラック・クラスターまで
処理要素
コンテナ
処理要素
コンテナ
処理要素
コンテナ
処理要素
コンテナ
処理要素
コンテナ
Streams データ・ファブリック
トランスポート
x86
X86
ブレード
Box
x86ブ
X86
ブレード
レード
x86
FPGA
ブレード
ブレード
x86ブ
X86
ブレード
レード
x86
Cell
ブレード
ブレード
70
7
1
Streams ランタイム
最適化スケジューラーは演算子を処理ノード
へ割り付け、資源配分を継続的に行う
資源、ワークロード、データ量の
変動に適応
処理要素
コンテナ
処理要素
コンテナ
市販ハードウェアで稼働 – 単一ノードから
BladeCenterから高パフォーマンス・マル
チラック・クラスターまで
処理要素
コンテナ
処理要素
コンテナ
処理要素
コンテナ
Streams データ・ファブリック
トランスポート
x86
X86
ブレード
Box
x86ブ
X86
ブレード
レード
x86
FPGA
ブレード
ブレード
x86
Blue
ブレード
Gene
x86
Cell
ブレード
ブレード
特殊ハードウェアの活用も可能
71
低レイテンシー エンド・トゥ・エンドの例
163 ストリーム
2,133 ストリーム
1,975 ストリーム
データフィード
24 チャンネル
意思決定エンジン数: 163
Blue Gene ノード数:
356
PE数:
356
ストリーム数:
4,274
データレートは記録スピードの15倍
レイテンシーの平均値は150マイクロ秒
レイテンシーの最小値は50マイクロ秒
レイテンシーが2ミリ秒以上のメッセージ数は6.5万件のうち49件
72
Streamsight による稼動中アプリケーションの管理
アプリケーション群の論理ビューおよび物理ビュー
73
分散オペレーション
B 拠点
B 拠点
C 拠点
C 拠点
A 拠点
A 拠点
74
代表的なユースケース
株式市場
自然界向けシステム
• 株価への天候のインパクト
• 秒あたり500万件の市況
データ、150マイクロ秒以
内のトレーディング
• 野火管理
• 水資源管理
•
法規制
• リアルタイム、かつマルチモーダルな監視
r
te
a
W
輸送
• インテリジェントな交通管制
• グローバルな航空管制
不正防止
• 複数犯不正の検知
• リアルタイムの不正防止
製造業
• マイクロチップ製造ラインの
プロセス・コントロール
電波天文学
• 一瞬のイベントを検知
健康 & 生命科学
• 新生児 ICU モニタリング
• 院内感染早期警戒システム
• 遠隔ヘルスケア・モニタリング
75
TD 証券は InfoSphere Streams で
次世代トレーディング･プラットフォームを構築中
次世代アルゴリズミック・
トレーディング・プラットフォーム
1秒当たり160万件のイベントを処
理
ミリ秒のスピードで取引を特定、執
行
2010年までに１秒当たり500万件
のイベントまで成長する計画
コンテンツ･フィード、ニュース本文、
音声、ビデオを統合するように拡張、
より有効な意思決定のため高度な
処理内容を確立する予定
76
電波天文学
平方キロサイズのセンサー・ア
レイ (SKA)
電波望遠鏡アレイからの膨大
なデータを分析
InfoSphere
Streams
77
サイバーセキュリティ
様々なセンサー（ビデオ、電話通話記録、音声）を複合的に利用した監視システム
受信するデータストリームは巨大だが、“異常値”を示すデータはほとんどないというのが特
徴的 - 前処理で処理することに大いに意味がある
監視システム
ボットネット検出
78
オンタリオ工科大学での研究プロジェクト
未熟児のモニタリング
– SpO2(動脈血酸素飽和度)と
Mean ABP(観血的動脈血圧の
平均)を関連付けることで“新
生児心肺停止”を予測
• Sp02<85%
• 20秒間 血圧(BP)< 在胎週数
(GestAge)
Source
Join
Aggregate
Functor
Alert
BP
Functor
Aggregate
Join
Source
GestAge
Alert
Source
Aggregate
Functor
– 院内感染予測
• 心拍数(HR)の変動をモニタリング
• 臨床情報システム(CIS)のモニタリ
ング
• データを融合して敗血症を予測
• ベテラン ICU 看護士より6-24時間
早期に検知
Sp02
Source
Source
Source
Join
Punctor
UDF
Aggregate
Aggregate
Functor
UDF
Aggregate
Join
Baby Crashing: Sp02<85%&& BP<
Aggregate
GestAge for 20 secs)
79
ありがとうございました
80