Модуль 9.5: Просунуті сервіси кешування (ElastiCache / Memorystore)
Складність: [COMPLEX] | Час на виконання: 2 год | Передумови: Модуль 9.1 (Бази даних), основи Redis
Чому цей модуль важливий
Розділ «Чому цей модуль важливий»У листопаді 2023 року e-commerce платформа зазнала повного краху під час флеш-розпродажу. Трафік злетів із 3 000 до 45 000 запитів на секунду. База даних SQL досягла свого ліміту в 15 000 з’єднань і перестала відповідати. Автомасшабувальник додавав нові поди, але кожен новий под намагався відкрити ще більше з’єднань із базою, роблячи ситуацію катастрофічною. Сайт не працював 28 хвилин — у самий пік продажів. Збитки оцінили у $2.3 мільйона.
У команди був кластер Redis, але це був самостійно керований StatefulSet без належного моніторингу. Тільки під час постмортему виявилося, що за 20 хвилин до розпродажу Redis тихо видалив 60% кешу через переповнення пам’яті (memory limit). База даних отримала прямий удар у 45 000 запитів, бо кеш був фактично порожнім.
Вони перейшли на керований Google Memorystore for Redis із правильно налаштованими лімітами та алертингом. Наступний розпродаж витримав 62 000 запитів на секунду, а база даних бачила лише 800 запитів — ефективність кешу склала 98%. Кешування — це не опція для продакшну. Це різниця між базою даних, яка є “пляшковим горлом”, і базою, яка є надійним тилом.
Redis vs Memcached: Що обрати?
Розділ «Redis vs Memcached: Що обрати?»| Фактор | Redis | Memcached |
|---|---|---|
| Структури даних | Хеші, списки, множини, гео-дані | Тільки “ключ-значення” |
| Стійкість (Persistence) | Так (можна зберігати на диск) | Ні (тільки пам’ять) |
| Реплікація | Так (авто-failover) | Ні (кожен вузол сам по собі) |
| Best for | Складні кеші, сесії, черги | Простий “ключ-значення” кеш |
Для 90% задач у Kubernetes обирайте Redis. Він набагато потужніший і надійніший.
Стратегії кешування
Розділ «Стратегії кешування»1. Cache-Aside (Lazy Loading) — Найпопулярніша
Розділ «1. Cache-Aside (Lazy Loading) — Найпопулярніша»Програма спочатку питає кеш. Якщо там порожньо (miss) — іде в базу, бере дані і записує їх у кеш.
- Плюс: Кешується тільки те, що реально просять юзери.
- Мінус: Перший запит завжди повільний.
2. Write-Through
Розділ «2. Write-Through»Програма пише дані одночасно і в базу, і в кеш.
- Плюс: Дані в кеші завжди свіжі.
- Мінус: Запис стає повільнішим.
3. Write-Behind (Write-Back)
Розділ «3. Write-Behind (Write-Back)»Програма пише в кеш і миттєво відповідає успіхом. У базу дані записуються асинхронно через деякий час.
- Плюс: Надшвидкий запис.
- Мінус: Якщо кеш “впаде” до запису в базу — дані будуть втрачені.
Cache Stampede: Як не “вбити” базу
Розділ «Cache Stampede: Як не “вбити” базу»Cache Stampede (тупіт стада) стається, коли дуже популярний ключ у кеші зникає за таймаутом. Сотні подів одночасно бачать “порожньо” і всі разом кидаються в базу, щоб її запитати.
Як боротися:
- Probabilistic Early Expiration: оновлювати кеш трохи раніше, ніж він закінчиться, з певною імовірністю.
- Distributed Lock: тільки один под іде в базу оновлювати кеш, решта — чекають.
- Background Warmup: фоновий процес (CronJob), який постійно оновлює популярні ключі, не чекаючи їх зникнення.
Типові помилки
Розділ «Типові помилки»| Помилка | Чому це стається | Як виправити |
|---|---|---|
| Кеш без TTL (часу життя) | “Ми самі видалимо, коли треба” | Завжди ставте таймаут (TTL). Це ваш запобіжник від вичерпання пам’яті |
| Redis для всього на світі | Один кластер для кешу та черг | Розділяйте: кеш можна очистити (flush), черги — ні. Використовуйте різні інстанси |
| default Max-Memory policy | Redis видає помилку, коли повний | Ставте allkeys-lru — Redis сам видалятиме найстаріші дані, щоб звільнити місце новим |
| Нове з’єднання на кожен запит | Стара звичка з PHP/Python | Використовуйте Connection Pooling у ваших додатках |
Тест
Розділ «Тест»1. Що таке "Hit Rate" і який показник вважається хорошим для продакшну?
Hit Rate — це відсоток запитів, на які кеш відповів успішно. Для продуктових систем хорошим показником є 80-95%. Якщо він нижчий за 50% — ваш кеш майже не приносить користі і лише додає затримки.
2. Чому важливо використовувати 'allkeys-lru' політику для кешу?
Тому що пам’ять коштує дорого і вона обмежена. Коли Redis заповниться, політика LRU (Least Recently Used) автоматично видалить дані, якими давно не користувалися, звільнивши місце для свіжих запитів. Без цього ваші додатки почнуть отримувати помилки запису.
Практична вправа: Оптимізація кешу
Розділ «Практична вправа: Оптимізація кешу»- Розгорніть інстанс Redis у вашій хмарі.
- Підключіть под до Redis і перевірте швидкість
SET/GET. - Налаштуйте TTL 60 секунд для всіх записів.
- Створіть дашборд у Cloud Monitoring, який показує:
- Кількість з’єднань (Connected Clients).
- Використання пам’яті (Memory Usage).
- Cache Hit Ratio.
Наступний модуль
Розділ «Наступний модуль»Переходьте до Модуля 9.6: Пошукові та аналітичні рушії — ви навчитеся інтегрувати OpenSearch та Elasticsearch для швидкого пошуку по логах та великих масивах даних вашого кластера.