著者について。 アーチーラッセル-Flickrのバックエンドエンジニア
Flickrのようなサービスで最も高価な記事の1つはストレージです。 近年、コストを削減するためのさまざまな手法について説明しました。COSの使用、GPUでの動的なサイズ変更 、 知覚圧縮などです。 これらのプロジェクトは非常に成功しましたが、データストレージで多くのお金を失い続けました。
2016年の初めに、私たちは新しいレベルに到達するというタスクを設定しました。新しいメディアを購入せずに1年間持ちこたえることです。 さまざまな手法を使用して、成功しました。
コスト履歴
ナプキンでの小さな算術計算は、ストレージコストが大きな懸念事項であることを示しています。 Flickrユーザーは、トラフィックの多い1日に最大2,500万枚の写真をアップロードします。 それぞれに平均3.25 MB、合計80 TBが必要です。 S3のようなクラウドホスティングサービスに単純に投稿することにより、1日の写真が年間3万ドルずつ引き出され、その後も毎年コストが発生し続けます。
非常に大規模なサービスには、2億人以上のアクティブユーザーがいます。 S3のようなホスティングに保存する写真はそれぞれ1000枚で、年間2億5,000万ドル（またはユーザーあたり1.25ドル）に加えて、ネットワークおよびその他のコストがかかります。 これはすべて、新しいアカウントが登録されると蓄積され、既存のユーザーは速度を上げて写真を撮ります。 幸いなことに、私たちのコストは、主要なサービスのコストと同様に、S3の単純なストレージとは異なりますが、それでもかなりの額です。
バイトあたりのコストは下がりましたが、iPhoneのようなプラットフォームからの各写真のサイズは大きくなりました。 画像コストは大幅に変更されていません
ストレージコストは時間とともに低下します。 たとえば、S3の価格は2009年の1か月あたり0.15ドルから2014年の1か月あたり0.03ドルに低下し、クラウドホスティングプロバイダーは、まれにしかアクセスできないデータを保存するための新しい料金をリリースしました。 NASメーカーも大幅に価格を引き下げました。
残念ながら、このバイトコストの削減は、対立する力によってバランスがとられています。 iPhoneでは、カメラの解像度を上げ、連続撮影モードを追加し、短いアニメーション（ライブ写真）を追加すると、画像のサイズがバイト単位で急速に増加するため、画像のコストはほとんど変化しません。 そして、iPhoneからの画像は最大のものからはほど遠い。
これらのコストに対抗するため、写真ホスティング会社は多くのオプションを導入しています。 ほんの一部をご紹介します。低品質またはつまらない写真の保存、データストレージに対するユーザーへの課金、広告の紹介、写真の印刷物などの関連製品の販売、モバイルデバイスの購入とホスティングのリンクです。
コストを抑えるための多くの技術的アプローチもあります。 それらのいくつかを概説し、以下で実装した3つのアプローチについて説明します。ストレージシステムでのしきい値の設定、より多くの画像のスペースを節約するための既存の方法の拡張、ロスレスJPG圧縮の導入。
ストレージのしきい値設定
問題に突入し、ストレージシステムを慎重に調査しました。 設定は、大量の上書きと頻繁な情報の削除を想定して設定されていることがわかりましたが、これは起こりませんでした。 ストレージはかなり静的です。 ユーザーがダウンロード後に画像を削除または変更することはほとんどありません。 また、2つの予約領域があります。 5％はスナップショット用に予約されています-誤って削除したり上書きしたりするのに役立つスナップショットで、8.5％の空きディスク容量が予約されています。 合計で、スペースの約13％が使用されていません。 専門家は、パフォーマンスの低下を防ぐためにディスクの10％を空けておくべきだと言いますが、5％で十分です。 そこで、2つの予約領域を1つにまとめ、空きディスク領域のしきい値をこの値に減らしました。 これは問題を解決する最も簡単な方法です（今のところ）が、良い結果をもたらしています。 いくつかの小さな構成変更の後、メディアの8％以上を解放しました。
ストレージのしきい値設定
既存のアプローチを拡張する
以前の記事では、サムネイル画像と知覚圧縮の動的生成について説明しました。 2つの方法の組み合わせにより、削減されたコピーのストレージスペースが65％削減されましたが、これらの手法は2014年以前にダウンロードされた多くの画像には適用されませんでした。 これには1つの大きな理由があります。古いファイルの大規模な変更は本質的に危険であり、安全な操作には多大な開発時間と労力が必要です。
縮小コピーの動的生成のシステムを拡張すると、動的生成インフラストラクチャの負荷が大幅に増加するのではないかと心配したため、最も人気のない画像からのみ静的縮小コピーを削除することにしました。 このアプローチを使用して、4つのGPU内で削減されたコピーを動的に生成するという全体的な負担を維持しました。 このプロセスには、負荷の高いストレージシステムがあります。 負荷を最小限に抑えるために、異なるボリュームで操作をランダム化しました。 プロセス全体に約4か月かかりました。その結果、ストレージシステムにしきい値を設定した後よりもさらに多くのスペースを解放しました。
サムネイルのサイズを縮小する
ロスレスJPG圧縮
Flickrは、アップロードされた画像のバイト単位の正確な記録に長い間取り組んできました。 これにより、最大空き容量に制限が課されますが、ロスレスJPG写真を圧縮するツールがあります。 よく知られた2つのツールは、DropboxのPackJPGとLeptonです。 これらのプログラムはJPGをデコードし、より効率的な方法を使用して非常に慎重に圧縮します。 通常、JPGを約22％削減できます。 Flickrはたくさんあります。 欠点は、クランプが大量のCPUリソースを消費することです。 PackJPGは1つのコアで約2 MB /秒の速度で動作します。つまり、ペタバイトの写真を圧縮するには約15コア年が必要になります。 Leptonはいくつかのコアを使用し、15 MB / sの速度でPackJPGよりもはるかに高速ですが、同じジョブを実行するにはほぼ同じCPUリソースが必要です。
このCPU要件は、サービスの毎日の運用も複雑にします。 Flickrですべての画像を圧縮すると、デコードタスクを実行するために数千のコアが必要になる可能性があります。 オリジナルにアクセスするためのユーザー認証を要求するなど、圧縮画像へのアクセスにいくつかの制限を導入することを考えましたが、最終的には、アクセスがまれなプライベート写真に目を向けると、開梱はまれなイベントになると判断しました。 さらに、最大イメージサイズを制限すると、展開するための最大コンピューティングリソースが制限されます。 この変更は、既存の一連のテクノロジーの一部として、追加のCPUリソースを割り当てる必要がなく、ユーザーの観点からは最も小さな変更のみで展開されました。
元のユーザーの写真でロスレス圧縮手順を実行することは、おそらく最もリスクの高いアクションでした。 縮小されたコピーは問題なく再作成できますが、破損した元のイメージは復元できません。 私たちの戦略の重要な要素は「ピンチ-解凍-チェック」方法でした。各ピンチ画像は解凍され、オリジナルが削除される前にオリジナルのオリジナルと比較されました。
作業はまだ進行中です。 かなりの部分を圧縮しましたが、アーカイブ全体の処理には時間がかかり、年の半ばまでに「1年に1つの新しいバイトではない」という目標を達成しました。
将来のオプション
検討中のアイデアはまだいくつかありますが、まだ実装されていません。
各イメージの現在のストレージモデルには、2つのデータセンターに保存されている元の小さなコピーがあります。 このモデルは、画像がいつでも比較的迅速に表示できる状態にあることを前提としています。 しかし、数か月以上使用されていないアカウントのプライベート写真は見られないでしょう。 これらの写真を「フリーズ」し、小さなコピーを消去して、「眠っている」ユーザーが戻った場合に再度生成することができます。 このような「デフロスト」プロセスは、通常のアカウントでは30秒未満で完了します。 さらに、プライベート写真（「眠っている」ユーザーではない）については、各縮小コピーの1つの非圧縮バージョンに切り替えて、必要に応じて解凍できるように圧縮バージョンを2番目のデータセンターに保存できます。
おそらく、「眠っている」ユーザーの元の各写真のディスクに2つのコピーさえ必要ありません。 まれなアクセステープドライブを備えた低速システムに1つのコピーを移動し、もう1つをディスクに残すモデルの概要を説明しました。 これにより、クラッシュ時のデータの可用性が低下しますが、これらの写真は「眠っている」ユーザーのものであるため、影響は最小限に抑えられ、ユーザーには写真の小さなコピーが表示されます。 ここで最もデリケートな部分は、テープドライブでの検索時間が非常に長いため、データの配置です。 「眠っている」写真と見なされるものの条件に応じて、このような方法は最大25％のディスク容量を節約できます。
また、重複を排除する可能性も調査しましたが、3％の領域で重複の数を特定しました。 ユーザーは自分のデバイス上に自分の画像の複製をたくさん持っていますが、それらはダウンロードツールによって計算されます。 また、小さなコピーに使用できる代替のグラフィカル形式も検討しました。 WebPは通常のJPGよりもコンパクトかもしれませんが、知覚圧縮を使用することで、サイズ変更操作を高速化しながらバイト単位でWebPにアプローチすることができました。 BPGプロジェクトは、H.265に基づいたはるかに効率的なエンコードを提供しますが、知的財産の負担やその他の問題があります。
ビデオにはいくつかの最適化オプションがあります。 Flickrは主に写真を対象としていますが、ビデオファイルは通常はるかに大きく、多くのスペースを占有します。
おわりに
最適化のいくつかの段階
2013年以降、ストレージシステムを約50％最適化しました。 最新の努力のおかげで、私たちは2016年に1つの追加メディアを購入することなく生きましたが、まだ追加の最適化オプションがあります。
Peter Norby、Teja Komma、Shijo Joy、およびBei Wuは、ゼロバイト予算のチームのバックボーンでした。 他の多くの人が支援しました。