効果とメカニズムを探る

ディスクのパフォーマンスがメモリに比べて大きく劣るのは、ハードウェアとソフトウェアの両側面における理由があることを、これまでに説明してまいりました。すなわち、機械的な動作は電子的な動作に比べて圧倒的に遅いという点、そしてディスク・データへのアクセスはファイル管理方式の切換えというオーバーヘッドを伴うという点です。ディスク上のデータへのアクセス頻度が高い基幹業務においては、ディスクがシステム全体のパフォーマンス上のボトルネックになりかねず、望ましいことではありません。IBM i の単一レベル記憶は、ハードウェア的な制約は回避できないながらも、ソフトウェア的な仕組みを工夫することでその影響が出る頻度を最小化する、という方針の元に成り立っています。この章ではその仕組みを探ってみましょう。

単一のIBM i が保持できるメモリとディスクの記憶域の大きさは、合わせて最大2⁶⁴バイトであることは前章で述べたとおりです。ユーザーやアプリケーションからは、仮想アドレス空間とも呼ばれるこの記憶域全体が、TIMI仮想マシン上のメモリに見えています。メモリ内のデータにアクセスするために、1バイト毎に割り当てられたアドレスを利用する点は、他のシステムと変わるところはありません。ただファイルを管理するのにバイト単位では細か過ぎるので、4KBサイズの「ページ」と呼ばれる塊を単位にしています。IBM i の仮想アドレス空間は無数の4KBサイズのページの集合体であり、ある特定の4KBページはメモリとディスクのどちらかに存在していることになります。ちなみに4KBページによるメモリ管理は現代のシステムにおいてかなり一般的とも言えますが、IBM i の単一レベル記憶と異なり、ディスクにまでは及んでいません。

仮想アドレス空間内の各ページは、物理メモリやディスク上に配置・関連付けされています。これを管理するのは、TIMI仮想マシンよりも下層の、すなわちハードウェア寄りにあってマイクロコードに相当する、SLIC（System Licensed Internal Code）の仕事です。ユーザーはファイルすなわちオブジェクトを仮想アドレス空間上で操作するわけですが、それぞれのファイルを構成するページが、その裏側でどこに存在していてどのように移動される、といったことに関知する必要はありません。そして単一のファイルは通常は複数のページで構成され、仮想アドレス空間の中で連続する領域を占有しますが、SLICの最適化ロジック次第なので、必ずしも物理デバイス上の連続領域に配置されるとは限りません。

あるユーザーがプログラムを呼び出す状況を想定してみましょう。指定されたライブラリ名・オブジェクト名に基づいて、システムは仮想アドレス空間上のページを特定し、対応するハードウェア上のページがメモリ内にあるかどうかを調べます。ここでもし見つからなければ、ページはディスクに存在するものとしてその場所を特定すると、メモリ内の未使用の領域に移動して実行します。メモリへのページ移動は「ページ・イン」と呼ばれ、可能な限りそのままメモリ内に留まります。ここで別のユーザーが同じプログラムを起動しようとすると、該当ページは既にメモリに読み込まれていますので、ディスクにアクセスすることなく直ちに実行されます。

このメカニズムは比較的最近のスレッド・プログラムと同様の効果をもたらしますが、IBM i の場合は旧来のプロセス・プログラムにおいて既に実現されているのです。他システムにおいて既存のプロセス・プログラムをスレッド化することは可能ではあるのですが、デバッグの難易度が上がるのと、それなりの作業とテストの負荷がかかると言われています。プロセス・プログラムは無くならないのが実情のようです。

他システムのプロセス・プログラムでは、ユーザーが異なればその作業空間は個別に確保されなければなりません。既に別ユーザー用にメモリに展開済みであったとしても、呼び出されればプログラムは再度ディスクからメモリに移動されます。これは全てのユーザーがシステム資源を共有できるのか、ユーザー別に資源を確保しなければならないのか、の違いです。ディスク・アクセスはメモリの場合と比べて、何万倍もの時間を要する作業ですので、メモリをあたかもキャッシュとして利用できる単一レベル記憶の仕組みは、パフォーマンス上極めて有利に機能します。

メモリ容量はディスク容量よりも小さいのが通常なので、ディスク上の全てのページをメモリに収容することはできません。システムを利用しているうちに、メモリ上の空き領域はいずれ全て使い果たされてしまいます。ここでさらに新たなページをメモリに移動するためには、空き領域を確保するために逆方向、すなわち既に存在しているメモリ上のページをディスクに追い出す必要が生じます。どのページを移動対象にするのか、搭載されている複数のディスク・ドライブの中でどれをその行先にするのか、を決定しなければなりません。ちなみにディスクへのページ移動は「ページ・アウト」と呼ばれます。

書出しページを決定するにあたっては極めてシンプルなやり方、すなわち最も長時間アクセスされなかったページが選択されます。これはLRU（Least Recently Used）方式と呼ばれる、ごく一般的に利用されるアルゴリズムです。一方、SLICはシステム稼動中に各ディスクのアクセス状況を常時モニターしており、その統計情報を参照しながら、最も利用されていないディスクを書き出し先として選びます。システムをしばらく使用しているとIBM i のディスク使用率が自動的に平準化されるのは、この仕組みによるものです。例えば容量一杯までデータが書き込まれた10個のディスクで構成されたシステムに、新たに11個目の空のディスクをインストールすると、平準化されるまでページの書き出し先として選択されることになります。この一連のページの配置と移動は、SLICが全自動で行いますのでユーザーは意識することはありません。

他のサーバーであれば、専任のデータベース管理者が、各ディスクにかかる負荷をどのようにして分散するのかを検討し、各ファイルのディスクへの配置を決定しなければなりません。ディスク容量の限界が近づいたために空のディスクを追加したら、あらためてファイルの再配置を検討する必要があります。一方IBM i においてはこの作業が自動的に行われるために、専任のデータベース管理者を必要とすることがありません。データベース管理者要らず、というのはシステム運用に要する作業負荷、ひいてはTCO（Total Cost of Ownership： 総所有コスト）削減に大きな効果があります。特に他のサーバーからIBM i に移行してきたユーザーが、日々の運用の違いとして最も強く感じるのはこの点です。IBM i に慣れていないと、手を下す術が何もない、と考えて薄気味悪さを感じてしまうケースもあるそうですが、自動運転を前提とした設計になっている、というのが実情です。

単一レベル記憶が人手を要しないパフォーマンス・チューニングに寄与する例を、もう一つ見てみたいと思います。アプリケーションの中で、トランザクション処理のために必ず参照されるファイルがあったとしましょう。IBM i の単一レベル記憶では、当該ファイルは4KBページに分解され、システム内の全てのディスクに分散配置される可能性があります。アプリケーションのレベルでは当該ファイルに高いアクセス負荷がかかることが懸念されますが、物理デバイスのレベルで見ると負荷は全ディスクに分散されることになります。すなわちどれか特定のディスクがボトルネックになることはありません。他のシステムにおいては、ファイルすなわち関連するページは特定ディスク上に集中的に配置されるので、そのディスクへのアクセス負荷の高さがアプリケーション稼働におけるボトルネックとなるリスクがあります。

ストレージ・テクノロジーは、ディスク、フラッシュメモリにディスクと同じSASなどのインターフェースを備えたSSD、さらにそのインターフェースをフラッシュメモリ用に最適化したNVMeと進化を続けています。これらの新しいテクノロジーはプロセッサやメモリに比べれば低速ではありますが、ディスクに比べて極めて高速なので、IBM i の単一レベル記憶によるパフォーマンス効果は薄れ気味になってくるのは事実です。むしろデータベース管理者が不要になるなど、ストレージを管理するための作業負荷が大きく軽減される、ひいては人件費削減をもたらすことのメリットの方が、最近は際立ってきているのではないかと思います。