CPUのリソースを動的増減する方法
OSカーネルが持つCPUスケジューリング機能は、複数あるプロセスやスレッドのうち1つを選択してCPU上に割り当てます。この割り当て時間はミリ秒の単位で制御されており、別のプロセスに切り替えることができます。1つのプロセスやスレッドがCPU上にいることができる時間の単位が人間の時間感覚よりもかなり短いため、1つのCPU上で複数の処理が並行に動作しているように見えます。
そして、同時に実行状態になれるプロセス数の上限はOSカーネルが認識しているCPUスレッド数です。そのため、CPUスレッド数が増えると、同時に処理可能なユーザーからのリクエスト数や、１つのSQL処理の並列度を上げることができます。
プロセスやスレッドはもともとCPUを占有せずに処理の途中でもその時の状態をメモリーに保存して追い出されるように作られているため、CPU数の増減をOSが認識することができれば、CPUスケジューリング機能がスケジュール対象とするCPUの個数に合わせたスケジューリングをするだけです。
データベース・エンジン側はOSカーネルのCPUスケジューリング機能で割り振られたCPUでプロセスやスレッドの処理を進めるだけなので、データベース・エンジン側では特に何もしなくてもCPU数の増減には対応できることになります。
ここまではOS環境が用意するCPU数をデータベース・エンジンが全て使用するという暗黙の前提を置いていました。また、別の階層でデータベース・エンジンが使用するCPU数を制御する実装があります。Oracle Databaseのようにデータベース・エンジン自体が自身のCPU使用量上限を制御するリソース制御機能を持っているものがあります。ユーザー空間で動作しているプロセスが自分からCPUを手放すことで使用可能なCPU時間に制限をかけています。
データベース・エンジン自体がCPUリソース制御機能を持っていると、複数のアプリケーションが1つのデータベースにアクセスする場合でも、アプリケーションごとに使用できるリソース量を区別して制御できます。これは統合型データベースを構成するのに必要な要素です。
マイクロサービス・アーキテクチャに代表されるような単一アプリケーション単一データベースでシステムを構築する場合、1つのOS環境上では１つのアプリケーションのためのデータベース・エンジンしか動作していないという仮定を置くことができます。そのためリソース制御機能はデータベース・エンジンに実装する必要はなく、その代わりに仮想マシンなどのOS環境のリソース上限枠の制御を使用します。
メモリーのリソースを動的増減する方法
メモリー・リソースの増減というのはOSやデータベース・エンジンが使用できる容量を指します。主にストレージへのアクセス頻度を下げるためにデータをキャッシュする用途の容量です。
マザーボードに刺すメモリー・モジュールはデータベース・エンジンが稼働したまま追加するという運用をするものではありません[1]。メモリー・モジュールを増設や交換するときはマシンの電源を停止して行います。マザーボード上に存在している複数のメモリー・モジュールにはインターリーブしたアクセスが行われ、性能上限はマシンが稼働している間は固定です。
[1] Linuxもメモリーの活線挿抜に対応する機能を持っていますが、交換にはマシン筐体のふたを開けるという操作を行うため、実質的にマシンの電源を落とす運用がなされます。
OSに割り当てられたメモリー容量を削減するには、まずOS上で稼働しているデータベース・エンジンのプロセス群が実際に使用している領域を解放させて空き領域にする必要があります。
メモリーはプロセスがいったん確保すると、そこを長時間使い続けることになります。データベース・エンジンが使用するメモリー容量を削減するためには、プロセスがその領域のデータを使用している処理を完了するのを待ってから解放する必要があります。
Oracle Databaseのようにデータベース・エンジンが確保しているメモリーを動的に増減できるものもあります。データベース・エンジンが使用するメモリーのかなりの部分は、低速なストレージ・デバイスに格納されているデータベースのデータをキャッシュする目的で使用されます。キャッシュ用の領域は容量を削減するとキャッシュ・ミスによって低速なデバイスへのアクセスが増えて性能は低下しますが、動作としては継続可能です。そのため、データベース・エンジンのメモリー容量を動的に削減する箇所はこのデータをキャッシュする領域が対象になっています。
データベース・エンジンは一般的にDRAMをストレージのライトバック・キャッシュとして使用しています。上図を例にすると、（1）最新の更新データはメモリー上にあります。（2）それをストレージに書き戻せば最新のデータはストレージにもあることになります。すると（3）キャッシュ用のメモリーを解放してデータベース・エンジンが使用するメモリー割り当てを減らすことができます。
DRAMのメモリー・スロットはマザーボードの面積のかなりの割合を占めますが、容量上限はストレージ・デバイスに比べてかなり小さく、かなり貴重なリソースとなります。第7回で説明したように、インメモリー・データベースはDRAMに格納できるデータ容量がデータベース・サイズの上限になってしまうため、単一インスタンス構成のスケール・アップ型は用途が限定されます。インメモリー・データベースでメモリー容量を増やすには物理マシン複数台で構成するスケール・アウトの手法がとられます。
まとめ
パブリック・クラウドが普及してハードウェアの調達は短時間でできるようになりましたが、データベース・エンジンが使用できるハードウェア・リソースを動的に増減できるかは別の話です。
技術的にリソース上限枠の動的増減に対応しているものもありますが、パブリック・クラウドの課金の仕組みで使用したリソースに比例した額を支払うことになっているものもあります。
データベース・エンジンが使用できるリソースを技術的に制限するにしても様々な階層があります。今回はまず1台のサーバー・マシンの中のCPUとメモリーを増減する実装について扱いました。
次回はストレージの動的な増減について見ていきましょう。
