CACHE
В ответу пользаку не всегда важна огромная точность. Например если пользак делает запрос на получение данных по определенному условия, и в бд попали новые данные, то нам не обязательно сразу же отдавать их. Лаг в несколько секунд часто допустим.
Если мы идем в эту историю то нам можно выполнять запрос один раз и класть его в кеш. И если эти данные запрашиваются десятки раз в секунду то нам можно скратить запросы в бд до одного раза. И потом отдавать их просто из кеша. Это сильно снизить нагрузку)
В ответу пользаку не всегда важна огромная точность. Например если пользак делает запрос на получение данных по определенному условия, и в бд попали новые данные, то нам не обязательно сразу же отдавать их. Лаг в несколько секунд часто допустим.
Если мы идем в эту историю то нам можно выполнять запрос один раз и класть его в кеш. И если эти данные запрашиваются десятки раз в секунду то нам можно скратить запросы в бд до одного раза. И потом отдавать их просто из кеша. Это сильно снизить нагрузку)
👍1
GPU
Если мы берем маленькие языковые модели то в подборе gpu важнее память. Если есть взять карту более старого поколения но с бОльшем количеством памяти то лучше взять ее.
Ведь сами расчеты там в любом случае будут занимать секунды, и отличие в 10-15 процентов не сыграют большой роли. А вот помещать большее количество параметров в память очень важно. Ведь постоянно дозапрашивать их с диска будет дольше чем разово выгрузить их в память.
В большенстве доступных карт сейчас не больше 16гб, в редких случаях 24 или 32. И вот выбрать более старую карту с 16гб будет куда лучше чем самую новую с 12.
Если мы берем маленькие языковые модели то в подборе gpu важнее память. Если есть взять карту более старого поколения но с бОльшем количеством памяти то лучше взять ее.
Ведь сами расчеты там в любом случае будут занимать секунды, и отличие в 10-15 процентов не сыграют большой роли. А вот помещать большее количество параметров в память очень важно. Ведь постоянно дозапрашивать их с диска будет дольше чем разово выгрузить их в память.
В большенстве доступных карт сейчас не больше 16гб, в редких случаях 24 или 32. И вот выбрать более старую карту с 16гб будет куда лучше чем самую новую с 12.
👍1🎄1
PARALEL
Для больших команд которые разрабатывают кучу микросерисов нужно сделать удобное окружение. Один из важных моментов это паралельность CI/CD. Что бы не было такого что один сервер с раннором 24/7 обрабатывает очередь и люди ждут сборки по несколько часов.
Тут хорошо ложится автоскейл кубера. Тут под каждую задачу будет выделяться нода, подключаться к кластеру и обрабатывать задачу. После завершения задачи она либо берет следующую из очереди либо гасится по ненадобности.
Это неплохой баланс в мощности и стоимостью. Не нужно держать десятку нод и платить за их простой.
Но главное не забывать про лимиты, что бы кубер не раздул кластер до сотен нод)
Для больших команд которые разрабатывают кучу микросерисов нужно сделать удобное окружение. Один из важных моментов это паралельность CI/CD. Что бы не было такого что один сервер с раннором 24/7 обрабатывает очередь и люди ждут сборки по несколько часов.
Тут хорошо ложится автоскейл кубера. Тут под каждую задачу будет выделяться нода, подключаться к кластеру и обрабатывать задачу. После завершения задачи она либо берет следующую из очереди либо гасится по ненадобности.
Это неплохой баланс в мощности и стоимостью. Не нужно держать десятку нод и платить за их простой.
Но главное не забывать про лимиты, что бы кубер не раздул кластер до сотен нод)
👍1
GPU
Изначально эти чипы создавались ради обработки графики. Так как там есть высокая паралельность, при умении делать простые операции.
Это значит что бы можем паралельно делать простые преобразования над матрицами, чем и является работа с графикой. Но внезапно оказалось что подобные вычесления подходят и для задач связанных с AI. А если совместить обработку графики и ИИ то альтернатив почти нет, никакие другие типы чипов не вывезут.
Например вчера вечером собрал небольшой проект, который обрабатывает видеопоток с камеры и вытаскивает оттуда обьекты заданные в промте. Для одного потока в десятки fps вполне хватает 4080 super на 16гб, и даже остается много ресурса на другие модели)
Изначально эти чипы создавались ради обработки графики. Так как там есть высокая паралельность, при умении делать простые операции.
Это значит что бы можем паралельно делать простые преобразования над матрицами, чем и является работа с графикой. Но внезапно оказалось что подобные вычесления подходят и для задач связанных с AI. А если совместить обработку графики и ИИ то альтернатив почти нет, никакие другие типы чипов не вывезут.
Например вчера вечером собрал небольшой проект, который обрабатывает видеопоток с камеры и вытаскивает оттуда обьекты заданные в промте. Для одного потока в десятки fps вполне хватает 4080 super на 16гб, и даже остается много ресурса на другие модели)
👍1
K8S
Для меня основной минус кубера в том что все делают его по своему.
От проекта к проекту каждый кластер будет уникален, особенно если используются разные провайдеры или это селф хостед. Там будут разные storage clases, ингресы, работа с сертами и переменными. Это создает дополнительнюу сложность когда вы разрабатываете дистрибутив приложения под кубер.
Это, чаще всего, решает вельюс файлом. Когда клиент может определить свои настройки. Но это усложняет сам процесс поставки софта клиенту, ведь ему придется самому донастраивать что то.
В этом плане обычная виртуалка с докером куда проще, можно предоставить клиенту docker compose со всем необходимым и у него все сразу заработает)
Для меня основной минус кубера в том что все делают его по своему.
От проекта к проекту каждый кластер будет уникален, особенно если используются разные провайдеры или это селф хостед. Там будут разные storage clases, ингресы, работа с сертами и переменными. Это создает дополнительнюу сложность когда вы разрабатываете дистрибутив приложения под кубер.
Это, чаще всего, решает вельюс файлом. Когда клиент может определить свои настройки. Но это усложняет сам процесс поставки софта клиенту, ведь ему придется самому донастраивать что то.
В этом плане обычная виртуалка с докером куда проще, можно предоставить клиенту docker compose со всем необходимым и у него все сразу заработает)
👍1
DEPENDENCY
Даже если мы в своем проекте используем минимум зависимостей, только известные большие библиотеки, то это не значит что на проде их будет не много. Каждая более менее большая библиотека тянет за собой зависимости поменьше, в свою очередь они тянут другие. Может получится что явно включив в проект 5 библиотек в конечной сборке их будет десятки и сотни.
В чем тут проблема? В конечном итоге в сборку могут попасть устаревшие и плохо защищенные зависимости. А отследить это будет очень сложно, для этого нужно разбирать вообще все что тянут библиотеки на каждом уровне зависимости.
Так же есть популярный способ атак: отследив все зависимости больших библиотек мы почти гарантированно найдем какой ни будь репозиторий с древними либами за которым уже никто не следит. И чаще сам софт репозитория будет плохо защищен. Поломав его и подменив либу на уязвимый код мы автоматически атакуем все проекты которые используют изначальную большую библиотеку.
Такие случаи уже были с npm репозиториями, когда в какой то пакет внедряли RCE.
Даже если мы в своем проекте используем минимум зависимостей, только известные большие библиотеки, то это не значит что на проде их будет не много. Каждая более менее большая библиотека тянет за собой зависимости поменьше, в свою очередь они тянут другие. Может получится что явно включив в проект 5 библиотек в конечной сборке их будет десятки и сотни.
В чем тут проблема? В конечном итоге в сборку могут попасть устаревшие и плохо защищенные зависимости. А отследить это будет очень сложно, для этого нужно разбирать вообще все что тянут библиотеки на каждом уровне зависимости.
Так же есть популярный способ атак: отследив все зависимости больших библиотек мы почти гарантированно найдем какой ни будь репозиторий с древними либами за которым уже никто не следит. И чаще сам софт репозитория будет плохо защищен. Поломав его и подменив либу на уязвимый код мы автоматически атакуем все проекты которые используют изначальную большую библиотеку.
Такие случаи уже были с npm репозиториями, когда в какой то пакет внедряли RCE.
👍1
DNS
При покупке домена нам нужно им как то управлять. Для этого нам нужен dns сервер.
Обычно, регистраторы предоставляют эту услугу за отдельную плату. Но чаще всего это не удобно, ведь разные наши домены могут быть у разных регистраторов, и тут либо мигрировать все в один либо менеджить несколько днс на разыных сервисах.
Для решения этой боли обычно использую cloudflare. Он прендоставляет бесплатный днс, который можно указать для всех доменов на всех регистраторов. По итогу получается единое место где мы можем добавлять запись и они будут супер быстро обновляться. Плюс cloudflare предоставляет довольно много фичей по защите и фильтрации трафика.
При покупке домена нам нужно им как то управлять. Для этого нам нужен dns сервер.
Обычно, регистраторы предоставляют эту услугу за отдельную плату. Но чаще всего это не удобно, ведь разные наши домены могут быть у разных регистраторов, и тут либо мигрировать все в один либо менеджить несколько днс на разыных сервисах.
Для решения этой боли обычно использую cloudflare. Он прендоставляет бесплатный днс, который можно указать для всех доменов на всех регистраторов. По итогу получается единое место где мы можем добавлять запись и они будут супер быстро обновляться. Плюс cloudflare предоставляет довольно много фичей по защите и фильтрации трафика.
👍1
K8S
Уже покритиковал кубер за то что он слишком настраиваемый и у всех разный. Время похвалить.
С одной из сторон эта настраиваемость позволяет положить куб на любую инфру. В каждой компании и облаке может быть своя система виртуализации, хранения данных, балансировки нагрузки и тд. И куб встанет почти куда угодно.
Это дает нам важное приемущество - верхнеуровнево у всех будет один интерфейс работы с инфрой, это сам куб. Будут различия в настройки pvc, ингрессов, сетевого взаимодействия и тд, но это мелочи по сравнению с тем что все остальное будет идентичным.
При переходе между проектами с разным кубом нужно сильно меньше времени на погружение в инфру, чем без куба)
Ну и как писал раньше, это иногда вызвает и сложности)
Уже покритиковал кубер за то что он слишком настраиваемый и у всех разный. Время похвалить.
С одной из сторон эта настраиваемость позволяет положить куб на любую инфру. В каждой компании и облаке может быть своя система виртуализации, хранения данных, балансировки нагрузки и тд. И куб встанет почти куда угодно.
Это дает нам важное приемущество - верхнеуровнево у всех будет один интерфейс работы с инфрой, это сам куб. Будут различия в настройки pvc, ингрессов, сетевого взаимодействия и тд, но это мелочи по сравнению с тем что все остальное будет идентичным.
При переходе между проектами с разным кубом нужно сильно меньше времени на погружение в инфру, чем без куба)
Ну и как писал раньше, это иногда вызвает и сложности)
👍1
SEC
В контексте безопасности нужно донастраивать наши фреймворки.
Например - спринг по дефоту запускает актуатор на том же порту что и приложение, и можно снаружи обратится на него. Самое невинное что грозит - раскрытие информации про инфру.
И вот таких моментов может быть много. Лучший вариант тут это закрыть все и открывать по мере необходимости. Ну и использовать специализированные DAST сканеры которые протыкают все возможные открытые эндпоинты.
В контексте безопасности нужно донастраивать наши фреймворки.
Например - спринг по дефоту запускает актуатор на том же порту что и приложение, и можно снаружи обратится на него. Самое невинное что грозит - раскрытие информации про инфру.
И вот таких моментов может быть много. Лучший вариант тут это закрыть все и открывать по мере необходимости. Ну и использовать специализированные DAST сканеры которые протыкают все возможные открытые эндпоинты.
👍1
NET
В плане сети логика должна быть такой: все что не разрешено должно быть запрещено.
Внешний балансер по дефолту не прокидывает ничего, и мы явно должно прописать проксирование, открытые порты и внутренние локейшены.
Сейчас просто сталкиваюсь с тем что в открытом доступе многих проектов валяется минио, нексус, кейклок и так далее. Где то с дефолтными кредами, где то с анонимным доступом и прочими косяками.
Чаще проблема тут в том что люди забывают и забивают на это, главное что бы основной сервис работал)
В плане сети логика должна быть такой: все что не разрешено должно быть запрещено.
Внешний балансер по дефолту не прокидывает ничего, и мы явно должно прописать проксирование, открытые порты и внутренние локейшены.
Сейчас просто сталкиваюсь с тем что в открытом доступе многих проектов валяется минио, нексус, кейклок и так далее. Где то с дефолтными кредами, где то с анонимным доступом и прочими косяками.
Чаще проблема тут в том что люди забывают и забивают на это, главное что бы основной сервис работал)
👍1
MOBILE
Последнии дни тыкал мобильные приложения на безопасность.
И хочется сказать, приложения под IOS сильно безопаснее. Даже же что бы влететь в него и проверить базовые вещи нужно постараться куда сильнее чем на андроиде.
Условно декомпилить apk сборку занимает минут 5, и еще 5 минут что бы просканить на самые очевидные проблемы с хардкодом. На ios сборках это займет сильно больше времени, и бесплатными решениями тут не обойтись.
НО, это все не спасает от ошибок разработчиков в хардкоде и ошибках в логике. Условно декомпилить в асемблер и сделать поиск сигнатур не очень сложно.
Последнии дни тыкал мобильные приложения на безопасность.
И хочется сказать, приложения под IOS сильно безопаснее. Даже же что бы влететь в него и проверить базовые вещи нужно постараться куда сильнее чем на андроиде.
Условно декомпилить apk сборку занимает минут 5, и еще 5 минут что бы просканить на самые очевидные проблемы с хардкодом. На ios сборках это займет сильно больше времени, и бесплатными решениями тут не обойтись.
НО, это все не спасает от ошибок разработчиков в хардкоде и ошибках в логике. Условно декомпилить в асемблер и сделать поиск сигнатур не очень сложно.
👍1
P.S. в работе с мобилкой я пока новичек, не так много опыта. Но даже так андроид легче поддается)
SCALE
Инфра подходящая для больших проектов с нагрузкой нужна только для больших проектов с нагрузкой.
Если мы делаем сайт с несколькими микросервисами на бекенде и небольшой нагрузкой в 500-600 rps то супер масштабируемая инфра с кубом, кластерами баз и прочеми замарочками только усложнит жизнь. По опыту для большенства небольших проектов хват 5-6 серверов и docker-compose. Такая связка может работать годами и не создавать проблем.
Но почему то многие сразу поднимают их на серьезной инфре и потом страдают из за поддержки)
Инфра подходящая для больших проектов с нагрузкой нужна только для больших проектов с нагрузкой.
Если мы делаем сайт с несколькими микросервисами на бекенде и небольшой нагрузкой в 500-600 rps то супер масштабируемая инфра с кубом, кластерами баз и прочеми замарочками только усложнит жизнь. По опыту для большенства небольших проектов хват 5-6 серверов и docker-compose. Такая связка может работать годами и не создавать проблем.
Но почему то многие сразу поднимают их на серьезной инфре и потом страдают из за поддержки)
👍1
REALTIME
Операционные системы реального времени.
Обычно применяются в машинах или IOT. В чем отличие от обычных систем?
Там хорошая система приоритезации процессов и в целом работы с ними. Например если в систему пришел сигнал с определенного датчика важного то отработка это сигнала может выместить все остальные процессы и выполнится в первую очередь. Либо сразу после текущего выполнения, либо текущий поставится на паузу.
Это сильно отличается от классических систем, где все процессы по дефолту равноправны и выполняются паралельно либо последовательно. Там конечно можно настроить приоритет, но по дефолту система на это не заточена.
Разработка софта под такие системы требует определенного скила, но зато можно получить максимальную отзывчивость и надежность, плюс можно гарантировать срок выполнения задачи)
Операционные системы реального времени.
Обычно применяются в машинах или IOT. В чем отличие от обычных систем?
Там хорошая система приоритезации процессов и в целом работы с ними. Например если в систему пришел сигнал с определенного датчика важного то отработка это сигнала может выместить все остальные процессы и выполнится в первую очередь. Либо сразу после текущего выполнения, либо текущий поставится на паузу.
Это сильно отличается от классических систем, где все процессы по дефолту равноправны и выполняются паралельно либо последовательно. Там конечно можно настроить приоритет, но по дефолту система на это не заточена.
Разработка софта под такие системы требует определенного скила, но зато можно получить максимальную отзывчивость и надежность, плюс можно гарантировать срок выполнения задачи)
👍1
ROLE
Есть системы с перегруженной ролевой моделью. Тот же самый яндекс клауд.
Да, понятно, это дает гибкую систему доступов. Можно дать только те доступы которые точно нужны.
Но когда вас в команде 5 человек и всем нужно плюс минус одно и тоже, с небольшими отличиями, то такая ролевая модель становится очень проблематичной. Иногда поиск и доьавление нужных ролей может занять больше времени чем задача для которой нужны эти доступы.
Поэтому мне нравятся облака типа селектела, где минимум сложностей что бы получить доступ.
Есть системы с перегруженной ролевой моделью. Тот же самый яндекс клауд.
Да, понятно, это дает гибкую систему доступов. Можно дать только те доступы которые точно нужны.
Но когда вас в команде 5 человек и всем нужно плюс минус одно и тоже, с небольшими отличиями, то такая ролевая модель становится очень проблематичной. Иногда поиск и доьавление нужных ролей может занять больше времени чем задача для которой нужны эти доступы.
Поэтому мне нравятся облака типа селектела, где минимум сложностей что бы получить доступ.
👍1
VERSION
Даже идемпотентность настроенный сервер через декларативный манифест может отличатся от другого сервера настроенного точно так же.
Что бы получить два идентичных сервера нужно поднять их на одном и том же образе ОС и прогнать настройку прям в одновременно. Иначе мы не можем гарантировать что все версии зависимостей будут идентичны.
В конечном итоге может придти к тому что на одном из серверов начнуться ошибки которых нет на другом. Как сегодня у меня случилось, выкатили микросервис на стенд с более старой версией докера и получили ошибку, пришлось обновлять то той же версии что и на тесте)
Вывод наверно тут один, нельзя гарантировать что два сервера будут одинаковые если мы настраиваем их в разное время и на более свежем образе той же ОС)
Даже идемпотентность настроенный сервер через декларативный манифест может отличатся от другого сервера настроенного точно так же.
Что бы получить два идентичных сервера нужно поднять их на одном и том же образе ОС и прогнать настройку прям в одновременно. Иначе мы не можем гарантировать что все версии зависимостей будут идентичны.
В конечном итоге может придти к тому что на одном из серверов начнуться ошибки которых нет на другом. Как сегодня у меня случилось, выкатили микросервис на стенд с более старой версией докера и получили ошибку, пришлось обновлять то той же версии что и на тесте)
Вывод наверно тут один, нельзя гарантировать что два сервера будут одинаковые если мы настраиваем их в разное время и на более свежем образе той же ОС)
👍1
RELEASE
Есть асинхронные модели релизов.
Как это может выглядить:
Создается тег и проходят сборки. А система сама приходит к целевому состоянию. Там могут быть сложные схемы, например последовательность деплоя и сложные миграции.
То есть джоба деплоя просто тригерит старт релиза, и со временем система сама придет к актуальной версии. Для реализации таких схем часто используются gitops операторы, с описанной схемой деплоя в хельм чартах.
Иногда такие схемы удобнее, можно более прозрачно проводить сложные схемы и делать это более безопасно.
Я все еще не принимаю GitOps
Есть асинхронные модели релизов.
Как это может выглядить:
Создается тег и проходят сборки. А система сама приходит к целевому состоянию. Там могут быть сложные схемы, например последовательность деплоя и сложные миграции.
То есть джоба деплоя просто тригерит старт релиза, и со временем система сама придет к актуальной версии. Для реализации таких схем часто используются gitops операторы, с описанной схемой деплоя в хельм чартах.
Иногда такие схемы удобнее, можно более прозрачно проводить сложные схемы и делать это более безопасно.
👍1
Впервые решился на тест батареи мака на М процессоре
Сегодня весь день без подзарядки и в активной работе, осталось 35 процентов)
Сегодня весь день без подзарядки и в активной работе, осталось 35 процентов)
REVERT
Основная проблема откатов релизов - миграции.
Дело в том что после накатывания релизом сначала выполняются миграции которые меняют схему базы.
Но в дальнейшем, если релиз проблемный то просто откатом кода может не обойтись, так как старая версия может быть несовместимой с новой схемой. Основное решение тут - писать не ломающии миграции и тестировать откат релиза на тест стенде.
Ну и сами миграции, в момент исполнения, должны быть транзакционными. Что бы в момент их исполнения можно было быстро откатить при ошибке.
Основная проблема откатов релизов - миграции.
Дело в том что после накатывания релизом сначала выполняются миграции которые меняют схему базы.
Но в дальнейшем, если релиз проблемный то просто откатом кода может не обойтись, так как старая версия может быть несовместимой с новой схемой. Основное решение тут - писать не ломающии миграции и тестировать откат релиза на тест стенде.
Ну и сами миграции, в момент исполнения, должны быть транзакционными. Что бы в момент их исполнения можно было быстро откатить при ошибке.
👍1
LOCK
Для того что бы более менее застраховать себя от ломающих обновлений транзитивных зависимостей глубокого уровня есть lock файлы.
Обычно все эти вложенные зависимости скачиваются из соответствующих репозиториев языка. Мы можем разово все собрать, проверить что все работает как надо, и зафиксировать вообще все в lock файле. И тогда при следующей установке мы точно получим все те же версии зависимостей что и при рабочей сборке.
В чем отличие от обычного файлы с списком зависимостей? Например requirements.txt в питоне. В том что в нем описываются верхнеуровневые пакеты, которые под собой могут тянуть другие пакеты не явным образом. А вот lock файл как раз фиксирует версии всех этих не явных пакетов.
Для того что бы более менее застраховать себя от ломающих обновлений транзитивных зависимостей глубокого уровня есть lock файлы.
Обычно все эти вложенные зависимости скачиваются из соответствующих репозиториев языка. Мы можем разово все собрать, проверить что все работает как надо, и зафиксировать вообще все в lock файле. И тогда при следующей установке мы точно получим все те же версии зависимостей что и при рабочей сборке.
В чем отличие от обычного файлы с списком зависимостей? Например requirements.txt в питоне. В том что в нем описываются верхнеуровневые пакеты, которые под собой могут тянуть другие пакеты не явным образом. А вот lock файл как раз фиксирует версии всех этих не явных пакетов.
👍1
REINSTALL
Иногда легче собрать новую инфру чем переделывать текущую.
Стратегия тут может быть такой:
- Поднимаем нормальную дев инфру
- Настраиваем релизный процесс туда
- Тестируем
- Если все окей поднимаем такую же прод инфру, но с старой бд
- Релизимся
- Тестируем
- Переключаем домен на новый прод
Получится максимально бесшовный процесс, когда пользователи даже не заметят изменений. По необходимости можем настроить миграцию бд на новый сервер, в релизное окно или бесшовно)
Иногда легче собрать новую инфру чем переделывать текущую.
Стратегия тут может быть такой:
- Поднимаем нормальную дев инфру
- Настраиваем релизный процесс туда
- Тестируем
- Если все окей поднимаем такую же прод инфру, но с старой бд
- Релизимся
- Тестируем
- Переключаем домен на новый прод
Получится максимально бесшовный процесс, когда пользователи даже не заметят изменений. По необходимости можем настроить миграцию бд на новый сервер, в релизное окно или бесшовно)
👍1