IBM i のウンチクを語ろう
～ その6：IBM i のウンチクを語ろう ～ 単一レベル記憶-1 ～
皆さん、こんにちは。今回のテーマは単一レベル記憶です。AS/400生みの父と言われるFrank Soltis博士はSingle-Level Store、巷ではしばしばこの頭文字を取ってSLS、と呼んでいるテクノロジーです。テクニカルにはディスク領域も全てメモリと見なす仕組み、またはディスクとメモリとの区別をしない仕組み、だと説明できますが、これだけだと「だから何？」という疑問しか残りません。これまでIBM i の代表的なアーキテクチャーをいくつか解説してきましたが、その中で最も説明しづらく、話すと長くなる傾向があるのがこれです。前提として述べなければならない事がいくつかあるためなのですが、せっかくの機会ですので、端折ることなく何回かに分けてじっくりと説明していきたいと思います。
さて、そもそも単一レベル記憶は何を目的として設計されたのかと言いますと、ディスク・アクセスのパフォーマンスの懸念を解消することにありました。システムは稼動する際に、プロセッサ、メモリ、ディスクの三者を主に利用しますが、この中で最も遅いデバイスがディスクだというわけです。いくつか製品のスペックを参照しながら例を挙げて見てみましょう。プロセッサが動作する際の最小の待ち時間単位は1クロックです。3GHzで動作するプロセッサがあったとしたら、その待ち時間は0.333×10-9秒です。メモリについては、プロセッサから要求を受け取ってからデータを返すまでの遅延時間が70ns（ナノ秒）だとしたら、その待ち時間は70×10-9秒、すなわち210クロックに相当します。同様に遅延時間5.4ms（ミリ秒）のディスクは5,400,000×10-9秒、すなわち16,200,000クロック相当になります。10-9秒と言っても生活感が出ないので、仮に1クロックを1秒とおいてみましょう。そうするとメモリの遅延時間は3分30秒、ディスクに至っては約半年にも相当します。1秒に一つの仕事をする人が、ディスクに向かって「ちょいとデータを拾ってきてくれ」と頼むと、「あいよ、でも半年待ってね」となるわけです。「こいつはやる気があるのか？」と言いたくもなりますね。
これほどの大きな違いは、プロセッサにせよメモリにせよ遅延は電子的なものであるのに対して、ディスクの場合は機械的なものであることに理由があります。すなわちデータ読み取りのためのヘッド部分を行きつ戻りつさせ、磁性体を塗布した円盤（プラッタ）を回転させるために、モーターを利用しているわけですが、電子的なものに比べて圧倒的に遅いのです。そして近年の技術革新は記憶容量が大きくなる方向には進んでいますが、遅延時間の短縮化の方はほとんど進捗がありません。例えば現在最高速のディスク円盤は分速15,000回転を達成していますが、A Brief History of Disk Storage（http://www.lewan.com/blog/2015/04/02/a-breif-history-of-storage）によると、この速度を最初に達成したのは2000年であり、以降の高速化はなされていません。これまでは、多くのディスク・ドライブを実装して負荷を分散させたり、キャッシュを大容量化するなどして高速化を実現してきました。昨今のシステムでは手詰まりになりつつあるため、フラッシュ・メモリ・テクノロジーを活かしたSSD（Solid State Drive）の採用によって、ディスクがボトルネック化するのを防ぐ傾向があります。それでも遅延時間0.12ms（ミリ秒）だとすると、ディスクよりも圧倒的に高速ではありますが、360,000クロック、先の例に従うと100時間にも相当しますので、プロセッサやメモリに比べると十分に低速です。
実際のシステムにおいては、プロセッサとメモリないしはディスクとの間に、より高速なキャッシュとかバッファと呼ばれるメモリが介在するため、できる限り「半年も」待たされることがないような工夫が施されています。ディスク上のデータ全ては無理にしても、頻繁にアクセスしそうな一部のデータだけでもメモリに取り込んでおけば、何とかできそうです。何か調べ物をしようとした時に、都度図書館に出かけなくても、関係のありそうな本を数冊借りておけば便利なのと同じ理屈です。しかしながら特にビジネス用アプリケーションにおいては、アクセスしたいデータは一所にまとまらずに、ディスクのあちこちに散在する傾向があります。調査するべき範囲が広大なので、数冊の本が手元にあるだけではあまり役立たないのと同じです。データの局所性の高い、すなわち演算対象になるデータがディスク上に連続的に配置されている傾向の強い科学技術計算に比べると、キャッシュやバッファの効果は出にくいと言われています。ビジネスのためのシステムであるIBM i にとっては何とかしたいところです。これは、稼動させるアプリケーションのタイプによって、ハードウェアのチューニングを施すべきポイントが違うことの一例です。いずれにせよディスクの遅延時間が、システムのパフォーマンスを制約するボトルネックになる可能性があるわけです。
最近では、メモリ容量を十分に巨大化させておいて、ディスク・アクセスを経由しないでシステムを稼動させてしまおう、という力づくの考え方も登場しています。インメモリ・データベースがその例です。ただ、容量あたりコストはディスクの方が圧倒的に安いので、効果を見極めてから実装することになります。
さて、これまでハードウェアのパフォーマンスについて述べてきましたが、ソフトウェア面においても考慮するべき点があります。それは科学技術計算よりもむしろ、ビジネス用システムにおいて顕著です。特にIBM i のような統合型システムですと、同時に複数のプログラムが稼動し、複数のユーザーがアクセスします。ミクロ的に言うと、システムは一時点に一つの作業を実施するのが基本にありますので、時間を細かく切り刻んで、高速に複数のタスク（仕事）間で切り替え（コンテキスト・スイッチ）を行います。銀行で一人の係員の方が、窓口間を高速移動しながら同時に複数の人に向けてサービスを提供するようなものです。ビジネス用システムにおいては、タスク切り替え頻度が高いため、これをどのようにして短縮するのか、という課題があるわけです。パフォーマンスと言うと、仕事を完了させるための経過時間を気にしたくなりますが、複数の仕事を同時処理するための、時間あたり総仕事量（スループット）も重要な指標なのです。
タスクの呼び出しがかかると、システムは作業領域をメモリ内に確保します。別のタスクの呼び出しがかかると、再度あらためて作業領域を確保します。ここで両作業領域に割り当てられる仮想アドレス空間が同一になると、切り替えに際して作業中データを一時的にどこかに退避させなければなりません。タスク間で通信を行おうとすると、処理はさらに複雑になります。これに対して、複数の作業領域を常駐させるだけの大きな仮想アドレス空間が確保されていて、データを退避させたり呼び戻したりする必要性がなければもっと処理は単純化できますし、パフォーマンスが向上する事が期待できます。ロチェスター開発部門は、作業領域常駐型と切替型とを比較して、前者のシステム・プログラムのステップ数は約半分、すなわちパフォーマンスは二倍になることを見極めました。選択すべきは作業領域常駐型です。
ちなみに上記タスク管理の考え方は旧来のものであり、現在はスレッドと呼ばれるより軽量化されたプログラミング・モデルが採用されるケースが多くなってきました。スレッドに割り当てられる資源量は極めて小さいので、切り替えが速いというメリットがあります。ただしスレッド対応化されていない旧来プログラムを、スレッド型に書き換えるには多大な負荷がかかります。結局スレッドは今でも万能の答えにはなりません。
そろそろ紙面も尽きてきたようです。次回も続ける予定です。
