クラスタ・分散・高信頼システムに関する世界観です。
僕は、自分のプログラミング技術の勉強として、並列コンピューティングを学ぶことを目標にすることにした。
きっかけは、Webに対して限界を感じたことである。
Webは、CGIのように、ひとつひとつのページの中でプログラムが完結していて、別のファイルを読み込めるとは言っても、データの共有などは最小限であり、スタンドアローンのプログラムと比べると見劣りする。
僕の知識不足かもしれないが、Webでテキストエディタやワープロ・表計算ソフトなどを作るのは非常に難しいと思う。
よって、僕はPHPやRubyやJavaScriptといった言語は、最先端の流行プログラミング言語と言っても、本当のプログラミング技術ではないと思う。
本当のプログラミング技術とは、C/C++やJavaといった言語を用いた、スタンドアローンのプログラムだと思う。
そして、最近は並列処理言語が流行っている。Scala, Golang, Erlang, Rustといった最先端の言語は、並列処理に基づく設計の考え方をしている。また、LinuxやFreeBSDは古くから存在するOS技術でありながら、ほかのOSを並列処理を含めた高パフォーマンスで圧倒している。
これらの言語と技術は、スケーラビリティをその優越性としている。ひとつのマシンだけで高性能を発揮するのではなく、たくさんのマシンがクラスタのようにネットワークで結びついて、高パフォーマンスを叩き出すのである。
よって、並列コンピューティング技術は、決して昔のメインフレーム上のFORTRANやCOBOLやオープン系クラスタのような古い技術ではなく（これらの古い技術も今でも現役だが）、とても新しく最先端の技術なのである。
そして、僕は並列コンピューティング技術を研究した人に、プログラミングの高いスキルを持った人が多いと個人的に感じている。本や書籍の著者を見ても、並列コンピューティングを大学時代に学んだという人は僕の主観として多く感じる。並列コンピューティング技術は、プログラミング技術を学ぶ上で、スキルアップのために非常に有効なのである。
また、並列コンピューティング技術は、とても社会のためになる技術である。人工知能は監視に利用され、WebはSNS上のフェイクやいじめなどといった問題があり、ネットゲームは依存症の問題がある。これに比べて、並列コンピューティング技術は、特に医学上の薬やワクチンといった病気を治すための技術だったり、気象観測や気象災害の予測といった気象のための技術だったりと、とても社会にとって有益かつためになる技術だと思う。
僕は、並列コンピューティング技術とともに学ぶ言語として、Javaを選ぶ。Javaを選ぶ理由は、JavaにはJavaBeansやRMIといった、Java独自の分散コンピューティング技術が多いからだ。CORBAのような標準規格ではなくても、Javaはとても分散コンピューティングに適した言語である。同時に、Javaだけを学ぶのではなく、FORTRANやC/C++やPythonといった、科学技術計算やシステムに必要な言語は学ぶことが必要となる。あるいは、プログラミング技術だけではなく、数学、物理学、生物学、化学、地学、気象学、天文学といった、理系の学問はすべて、プロの学者並みに分かっている必要がある。そうでなければシミュレーションをするための計算プログラムが書けない。
そして、多くの並列コンピューティングに使うためのライブラリやフレームワークの知識も必要だし、アルゴリズムやデータ構造についても学ぶ必要がある。デザインパターンについては、通常のデザインパターンだけではなく、マルチスレッドに基づくデザインパターンもきちんと学ぶ必要がある。
そして何より、コンピュータ資源が必要だ。大学や研究機関のような、たくさんのコンピュータ資源が使える環境がなければ、並列コンピューティングを研究することはできない。だから、大学に入るために受験勉強から取り組まなければならない。そのためには高校の数学や理科の勉強が必須だ。もちろん、英語や国語や社会科についても勉強が必要となる。
よって、本当は、僕が実際に並列コンピューティングを学ぶことになるのは、まだまだはるかに先のことになる。それでも、「人生における目標が出来た」ということは評価すべきことだ。僕は今まで、何も知らないにもかかわらず色んなことを勉強した結果、これ以上常識を増やすことができなくなってしまった。そのため、これ以上僕は人生の残りの期間においてするべきことがなくなってしまった。すべきことがないなら何もしなければいいと思われるかもしれないが、何もしないで生きるというのは非常に辛い。だから、なんらかの目標が欲しかった。
だから、僕は今から、本を読んで並列コンピューティングとJavaの詳しい勉強をしていきたい。Linuxの知識はまったく無駄にはならない。そして、その勉強をした経験を活用して、さまざまなプログラミング技術を身に付けられればいいなと思っている。
後日注記：実際のところ、PHPでの各ページのデータ共有のためには、たとえばファイルにデータを記録したり、データベース管理システムを使えば、最低限なんとかはなります。ですが、それでも、C/C++やJavaのような、各機能でデータを共有できるプラットフォームほどに柔軟性はありません。また、僕は動的型付け言語が、大規模な開発には向いていないと思います。「あれ、このメンバ変数はどのクラスのメソッドを持っているのだったっけ？」となった時に、PHPなどでは簡単にクラスの型を知ることができません。なので、どれだけ動的型付けのWeb言語が流行しても、C/C++やJavaのよさというのはなくならないものだと思います。
後日注記：もしかしたら、PHPやRubyでも、各ページの中で同じオブジェクトを共有する方法があるかもしれません。たとえばRubyでは、RailsというWebフレームワークがありますが、もしかしてRailsを使えばそういうことができるかもしれません。そのような機能があったとしたら、それは僕の知識不足であり、不勉強のせいです。もしかしたらJavaのアプリケーションサーバやJavaBeansはそのようなものを実現しているのかもしれません。
JavaBeansも参照のこと。
絵で見てわかるITインフラの仕組み (DB SELECTION)を参考に執筆しました。
エンタープライズシステムでは、大きく分けて、IBMのメインフレームのような「中央集約アーキテクチャ」と、UNIXやC/C++などの標準技術を用いた「オープン系分散・分割アーキテクチャ」に分かれる。
IBMのメインフレームは、巨大な大型コンピュータがひとつあり、内部の処理はとても高度かつ複雑で、とても大きな処理能力と信頼性があるが、ユーザーによる変更の柔軟性や拡張性が低く、コストも高くなる傾向にある。
これに対して、オープン系システムでは、ひとつひとつのコンピュータの処理能力はメインフレームほど大きくないが、たくさんのコンピュータをネットワークでつないで、分散型システムすなわち「クラスタ」を構築する。UNIXのような標準的OSやC/C++のような標準的言語を使うため、多くのコンピュータメーカー・ハードウェア・ソフトウェア・ベンダーに開かれているという意味で「オープン系」と呼ばれる。
一般的に、オープン系の方が拡張性や柔軟性が高いが、その代わりひとつひとつのコンピュータの性能や信頼性は低いため、ある特定の系が故障しても別の系が働くように「冗長化」や「アクティブ・スタンバイ」を行う必要がある。
（絵で見てわかるITインフラの仕組み (DB SELECTION)を参考に執筆しました。）
メインフレームも参照のこと。
また、最近は企業の業務システムもクラウド化が進んでいる。
クラウドによって、ネットワーク上のシステムを社内でインターネットを通じて使うことで、自前でシステムを構築する場合よりもコストや手間の削減に繋がる。
これに対して、自社の企業内にシステムを配置し、自社運用するシステムを「オンプレ」と呼ぶ。
クラウドも参照のこと。
現在の業務システムでは、三階層型システムと呼ばれる、Webブラウザをクライアントの操作端末とし、Webサーバ、APサーバ、DBサーバを用いてシステムを構築するのが一般的。
異なる種類のシステムであっても、多くの場合三階層型システムで対応できる。
（絵で見てわかるITインフラの仕組み (DB SELECTION)を参考に執筆しました。）
商用のエンタープライズシステム、常に稼働していなければならないインフラなどではAPサーバにJava EEなどを使う。オープンソースかつ軽量なApache Tomcatのほか、多機能性を求める場合はオープンソースならRed HatのJBoss、あるいはOracleのWebLogicやIBMのJavaアプリケーションサーバなどを使うことがJavaのAPサーバとして一般的である。たくさんのマシンで分散環境を構築する場合、再利用可能なコンポーネントとしてJavaBeansやEJB、分散オブジェクト技術のRMIやCORBAを使うこともある。
WebのシステムならばAPサーバにRuby on RailsやNode.jsなどを使うことも多い。
DBサーバとしては、オープンソースで手軽なMySQLやPostgreSQLのほか、意外と今でもOracleなどのシェアが多い。Microsoft SQL Serverなども健闘している。IBM DB2はあまりシェアを大きく持っていないが無視できない存在である。
また、実運用ではそれぞれのサーバに異なる物理マシンを割り当てることが一般的だが、デプロイの前段階として開発用のマシンで動作試験を行う場合はDockerなどの仮想化システムを使い、運用マシンと同等の環境を試すことができる。
JavaサーブレットやRDBMSなどを参照のこと。
自分の書いたブログ「神々とともに生きる詩人」2021/02/02より。
| 用語 | 説明 |
|---|---|
| レプリケーション | レプリケーションは、データの複製を作ること。 |
| ジャーナリング | ジャーナリングは、ログや記録を取ること。 |
| ポーリング | ポーリングは、一定時間ごとに確認すること。 |
| 割り込み | 割り込みは、処理の途中で別の処理が入ること。 |
| ボトルネック | 全体のスループットが悪い時、 もっとも効率の悪い部分（ボトルの首）が、 全体の円滑な流れを全て制限してしまうことを、 ボトルネックと呼ぶ。 |
| 冗長化 | 冗長化とは、ある部分が故障しても別の部分を使うことで、耐障害性をはかる仕組み。 |
| フェイルオーバ | サーバがダウンしても別のサーバが代わりを務めることを、フェイルオーバと呼ぶ。 |
詳しくは絵で見てわかるITインフラの仕組み (DB SELECTION)が参考になります。
データベースの勉強をしていると、「冗長構成の構築」という言葉が良く出てくる。
どんなに破損があっても別の同じシステムが代わりを務められるようにし、信頼性を確保する。
単にデータが破損した時のために別の場所に複製しておく（レプリケーション）ようなストレージ的な冗長性もあれば、あるシステムがダウンした時に別のシステムが代わりを務める（フェイルオーバ）ことで、ノンストップでシステムを安定稼働させるような、可用性を意味する冗長性もある。
データベースも参照のこと。
スパコンやクラスタでは、スピードや効率などのパフォーマンスを重視する「スケーラビリティ」と、ノンストップで安定してシステムが動き、データが失われず、どこかが故障されれば別のどこかが代わりを務めるような「リダンダンシー」（冗長性・高可用性）の種類がある。
ハイパフォーマンスクラスター（HPC）では、たくさんのコンピュータを繋げて並列処理を行うことで、極めて高速・高性能なクラスターを実現する。コンピュータをたくさん繋げることで高性能を目指すことをスケーラビリティと呼ぶ。
また、フェイルオーバは冗長性の一種で、システムが故障したりダウンしても、別のシステムが自動的に代わりを務めるようにする。
ロードバランサは、サーバの負荷を分散させる仕組み。
ロードバランサは、クライアントとサーバの間に入り、中央で窓口となってリクエストを集中的に受け取り、それぞれのサーバに負荷のかかる処理を分散させる。クライアントから見ると、ロードバランサがサーバであるかのように見える。
Linux上でロードバランサクラスタを構築する技術にはLVS（Linux Virtual Server）、keepalived、ldirectord、HAProxyなどがある。
（詳しくは徹底攻略 応用情報技術者教科書 平成30年度が参考になります。）
ワークロード管理について。基本的に、仮想サーバーのリソースを適切に配分する。空いているマシンのリソースを活用するためにリソースを再配分することは大切だが、もしリソースが外部から必要とされていて重要度が高かった場合には、再配分することに対するリスクもある。システムの日々の状態を分析して、適切に行うこと。
以下のページが参考になります。
仮想化も参照のこと。
2024.03.05編集
LinuCのサイトから無料で教科書がダウンロードできる。ただし個人情報の入力が必要。
以下の書籍が参考になります。
クラスタとは、複数の分散コンピュータを使ってひとつのサーバやスパコンのようなシステムを構築する手法。
LinuxでHA（High Availability）クラスタを行うためには、以下のようなページが参考になる。
僕が思うにKubernetesでクラスタをやるのが良いのではないかと。
DockerやKubernetesも参照のこと。
Beowulfは結構昔に流行した分散システムで、OSにLinuxやBSDなどの安価なコモディティ製品を使う。並列処理ライブラリMPIなどとともに用いる。
Pacemaker（旧Heartbeatの後継）は比較的有名なOSSによる高可用クラスタシステム。
LinuxのHPCクラスタには、Beowulf（NASA）、SCore（通商産業省）、MOSIX、Globusなどが挙げられる。
クラスタ向けのパッケージには、openMosix、Kerrighed、OpenSSI、PVM、OSCAR、Grid Engineなどがある。
クラスタ用のディストリビューションには、Glusterがある。
バッチシステム（JMS・ジョブスケジューラーと呼ばれる）には、OpenPBSやTorqueがある。
並列計算用のライブラリには、MPICHやMPICH2などがある。
Linuxでは高可用性クラスターの例として、Linux Virtual Server、Linux-HAによるHeartbeat/Pacemaker、Red HatによるRed Hat Cluster Suiteなどがある。
Linuxはスーパーコンピュータ用のOSとして良く使われている。以下のページを見れば分かる通り、TOP500のほとんどはLinux。IBMのスパコンではRHELが目立つが、ドイツのスパコンにはSUSEが良く使われているようだ。
日本のスパコンとしては京や地球シミュレータなどが過去に頑張っていた。地球シミュレータはNECによるスパコンで、かつてはベクトルプロセッサを用いた数少ないスパコンだった。
Slurmはオープンソースなジョブスケジューラ（ワークロード管理ソフトウェア）。多くのスパコンやクラスタで使われている。
LinuxやBSDによるオープンソースなクラスタ方式。
Linuxによる負荷分散のための仮想サーバシステム。
Linux-HAはLinuxなどによる高可用性システム。クラスタ管理プログラムHeartbeatを主な成果とする。
分散ファイルシステムを参照のこと。
CORBAを参照のこと。
分散OSを参照のこと。
並列処理を参照のこと。
僕は、「分散環境」という時に、マシンをクラスタで用いることもできるとは思うが、そうではなく、たとえばjQueryのJavaScriptファイルをHTMLから呼び出すような形で、「分散アプリケーション環境」というのを作れないかと思う。
たとえば、「こんなソフトが使いたい」と思った時に、インターネットを検索して、そのURLからワンクリックでアプリケーションを起動できるようにする。
WebサービスやWebアプリケーションがこれに近いかもしれないが、専用のサービス運営サーバーを管理するのではなく、ただサーバーにアップしてある「バイナリファイル」を適切に実行できるようにする。
JavaScriptのようにすると面白いと思うのだが、実際はGNOMEのような「理想だけで終わってしまった」システムになるかもしれない。だが、ファイル共有ソフトがやっているように、P2Pで分散システムで「リレーション環境」ができれば、HTMLやハイパーテキストの考え方と結びついて、とても面白いことになるのではないかと思う。
面白いと思うのは、すでにあるサービスを組み合わせて、モジュールのように別のサービスを作ったり、連携させたりするような段階である。
ハイパーテキストのリンクからGoogle検索を作ることはできるが、たとえばInstagramとGoogleイメージ検索を組み合わせて、ハッシュタグのようなものから独自の検索をさまざまなオプションでできるようにするとか、そんな風に一種の仮想コンピュータシステムのようなものを、ネットのみんなで作ったり使ったりできるようにすると、面白いのかもしれないと思う。
インスタで流行している写真から、ストリートビューでその場所に行ってみよう的な、これはまだリンク利用の域を出ていないが、色んな応用が考えられる。ある意味、GNOMEやCORBAの理想はそういうものだったのかもしれない。
また、ハードウェアインフラ的なものを考えると、Cellチップがやっていたように、「みんなのパソコンを使って処理を分散して行う」というモデルも考えられる。
ゲームだけではなく、多くの処理をみんなのパソコンで行えば、「巨大なコンピュータ資源」が手に入り、カーナビやDVDレコーダーは資源の一つになって、世界中全ての機器が繋がる。
（以下の文章は、クラスタやワークロード管理について何も分かっていない、経験や知識のない自分の書いた文章であるため、一般的な良識と比較して間違ったことを教えています。注意してご覧ください。）
クラスタなど、たくさんのマシンが繋がったシステムでは、ワークロード管理が重要になります。
たとえば、MINIXで有名なアンドリュー・タネンバウム教授が作っている研究用の分散OS、Amoebaでは、ネットワークで繋がったたくさんのマシンを、ひとつのシステムであるかのように仮想化し、スケジューリングやメモリ管理を分散された中で行う、分散型のタイムシェアリングシステムを開発しています。
そのように、たくさんのマシンに繋がった環境では、たくさんのマシンがあるからこそ、そのマシンのリソースを適切に使わなければなりません。
仮想マシンのリソースをどのように配分するか、という「ワークロード管理」を行うためには、ジョブスケジューラと呼ばれるソフトウェアを使う必要があります。
ワークロード管理においては、余っているマシンにリソースを再配分することには、メリットとリスクが両方存在します。空いているマシンのリソースを有効に活用することもできますが、もしもサービスの重要度が高く、外部から必要とされていた場合、リソースを簡単に動かすのはリスクを伴います。
詳しくは以下のページが参考になります。
2024.03.05編集