キャッシュヒット率(CHR)は、キャッシュで見つかったリクエストのパーセンテージを把握する一般的な指標です。残念ながら、CHRを指標にしすぎると、いくつかの重要な意味を見落とす危険があります。
現実のワークロードでは、データ・アクセスが非常に偏っていることが多く、本番キャッシュのヒット率は日常的に90％以上、時には99.9％を超えることもあります。例えば最近のDynamoDBの論文では、メタデータキャッシュへの99.75%のキャッシュヒット率を挙げています。この論文では、高いキャッシュ・ヒット率の深い意味も取り上げています。キャッシュがコールドになった場合の二峰性の挙動です。。DynamoDBチームの分散システムの専門家でさえ、キャッシュヒット率が低下した結果について実体験していまする。彼らだけでありません。多くのチームは、魅惑的に高いキャッシュヒット率のマイナス面を見過ごしてしまっています。
単純に考え直すだけで、エンジニアはこのコンセプトの核心的な意味合いであるキャッシュ・ミス・レート（CMR）を内面化することができます。CMRのスパイクは負荷のスパイクに直接相関するため、データベースへの負荷の増加の影響についてチームを正直に保つための強力な指標となります。
CMRが1％という単純な例を考えてましょう。バックエンドをヒットしなければならないリクエストが100％増加します。一方、同じシナリオをCHR測定基準で枠付けすると、99%から98%に低下しますが、1％の低下は些細なことです。データベースの負荷が2倍になることは、もっと憂慮すべきことです。
CHRと負荷の関係性は以下で演算できます：
Load = CURRENT_CHR / (1 – NOMINAL_CHR)
これは難しい算数ではありませんが、CMRの急上昇をCHRの低下と認識した場合、その重大な意味を見落とすように脳を騙すには十分複雑です。CMRに注意を払うことで、メンテナンス・ウィンドウやスケーリング・イベント中に、一見小さな問題に見えることが、システム全体に与える影響を素早く文脈化することができます。
運用ダッシュボードを見てみましょう。ほとんどすべてのアラームがスパイク（レイテンシー、エラーなど）に対して発生しています。ディップ（リクエスト率など）に対するアラームには良いユースケースもありますが、私たちはスパイクを探すように訓練されています！キャッシュが冷えていれば、キャッシュ・ミス・レートは急上昇します。
CMRスパイクの原因は？
再起動は、デプロイメントや故障したノードなどによって引き起こされます。どちらの場合も、新しいノードはデータ（コールドキャッシュ）がない状態でエコシステムに導入されます。AWSのElastiCacheでは、デプロイはユーザーが選択したメンテナンスウィンドウに限定され、一方、障害ノードはEC2インスタンスの障害として定期的に発生する可能性があります。残念ながら、レプリケーションやマルチAZのセットアップがあったとしても、ノードの障害やメンテナンスウィンドウはCMRに影響を与えます。さらに、キャッシュのウォームアップにメンテナンスウィンドウよりも大幅に時間がかかる場合があり、特定のシナリオではCMRへの影響が大幅に長くなることを意味します。
リハッシュは通常、キャッシュのスケールインやスケールアウトの際に発生します。新しいノードの導入やノードの削除によってキャッシュ・トポロジーが変化し、キーの再分散が起こります。リハッシュの初期段階では、キャッシュ・クライアント間で、特定の鍵の置き場所について 意見が分かれることがあります。クライアントAがノードXに鍵を「セット」したが、クライアントBがノード Yから鍵を取得した場合、キャッシュ・ミスが発生します。リハッシュの初期段階の後、一部の鍵は新しく指定された場所にリセットされて いないかもしれません。このシナリオでは、クライアントが新しい場所でその鍵に対して再度「セッ ト」を発行するまで、クライアントは新しい場所からのミスを取得し続けます。さらに、アイテムが存在しないことを観測している複数のクライアントから set がトリガーされることも多くあります。これはバックエンドの負荷を増やすと同時に、冗長な`set’コマンドによってキャッシュのパフォーマンスを低下させます。
CMRのスパイクを最小限に抑えるには？
レプリケーションはデータのコピーを複数作成します。これにより、与えられたキーの潜在的な読み取りスループットが向上するが、キーが見つかる場所も複数になります。例えば、システム内に3つのレプリカがあり、それらの間でリクエストが均等に分散されている場合、1つのノードが故障しても、リクエストの33％がコールドノードに到達し、ミスを返すだけです。
キャッシュのウォーミングによって、新しいノードは、読み込みパスで利用可能になる前に、いくつかのsetコマンドを観察することができます。例えば、Facebookのmcrouterは、新しいノードが入ってくると、そのノードをウォームアップします。PinterestはEC2上のセルフマネージド・キャッシング・ノードで同様のパターンを使っています。キャッシュのウォーミングはシンプルです。ノードを突然終了させ、その代わりに新しいコールドノードを投入する代わりに、新しいノードがキーの意味のある部分を持つまでの限られた期間、トラフィックの一部を新しいノードにレプリケートします。これは、人気のある鍵が顧客に最も大きな影響を与えることが多いという事実を考慮すれば、非常にエレガントな手法です。キャッシュウォーミングによってCMRのスパイクがなくなるわけではないが、たいていの場合、CMRのスパイクを有意に薄めることができます。
CHRやCMRの影響が矮小化されるとどうなるか？
顧客やプロバイダーは、一般的な動作として多少のミスを許容できます。それにもかかわらず、ミスシナリオの明確な仕様がないため、キャッシュチームが感じるべきオーナーシップがぼやけてしまいます。ノードの故障（またはデプロイメント）、トポロジーの変更（スケールイン／スケールアウト）、メモリ圧力に起因する退避によって引き起こされるミスは、大部分軽減することができます。残念ながら、キャッシングサービスは、デプロイメント、スケールイン、スケールアウトによって引き起こされるCMRスパイクを緩和するために必要なエンジニアリング努力を投資していません。その代わりに、プロバイダーがすべてのキャッシュミスを顧客のせいにしているのをよく見かけます。 “もし顧客が私にキーを渡さなかったとしたら、どうやってそれを返せというのか？” ElastiCacheのようなサービスは、繰り返されるスケールインとスケールアウトによるCMRへの影響を減らすためのベストプラクティスとして、スケールインを無効にすることを顧客に推奨しています。
スケールインを無効にする – Target Trackingの自動スケーリングは、メトリクスのスパイク/ディップが連続的なスケールアウト/スケールインの振動を引き起こす可能性があるため、ワークロードが徐々に増減するクラスタに最適です。このような振動を避けるために、スケールインを無効にして開始し、後で必要に応じて手動でスケールインすることができます。
スケールイベントを最小化することはCMRにプラスの影響を与えますが、その代償として利用率が10%未満のクラスタが無駄にオーバープロビジョニングされることになります。結局、顧客は高い請求で苦しむことになります。
CMRについてのMomentoの見解
CMRはMomentoの基本的な焦点です。CMR の急上昇は、顧客のデータベースへの負荷の増大に対応することを理解しており、CMR の急上昇を最小限に抑えることができれば、顧客に真の弾力性とメンテナンス ウィンドウのない継続的な可用性を提供できます。これが、Momento を設計する上での原動力となりました。
Momentoのプロキシ・フリートは、低レイテンシでgRPCに裏打ちされたメッセージング・バスを使用しています。
これにより、プロキシ・フリートはキャッシュ・トポロジーの状態変化を迅速に知ることができ、キーがどこにあるべきかについてノード間で不一致が生じる期間を最小限に抑えることができます。
Momento SDKはサーバー側のキャッシュ・トポロジーの変更に影響をうけない
今日、最新のキャッシュ・クライアント（SDK）はキャッシュ・トポロジーを追跡する必要があります。このリーキーな抽象化を取り除くことで、舞台裏での状態変化にさえ気づかない、よりシンプルなSDKを生成することができます。
Momentoは、デプロイ時、スケールイン時、スケールアウト時にノードをウォームアップします。
トポロジーの変更を抽象化するだけでなく、ウォームアップ後にノードを導入します。このため、メンテナンスウィンドウが不要になり、CMRに影響を与えることなく継続的にデプロイできます。
今度、あなたのチームがCHRをチャートに貼ったり、デザインレビューで議論したりするのを見かけたら、それをCMRに関する会話に置き換えて、新しい洞察が得られるかどうか考えてみてください。一方、キャッシングベンダーが「弾力性」や「自動スケーリング」を提供している場合は、デプロイ時、スケールアウト時、スケールイン時に CMR がどうなるかを尋ねてみてください。
Share
EN 
JP