過去何度かトライしてきたシステム監視サービスにようやく見通しが立った。インハウスで構築できる状況には、おそらくあと5年ほど要するだろう。
要するにDRAM管理の弱いツールをコンテナで安定動作させる方法がない、ということが分かった。この結論に至るまで、多様なツールをセットアップした。
とくにデータストアについては、PostgreSQLなどのRDBMSやValkeyなどの素朴なKVSだけが例外的にメモリ管理が行き届いている状況で、ほかのミドルウェアは全滅と言える。監視システムはそれぞれ独自のデータストアに依存しており、ベアメタルのハード環境が必須だ。
DRAMが高止まりしている
この先もっとも簡潔なブレークスルーのシナリオは、DRAMの価格が10分の1に下落することだ。サーバーのメモリ容量が10倍になれば、相当多くのツールが概ね安定動作するだろう。
DRAMのコモディティ化はすでに起きていてもおかしくない展開ではあったが、明らかに10年ほど前に止まった。たしかに半導体微細化が限界にぶち当たった影響は大きいのだろう。チップ当たりの容量密度が10倍になるような技術進化を達成できていない。
ただ、技術進歩が完全に止まったとしてもエクスペリエンス・カーブのような量産効果まで市場に届いて来ないのは異常に見える。
近年進展している世界経済のブロック化や戦時雰囲気のような産業政策の影響が大きいのではないか。そう考えるとDRAM価格はこの先10年も高止まりしたままの展開が十分考えられる。
コンテナOSが仮想メモリを制約している
ハード自体が高価であることに加えて、コンテナ化により仮想メモリの機能が退化していることも逆風に拍車をかけている。
LinuxなどのUnix OSはスワップというDRAM容量を補完する機能を備えているのだが、kubernetesなどのコンテナOSは長らくスワップを実装できずに来ている。
スワップは、SSDなどのディスクをメモリ領域として転用することで擬似的にDRAM容量を拡張する。
当然ながらディスクは遅いので、スワップをDRAMと同じものとして扱ってしまうと顕著に性能劣化する。これはスラッシングと呼ばれている。
kubernetesは現状スワップを本来のDRAMと区別して扱う機能がないため、機能ごとdisableにしている。よって実メモリ以上のDRAMを使う状況になるとOOMKillerによってアプリが丸ごと異常終了するより他ない。
この状況は良いと考えられているわけではないが、v1.30現在では設計が議論中であり、実現までまだ時間がかかる。
