Последние четыре года я занимался в стартапе руководством инфраструктурой, которая должна была быстро масштабироваться. С самого начала я принял фундаментальные решения, которых компании нужно было придерживаться несмотря ни на что все эти четыре года. В посте я перечислю некоторые из важных решений, принятых мной, расскажу, сожалею ли я о них, или одобряю.
AWS
▍ Выбор AWS вместо Google Cloud
? Одобряю
Изначально мы пользовались и GCP, и AWS. Всё это время я понятия не имел, кто мой «менеджер по аккаунту» Google Cloud, и в то же время мы регулярно проводили совещания с нашим менеджером по аккаунту AWS. Сложилось ощущение, что в Google всё построено на роботах и автоматизации, а Amazon делает упор на внимание к клиенту. Эта поддержка помогла нам при оценке целесообразности применения новых сервисов AWS. Наряду с поддержкой, AWS проделала отличную работу по повышению стабильности и минимизации изменений в API без обратной совместимости.
Когда-то Google Cloud был подходящим выбором для кластеров Kubernetes, особенно когда было не совсем понятно, будет ли AWS инвестировать в EKS вместо ECS. Однако сегодня благодаря дополнительным интеграциям Kubernetes с сервисами AWS (external-dns, external-secrets и так далее) проблем практически не возникает.
▍ EKS
? Одобряю
Если вы только не экономите каждый цент (и если ваше время не бесплатно), то нет никаких причин поддерживать собственную плоскость управления, а не использовать EKS. Основное преимущество использования альтернатив в AWS наподобие ECS — это глубокая интеграция в сервисы AWS. К счастью, поддержка Kubernetes тоже во многих отношениях улучшилась: например, использование external-dns для интеграции с Route53.
▍ EKS managed addons
? Сожалею
Мы начинали с EKS managed addons, потому что я подумал, что это «правильный» способ работы с EKS. К сожалению, мы всегда сталкивались с ситуацией, когда нужно настроить саму установку. Например, запросы CPU, теги образов или какую-нибудь configmap. С тех пор мы перешли на использование helm chart вместо аддонов, и всё стало работать намного лучше, система схожа с нашими готовыми конвейерами GitOps.
▍ RDS
? Одобряю
Данные — самая критичная часть инфраструктуры. Если вы потеряете сеть, то это приведёт лишь к даунтайму. Если потеряете данные, то можете потерять и компанию. Затраты на разметку при использовании RDS (или любой другой управляемой базы данных) оправдывают себя.
▍ Redis ElastiCache
? Одобряю
Redis хорошо работает и в качестве кэша, и как продукт в целом. Он быстр, его API простой и хорошо задокументирован, а реализация проверена временем. В отличие от других решений для кэширования наподобие Memcached Redis имеет множество функций, благодаря которым он полезен не только в кэшировании. Это отличный швейцарский армейский нож, позволяющий «быстро работать с данными».
Я не совсем понимаю, каково состояние Redis для поставщиков облачных услуг, но мне кажется, что он настолько широко используется клиентами AWS, что AWS продолжит качественно его поддерживать.
▍ ECR
? Одобряю
Изначально мы хостились на quay.io. У него была целая куча проблем со стабильностью. После перехода на ECR всё стало намного стабильнее. Также большим плюсом стали более глубокие интеграции разрешений с нодами EKS и серверами разработки.
▍ AWS VPN
? Одобряю
Существуют альтернативные решения Zero Trust VPN от компаний наподобие CloudFlare. Я уверен, что они хорошо работают, но AWS VPN крайне проста в настройке и понимании (я считаю, что «чем проще, тем лучше»). Для управления VPN-доступом мы пользуемся Okta, и это очень приятный опыт.
▍ Premium-поддержка AWS
? Сожалею
Она крайне дорога: стоит почти столько же (а то и больше), как затраты на ещё одного инженера. Я считаю, что если бы у нас в компании было мало знаний об AWS, то такая поддержка бы себя оправдала.
▍ Control Tower Account Factory для Terraform
? Одобряю
До интеграции AFT использование control tower вызывало много проблем, потому что его было очень сложно автоматизировать. Потом мы интегрировали в свой стек AFT и с тех пор запуск аккаунтов работает отлично. Кроме того, AFT упрощает стандартизацию тегов для аккаунтов. Например, наши продакшен-аккаунты имеют тег, который мы можем использовать для принятия решений о пиринге. Для нас теги подходят лучше, чем организации, потому что решение о том, какие свойства описывают аккаунт не всегда являются древовидной структурой.
Процесс
▍ Автоматизация процесса постмортемов при помощи Slack-бота
? Одобряю
У всех всегда много дел. Если ты напоминаешь людям, что нужно заполнить постмортем, то можешь почувствовать себя «плохим человеком». Поэтому пусть плохим парнем вместо вас будет робот. Это упрощает процесс, подталкивая людей следовать процедуре SEV и постмортема.
Поначалу он может быть не особо сложным. Достаточно простых «За час не было сообщений. Кому-нибудь нужно опубликовать обновление» или «Прошёл целый день, но не было ни одного приглашения в календаре. Кто-то должен запланировать совещание по постмортему», а затем развивать эту систему.
Использование шаблонов инцидентов PagerDuty
? Одобряю
Зачем заново изобретать велосипед? PagerDuty публикует шаблон того, что нужно делать во время инцидента. Мы немного настроили его (здесь нам на помощь пришла гибкость Notion), но это было хорошей отправной точкой.
▍ Регулярные ревью тикетов PagerDuty
? Одобряю
Алертинг в компании выглядит так:
- У нас нет алертов. Нам нужны алерты.
- У нас есть алерты. Их слишком много, так что мы их игнорируем.
- Мы расставили приоритеты алертов. Меня будят только самые критичные.
- Мы игнорируем все некритичные алерты.
У нас создана двухуровневая система алертов: критичные и некритичные. Критичные алерты будят людей. Некритичные алерты «пингуют» дежурную поддержку асинхронно (по электронной почте). Проблема в том, что некритичные алерты часто игнорируются. Чтобы разрешить эту проблему, у нас проводятся регулярные (обычно раз в две недели) совещания по ревью PagerDuty, где мы анализируем все алерты. В случае критичных алертов мы обсуждаем, должны ли они оставаться критичными. Затем мы рассматриваем каждый из некритичных алертов (обычно выбирая несколько на каждое совещание) и обсуждаем, как устранить и их (обычно настройкой пороговых значений или созданием автоматизации).
▍ Совещания по отслеживанию ежемесячных трат
? Одобряю
Ещё на ранних этапах я организовал ежемесячное совещание для рассмотрения всех наших затрат на SaaS (AWS, DataDog и так далее). Ранее мы рассматривали их только с точки зрения финансов, но в таком случае сложно отвечать на общие вопросы типа «разумна ли эта величина затрат?». Во время этих совещаний, которые обычно посещали и финансовый отдел, и отдел разработки, мы рассматривали каждый счёт, относящийся к ПО и логически рассуждали, кажутся ли эти затраты оправданными. Мы подробно углублялись в численные показатели каждого из больших счетов и пытались проанализировать их.
Например, в случае AWS мы группировали элементы по тегам и разделяли их по аккаунтам. Эти две размерности, а также общее имя сервиса (EC2, RDS и так далее) давали нам хорошее представление о том, от чего в основном зависят затраты. Кроме того, на основании этих данных мы углублялись в изучение использования конкретных spot instance или смотрели, какие аккаунты сильнее всего влияют на сетевые затраты. Но не стоит ограничиваться одной AWS: анализируйте все основные источники затрат компании.
▍ Работа с постмортемами в DataDog или PagerDuty
? Сожалею
Постмортемы должны делать все. И в DataDog, и в PagerDuty есть интеграции для написания постмортемов; мы попробовали каждую из них.
К сожалению, оба инструмента усложняют настройку процесса постмортемов. Учитывая удобство википодобных инструментов типа Notion, я считаю, для управления постмортемами лучше использовать такие инструменты.
▍ Не используем Function as a Service(FaaS) в большей степени
? Сожалею
Не существует высококачественных инструментов FaaS для управления рабочими нагрузками GPU, поэтому мы пока не можем пользоваться FaaS в полной мере. Однако многие рабочие нагрузки CPU могут быть FaaS (lambda и так далее). Самый серьёзный контраргумент против них — это затраты. Люди считают так: «Этот тип инстанса EC2, работающий 24/7 при полной нагрузке, намного дешевле, чем работающая Lambda». Это так, но в то же время сравнение ложное. Никто не исполняет сервис с загрузкой CPU на 100%. Всегда используется какой-нибудь алгоритм масштабирования, который говорит: «Никогда не достигай 100%. При 70% повышай масштаб. И всегда непонятно, когда следует снижать масштабирование; люди пользуются эвристиками типа „нагрузка была 10% в течение 10 минут, снижаем масштаб“».
Ещё одно неявное преимущество Lambda в том. что очень легко отслеживать затраты с высокой точностью. При развёртывании сервисов в Kubernetes затраты могут оказаться скрытыми за другими объектами каждого нода или другими сервисами, запущенными в том же ноде.
▍ GitOps
? Одобряю
Пока GitOps масштабировался вполне неплохо и мы используем его для многих частей нашей инфраструктуры, в частности, для сервисов, terraform и конфигурации. Основной недостаток заключается в том, что процессы, ориентированные на конвейер, дают чёткую картину: вот прямоугольник, означающий, что ты сделал коммит, а вот стрелки, идущие от прямоугольника к концу конвейера. При использовании GitOps нам пришлось вложиться в инструментарий, помогающий людям отвечать на вопросы типа «Я выполнил коммит, почему его пока не развернули?».
Тем не менее, гибкость GitOps стала огромным плюсом и я крайне рекомендую применять его в вашей компании.
▍ Приоритет эффективности команды выше, чем внешних потребностей
? Одобряю
Скорее всего, ваша компания продаёт не саму инфраструктуру, а другой продукт. Это накладывает на команду давление по выпуску фич, не позволяя масштабировать собственную рабочую нагрузку. Но как и в самолётах рекомендуют сначала надеть маску на себя, так и здесь нужно первым делом нужно обеспечить эффективность команды. За редкими исключениями, я никогда не сожалел о том, чтобы отдать приоритет времени на написание автоматизации или документации.
▍ Использование базы данных несколькими приложениями
? Сожалею
Как и в большинстве случаев технического долга, мы не принимали это решение, оно появилось естественным образом. Рано или поздно кто-то хочет, чтобы продукт делал что-то новое, поэтому создаёт новую таблицу. Это кажется нормальным, потому что теперь между двумя таблицами есть внешние ключи. Но поскольку всем владеет кто-то, и этот кто-то — строка в таблице, то внешние ключи появляются между всеми объектами в целом стеке.
Так как базу данных используют все, за ней не следит никто. У стартапов нет возможности воспользоваться роскошью DBA, поэтому всё, чем не владеет никто, владеет инфраструктура.
Самые серьёзные проблемы с базой данных общего пользования:
- В базе данных накапливается мусор и непонятно, можно ли его удалять.
- При возникновении проблем с производительностью инфраструктура (без глубокого знания продукта) должна отлаживать базу данных и определять, куда выполнять перенаправление
- Пользователи базы данных могут пушить плохой код, делающий плохие вещи с базой данных. Эти плохие вещи могут отправлять алерты через PagerDuty инфраструктурной команде (потому что она владеет базой данных). Плохо, когда приходится поднимать одну команду из-за проблем другой. Если приложение владеет базами данных, то первым делом за неё отвечает команда приложения.
Тем не менее, я не против стеков, стремящихся делить единую базу данных. Просто имейте в виду необходимые компромиссы и разработайте хорошую стратегию управления ими.
SaaS
▍ Неиспользование платформы идентификации с самого начала
? Сожалею
Поначалу я пользовался Google Workspace, применяя его для создания групп сотрудников, чтобы назначать им разрешения. Такой подход оказался недостаточно гибким. Оглядываясь назад, скажу, что я бы гораздо раньше выбрал Okta. Она работает очень хорошо, имеет интеграции практически со всем и решает множество проблем с комплаенсом/безопасностью. Изначально выберите решение для идентификации и пользуйтесь только теми поставщиками SaaS, которые имеют интеграцию с ним.
▍ Notion
? Одобряю
Любой компании нужно место для хранения документации. Notion оказалась отличным выбором и работала гораздо лучше тех инструментов, которые я использовал раньше (Wiki, Google Docs, Confluence и так далее). Концепция базы данных для упорядочивания страниц позволила мне создавать достаточно сложные организации страниц.
▍ Slack
? Одобряю
Слава богу, мне больше не нужно пользоваться HipChat. Slack — отличный инструмент коммуникации, но для снижения стресса и шума я рекомендую:
- Использовать треды для краткости общения.
- Не ждать, что люди будут сразу же отвечать на сообщения.
- Мотивировать отказываться от личных сообщений в пользу публичных каналов.
▍ Переход с JIRA на linear
? Одобряю
Между ними и сравнения нет. JIRA настолько раздута, что я даже волновался, что при её работе в ИИ-компании она обретёт сознание. Когда я пользуюсь Linear, то часто думаю «интересно, можно ли сделать X», пробую, и действительно получается!
▍ Неиспользование Terraform Cloud
? Никаких сожалений
Изначально я пытался провести миграцию нашего terraform в Terraform Cloud. Самый большой недостаток заключался в том, что я не мог обосновать затраты. С тех пор я перевёл нас на Atlantis, и он работает достаточно хорошо. На случаи, когда Atlantis не справляется, мы написали автоматизацию в наших конвейерах CI/CD, восполняющую эту нехватку.
▍ GitHub actions для CI/CD
? Одобряю (более-менее)
Мы, как и большинство компаний, хостим код на GitHub. Изначально мы пользовались CircleCI, но перешли для CI/CD на Github actions. Маркетплейс доступных действий велик, а синтаксис легко читается. Основной недостаток Github заключается в большой ограниченности поддержки рабочих процессов с самостоятельным хостингом. Для своих раннеров с самостоятельным хостингом в EKS мы пользуемся EKS и actions-runner-controller, но интеграция часто выдаёт баги (однако нет ничего, что нельзя было бы решить). Надеюсь, в будущем GitHub отнесётся к самостоятельному хостингу Kuberentes более серьёзно.
▍ Datadog
? Сожалею
Datadog — отличный продукт, но он дорог. Но не просто дорог: я опасаюсь, что его модель затрат особенно плоха для кластеров Kubernetes и компаний, занимающихся ИИ. Кластеры Kubernetes наиболее экономичны, когда вы можете включать и отключать множество нодов, а также использовать spot instance. Модель ценообразования Datadog зависит от количества имеющихся у вас инстансов, а это значит, что даже в случае, когда у нас одновременно есть не больше десяти инстансов, если мы включим и отключим 20 инстансов, то и заплатим за 20 инстансов. ИИ-компании активно задействуют GPU. В CPU-ноде могут быть десятки одновременно работающих сервисов, благодаря чему цена Datadog за нод распределяется по множеству сценариев использования, а GPU-нод обычно использует только один сервис, поэтому затраты Datadog на каждый сервис гораздо выше.
▍ PagerDuty
? Одобряю
PagerDuty — отличный продукт с хорошей ценой. Мы никогда не жалели о его использовании.
ПО
▍ Миграция схем при помощи Diff
? Одобряю (более-менее)
Каким бы образом вы ни реализовывали управление схемами, это сложная и пугающая задача. Данные важны, а миграция на плохую схему может привести их утере. Из всех пугающих способов решения этой сложной проблемы мне больше всего подошла идея checkin всей схемы в git с последующим использованием инструмента генерации SQL для синхронизации базы данных со схемой.
Ubuntu для серверов разработки
? Одобряю
Изначально я пытался сделать серверы разработки с той же базовой операционной системой, на которой работают наши ноды Kubernetes, думая, что это приблизит среду разработки к продакшену. Сейчас я могу сказать, что усилия того не стоили. Я доволен тем, что мы используем для серверов разработки Ubuntu. Это операционная система с хорошей поддержкой и в ней есть большинство нужных нам пакетов.
▍ AppSmith
? Одобряю
Нам часто нужно автоматизировать процессы для собственных инженеров компании: перезапуск/promotion/диагностика и так далее. Нам достаточно легко создать API для решения этих задач, но немного утомительно отлаживать чью-то конкретную установку CLI/ОС/зависимостей и так далее. Возможность создания простого UI, чтобы инженеры могли взаимодействовать с нашими скриптами, очень полезна.
Мы самостоятельно хостим AppSmith. Он работает… достаточно неплохо. Разумеется, кое-что приходится менять, но этого достаточно для бесплатного тарифа. Изначально я изучал возможность более глубокой интеграции с retool, но цена на тот момент себя не оправдывала, тогда было слишком мало интеграций.
▍ helm
? Одобряю
Helm v2 имел плохую репутацию (и на то были причины), но helm v3 работает вполне неплохо. По-прежнему есть проблемы с развёртыванием CRD и с объяснением разработчикам того, почему их helm chart не разворачивается корректно. Однако в целом helm хорошо работает как способ упаковывания и развёртывания версионированных объектов Kubernetes, а язык написания шаблонов Go сложен в отладке, но мощен.
▍ helm chart в ECR(oci)
? Одобряю
Изначально наши helm chart хостились внутри S3 и скачивались при помощи плагина. Основные недостатки этого заключались в необходимости специального плагина helm и ручном управлении жизненными циклами. С тех пор мы перешли на хранение helm chart в OCI и не имели никаких проблем с этой системой.
▍ bazel
? Непонятно
Честно говоря, многие умные люди любят bazel, так что уверен, это не особо плохой выбор.
Лично мне кажется, что при развёртывании сервисов на Go bazel оказывается слишком мощным. Думаю, Bazel — отличный выбор, если его использовали на предыдущем месте работы и вы испытываете ностальгию.
▍ Неиспользование open telemetry с самого начала
? Сожалею
Изначально мы отправляли метрики напрямую в DataDog при помощи его API. Из-за этого было очень сложно извлекать их.
Четыре года назад Open telemetry не была такой совершенной, но уже стала довольно качественной. Мне кажется, её телеметрия метрик по-прежнему достаточно сырая, но трассировка великолепна. Рекомендую использовать её с самого начала в любой компании.
▍ Выбор renovatebot вместо dependabot
? Одобряю
Хотел бы я, чтобы мы раньше задумались о том, чтобы обеспечивать актуальность зависимостей. Когда слишком оттягиваешь это, то версии оказываются слишком устаревшими, а процесс обновления становится длинным и неизбежно подверженным багам. Renovatebot имеет достаточную гибкость, чтобы подстроить его под свои нужды. Самый большой (и довольно серьёзный) его недостаток в том, что он ОЧЕНЬ сложен в настройке и отладке. Но, наверно, это лучший из всех плохих вариантов.
▍ Kubernetes
? Одобряю
Вам нужно что-то для хостинга длительно выполняемых сервисов. Kuberentes — популярный выбор, хорошо подошедший нам. Сообщество Kubernetes проделало отличную работу по интеграции сервисов AWS (например, балансировщиков нагрузок, DNS и так далее) в экосистему Kubernetes. Самый большой недостаток любой гибкой системы заключается в том. что её можно использовать множеством разных способов, а значит, и есть множество способов использовать её неправильно.
▍ Покупка собственных IP
? Одобряю
Если вы работаете с внешними партнёрами, то вам часто придётся публиковать для них белый список своих IP. К сожалению, в дальнейшем вы можете разработать другие системы, которым потребуются собственные IP. Покупка собственного блока IP — отличный способ избежать этого, благодаря передаче внешнему партнёру большого блока CIDR для белого списка.
▍ Выбор Flux для k8s GitOps
? Никаких сожалений
Изначально для работы с GitOps и Kubernetes мы выбирали между ArgoCD и Flux: я выбрал Flux (в то время v1). Это оказалось очень удачно. Сейчас мы пользуемся Flux 2. Единственный недостаток заключается в том, что нам пришлось создать собственный инструментарий, чтобы помогать людям понять состояние их развёртываний.
Я слышал много хорошего о ArgoCD, так что уверен, что это тоже безопасный выбор.
▍ Karpenter для управления нодами
? Одобряю
Если вы используете EKS (и не полностью на Fargate), то вам следует пользоваться Karpenter. Точка. Мы использовали другие системы автоматического масштабирования (autoscaler), в том числе стандартный Kubernetes autoscaler и SpotInst. Среди них всех Karpenter оказался самым надёжным и экономичным.
▍ Применение SealedSecrets для управления секретами k8s
? Сожалею
Изначально я думал отдать управление секретами чему-то в стиле GitOps. Два основных недостатка использования sealed-secrets:
- Разработчикам со слабым знанием инфраструктуры было сложнее создавать/обновлять секреты
- Мы потеряли все уже имевшиеся автоматизации AWS, которые применялись для ротации секретов (пример)
▍ Использование ExternalSecrets для управления секретами k8s
? Одобряю
ExternalSecrets очень хорошо подошёл для синхронизации секретов AWS -> Kubernetes. Процесс понятен для разработчиков и позволяет нам пользоваться terraform как способом для удобного создания/обновления секретов внутри AWS, а также для предоставления пользователям UI для создания/обновления секретов.
▍ Использование ExternalDNS для управления DNS
? Одобряю
ExternalDNS — отличный продукт. Он синхронизирует наши DNS-записи Kubernetes -> Route53 и за прошедшие четыре года создал очень мало проблем.
▍ Использование cert-manager для управления сертификатами SSL
? Одобряю
Очень понятен в настройке и работает без проблем. Крайне рекомендую его для создания собственных сертификатов Let’s Encrypt для Kubernetes. Единственный недостаток заключается в том, что иногда у нас бывают клиенты с древним технологическим стеком, не доверяющие Let’s Encrypt, и для них нам нужно покупать платный сертификат.
▍ Bottlerocket для EKS
? Сожалею
Наш кластер EKS раньше работал на Bottlerocket. Основной проблемой были частые сетевые неполадки CSI, а отладка образов bottlerocket оказалась гораздо сложнее, чем отладка стандартных EKS AMI. Применение оптимизированных под EKS AMI для наших нодов не создало нам никаких проблем, и при этом у нас по-прежнему оставался бэкдор для отладки самого узла при возникновении странных сетевых неполадок.
▍ Выбор Terraform вместо Cloudformation
? Одобряю
Любой компании следует использовать Infrastructure as Code. При работе с AWS два основных варианта — это Cloudformation и Terraform. Я пользовался обоими и не жалею, что выбрал Terraform. Его было проще расширять под других поставщиков SaaS (например, PagerDuty), синтаксис читается проще, чем у CloudFormation, и он не создал у нас никаких препятствий или замедлений.
▍ Неиспользование решений IaC с большим упором на код (Pulumi, CDK и так далее)
? Никаких сожалений
Terraform и CloudFormation — это файлы данных (HCL и YAML/JSON), описывающие вашу инфраструктуру, а решения наподобие Pulumi или CDK позволяют писать код, выполняющий то же самое. Разумеется, код — это мощь, но мне показалось, что ограничения HCL в Terraform — это благо, потому что они снижают сложность. Писать сложный Terraform, разумеется, возможно, просто этот процесс более очевиден.
Некоторые из этих решений, например, Pulumi, были придуманы много лет назад, когда у Terraform ещё не было многих современных функций. Новые версии Terraform интегрировали множество функций, которые можно использовать для снижения сложности. Мы выбрали промежуточный подход: генерацию базовых «скелетов» кода Terraform для тех частей, которые нужно абстрагировать.
▍ Неиспользование сетевого меша (istio/linkerd и так далее)
? Никаких сожалений
Сетевые меши очень хороши и многие умные люди хвалят их, поэтому я уверен, что это хорошая идея. К сожалению, я считаю, что компании недооценивают сложность систем. В целом я могу дать такой совет касательно инфраструктуры: чем меньше, тем лучше.
▍ Балансировщик нагрузок Nginx для EKS ingress
? Никаких сожалений
Nginx стар, стабилен и проверен временем.
homebrew для скриптов компании
? Одобряю
Скорее всего, вашей компании понадобится способ распространения скриптов и двоичных файлов, которыми будут пользоваться инженеры. Homebrew вполне неплохо с этим справляется для пользователей и Linux, и Mac.
Go для сервисов
? Одобряю
В Go легко разобраться новым инженерам и это в целом хороший выбор. Go должен быть языком по умолчанию для сервисов без использования GPU, основным узким местом которых является сетевой ввод-вывод.
Скидки, итоги розыгрышей и новости о спутнике RUVDS — в нашем Telegram-канале ?
