Articles from 2月 2018

この前、久しぶりに512GB SSDのMacBookで映像編集を行いました。
普段僕はどのマシンを使っていても基本ツール（Font / Application / Basicな素材など）で150GB程度のデータと、作業データ50GB程度で合計200GB前後を消費していますが、今回、結構長編の映像を作業していたら、気づいたら450GBくらいまでストレージ容量を使ってしまっていました。

こうなると、ほぼ全ての作業がもっさりします。
デスクトップのアイコンを表示するのに数分を要するくらい。もう、年代物のMacをいじっている様な感覚です。

僕はすっかり128GBくらいしか容量がなかった頃のストレージマネジメントの基本「保存容量で半分以上使うとパフォーマンスに影響する」を忘れていました。
SSD MacBookの時代になって、

• ストレージは寿命を気にしなければならない
• 容量が少なくなったまま使うとパフォーマンスの低下とともに寿命が著しく短くなる（特定の領域を何度もWriteする羽目になるから）
• メモリスワップは積極的にSSDに書き込まれる。だから、目に見えない使用容量がある

など、気にしなければならないことはいくらでもあったのに。。。笑

なんでそんなことを忘れてしまったのか？

ここ10年ほどの間、僕はオンラインプロダクトに関するエンジニアリング最前線でMacを使ってきたのですが、
その間に僕が作り上げたプロダクトがハンドリングするデータのほとんどはサーバー上に保存されます。
ここに、上記の事実を忘れさせた要素があったことに気がつきました。

オンラインプロダクトの開発を行っていると、サーバ上のストレージマネジメントは今や上限容量の90%程度までは利用して良いのが前提です。
これは、

• もともとLinuxなどのサーバOS自体がそういったストレージマネジメントを前提に作られていること
• サーバの用途（DatabaseやTCP Connectionさばき）が特化している状態がほとんど

であるためもありますが、これはそうはいっても物理サーバではそれでもせいぜい75%程度までが限界でした。
※もっと変態的なチューニングをしている人はいそうですが。。。

それが昨今、AWS / GCP / Azure / IBMなどで展開される仮想マシンでは、ミドルウェア特性を理解してうまく組まれているアーキテクチャ上で動いているシステムや、AWS RDSやElasticSearch、GCP BigQuery / Spannerなど、アプリケーション層をパッケージングして提供しているマネージドサービスなどでは、下手するとストレージ使用量が100%に到達してデータが保存できなくなってから気づく、みたいなことが珍しくありません。（監視をしっかりして珍しくしなければならないという議論はここでは割愛します）

仮想マシンやマネージドサービスのストレージ容量とは

僕はすっかりと数年の間で上記の様な頭になってしまっていたのですが、手元のコンシューマ機と仮想マシンやマネージドサービスのストレージ容量は、その意味するところが全く違います。
2013年にMicrosoftが発表したのHyper-Vに始まり、近年のPV・HVMなどの仮想化技術は、そもそも仮想マシンのストレージが分散ストレージ上の仮想ストレージである特性を活かして、この「保存容量が少なくなってきたときにパフォーマンスが低下する問題」をものの見事に「まるでそんなことはなかったかの様にパッケージング」しています。
こうした背景を鑑みると、

• コンシューマー機のストレージ容量は「物理的に保存できるサイズ」
• 仮想サーバのストレージ容量は「保存して良い（許可された）サイズ」

と言い換えることができます。
すっかりとこのことを忘れていたのが、今回僕が自分のMacの使い方を誤った原因でした。
いまだによく叫ばれる「仮想マシンは物理マシンはどっちがコストパフォーマンスが良いのか？」という観点は、仮想マシンを動かすバイザーの性能傾向をちゃんと考えないと一概に答えが出せないなぁと思うのでした。
そういえば、そこの観点は抜けてたな。。。と。

独り言でした。
その前に、そもそもMacBookで映像編集は可能なのか？