スキルのある社内のエンジニアを、大量の写真を表示するためのバックエンド部分の問題解決に投入するべきか、それともユニークな新機能を開発するの に投入するべきか選ばなければならない。答えは明らかだ。優秀なエンジニアはユニークな機能の開発に投入し、他社と技術的な課題がオーバーラップする部分 はソリューションを購入すればいい。そこで我々は簡単な方法を選ぶことにした。NFSストレージ製品を購入したのだ。
ところが、そのファイルシステムは大量のファイルをサポートするのに向いておらず、データはファイルキャッシュに収まらず、ストレージ容量よりもI/Oの多さによって性能が限界を迎えてしまった。
大量の写真データを扱うとき、ディスクの物理I/Oが性能の限界を決める。調査してみると、1つの写真を取り出すのに10回もの物理I/Oが行われ ていた。データは複雑なディレクトリの中に格納され、ファイルキャッシュメモリは大量の写真データのためにほとんど役に立っていなかった。
そこでまず、ファイルメタデータの扱いやディレクトリの構造、ブロックサイズなどについて最適化を行い、物理I/Oを2~4回程度までに減らした。
さらに、独自のHeystackと呼ばれるオーバーレイファイルシステムを構築した。これは多くの写真データを集めてそれらをOSからは1つのファ イルのように見せかけ、メタデータはキャッシュするなどの仕組みを持つ。これでほとんどの場合1回の物理I/Oで写真データを取り出せるようになった
Facebookが大規模スケーラビリティへの挑戦で学んだこと(前編)~800億枚の写真データとPHPのスケーラビリティ問題 - Publickey
ストレージの場合、CPUやメモリより先にIOPSによって限界が決まります。
