Оптимизация Docker-образов с помощью dive

Недавно прогнал наш dev-образ через утилиту dive
Судя по результатам, надо образ на диету садить)

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

Так я увидел что примерно половина образа это различные системные библиотеки в /usr/bin/lib, например zsh занимает 205МБ

Большой размер образа приводит к тому, что место в registry быстро забивается, кэш слоев хуже переиспользуется, долго пулится в CI/CD

Как можно исправить ситуацию?

- Видно, что в разделе Potential wasted space указано 75 МБ, скорее всего остались артефакты apt, которые можно удалить

- Можно использовать multistage, что чуть улучшит кэширование, и мастхев для продовых образов

🚀 Пост Guru PHP: @msavin_dev

Закон протекающих абстракций и почему он портит вам tail latency

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

Tail latency — это когда запрос, обычно делающийся за 200 ms, внезапно занимает 2 s. Такое поведение ухудшает пользовательский опыт - пользователь может не дождаться и уйти. В распределённой системе эффект еще и усиливается: один затупивший вызов тянет за собой всю цепочку

Почему появляются такие задержки? Сеть потеряла пакет, TCP ушёл в backoff, DNS задумался, GC начал собирать мусор не вовремя, прокси сделал лишний ретрай. В обычном коде всё выглядит гладко, но под нагрузкой эти мелочи превращаются в p95/p99 latency

Как бороться с tail latency? Есть ряд паттернов:
- хеджированные запросы - отправляем запрос на несколько нод сразу, и берем ответ от первого
- request coalescing - одинаковый запросы "склеиваем" в один, чтоб не грузить нижние слои системы
- deadline propagation - каждый участок запроса знает сколько у него осталось времени на выполнение
- circuit breakers - если модуль стал отдавать много ошибок, можно отрезать часть запросов от него, чтоб дать ему восстановиться
- latency-aware load balancing - раскидывать нагрузку не round-robin'ом, а в зависимости от состояния нод

Каждый паттерн — отдельная история, но вместе они сильно уменьшают хвосты.

🚀 Пост Guru PHP: @msavin_dev

Blue-Green Deployment

Blue-green — это способ выкатывать новую версию без простоя и практически с мгновенным откатом на старую версию если что-то пошло не так

У вас есть два окружения — blue (текущий прод) и green (новая версия).
Вы обновляете green, прогоняете smoke-тесты, а потом просто переключаете трафик на него.
Переключение обычно занимает миллисекунды — достаточно указать load balancer’у новый бэкенд.
При этом мы имеем такую же простую возможность отката, если что-то все таки пошло не так - переключаем трафик на blue и спокойно правим green

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

Blue-green не решает все проблемы, но снимает главный страх релизов:
“если что-то поломается, мы вернём всё назад за секунду”.

🚀 Пост Guru PHP: @msavin_dev

Scale Cube: 3 способа масштабироваться

Когда система перестаёт держать нагрузку, приходит время масштабироваться
Обычно делают так:

- добавили инстансы → стало не лучше
- распилили на микросервисы → стало хуже

Scale Cube модель предлагает 3 оси. Каждая закрывает свой bottleneck:

X - клонирование
Больше одинаковых копий сервиса за балансером.
Помогает, когда упираетесь в CPU/IO на приложении.

Y - разделение ответственности
Делите по функциям: поиск, отчёты, платежи.
Нужно, когда одна часть системы “убивает” остальных и её надо изолировать/масштабировать отдельно.

Z - разделение по данным (sharding/partitioning)
Делите данные по ключу (user_id, region).
Применяется когда потолок - данные: одна БД/таблица, hot keys, локи. Запись и чтение можно масштабировать отдельно

Например, если узкое место - база, то:

- X почти не поможет (вы просто сильнее нагрузите БД)
- микросервисы чаще ухудшат (больше запросов + распределённые транзакции/консистентность)
- а вот Z может дать рост capacity

Выбирать ось надо по bottleneck’у.
Если вы не можете назвать узкое место цифрами - вы не масштабируете, а только усложняете систему.

🚀 Пост Guru PHP: @msavin_dev