Momento Japan ElastiCache Redisのすべての利点を得る。そしてそれだけではありません。
ElastiCache RedisはRedisエコシステムの隠れたヒーローです。Redisの成長と普及に貢献してきました。しかし、Redisは一見古くからあるような話です。Redisは、10年以上にわたって幅広い機能を含むように成長した、非常に評価の高いオープンソースソフトウェアプロジェクトであり、非常に正当な理由のある活発な開発者コミュニティを持っています。MomentoチームのRedis愛については、Momento vs Redisのブログで詳しく紹介しています。
皮肉なことに、ElastiCache Redisやその他のマネージドRedisサービスはクラウドネイティブではありません
そのためには、真にクラウドネイティブなソリューションが必要です。Momentoはまさにそれを実現しました：
・私たちは、このようなデータ要件に対する開発者インタフェースを完全に再構築し、クリーンスレートで実装することで、より迅速なイノベーションを実現できると信じています。
・真にサーバーレスなアプローチ（分散アーキテクチャ）から始めることで、よりスムーズな運用結果（可用性、スケーラビリティ、テールでの一貫したレイテンシ）が得られると信じています。すべての開発者がElastiCache Redisの操作の専門家であるべき（あるいはなりたい）わけではなく、難しい方法を学ぶことはビジネスにとって苦痛であり、コストがかかります。
・私たちは、よりシンプルで合理的な方法で、データ関連の問題を解決する機会が他にもたくさんあると考えています。その例として、当社のMomento Topics製品を見てください。低レベルのコンポーネントやコマンドについて学んだり、目的に合わせて慎重に組み合わせたりする必要はありません。
ElastiCache Redisや他のマネージドRedisサービスがなぜクラウド・ネイティブでないのか、そしてMomento Cacheがどのようにレベルアップしているのか、その理由を読み解きましょう。
ElastiCache Redisがクラウドネイティブではない8つの理由
1.ノード、クラスター、ネットワークの複雑さと高レベル・リソースの抽象化
DynamoDBやS3のようなサービスのドキュメントを見てみると、ノード、クラスタ、サブネット、AZなどについての言及はありません。あるのはエンドポイントと、「テーブル」や「バケット」といったリソースの高レベルな抽象化だけです。Momentoも同じ真にサーバーレスなアプローチに従っており、単純に “CreateCache() “を呼び出すことができます。ベンダーによっては、抽象化された名称を使うことでサーバーレスを提供しているふりをしようとしているので、注意深く見てください。価格やメンテナンス／セキュリティ情報などの詳細をさらに掘り下げると、ノードに相当するもの、AZ周辺のネットワーク選択などが見つかるかもしれません。この区別は重要で、もしこのようなことが見られるなら、マネージドサービスのアーキテクチャが真の分散型ではないことを示唆しており、以下の要因で説明するように、スケール、運用オーバーヘッド、コストに関する制約がより多く発生することになります。ベストプラクティスは、分離されたリソースを運用することです。「バケット」であれば簡単で問題ありませんが、「クラスタ」であれば、最小限のバイイン、メンテナンスウィンドウ、スケーリングの痛み（すべてクラスタ単位で）にサインアップすることになるでしょう。アーキテクチャが大きくなり、マイクロサービス指向になればなるほど、労力、痛み、リスクは倍増します。各サービスは、多くの個別の環境（開発環境、統合環境、ステージング環境、プロダクション環境）に存在する可能性が高いことを忘れないでください。
2.メンテナンスウィンドウ
APIを抽象化するルーティング・レイヤーが提供する分散環境では、追加のAPIやパラメータを公開し、SDKにサポートを追加することで、製品の改良が展開されます。DynamoDB、S3、Momento Cacheがそうです。マイナーバージョンもメジャーバージョンもありません。メンテナンス・ウィンドウがないため、アップデートは認識されず、顧客エクスペリエンスに影響を与えません。
マネージドRedisの代替について：純粋に支出を減らすためにキャッシュを使用しているのであれば、メンテナンス中に信頼できるソースにフォールバックすることは許容されるかもしれませんが、トラフィックが少ない時間帯にこれを行うことを計画する必要があります。一方、ElastiCache Redisを高度なデータ構造のプライマリストアとして使用している場合は、より多くのことを計画する必要があります。マネージドRedis製品によっては、メンテナンス・ウィンドウがそのように明確に記述されている場合もあれば、「短時間の中断と緊急アップグレードの可能性」というような微妙な表現になっている場合もあります。
3.最小限のバイイン（スケール・ツー・ゼロではない）とオーバープロビジョニング
ほとんどのマネージドRedisオプションでは、リクエストに対する支払いのみを可能にする価格モデルは提供されていません。これは、最小の粒度（通常は時間単位）でプロビジョニングされたレベルの能力を維持することを意味します。多くの場合、これはノードごとになり、単一ノードが提供できる以上の可用性を求める場合は、複数のAZで複数のノードを実行することを考える必要があります。一般的に、この構成は1ヶ月間ずっと稼働させることになるため、最低限必要なのは1ヶ月を通して3つのノードを稼働させるコストでしょう。ノードは小さくても構いませんが、合理的に利用可能なRedisストア（サービスごと）の最低額は、おそらく35ドル/月以上でしょう。コストを削減するために、多くのオペレータは低環境（開発／テスト）において、レプリケーションなしの単一ノードの運用といったトレードオフを行うようになります。インメモリーストアに弾力性がなく、ノードがリブートしたらどうなるでしょうか？その通りです、テスト作業をやり直すことになります。
このような心配をする必要がなくなったらいいと思いませんか？Momento Cacheを使えば、どのキャッシュでも同じ高可用性とパフォーマンスを得ることができます。5リクエスト/秒から500万リクエスト/秒に増強する必要がありますか？問題ありません。中断もなく、運用の手間もかかりません。
4.セキュリティとアクセス・コントロールの優先順位の低さ
意見： TLSは（ElastiCache Redisのように）オプションにすべきではありません。意図的あるいは偶発的な設定で、データとアクセス認証情報を平文で転送する余地はないはずです。Momento Cacheは、ネットワーク上のすべてのデータを暗号化し、ストレージ（メモリを含む）内のデータも暗号化します。
Redisでは、すべてのデータと操作が同じ認可を受けます。Momentoは、期限切れのAPI認証キーと短命のクライアントアクセストークンを使って、きめ細かな認証（スーパーユーザー、読み取り専用、書き込み専用、キーごと）を提供します。これをRedis（プロバイダを問わず）と比較すると、Redisのデータを複雑なネットワーク構成で隠そうとする理由がたくさんあることがわかるでしょう。Redisへのアクセスはすべて、あなたが構築し管理する必要のあるアプリケーション・コードによってゲートされるべきです。
5.異なる作業負荷特性を緊密に結合するスケールの選択
前述した、最小限の購入とノード／クラスタの複雑さというペインポイントに加え、マネージドRedisでは一般的に、CPU、ストレージ容量（メモリサイズ）、ネットワーク帯域幅またはリクエストレートの特定の比率を選択する（そして本番でコミットする）必要があります。これには、ノードのタイプやサイズの範囲など、さまざまなオプションがあります。しかし、もし「ティア」がCPU：メモリ：スループットの比率を制限するのであれば、それは別の名前のノードに過ぎないのではないかと自問してみてください。ワークロードは時間とともに性質が変化し、季節的な変動もしばしばあります（毎日の繁忙期と低調期、毎月の一括処理、毎年のピークイベント）。各タイプのデータ操作には、CPUの面で特別な要求があり、その重みは高度なデータ構造のサイズによって異なります。いつでも、これらのリソース特性の1つまたは複数が、他のリソースよりもはるかに効率的に利用されていない可能性が高いことがお分かりいただけるでしょう。真のサーバーレスであるMomento Cacheは、このバランスの変化を気にすることを求めません。
6.ホットキーとホットシャード
ほとんどのシャーデッドストア（マネージドRedisを含む）では、予期せぬトラフィックの急増や集中があると、単一のキー（または同じシャード内の少数のキー）がバックエンドノードを圧倒する可能性があります。これにより、配置されたデータが「ブラウンアウト」する可能性があります。Momentoの分散アーキテクチャでは、極めてホットなキーのために2層目のキャッシュをタイムリーに追加し、このトラフィックからプライマリ・キャッシュを保護し、さらに優れたパフォーマンスでホットなキーにサービスを提供し続けることで、嵐を乗り切ることができます。
7.影響リスクを考慮したノードサイズ単位でのスケーリング
ノードとクラスタによって定義されるマネージドRedis製品は、スケールアップやスケールダウンが複雑です。読み込み負荷の変化に対応するために、レプリカノードを追加したり削除したりすることができますが、最小の増分は1ノードのサイズ（とコスト）です。レプリカを追加すると、リーダーはレプリケーションの作業を処理しなければならないため、CPU負荷が増加します。ノードタイプの垂直スケーリングも可能で、必要に応じてクラスタのノードタイプを変更することができます。残念ながら、これらの変更はいずれも、ユーザーが認識するアプリケーションのパフォーマンスに影響を与えることなく行われることはないでしょう。Redisクライアントはしばしば再接続を余儀なくされ、このようなスケーリング中にミスが増加する可能性があります。シャーディング（「クラスタ・モード」）のサポートがあるかもしれません。しかし、スケーリングやシャードの追加/削除を行う際に、何らかの影響が生じる可能性があります。Momento Cacheの顧客は、このようなことを考える必要はありません。バックエンドですべてのスケーリングを自動的に処理し、非常にスムーズに変更を処理します。
スケーリングに苦労した結果、Momento Cacheへの移行時に私たちが評価するマネージドRedisの実装のほとんどは、大量にオーバープロビジョニングされています。オペレータは、負荷が低いときにスケールアウトしたがらず、未使用のキャパシティを大きくバッファして、成長や予期せぬスパイクをカバーする傾向があります。そして、影響とコストの可能性があるため、積極的なスケールアウトをためらってしまいます。残念なことに、スケールアウトは、運用に継続的な影響がある場合に、緊急に実施しなければならないことがあまりにも多いのです。
8.BYO 認証と RESTful データ・インターフェース
セキュリティに関して前述したように、認証と認可のサポートが弱いため、Redisストアを隔離されたネットワークに構築し、運用する必要があります – そして、Redisへのアクセスを管理するアプリケーションレイヤーを構築する必要があります。アプリケーションが複雑であれば、これはおそらく漸進的な取り組みとなるでしょう。しかし、単にキーによるPOSTやGETデータへのHTTPSアクセスを提供するだけであればどうでしょうか。これは多くのアーキテクチャにとって重要なパターンです。Momento Cache は、キーによるデータへの HTTPS での直接的な RESTful リクエストを提供します。キャッシュデータをより広範なアプリケーションアーキテクチャに直接統合し、安全に行うことができます。
結論
Momento Cacheを「サーバーレスのElasticache Redis」と考えるのは簡単でしょう。私たちは、この言葉を褒め言葉のように捉えています。私たちは本当にサーバーレスなのです（単に管理されているだけでなく、用語や価格構造のショートカットを使ったマーケティングの遊びとしてこの言葉を使用しているだけではありません）。そして、私たちが行っていることの一部は、Redisプロジェクトが焦点を当ててきたデータの課題の多くを解決するために、キャッシュや高度なデータ構造をサポートしています。しかし、Momentoのサービスは、これ以上のことを目指しています。運用上の痛みを解決し、迅速、安全、信頼性の高いビルドをよりシンプルにします。私たちのデータソリューションのエコシステムが成長するにつれ、特定の開発者のニーズを箱から出してすぐに完璧に解決できるように作られた製品が増えていくでしょう。特定のパターンをカバーするために、いくつかのデータ構造と多くのコマンドを手渡され、それらをうまく組み合わせる必要があるのとはまったく違います。
Momento Cache、Momento Topics、Momento Vector Index – 他に何を解決できますか？今すぐMomentoを始めましょう。