Broadcom і Redis опублікували спільну reference architecture для запуску enterprise-grade Redis Software на VMware Cloud Foundation 9.1 з vSphere Kubernetes Service. Це конкретний blueprint з виміряними цифрами, сайзингом і прикладами декларативного деплою, а не черговий маркетинговий анонс про «партнерство».

Чому це питання взагалі болить

Якщо ти колись пробував запустити stateful-сервіс типу Redis на Kubernetes, ти знаєш ці питання: скільки ресурсів виділити воркерам, який мережевий шлях обрати, як налаштувати persistence, що станеться при падінні пода під навантаженням. На голому Kubernetes відповіді доводиться добувати методом проб і помилок, часто вже в проді.

Для команд, що будують fraud detection, streaming analytics, AI-агентів чи feature stores, ціна помилки тут висока – мова про швидкий доступ до даних під конкурентним навантаженням, де затримка в кілька мілісекунд може зламати SLA. Якщо потрібен фундамент перед тим, як узагалі братись за Kubernetes-варіант, корисно спершу розібратись, коли кеш реально потрібен, а коли шкодить.

Що саме опублікували

Broadcom і Redis валідували конкретні деплойменти Redis Software на VCF з VKS на залізі Dell PowerEdge R770 з процесорами Intel Xeon 6740P. Тестування memtier_benchmark проводилось з увімкненим TLS, а трафік ішов через фізичну мережу 25 GbE між окремими групами хостів для Redis і клієнтів – тобто цифри відображають реальний мережевий шлях, а не локальний loopback.

Результати охоплюють кілька сценаріїв:

  • Latency при масштабі. На трьохнодовому кластері з шістьма primary shard combined P99 latency для GET і SET лишався в межах sub-millisecond при pipeline depth 1–2.
  • Пропускна здатність. П’ятинодова конфігурація з шістьма client worker VM видала приблизно 2.0M ops/s при combined P99 latency 1.0–1.5 мс.
  • Online scale-out. База з AOF persistence виросла з п’яти до десяти primary shard під живим трафіком за 56 секунд, і клієнт не зафіксував жодної помилки з’єднання.
  • Resilience. У тестах з видаленням подів і drain-and-return воркер-нод Kubernetes відновив Redis-поди до стану Ready, а клієнтські навантаження завершились без зафіксованих помилок з’єднань.
  • Multi-tenant. Дві бази на спільному п’ятинодовому кластері розділили пропускну здатність приблизно порівну з порівнянною латентністю при симетричному навантаженні.

Керується все це через декларативні Kubernetes-ресурси RedisEnterpriseCluster (REC) і RedisEnterpriseDatabase (REDB), які надає Redis Enterprise operator. Платформні команди отримують провіжинінг і масштабування кластерів та баз через звичні Kubernetes та GitOps воркфлоу, а не через ручні команди на кожній ноді.

Практичний шар: чекліст перед тим, як братись за Redis на Kubernetes

Конкретну схему CRD для REC і REDB джерело не наводить, тож замість вигаданого YAML – чекліст питань, які варто пройти з командою перед тим, як переносити Redis на Kubernetes-платформу (неважливо, VCF це чи інший дистрибутив):

  1. Мережа. Де фізично проходить трафік між Redis-подами і клієнтами – через overlay-мережу Kubernetes чи через окремий фізичний сегмент? Від цього залежить реальна latency, а не та, що в синтетичних тестах на localhost.
  2. Persistence. Який режим обираєш – AOF, RDB snapshots чи обидва? Який storage backend стоїть під подами і як він поводиться при scale-out операціях?
  3. Шардинг. Скільки primary shard закладаєш на старті і як виглядає процедура online-розширення без простою для твого навантаження?
  4. Відмовостійкість. Що відбувається з клієнтськими з’єднаннями при видаленні пода чи drain нод – чи є retry-логіка на боці клієнта, чи ти покладаєшся виключно на платформу?
  5. Multi-tenancy. Якщо кілька баз живуть на одному кластері, як розподіляється пропускна здатність під асиметричним навантаженням – не лише під симетричним тестовим сценарієм?

Якщо твоя команда вже думає про retry-поведінку клієнтів при збоях з’єднання, варто паралельно переглянути idempotency в API-шарі – ці дві речі завжди йдуть у парі, коли мова про надійність під навантаженням.

Чесні trade-offs

Reference architecture – це виміряний baseline на конкретному залізі й конкретній конфігурації мережі, а не гарантія для будь-якого інфраструктурного стеку. Цифри з Dell PowerEdge R770 на 25 GbE мережі не переносяться автоматично на твій кластер з іншими процесорами, іншою мережею чи іншим типом сховища.

Kubernetes-оператор знімає частину ручної роботи з провіжинінгу, але додає шар абстракції, який треба розуміти: дебажити проблему через REC/REDB ресурси – це інший навик, ніж дебажити Redis напряму через CLI. Якщо команда ще не має досвіду з Kubernetes-операторами взагалі, крива навчання буде стрімкішою, ніж здається з маркетингового слайду.

Online scale-out за 56 секунд – це вимірювання для конкретного переходу з п’яти до десяти shard під конкретним тестовим навантаженням. Поведінка при більших стрибках шардів чи при іншому профілі трафіку (наприклад, важкі write-heavy операції замість збалансованого GET/SET) може відрізнятись, і джерело про такі сценарії не говорить.

Коли це брати

Ця reference architecture має сенс, якщо ти вже на VMware Cloud Foundation або плануєш туди мігрувати, і тобі потрібен Redis як production-grade real-time data layer – не просто кеш для сесій, а база під fraud detection, streaming analytics чи feature store з вимогами до latency і відмовостійкості.

Якщо в тебе невеликий проєкт з помірним навантаженням і Redis потрібен переважно для кешування, витрати на Kubernetes-оператор і VCF-інфраструктуру навряд чи окупляться – простіший managed-варіант або звичайний self-hosted instance закриє задачу дешевше й швидше.

Підсумок

Спільна reference architecture дає те, чого раніше бракувало: виміряні цифри sizing і resilience для Redis Software на Kubernetes, а не лише теоретичні рекомендації. Але перед тим як копіювати цифри собі в капасіті-планування, прожени власний чекліст по мережі, persistence і поведінці клієнтів при збоях – залізо і мережа в тебе майже напевно інші.