DevOps без Dev, с какой стороны подступиться?

Вот например что это за динамические контейнеры на amazon, которые поднимаются по api когда нужны мощности, на них разварачивается некое ПО и идет переадресация запросов от пользователей или других подобных динамических сервисов?

Не поверишь - это контейнеры, которые поднимаются когда нужны дополнительные мощности. Представь что у тебя есть сервис, инстанс которого одновременно может обслуживать 10 пользователей. Тут к тебе приходят одновременно 20 пользователей - ты поднимаешь еще один инстанс, пользователи получают услугу, все ок. Потом нагрузка опять спадает до 10 одновременных юзеров - ты гасишь один инстанс - он же будет простаивать, а это все-таки деньги.

В "классическом" случае если к тебе приходит 11 пользователь, а сервис может только в 10, то этот одиннадцатый получает ошибку и идет ныть в твиттер. Ты поднимаешь мощный сервак, которой одновременно может аж 100 пользователей обслужить, чтоб на всякий случай, и 99% времени он загружен на 10 процентов и ты просто так платишь деньги.

Интересует с чего начать погружение во все это болото в 2020 - книги, статьи, видео. Можно на eng.

Ну вот с докера и начни, параллельно и все остальное зацепишь. Статьи - да об этом из каждого утюга рассказывают, ты не вообще не искал?

БД то одна. ЕЕ не динамизируешь.

Это ты сейчас про какую БД? Ну кроме того, что у того же амазона есть вполне себе масштабируемые (в определенных пределах) RDBMS решения, такие вещи вообще на них не делаются.

В смысле хочешь https://aws.amazon.com/certification/certified-sysops-admin-associate/ ? Берёшь и готовишься к сертификации, на aws есть ссылки, на всяких udemy должны быть видео если они тебе нужны.

Какие такие, простите, вещи на бд не делаются?

Начни так - приходишь разрабом в стартап, говоришь что любишь обмазываться несвежим композом и собирать реплика-сет. Потом главное отбиться

БД то одна. ЕЕ не динамизируешь

Чо?

По-настоящему масштабируемые аппы на RDBMS не делаются.

+1

4.2 же.

Мы просто о разных степенях масштабируемости говорим. Кому-то и master-slave на двух DL380 - круто и масштабируемо.

Oops?

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

Я понмаю зачем оно надо, я не понимаю как. Получается пользователи ломятся на условный балансер, который считает число соединений и если их становится слишком много, для текущего ко-ва серверов, отправляет запрос по api на поднятие новых, ему в ответ возвращаются адреса этих серверов. а если сам балансер уже не справляется? То он сам должен поднимать себе помощника или за ним кто-то наблюдает (и вот этот наблюдатель - готовое решение или надо самому писать?) со стороны и поднимает еще один балансер? И как сказать пользователям, что теперь у нас два балансера (по сути точки входа), добавлять запись в dns?

Ну и все эти динамические контейнеры - они по сути дают процессорные мощности, а хранилища данных (файлы, бд) должны распологаться на более «статичных» серверах и тоже как-то реплецироваться между собой. Ну и кеширование для более быстрой отдачи данных.

Статьи - да об этом из каждого утюга рассказывают, ты не вообще не искал?

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

тут выше подсказали - SysOps

TechOps вообще-то. Но это понятие включается в себя как DevOps, так и остальные Ops, например, Infrastructure.

Шардинг кривыми руками васянов - наше всё

Это не девопс.

А кто?

Подозреваю, что это отсылка на классическое «если в компании есть команда devops’ов, то эта компания не понимает суть devops».

Devops — это когда команда инженеров сама деплоит то, что они наговнокодили.

Но даже в этом случае это не обязательно значит что кодеры сами всё деплоят: в команде может быть отдельный человек для работы с этим всем, но суть — в том, что команда в целом осознаёт, как всё это будет деплоиться ещё до того, как начали впиливать фичу, что повышает velocity…<поскипано 3 килобайта agile-баззвордов>

Вот меня часть про «разработку» не интересует, а именно управление всей этой архитектурой, через взаимодействие с dev естественно.

То он сам должен поднимать себе помощника или за ним кто-то наблюдает

и вот этот наблюдатель - готовое решение или надо самому писать?

Ну смотря что за сервер выбран. В "домашних" условиях за этим будет следить скорее всего какой-нибудь самописный демон, который будет брать данные из мониторинга - потому что сам сервер может и не справиться с поднятием помощников если его резко закидают запросами, да и как-то не очень правильно чтоб балансер рулил инфраструктуров. Во всяких там SaaS решениях это все будет под капотом.

И как сказать пользователям, что теперь у нас два балансера (по сути точки входа), добавлять запись в dns?

В dns вообще лучше лезть как можо меньше, потому что вы не знаете что пользователь (или его апстрим) у себя накрутил и не можете гарантировать что ваши изменения быстро подтянуться. Еще несколько лет назад зона ru, например, синкалась то ли 4, то ли 5 раз в сутки.

Тут вам нужна какая-то железка или стороннее решение (типа cloudflare) на входе, которая будет заточена на то чтоб раскидывать траффик. У нас например какой-то там citrix стоит (я не в курсе особо), которой проталкивает через себя траффик практически ко всем проектам - там количество возможных соединений зависит тупо от количества доступной памяти.

То есть точка входа для пользователя практически никогда не меняется. Что происходит под капотом это уже зависит от выбранного стека.

Ну и все эти динамические контейнеры - они по сути дают процессорные мощности, а хранилища данных (файлы, бд) должны распологаться на более «статичных» серверах и тоже как-то реплецироваться между собой. Ну и кеширование для более быстрой отдачи данных.

Ну в целом да. Еще следует помнить про шардирование - чем держать жирный сервер с базой на терабайт лучше раскидать это все на 10 серверов с кусками базы по сто гигов. Но опять же, это актуально когда на "обычную" модель построения сервиса натягиваются контейнеры и вот это все. Если проект сразу пишется "по-новому" то у вас там будет куча маленьких сервисов, каждый со своей базой, и они будут общаться между собой, так что как такового единого общего хранилища не будет.

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

Вот меня часть про «разработку» не интересует, а именно управление всей этой архитектурой

Так дело в том что devops и вся эта идея про контейнеры это не "делай так, а не иначе", а набор идей, которые теоретически могут упростить жизнь. И на основании этих идей каждый пилит что-то свое. При этом devops как бы подразумевает что вы можете в разработку и в архитектуру разрабатываемых решений. Вообще тут как курица и яйцо - если вы не можете придумать как ваши сервисы можно контейнерезировать, то вы не сможете понять что нужно делать на серверах, и наоборот - если вы все всегда поднимали на железе с тоннами памяти, цпу и рам, и у вас там сто мнолитов крутилось, вы не придумаете что и как вы сможете разделить на уровне кода. Так что тут либо вникать в разработку, либо, как уже сказали, получать какой-нибудь там сертификат по AWS.

Лучше расскажите как эти вещи ведут себя под DDOS. Оно понятно, что динамически можно любую мощь поднять, развернуть и обслуживать миллионы запросов в секунду.

Вопрос лишь в том, что при этом станет с кошельком.

По-настоящему масштабируемые аппы на RDBMS не делаются

ок, назови крупные (хотя бы 5000 rps) аппы, которые не имеют под ними мускулы/оракла/постгреса

Тут вам нужна какая-то железка или стороннее решение (типа cloudflare) на входе, которая будет заточена на то чтоб раскидывать траффик. У нас например какой-то там citrix стоит (я не в курсе особо), которой проталкивает через себя траффик практически ко всем проектам - там количество возможных соединений зависит тупо от количества доступной памяти.

Интересно. А оно получается просто маршрутизирует трафик во внутреннюю сеть? Ведь у нас ко-во портов ограничено и если с каждым пользователем делать по коннекту, то быстро закончится.

При этом devops как бы подразумевает что вы можете в разработку и в архитектуру разрабатываемых решений.

А не много для одного человека получается? И архитектуру продумать и код написать и инфраструктуру настроить...человек-оркестр.

Ведь у нас ко-во портов ограничено и если с каждым пользователем делать по коннекту, то быстро закончится.

Коннект по TCP это "адрес клиента + порт клиента + адрес сервера + порт сервера". Разные адреса клиентов позволяют серверу принимать неограниченное* число коннектов (с TCP-ограничением в 65535 на клиента), или в роли клиента поднимать до 65535 коннектов до апстрима (проксируя запросы). В случае когда сервер принимает подключения никаких проблем нет. Когда он проксирует запросы - ну просто "добавляем ему айпишников", каждый из которых дает нам еще 65535 коннектов до апстрима.

* ну с учетом того что серверу хватает памяти и прочих ресурсов чтоб все это обслужить.

А не много для одного человека получается? И архитектуру продумать и код написать и инфраструктуру настроить...человек-оркестр.

Так один из немаловажных аспектов этой идеи это то что вы разрабатываете не монолиты, а маленькие сервисы. Конечно когда у вас проект на миллиарды KLOC то не то что один человек не осилит, с этим целые команды годами пытаются справиться. А когда у вас проект уровня хэлловорлда то вы сами можете и в архитектуру, и в кодинг, и в тесты, и в деплой и эксплуатацию.

Конечно есть те кто продумывает архитектуру всего проекта (как все эти куски в кучу соберутся) и инфраструктуру (что и как будет разворачиваться), но мне кажется на этапе знакомства с этой практикой и без опыта "простого" применения всего этого такими вопросами голову забивать рано.

это такая плоская шутка про DynamoDB?

Коннект по TCP это «адрес клиента + порт клиента + адрес сервера + порт сервера».

Это я понимаю, потому и спросил про маршрутизацию, когда порты не будут тратиться. А сам промежуточный балансер уже может получать список серверов (кеширующих, наверное) для пересылки от некоего орбитора.

ну просто «добавляем ему айпишников»

А как сообщить клиентам про эти новые айпи? Ну понятно, что можно сделать костыль и при включении клиентского ПО оно ходить на bootstrap сервер и забирает список актуальных адресов для подключения, но это получается еще один сервис.

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

Вопрос лишь в том, что при этом станет с кошельком.

Ваш схуднет, амазоновый потолстеет =)

Еще забавно если какой-нибудь ключ от апихи утечет, и на вашем аккаунте быстренько начнут майнить биткоины или еще что-то подобное.

Слышал истории об обоих вариантах.

ок, назови крупные (хотя бы 5000 rps) аппы, которые не имеют под ними мускулы/оракла/постгреса

Мы обслуживаем порядка 180 миллиардов запросов в день. У нас нет RDBMS от слова совсем. А 5000 rps это даже не одна нода из тысяч.

Мы

Ок, но вы это далеко не единственный в мире масштабируемый апп

Ну строго говоря, у нас их десятки, этих аппов. Никакая высоконагруженная хорошо распараллеленная система на RDBMS работать не будет, по понятным причинам. Ибо что может сотня маленьких DL380 по отдельности, не сможет один. Чтобы RDBMS работала в таких условиях, ей нужен гипотетический сервер, работающий в сотни раз быстрее обычного железа, потому что ни одна из них не кластеризуется в классическом понимании.

потому что ни одна из них не кластеризуется в классическом понимании.

Вот это уже не совсем корректно

Вот меня часть про «разработку» не интересует, а именно управление всей этой архитектурой, через взаимодействие с dev естественно.

тебя не интересует разработка, но ты лезешь в архитектуру приложения. с фига ли интересно?

Вот это уже не совсем корректно

Ну-ка? Кластеризуй мне PostgreSQL как Kafka?

И давай не будем говорить про EDW, в которых от RDBMS только совместимый интерфейс и то не весь.

Воркер - это процесс или отдельный сервер?

Ну скажем так - компонент сервера, принимающего входящие соединения. Как это там будет сделано - отдельный поток, отдельный процесс или вообще что-то стоящее на отдельной машине разницы особой не играет (но мне кажется проще и быстрее внутри одного процесса все это сделать)

Никакая высоконагруженная хорошо распараллеленная система на RDBMS работать не будет

а все, что работает на RDBMS — просто недостаточно хорошо распараллелено. ага.

Ну, предположим у нас есть мощная железяка с кучей виртуальных контейнеров и виртуальной сетью, когда из внешней сети приходит пакет от клиента железяка маршрутизирует его в один из контейнеров и софт внутри контейнера устанавливает соединения с клиентрм и обрабатывает запросы (сам или дальше перекидывает).

Эти контейнеры и есть воркеры? Ну одним из вариантов воркеров.

а все, что работает на RDBMS — просто недостаточно хорошо распараллелено. ага.

Да софт может быть сколь угодно хорошо распараллелен, но боттлнеком будет перфоманс RDBMS. Потому что она не кластеризуется никак.

Мы обслуживаем порядка 180 миллиардов запросов в день.

Прости, но чот я с трудом верю, что в РФ где-то есть такие цифры. Это в какой сфере?

Шардирование в постгре завезли даже не вчера. На пяти шардах тянем без напряга 3к рпс, запас где-то в 2 раза есть по мощности.

Но у нас очень хорошо прогнозируемые нагрузки.

Да софт может быть сколь угодно хорошо распараллелен, но боттлнеком будет перфоманс RDBMS. Потому что она не кластеризуется никак.

По классике в этот момент ты распиливаешь прилагу и ее БД на мелкие части.

Не, я тут не топлю за использование реляционок вообще везде, но затыкать абстрактными монгами косяки проектирования - это тупиковый путь.

Никакая высоконагруженная хорошо распараллеленная система на RDBMS работать не будет

Да софт может быть сколь угодно хорошо распараллелен, но боттлнеком будет перфоманс RDBMS.

мать, нас учат коммерции

Потому что она не кластеризуется никак.

сильное утверждение. как в плане того, что прям никак, так и в плане того, что единственный способ повысить перфоманс биде — собрать кластер биде.

Прости, но чот я с трудом верю, что в РФ где-то есть такие цифры. Это в какой сфере?

Это не РФ, это транснациональная компания.

Шардирование в постгре завезли даже не вчера. На пяти шардах тянем без напряга 3к рпс, запас где-то в 2 раза есть по мощности.

3 рпс по нашим меркам - это детский сад штаны на лямках… А еще латентность. Есть аппы, работающие в микросекундных задержках. Не миллисекундных, да.

По классике в этот момент ты распиливаешь прилагу и ее БД на мелкие части.

Все верно. Но мелкие части тоже высоконагруженные.

сильное утверждение. как в плане того, что прям никак, так и в плане того, что единственный способ повысить перфоманс биде — собрать кластер биде.

Так ты давай с примерами и бенчмарками. На вышеуказанную нагрузку - она не гипотетическая.

ага, сейчас, пиво только допью. с детства мечтал с твоими безапелляционными понтами сражаться

Эти контейнеры и есть воркеры? Ну одним из вариантов воркеров.

Ну очень грубо говоря да. Вообще воркером обычно называют какой-то компонент, который выполняет задачи. Например я могу в приложении завести несколько потоков и закидывать входящие запросы в них - это будут мои воркеры. Или я могу поднять какой-то сервер очередей и приложение входящие запросы будет в него закидывать, их оттуда будут брать другие приложения - воркеры, обрабатывать, отправлять обратно через очередь серверу на входе - и тут он уже будет воркером, потому что выполняет задачу доставки контента до клиента. Ну и так далее - я хочу сказать что воркер это про логическое деление - какой-то компонент, который делает работу, и копий такого компонента можно запустить больше одного.

Хочу заметить что описанная схема не обязательно будет работать с http-трафиком - пока мы там по очередям шаримся все таймауты выйдут и клиент отвалится. В таком случае я бы делал (если бы я мог писать сервера, лол) в рамках потоков сервера или какого-то взаимодействия между процессами, или если мне надо разнести все это физически на разные машины то изобретал бы какой-то протокол общения, чтоб типа как прокси, но все в рамках одного коннекта.

Конечно я не знаю как конкретно это все работает у того же амазона или еще в каких-то решениях за сотни нефти - обычно такими разработками предпочитают не делиться.