クラウドコンピューティング企業はAIの開発や運用に役立つGPUクラスタを製品として展開しています。そんなクラウドGPUの安定性について、これまでに400万基以上のGPUインスタンスを管理してきたModalが解説しています。
Modalは「Amazon Web Services(AWS)」「Google Cloud(GCP)」「Microsoft Azure」「Oracle Cloud Infrastructure(OCI)」といった大手クラウド企業からコンピューティングリソースを調達してGPUクラウドサービスを展開しています。記事作成時点では2万基のGPUを同時に管理しており、過去数年間で管理したGPUの数は400万基を超えています。
・クラウドAのインスタンス起動APIは最もシンプルで信頼性が高い。ベアメタルもしくは仮想マシンにリクエストしてHTTP 201が返ってきた場合、99.6％の確率で起動に成功し、起動時間は2～3分と比較的短時間である。
・クラウドAのH100で画像生成AIのStable Diffusionを実行した場合、クラウドCやクラウドDと比べてパフォーマンスが50％低くなる。
・クラウドCでは2025年の数カ月間にH100が非常に高温になり、90度を超えることもあった。温度が70度後半に達すると処理性能が低下し始める。
・クラウドCのH100は他のクラウドより228MiB多くメモリを予約する。このため、ユーザーが使用できるメモリが少なくなる。
・クラウドDのA10ではクロック周波数の低下が頻繁に発生する。
・クラウドDのアメリカリージョンの1つのA10では修正不可能なECCエラーが頻繁に発生する。
・クラウドDはコストパフォーマンスが最も良好。特にベアメタルサーバーは最高である。
Metaが発表したLlama3のトレーニングに関するレポートでも「予期せぬ問題の58.7％がGPUに由来するものだった。一方で、CPUに由来する問題は0.5％だった」ということが報告されています。これらの結果をもとに、Modalは「GPUの性能は驚異的ですが、信頼性が足かせとなっています」と結論付けています。
⇧ 諸々の「トレードオフ」はあるとは思いますが、「信頼性」が安定しない原因は分からず終いということなんですかね...
「保守・運用」の負担が大きそうですな...
Docker Engineで利用されているbbolt（BoltDB のフォーク）は破損し易いらしいが...
前に、
⇧ 上記の記事の時に「Docker Engine」の「バージョン」について、
- アップグレード
- ダウングレード
の正確な「情報」が見当たらない話をしたのだが、「1. アップグレード」については、
⇧ 記載されており、「リポジトリ」で「Docker」の「パッケージ」を指定して「インストール」すれば良いとあり、特に注意事項とかも無い。
なのだが、「Docker」は「破壊的変更」の頻度が高いせいなのか分からないが、「バージョン」を変更すると普通に動作しなくなることが多い...
ネットの情報を漁っていたところ、
⇧ 上記の「issue」によると、「停電」による「接続断」の影響とかも受けるらしい...
で、「Docker Engine」では「bbolt（BoltDB のフォーク）」なるものが利用されているらしく、破損し易いらしい...
■Dockerの情報を確認
[vagrant@zabbix-server ~]$ sudo docker info
Client: Docker Engine - Community
Version: 29.1.3
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.30.1
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v5.0.1
Path: /usr/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 1
Running: 0
Paused: 0
Stopped: 1
Images: 4
Server Version: 29.1.3
Storage Driver: overlayfs
driver-type: io.containerd.snapshotter.v1
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 splunk syslog
CDI spec directories:
/etc/cdi
/var/run/cdi
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: dea7da592f5d1d2b7755e3a161be07f43fad8f75
runc version: v1.3.4-0-gd6d73eb8
init version: de40ad0
Security Options:
seccomp
Profile: builtin
Kernel Version: 4.18.0-553.89.1.el8_10.x86_64
Operating System: Rocky Linux 8.10 (Green Obsidian)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.737GiB
Name: zabbix-server.example.jp
ID: adc89462-1342-4bb9-873a-8dfe7e0058e5
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
::1/128
127.0.0.0/8
Live Restore Enabled: false
Firewall Backend: iptables+firewalld
WARNING: Support for cgroup v1 is deprecated and planned to be removed by no later than May 2029 (https://github.com/moby/moby/issues/51111)
で、「Docker」が「iptables」に勝手に設定を追加してくれてしまっているらしいので、一応、確認。
⇧ 上記サイト様によりますと、2種類の確認コマンドがある模様。
「Google Gemini」に質問してみたところ、以下のような回答が返ってきた。
■Dockerが勝手にiptablesに設定を追加してるので確認
[vagrant@zabbix-server ~]$ sudo iptables-save # Generated by iptables-save v1.8.5 on Sun Jan 25 23:01:04 2026 *filter :INPUT ACCEPT [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] :DOCKER - [0:0] :DOCKER-FORWARD - [0:0] :DOCKER-BRIDGE - [0:0] :DOCKER-CT - [0:0] :DOCKER-INTERNAL - [0:0] :DOCKER-USER - [0:0] -A FORWARD -j DOCKER-USER -A FORWARD -j DOCKER-FORWARD -A DOCKER ! -i docker0 -o docker0 -j DROP -A DOCKER-FORWARD -j DOCKER-CT -A DOCKER-FORWARD -j DOCKER-INTERNAL -A DOCKER-FORWARD -j DOCKER-BRIDGE -A DOCKER-FORWARD -i docker0 -j ACCEPT -A DOCKER-BRIDGE -o docker0 -j DOCKER -A DOCKER-CT -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT COMMIT # Completed on Sun Jan 25 23:01:04 2026 # Generated by iptables-save v1.8.5 on Sun Jan 25 23:01:04 2026 *security :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT # Completed on Sun Jan 25 23:01:04 2026 # Generated by iptables-save v1.8.5 on Sun Jan 25 23:01:04 2026 *raw :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT # Completed on Sun Jan 25 23:01:04 2026 # Generated by iptables-save v1.8.5 on Sun Jan 25 23:01:04 2026 *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT # Completed on Sun Jan 25 23:01:04 2026 # Generated by iptables-save v1.8.5 on Sun Jan 25 23:01:04 2026 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :DOCKER - [0:0] -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE -A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER COMMIT # Completed on Sun Jan 25 23:01:04 2026 [vagrant@zabbix-server ~]$
■Dockerが勝手にiptablesに設定を追加してるので確認
[vagrant@zabbix-server ~]$ sudo iptables -nL --line-numbers Chain INPUT (policy ACCEPT) num target prot opt source destination Chain FORWARD (policy DROP) num target prot opt source destination 1 DOCKER-USER all -- 0.0.0.0/0 0.0.0.0/0 2 DOCKER-FORWARD all -- 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT) num target prot opt source destination Chain DOCKER (1 references) num target prot opt source destination 1 DROP all -- 0.0.0.0/0 0.0.0.0/0 Chain DOCKER-FORWARD (1 references) num target prot opt source destination 1 DOCKER-CT all -- 0.0.0.0/0 0.0.0.0/0 2 DOCKER-INTERNAL all -- 0.0.0.0/0 0.0.0.0/0 3 DOCKER-BRIDGE all -- 0.0.0.0/0 0.0.0.0/0 4 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 Chain DOCKER-BRIDGE (1 references) num target prot opt source destination 1 DOCKER all -- 0.0.0.0/0 0.0.0.0/0 Chain DOCKER-CT (1 references) num target prot opt source destination 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED Chain DOCKER-INTERNAL (1 references) num target prot opt source destination Chain DOCKER-USER (1 references) num target prot opt source destination
■Docker Engineが利用しているであろうbbolt（BoltDB のフォーク）
[vagrant@zabbix-server ~]$ sudo find /var/lib/docker/ -type f -name "*.db" -exec ls -la {} \;
-rw-------. 1 root root 32768 Jan 25 10:39 /var/lib/docker/volumes/metadata.db
-rw-r--r--. 1 root root 65536 Jan 25 19:39 /var/lib/docker/network/files/local-kv.db
-rw-------. 1 root root 131072 Jan 3 18:31 /var/lib/docker/buildkit/history_c8d.db
-rw-------. 1 root root 131072 Jan 25 19:39 /var/lib/docker/buildkit/cache.db
-rw-------. 1 root root 131072 Jan 3 18:32 /var/lib/docker/buildkit/containerd-overlayfs/metadata_v2.db
[vagrant@zabbix-server ~]$ sudo find /var/lib/docker/ -type f -name "*.db" -exec sh -c '
> ls -la "$1"
> xxd -l 4 "$1"
> echo "----"
> ' sh {} \;
-rw-------. 1 root root 32768 Jan 25 10:39 /var/lib/docker/volumes/metadata.db
00000000: 0000 0000 ....
----
-rw-r--r--. 1 root root 65536 Jan 25 19:39 /var/lib/docker/network/files/local-kv.db
00000000: 0000 0000 ....
----
-rw-------. 1 root root 131072 Jan 3 18:31 /var/lib/docker/buildkit/history_c8d.db
00000000: 0000 0000 ....
----
-rw-------. 1 root root 131072 Jan 25 19:39 /var/lib/docker/buildkit/cache.db
00000000: 0000 0000 ....
----
-rw-------. 1 root root 131072 Jan 3 18:32 /var/lib/docker/buildkit/containerd-overlayfs/metadata_v2.db
00000000: 0000 0000 ....
----
[vagrant@zabbix-server ~]$ sudo strings /var/lib/docker/volumes/metadata.db | head
volumes
python{"Name":"python","Driver":"local","Labels":{"dev.container.volume":"true"},"Options":null}vscode{"Name":"vscode","Driver":"local","Labels":null,"Options":null}
[vagrant@zabbix-server ~]$ sudo xxd -s 4096 -l 16 /var/lib/docker/volumes/metadata.db
00001000: 0100 0000 0000 0000 0400 0000 0000 0000 ................
[vagrant@zabbix-server ~]$ sudo xxd -s 4096 -l 16 /var/lib/docker/network/files/local-kv.db
b
00001000: 0100 0000 0000 0000 0400 0000 0000 0000 ................
[vagrant@zabbix-server ~]$ sudo xxd -s 4096 -l 16 /var/lib/docker/buildkit/cache.db
00001000: 0100 0000 0000 0000 0400 0000 0000 0000 ................
[vagrant@zabbix-server ~]$
■その他のDocker Engineに関わってそうな情報
[vagrant@zabbix-server ~]$ sudo ls -la /usr/lib/systemd/system | grep -e "container" -e "docker"
-rw-r--r--. 1 root root 1242 Dec 19 03:49 containerd.service
-rw-r--r--. 1 root root 1263 Nov 4 17:24 container-getty@.service
-rw-r--r--. 1 root root 1268 Dec 12 23:48 docker.service
-rw-r--r--. 1 root root 295 Dec 12 23:48 docker.socket
[vagrant@zabbix-server ~]$ sudo ls -la /var/run/ | grep docker
drwx------. 4 root root 100 Jan 25 19:39 docker
-rw-r--r--. 1 root root 4 Jan 25 10:39 docker.pid
srw-rw----. 1 root docker 0 Jan 25 10:39 docker.sock
[vagrant@zabbix-server ~]$ sudo ls -la /var/lib/docker/
total 8
drwx--x---. 11 root root 156 Jan 25 10:39 .
drwxr-xr-x. 47 root root 4096 Jan 3 11:18 ..
drwx--x--x. 5 root root 99 Jan 3 12:33 buildkit
drwx--x---. 3 root root 78 Jan 8 17:20 containers
-rw-------. 1 root root 36 Jan 3 11:08 engine-id
drwxr-x---. 3 root root 19 Jan 3 11:08 network
drwx------. 3 root root 17 Jan 3 11:08 plugins
drwx--x---. 3 root root 23 Jan 3 12:30 rootfs
drwx------. 2 root root 6 Jan 25 10:39 runtimes
drwx------. 2 root root 6 Jan 3 11:08 swarm
drwx------. 2 root root 6 Jan 25 10:39 tmp
drwx-----x. 4 root root 78 Jan 25 10:39 volumes
[vagrant@zabbix-server ~]$ sudo ls -la /var/lib/containerd
total 8
drwx------. 13 root root 4096 Jan 3 12:30 .
drwxr-xr-x. 47 root root 4096 Jan 3 11:18 ..
drwxr-xr-x. 4 root root 33 Jan 25 10:39 io.containerd.content.v1.content
drwx------. 2 root root 18 Jan 3 11:08 io.containerd.grpc.v1.introspection
drwx--x--x. 2 root root 21 Jan 3 11:08 io.containerd.metadata.v1.bolt
drwx--x--x. 3 root root 18 Jan 3 12:30 io.containerd.runtime.v2.task
drwx------. 2 root root 6 Jan 3 11:08 io.containerd.sandbox.controller.v1.shim
drwx------. 2 root root 6 Jan 3 11:08 io.containerd.snapshotter.v1.blockfile
drwx------. 2 root root 6 Jan 3 11:08 io.containerd.snapshotter.v1.btrfs
drwx------. 2 root root 6 Jan 25 10:39 io.containerd.snapshotter.v1.erofs
drwx------. 3 root root 23 Jan 3 11:08 io.containerd.snapshotter.v1.native
drwx------. 3 root root 42 Jan 3 12:30 io.containerd.snapshotter.v1.overlayfs
drwx------. 2 root root 6 Jan 8 17:01 tmpmounts
[vagrant@zabbix-server ~]$
⇧ まぁ、公式の「ドキュメント」で「bbolt（BoltDB のフォーク）」を使っているという話がヒットしないのよね...
とりあえず、「Docker Engine」の「設計」の「思想」が分からないので何とも言えないのだが、「破壊的変更」の頻度が高いので「データベース」の「データ」の互換性があるのかどうかが分からない...
そもそも、「正常」でない状態の/var/lib/docker/network/files/local-kv.dbが分からないので、破損しているのかどうかを判断する方法が皆目見当が付かない...
つまり、「Docker Engine」を構成するファイル群の、
- 何が？
- どこに？
- どのように？
影響するのかが分からないのよね...
ちなみに、「Docker Engine」の「構成概要図」について、
softwareengineering.stackexchange.com
⇧ 上記のようなものが公式の「ドキュメント」から削除されているっぽいのよね...
日本語版の古い「ドキュメント」だと、残っているっぽいが...
Docker Engine とは何ですか？
Docker Engine は３つの主なコンポーネント（構成要素）を持つクライアント・サーバ型アプリケーションです。
まぁ、「Docker」の仕組みが「ブラックボックス」であることには変わりがないのだけど...
ちなみに、
⇧ 上記の「トラブルシューティング」の「情報」も少な過ぎて全く役に立たないのよね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
