- PacketFabric流
- PacketFabric’s WAY
- PacketFabric流とは、PacketFabricのスタッフ・エンジニアによる
ネットワーク・ソリューション等に関する情報配信メディアです。
コンピュータはどう動くのか、或いは、この世の大概の悪の原因 Do you know how your computer really works, or “The Root of Almost All Evil?”
2024年07月12日
<まくら>
先日「IT者たるもの、Cの主要関数くらい覚えておかなければならない」と内部で発言したら結構な数の「お前は何を言ってるんだ?」を周囲から頂いたのですが、いや必要だろプログラムとかOSとかが、どう動いてるのか分からなかったらログの解析だって出来ないじゃん、とかド正論で反駁したところ、いまいちご理解を頂けなかったのですよ。
俺の説明が雑なんかな〜とか色々思いましたが、いや、そこら辺の基礎知識が足りないまま色々覚えても意味ないよなあ、そう考えるとPCの仕組みを覚えたり進歩をリアタイで見ながら使い続けてきた自分の世代が一番幸せだったんだなあ、とか思ったりもしたわけで。
逆に、そういう「自分が知っていて当たり前だと思ってる」前提が各人で違うところに問題あるんでは、とか、そういう前提知識を一度整理してみようかな、と思ってる最中に「放置してるブログ書いてね(はあと(殺意」と言われたのでつらつら書いてみようかなっていう話です。
本当は「パケット太郎の大冒険 〜ルータをくぐる度に死と再生を繰り返す奇妙な冒険〜」とか色々ネタが突然降りてきたんですけど、面倒いのでまたの機会とします。ちょっと面白そうで書きたい気持ちもありつつ。
ほとんど何も見ないで覚えていることを書いておくものなので、間違ってる、勘違いしているところはあるかもしれません。
<コンピュータとは>
コンピュータとは「入力したデータを演算して出力する」機能をもった機械だという個人的認識です。なんか「ネットワーク」とか色々小難しい事言うたりやってたりしますけど、本質は(浜の真砂くらいの数のNANDゲートで成り立つ)演算の組み合わせですね。量子コンピュータについては毛色がちがう部分ありますけど一旦おいときます。
卓上計算機だってコンピュータだな、そう考えると。卓上計算機のボタンがどんどん増えると函数電卓になり、もっとボタンや機能を増やしたらパソコンになるみたいな考え方です。まあボタンが2万くらい並んだ卓上計算機があったとして、使えるかと言えば使えないですしそれはもう卓上に収まらないんですが。
色んな機能や演算が出来るのはいいけどそれを個別で管理するのはとても面倒なので、「プログラム」という考え方が生まれたわけですが(ノイマン式だっけ?)、「じゃあ、機械が持つ様々な機能をまとめて管理するプログラム」をコンピュータの起動時に一個用意しておけば、それを覚えるだけで色んな機能が使えるから便利じゃない?って考えられたのがOSですね。そういえばCP/M50年、BASICから60年のはずです、今年(2024年)は。なおBASICはOSです(独断)。
今現在、人間が「コンピュータ」として考えるのは、この「OSが搭載されたコンピュータ」だと思います。Z80です!って人も居るかもしれませんけど、まあ初手がいきなりZ80とアセンブラとかそういう大人には憧れを抱きますけど、そういう大人はこの文章読んでる暇あったら、代わりにこのコラム書いてくださいっていう(切実。
<余談的な、CPUの2つの潮流、CISCとRISC>
CPUっていうのは計算する機能の中心、コアの部分ですが、実はメーカによって中身は違うものです。とはいえ現在、その上で走るOSがほぼ一緒のためCPUの中の違いを気にしない人も増えています。まあARM系なのかIntel系なのかとか、くらいは知っといてもいいかと思います。
昔は、大きくわけて「複雑な命令セットを多数用意したCISC」「単純な命令を主とするのでシンプル、速いRISC」という潮流があったと思うんですけど、今そういうこと言う人あまりいません。まあRISCベースのCPUでも変に複雑なCPUあるし、ハイブリッド的なCPUが主流ってことじゃないかなって理解してます。
有名どころのIntel AMDが中心のX86やX86-64系、
スマホや最近ノートパソコンでも使われだしたARM系、
オープンなアーキテクチャとして色々話題なRISC-V、
など、色々なCPUがあります(そしてそれぞれのCPU用にLinuxなどのOSがあり、画面の見た目が同じになるので素人には区別がつかない)。
<OSの考え方、モノリシックとマイクロカーネル>
潮流については、実はOSでも「一枚岩の、機能を集約する」モノリシックカーネルと、「機能ごとに分散している」マイクロカーネル、という二つの潮流がありました。昔の話です。昔かな?また、マイクロカーネルを提唱した、学習用のUNIX系OS、MINIXの功績で今年2024年のACM Software System Awardを受賞したタネンバウム教授とLinuxの開発者、リーナス・トーバルズの論争とかで、一部ギークには有名なお話なのでご存知の方も多いと思います。個人的には常識の話ですが、常識じゃないって多数の人が言うので書いておきます。
簡単にいうと、「保守が容易だけど、一部の障害が全体に波及する一枚岩システム」と「一部分に障害が発生しても該当部分の切り離しと復旧が容易だが、保守管理が大変な分散型システム」の対立でした。
<「堅牢性高いOS」としてのマイクロカーネルなLinux>
で、です。昨今のネットワークに限らずITの機器って無駄に(無駄に言うな)機能が多いので、管理用にOSが入ってること多いじゃないですか。そして組み込み系のOSなんて単価安い方がいいに決まってるので、オープンソース系とか採用されることが多いじゃないですか(偏見)。そう言う時に、モノリシックなOSが搭載されていると、
「何か一部分が壊れたりハングると、OS全体がクラッシュする」
という最悪の事態が発生しやすくなりますると嫌じゃないですか。ていうか嫌ですし、非常に困るのでそんな機械使いたくないですね。
一方でマイクロカーネル/モジュールが持つ「障害時、該当サービス・モジュールだけがクラッシュして再起動するが、他の機能に影響を及ぼさない」という部分がものすごくメリットになるわけです。壊れた部分は壊れてるけど、他の部分は正常に動作し続けるのは、まさに今現在、我々がネットワークやら、ミッションクリティカルな運用に利用する機器に求めることですね。
現在はLinuxでも、かつての一枚岩システムから必要なモジュールを読み出すマイクロカーネル化が進んでいて、全体のクラッシュになりにくいですよね。モジュール化が進んだLinuxを機器のOSとして採用してる例が増えているわけです。
<OSの中で動くのがモジュールなら、上では何が蠢いているか?答え:悪魔(デーモン)>
OS自体がモジュール化されていて、壊れた部分を切り離したりといった運用が出来たとしても、そのOSの上で動作するアプリケーション・ソフトウェアが「バグった時にOSごと死ぬ」とかだと結局モノリシックカーネルと同じです。そんな機械使いたくないですね。
そこで、「該当サービスだけ切り離して再起動出来る」など、機器の安定性のためには、個別に独立したアプリケーションが各自勝手に動いてる状況が一番安定してると思います。そういう、ユーザの操作から独立して動作するアプリケーションソフトウェアをLinuxやUNIX界隈では「デーモン」、Windows界隈では「サービス」と呼んでいますね。LinuxとかUNIX系のprocessなら「なんとかd」という名前で動いてる奴ですね。なお英語では悪魔のdemonではなくギリシャ語由来のdaemonです。常識です。常識かな?
ここまでの知識があって初めて、「なんか文字が並んでいる」としか思えなかったログが、「あ、UNIX系のOS上で動作しているなにかのプロセスが死んだみたいだ」まで読み解けるようになります。ていうか理解れ、くらいは言いたいところ。
<だいたいのモジュール(デバイスドライバ)やデーモンはC言語だよね>
どうやって動いてるかはわかりましたが、死んだ時どうなるか、とか実際どんなコードでどんな挙動するのか、とかまで分かっとけばよりデバッグというか解析しやすくなりますし、そういう意味でデーモンとかプロセスとか、どういう事?とか思い始めると結局Linuxとかの大本になった、UNIXのソースとか読まなくちゃいけなくなるわけです。そこまで暇じゃないのでオライリーのカーネル解説本読む程度でもいいんじゃないかなって思ってますけど(面倒なので逃避中)。
そんなUnixですが、最初PDP-11上でアセンブラ(機械語)で開発されつつ、メンテナンスとか面倒くさいってことからアセンブラよりUNIXを書きやすい言語としてC言語が開発されていた筈です。なので、Cの関数はUNIX系のシステムコール(OS内部の命令)と近いものが多いので勉強しておけって昔どっかで読んだ記憶があるんですよね。本当かどうか調べてないけど。実際近いと思います。つまりOSのカーネルまで調べなくても、C言語ある程度分かってれば、何がどうなってるのかわかるんじゃないっていうのが、このブログの最初に書いた発言の真意なんです。
自分で書いといてなんですがそんな真意があった事に今気づいたのは、秘密です。
<この世の大概の悪の原因はmallocか不要なfree>
そして、Cをある程度書いたことのある人間なら絶対にわかる鉄則として、大体の場合に突然アプリケーションが死ぬ原因は「解放済メモリへのアクセス」か「メモリ割り当ての失敗」なのです(独断による偏見)。
なので、IT機器を嗜む者、mallocとmallocにまつわるバグの、40年くらいの歴史などは読み物としても過去例としてもネット上に転がってるので、探して読んで覚えておいた方がいい!と思います。
あと、こういう不用意なメモリ解放やらで安全性が担保されにくいCなんか使うの止めて、より安全なRustいいよねRustっていう流れが加速しそうだな、というプログラム言語の流れみたいなものを知っておくといいんじゃないかな、と。
<まとめ>
「お前は何を言ってるんだ」と聞かれたので説明したら、自分でも何を言ってるのかよくわからなくなってきた。
<どっとはらい>
- 最近の記事
-
-
- 2024年7月12日
- コンピュータはどう動くのか、或いは、この世の大概の悪の原因 Do you know how your computer really works, or “The Root of Almost All Evil?”
-
- 2023年5月25日
- ローカルブレイクアウトしたのにSaaSは遅いまま…Unitas Networkの出番です
-
- 2022年6月30日
- エッジコンピューティング v.s. クラウドコンピューティング ~鍵を握るのはネットワークエッジ~
-
- 2021年6月17日
- 昨今のネットワークエッジとINAPのインテリジェント・ルーティング
-
- 2021年3月16日
- Kubernetes Cluster HA構成 後編「クラスターの作成と検証」
-