マイクロサービスごとに異なるRedisインスタンス？
nポッドでKubernetesを実行していて、それぞれが個別のマイクロサービスであるとします。現在、これらのサービスの一部にはキャッシングレイヤーが必要です。考慮に入れると：
- redisが数億のキーに対してテストされ、パフォーマンスが優れていたという事実
keysをnamespacesでタグ付けできるという事実（この場合はマイクロサービス名になります）- データの有効期限が比較的短いという事実（特定の瞬間に1000万以上のキーの数に達することはほとんどありません）
- データがフェッチされる単一の（レプリケートされた）データベースがあるという事実。 PS：これは事後対応の原則に反することを知っています。 （これを追加するように通知してくれた Ewan に感謝）
それぞれが単一のサービスに対応する個別のRedisポッドを起動するか、またはスレーブコンテナー用の個別のポッドを備えた単一のRedisマスターポッドがより良いアーキテクチャの選択になるでしょうか？個別のRedisポッドを持つことは、ある種のアンチパターンでしょうか？
ジレンマを視覚化するのに役立つ図：
キャッシュが orthogonal であるとアーキテクチャ（そしてそれがそうである）と見なす場合、最初の画像は問題ありません。
PODごとに1つのセキュリティサービス、1つのAPIゲートウェイ、1つのメッセージブローカー、または1つのサービスロケーターをデプロイしないのと同じ理由で、PODごとに1つのキャッシュ（レプリカセット内）をデプロイする必要はありません。1
時期尚早の最適化に注意してください
キャッシュは、特定のパフォーマンスの問題を解決するためのものです。主に高価な IPC または重い計算から導出されたもの。これらの問題の証拠がなければ、「MSの神」のためにPODごとに（レプリカセットで）キャッシュを展開することは、（とりわけ）時期尚早な最適化です。
Cloudはあなたを殺すことができます。
私たちの目標がアーキテクチャをクラウドに展開することである場合、賢明な動きは小規模から始めることです。保守的になる。逆にアーキテクチャのサイズが大きくなりすぎているため、必要に応じてスケールアップします。特大のアーキテクチャは、文字通り、すぐにROIを浪費するプロジェクトを終了させる可能性があるため、クラウドでは潜在的に危険です。 2
問題に応じてソリューションのサイズを決定します
最初に負荷テストを実行し、パフォーマンス問題の証拠のメトリックと断片を取得し、キャッシュがこれらの問題の解決策であるかどうかを確認します。次に、問題に応じてソリューションのサイズを決定します。サービスが専用キャッシュを必要とすることが証明されている場合にのみ、それらを展開します。あなたがそれをする時までに、あなたはそれを客観的な測定基準を支持し、請求書を管理下に維持します。
一度言われた
解決策が解決する問題よりも複雑または高価な場合、それは収益性の高い解決策ではありません。 それも解決策ではありません！
強調鉱山
複雑さを抑える
MSアーキテクチャ自体は複雑であり、私たちがほとんど理解していない教義や信念のために、さらに複雑にする必要はありません。システムの全体的な複雑さを可能な限り低くしますが、低くはしません。言い換えれば、それを単純に保ちますが、アーキテクチャの目的（展開とSDLCの完全な自由）を無効にするという犠牲を払うことはありません。
1：MSアーキテクチャは、多くの小さなシステムではなく、ビジネスの「機能」によって構成された単一のシステムであり、すべてを連携させてより優れたものにします。
2：クラウドは決して安価ではありません。特に、RAMの購入に関しては
個別のサービスは、個別のREDISインスタンスを使用する必要があります。
理由：REDISの停止を引き起こす別のサービスによるREDISの不適切な使用は、アプリケーションに影響を与えません。
サービス間通信に使用されるキューのみを共有する必要があります。
あるサービスが別のサービスの名前空間に書き込むことを防止できますか？そうでない場合、1つのRedisインスタンスを共有すると、サービスの分離が壊れます。そして間もなく、Redisはデータを同期する方法として使用されます。あるサービスが別のサービスのデータを誤って操作するリスクは言うまでもありません。
Redisを介して個別の名前空間を適用できる場合、つまり、ほとんどのSQLデータベースサーバーで可能であるように、独自の名前空間にのみアクセスできる異なるアクセス資格情報を適用できる場合、すべてのサービスに1つの冗長性ボトルネックがあることを受け入れれば、共有はうまくいきます。