筆者が並列コンパイラを題材に卒論を書いていた二十数年前、学会では分散処理および並列処理の研究が花盛りでした。SunOSやUltrix、Apollo Domainなどの名前を聞いて懐かしむ読者は私と同じ世代でしょう。

振り返ってみれば、歴史的に計算機トポロジーは集中と分散を繰り返してきています。集中処理の代表であるメインフレームはクライアント・サーバー・コンピューティングの登場によりその覇権を奪われてしまいましたが、IBMは一時点で複数の仕事をさせるマルチタスクの実現のためにVMなる仮想化OSも合わせて提供していました。メインフレームであっても処理の同時性は必須要件であったわけです。ところでVMwareが登場したときに既視感を覚えたのは私だけではないはずです。

少し前にグリッドコンピューティングという、リモートに分散的に存在する分散計算機資源を暫時統合活用して巨大な処理系として有効活用する流れがありました。一旦必要になる計算容量を定義して調達しても、時間の経過とともにその定義は陳腐化しもっと計算資源を欲するようになることは明らかなのですが、その時点で投入できる資金にかぎりがある以上、常識的成長予測を大幅に超える要件定義を最初からすることは許されません。そこで必要な処理要件が増加したときに、その補填に必要な計算機資源をネットワーク上に求めるというコンセプトで解決に挑もうするのがグリッドです。余談ですが、このネットワーク上に存在するメンバー・ノードを活用するというコンセプトは、先般話題のブロックチェーン技術などで一層の発展を見ています。閑話休題。

一般論ですが、必要な計算容量を見積るときにはMFLOPSなどの単位が用いられますが、実際にハードウェアを調達するときには「台」という単位に置き換えられます。1台、2台、3台とサーバーを数えるその「台」です。何台必要か？と考え始めた途端、いきなり完成品がイメージされ、それがサーバーメーカーの標準品であれば単台で動作するために必要な部品としてCPU、Memory、SSD、NIC、GPUなどが一揃え搭載されています。コンピュータ・システムへの計算資源の追加や削減はこの「台」という単位で考察、実施されるわけです。本当はCPU1個を追加できればいいのに、CPU単体を取り出すわけにはいかないので、OSを導入するSSDや他のサーバーと接続するためのNICと一緒になっているサーバーという筐体が単位になるわけです。加えて、この筐体内部に存する部品は他のサーバーと共有することは簡単にはできません。サーバーAに内蔵されているGPUをサーバーBが自由に使うというわけにはいきません。

このように計算機の容量要件、構成要件は日夜変動するのに、いまだに「台」という硬直的な単位でしか応ずることができない現状があるわけです。昔から認識されていたこの課題ですが技術的および経済的なバリアによりこれまで実際的な解決を見てきませんでした。しかし昨今一つの有力解が出てきました。それが「コンポーザブル・インフラストラクチャー（CI）」です。まだまだ商用で使える製品は少ないのが実情ですが、次回はこのCIについて掘り下げてご紹介するつもりです。

（代表　古田　雅一）