フラッシュ・ストレージを導入すればCPUコア数は本当に減らせるの？──データベース性能は“わんこそば”で考えよう!：データベース基盤と管理の「それって本当？」――スペシャリストが真実を暴く（1/3 ページ）

「フラッシュ・ストレージを導入すれば、データベースが高速化する」という話と合わせて、「フラッシュ・ストレージを導入すれば、データベース・サーバーのCPUコア数を減らせて、コスト・メリットもある」という話を聞いたことがないでしょうか。「ストレージが速くなったのだから、代わりにCPUを減らせる」と言われると、なんとなくそんな気もするかもしれませんが、果たして本当なのでしょうか。[パフォーマンス改善][Oracle Database 12c][Engineered System]

[PR／＠IT]

PR

日本オラクル 柴田竜典

　こんにちは、日本オラクルのシバタツこと、柴田竜典です。データベース・パフォーマンス・チューニングに関わって12年になりました。チューニングというと、パラメーターを細かくあれこれいじるというような手法をイメージされる方もいるかもしれませんが、実際にはそれで性能向上する量は、良くて2倍とか3倍程度です。何十倍、何百倍の桁違いな性能向上を実現するには、データベース・システムのボトルネックを発見して、それを取り払うことが必要です。今回のテーマは、この “ ボトルネックはなにか” という感覚を磨くのに適していますので、ちょっと腰を据えて考えてみようと思います。データベースの深い知識は不要です。コンピュータの基本的な知識を思い出してもらうだけで十分です。

　ストレージをフラッシュ・ドライブにしたり、メイン・メモリーを増やすことでストレージIO自体を減らすことがスループット向上に貢献するという点は事実だと思います。しかし、その高速に読み込んだデータを処理するCPUが足りなければ、全体のスループットは伸びないはずです。“ボトルネック”とは「ビン（ボトル）から注げる水の量は、たとえビンの底がどんなに広くても、ビンの細くなっている首のところ（ネック）の狭さで決まってしまう」ということのたとえです。ストレージをビンの底、CPUを注ぎ口とした場合、「ビンの底を広げれば、注ぎ口は狭められる」という主張に違和感はありませんか？ 私ならジョッキを用意します。

そうだ! わんこそばで考えてみよう!

　コンピュータ処理を“わんこそば”でたとえてみます。そばをお椀に給仕してくれる人がストレージ、そばを食べる人がCPUです。給仕してくれるミサエさんは1杯のそばを4秒で準備でき、食べるタケシくんは1杯のそばを6秒で食べられるとします。ミサエさんがそばの準備を終えたにもかかわらず、タケシくんが前の1杯をまだ食べ終えていない場合は、ミサエさんはそばをもって待ち構え、タケシくんが食べ終えたと同時に給仕できるものとします。

　このとき、ミサエさんが2倍速くなって、1杯のそばを2秒で準備できるようになっても、タケシくんが1杯のそばを6秒でしか食べられないままであれば、1分間で食べられる量は10杯（＝60秒÷6秒）で変わりません。タケシくんがミサエさんより遅い、つまりタケシくんがボトルネックだからです（図1）。

図1　ミサエさんの準備スピードが速くなってもタケシくんの食べるスピードが変わらなければ、CPU 時間当たりに食べられる杯数は変わらない

　そこで、タケシくんと同様に1杯のそばを6秒で食べられるノリオくんを増やして、食べる人が2人になれば、1分間で食べられる量は2倍の20杯（＝60秒÷6秒×2人）になります。「ストレージが速くなったら、CPUコア数を増やす必要がある」という、「ストレージが速くなったのだから、その分CPUを減らせる」とは真逆の結論となりました（図2）。

図2　ボトルネックとなっていたCPU を追加したことでデータ処理量を増やせる

　逆に、ミサエさんの準備が1杯4秒のまま、タケシくんとノリオくんの2人を対応したらどうなるでしょうか。ミサエさんがタケシくんとノリオくんより遅くなり、ボトルネックがミサエさんになってしまいました。つまり、「CPUが増えたら、ストレージを速くする必要がある」とも言えるということです（図3）。

図3　CPUを増やしてもストレージが変わらなければ、ストレージがボトルネックに

　コンピュータのCPUがI/O待ちしている場合、そのCPUはI/Oをぼけーっと待っているわけではなく、並列して実行されている別の処理を行えます。Linuxのvmstatでは、wa（I/O待ち時間）とid（アイドル時間）が別項目なので、I/O待ちという仕事中のように勘違いしやすいですが、Solarisのvmstatではwaはidに含まれ、区別しません。タケシくんはミサエさんがそばを準備している（I/Oしている）間、ぼけーっと待っている必要はなく、別のそばを食べ続けられ（ほかの処理を行なえ）ます。

　“性能”と一言で言っても、「1分に何件処理できるか」というスループットと、「1件を何分で処理できるか」というレスポンス時間は、明確に分けて考えないといけません。なぜなら、ほとんどのエンタープライズ・システムでは、1台のマシン内で複数のプロセスが並列に動いているからです。並列数を増減させるだけでスループットは増減しますが、レスポンス時間は並列数を増減させても変わりません。そして、このスループットを改善するためには、ボトルネックではないミサエさんをいくら速くしても効果がなく、ボトルネックであるタケシくんを助けるためにノリオくんを投入する必要がありました。