Не очень понял зачем делать снимки OS, если вы уже пользуетесь контейнерами? В свое время как раз docker смог заменить эту тяжелую технологию. В этом был бы еще смысл если у вас был auto scaling group, но я так понял у вас нет. И вам вроде как и не надо, можно в ручную создать новую vm и пролить на нее все необходимое.
Не сочтите за вброс, я рад что вы разбираетесь в новых технологиях и успешно их внедряете, даря людям стабильность и простоту. Но с точки наблюдателя кажется что вы дорвались да разных модных игрушек :-)
Как пример ваше желание запрыгнуть на kubernetes. Он не рассчитан на пару тройку машин. Выгода от него есть когда у вас есть четкое разделение на отдел поддержки этого kubernetes и много отделов разработки.
По первому алерту видно что началось все с БД. На этом этапе разве не увидили в мониторинге что с БД явно что то не то? Разве не было в cookbook минимальных указаний в какие метрики сломтреть/что делать с БД в этом случае?
У вас нет метрик среднего времени и количество обработанных запросов на backend? Если бы тормозила БД/сервисы то в этих метриках наверное можно было бы увидеть что проблема не в DDOS а в каком то узком горлошке внутри.
Неужели в логах не было кикаких ошибок? Я прям не могу поверить что приложения нигде не чихали и все проглатывали и до последнего момента не было понятно что БД не тянет.
Я правильно понял что основная БД одна без реплик?
Как тогда происходит увеличение CPU? Все останавливается, DODO IS встает колом, и через пару минут начинает оживать? А часто такое делаете? Это обкатаный этап?
Я правильно понял что сначала накинули экземплятров приложений и следом перезагрузили БД? Просто звутит как выстрелить себе в ногу... увеличить нагрузку на БД (которая вроде как и так вышла за алерт) и потом еще ее перезапустить...
Есть причина не использовать. И она весьма серьёзная. В alpine используется musl вместо glibc, что может приводить к случайным падением сервисов на python/jvm/и тд под нагрузкой.
При этом совершенно не понятны плюсы, кроме размера одного базового образа.
Я конечно бесконечно далек от этой области, но мне кажется вы чрезмерно верите в "рынок".
Я полагаю как только какой-нить банк, или любая другая крупная организация, выберет например МЦСТ для закупки процессоров, все остальные покупатели побегут ту да же. Потому что просто экономически выгоднее печатать большими партиями, и можно выбить на этом основании скидку. А еще потому что ПО будет быстрее развиваться силами большой компании. Ну и автоматом это начнет душить Ядро/Байкал, потому что поток инвестиций будет несоизмерим.
Конкурировать надо с внешним рынком, а не с микрошечным внутренним.
Я думаю как раз надо разбивать все на компоненты/процессы и пытаться импортозамешать их потихоньку силами всех локальных компаний. Иначе это возьня на месте.
Вы часом DDD (Data Driven Development) с Domain Driven Design не перепутали? Потому что в докладе «Особенности микросервисов на примере e-Com-платформы / Андрей Евсюков» насколько я помню речь шла про Domain Driven Design.
Почему то в каждой статье про DDD, авторы дорисовывают ореол божественности данной модели разработки.
Аля, анемичная модель — это антипаттерн, а DDD это передавая практика.
Сюда же — Команды хотят делать инструменты и решения, которые наиболее правильно, быстро и красиво решают бизнес-задачи
Я имел «счастье» разрабатывать проект по этой модели (По Вернону). И это было очень долго и сложно. А сейчас на поддержке — это очень сложно и очень больно.
По факту DDD это некая «красивая» модель, которая не ложиться на реальный мир. Ее постоянно пиарят и докручивают новыми фичами. Аля Event Sourcing, Microservices, теперь оказывается еще и функциональщиной. И каждый раз дают обещания — вот сейчас то точно полетит. Только вот есть проблема. DDD не летит. Никто массово ее не применяет, ни у кого не получается натянуть на реальный мир.
Постараюсь донести основную идею. Не бывает красивой модели разработки в вакууме. Если DDD не ложиться на экономически выгодную разработку — значит это плохая модель.
День добрый.
А что за провайдер/хостинг такой что дает вам MsSQL с лицензией? Насколько я слышал для России лицензии закрыли.
Из текста непонятно в итоге где храните логи. Поделитесь?
На всякий случай оставлю тут ссылку на https://keeweb.info/
Не очень понял зачем делать снимки OS, если вы уже пользуетесь контейнерами? В свое время как раз docker смог заменить эту тяжелую технологию. В этом был бы еще смысл если у вас был auto scaling group, но я так понял у вас нет. И вам вроде как и не надо, можно в ручную создать новую vm и пролить на нее все необходимое.
Не сочтите за вброс, я рад что вы разбираетесь в новых технологиях и успешно их внедряете, даря людям стабильность и простоту. Но с точки наблюдателя кажется что вы дорвались да разных модных игрушек :-)
Как пример ваше желание запрыгнуть на kubernetes. Он не рассчитан на пару тройку машин. Выгода от него есть когда у вас есть четкое разделение на отдел поддержки этого kubernetes и много отделов разработки.
Есть еще IVA Technologies - https://iva-tech.ru/catalog/product-iva-mcu/ за номером №5563
Спасибо за разбор. Читать было увлекательно.
Но почти сразу начали возникать вопросики :-)
Не могли бы вы поделиться уточнениями:
По первому алерту видно что началось все с БД.
На этом этапе разве не увидили в мониторинге что с БД явно что то не то?
Разве не было в cookbook минимальных указаний в какие метрики сломтреть/что делать с БД в этом случае?
У вас нет метрик среднего времени и количество обработанных запросов на backend?
Если бы тормозила БД/сервисы то в этих метриках наверное можно было бы увидеть что проблема не в DDOS а в каком то узком горлошке внутри.
Неужели в логах не было кикаких ошибок?
Я прям не могу поверить что приложения нигде не чихали и все проглатывали и до последнего момента не было понятно что БД не тянет.
Я правильно понял что основная БД одна без реплик?
Как тогда происходит увеличение CPU? Все останавливается, DODO IS встает колом, и через пару минут начинает оживать?
А часто такое делаете? Это обкатаный этап?
Я правильно понял что сначала накинули экземплятров приложений и следом перезагрузили БД?
Просто звутит как выстрелить себе в ногу... увеличить нагрузку на БД (которая вроде как и так вышла за алерт) и потом еще ее перезапустить...
Есть причина не использовать. И она весьма серьёзная. В alpine используется musl вместо glibc, что может приводить к случайным падением сервисов на python/jvm/и тд под нагрузкой.
При этом совершенно не понятны плюсы, кроме размера одного базового образа.
Ну гугловая реализация и так на c/c++, но похоже они оч старались.
Может оч надо было обосновать почему надо все перепиасать на какой нить golang 😅
Надо помнить что для Python реализация grpc оч тормозная.
Я конечно бесконечно далек от этой области, но мне кажется вы чрезмерно верите в "рынок".
Я полагаю как только какой-нить банк, или любая другая крупная организация, выберет например МЦСТ для закупки процессоров, все остальные покупатели побегут ту да же. Потому что просто экономически выгоднее печатать большими партиями, и можно выбить на этом основании скидку. А еще потому что ПО будет быстрее развиваться силами большой компании. Ну и автоматом это начнет душить Ядро/Байкал, потому что поток инвестиций будет несоизмерим.
Конкурировать надо с внешним рынком, а не с микрошечным внутренним.
Я думаю как раз надо разбивать все на компоненты/процессы и пытаться импортозамешать их потихоньку силами всех локальных компаний. Иначе это возьня на месте.
А авторы случайно не сравнивали скорость/качество сжатия json+zstd vs messagepack+zstd?
Слышал что при сжатии нет особой разницы между текстовыми форматами и бинарными
Почему не воспроизводимой? Собирайте на CI в той же версии image. Или используйте docker multi-stage build.
Есть более правильный способ
А в Dockerfile
А расскажите как вы разрабатываете в docker?
У них есть своя веб морда с чатиками. Вполне годная штука.
Бесплатная версия с их подписью и лимитами.
Вы часом DDD (Data Driven Development) с Domain Driven Design не перепутали? Потому что в докладе «Особенности микросервисов на примере e-Com-платформы / Андрей Евсюков» насколько я помню речь шла про Domain Driven Design.
И если не секрет, какой примерно объем данных в целом.
Спасибо за статью. Весьма познавательно. Только вот в статье не раскрыто как же сделана физическая сеть, что тоже интересно.
Мне кажется вы что-то совсем странное себе придумали. ПО это лишь средство достижения бизнес цели, а не инвестиция.
Я имел «счастье» разрабатывать проект по этой модели (По Вернону). И это было очень долго и сложно. А сейчас на поддержке — это очень сложно и очень больно.
По факту DDD это некая «красивая» модель, которая не ложиться на реальный мир. Ее постоянно пиарят и докручивают новыми фичами. Аля Event Sourcing, Microservices, теперь оказывается еще и функциональщиной. И каждый раз дают обещания — вот сейчас то точно полетит. Только вот есть проблема. DDD не летит. Никто массово ее не применяет, ни у кого не получается натянуть на реальный мир.
Постараюсь донести основную идею. Не бывает красивой модели разработки в вакууме. Если DDD не ложиться на экономически выгодную разработку — значит это плохая модель.