В том, что непонятен смысл облака, с ограничениями.
Так их нет, ограничений :). Вы же видите разницу между "заказать железки, дождаться их поставки, настройки, сетапа ОС, настройки ОС, подключить в кластер" и "изменить два параметра в yaml-манифесте и через 5-10 минут получить +20 виртуалок (уже подключенных в кластер и принимающих pod'ы и трафик)"? Так вот это самая поверхностная разница и смысл.
Если бы задачу выполнял рядовой программист - да, согласен, у рядового программиста нет такого опыта. Но вы же специализируетесь на поддержке.
Везде хватает своих вызовов. Иначе программист через 10 лет работы не допускал бы уже ошибок и весь его софт работал бы без багов, автослесарь через 200 машин мог бы починить любую проблему с закрытыми глазами и так далее, и развиваться бы им было некуда, верно?
В общем, как понимаю, не смотря на падения прода, вы считаете, что сделали все, что смогли, и ошибок не допустили?
Удивительно, я везде говорю и пишу о том, что "да, мы допустили немало ошибок, но мы их учитывали и делали все лучше и лучше с каждым разом, в конечном счете получив на текущий момент качественно новую инфраструктуру", поэтому совершенно не понимаю, каким образом вы сделали такой вывод :).
Не расскажете поподробнее - почему?У меня такая логика в голове не укладывается - ключевое мероприятие года, а руководству главное лишнюю копейку не переплатить.
К сожалению не расскажу, это бизнес история которая наверняка имеет свои причины, и мы не хотели бы выдавать какие-то суждения по этому поводу. У нас была вполне конкретная задача и условия.
Плюс, на сколько я знаком (а знаком поверхностно) с облаками - их основная фишка как раз в возможности иметь неограниченные ресурсы, а платить только за то, сколько реально израсходовал.
Все так, а вопрос в чем? Мы можем неограниченно скейлиться (докупать ресурсы в автоматическом режиме), но за то, что сейчас запущено и работает - платить обязаны.
Практика показывает, что задачи всегда сложнее и больше, чем кажутся на первый взгляд. И на второй взгляд тоже. Возникает вопрос, а на сколько ваша команда была опытной, что она наступила на эти, классические, грабли?
Богатый опыт эксплуатации разных по размеру и сложности проектов показывает, что всегда найдется возможность для косяка (уж простите за слэнг) :). Тут же речь не о том, что "кто-то говорил надо больше - мы не послушали" или "мы чайники и не поняли, что надо иначе/больше/лучше", а исключительно в разрезе комплекса факторов в виде определенной ограниченности в ресурсах, сложности выстраивания нагрузочных тестов, невозможности быстро и просто определить, а сколько ресурсов потребуется для сайта, если посетителей будет в 2 раза больше, или в 5, или в 10. Об этом и было сказано в статье. С нашей стороны мы сделали best effort - подготовили такую инфру, которая в базе уже покрывает все эти кейсы, а дальше вопрос регулировки и подстройки для частных случаев.
Ваше сообщение более чем логично, но если даже масштабирование не спасает от ухода в 403 в пике, то что тогда спасает ? :)
403 - это все-таки про другое, вы наверное имели в виду 5** ошибки. Спасает конечно, разница между упасть на все время всплеска посещений против 5% таймаутов на 10% запросах, как пример :). Плюс вопрос в трудоемкости операций, запасе отказоустойчивости, гибкости и простоты изменения инфраструктуры, и многих других факторах. Я уж не говорю про запас ресурсов, которые без удобной автоматизации, наращивать достаточно некомфортно, особенно в условиях "пожара". Инфраструктура такого рода позволила нам избавиться от множества узких мест и перейти на качественно иной уровень. Что касается частных случаев ошибок на сайте - их надо разбираться отдельно и предметно, это в том числе позволит улучшить пользовательский сервис ;).
Вот именно из-за таких проблем и проводятся работы вроде упомянутых в статье. По факту - мы не утверждаем, что падений не было и не будет, падает кто угодно (даже google). Не падает только то, что вообще не работает. Самое главное в таких ситуациях - разобраться в причинах и научиться на ошибках, чтобы их не повторить. Ранее было много нюансов в работе проекта, площадок, приложения (часть этих нюансов мы описали в статье), и бОльшую часть из них мы итеративно устраняли совместно с разработчиками. Каждое следующее событие давало нам новый опыт и новый вызов. В статье - показательный пример такого события, которое помогло прийти инфраструктуре к новому витку развития, чтобы соответствовать текущим требованиям.Что касается битрикса - вы заблуждаетесь, он никогда (при нас по крайней мере) не использовался в качестве движка для сайта.
Получается, что вся связка стоила нам лишь добавления одного сервера стоимостью 60 евро и бесплатного трафика, который отдается с него, в текущих объемах. При этом есть еще двукратный запас по росту трафика до того момента, когда он может начать оплачиваться.
Для обучения, одна история неудачи стоит десяти историй «успеха»!
Это верно! :)
По-английски это называется «Failure Mode and Effects Analysis», например, вот очень хороший пост на тему.
Спасибо, изучим!
Обычно такие выводы остаются исключительно на бумаге (в секции «будущие шаги» пост-мортема, прямо как у вас), прямо как новогодние обещания. Полезно быть реалистом на этот счет :)
Ну, тут два момента, первый — мы стараемся все-таки избегать вот этих вот бумажных формализмов и если и пишем про «будущие шаги», то стараемся их делать выполнимыми и реальными и второе — лично я реалист, но с верой в лучшее, как минимум стремление к выполнению этого шага уже даёт существенный позитивный рывок ;)
Очень хотелось!
Но как всегда — на проде невозможно, кто же нам даст терзать прод в свою волю. А чтобы это воспроизвести не на проде — нужно поднимать идентичный тестовый стенд, на что конечно же нет ресурсов.
Вы же понимаете насколько это упрощенно и однобоко звучит? :)
К сожалению мир не делится на белый и черный. Есть моменты когда мы можем бороться, есть — когда нет. Есть моменты когда бизнес может идти на встречу, а есть — когда физически нет таких возможностей. Мы стараемся идти на встречу при любом раскладе дел.
И мы не спорим с этим! :)
Но и не мы разработчики той системы которую обслуживаем. А провести рефактор кода далеко не всегда возможно, и нам надо выкручиваться исходя из существующих вводных данных, а не того, чего хотелось бы в идеале.
К сожалению у нас нет адекватного решения для redis cluster в кубах, поэтому пока используется sentinel.
В случае с sentinel существует дополнительный сетевой хоп, т.к. приложение сначала идет в sentinel-proxy, после чего уже попадает в сам редис, конечно же это касается тех приложений, который не поддерживает нативную работу с sentinel.
В таком случае по идее проблем не должно быть, т.к. там ассинхронные операции и напрямую влиять на клиентские get'ы и mget'ы не должны.
На практике это удавалось проверить или допущение?
И если можно — уточните, что вкладываете в понятие «высокие нагрузки» в каких-то абсолютных показателях?
Ниже вот ответили, ставить istio с трейсером. Но по опыту, в 90% случаев, проблема в сети между нодами. В случае с тем же flannel, ломаться обычно просто нечему. Не говорю конечно о крайних случаях, когда что-то сложное — огромные нагрузки, огромные кластера, тысячи сервисов и так далее, но если это ваш кейс, совершенно непонятно как вы ещё живёте без чего-то вроде istio :)
Поддерживаемые протоколы есть в таблице, также обычно все кто поддерживает tcp в полной мере, имеют полноценную l4 балансировку.
Про http2 это упущение (там действительно есть нюансы, например не все ингрессы умеют проксировать http2, а только терминировать), которые к сожалению, скорее всего будут еще обнаруживаться, уж слишком большой объем обзора :(.
В том, что непонятен смысл облака, с ограничениями.Так их нет, ограничений :). Вы же видите разницу между "заказать железки, дождаться их поставки, настройки, сетапа ОС, настройки ОС, подключить в кластер" и "изменить два параметра в yaml-манифесте и через 5-10 минут получить +20 виртуалок (уже подключенных в кластер и принимающих pod'ы и трафик)"? Так вот это самая поверхностная разница и смысл.
Если бы задачу выполнял рядовой программист - да, согласен, у рядового программиста нет такого опыта. Но вы же специализируетесь на поддержке.
Везде хватает своих вызовов. Иначе программист через 10 лет работы не допускал бы уже ошибок и весь его софт работал бы без багов, автослесарь через 200 машин мог бы починить любую проблему с закрытыми глазами и так далее, и развиваться бы им было некуда, верно?
В общем, как понимаю, не смотря на падения прода, вы считаете, что сделали все, что смогли, и ошибок не допустили?
Удивительно, я везде говорю и пишу о том, что "да, мы допустили немало ошибок, но мы их учитывали и делали все лучше и лучше с каждым разом, в конечном счете получив на текущий момент качественно новую инфраструктуру", поэтому совершенно не понимаю, каким образом вы сделали такой вывод :).
Речь конечно про персональные данные.
Не расскажете поподробнее - почему?У меня такая логика в голове не укладывается - ключевое мероприятие года, а руководству главное лишнюю копейку не переплатить.К сожалению не расскажу, это бизнес история которая наверняка имеет свои причины, и мы не хотели бы выдавать какие-то суждения по этому поводу. У нас была вполне конкретная задача и условия.
Плюс, на сколько я знаком (а знаком поверхностно) с облаками - их основная фишка как раз в возможности иметь неограниченные ресурсы, а платить только за то, сколько реально израсходовал.Все так, а вопрос в чем? Мы можем неограниченно скейлиться (докупать ресурсы в автоматическом режиме), но за то, что сейчас запущено и работает - платить обязаны.
Практика показывает, что задачи всегда сложнее и больше, чем кажутся на первый взгляд. И на второй взгляд тоже. Возникает вопрос, а на сколько ваша команда была опытной, что она наступила на эти, классические, грабли?Богатый опыт эксплуатации разных по размеру и сложности проектов показывает, что всегда найдется возможность для косяка (уж простите за слэнг) :). Тут же речь не о том, что "кто-то говорил надо больше - мы не послушали" или "мы чайники и не поняли, что надо иначе/больше/лучше", а исключительно в разрезе комплекса факторов в виде определенной ограниченности в ресурсах, сложности выстраивания нагрузочных тестов, невозможности быстро и просто определить, а сколько ресурсов потребуется для сайта, если посетителей будет в 2 раза больше, или в 5, или в 10. Об этом и было сказано в статье. С нашей стороны мы сделали best effort - подготовили такую инфру, которая в базе уже покрывает все эти кейсы, а дальше вопрос регулировки и подстройки для частных случаев.
403 - это все-таки про другое, вы наверное имели в виду 5** ошибки.
Спасает конечно, разница между упасть на все время всплеска посещений против 5% таймаутов на 10% запросах, как пример :). Плюс вопрос в трудоемкости операций, запасе отказоустойчивости, гибкости и простоты изменения инфраструктуры, и многих других факторах. Я уж не говорю про запас ресурсов, которые без удобной автоматизации, наращивать достаточно некомфортно, особенно в условиях "пожара".
Инфраструктура такого рода позволила нам избавиться от множества узких мест и перейти на качественно иной уровень. Что касается частных случаев ошибок на сайте - их надо разбираться отдельно и предметно, это в том числе позволит улучшить пользовательский сервис ;).
Вот именно из-за таких проблем и проводятся работы вроде упомянутых в статье.
По факту - мы не утверждаем, что падений не было и не будет, падает кто угодно (даже google). Не падает только то, что вообще не работает. Самое главное в таких ситуациях - разобраться в причинах и научиться на ошибках, чтобы их не повторить. Ранее было много нюансов в работе проекта, площадок, приложения (часть этих нюансов мы описали в статье), и бОльшую часть из них мы итеративно устраняли совместно с разработчиками. Каждое следующее событие давало нам новый опыт и новый вызов. В статье - показательный пример такого события, которое помогло прийти инфраструктуре к новому витку развития, чтобы соответствовать текущим требованиям.Что касается битрикса - вы заблуждаетесь, он никогда (при нас по крайней мере) не использовался в качестве движка для сайта.
Это верно! :)
Спасибо, изучим!
Ну, тут два момента, первый — мы стараемся все-таки избегать вот этих вот бумажных формализмов и если и пишем про «будущие шаги», то стараемся их делать выполнимыми и реальными и второе — лично я реалист, но с верой в лучшее, как минимум стремление к выполнению этого шага уже даёт существенный позитивный рывок ;)
Но как всегда — на проде невозможно, кто же нам даст терзать прод в свою волю. А чтобы это воспроизвести не на проде — нужно поднимать идентичный тестовый стенд, на что конечно же нет ресурсов.
К сожалению мир не делится на белый и черный. Есть моменты когда мы можем бороться, есть — когда нет. Есть моменты когда бизнес может идти на встречу, а есть — когда физически нет таких возможностей. Мы стараемся идти на встречу при любом раскладе дел.
Но и не мы разработчики той системы которую обслуживаем. А провести рефактор кода далеко не всегда возможно, и нам надо выкручиваться исходя из существующих вводных данных, а не того, чего хотелось бы в идеале.
В случае с sentinel существует дополнительный сетевой хоп, т.к. приложение сначала идет в sentinel-proxy, после чего уже попадает в сам редис, конечно же это касается тех приложений, который не поддерживает нативную работу с sentinel.
В таком случае по идее проблем не должно быть, т.к. там ассинхронные операции и напрямую влиять на клиентские get'ы и mget'ы не должны.
И если можно — уточните, что вкладываете в понятие «высокие нагрузки» в каких-то абсолютных показателях?
Ниже вот ответили, ставить istio с трейсером. Но по опыту, в 90% случаев, проблема в сети между нодами. В случае с тем же flannel, ломаться обычно просто нечему. Не говорю конечно о крайних случаях, когда что-то сложное — огромные нагрузки, огромные кластера, тысячи сервисов и так далее, но если это ваш кейс, совершенно непонятно как вы ещё живёте без чего-то вроде istio :)
Про http2 это упущение (там действительно есть нюансы, например не все ингрессы умеют проксировать http2, а только терминировать), которые к сожалению, скорее всего будут еще обнаруживаться, уж слишком большой объем обзора :(.
Спасибо за информацию, я о таком нюансе не знал!
Посмотрим, проверим по возможности.