明確な言語で分散システムの法律またはデータ処理を渡す方法

作業がコンピューターテクノロジーに関連していない場合は、おそらくコンピューターまたはクラウドにデータがどのように保存されるかについて長い間考えなかったでしょう。 私は、ハードドライブやメモリチップの物理的なメカニズムについてではなく、同時にあなたが考えるよりも複雑で理解しやすいものについて話している。



たとえば、一般的なテキストファイル、銀行口座、マルチプレイヤーゲームの世界など、多くの人が読んですぐに編集したいデータがある場合、ドキュメントの内容と一般的な合意に達し、誰も他の人を上書きしないようにする方法仕事？ これは分散システムにおけるコンセンサス問題であり、これに対処するために、古代ギリシャの羊、独裁者、架空の島々について話さなければなりません。







「他の島は何ですか？」



この問題を解決するために使用された最も重要な方法の1つに関する元の科学論文は、誰もいないにもかかわらず、古代ギリシャのパクソス島（パクソス）の架空の議会が部分的に法律を通過した方法についての長い議論の形で書かれていたことが判明しました議員のうち、彼がいつ議会に出頭するかを確実に言うことは不可能でした。 これは、グループの一部がいつまでも利用できない場合に、ファイルに何を書き込むかについて、人々のグループがどのように同意できるかを示す優れた隠phorです。 元の記事は、これまでに公開された最もおもしろい真面目な科学記事の1つであり、私が今まで見た複雑なアルゴリズムの最良の説明の1つです。 このメタファーは、分散システムにおけるコンセンサス問題の一部を説明するのに見事に機能し、ファイルシステムについて話すよりもはるかに興味深いので、この記事で使用します。



この比phorが非常にうまく機能する理由は、ファイルと法律の両方のケースで、多くの人が変更したい、多くの人が読みたいが、誰もこのプロセスにすべてを費やしたくないデータがあることですあなたの時間。 ファイルを読むことがディスクからデータを受信できる速度によって制限されるのと同じように、一連の法律で本を同時に読むことは、一度に本を見ることができる人の数によって制限されます。 同時録音では、全員が互いの決定を上書きしないことに同意する必要がありますが、それを行うための長い議論はありません。 世界の誰もが本を交互に使用するという事実に加えて、この問題をどのように解決できますか？



ファイルシステムとデータベース操作について話す代わりに、現実との偶然の一致がランダムで、居住者が法令と法律の発行に取りつかれている偽エーゲ海の島に移りましょう。 法律が必要なときに誰でも法律を読めるようにするだけです。 いくつかの曲がりくねった物語を辿る方法があります。そして、私たちが終わる頃には、IT専門家が直面している形で、分散コンセンサスの問題に気付くでしょう。 羊を除きます。



ちなみに、この物語の原因となったものを除いて、多くの島があり、その名前は完全に発明されていますが、それについては後で詳しく説明します。

ヤドカリとメキシコ料理

Pseudemoxos島での最も単純なケースから話を始めます。 ここには、自分の使用のために法律と法令を書いている一人の隠者が住んでいます。 最初は、ノートブックと鉛筆という非常にシンプルでわかりやすい方法を使用しました。 法律を追加したり、法律を変更したり、必要に応じて法律を再編成したり、新しいものを好きな場所で消去して書き留めることができました（実際、これが90年代の終わりまでコンピューターのディスクが機能する方法でした）。



この方法は、消去するとほつれすぎた紙を除いて、非常にうまく機能しているように見えました。 しかし、ある日、怪しげなブリトーの箱が陸に投げられたとき、隠者はそのような決定の恐ろしい欠陥を実現しました。 法律に変更を加える-テキストを消去して何かを書き始めると、隠者は私たちが丁寧に「職場での緊急事態」と呼ぶことを経験しました。 多少みすぼらしい隠者が自分のコードに戻ったとき、彼は自分が書くつもりだったことを忘れただけでなく、本の真ん中の空きスペースが古い法律でも新しい法律でも満たされていないことに気づきました、そして急いで書かれた落書きは読むことができません！



メタファーは、コンピューターまたはプログラムがクラッシュしたときに何が起こるかを説明します-ディスク上のデータは絶望的に歪む可能性があります。 隠者のより深刻な失敗は、書かれた言葉を傷つけるだけでなく、ページ全体にかなり不快で一定のマークを残す可能性がある磁気ヘッドのブロックの損傷などのイベントと比較することができます。



これらの問題は、ロギングを使用して解決されます。 スキームは、人々が会計帳簿または実験室観察日記をつけるように、何も消去しないことです。 現在、私たちの隠者は書類の束を保持しており、法律を変更したいとき、彼は日記に新しいエントリを追加します。



6月4日10:32-食品安全法に追加：無期限に海にいたブリトーの摂取は禁止されています。



各編集は、挿入、変更、削除のいずれであっても、ログの最後にペンで書き込まれます。 隠者は記録を消去することはないため、緊急事態から保護されています。 最悪の場合、不完全で破損したログエントリが存在するか、単に書き込み試行の失敗の痕跡がありますが、これは単に無視できます。 ジャーナルには、すべての変更を記録するという追加の利点があります。 法律が1年前にどのように見えるかを見るために、私たちの隠者は単に雑誌を読んで、その日に止まることができます。



雑誌の明らかな欠陥の1つは、ノートよりも読むのが難しいということです。 食品安全法の現在のバージョンを知るには、雑誌の最初から始め、最後まで読んで、すべての変更を追跡する必要があります。 雑誌のボリュームが時間とともに増加するにつれて、プロセスはますます面倒になります。



物事を簡素化するために、隠者は空のディレクトリのスタックを保持します。 雑誌が大きくなりすぎると、一連の法律を作成するのに時間がかかります。最初から最後まで雑誌を読み、法律全体を最新の状態に定式化し、この状態を法律のコレクションに書き込みます。 法律のコードの表紙に、彼は次のように書いています。「これは[そのような日付]の法律の状態です。」 法律をさらに使用するには、法律のコードと法律の収集日以降に行われた変更のジャーナルを読むことだけが必要です。 この日付よりも古いログは、セットの前に変更履歴が必要な場合、または単に破棄する場合に保存できます。



私たちの隠者が新しい法律を開発するのに忙しすぎて、定期的に一連の法律を作ることができない場合は、店員（つまり、最初と並行して実行されている2番目のコンピュータープログラム）を呼び出すことができます。 書記官は、合意された時間まで雑誌を読み、法律のコードを書き、彼が新しいコレクションを使い始めることができるように彼が終わったことを隠者に知らせます。 彼の仕事を遂行するために筆記者に何も言う必要はないので、隠者は黙って彼の仕事を続けることができます。



この方法にはさらに利点があります。 私たちの隠者は彼の知恵で広く知られるようになりました（たとえば、海で提供されるメキシコ料理を拒否することに関する彼の教訓）。多くの人々は彼の法律を読みたいかもしれません。 これらの読者が特定の日付から法律のコードに満足している限り、賢人を邪魔することなく、自分でコピーを作成して自由に読むことができます。 法律の最新版を必要とする人だけが直接彼に連絡するべきです。



（パーソナルコンピューターでの雑誌の使用は1990年代後半に始まり、2000年代半ばに普及しました。お使いのコンピューターはおそらくジャーナリングを使用しているでしょう。）

フォタス島のカオス

Psevdomoxos島の近くには、Fotasの大きな島があります。 この島は人口があまり多くありませんが、すべての住民が生活を管理するための統合された法律システムが必要であることに同意するのに十分な人々がいます。 それにもかかわらず、Fotasicaの居住者は和解できない独立性で知られています。彼らは他の居住者またはグループが彼らを支配することを許可していないため、Fotasの居住者は法律を通過させる権限を有すると判断しました。 これを行うには、日付、時刻、および名前を記載した紙に法律を書き、メッセンジャーをフォタス図書館に送ります。そこで、書記官は法律ジャーナルに追加します。



（これは、多くの人が最初にファイルに何が含まれるかについてコンセンサスを作らずに、単一のファイルへの変更を同時に保存しようとすることを意味します。）



何かがうまくいかないかもしれないいくつかのケースを見るために、我々は島の海岸の1つに住んでいて儀式の犠牲の純粋さを非常に心配しているAgniyaで物語を始めます。 彼女は法律を紹介します：



6月1日正午-羊の販売に関する法律32.1.2が次のように修正されます。死の痛みの下では、コートが完全に白ではない羊を販売または購入することは禁じられています。 署名、Agnia。



島の反対側で、販売が困難な黒羊を何匹か持っているバジルは、彼自身の法律を書いています。



6月1日正午-羊の販売に関する法律32.1.2が次のように修正されます。コートの色が原因で、羊の売買を拒否することはできません。 署名、バジル。



少し後に、店員は同じタイムスタンプを持つ2つの新しい法律を発見します。 彼は何をすべきですか？ バジルがガラテアに黒羊を売るために町にやって来て、彼女が非白羊の購入を拒否すると、彼らは法典を読みに行きます。 法律のどのバージョンを使用すべきですか？ そして、書記官が次の法律のコードを収集しようとするとどうなりますか？ （2人が同じファイルの同じ部分に異なるデータを同時に書き込もうとすると、結果はまったく同じになります。）



よりデリケートな問題を説明するために、Agniaが法律の読み取り/変更/書き込み操作を実行したいと考えていることを想像してください。彼女は現在の法律を見て、変更を加えることを決定し、それを書き留めます。 しかし、彼女がこれをしている間、バジルは法律に矛盾を持ち込みます。 たとえば、10：00にAgniaは法律を読みます



セクション32.1.3。 ヤギを売る人は、図書館の一般基金に1コインに相当する税金を支払わなければなりません。



彼女は熟考し、10：02に次のメッセージを書き込みます。



6月1日10:02-法32.1.3では、「1コインに等しい」を「2コインに等しい」に変更する必要があります。 署名、Agnia。



残念ながら、ヤギ税を嫌うバジルは10:01に次のように書いています。



6月1日10:01-法32.1.3が「2月中旬-オリーブの日」に置き換えられました。 それであなたは行き​​ます。 署名、バジル。



私たちの書記官は、法律を調和させて整理しようとしていますが、非常に混乱しています。彼がアグニヤからメッセージを受け取ったとき、法律32.1.3はすでにナショナルオリーブデーを設定しています。 彼は何をすべきですか？ バジルが「図書館の一般基金に支払う」を「バジルに支払う」に置き換えたと想像してください。



同じ法律のコードを編集するときに複数の著者が競合する場合、同様の状況が発生します。 多くのソリューションがあり、それぞれに長所と短所があります。 これらのソリューションは、2つの主なタイプのモデルに分類できます。 1つのタイプは「究極の一貫性」または「最終的な一貫性」で、記録を管理するいくつかのルールにより、全員が互いに会話することなく同時に記録できます。 このモデルにより、しばらくの間、新しい更新がない場合に、データ（レプリカ）のすべてのコピーの一貫性が確保されます。 このアプローチのコストは、現時点では誰も法律の正確な状態を知ることができず、誰もがそれが最近何であるかしか知ることができないということです。 別のモデルは「厳格な一貫性」であり、あらゆる種類の記録が可能であり、誰もが法律の現在の状態を知ることができますが、各記録について合意に達するコストがかかります。



両方のタイプのモデルが役立ちます。 時々、標準が少し時代遅れになる情報があります。 たとえば、Fotasの住民が年次フォトアルバムを作成するとき。 彼らはお互いに写真を交換し、最新の写真を持っている必要はないので、より単純な「最後の一貫性」が良いでしょう。 一方、「厳格な一貫性」は、コストにもかかわらず、これらの法律にとってより有用です。 （これはコンピューターにも当てはまります。たとえば、Googleにアップロードした画像は「長期的に一貫性」でシステムに保存され、表示権を決定するアクセス制御リストは厳密な一貫性を使用して保存されます）



フォタス島に戻ります。

最後に、すべてが理にかなっています

最初の問題を簡単に解決できました。同じタイムスタンプを持つ矛盾する法律で、タイブレークルールを追加するだけで、マークが同じになることはありません。 たとえば、作者の名前をアルファベット順にラベルに追加して、レースの場合、Agniaからの変更が常にバジルの前に行われるようにすることができます。 （または、名前が一致する場合、各居住者に一意の番号を割り当てることができます）。 タイムスタンプが一致しなくなった後、混乱はありません。 ガラテアが町に入り、バジルの法則が唯一のものです。



このような相互書き換えが問題になる場合は、まず誰が何かを書くことができるかについて合意することで回避できます。 たとえば、1週間でAgniaは偶数の法律のみを編集できますが、Bazilは奇妙で、来週はその逆です。 （コンピューターでは、2人の作成者がまったく同じファイルを書き込もうとしないようにファイルスペースが分割されることがよくあります。たとえば、新しくアップロードされた各写真に一意の名前を自動的に割り当てることができます。）



2番目の問題を解決するために、その存在の可能性を破壊します。修正を禁止するためにジャーナル化のルールを変更し、完全な置換、追加、または削除のみを許可します。 これは、ジャーナルの文言がその解釈について法律の現在の状態に依存できないことを意味します。 アグニアは法律で彼女の法律を書かなければなりません



6月1日10:02-法32.1.3は、「ヤギを売る人はすべて、上院に2コインに相当する税金を支払わなければならない」に置き換えられます。 アグニア。



彼女の記録には後のタイムスタンプがあったため、彼女の法律のバージョンはバジルのバージョンを簡単に破りました。



このような法律を書くシステムには、スピードとシンプルさという利点があります。誰もが他の人と相談することなく、いつでも法律を書くことができます。 しかし、法律を使用することは驚くほど難しい作業になりつつあります。 ヤギの販売に対する現在の税率を知りたい場合は、図書館に行き、法律32.1.3を読むように依頼します。 10:05に到着すると、法律のコードと変更のジャーナルを読みます。 法律では、「ヤギを売る人は誰でも上院に1コインに相当する税金を払わなければならない」



おわかりのように、アグニアは10:02に法律を変更しましたが、彼女のメッセンジャーはまだ到着していません！ 状況を少し簡単にするために、メッセンジャーはライブラリに登録できます。メッセンジャーが各居住者から到着すると、メッセージを配信した後、ボードにメモを書き、フォトメッセンジャーからのすべてのメッセージがそのようなときに配信されたことを示します。 次に、訪問者は掲示板を見て、Agniaからの最後のメッセージが午前9時に、Vasilyからの夕方7にあったことを確認できます。 少なくとも今読んでいる法律は、前夜の7時から正確であり、ボード上に表示される最も早い時間であり、この時間の前に書かれたすべての変更は到着するはずです。 （この時間は「最低水準点」と呼ばれます）



もちろん、特定の市民があまり対立していない場合、彼からの更新はまれであり、誰もが質問をするでしょう。「変更はまだ図書館に届いていないのですか、それとも単にないのですか？」更新があるかどうかに関係なく、ボードは関連性を維持します。



フォタスの住民は創造的な人々であるため、メッセンジャーのこの絶え間ない流れは、そうでなければ人生を簡素化できることをすぐに認識しました。 図書館に退屈な旅行をする代わりに、彼らは単に法と変更ジャーナルのコードの彼ら自身のコピーを保つことができます。 現在、彼らのメッセンジャーは毎回、ジャーナルのすべての最新の変更と、ボードにあった日付のコピーを取り戻します。 彼らはコピーを更新し、それらを参照する場合があります。



しかし、フォタスの人口が増加するにつれて、図書館に駆け込む使者の動きが問題になりました。 雑誌や金庫をコピーする筆記者にとって、山羊税の変更に関する法律を単純に可決する作業は、ひどくゆっくりと解決され始めました。 幸いなことに、写真コミュニティは自分たちの問題をすでに解決していることに気付きました。法律の独自のコピーを持っているので、中央図書館はもう必要ありません！



代わりに、いくつかのブランチライブラリが開かれました。 メッセンジャーは最も近いブランチでアップデートを配信および受信できますが、他のメッセンジャーはブランチライブラリの各ペア間を移動して、すべてのアップデートのコピーを送信します。 その結果、「ツリーのようなマップ」が構築されました。各ブランチを互いに接続し、各住民をブランチで接続する構造です。 更新はマップに表示されているルートに沿ってのみ配信されますが、各市民または支部は別の市民または図書館に関連付けられているため、最終的に、居住者によるすべての変更はFotasのすべてのユーザーが利用できます。 最終的には誰もが同じジャーナルを手にすることになり 、法律のコードは最終的に合意されるでしょう！



このアプローチには多くの利点があります。 たとえば、危険な有料道路に沿って移動する必要がある場合は、島の中心部から東部の山々への唯一の道であり、この方法で行く必要があるのは1人のメッセンジャーだけです。 西から東へ、またはその逆に更新を配信し、道路の反対側にあるブランチブランチは、島の残りの部分に情報を配信します。

（この段階では、個々の居住者と図書館の支部の間に大きな違いはもはやないことに注意することができます。誰もがコピーを持ち、適切なルートに沿って使者を送り続ける限り、誰もが単にそれを書くだけで法律を変更できます独自のジャーナルとシステムを介した情報の普及）



この方法は非常に効果的ですが、3つの大きな欠点があります。



第一に、法律の現状について誰も確実に知ることができません。 自分の日記に書いた擬似モクソスの隠者とは異なり、Fotasの居住者は、変更を行った後、将来この法律を読んだ人がこの変更を見るという保証はなくなりました。 遠い将来にこれを読む人だけがこの変化を見るでしょう。 （これは、「読み取り後書き込みチェック」なしの一貫性の欠如と呼ばれます）



第二に、 read-modify-writeを実行することはできません。 2人の写真居住者が同じ法律を変更しようとすると、結果は予測できません。 この問題を回避するために、フォトフェローは、自分がこの法律を変更しようとしている唯一の人物であり、変更を行う前に最新バージョンの法律を読んでいることを確認する方法を見つける必要があります。



第三に、この方法はネットワーク障害に対して脆弱です。居住者の一人の遠隔地に通じる道路が岩の崩壊によって遮断されていると想像してください。 彼は外の世界から更新を受け取ることはできず、彼の最後のメッセージ以降、いつでもすべての更新があると誰も想定できません。 また、それ以来、彼は何も送信していないと誰も想定できません。 残りは、居住者が岩について知らず、彼自身の日記に書き続けて、決して来ないメッセンジャーを待っていることを示唆します。 したがって、システム全体が停止し、誰も「最低水準点」を押し進めず、唯一の方法が失われるため、誰も新しい法律のコードを作成できません。



コンピュータの実践では、このような問題は現実的で深刻です。 1つのノード（コンピューターまたは場合によってはデータセンター）がシャットダウンするたびに、エンジニアはすぐに状況を評価し、ノードを復元および再接続できるかどうかを判断する必要があります。 そうでない場合、他のサーバーはセットを形成できず、それらのログは増え続け、読者に問題を引き起こします。 この場合、孤立したライターはますます非同期になります。 問題をすぐに解決できない場合、分離されたノードは完全に切断されることがよくあります;接続したい人をルーティングするために他の方法が使用されます-多くの場合、外部ネットワークが非常に遅くなります。 ただし、残りのノードは待機し続けます。 問題がすぐに解決されないことが明らかになった場合、唯一の可能性があります：失われたノードをネットワークから完全に削除し、他のノードにそれらのノードがもはや存在しないふりをして、それらからの更新がないことを伝えること。 ノードは開発されますが、隔離されたノードが実行するレコードは、他の方法でコピーされてメインネットワークに転送されない限り、永久に失われます。

Fotasのお客様と厳格な一貫性

したがって、上で見たのは、Fotansのように素早く書きたいが、何かの最新バージョンを読むことにあまり興味がない、独立した島民にとっては合理的な解決策です。 しかし、これが単に受け入れられない状況ではどうなりますか？ 法律は実際に良い例です-10:00に犯罪を犯した場合、それに対する法律が9:00または11:00に可決されたかどうかは非常に重要です。 現在形の法律に関する重要な知識。



Fotasが合法的なビジネスを展開し始めたとき、問題はさらに大きくなりました。 ご覧のとおり、フォタスは多くのはるかに小さな島に囲まれています。各島には独自の産業があり、したがって独自の法律が必要です。 小さな島であるため、フォタスのような筆記者とメッセンジャーのシステムを維持するためのリソースがありません。 彼らはスクライブやメッセンジャーを訓練することは決してできませんでした。 したがって、これらの小さな島々は長年にわたって最も単純な解決策を使用し続けました。各島には擬似エモキソスタイルの雑誌を備えた独自の隠者があり、法律を読んだり修正したい人は誰でも隠者とのコミュニケーションのために並んでいます。 この方法は、特に仙人が病気になったり、津波によって流されたりした場合、遅くて効果がありません。 しかし、Fotasのようなリソースを持っていなかったので、彼らは自分の道を進んだだけでした。



Fotaschanは、機会を感じて、彼らの法典を隣人へのサービス（LaaS）として提供しました。 クライアントの島々は、法のFotasコードの一部として法令を読んだり書いたりすることができた；各島は誰も書けない独自の章を受け取った。



最初は、隣人は喜んでいた：彼らはもはや隠者と話すために並ぶ必要はありませんでした。 フォタスへの旅行時間を考慮に入れても、プロセスははるかに高速になりました。 （実際、Fotasaneはネットワークの一部となったさまざまな島に大使館を作成することにより、移動時間を短縮するように働きました）。 また、はるかに信頼性が高かった。 津波がいくつかの島を破壊し、Fotasに深刻な被害を与えたとき、各写真居住者は法典全体のコピーを持ち、システムは簡単に復元されました。 Fotasは非常に多くの島に近いため、島はメッセージを転送するための信頼できる方法としてFotasシステムを使用し始めました。



しかし、先ほどお話しした2つの問題はより明確になりました。 たとえば、パラフォイタス島（クライアントの島の1つ）では、アンドロスのワイン会社が注文を追跡するためにフォタスボールトを使用しました。 アンドロスは、地元の政治家の結婚式のために100アンフォラのワインの注文を受け、注文書に記入しました。 翌日、彼のリモートの従業員の1人が注文書をチェックしましたが、メッセンジャーはこの時間までに記​​録を届けることができず、嵐のために別の港でブロックされました。 従業員は注文を知らず、ワインは結婚式の日前に準備ができていませんでした！



シラノス島の状況は良くありませんでした。 read-modify-writeの問題を解決するために、一度に1人しか法律を変更できず、月曜日には偶数番号の法律を担当するBavkidaを任命し、残りはGalenを任命しました。 火曜日-その逆など。 しかし、ガレンは非常に短気で、機会が現れ次第、火曜日の真夜中に偶数法を正確に変更しました。 残念ながら、バブキダは昨夜11時58分に同じ法律を変更し、彼女の変更はまだガレンに届けられていませんでした。 ガレンは法律を制定し、バウキダの作品をうっかり書き直した。



近隣の島々のいくつかは非常に満足していました。 たとえば、EpifoitasはFotasのリポジトリを使用してローカルの詩をアーカイブしました。詩がアーカイブされるとすぐに、それは決して変わりませんでしたが、新しい詩は再読されて、加えられました。彼らにとって、Fotasシステムは信頼性が高く安価でした。しかし、全体として、Fotasシステムの欠陥が明らかになった島は十分にありました。

パクソス議会

, (Paxos). , . , , , « Paxos». ( )



, , , , . «The Part-Time Parliament» . , , . . , !



, . --, . , , , .



: , , , - . , : , , , - . , , . , , ​​ , .







Paxos : , , , . - , , , , , : «! - !» , , . , - , , . , , , , .



: , , ; --, , , . « », « , , , , , , ».



, . , , . , . , . , .



Paxos : «Read-latest», , «read-recent», . «read-recent» Paxos, . . (, , , , , , , ).



, Paxos - , .

:

, . , , , . , .



, , , . ( , , , ). Paxos , . . , , , . , , , , , , , , .



, . , , , , . , , . - , , , . , , , .



, - , , . - , , . , . - , , .



. , . : « ?» , — , . , , : « ». , . , , .



, , , — , . , , Paxos . Paxos , , ( ).



. ( , ), . , , , , - .



, . — . , . , , , . , , . , . , , . , . « » « ». , , .



— . , , 7:1. !



, , . - , , . . . , , Paxos ( ) . , , , .



. , . , , - , Paxos. , , , , . , , . , , -, , , .



Chubby, .

最後に

, Yonatan Zunger, Distinguished Engineer on Privacy at Google



, . : , , , , , ?



, :



* ( ), , . , , , .



* ( ), ( ) , , . , , , , . , , , ( ), .



* ( , , «Paxos»). . , , .



* ( ) — , , - - . , , , .



これらのシステムの最大の利点は、クライアントの観点からは、方法ではなく、提供する保証が異なることです。今、私はあなたを去ります。架空の島についての面白い物語のチェーンをさまよいましたが、あなたが学んだのは子供向けのコンピューターサイエンスではありません。これは、ITプロフェッショナルが毎日直面している現実です。したがって、あなた自身がITスペシャリストでなく、専門家になることを計画していない場合でも、現在のコンピューターコンピューティングがどのように組織されているかをよりよく理解していただければ幸いです。