FacebookにおけるFlashcacheの歴史
Facebookは2010年にFashcacheを使用しました***当時、エンジニアはまだSASまたはSATAドライブベースのソリューションと完全にフラッシュベースのソリューションのどちらかを選択していました。しかし、どちらの選択肢も満足のいくものではありませんでした。2010年当時、SATAは読み書きが遅く、SASは多くのハードディスクを必要とし、フラッシュの価格は高かったのです。
1つの可能なアプローチは、データベースを複数の階層に分割することでした。1つは最も要求の多いデータを処理するためのもので、高性能なハードウェア・デバイスでバックアップする必要があり、もう1つは要求の少ないコールドデータで動作する低性能なデバイスです。当時、データ・アクセス・パターンが典型的なZipfian分布を示していたため、このアプローチは技術的に実現可能でした。欠点は、このアプローチが比較的複雑であることで、当時利用可能だったデータのサイズでは、複雑さを追加することが賢明な選択でないことは明らかでした。
2010年、この問題をソフトウェアレイヤーから解決する好機が訪れました。そこで、InnoDBに直接L2キャッシュのサポートを追加することの実現可能性が評価されましたが、MySQLのようなデバイスのキャッシュを追加する方がより望ましいことが判明しました。その結果、FlashcacheをLinuxカーネルのデバイスマッピングモジュールとし、大規模な本番環境にデプロイすることを選択しました。
パフォーマンス分析と最適化
InnoDBの圧縮性能の助けを借りて、より多くの論理データが保存され、通常、より高いIOPSが必要とされました。その後、一部の古いデータは他の階層に移行され、通常の読み取りに影響を与えることなく、可能な限りスペースを取らないように最適化されました。その後、ディスクIOの負荷需要も増加しているため、ハードディスクIO制限の一部のサーバーは飽和状態に達しました。これを踏まえて、本番環境におけるFlashcacheのパフォーマンスをより深く調査し、さらなるパフォーマンス向上の可能性を検討し始めました。
異なるタイプのディスク・ドライブの動作特性は、ハード・ドライブの回転速度、ヘッド速度、1回転あたりの読み取り回数など、多くの要因によって決まります。過去において、SATAハードディスク・ドライブは一般的にエンタープライズSASコンポーネントほど性能が良くなかったため、システム性能を向上させるためにはソフトウェア・スタックを最適化することが重要でした。
iostat」のようなツールは、システムの全体的なパフォーマンスを理解するために多くの場合役に立ちますが、より深い調査には役立ちません。ここでは、Linuxのblktraceツールを使用して、データベース・ソフトウェアによる各リクエストをトレースし、フラッシュ・メモリとハードウェア・キャッシング・メカニズムがこれらのリクエストをどのように処理するかを分析しました。その結果、改善すべき 3 つの領域、すなわち、読み取り/書き込みの分散、キャッシュの再利用、効率的な書き込み操作が判明しました。
1.読み書き分配
分析の結果、書き込み操作はドライブ上の一部の領域に集中している一方、読み取り操作は非常に不均一に分散していることが明らかになりました。より多くのデバイスをFlashcacheに追加してワークロードを監視し、キャッシュの挙動をより正確に測定しました。高いレベルでは、概ねこのようなことが起こりました：
キャッシュ・メンテナンス作業を簡素化するため、キャッシュ・デバイスは2Mサイズの多数のセルに分割され、ストレージ全体の2Mサイズの部分がキャッシュにリニアにマッピングされます。しかし、このアーキテクチャでは、ホット・テーブルが同じキャッシュ・セルに整列され、コールド・テーブルが他の未使用セルを占有することになります。
この問題の解決策は、キャッシュの小さなチャンクを考慮できる優れたコンフィギュレーション・アルゴリズムを持つか、与えられたセル内のデータの種類を増やすかのどちらかです。簡単な戦略調整の結果、後者の選択肢が決定的に選ばれました。
ハードディスク側に関連するデータを2Mから256Kに削減。
フラッシュ側に関連するデータを2Mから16Mに増加（セルあたり512ページから4096ページへ）
線形マッピングをランダム・ハッシュ・フェッチに置き換え
上記の変更により、ホットデータがより多くのキャッシュ領域に分割されます。下図はその効果を示しています：
変更前は、キャッシュの50パーセントがハードディスク操作の80パーセントに「貢献」していました。変更後、同じ割合のキャッシュでは、ハードディスク操作の50%しか実行されませんでした。
2.キャッシュ回復
Facebookでは、データベースサーバーは小さな論理ブロックを使用しており、圧縮されたInnoDBテーブルは4Kまたは8Kしか使用しませんが、非圧縮のものは16Kサイズの論理ブロックを使用します。z Flashcacheユニットのサイズを大きくした後、ワークロードが変化したため、FIFOに代わるものを探す必要がありました。
blktrace サブシステムによって提供されるトレース機能を使用することで、異なるキャッシュ再利用アルゴリズムのパフォーマンスをモデル化するためのメカニズム一式を実装する必要がなくなります。キャッシュを通過するすべてのアクションを管理しなければならないので、シンプルで効率的でなければなりません。Pythonで書かれたLRUデコレータは20行弱のコードで、中間点挿入機能を追加しても15行のコードでした。最終的に、データセット上での再生アルゴリズムの異なる性能をモデル化するために、簡単なシミュレータが書かれました。中間点挿入機能付きLRUがより効果的であることがわかりましたが、それでも新しく読み込んだデータブロックを挿入するためにLRUの***中間点を決定する必要がありました。
複数回参照されていることが判明したデータブロックは、LRUの中間点から先頭に移動されました。これらのデータ・ブロックが***回読み取られたときにLRUの先頭に置かれた場合、1回だけのデータ・ブロックの多くは、より頻繁に読み取り操作が行われるページをLRUから押し出すことになります。もしLRUの中点に置かれた場合、それらは50パーセンタイルになります。それらを先頭に配置した場合、それらは0パーセンタイルになります。図に示すように、キャッシュが有効であるためには、挿入ポイントは少なくとも85パーセンタイルになければなりません。
この動作は特定のワークロードに基づいており、これを理解することでFlashcacheの効率を向上させることができます。現在、Flashcache は中間点挿入ユニットを 75 パーセンタイルで使用しています。この設定は、古いページが25%存在することを許容するという点でやや保守的ですが、リファクタリングやマイグレーションなどのキャッシュ動作が以前のモデリングでは考慮されていなかったため、それでも標準的なLRUより優れています。
Facebookでは、複数のデータベースインスタンスが各マシンで実行され、最も長く稼動しているインスタンスの古いテーブル領域が優先され、新しいテーブルは慎重に扱われます。
3.書き込み操作の効率
フラッシュキャッシュは信頼性の高いプリライト・キャッシュとして機能し、ハードディスクへの多くの書き込みを事前にフラッシュメモリに統合することができます。
このモデルでは、キャッシュ・ユニットごとにダーティ・ページのパーセンテージを固定しようとします。異なるキャッシュ・ユニットは異なる振る舞いをするので、このモデルでは、アンダー・アロケートまたはオーバーオール・アロケート・キャッシュが修正されたページに対して最終的に構成されます。いくつかの部分はノンストップで書き込まれ、いくつかのダーティページは1週間キャッシュされるため、リードキャッシングに深刻な影響を与えます。
この問題を解決するために、読み取り操作と書き込み操作をもはや分離しないダーティ・データ再生方法が実装されています。すべてのデータは同等に扱われ、キャッシュがページを再利用したい場合は、LRUで最も古いページを探すだけです。最も古いページがダーティな場合、キャッシュはバックグラウンド再生利用アルゴリズムを呼び出してページを再生利用し、次に古いページを再利用して新しいデータをキャッシュします。
これは、書き込み操作の問題を解決すると同時に、書き込み前キャッシュの書き込みマージ効率とスピード書き込み能力を向上させます。また、読み出し操作に使用できる領域を増やし、全体的なキャッシュ効率を向上させます。
今後の課題
以上の3つの改善が達成されたことで、今後の課題が見えてきました。まず、メタデータの構造を調整してデータの読み出し効率を向上させましたが、テラバイト級のキャッシュデバイスとハードディスクストレージで構築される次世代システムをFlashcacheでサポートするには、まだ多くの課題が残っています。また、マルチコアCPUでの並列データ読み出しをサポートするための、きめ細かなロック機構の開発も進行中です。
同時に、フラッシュ・メモリのギガバイトあたりの価格は低下していますが、理想的な範囲にはまだ程遠い状態です。SSDには書き込み回数に制限があるため、書き込み回数が上限を超えないようにすることも重要です。フラッシュにデータを書き込むとキャッシュ・データが失われるため、小さすぎるフラッシュ・デバイスを使用すると落とし穴があります。この場合、***どのキャッシュ層も複数の層間の大きな性能差に依存するため、回転が速すぎないドライブを使用します。
これらの改良により、FlashcacheはFacebookソフトウェアスタックのビルディングブロックとなりました。新しいブランチで数千台のサーバーを稼動させると、flashcache-1シリーズからパフォーマンスが劇的に向上しました。最も多忙なシステムでは、読み取り操作のI/Oが40%低下し、書き込み操作のI/Oが75%低下しました。flashcache-3シリーズのコードはGitHubにコミットされています。
