[db tech showcase Tokyo 2016] E33: こんな方法あり!? 何でもありです! インフラストラクチャレベルインメモリコンピューティング! by 株式会社ネットワールド三好哲生

© PernixData. All rights reserved.
こんな方法あり!? 何でもありです!
インフラストラクチャレベルインメモリコンピューティング!
Re-Think Storage Performance
株式会社ネットワールド
マーケティング本部三好哲生

株式会社ネットワールドの概要
設立
１９９０年８月１日Ｎｏｖｅｌｌ社ＮｅｔＷａｒｅディストリビュータ
事業モデル
ソリューションズ･ディストリビュータ
ビジョン
『ハイブリッド・クラウド・イノベーション』の実現
主要戦略製品
VMware、 Cisco、 EMC、 NetApp、 Microsoft、 TrendMicro、 IBM、 Citrix、・・・
売上高
６６８億円（２０１５年１２月度）
社員数
４２０名（内、１／４が技術本部）
事業所
東京本社、大阪、名古屋、福岡

お前は誰だ?
1981年3月11日生まれ (東日本大震災の日に30歳)
九州出身 (長崎、佐賀、福岡)
好きなもの
ラーメン
お酒
新しいもの
息子
ネットワールドでは以下を担当
クラウド関連製品のマーケティング
最新のIT商材の発掘、ビジネス開発
3

最近では･･･
OpenStackとか、Kubernetesはじめました
4

仮想化の会社が何をしに来た?
仮想化がクラウドになり･･･クラウドでデータベースが動くように
でも、まだまだ･･･
｢今あるデータベース｣を｢そのまま｣クラウドで動かせない
大人の事情 (ライセンスの考え方とか･･･)
その前に解決できる事情 (仮想化すると遅いとか･･･)
5

何を実現するべきか?
制限のない、アプリケーションにとって優れたパフォーマンスをインフラレベルで展開する

データベースにまつわる話 #1
データベースはストレージのパフォーマンス問題の解決のために
過剰に複雑化している
7
• メモリ管理
• 体現ビュー/インデックス
• 新しいストレージエンジン – カラムストア

データベースにまつわる話 #2
データベースはプロプライエタリなインフラ機能に依存している
8
仮想化でうまくいくのでは!
ベンダーロックインによるコスト肥大

インフラストラクチャにまつわる話
そう、データベースの仮想化は当然の流れ、しかし･･･
9
ストレージのパフォーマンスのせいでデータベースの仮想化がうまくいかない!
仮想化統合されたプライベートクラウドの隣にDB環境(サイロ)が･･･

インメモリコンピューティングが答えとなるか?
10

SAP HANA ･･･ Storage Requirementsより
データ : SAP HANAはセーブポイントブロックと呼ばれる変更デー
タを空き領域に書き込むことで、インメモリデータのコピーを永続
化します。その際のI/O操作はデータの利用の状況や、空きブ
ロックの数などで変動しますが、4 KBから16MB(スーパーブロック
を考慮すると最大64MB)になります。各々のSAP HANAサービス
(プロセス)が自身のセーブポイントファイルを別々に書き込みます。
これは標準では5分おきに行われます。
Redo ログ : 障害時にデータを失わず、復元できることを保証する
ために、SAP HANAは一つ一つのトランザクションをredo ログエ
ントリと呼ばれる形状で記録します。各々のSAP HANAサービス
がそれぞれ自身のredoログ・ファイルを別々に書き込みます。一
般的には書き込みのブロックサイズは4 KBから1MBの幅です。
11

SAP HANA on vSphere ･･･
Guidelines for being virtualized with VMware vSphereより
SAPとVMwareは以下のvSphere上で仮想化したSAP HANAのた
めのベストプラクティスに記載されたVMwareのストレージの技術
的な構成を推奨します。特に利用可能な場合、SAP HANAのログ
格納のために作成された仮想ディスクはローカルSSDもしくはPCI
アダプターのフラッシュを利用してください。メインのエンタープラ
イズストレージはSAP HANAをデータセンタへ統合するアプロー
チにおいて利用されます。
12

突っ込みどころ･･･
念のため64MBとか、1MBとか巨大なブロックで書き込みます
その先はローカルSSDまたはPCIeフラッシュを推奨します
13
Hypervisor ハイパーバイザーハイパーバイザー
• •
ハイパーバイザー
HANA
ログファイル
まて、まて･･･
ハイパーバイザーホスト障害時は?
ライブマイグレーション出来ない?
SSDを別のホストに付け替えて復旧?
仮想化の良さが全く使えない･･･。

そもそも･･･Flashは早いけど･･･
64MB、1MB ･･･デカイっ! デカすぎる!
ファイルシステムで自動的に分割されるケースもありますが･･･
14
32KB以上では急激にパフォーマンスが劣化します

本末転倒
これ、インメモリじゃなくて、結局Flashでしょ･･･(もちろんRead
IntensiveなDBであればさほど大きな問題ではありません)
15

ソフトウェア側も進化してきました･･･
16
メモリ
キャッシュ
ライブラリ
インメモリアプリケーション
ユーザーがアプリを開発
Memcached, GemFire
SAP HANA
Oracle 12c
SQL Server 2014
ISVがアプリを対応させる

これまでのインメモリコンピューティング
インメモリキャッシュライブラリへの対応
インメモリデータベースへの対応
インメモリ対応データベースのコスト
17
function get_foo(foo_id)
foo = memcached_get("foo:" . foo_id)
return foo if defined foo
foo = fetch_foo_from_database(foo_id)
memcached_set("foo:" . foo_id, foo)
return foo
end
CREATE TABLE FOO (…..) WITH (MEMORY_OPTIMIZED=ON);
Microsoft SQL Standard ¥153,000
Microsoft SQL Enterprise ¥731,000
Oracle SQL Standard ¥1,050,000
Oracle SQL Enterprise ¥5,700,000
Oracle Database In-Memory ¥2,760,000
誰がやるの? いつやるの?
どのテーブルが適切?
使い始めないとわからない･･･

モチベーション
仮想化の便利さとインメモリの良さを両立する
複雑な設定項目を必要としない(クラウド的に使える)
そんなインメモリコンピューティングに挑みます!
････見つけました。
18

経験豊かな創業者
Poojan Kumar, CEO (Exadata 共同創始者; VMware データグループの長)
Satyam Vaghani, CTO (VMware Storage CTO; VMFS と VVOLS の創造者)
VMware, Oracle, NetApp, EMC等からのエキスパートエンジニアリングチーム
業界随一の支援者達 (Marc Benioff, John Thompson, Mark Leslie, ..)
PernixData: ストレージと仮想化のエキスパート
19

インメモリコンピューティングをインフラレベルで実装する
© PernixData. All rights reserved. 20
メモリ
キャッシュ
ライブラリ
インメモリアプリケーション
インフラストラクチャレベルのインメモリコンピューティング
ユーザーがアプリを開発
Memcached, GemFire
SAP HANA
Oracle 12c
SQL Server 2014
PernixData
ISVがアプリを対応させる
あらゆる
アプリが
対応

戦略的インフラストラクチャプラットフォーム
21
 サーバのRAMとフラッシュをデータ高速化層へと集約
 環境の変更なく劇的にパフォーマンスを向上
Hypervisor
Performance
ハイパーバイザーハイパーバイザー
• •
パフォーマンスの
スケールアウト
仮想マシン
近くで完了
するI/O
パフォーマンス
キャパシティ
データサービス
PernixData FVP ソフトウェア

FVP の革新 #1:
100% 非破壊的
22
再起動、アプリケーションへの変更、運用への変更なし
仮想マシンへの変更なし
ストレージに透過的
あらゆるサーバ
あらゆるストレージ
あらゆるフラッシュ/RAM

FVP の革新 #2:
フラッシュと RAM をホスト間でクラスタ化
23
仮想マシン運用に統合
– vMotion
– DRS
– HA
– Snapshot
– vCloud Director
– SRM
仮想マシンの直近で動作する柔軟なI/O高速化レイヤー
ハイパーバイザーハイパーバイザー

FVP の革新 #3:
耐障害性をもつ書き込みの高速化
24
ハイパーバイザーハイパーバイザーハイパーバイザー
書き込みデータ
コピー 1 コピー 2
Write
Back
完全なデータ保護を実現しながら、あらゆるアプリケーションのパフォーマンスを改善
ACK(完了通知)
コピーは0～2まで設定可能

デステージャー(Destager)
DirtyなWriteを継続的にSANへ書き出し
それぞれのWriteに単一のシリアルナンバーを設
定、加算してゆく
Writeを一塊に
 複数のWriteを同時実行せず、一塊に
 SANへの書き出しも並行して実施
Writeが完了するとFlashへチェックポイントレコー
ドを返却
SAN帯域の平等利用(Fair-Share)のため･･･
 VM単位でデステージャーが処理を分割して実施
 バッチのサイズに最大値を設ける
25
VM
Flash/RAM
Destager
SAN
VMからの書き込み
チェック
ポイント
一塊の
多重化されていない
Write

動作概要
26
VM
Flash/RAM
Destager
SAN
チェック
ポイント
一塊の
Write
1
0
2
1
3
2
4
3
5 6
Flash内に
チェックポイントとし
て記録
SAN内にどのチェック
ポイントまで格納したか
判別するファイルを作成
123
リモートホストへ
も共有
1 2 3

チェックポイントとは?
27
チェックポイントは以下から構成
 シリアルナンバー
 VMのUUID
Write-Backが冗長化されたVMはピアへチェックポイントを転送
プライマリとピアはホストフラッシュ上にチェックポイントを書き込み
プライマリとピアは書き込みのデステージ完了を以下で判断
 シリアルナンバー <= チェックポイント(のシリアルナンバー)
チェックポイントを発行することでリカバリにかかる時間を減らす

スケールアウト型のインフラストラクチャレベルインメモリコンピューティング
28
• 仮想マシンごとにキャッシュを有効にするだけ(プログラミング不要)
• オンデマンドにキャッシュがウォームアップ(スキーマの変更不要)
• インメモリオプションの代わりにFVPと必要に応じてRAMの増設(低コスト)
簡単、低コスト、インメモリ対応待ち不要

DFTM-Z : 調整型メモリ圧縮 –Flash並の価格でRAM利用-
29
1 Writeバッファは非圧縮領域
2 利用頻度の低いものを圧縮
3 圧縮領域から一度非圧縮領域に展開して利用

Writeの継続的なバースト(キャッシュ溢れ)
30
VM
Flash/RAM
Destager
SAN
キャッシュからのWrite ACK
(Flash/RAMのレイテンシ)
SANからのWrite ACK
(SANのレイテンシ)

メモリは高価、Flashでもなんとかイケないのか?
31
Flash
(10-100 µs)
HDD
(1-10 ms)
高速メディアの
採用
データ配置と
文脈理解による最適化
RAM
(100 ns)
レガシー
ハイブリッド
ストレージ
オールフラッシュ
ストレージ
ハイパー
コンバージド
ストレージ
サーバ
アプリケーション
PernixData
インテリジェント
スケールアウトストレージ

Flashをより高速化するテクノロジ : F2
32
FlashハイパーバイザーはFlashよりも速いか?
FVP F2 off 
FVP F2 On 

Flashをより高速化するテクノロジ : F2
33
FlashハイパーバイザーはFlashの特性を改善できるか?
FVP F2 off 
FVP F2 On 

何をやっている?
34
VM
Flash
Destager
SAN
チェック
ポイント
一塊の
Write
F2
Flashが喜ぶI/Oに変換
小さいブロックのI/Oをまとめてから1つのI/Oで
･デバイスとしてのI/O性能を仮想的に上げる
･ FlashのI/O Queueを節約できる
･ SANへの書き込みは元データに復元して
･スモールブロックには効果あり

アプリケーションを理解する – PernixData Architect
35
Read/Writeの割合やブロックサイズ
2軸分析や各VMのワーキングセットサイズ

データベースってどんな種類があるの?
データパイプライン
36

データベースを大別すると4つ
37
OLTP レポーティング OLAP 解析
概要
ATM/Web等
顧客が特定の
データにアクセ
ス、トランザク
ションする
DB内のデータを
集計して傾向や
ビジネスパ
フォーマンスを
分析する
OLTPをドリルダ
ウン分析、特定
の条件の顧客
同行の分析など
様々なテーブル
の数字同士の相
関づけからビジ
ネスパフォーマ
ンス分析
可用性 +++ + + +
同時並行性 +++ + + +
レイテンシの
重要度
+++ + ++ +++
スループットの
必要性
+ +++ +++ +++
アドホック + + ++ +++
I/O操作 R/W混在 Read中心 Read中心 R/W混在
Writeは一時ファイル
レイテンシまたはスループットまたはその両方が重要

ブロックサイズによってはフラッシュは効果が低い
38
メモリで高速化すべきポイント32K以上のブロックサイズ
ベンチマークスコア取得時は512bなど小さなブロックで
Windows OSでは4K~8Kのブロックサイズ
Exchangeサーバなどは32K~64K
データベースは8K~32K
ブロックサイズ÷レイテンシ= スループット
レイテンシ= IOPSの逆数 + H/Wオーバーヘッド
FVPはH/Wオーバーヘッドを最小にする
ただし、高速化メディアのオーバーヘッドはどうする?

ミッションクリティカルシステム : SAP
39

ミッションクリティカルシステム : SAP
40
アプリケーションのI/O待ち時間が劇的に改善 ⇒ CPU利用率の向上

ミッションクリティカルシステム : SQLサーバ
41

新しいアプリケーション : Splunk
42
インフラストラクチャレベルのテクノロジーのため、アプリケーションを選ばない

アーキテクチャで劇的な変化が
43
実アプリケーションでの削減例(SQLのソートクエリ/一時ファイル生成)
データ読み込み
一時ファイルの書き出し
フィルタ処理
ストレージへの書き出し
(結果表示後)
FVP ON
FVP OFF
FVP ON
FVP OFF
FVP ON
FVP OFF
FVP ON
FVP OFF
合計 FVP ON
FVP OFF

キャパシティ
マネージメント
パフォーマンス
PernixDataは｢分離されたストレージ｣の新時代をリード
仮想化データセンタのストレージの最適化は｢ボックスの外で｣考える
• ハイパーバイザーとストレージのインテリジェンスの結合
• ビッグデータをビッグナレッジに
• ITのライフサイクル全体を管理
PernixData Architect ソフトウェア
• 仮想マシン単位でパフォーマンス割当
• アプリケーションが10倍高速化(低遅延)
• コンピューティングと一緒にスケールアウトするIOPS



まとめ
データベースとストレージインフラの間のギャップが有る
– リファレンスアーキテクチャですら、トンチンカン
– インフラ屋として何かできないか? (出来ないとマズイ･･･)
インフラレベルでインメモリを実現するテクノロジー
– アプリケーションを書き換えなくていい
– アプリケーションがどう使われるかは使い始めないとわからない
– ライセンスコストも安くなる?
メモリとフラッシュを使い分ける
– メモリ圧縮
– フラッシュを高速化する技術
– インフラレベルでアプリケーションの要件(ワークロード)を理解する
サーバサイドメディアで超低遅延
– CPUやメモリをいくら足してもダメ、、、なら間違いなくレイテンシ
– アーキテクチャでまだレイテンシを下げられる
結論
– DB(やアプリケーション)を理解すれば、まだまだインフラでやるべきことがいっぱい!

[db tech showcase Tokyo 2016] E33: こんな方法あり!? 何でもありです! インフラストラクチャレベルインメモリコンピューティング! by 株式会社ネットワールド三好哲生

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à [db tech showcase Tokyo 2016] E33: こんな方法あり!? 何でもありです! インフラストラクチャレベルインメモリコンピューティング! by 株式会社ネットワールド三好哲生

Similaire à [db tech showcase Tokyo 2016] E33: こんな方法あり!? 何でもありです! インフラストラクチャレベルインメモリコンピューティング! by 株式会社ネットワールド三好哲生 (20)

Plus de Insight Technology, Inc.

Plus de Insight Technology, Inc. (20)