＠IT DB高速化道場 メモ

メモ

■日本最大級の不動産総合サイト「アットホーム」のサービスを支える情報システム
・ハードウェアのファームウェアをアップデートしたところ、IO driveが見えなくなってしまった。
・exFlrash DIMMはファームウェアが安定しない。実行可能なファームウェアが限定される。
　1つのメモリが壊れた時にすべて仮想OSを別のサーバに移動した後しかメモリ交換を行えない。
・Violimemoryはチューニングが必要ないところが導入が楽。
　ガベージコレクションのメンテナンスが面倒。一定値を超えるとIOPSやレイテンシーに影響がでる。
・ストレージ選択は運用のしやすさがポイント。ファームウェア履歴や故障率の調査をすること。
・フラッシュ製品の導入をすることで全体的にコストダウンが見込める。

■ORACLE DB のパフォーマンス最適化への現実解とは？
・近年の動向として、DBへの投資はパフォーマンスが一番多い。
　パフォーマンスのために設計やメンテナンスコストが大きい。
・ORACLE ASM / ファイルシステム / ボリューム が事前に割り当てられている。
　多くのAFAではガベージコレクションをトリガー
　本当にパフォーマンスに大きな影響が出る。また、SSDの寿命にも影響f出る。
・平均サービス時間は完全なパロメーターではない。
　最適なユーザーエクスペリエンスを保てるか。
・コンテンツベースのデータ配置
　ガベージコレクションはシステムベースではなくハードウェアベースにすることで全体的なコントロールをハードウェアが行ってくれるため安定する。
・ベンチマークは長時間実施すること。数日間のテストでも性能劣化がないことを確認できると良い。
・スナップショットをうまく使うことでメンテナンス・寿命を効率的に行うことができる。
・データベース統合はかなり難しいため、ストレージ統合をすることで実質的なデータベース統合を目指す
・STATSPACK を利用して診断。OracleDBにバンドルされている。
・リプレイス前後でDB診断するのが良い。
　前は問題点分析、後はベンチマークとして利用する。

■技術が生み出す魔法！最新ハードウェアとチューニングで激速データベース
・DB CPUのwaitが発生しているはず。DBが待ち時間になっている。
　ストレージのアクセス分析を分析することでわかる。
・ブロック長を見て、レスポンスを見ると良い。
　ブロック長を長くするとIO数が減る。
　ただし、OSの設定と整合性が合わなくなることがある。
・IO多重度を考える。
　ブロック長が長い場合は多重度を上げた方がよい。
・ストレージの性能向上
　HDDを増設してLUNのストライピング数を増やすのは従来の対応。
　SSDを導入する方が安くて早い。ただし、コントローラの性能限界に来ることが多い。
・DBの高速化にはCPUをたくさん使おう。
　使っていないDBが多い。
　CPUはクロック数はアップせずコア数が増えている。
そのため、アプリケーションもそれに合わせたものにしないといけない。
・バッチ処理中はCPU負荷100％にすること。
　SYSは25％以下にする。25%以上の場合、全体的な設定の問題。
・並列できないDB製品を採用している場合があるため注意。その場合はクロックが高い製品を採用する。
　並列できる製品を利用していても並列設定をしていないまたは誤った設定をしているケースが多い。
・メモリが潤沢の場合、インデックスがない方が早い。(準オンメモリ)
　メモリを潤沢にした方がCPUが不要になるためDBライセンスが下がるため、メモリにお金を使った方が安い。
　また、ハードウェア全体のコストで考えた場合、メモリ潤沢の場合IAよりもUNIXの方が安い。
・ブロック長
DHW：１M以上、最近は４M
OLTP：8k～16k
・ファイバーチャネルは何本もつけて並列処理できるようにする。
・サーバとストレージの間にキャッシュ装置を入れると性能劣化する場合があるので慎重に。
DBのwaitが増えて遅くなることがある。
・ロード処理をする場合は1回にまとめた方がよい。こまめにやるとキャッシュを使えず遅くなることが多い。

■データベースのIOボトルネックを解消！！～HGSTの最新NVMe SSDソリューション～
・NVMe
PCI Express Flrashの標準化団体
これによってOS、サーバとの相性を意識する必要が少なくなった。
・HGSTの性能データはガベージコレクションが発生している状態で起債している。
・HGSTはもともとエンタイープライズ向けのHDDメーカーであるため、テスト要件が非常に厳しい。
・PCI Express Flrash を利用する場合、以下に並列を向上させるかがポイント。
　1処理あたりの処理時間はこれ以上はなかなか早くならない。

■クラウド基盤で実証されたデータベースの高速化
・アプリケーションが遅くなると
　Google 0.5秒遅くなるとと20％減
　Amazon 500ミリ秒遅くなると売り上げの1％ダウン
・PCIeアプリケーションアクセラレータは
　NANDフラッシュ＋PCI express＋ソフトウェア(VSL)
　でSSDをマザーボードに直結させて早くする。
・メリット
　高パフォーマンス
　低レーテンシー
　今のカードでRAID50 相当になっているため、データ保護が高い。
・RAMディスクの技術を採用している。
・元io drive。
　Sandiskに買われた。
・2008に初めてSSDがストレージに採用された。
・SSD iodrive
UBER　10^-16～17　10^-20
1枚当たりのリードエラー発生頻度　7セクター/念　1セクター/1000年
1000枚当たりのエラー発生頻度1セクター/時間　1セクター/日
・システムが求める3つの要件
　TCO、速度ベース、容量ベース
・オンメモリで処理しているシステムはPCIeを使っても早くならない。
・IDCの性能フェス「サバフェス」
・10月下旬にMySQLベースのDBパフォーマンスの話を聞くことができる。

■データベース環境における検証結果から理解する失敗しないフラッシュ活用法
・cMLX、TLCを扱っている企業は今後も安くなる見込みがあるが、それ以外のSSDを採用している企業は安くならない。
　SASの製造をやめる企業が今後増えていくため高くなっていくことが想定される、
　SASとSSDは2018年ごろには逆転する。
・ALL Frash FASでオールフラッシュの場合7年保守が選択できる。
・ミッドレンジ(20TB以上)の場合、SSDの方が安くなる。
　ハイエンド(40TB以上)の場合、ALL Frashの方が安い。
　しかし、100TB以上だと無理。
　※目安
・FASは安定性を重視している。HGSTも安定しているがFASよりも速度が倍程度。
・データベースは圧縮で性能をアップ。
　対外のストレージベンダーの性能データは重複排除が最高の時になっている。
・ベンチマーク結果等が書いてあるブログ。
tech ontap フラッシュ
・よさげなベンチマークツール
swingbench
・ハイエンドモデルをかった方が性能対比のコストは圧倒的に安い
・オールフレッシュベンダーがフラッシュの力でエンタープライズをスタンダードにしようは無理。エンタープライズとスタンダードの差の性能をフラッシュだけでは買えない。特に圧縮したときの性能アップはフラッシュではどうにもならない。

■楽天証券を支えるデータベース基盤と処理高速化への取り組み
・証券システムは09:00～09:05が一番トランザクションが高い。
　お昼、夕方も多いが上記の半分以下。
・Oracle Exadata V2 FULL Rackを3台
　2台本番で1台開発機
　期間DB44、Physical DB4、Logical DB4で構成
・約1年で V2からX3に移行。性能は10倍にすることを求められた。
・物理メモリを1.47TB→3.072TB
　Flash Cach 13.8TB→22.4TB
・huge pagesを採用。4kB→２MB
・本番とスタンバイを別々にした。
・すべてのHDDに均等に配置されるようにデータサイズを調整した。