Привет, хотел бы задать несколько вопросов. Я работаю с GCP. Это

не очень специфически по GCP, более с точки зрения архитектуры.

1. Это нормальная практика держать Redis в кубернетисе вместо того, чтобы использовать dedicated сервис, который предоставляет клауд?
2. Можно ли SQL Read реплики как-то автоскейлить в зависимости от нагрузки и поступают ли так?
3. Сейчас у нас SPA фронтенд сохраняется просто как статика в бакете. Поэтому когда запрос идет на несуществующую страницу (about, например, она отрисовывается SPA), то возвращается index.html со статусом 404. Поэтому также порекомендовали вынести это в кубернетис. Также, норм ли это практика?

Спасибо.

> Это нормальная практика держать Redis Смотря что считать нормой. Если по-сорокински — то да, конечно. А так — держать хоть какой редис — это невменяемая практика. И неважно, предоставляет его клауд или нет. (Ну, правда неважно. Вопрос пользоваться ли клаудом — это вопрос удобств и цэны, притом и то и другое вполне можэт быть не в пользу клауда). >Можно ли SQL Read реплики как-то автоскейлить Не запрещено, в принцыпе... Но обычно развернуть уснувшый датасет — это приличное время. Получится ли делать это для отработки пиков нагрузки? Это всё-таки не stateless сервис... Хотя, конечно, можно многое придумать. Снапшоты других read реплик, например. Если хранилка хорошо с таким работает — почему бы и нет. > Поэтому когда запрос идет на несуществующую страницу (about, например, она отрисовывается SPA), то возвращается index.html со статусом 404. Тут вообще не понял. SPA меняет URL на тот, который этой SPA не отрабатывается? Простите, а нафига так делать? Или что вообще? И да, с точностью до того, что я не понял проблемы — это всё строго ортогонально куберу.

2) в том, что нагрузка скачем. Может быть спайк какой-то и чтобы его хендлить

Про фронт — в SPA JS отрисовывает страницу по пути в URL. То есть если путь — /about, то файла about.html не существует, поэтому возвращается index.html и уже JS там отрисовывает

Что именно кешировать?

То есть всё нормально — при запросе /about нджынкс выдаёт SPA, которая со всем корректно разбирается. Тогда я не понял — какую проблему вы пытаетесь решыть (переездом в кубер или куда-то ещё).

Сейчас просто нет вообще nginx. Статика лежит в бакете и на бакете есть конфигурация: 1. 404 page -> index.html. Тут мы также ставим index.html, чтобы он возвращался при запросе файла about.html, например. Таким образом 404 статус код возвращается, а это не очень. 2. index page -> index.html

Я вообще хотел написать 3) про проьлему) Чего хочется от фронта то?

Я понял, у вас код 404. Да, это криво до ужаса. Переделывайте. Нет, кубер тут ни при чём. Но если тот, кто хочет переделывать — просит кубер — ну, дайте ему. Вы-то сами всё равно не умеете.

На что влияет код 404? Если это действительно важно, поставь перед бакетом лб с редиректом

На поисковых ботов, репутацию сайта и позицию в выдаче. SEO-приколы

Для этого всего надо делать нормальный robots.txt и публиковать валидные ссылки.

Не все SEO умные

Ну это да, иногда проще починить сайт, если по честному 404 тут технически неправильно. https://issuetracker.google.com/issues/151212194

А кто клиенту статику отдает, если nginx'a нет?

GCP, видимо https://cloud.google.com/storage/docs/access-control/making-data-public