Memcachedスケーリング戦略
現在、4つの専用memcachedサーバーを備えた本番環境を実行しています。各サーバーには48GbのRAM（42はmemcache専用）があります。現在は正常に動作していますが、トラフィックとコンテンツは増加しており、来年もきっと成長するでしょう。
Memcachedをさらにスケーリングするための戦略についてどう思いますか？今までどうしましたか：
ボックスにRAMがいっぱいになるまで追加しますか？同じ数のボックスでキャッシュプールを効果的に2倍にしますか？それとも、同じボックスを同じ数でさらに追加して水平方向にスケーリングしますか？ RAMの量。
現在のボックスは確かにより多くのRAMを処理できます。CPU負荷が非常に低く、唯一のボトルネックはメモリですが、キャッシュを分散して物事を作るのがより良い戦略ではないかと思います。より冗長で、1つのボックスを失うことによるキャッシュへの影響を最小限に抑えます（48Gbのキャッシュを失うのに対して96Gbを失う）。この決定をどのように処理しますか（または処理しますか）。
NICを最大限に活用せずに、100 GBを超えるメモリを消費するのは、何を移動しているのかを知りたいのです。
Memcacheはマシン間でかなり直線的にスケーリングするため、質問する必要があるのは次のとおりです。
- 私のシステムバスは現在飽和状態ですか？
- これはCPU使用率とは関係がない可能性があります-DMA転送はそのように表示されません
- 高密度メモリは、メモリ量の増加を含む新しいボックスと比べてどれくらい高価ですか？
- ラックスペース、消費電力などの全費用。
- キャッシュの25％を1％の確率で失うことと、キャッシュの12.5％を2％の確率で失うことの間に根本的な違いがありますか？ （ランダムに選択された故障率）。
スケーリングとは、10％が直感で、70％が測定と適応、20％が戻って別のことを試すことです。
それらが最も弱いリンクを最大にするか、費用効果がなくなるまで、それらをロードします。彼らはすでにそこにいるかもしれません。
私がこれを行ったとき、通常、ポイントボックスのサイズ（ラックスペースのコスト）、高密度チップの費用、および障害シナリオの処理の間に損益分岐点があります。これはほとんどの場合、最大メモリ密度よりも低い構成になります（また、通常は利用可能な最速のチップではありません）。これにより、前述のように、ノード障害の影響が改善され、通常はコスト効率が向上します。この選択を行う際に考慮すべきいくつかのコスト/事柄：
- ノードコスト（cpu/mem/etc）
- ラックスペースコスト
- 管理オーバーヘッド/コスト
- 障害シナリオ（N + 1を実行しようとしていますか？）
また、クラスターを成長させるときにボックスを最大化するようにアップグレードしました（通常はクラスターがかなり小さい場合）。スケールするにつれてメモリを追加購入する方が短期的には大幅に安くなり、より大きなアーキテクチャを作成するための時間を増やすことができるためです。決定。