ElastiCache Redisは、毎秒数百万のクエリやテラバイトの保存データをサポートするために簡単に拡張することができます。しかし、予想される最大のスパイクの容量を24時間365日プロビジョニングする必要はない可能性があります。スパイクの大まかな形がわかっていれば、Elasticache Redisのオートスケール機能を利用できるかもしれません。
スケーリング・ディメンションを理解する
ElastiCache Redisはキャパシティプランニングを完全にコントロールすることができます。そのため、スケーリングを検討する次元を理解することが重要です。簡単に言うと、RAM（メモリ圧力）、CPU（TPS圧力）、およびネットワーク制限（帯域幅または秒あたりのパケット）に基づいてクラスタをスケールする可能性があります。
作業セットがElastiCacheクラスタの利用可能なメモリより大きいと、キャッシュヒット率が悪くなります。より多くのメモリを持つことで、キャッシュヒット率を損なうことなく、より大きなワーキングセットを扱うことができます。メモリ使用率と退去のメトリクスを見ることで、メモリ・プレッシャーにさらされているかどうかの洞察を得ることができ、オートスケーリング・ポリシーを通知するために使用することができます。 同様に、CPU使用率のメトリクスを見ることで、CPU使用率に対してスケーリングが必要になる可能性があるかどうかを知ることができます。
ElastiCache Redisでネットワーク帯域幅を使用する場合、事態はかなり厄介になります。ほとんどのチームがトラブルに見舞われるのはここです。EC2インスタンスは数分間バーストすることができるが、一般的にEC2サイトで宣伝されている「Up To」の帯域幅数を維持することはできません。したがって、スパイクが短時間であれば、EC2のバースト容量がその日を救うことができます。しかし、（多くの場合5分後に）EC2は最終的に帯域幅のスロットルを開始し、ノードを厳しく停止させます。これは特に厄介で、それまで維持できていた負荷が突然機能しなくなるからです。例えば、r6g.largeは最大10Gbpsの帯域幅を提供するが、持続的に扱える帯域幅は0.75Gbpsに制限されます。
実際に何をスケールアップできるのか？
ElastiCache Redisにはシャードとレプリカという2つのスケーリング単位があります。シャードはデータがいくつのスロットに分割されるかを決定し、レプリカは各シャードのコピーの数を決定します。
ElastiCache Redisクラスタに複数のシャードを持つ必要がある理由はいくつかあります。第一に、データが単純に単一のノードに収まらない場合、シャードによって複数のノードにデータを分割することができます。第二に、データセットが単一のノードに収まるが、必要な書き込みスループットが単一のノードではサポートできない場合、シャーディングによってクラスタ内のシャード間で書き込みスループットを倍増させることができます。
システムにレプリカを置く理由は他にもある。第一に、リードを多用するワークフローの場合、レプリカを増やすことでリードを複数のマシンに分割できます。これにより、CPUやネットワークへの負荷を軽減することができます。第二に、レプリカはノード障害に対する冗長性に優れています。具体的には、インスタンスが死んだ場合にキャッシュのヒット率に影響を与えたくありません – そのため、レプリカを持つことは、そのようなシナリオで優雅にデグレースするのに役立ちます。
チートシートとして、非常に大量のデータを保存しようとしたり、高い書き込みスループットを処理しようとしたりする場合は、より多くのシャードが必要になります。しかし、読み込みスループットを向上させるだけであれば、レプリカを増やすことでフリート・スケールを向上させることができます。
ElastiCache Redis autoScalingの公式ベストプラクティス（そして何が問題なのか？）
AWSは、ElastiCache Redisクラスタをオートスケールするための公式ベストプラクティスをここに掲載しています。このベストプラクティスの中で、私が特に面倒だと思ったものがいくつかあります。
１．スケールインを無効にする。いや、これは私たちがガイドラインを誤解しているのではありません。ベストプラクティス4として、文字通り「スケールインを無効にする」べきだと書かれています。さらに、”スケールインを無効にした状態から始めてもよく、後で必要に応じていつでも手動でスケールインできる “と書かれています。
２．1つの指標だけでスケールさせる。 現実には、メモリ、CPU、ネットワークのいずれかを圧迫する可能性があります。しかし、ElastiCacheのベストプラクティスでは、複数のオートスケーリングポリシーを適用しないことを推奨しています。
３．一様分布の場合のみ使用する。これは重要な注意点です。ホットシャードがあるワークフローでは、フリート内のすべてのシャードを垂直方向にスケールしなければなりません（あるいは、すべてのシャードにレプリカを追加しなければならない）。これは、特にフリート内のシャードの数が増えるにつれて、信じられないほど非効率になる可能性があります。
４．緩やかなスパイクに最適。 スケジュールされたスケーリングポリシーを使用しない限り、ElastiCache Redisクラスタのスケーリングには10分以上かかることを認識しておくことが重要です。場合によっては、クラスタがスケールアップするまでにスパイクがなくなってしまうかもしれません。
自動スケーリングに価値はあるのか？
ElastiCache Redisのオートスケーリングは車のクルーズコントロールのようなものです。登場した当初は非常に便利で、印象的でした。インスタンスタイプ、インスタンス数、シャード対レプリカ、メモリ対CPU対ネットワークの圧力を認識しながらキャパシティを管理するのは、今日のサーバーレスファーストの世界ではあまりにも面倒です。開発者は、ここで細かいことに気を取られる必要はありません。一般的に、前例のない規模になったときというのは、ビジネスやアプリが大きな成功を収め、最も大きく目に見える瞬間が訪れたときです。自動スケーリングやキャパシティ・プランニングが不十分だった理由を知る時ではありません。チームは、このような人目につきやすい瞬間に障害の余波を引き受ける必要はなく、障害に気を取られるのではなく、エンドユーザーに価値を提供することに全力を注ぐべきです。
Momentoは自動操縦のようなものです。Momentoで容量管理をする必要はありません。ホットシャード？ホットキー？Momentoは自動的に最もホットなデータのコピーを作成し、需要が急増したときにクラスタを緩和します。同様に、Momentoは手動でテストすることなく、数百万TPSまでスケールさせることができます。Momentoは毎日このようなテストを行っているので、私たちがそれを処理できることを知っています。
ElastiCache Redisの “自動スケーリング “からアップグレードして、キャッシュを真の自動操縦にする準備はできましたか？今すぐMomento Cacheをお試しください。
Share
EN 
JP