フラッシュストレージで、このデータベースは速くなる？ならない？：データベース高速化のいま（1）（3/3 ページ）

» 2015年09月02日 05時00分公開

思ったほど速くならない？性能劣化の落とし穴

　ここまではフラッシュストレージによってデータベースを高速化した例を見てきた。だが、「フラッシュストレージさえ適用すれば、データベースシステムが必ず速くなるというわけではない」と森山氏は指摘する。

　森山氏によると、速くならない代表的なケースは「SQLの設計ミス」だという。フラッシュストレージに置き換えた際に、CPU負荷が下がらず、想定するパフォーマンスが出ない場合は、SQL設計の問題が隠れている可能性が高いという。

　ストレージI/O待ちによるCPUビジー状態が目立つ場合、SQLの中にあるムダは露見しにくい。また、その状態でもI/Oボトルネックの影響の方が大きいため、問題にならないことも多いが、フラッシュストレージ導入時には大きな影響を与える可能性がある。SQL見直しの他にも、CPU負荷低減のためにサーバー増強やSQL処理の並列化が必要となる場合もある。「事前アセスメントが重要な理由もここにある」（森山氏）という。

フラッシュストレージによるコスト削減の可能性

　一方、冒頭で「サーバー集約やソフトウエアライセンス費削減などを含む、総コストで比較した場合には、フラッシュストレージ導入に優位なケースが増えつつある」と述べたように、フラッシュストレージによってI/Oボトルネックが解消し、CPU使用効率にムダがなくなることで（CPUが処理待ちではなく、能力に見合った処理を続ける状態が実現すれば）、CPUコア数を削減できる可能性も見えてくる。コアライセンス契約でデータベースを利用している場合には、直接的なコスト削減も期待できる。

　森山氏は劇的なコア数削減の事例として、ある国の公的機関が持つシステムの事例を挙げる。リアルタイム性が重要なシステムだったが、運用中にI/O遅延が頻発、サーバー台数を追加して負荷低減していた。

　この事例では、肥大化したシステムの性能を高め、集約する目的でフラッシュストレージを導入。I/O遅延がなくなりサーバー負荷も減ったため、システムリソースに余裕ができたことから、サーバー仮想化による集約も実現した。具体的には、90CPUを8CPUに、物理サーバーは45台を2台に集約して運用できるようになったという。

この事例ではストレージI/O改善を契機に、CPUやメモリなどのリソースを使い切る構成を実現。サーバー仮想化による集約で物理サーバーを大幅に削減している

PoCで注意すべき「経過時間による性能の問題」

　最後に、フラッシュストレージ選定時の注意点も挙げておこう。それは「経過時間による性能劣化問題」だ。この問題は、フラッシュストレージの特性に起因する。

　フラッシュストレージはディスクストレージと異なり、「データ上書き」や「削除」処理の実体は、「上書き」でも「削除」でもない。「削除」に対しては「ブロック単位で0のデータを書き込む」処理が行われ、「書き込み」はどのようなデータサイズのものでもページ単位で領域を占有する。「上書き」は、いったんデータを消去し（0を書き込み）、新たにデータをページ単位で書き込む。

　いずれの処理においても、データやメタデータの移動や再書き込みが必要だ。そのため「8Kバイトの上書きであっても、実際には16Kを書き込んでいることもある」（岩本氏）。これを「ライトアンプリフィケーション（WA：Write Amplification）」という。

ライトアンプリフィケーション（出典：Wikipedia日本語版）

　フラッシュストレージ製品では、実行容量として示されるボリュームとは別に、「スペアブロック」として、隠れた領域に一定容量のストレージを確保し、WA処理に対処している。それでも「大量I/Oが発生する場合にはスペアブロックもすぐに埋まってしまう」（岩本氏）。

　そこでスペアブロックが枯渇しないよう、何らかの方法で定期的にガベージコレクションを行い、データブロックのムダを整理して新たなスペアブロック領域を作り出すのだが、この実装次第では、時間が経過するごとに動作に影響を及ぼし、パフォーマンス劣化の引き金になることがあるという。

　「短期的には高いパフォーマンスで要件を満たしていても、長時間I/O負荷をかけ続けたときに当初のパフォーマンスを維持できるものとそうでないものがある。細かな更新が多数発生し続けるシステムの場合、PoCでは12時間程度の長時間でのストレステストを実施し、パフォーマンスに問題がないかを確認すべきだ」（岩本氏）という。

「データベース高速化のいま」バックナンバー