Всем привет!

Как можно масштабировать нагрузку в облаке? Под облаком я понимаю k8s как некий стандарт.

1) "ручками". Простой, но не надежный способ. Отягощающий фактор - не всегда у сопровождения ПРОМ есть права на смену настроек Deployment, тогда требуется отдельный деплой

2) выставить число подов и limits, соответствующими максимальной нагрузке. Еще проще, но совсем не рационально в плане использования ресурсов

3) HorizontalPodAutoscaler https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/ Позволяет менять число подов сервиса при превышении некого порога нагрузки по cpu и memory. Порог - это не процент использования, а соотношения заданного requests с текущим значением. Подходит если требуемая нагрузка может превышать возможности 1 пода, и если сервис поддерживает горизонтальное масштабирование - т.е. stateless.

4) VerticalPodAutoscaler https://habr.com/ru/companies/flant/articles/541642/ Как следует из название - масштабирует поды вертикально. Тут есть нюанс - на данный момент k8s не позволяет менять requests и limits у пода "на ходу". Данная фича называется In-Place Update of Pod Resources и пока находится в бета-версии https://github.com/kubernetes/enhancements/issues/1287
Сейчас VerticalPodAutoscaler может следующее:
а) на основе истории использования подом ресурсов рассчитать и выдать рекомендуемые значения
б) применить эти значения при очередном плановом рестарте
в) самому рестартовать под
Подходит для следующих случаев:
а) statefull сервисы типа хранилища данных в облаке StatefullSet, для которых горизонтальное масштабирование или невозможно, или не приветствуется
б) "легкие" сервисы, которым достаточно одной реплики (или двух по требованиям надежности)
Из особенностей - не гарантируется корректная работа совместно с HorizontalPodAutoscaler по одним и тем же метрикам cpu и memory. И не работает с Java приложениями в плане нагрузки по памяти, т.к. Java сама управляет памятью, а VerticalPodAutoscaler эти данные не видит.
Ну и главный минус - необходимость рестарта для применения настроек

5) как избавиться от необходимости рестарта? Дождаться полноценного внедрения In-Place Update of Pod Resources и доработки VerticalPodAutoscaler. Или использовать бета-версию In-Place Update of Pod Resources реализовать соответствующий k8s controller самому. Это уже сделано: https://piotrminkowski.com/2023/08/22/resize-cpu-limit-to-speed-up-java-startup-on-kubernetes/
Данная реализация не умеет сама рассчитывать рекомендуемые значения requests. Зато позволяет красиво проблему JVM приложений, о которой я уже писал ранее - проблему долгого старта. Java, а точнее Spring приложение, при старте производит достаточно ресурсоемкую настройку контекста. Речь идет про обычный Spring Boot без применения всех возможных способов ускорить запуск. Если память после первоначальной настройки так и остается занятой созданными бинами, то cpu при старте требуется сильно больше, чем при обычной работе. Что с этим делать?
а) Не выделять лишние cpu - время старта увеличивается в разы
б) Пойти по пути, описанному в п.2 - выдать максимум ресурсов. Тогда может получиться, что мы тратим cpu на быстрый старт приложения, а далее ресурсы не утилизируются
в) In-Place Update of Pod Resources
Конкретно по данной реализации - мне она кажется не идеальной, т.к. ресурс по cpu настраивается в 2 манифестах, это не наглядно и способствует внесению несогласованных правок. Но решение в целом - полезное.

#k8s #cloud #scalability

Всем привет!

Случайно наткнулся на старую статью - 2015 год - про переход с legacy на Service Oriented Architecture ака SOA.
И хочу сказать, что это хороший пример развития истории по спирали)

Что в статье актуально?
Заменяем слово SOA на микросервисы, и в целом все, что касается преимуществ микросервисной архитектуры и стратегии перехода на нее - актуально. Микросервисы = SOA 2.0 )))

REST оставляем, SOAP+XML заменяем на gRPC\GraphQL для тех случаев, когда требуется большая производительность и гибкость соответственно по сравнению с REST. К слову, недостаток производительности и гибкости - это основные проблемы SOAP. Ремарка - знаю места, где SOAP еще жив (интеграция с госорганами), но он в любом случае вымирает.

ESB, трудности реализации асинхронного взаимодействия - все эти задачи взяла на себя Kafka. Прорывной инструмент - быстрый, надежный (обеспечивает дешевую персистентность), opensource, простой с точки зрения разработчика. В т.ч. потому, что нет необходимости разрабатывать логику маппинга сообщений на брокере. Да, он реализует только одну из двух основных моделей асинхронного взаимодействия - Publisher-Subscriber - и не реализует Message Queue. Но понятно, что топиками можно пользоваться как заменой очередей, и в большинстве случаев проблем при этом не будет.

Облачные решения - за 10 лет из вызова превратились в новую реальность)

А вызов сейчас - внедрение AI. Как-то так)

#microservices #ai #cloud #kafka #rest

Нужны ли sidecar?

Напомню, sidecar - это паттерн распределенных систем. Суть - есть 2+ контейнера. Один главный — контейнер собственно сервиса, содержит основную логику. Второй - "прицепной" (это дословный перевод sidecar) контейнер. Его роль - дополнить и улучшить контейнер сервиса. Причем часто основной сервис даже не предполагает о его существовании. Удобно для прозрачного навешивания нового функционала. Примеры: добавление Service Mesh, логирования, шифрования, работа с секретами...

У себя в компании я наблюдаю тренд по отказу от sidecar.

Почему?
У нас микросервисы. Мы не делаем их большими, требования к ресурсам стараемся оптимизировать - получаем реалистичные бизнес-требования, проводим НТ, устанавливаем requests и limits. Так по крайней мере должно быть)
Но что получается в итоге?
Предположим у нас service mesh. Предположим есть требование безы - весь входящий и исходящий трафик идет через ingress\egress. Это уже минимум +3 контейнера envoy proxy со своими limits. Если один контейнер сервиса = один envoy proxy, + ingress + egress.
А если каждый из них нужно "обмазать" sidecar для шифрования. А еще для хранения секретов. А еще для логирования. И еще какие-то требования платформы.
Итого я видел кейсы, когда на один контейнер простого бизнесового сервиса в namespace было 7 или 8 служебных контейнеров. И даже если каждый из них потребляет меньше ресурсов, чем бизнес сервис - в итоге мы получаем х3 накладных расходов по ресурсам. Грустно(
Проблема на самом деле не только в контейнерах - любые служебные pod в namespace тоже вносят свой вклад.

Как же решается проблема?
Путей несколько:
1) часть функционала можно встроить в сам приклад. Если в прикладе уже есть клиентский модуль сервиса X и его все равно надо периодически обновлять с пересборкой - сделать этот клиентский модуль чуть толще вполне себе можно.
2) у k8s есть такая штука как операторы. Это сервис, работающий где-то рядом с ядром k8s, который может отслеживать изменения конфигурации в любом namespace и по этому событию делать что-то полезное. Например, по наличию определенной аннотации у пода подгружать для него секреты. Или собирать метрики с пода, опрашивая url Prometheus, построенный по определенному шаблону. Или настраивать Rate Limiter на envoy proxy при его старте. Оператор можно создать самому, это по сути plugin для k8s
3) если продолжить мысль из предыдущего пункта - по такому же сценарию можно поступить и с Istio proxy (он же envoy). Встречайте - Ambient Mesh. Вот статья про технологию https://habr.com/ru/articles/807117/, а вот как это внедряется в Сбере https://yandex.ru/video/preview/3928252140575819915 Все прокси не исчезают, трафик в облаке большой, оператор не может маршрутизировать его сам. Но прокси создаются на каждой node, а не на каждом контейнере. Требования к ресурсам у них будут побольше, но все равно получаем экономию по ресурсам в разы.

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

#k8s #cloud #optimization

Можно ли засунуть PostgreSQL в облако?

Когда мы говорим о БД в облаке - обычно говорят о специально созданных для облака noSQL хранилищах.
Как пример можно привести YaDB и Amazon DynamoDB.
Их главные плюсы:
1) managed storage - администрирование идет в комплекте с облаком, неотъемлемая фича облака
2) возможность горизонтального масштабирования
Значит ли это, что старые добрые реляционные БД не попадут в облако и станутся в прошлом?
Нет.

На самом деле я уже об этом писал - https://t.me/javaKotlinDevOps/257
Существуют Azure Cosmos DB for PostgreSQL и Aurora PostgreSQL.
Это проприетарные решения под конкретное облако.

В связи с этим возникает два вопроса:
1) есть ли opensource решения?
2) как вообще удалось затащить PostgreSQL в облако?

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

Собственно хранилище - объектная файловая система, совместимая с S3 API - в любом облаке есть.
Это storage уровень. У него малая нагрузка на процессор, но большая I/O нагрузка на дисковую систему.

Еще у БД есть движок, рассчитывающий планы выполнения запросов и собственно их выполняющий. Это compute часть. Ей в теории хранилище вообще не нужно, а нужны CPU и RAM.
Т.е. compute часть является stateless, а этом значит ее можно быстро масштабировать с 0 до бесконечности. Ну не бесконечности конечно, а до свободного объема кластера. Учитывая, что тот же PostgreSQL написан на C - подыматься без данных он должен быстро.

Собственно, остается вопрос - позволяет ли PostgreSQL разделять compute и storage? И исходя из предыдущей информации - да, позволяет.
Например, есть https://www.orioledb.com/ Это storage движок для PostgreSQL, исправляющий несколько косяков в базовой архитектуре PostgreSQL в реализации MVCC (многоверсионности). Но это еще не облачное решение, оно позволяет эффективнее использовать ресурсы конкретного сервера. compute и storage все еще на одном сервере.

Но если как compute оставить движок PostgreSQL, а storage разнести по разным серверам(кластерам, зонам доступности) - мы получим облачное решение.

Самый известный opensource вариант - Neon, вот хорошая статья о нем:
https://habr.com/ru/companies/arenadata/articles/927464/
Если всмотреться в архитектуру https://habrastorage.org/r/w1560/getpro/habr/upload_files/30f/688/639/30f688639ad82b12c41b3c7928529d0a.jpg
то там все чуть сложнее, чем я описал выше.

А именно: storage слой - это не просто объектное хранилище S3.
Есть еще два уровня: safekeepers и pageservers.
Чтобы понять, зачем они нужны, следует вспомнить, что PostgreSQL хранит данные дважды:
1) в виде страниц (pages) на диске - слепок текущего состояния
2) и write-ahead logging (WAL) - append-only лог изменений, по которому восстановить состояние БД в любой момент времени.

safekeepers принимают WAL лог от compute node и сохраняют его на нескольких узлах (SSD диски) с соблюдением кворума, т.е. гарантий отказоустойчивости https://neon.com/blog/paxos.
Если safekeeper падает - запросы перенаправляются на другой узел. Но число safekeeper фиксированное, но благодаря кворуму падение какой-то части узлов система выдержит.

pageservers - получают WAL лог от safekeeper и преобразуют его в формат страниц PostgreSQL. После чего сохраняют все это - WAL и страницы с данными - в S3. pageservers тоже имеют SSD диски и являются кэширующим слоем перед S3. При падении конкретного pageserver - трафик переключается на резервный с некой задержкой.

Итого мы имеем:
1) "бесконечное" масштабирование объектного хранилища S3
2) ограниченное размером кластера масштабирование compute nodes
3) фиксированное число safekeepers и pageservers, что не является узким звеном в первом приближении, но требует понимания целевой нагрузки на чтение и запись.

Итого: традиционные СУБД не сдаются) Победит сильнейший)

#rdbms #cloud #nosql

Вдогонку про storage движки PostgreSQL

Во-первых - если говорить о классических СУБД, то storage движки - тема не новая, можно вспомнить MySQL, который исторически имел несколько движков. InnoDB - самый известный, а вот полный список из официальной поставки:
https://dev.mysql.com/doc/refman/8.4/en/storage-engines.html
Из интересного:
blackhole - ничего не сохраняет
csv - сохраняет понятно куда)
memory - аналогично)
federated - удаленные сервера, горизонтальное масштабирование, но похоже с рядом ограничений (не копал глубоко).
Плюс есть реализации от внешних поставщиков.

Во-вторых, возможность создания storage движков в PostgreSQL дает следующая фича - Table Access Method (TAM) Interface https://www.postgresql.org/docs/current/tableam.html
Это слой абстракции между storage и compute при работе с таблицами. И расширение PostgreSQL может переопределить метод. Например, для реализации принципиально другого способа хранения записей таблицы и конкурентной модификации данных (MVCC). Или реализации шардирования. Или сжатия данных.

Тут стоит упомянуть, что есть похожая технология Foreign Data Wrapper (FDW).
Это реализация стандарта SQL/MED, позволяющая подключать к PostgreSQL внешние удаленные хранилища и, соответственно, выполнять к ним SQL запросы. Т.е. дать унифицированный SQL API для внутренних и внешних таблиц.
Тут детали https://www.percona.com/blog/foreign-data-wrappers-postgresql-postgres_fdw/
В отличие от Table Access Method Interface данная технология сделана для подключения внешних источников данных, в то время как для TAM подразумевает внутреннее хранение. Или локально, или в случае cloud native - использование пусть и облачного, но своего хранилища.

Соответственно, полноценные storage движки - это движки, меняющие ТАМ.
Вот какие бы я выделил:

1) Orioledb, уже упомянутый ранее - ускорение сохранения данных за счет другой реализации MVCC. Еще умеют сжимать данные и работают над cloud ready storage с разделением compute и storage. В последнем случае позиционируют себя как конкурент Neon, но еще неготовый к production https://www.orioledb.com/blog/orioledb-neon-differences#orioledb-1.
Кандидат на замену основного движка PostgreSQL, но команда PostgreSQL пока сопротивляется)
Если нужно больше информации - лучше, чем описано тут я описать не смогу) https://t.me/rybakalexey/240
Из важных особенностей - требует патча ядра PostgreSQL, что нарушает идею бесшовной замены движков

2) TimescaleDB - оптимизация под хранение временных рядов. Если обычные данные PostgreSQL хранятся построчно (row storage), то новый движок добавляет column storage. Конкурент для InfluxDB и Prometheus. Тут можно найти больше деталей https://deepwiki.com/timescale/timescaledb/12-hypercore-and-columnar-storage

3) Citus - горизонтальное масштабирование, но без разделения compute и storage, а путем возможности создания shared-nothing шард и распределенного выполнения запросов. Это дает возможность безопасно хранить данных для разных потребителей на разных шардах, но при этом иметь возможность выполнять аналитические запросы по всему объему данных. Подходит для SaaS систем.

Для справки - есть достаточно много реализаций Foreign Data Wrapper, предоставляющие доступ к файлам:
0) PostgreSQL - единственный FDW, входящий в поставку PostgreSQL. Эталонная реализация.
1) Oracle
2) MSSQL
3) MySQL
4) parquet (parquet - стандартный формат для Data Lake - аналитических БД, Hadoop, spark и вот это все)
...

Маленькое замечание - в отличие от технологии dblink в Oracle, FDW хранит метаданные удаленной таблицы внутри, что позволяет оптимизировать план выполнения запроса. Например, выполнять какую-то агрегацию на удаленном сервере. Или вытаскивать с удаленного сервера только необходимые данные. Это плюс. А минус тот же, что у dblink - ходить в чужую БД плохо, и противоречит микросервисной архитектуре.
Поэтому видится, что основной способ применения FDW - прототипирование, какие-то временные решения или миграции. Вот пример использования для миграции данных из Oracle в PostgreSQL https://habr.com/ru/companies/vtb/articles/819133/

#db #cloud #postgresql