Как стать автором
Обновить

Инфраструктура еды: как мы саппортим «Тануки»

Время на прочтение6 мин
Количество просмотров6.2K
Всего голосов 28: ↑24 и ↓4+20
Комментарии10

Комментарии 10

  • Малдер, сколько на этом диске данных?
  • примерно миллион данных, Скалли
Оно было основано на Hashicorp vault (в качестве бэкенда для него выступил Consul)

Разве Consul не умеет хранить переменные сам по себе? Vault вроде бы нужен только для их шифрования?

Смешались в кучу кони, люди, И залпы тысячи орудий…
Тут было важно организовать всё так, чтобы они корректно регистрировались в протоколе обнаружения сервисов, который, в свою очередь, управлял работой ДНС.


А как тут организовано всё? Через DNS Interface консула?
Надежность системы: проблемы наблюдались в июле 2019-го — заказы не оформлялись в течении часа. Но это было до глобального переезда. В дальнейшем крупных инцидентов не наблюдалось.

Не сочтите за попытку дискредитировать, но просто вот 14 февраля 2020 года мы с женой решили провести романтический вечер, тогда еще COVID-19 был далеко и домашний вечер со свечами казался чем-то очень необычным, но как всегда помешали «тупые проблемы», пришлось даже написать в маркетинг Тануки. Правда ответа так и не последовало…
image
Расскажите что за проблемы были в этот день?


Забавно когда коммент, который явно несет в себе дискредитацию начинается с фразы «не сочтите за попытку дискредитировать. Не понимаю, зачем это делать :)

Я хочу ответить на него только этим сообщением, потому что любой другой диалог будет развитием троллинга, который технически начинается с фразы „А я вот видел!“.

К сожалению, никак не упомянут колл-центр. Он в обработке заказов участия не принимает?
Не знаю как сейчас, но ранее у них все заказы обрабатывались живыми людьми.
Т.е. можно построить сайт, который не "падает", но если колл-центр "умер", то большая часть пришедших заказов обработана не будет.

Отличный кейс! Ещё кейсы в студию!

Решения по первому направлению были, прежде всего, связаны со стабилизацией работы кластера MySQL. Отказываться от мастер-мастер репликации не хотелось, но и продолжать работать с плавающим IP было невозможно. Периодически наблюдались нарушения сетевой связанности, что приводило к нарушениям работы кластера.


Если использовался keepalived, то сервера должны были находиться в одной сети.
Наблюдались нарушения сетевой связанности в сети хостера?

Прежде всего, мы решили отказаться от плавающего IP в пользу прокси-сервера, где между мастерами будет контролируемо переключаться апстрим, так как в качестве прокси для MySQL мы задействовали nginx. Второй шаг — выделение двух отдельных серверов под слейвы. Работа с ними была также организована через прокси-сервер. И с момента реорганизации мы забыли о проблемах, связанных с работой с БД.


Т.е. один прокси без резервирования?
Довольно поверхностно описаны изменения. Хотелось бы больше технических подробностей (например о резервировании балансера, если таковое имеется), мы же на хабре.
И про 550 RPS не совсем понятно — это же не так много
Зарегистрируйтесь на Хабре, чтобы оставить комментарий