仮想コンピュータ、仮想化、バーチャルコンピューティング等について
一言で仮想化と言いましても、アプローチや特性でいくつかの種類があるようです。
仮にこの場だけで、仮想化の方式を大別して識別するために、カテゴリ１、２，３と３のタイプに分けて呼ぶことにします。
＜カテゴリ１＞コンピュータで、コンピュータをエミュレーションするということで、現実には具体的に存在しないコンピュータを演じるプログラムで提供される。これは、CPUを含めてハードウェアの挙動をエミュレーションすることを念頭に作られていて、マシン語の挙動をエミュレーションするタイプです。
＜カテゴリ２＞コンピュータのアプリケーションは結局のところ、OSのシステムコールを呼んで動作しているので、WindowsのシステムコールもLinuxのシステムコールも、FreeBSDのシステムコールも、UNIXのシステムコールも、MacOSのシステムコールも大体似たようなラインナップで揃っていて、ちょっと読み替えたり微調整することで有名なOSならエミュレーションができる。ただし、エミュレーションする仮想マシンのCPUは実物の本体のCPUと異なるとエミュレーションがやりづらいとか出来ないとかになる。
＜カテゴリ３＞本来はコンピュータAなんだけど、コンピュータBやCとしても応答し、サービスを提供する。これは、１台のコンピュータに異なる２つの名前を付けるとか、異なる複数のIPアドレスを割り当てるとか、名前空間を分離して複数台に見せるとか、コンテナとか言われる技法による仮想化。
カテゴリ１の場合、ソフトウェアでコンピュータをエミュレーションするわけですから遅くなります。その代わりデータ破壊など致命傷が発生したとしてもそれはエミュレーションされる仮想コンピュータだけが壊れるだけで、エミュレーションをしている本体のコンピュータには影響が及びません。（最近、影響が及ぶ危険性が発見されたりしていましたが）基本的には、エミュレーションされる仮想マシンで閉じて出来事が起きているだけです。
カテゴリ２の場合、カテゴリ３程は仮想マシン同士が関連していないので、１台のハングアップで、全部がコケると言う可能性は３よりは低いです。そして、速度はカテゴリ１ほど遅くはなくカテゴリ３よりは遅いです。
かたやカテゴリ３につきましては、一人二役とか三役みたいなことなので、どれかで致命傷が発生した場合全体に及ぶリスクはカテゴリ１より大きいです。しかし、実行速度とか、応答性いう点では、エミュレーションをしていないですから、かなり早いです。
つまり、理想はカテゴリ１だけど、現実的には、カテゴリ２や３を選んだほうが安く上がる。ようなことでした。しかし、CPUや、ハード周りもどんどん仮想化対応に成って来まして、カテゴリ１のアプローチでも、高い性能を出せるものが出てきました。
カテゴリ１の代表格は多分、Xenとかその系列だと思うのですが、かたやカテゴリ２のアプローチではKVM等で、カテゴリ３は名前空間の分離とかコンテナとかじゃないかと思うのですが、Dockerはどれかな？とか。
仮想マシン＝Virtual Machine(バーチャルマシン）と書いて、略してVMになりますが。
VMの２文字に含まれる意味合いや概念がどれなのか？
XenやKVMやコンテナやそういう仮想技術の上で動く、仮想コンピュータをVMと言いますし、
または、JavaVM等は、Javaが動作環境として想定している仮想的マシンをJavaVMと言ったりしますし、その他コンパイラーが想定する仮想的マシンもVMと書いたりしますし、あの場合も、この場合も、その場合もVMと２文字で書く事が有りますので、今どのVMの話でしたっけ？というのを意識していないと勘違いしてしまいます。仮想マシンにだけ、VMと書くわけでもなくて、メモリ機構の一つ仮想メモリ機構もVMと書きますし。
一言でVMと言ったって、どの仮想化なんだー。とか、どれを指し示して述べているんだーとか。何について語っているのか最後まで読まないとわからないだけど、しょっぱなから書いている事がややこしくて、最後まで読み進める気力が持たず、冒頭で萎える。
じゃ、VMって、いつからあるんだろう？ということですが。コンピュータが世に出てきて初期にはあったみたいです。IBM３６０シリーズでは、仮想機械や仮想記憶機構があったようです。
ちょっと視点を変えて、高級言語のコンパイラーを眺めてみますと、高級言語でOS自体を記述している例も多いのですが、一般的職業プログラマがOSを記述すると言うのはまれです。UNIXなら、SUNかHPか、IBMか、大手コンピュータメーカ関連に就職でもしないとそんな仕事しないでしょうし、Windowsなら、マイクロソフトに入社しないと、MacOSはAppleに入社しないとそんな仕事をすることはまずないと思います。しかし、LINUXなら、趣味や大学でLINUXの勉強や開発のために、OSのコードを高級言語で記述すると言うシーンはあるかもしれません。
ちょっとずれかけてきましたので軌道修正しますと、OSとアプリケーションの関係性なのですが、OSが、そのOSが乗っかっているハードウェアとしてのコンピュータリソースの管理をしていて、アプリケーションにリソースやサービスを提供することで「環境」を提供します。そして、その「環境」とは、実物のコンピュータではなくて、VMなんです。仮想的なコンピュータです。つまり、OS系プログラマは、アプリケーションにVM環境を提供するお仕事としてプログラムを書きますが、アプリケーションプログラマは、OSが提供してくれる「環境」としてのVMを前提としてプログラムを書きます。これは、例えて言うならお父さんと子どもたちの関係のようでもありまして、子どもたちが生活する部屋や通う学校や塾や食費や学費などの問題を、お父さんが荒れる世間の景気動向や、就労と家庭サービス、子どもたちの勉学・生活一切の手続きを処理して、子どもたちの成長環境を提供しているのに似ているかもしれません。「お父さん、来月夏合宿があるんだ」と言う息子さんの要求に対して、お父さんは、１銀行から下ろしてくる。２給料前借りをする。３借金をする。などの解決策を模索して、要求される来月までに工面しないといけないのですが、コンピュータでもにていて、アプリケーションがOSにメモリ空間３００ｋバイト頂戴。と言う要求をしてきた場合、OSは空いていれば、ほいと渡せますが、ない場合、隙間をかき集めて渡す。つまり、ちょっとそこの席詰めていただけますか？的なガベージコレクションをしたり、メモリの機構を活用して一連の連続した３００ｋバイトの空間を工面するとか、あれこれする事になります。工面できるまでは、アプリケーションを待たさないといけません。だけど、アプリケーションは、言い換えればアプリケーションプログラマは、フローチャートを書いている段階などで、ここで３００Kのメモリー空間を要求して次に初期値でクリアしてとか考えますが、あまり、３００ｋバイト耳を揃えて提供されるまで、待機するとかは考えないと思います。知識としてOSの機構をしっていれば、考察でこのタイミングで待機状態に入る可能性はあるかもとかは予想できますけど。ほぼそんなことは意識しません。と言うか、アプリケーションが処理途中の何処で中断が入って待機状態になるかとか、アプリケーションプログラマの制御権限外での出来事なので考えても仕方がありません。１個のCPU搭載マシンで、何十個ものアプリケーションやサービスやプログラムが同時進行するためには、OS都合で、順次最適化を図りつつ、優先度を考慮して今動けるプログラムをどんどん動かしつつ、待機状態にしたアプリなどを管理しつつ、そのアプリケーションが発行してきた要求の応答を返してあげるなどをしているわけなんですが。こういう構図はOSから見て、アプリケーションがVM環境で動いていると言えるわけなんです。だけど、OSプログラマはこの辺の機構を考える仕事ですが、アプリケーションプログラマはOSの機構を考えるお仕事ではなくて、利用者にどう言うサービスを提供するかを考えるお仕事ですから、OSがVMをどう扱うかについて、あまり考えないことも多いのです。
OSとアプリケーションの構図は、お釈迦様と孫悟空みたいな構図かもしれません。また、ゲストOSとホストOSの関係性もそういうことになります。
現実世界のリアルマシンがシャットダウンしてしまったり故障した場合に仮想マシンもコケる構図は、サービス中断に直結しますから、そうならないように常に予備システムを作っておいて、何処かのリアルマシンが障害でこけても、サービス中断にならないように、速やかに予備システムでサービス継続をする。というのは常套手段であり、映画トランセンデンスでも、人工知能がその手法で、人間が停止させようとして、何処かのシステムをシャットダウンしても、常に予備システムに切り替えつつ、自身は停止せずに成長を続けていったと思います。
だいぶ、話がずれていきましたので。
閑話休題
TK-80のデバッグの仕組みなんですけど、これは、モニタプログラムとハードウェア機構によりユーザーが作ったマシン語ソフトをデバッグできる優れたアイデアが入っていました。
初心者ユーザーがマシン語を組めばまず間違いなく、暴走しますが、TK-80はそんなソフトでもデバッグできる機構を搭載していました。動作モードにAUTOとSTEPが有り、STEPというモードがそれなのですが、この機構は、まさに仮想化の最初の一歩みたいな機構です。いや、すごい、すごすぎる。こんな簡単な回路で。
KT-80作った人たちって頭いいなーと思いました。
種明かしをしたいのですが、ヒントとして、普段の事務作業風景を思い浮かべていただくとして。
机に、会計処理の一式を展開して事務をしているところに、会合の看板を毛筆書きする仕事が舞い込んできた。と言うシーンで、机をお片付けして、毛筆書きする環境を整えるのもいいのですが。机の上のプラスチックシートに会計処理の途中の状態をのせたまま、棚に一旦避難させて、そこに毛筆書きする環境を整えると、会計事務の、状況をお片付けする手間が省けて、再展開する手間も省けて、状態保存もできる。CPUが処理中断して別のお仕事に切り替えて、元の仕事に戻る仕組みは、これに似ていて、CPU内部レジスタを一旦退避させて、割り込んできた仕事が終われば、中断していた状態に戻して中断していた業務を継続するのです。このための仕組みはすでに８０８０AというCPUには組み込まれていました。と言うのがヒントです。
と、ここまで書いたのですが、具体的な解説がWIKIペディアでなされているのに気づきましたので、その場所を記します。
TK-80 Wikipedia の記載の中で「シングルステップ実行」と言う章がありまして、そこで具体的な解説がなされていました。
閑話休題
話題を変えて、昔に流行ったTSS：タイム・シェアリング・システムについて思いを馳せますと、TSSシステムでは、利用者はCOBOLとか、FORTRANとか、BASIC等という、環境をターミナルを通じて提供してもらっていましたが、そのターミナルは、一台の巨大なコンピュータにつながっていていまして、TSSのシステムは、時分割で、利用者毎の処理を切り替えて、応答を返すことで、利用者個々人の環境を提供してくれていました。
だいぶ記述内容が発散してきました。間違った捉え方をしているかもしれませんので、私の記述を鵜呑みにしないでください。
より正確な情報については、各自ネットで調べてください。
老婆心ながら、初心者にありがちなことは、３文字略語を勘違いして読み進めてしまう事です。
TPOを考えよう。え？漫才の？。それは、TKOやろ！。
とか
漫才グランプリのF1に出ていたTPOってさ。え？それは、TKOやろ！。
とか勘違いがすぐにわかればいいのですが。IT関連では時として、完璧に勘違いしかねないので注意が必要です。
EMSと言う言葉でも、その３文字が相当な数の異なる概念を指し示していて、IT用語だけでもたくさん有ります。だからどう言う概念を３文字に省略しているのを勘違いすると、話の内容を相当に勘違いして受け取ってしまいます。ですので、今どの意味で,EMSと申されていますか？などと質問をして、早い段階で知っておかないと、結構な時間を無駄にしてしまいがちです。
EMS（イーエムエス，Electronics Manufacturing Service）
EMS Expanded Memory Specification
EMS：Electronic Mail System
EMS:Express mail service 国際郵便
EMS Electrical Muscle Stimulation 電気刺激を直接筋肉に与えるトレーニングを行う機械
EMS Execution Management Systemの略で、取引執行管理システムを指す。
セキュリティー関連の英語文献とかに、セキュリティーはルールが大切であるとか書いてある場合に、直訳して、そうかルールが大切なのか、よし、みんなでルールについて話しあおう。とか考えると思うのですが。
ルールは人間の振る舞い所作のルールなのか、自分たちの運営するコンピュータシステムやIT環境の実態に根ざした、セキュリティーポリシー策定後に、個別の設備に埋め込む設定や条件としてのルールなのか。を勘違いするとなかなか気づかないことも有りますよということなんです。
ルールと言う言葉が、何を示しているのか？について文面を読み間違ってはいけないですよね。
言葉や名称とそれが表す概念。勘違いすると同じスピーチを聞きながら、聴衆は異なる概念を、頭脳に展開することになります。意思疎通の齟齬が生まれます。それは、説明不十分なのか、聞き手の事前勉強不足なのか。
言葉や名称が表す概念について、ネィテブかそうじゃないかの違いで、脳裏に展開されるイメージや概念は、その幅も方向性も異なってきます。経験値によっても、異なってきます。