ハードウェアを知る (5) ハードディスク (1)
今回は、PC/Mac/スマホ では、ほぼ発売されていませんが。Cloud やサーバーではまだまだ現役のハードディスクを取り扱いましょう。よく、HDD (Hard Disk Drive) と略されますね。
HDDの登場
こちらにありますが、HDDが登場したのは、1956年と言われています。IBMですねー。
注目したいのが、その大きさと記憶容量です。50cmのディスクが24枚! メッチャ場所をとりますよね。音も結構大きかったかもしれません。これは私には、わからないのですが。そして、5 MBです。最大容量が。
今、iPhoneで写真を撮ると、1枚で、10MB弱になりますよね。最低でも 5MBくらい。スマホの写真1枚も保存できない。
それでも恐らく価格は数百万円から数千万円したのではないですかね…
HDDの登場前はパンチカードと言われる紙に穴をあけたものを使っていました。テープ形式だったりもしています。
私は全く見る機会がなかったですが。そのカードを読む機械が当然あったわけですよね。
どういう方向性で進化をしたのか?
これは実はCPUも同じです。小型化、高集約化、高速化、そして大容量のものに進化を遂げていくわけです。
HDD の進化の先で、フロッピーディスクも出てきました。FDD (Floppy Disk Drive) です。これは、ポータブルつまり取り外しのしやすいHDDと言ってもいいでしょう。
PCが出てきた1990年くらい。ストレージといえばFDDでした。何せ持ち運びがしやすいですから。
そういえば、ファミコンのディスクシステムもFDDでしたね。私は、子どもの頃にゼルダの伝説をディスクシステムのFDDでやりました😊 当時は、おもちゃ屋さんに、FDDの内容を500円で書き換えるデバイスが置いてあったんですよね。ゲームを買うのが 5,000円してた時代です。500円で新しいゲームが手に入るなんて! 小学生のお小遣いで買えますしね。
そして今考えれば、廃棄物も少なく、なんで無駄のない、Ecology な仕組みだったんでしょうね。
ファミリーコンピュータ ディスクシステム - Wikipedia
今や、その媒体は、USBメモリになり。そしてネットワーク。しかもインターネット越しでのデータのやり取りです。
それでもデバイスにストレージがあることには変わりありません。
HDDの構造
これは知っておいた方がいいです。
HDDもシステムなんですよ。複数のハードウェアが相互作用をして動作します。そして、この特性を知れば、最適なデータの読み書きの配置にたどり着くんです。
適当にやって動くのは、扱うデータ量が少なくて、トランザクション、ディスクの場合はInput - Output でIOと言いますが。それが少ないうちですからね。よく使う用語で IOPS があります。Input - Output per Seconds。つまり 1秒間の入出力の回数です。入力と出力を兼ねている事をしっかりと覚えておきましょう。ここは調べるんじゃなくて脳に入れておくべき基礎事項です。
ここで知ってもらいたいのが、磁気ヘッドという存在です。プラッタが円盤で、それが高速に回転をします。その際に円盤のどこを読み書きするかの位置を決めているのが磁気ヘッドです。見ていただければ理解しやすいと思いますが、物理的に磁気ヘッドも激しく動くんです。
ちょっと想像をしてみてください。
円盤の内側にデータがあって、その次のデータが円盤の一番外側にある。内側の1コマを読んで。次が、一番外の1コマ。その次が、なんと一番内側の先ほどの1コマの隣の次の1コマ。
めちゃくちゃ効率が悪いですね。たった3コマの読み書きをしたいのに、次の場所の情報まで読み取る必要もありますし。そして、磁気ヘッドはウインウイン動きまくるわけです。
だから、プラッタに効率的にデータを配置したいわけです。磁気ヘッドの動作は必要最低限にしたい。出来たら。プラッタの同じ円周の場所に連続で使うデータは並べておきたいんですよね。
ツールの意味
ちょっと古いんですけどね。今もほとんど同じなので。このHDDを管理する上で大事な2つのツールを紹介しましょう。
左側は、ドライブのフォーマットツールです。
右側は、デフラグツールです。
フォーマット
Windows だと Cドライブなど、特定のドライブを丸ごと初期化します。その際、アロケーション ユニット サイズ、というのがありますよね。これは何かと言えば。一度のデータの読み書き、つまり IO で、何バイドのデータを扱うのか?という設定なんです。
これは超絶大事なんですよ。
Windowsでよく使われているファイルシステムは、実は 4KB がデフォルトなんです。これはファイルの読み書きが激しい事を前提にしているという理解でいいと思います。つまり、ファイル単位の読み書きに最適化をされています。
NTFS、FAT、および exFAT のデフォルトのクラスター サイズ (microsoft.com)
ここでは、Web Server を考えます。
HTMLやJavacript などのファイルサイズは、おそらくですが、1つのファイルは、10KBとか。多くても100KBとかじゃないですかね。敢えてスクリプト系の言語のパッケージを例に出しますが。
これは Python でよく使われる numpy のファイル達です。
以下は私の Windows 環境の例です。皆さん、それぞれのPython環境で見てみてくださいね。
C:\Users\<ご自身のWindowsユーザーアカウント>\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\site-packages\numpy
ルートの直下はファイルサイズもかわいい感じですね。
core フォルダの中です。
1MB越えが幾つかありますが。ほとんどのファイルは10KB前後ですかね。3MBのまさにメガサイズがありますから、例外扱いして、それ以外の平均値をとった方がいいですね。
さて話を戻します。
これらのファイルが、一度に書き込まれたとすれば。パッケージのインストール時に他の書き込み処理を一切していないとすれば、おそらくですが、一度に一気に書き込まれるでしょう。
アプリケーションで使うファイルは、殆どのケースが読み取り専用です。つまり、ストレージ上は一気に並んでいた方が良く。この場合は、アロケーションユニットを大きめに取ります。一度HDDからメモリーにロードされれば、そのファイルが変更されるか、Web Serverが再起動しない限りは、ストレージにアクセスする事はありません。
64KB や 128KB でもいいでしょうね。
画像のファイルの場合はどうでしょう。HTTP経由でダウンロードするわけですから、小さ目がいいのですが。解像度が大きくなっていたり、PC/Macなどのい大画面で表示させたい場合は、大きくなることもあると思います。1MB越えはよくあるでしょう。
この場合は、アロケーションユニットサイズは大きめにとります。1MB越えでもいいかもしれません。
チューニングの一つですよね。
デフラグ
これは何となく想像がつきますよね。
データをファイルとして書き込む際には、物理ストレージ上のなるべく同じ場所に書こうとします。ところが、読み書きが激しくなると、1つのファイルが、物理ストレージ上で、分割されることも出てきます。ちなみにですが、部分的な削除が一番つらいです。
例えば、文章を書いていて、ファイルとして保存します。そのファイルを開いて、また文章を追記します。そして、上書きします。ここでストレージ上は、極端な例ですが。
最初のファイルの場所。4KB利用。
次のデータの位置情報を保存。4KB利用。
同じファイルの次のデータの保存。4KB利用。
という形になりえます。実際には、1つのファイルのデータの場所の管理はOS側で持っていますので、ここまで不効率じゃないですが。
次に最初のファイルの一部分を削除します。
そうすると、データの構造は変わらないのですが。最初のファイルには不要な場所ができるわけですよ。
この部分、アロケーションユニットのサイズ次第では、誰も使えない領域になることもありえます。
結果、アロケーションユニットをまたがる事になりますね。この状態をフラグメンテーションと言います。
デフラグは、デ・フラグ、です。フラグメンテーションの解消をするんです。
ファイルの内部データの分割が激しくなると。磁気ヘッドが動きまくるわけですから。当然処理に必要な時間は長くなるわけです。
読み取りばかりのドライブはいいです。
読み書きの多いドライブは定期的にデフラグをすることで、ディスクのIOのパフォーマンスが改善する可能性が高いわけです。
注意点は、デフラグは、その処理自体が、ディスクIOがとても高いんです。つまり、コンピューターが暇なときにやった方がいいんです。
今の Windows OSについているデフラグツールは、デフラグのスケジュールが組まれています。
デフラグツールを見てみると、プログラムが実行されるスケジュールが設定されています。
よしなにやってくれるんですよね。HDDじゃなくてSSDでも。
そして、Windows 11のタスクスケジューラーです。
これが実行コマンド
これが、トリガー、つまりプログラムの起動条件です。
.jar, .war や container の是非
さて。
Javaの場合、コンパイルすると javaの中間コードが出来るんでしたね。実はそれは zip形式で圧縮されている1つの jar ファイルになります。JavaのWebアプリケーションの場合は war ファイルですね。ファイルが1つになって、しかもファイルサイズを最小にするために圧縮されていることがポイントです。
HDDの事を考えたら、なんて賢いんだろうって思いませんか?
Docker が登場して Container でアプリケーションをビルドすることが増えましたね。
この Magazine の中の別の回 でも触れました。
Container も1つのファイルになるんでしたよね!
Docker for Desktop で見ると…
docker/getting-started のファイルサイズは 約28MB。
Windows で Docker と WSL を使う場合は、Windows OS上では仮想ハードディスク形式の1つのファイルになっています。ただ、このファイルは読み書きされるんですよね。開発環境として Windows を使っている場合は😊
私の Windows 11では、約 5 GB の VHDX ファイルです! アロケーションユニットを幾つとっているんでしょうね😊
WSL 2 仮想ハード ディスクのサイズを拡張する | Microsoft Docs
本番環境だと Ubuntu などの Container 環境で動きます。
docker info コマンドで、どこにイメージのファイルが格納されているかがわかります。
実際にその環境で Image ファイルを探してみてください。
C:\Users\dahatake>docker info
Client:
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc., v0.7.1)
compose: Docker Compose (Docker Inc., v2.2.3)
scan: Docker Scan (Docker Inc., v0.17.0)
Server:
Containers: 1
Running: 1
Paused: 0
Stopped: 0
Images: 1
Server Version: 20.10.12
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 7b11cfaabd73bb80907dd23182b9347b4245eb5d
runc version: v1.0.2-0-g52b36a2
init version: de40ad0
Security Options:
seccomp
Profile: default
Kernel Version: 5.10.60.1-microsoft-standard-WSL2
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 7.567GiB
Name: docker-desktop
ID: HHBZ:7VNM:XWZT:JHFG:VDJF:3GX6:AFBV:B6JM:WU6V:XN4P:ZRXX:7VFU
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5000
127.0.0.0/8
Live Restore Enabled: false
WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support
C:\Users\dahatake>
まとめ
今回はHDDを見てきました。日常作業のPCと、Web Server とでストレージの使われ方が大きく異なることが想像できたのではないでしょうか?
Windowsの場合、C Driveに。Linuxでも、一つのマウントしたパスに、アプリケーションが使うファイルや、データのファイルなど、全てのファイルを置くのが如何に効率が悪いのかが、理解できたと思います。
今回は取り扱っていませんが、是非、SQL Server や MySQLなどのデータベースの使うファイルがどうなっているかもご自分で探してみてくださいね。機会があれば、取り扱います。