第7回　大規模データ処理におけるCPUとI/Oのバランスをどう考えるか

3大ボトルネックを解消すれば終わり、ではない

これまでの連載では、ディスクI/O、CPU、ネットワークI/Oの3つの観点で、大規模データを処理するときのボトルネックの傾向と改善点について説明しました。それらの改善策をすべてを実施すれば、もう何も心配する必要はないのでしょうか？

残念ながら、よかれと思って実施したチューニングがほかの箇所に影響を与える可能性があります。最終回となる今回は、その具体例を見ていきましょう。

データを圧縮した場合、CPUボトルネックが生じやすくなる

大規模データを扱うときは、データの総量を小さくしてストレージ装置のコストを削減するため、圧縮機能の利用を検討することが多いです。

データを圧縮する場合、RDBMSの機能を利用するのが一般的です。たとえばOracle Databaseには、以下のように何種類かの圧縮機能があります。

標準圧縮機能
OLTP圧縮機能（Advanced Compression Optionにて提供）
⇒同一ブロック内で重複しているデータの冗長性を排除し、格納します。
Hybrid Columnar Compression機能（Exadataおよび一部ストレージ機器にて利用可能）
⇒列単位でデータを圧縮して格納します。

しかし、データを圧縮する際には、CPU処理とI/O処理に影響が出る点に注意しなければなりません。多くの実装において、「⁠圧縮」とは以下のことをもたらします。

CPUリソースをより多く要求する
圧縮した結果として、ディスクI/Oのアクセス量は低下する

つまり、「⁠ボトルネック」という観点では、ディスクI/OよりもCPUボトルネックが生じやすいのです。

これは、解凍するときも同じで、「⁠解凍」というオペレーションをCPUに依頼する必要があります。

もともとディスクI/Oの負荷が高いDBであれば、圧縮機能を利用することによりボトルネックが解消し、性能が改善する可能性があります。しかし、もともとCPU負荷の高いDBであれば、圧縮機能によりCPUボトルネックが悪化し、性能が劣化する可能性もあるのです。

圧縮機能を導入する場合、現時点でシステムのボトルネックがどこに生じているのか、ある程度見極める必要があります。

SSDなどを利用するとCPUの負荷は上がる

HDDのレスポンス時間は、メモリ上のデータへアクセスする場合に比べて低速ですが、最近はHDDの代替として、より高速な以下のものを利用することが増えてきました。

Solid State Disk（SSD）
PCIスロットに直結するフラッシュディスク

Exadataでも、フラッシュとHDDを併用することにより、ディスクI/Oのレスポンスを全体的に向上させているうえ、複数フラッシュの同時読み書きを実現することにより、スループットも改善しています。

これらの高速ディスクは、万能なソリューションのように謳われています。たしかに、第2回でもご紹介したとおり、大規模データを利用するときのRDBMSのボトルネックの大半はディスクI/Oです。

しかし、それで問題はすべて解消するのでしょうか？

データを高速ディスク上に配置すると、まずI/Oレスポンスが向上します。SQLの観点で見ると、ディスクにデータを要求してから返ってくるまでの時間が短縮されるので、すぐ次の処理に移れるのはまちがいありません。

ただし、次の処理ではまたCPUを使うので、トータルで見るとCPUを利用している時間が長くなってしまいます。スループットも改善しているので、複数のユーザが利用するときでもレスポンスがあまり低下せず、DB全体のCPU負荷が上がる結果となります。

パフォーマンスの問題を解決するためにディスクを高速化することもありますが、CPU使用率がすでに飽和している場合、思わぬボトルネックを招く可能性があるのです。

ボトルネックは変化するもの

上記2つの例では、ディスクI/Oを改善したことでCPU負荷が増えました。この連載の第4回でもご紹介しましたが、すべてのI/Oボトルネックが解消した場合、システムのボトルネックはCPUとなります。

ボトルネックがCPUになった後は、リソース・マネージャによりCPUの使用率を制限し、適切にリソースを配分するのが理想です。しかし、このアプローチは、「⁠一部の処理を遅くすることで、ほかの処理を速くする」という手段となります。

すべての処理を速くするには、今度はCPUをより高速なもの、よりコア数が多いものに置き換える必要があります。それに伴い、より多くのCPUコアを使い切れるよう、処理を並列化する必要があるでしょう。

そしてCPUボトルネックがなくなったら……今度はどこがボトルネックになるのでしょうか？

ディスクI/O？
ネットワークI/O？

この追いかけっこはいつまで続くのでしょうか？

「ボトルネックがない状況」とは、CPU、ディスク、ネットワークなど、すべてのリソースが均等に利用されている状況を指します。それは、CPU使用率が100％であり、ディスク使用率が100％であり、ネットワーク使用率が100％であり、かつHWおよびOSのどのキューにも待ち行列が生じていないということです。インフラの魔術師でもない限り、そのような状況を実現することはできません。

「ボトルネックをすべて解消する」というチューニング・アプローチをとるのは止めましょう。システムとして健全なのは、次の2つを実現できているときです。

目標性能に達している
（⁠つまり、ユーザがハッピーであるということ）
ボトルネックの箇所が把握できていて、次に改善すべきポイントが明確である
（⁠つまり、拡張の余地が残されていること）

大規模データを扱う場合、高性能なハードウェアを導入することから入る場合も少なくありません。しかし、どこか特定のレイヤーがいくら高性能であっても、一番低速なレイヤが足を引っ張る可能性があります。アプリケーションの特性に応じて机上で検討したり、実機で検証（Proof of Concept、略してPoCとも呼ぶ）することを心がけるようにしたいですね。

最後に

本連載では、RDBMS上での大規模データ処理においてボトルネックとなりやすいポイントと、改善のアプローチについてご紹介しました。モデルを簡略化して細かい説明を省いてしまったので、また別の機会に、より具体的な例や、AWR/Statspackレポートなども交えながら説明したいと思っています。

RDBMSは大規模データには向かないのか？

そんなことはまったくありません。ポイントを押さえて設計およびチューニングを実施すれば、安心して利用することができます。

今回の連載でお伝えした内容が、今後のみなさんの業務に少しでもお役に立てば幸いです。

またお会いしましょう！