☁️ Облачные платформы

Короткий ответ Начинают с разбивки расходов по сервисам, регионам и тегам за период в инструменте биллинг-аналитики провайдера, сравнивают с предыдущим периодом, чтобы локализовать основной прирост, а затем проверяют этот конкретный компонент на предмет забытых/избыточных ресурсов, изменения конфигурации или аномального использования. Как это работает подробнее биллинговые инструменты провайдера позволяют группировать затраты по сервису, региону и тегу и смотреть динамику по дням, что быстро показывает, вырос ли счёт равномерно или из-за одного компонента. Пример кода Что использовать на практике Рекомендация. типичные находки — забытые тестовые ресурсы, не удалённые после эксперимента; переход с reserved на on-demand после истечения резервации; рост объёма логов/снапшотов без lifecycle-политики; баг, вызывающий аномальный автоскейлинг или retry storm. Проверка. после удаления/переноса в архивный класс найденного источника роста и настройки lifecycle-политики следующий счёт должен вернуться к ожидаемому уровн

Читать полностьюcloud-billing

Короткий ответ Возможные пути — вынести состояние из инстанса во внешнее хранилище (сессии в управляемый кэш/БД, файлы в общее хранилище), что позволяет масштабировать горизонтально как обычный stateless-сервис; либо, если переписать приложение в разумные сроки нельзя, использовать вертикальное масштабирование и/или sticky-сессии как временное паллиативное решение с явно осознанными ограничениями. Как это работает подробнее вынос состояния во внешний управляемый сервис устраняет привязку запроса к конкретному инстансу, после чего балансировщик может направлять запросы на любой здоровый инстанс, а группа авто-масштабирования — свободно добавлять/убирать инстансы; sticky-сессии закрепляют клиента за конкретным инстансом по cookie, что позволяет масштабироваться для новых клиентов, но не решает равномерность распределения нагрузки и усложняет graceful-замену инстансов. Пример кода Что использовать на практике Рекомендация. для относительно небольшого объёма изменений вынос состояния в управляемый кэш — быстрая и

Читать полностьюautoscaling

Короткий ответ Target tracking автоматически подбирает число инстансов, чтобы держать метрику около заданного целевого значения; step scaling меняет число инстансов ступенчато в зависимости от того, насколько метрика превысила порог; scheduled scaling заранее меняет ёмкость по расписанию независимо от текущей метрики. Как это работает подробнее target tracking использует управляющий алгоритм, который сам вычисляет, сколько инстансов добавить/убрать; step scaling требует вручную определить пороги и для каждого — конкретный шаг изменения; scheduled scaling просто меняет min/max/desired в заданное время. Пример кода Что использовать на практике Рекомендация. target tracking — разумный выбор по умолчанию для большинства веб-нагрузок с одной ключевой метрикой; step scaling применяют, когда нужна более тонкая реакция на разные уровни нагрузки; scheduled scaling используют для заранее известных предсказуемых паттернов. Проверка. при резком скачке CPU до 90% step scaling должен сразу добавить 5 инстансов, тогда как ч

Читать полностьюautoscaling

Короткий ответ Blue/green разворачивает полностью новую копию окружения параллельно со старой и переключает весь трафик разом после проверки, обеспечивая быстрый откат переключением обратно; canary постепенно направляет небольшую, растущую долю трафика на новую версию, позволяя обнаружить проблему на ограниченной части пользователей. Как это работает подробнее при blue/green обе версии полностью развёрнуты одновременно, а переключение происходит на уровне балансировщика/DNS практически мгновенно для всех пользователей сразу; при canary балансировщик направляет, например, 5% трафика на новую версию, постепенно увеличивая долю при отсутствии ошибок. Пример кода Что использовать на практике Рекомендация. blue/green проще реализовать и даёт быстрый полный откат, но не защищает от проблем, проявляющихся только под полной нагрузкой; canary лучше обнаруживает проблемы, зависящие от реальной продовой нагрузки, но требует более сложной маршрутизации по процентам и метрик для автоматического решения. Проверка. при обна

Читать полностьюblue-green

Короткий ответ Большинство облачных провайдеров берут плату за исходящий трафик из своей сети в интернет (а иногда и между регионами/зонами), тогда как входящий трафик обычно бесплатен; архитектура с большим объёмом исходящих данных может создавать существенную неочевидную статью расходов. Как это работает подробнее трафик внутри одной зоны доступности обычно бесплатен или минимален, между зонами одного региона — платный по невысокой ставке, за пределы облака в интернет — платный по более высокой ставке. Пример кода Что использовать на практике Рекомендация. для снижения расходов на egress используют CDN для раздачи статического контента, сжатие данных и размещение часто обменивающихся данными сервисов в одной зоне/регионе. Проверка. при анализе счёта за облако статья «Data Transfer» должна быть сопоставлена с архитектурной схемой, чтобы понять, какой компонент генерирует основной исходящий трафик. Подводные камни Риск. не замечать плату за трафик между AZ при проектировании «просто для надёжности» Риск. архи

Читать полностьюarchitecture

Короткий ответ Lifecycle-политика — набор правил, которые автоматически переносят объекты в более дешёвый класс хранения или удаляют их по истечении заданного времени, без ручного вмешательства; используется для снижения стоимости хранения редко используемых или устаревших данных. Как это работает подробнее правило задаёт условие (возраст объекта, префикс, тег) и действие (перевести в холодный класс или удалить); провайдер применяет правило автоматически в фоне по расписанию. Пример кода Что использовать на практике Рекомендация. логи и бэкапы часто переводят в холодное хранилище через 30–90 дней и удаляют через 1–2 года согласно требованиям хранения данных; важно заранее учитывать время и стоимость восстановления из архивного класса. Проверка. через 30 дней объекты под префиксом logs/ должны сменить класс хранения на архивный, что видно в выводе list-objects по полю StorageClass. Подводные камни Риск. переносить в архивный класс данные, которые нужно читать часто, резко увеличивая стоимость за счёт платы за

Читать полностьюcloud-storage

Короткий ответ Снапшот — точечный, обычно инкрементальный образ состояния блочного диска на момент времени; из снапшота можно создать новый диск и восстановить данные, но это резервная копия на уровне инфраструктуры, а не замена логического бэкапа приложения. Как это работает подробнее первый снапшот копирует все занятые блоки диска, последующие — только изменившиеся блоки, что экономит место и время; снапшот можно сделать по расписанию через политику автоматизации. Пример кода Что использовать на практике Рекомендация. снапшоты дисков БД делают консистентными, либо приостанавливая запись на короткое время, либо используя поддержку СУБД для flush перед снимком, иначе можно получить неконсистентные данные. Проверка. статус снапшота переходит из pending в completed, после чего из него можно создать новый том в той же или другой зоне доступности. Подводные камни Риск. считать снапшот полноценной заменой логическому бэкапу базы данных Риск. не проверять снапшоты восстановлением (непроверенный бэкап равносилен его

Читать полностьюbackup

Короткий ответ Read-реплика — асинхронная копия основной базы данных, доступная только для чтения, которая используется для горизонтального масштабирования нагрузки чтения; она не предназначена как основной механизм обеспечения высокой доступности. Как это работает подробнее изменения с primary реплицируются на read-реплику асинхронно, с задержкой (replication lag); приложение направляет запросы на чтение на реплику, а запросы на запись — только на primary. Пример кода Что использовать на практике Рекомендация. read-реплики добавляют, когда чтение становится узким местом; важно мониторить replication lag и проектировать приложение так, чтобы допускать eventual consistency для данных, прочитанных с реплики. Проверка. новая реплика появляется в статусе available, метрика ReplicaLag показывает задержку в секундах относительно primary. Подводные камни Риск. использовать read-реплику как резервную копию для аварийного переключения записи без понимания, что promotion — ручная или полуавтоматическая операция с прост

Читать полностьюmanaged-databases

Короткий ответ Security Group — виртуальный файрвол, привязанный к сетевому интерфейсу инстанса, который разрешает трафик по правилам (протокол, порт, источник); по умолчанию весь входящий трафик запрещён, и правила нужно добавлять явно. Как это работает подробнее правила обычно описываются как allow-list и применяются к конкретному ресурсу, а не ко всей подсети; большинство реализаций stateful — если разрешён входящий запрос, ответный трафик пропускается автоматически. Пример кода Что использовать на практике Рекомендация. открывают только нужные порты (например, 443) и ограничивают источник максимально узко (конкретный CIDR или другая security group) вместо 0.0.0.0/0 там, где это не требуется. Проверка. подключение по HTTPS снаружи работает, а SSH снаружи VPC получает отказ соединения (connection timed out). Подводные камни Риск. открывать порт 22/3389 всему интернету «для удобства отладки» Риск. создавать одну общую security group на все сервисы вместо разделения по ролям Риск. забывать закрыть временно от

Читать полностьюcloud-networking