Weitere ähnliche Inhalte
Ähnlich wie [db tech showcase Tokyo 2016] E33: こんな方法あり!? 何でもありです! インフラストラクチャレベルインメモリコンピューティング! by 株式会社ネットワールド 三好 哲生 (20)
Mehr von Insight Technology, Inc. (20)
[db tech showcase Tokyo 2016] E33: こんな方法あり!? 何でもありです! インフラストラクチャレベルインメモリコンピューティング! by 株式会社ネットワールド 三好 哲生
- 1. © PernixData. All rights reserved.
こんな方法あり!? 何でもありです!
インフラストラクチャレベルインメモリコンピューティング!
Re-Think Storage Performance
© PernixData. All rights reserved.
株式会社ネットワールド
マーケティング本部 三好哲生
- 2. © PernixData. All rights reserved.
株式会社ネットワールドの概要
設立
1990年8月1日 Novell社NetWareディストリビュータ
事業モデル
ソリューションズ・ディストリビュータ
ビジョン
『ハイブリッド・クラウド・イノベーション』の実現
主要戦略製品
VMware、 Cisco、 EMC、 NetApp、 Microsoft、 TrendMicro、 IBM、 Citrix、 ・・・
売上高
668億円(2015年12月度)
社員数
420名 (内、1/4が技術本部)
事業所
東京本社、大阪、名古屋、福岡
- 3. © PernixData. All rights reserved.
お前は誰だ?
1981年3月11日 生まれ (東日本大震災の日に30歳)
九州出身 (長崎、佐賀、福岡)
好きなもの
ラーメン
お酒
新しいもの
息子
ネットワールドでは以下を担当
クラウド関連製品のマーケティング
最新のIT商材の発掘、ビジネス開発
3
- 5. © PernixData. All rights reserved.
仮想化の会社が何をしに来た?
仮想化がクラウドになり・・・クラウドでデータベースが動くように
でも、まだまだ・・・
「今あるデータベース」を「そのまま」クラウドで動かせない
大人の事情 (ライセンスの考え方とか・・・)
その前に解決できる事情 (仮想化すると遅いとか・・・)
5
- 6. © PernixData. All rights reserved.
何を実現するべきか?
制限のない、アプリケーションにとって優れたパフォーマンスをインフラレベルで展開する
- 7. © PernixData. All rights reserved.
データベースにまつわる話 #1
データベースはストレージのパフォーマンス問題の解決のために
過剰に複雑化している
7
• メモリ管理
• 体現ビュー/インデックス
• 新しいストレージエンジン – カラムストア
- 8. © PernixData. All rights reserved.
データベースにまつわる話 #2
データベースはプロプライエタリなインフラ機能に依存している
8
仮想化でうまくいくのでは!
ベンダーロックインによるコスト肥大
- 9. © PernixData. All rights reserved.
インフラストラクチャにまつわる話
そう、データベースの仮想化は当然の流れ、しかし・・・
9
ストレージのパフォーマンスのせいでデータベースの仮想化がうまくいかない!
仮想化統合されたプライベートクラウドの隣にDB環境(サイロ)が・・・
- 11. © PernixData. All rights reserved.
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
- 12. © PernixData. All rights reserved.
SAP HANA on vSphere ・・・
Guidelines for being virtualized with VMware vSphereより
SAPとVMwareは以下のvSphere上で仮想化したSAP HANAのた
めのベストプラクティスに記載されたVMwareのストレージの技術
的な構成を推奨します。特に利用可能な場合、SAP HANAのログ
格納のために作成された仮想ディスクはローカルSSDもしくはPCI
アダプターのフラッシュを利用してください。メインのエンタープラ
イズストレージはSAP HANAをデータセンタへ統合するアプロー
チにおいて利用されます。
12
- 13. © PernixData. All rights reserved.
突っ込みどころ・・・
念のため64MBとか、1MBとか巨大なブロックで書き込みます
その先はローカルSSDまたはPCIeフラッシュを推奨します
13
Hypervisor ハイパーバイザー ハイパーバイザー
• •
ハイパーバイザー
HANA
ログファイル
まて、まて・・・
ハイパーバイザーホスト障害時は?
ライブマイグレーション出来ない?
SSDを別のホストに付け替えて復旧?
仮想化の良さが全く使えない・・・。
- 14. © PernixData. All rights reserved.
そもそも・・・Flashは早いけど・・・
64MB、1MB ・・・ デカイっ! デカすぎる!
ファイルシステムで自動的に分割されるケースもありますが・・・
14
32KB以上では急激にパフォーマンスが劣化します
- 15. © PernixData. All rights reserved.
本末転倒
これ、インメモリじゃなくて、結局Flashでしょ・・・(もちろんRead
IntensiveなDBであればさほど大きな問題ではありません)
15
- 16. © PernixData. All rights reserved.
ソフトウェア側も進化してきました・・・
16
メモリ
キャッシュ
ライブラリ
インメモリ アプリケーション
ユーザーがアプリを開発
Memcached, GemFire
SAP HANA
Oracle 12c
SQL Server 2014
ISVがアプリを対応させる
- 17. © PernixData. All rights reserved.
これまでのインメモリコンピューティング
インメモリキャッシュライブラリへの対応
インメモリデータベースへの対応
インメモリ対応データベースのコスト
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. © PernixData. All rights reserved.
モチベーション
仮想化の便利さとインメモリの良さを両立する
複雑な設定項目を必要としない(クラウド的に使える)
そんなインメモリコンピューティングに挑みます!
・・・・ 見つけました。
18
- 19. © PernixData. All rights reserved.
経験豊かな創業者
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
- 20. インメモリコンピューティングをインフラレベルで実装する
© PernixData. All rights reserved. 20
メモリ
キャッシュ
ライブラリ
インメモリ アプリケーション
インフラストラクチャレベルのインメモリコンピューティング
ユーザーがアプリを開発
Memcached, GemFire
SAP HANA
Oracle 12c
SQL Server 2014
PernixData
ISVがアプリを対応させる
あらゆる
アプリが
対応
- 21. © PernixData. All rights reserved.
戦略的インフラストラクチャプラットフォーム
21
サーバのRAMとフラッシュをデータ高速化層へと集約
環境の変更なく劇的にパフォーマンスを向上
Hypervisor
Performance
ハイパーバイザー ハイパーバイザー
• •
パフォーマンスの
スケールアウト
仮想マシン
近くで完了
するI/O
ハイパーバイザー
パフォーマンス
キャパシティ
データサービス
PernixData FVP ソフトウェア
- 22. © PernixData. All rights reserved.
FVP の革新 #1:
100% 非破壊的
22
ハイパーバイザー
再起動、アプリケーションへの変更、運用への変更なし
仮想マシンへの変更なし
ストレージに透過的
あらゆるサーバ
あらゆるストレージ
あらゆるフラッシュ/RAM
PernixData FVP ソフトウェア
- 23. © PernixData. All rights reserved.
FVP の革新 #2:
フラッシュ と RAM をホスト間でクラスタ化
23
仮想マシン運用に統合
– vMotion
– DRS
– HA
– Snapshot
– vCloud Director
– SRM
仮想マシンの直近で動作する柔軟なI/O高速化レイヤー
ハイパーバイザー ハイパーバイザー
PernixData FVP ソフトウェア
- 24. © PernixData. All rights reserved.
FVP の革新 #3:
耐障害性をもつ書き込みの高速化
24
ハイパーバイザーハイパーバイザー ハイパーバイザー
書き込みデータ
コピー 1 コピー 2
Write
Back
完全なデータ保護を実現しながら、あらゆるアプリケーションのパフォーマンスを改善
PernixData FVP ソフトウェア
ACK(完了通知)
コピーは0~2まで設定可能
- 25. © PernixData. All rights reserved.
デステージャー(Destager)
DirtyなWriteを継続的にSANへ書き出し
それぞれのWriteに単一のシリアルナンバーを設
定、加算してゆく
Writeを一塊に
複数のWriteを同時実行せず、一塊に
SANへの書き出しも並行して実施
Writeが完了するとFlashへチェックポイントレコー
ドを返却
SAN帯域の平等利用(Fair-Share)のため・・・
VM単位でデステージャーが処理を分割して実施
バッチのサイズに最大値を設ける
25
VM
Flash/RAM
Destager
SAN
VMからの書き込み
チェック
ポイント
一塊の
多重化されていない
Write
- 26. © PernixData. All rights reserved.
動作概要
26
VM
Flash/RAM
Destager
SAN
VMからの書き込み
チェック
ポイント
一塊の
多重化されていない
Write
1
0
2
1
3
2
4
3
5 6
Flash内に
チェックポイントとし
て記録
SAN内にどのチェック
ポイントまで格納したか
判別するファイルを作成
123
リモートホストへ
も共有
1 2 3
- 27. © PernixData. All rights reserved.
チェックポイントとは?
27
チェックポイントは以下から構成
シリアルナンバー
VMのUUID
Write-Backが冗長化されたVMはピアへチェックポイントを転送
プライマリとピアはホストフラッシュ上にチェックポイントを書き込み
プライマリとピアは書き込みのデステージ完了を以下で判断
シリアルナンバー <= チェックポイント(のシリアルナンバー)
チェックポイントを発行することでリカバリにかかる時間を減らす
- 28. © PernixData. All rights reserved.
スケールアウト型のインフラストラクチャレベルインメモリコンピューティング
28
• 仮想マシンごとにキャッシュを有効にするだけ(プログラミング不要)
• オンデマンドにキャッシュがウォームアップ(スキーマの変更不要)
• インメモリオプションの代わりにFVPと必要に応じてRAMの増設(低コスト)
簡単、低コスト、インメモリ対応待ち不要
- 29. © PernixData. All rights reserved.
DFTM-Z : 調整型メモリ圧縮 –Flash並の価格でRAM利用-
29
1 Writeバッファは非圧縮領域
2 利用頻度の低いものを圧縮
3 圧縮領域から一度非圧縮領域に展開して利用
- 30. © PernixData. All rights reserved.
Writeの継続的なバースト(キャッシュ溢れ)
30
VM
Flash/RAM
Destager
SAN
キャッシュからのWrite ACK
(Flash/RAMのレイテンシ)
SANからのWrite ACK
(SANのレイテンシ)
- 31. © PernixData. All rights reserved.
メモリは高価、Flashでもなんとかイケないのか?
31
Flash
(10-100 µs)
HDD
(1-10 ms)
高速メディアの
採用
データ配置と
文脈理解による最適化
RAM
(100 ns)
レガシー
ハイブリッド
ストレージ
オールフラッシュ
ストレージ
ハイパー
コンバージド
ストレージ
サーバ
ハイパーバイザー
アプリケーション
PernixData
インテリジェント
スケールアウトストレージ
- 32. © PernixData. All rights reserved.
Flashをより高速化するテクノロジ : F2
32
FlashハイパーバイザーはFlashよりも速いか?
FVP F2 off
FVP F2 On
- 33. © PernixData. All rights reserved.
Flashをより高速化するテクノロジ : F2
33
FlashハイパーバイザーはFlashの特性を改善できるか?
FVP F2 off
FVP F2 On
- 34. © PernixData. All rights reserved.
何をやっている?
34
VM
Flash
Destager
SAN
VMからの書き込み
チェック
ポイント
一塊の
多重化されていない
Write
F2
Flashが喜ぶI/Oに変換
小さいブロックのI/Oをまとめてから1つのI/Oで
・ デバイスとしてのI/O性能を仮想的に上げる
・ FlashのI/O Queueを節約できる
・ SANへの書き込みは元データに復元して
・ スモールブロックには効果あり
- 35. © PernixData. All rights reserved.
アプリケーションを理解する – PernixData Architect
35
Read/Writeの割合やブロックサイズ
2軸分析や各VMのワーキングセットサイズ
- 37. © PernixData. All rights reserved.
データベースを大別すると4つ
37
OLTP レポーティング OLAP 解析
概要
ATM/Web等
顧客が特定の
データにアクセ
ス、トランザク
ションする
DB内のデータを
集計して傾向や
ビジネスパ
フォーマンスを
分析する
OLTPをドリルダ
ウン分析、特定
の条件の顧客
同行の分析など
様々なテーブル
の数字同士の相
関づけからビジ
ネスパフォーマ
ンス分析
可用性 +++ + + +
同時並行性 +++ + + +
レイテンシの
重要度
+++ + ++ +++
スループットの
必要性
+ +++ +++ +++
アドホック + + ++ +++
I/O操作 R/W混在 Read中心 Read中心 R/W混在
Writeは一時ファイル
レイテンシまたはスループットまたはその両方が重要
- 38. © PernixData. All rights reserved.
ブロックサイズによってはフラッシュは効果が低い
38
メモリで高速化すべきポイント32K以上のブロックサイズ
ベンチマークスコア取得時は512bなど小さなブロックで
Windows OSでは4K~8Kのブロックサイズ
Exchangeサーバなどは32K~64K
データベースは8K~32K
ブロックサイズ÷レイテンシ= スループット
レイテンシ= IOPSの逆数 + H/Wオーバーヘッド
FVPはH/Wオーバーヘッドを最小にする
ただし、高速化メディアのオーバーヘッドはどうする?
- 40. © PernixData. All rights reserved.
ミッションクリティカルシステム : SAP
40
アプリケーションのI/O待ち時間が劇的に改善 ⇒ CPU利用率の向上
- 42. © PernixData. All rights reserved.
新しいアプリケーション : Splunk
42
インフラストラクチャレベルのテクノロジーのため、アプリケーションを選ばない
- 43. © PernixData. All rights reserved.
アーキテクチャで劇的な変化が
43
実アプリケーションでの削減例(SQLのソートクエリ/一時ファイル生成)
データ読み込み
一時ファイルの書き出し
フィルタ処理
ストレージへの書き出し
(結果表示後)
FVP ON
FVP OFF
FVP ON
FVP OFF
FVP ON
FVP OFF
FVP ON
FVP OFF
合計 FVP ON
FVP OFF
- 44. © PernixData. All rights reserved. 44
キャパシティ
マネージメント
パフォーマンス
PernixDataは「分離されたストレージ」の新時代をリード
仮想化データセンタのストレージの最適化は「ボックスの外で」考える
• ハイパーバイザーとストレージのインテリジェンスの結合
• ビッグデータをビッグナレッジに
• ITのライフサイクル全体を管理
PernixData Architect ソフトウェア
• 仮想マシン単位でパフォーマンス割当
• アプリケーションが10倍高速化(低遅延)
• コンピューティングと一緒にスケールアウトするIOPS
PernixData FVP ソフトウェア
- 45. まとめ
© PernixData. All rights reserved. 45
データベースとストレージインフラの間のギャップが有る
– リファレンスアーキテクチャですら、トンチンカン
– インフラ屋として何かできないか? (出来ないとマズイ・・・)
インフラレベルでインメモリを実現するテクノロジー
– アプリケーションを書き換えなくていい
– アプリケーションがどう使われるかは使い始めないとわからない
– ライセンスコストも安くなる?
メモリとフラッシュを使い分ける
– メモリ圧縮
– フラッシュを高速化する技術
– インフラレベルでアプリケーションの要件(ワークロード)を理解する
サーバサイドメディアで超低遅延
– CPUやメモリをいくら足してもダメ、、、なら間違いなくレイテンシ
– アーキテクチャでまだレイテンシを下げられる
結論
– DB(やアプリケーション)を理解すれば、まだまだインフラでやるべきことがいっぱい!