Мы использовали Google App Engine (GAE) для создания и поддержки некоторых одноразовых проектов. По мере роста интенсивности использования GAE возникла необходимость перехода к среде AWS, в которой доступен более высокий уровень контроля.
В качестве примера подобного перехода можно привести наш микросервис обработки изображений, который называется ImageBoss. Этот сервис позволяет по запросу изменять размеры изображений, обрезать их. В результате вашим художникам не придется создавать слишком много вариантов каждого графического объекта. Первоначально этот микросервис был развернут на платформе GAE. При этом одновременно на каждом узле для Go было доступно лишь одно ядро. В результате были очень высоки эксплуатационные расходы. После перемещения этого сервиса на платформу AWS была получена оптимально настроенная среда приложения.
Хотя услуги AWS обходятся дороже услуг других облачных провайдеров, взамен пользователи получат отличный набор инструментальных средств. На вопрос о стоимости выполнения анализа с помощью AWS Гросс сказал следующее:
Если нам нужно будет перейти от AWS к другому провайдеру, нам придется найти замены для управляемых услуг, таких как SQS или DynamoDB. Затраты на выполнение подобных замен наверняка превысят возможную выгоду. К тому же наша рабочая нагрузка идеально вписывается в почасовую модель ценообразования AWS. В этом случае мы будем регулярно масштабировать узлы в течение рабочего дня. Это позволит обоснованно прогнозировать возникающие требования и в случае необходимости выполнять масштабирование при небольших затратах.
К тому же затраты на поддержание платформы AWS намного меньше, чем затраты на поддержку CDN (большие затраты связаны с большим объемом видеоданных, передаваемых каждый месяц) и зарплаты инженеров. Небольшая оптимизация расходов в случае перехода к другому провайдеру нивелируется резким ростом трудозатрат со стороны инженерного персонала.
При рассмотрении существующих технологий, используемых в процессах выбора инструментов, задайте себе следующие вопросы.
• Какие средства абсолютно необходимы, а какие – желательны?
• Какие решения доступны прямо сейчас, а какие могут стать доступными в ближайшее время?
• Каким образом затраты на внедрение необходимых вам средств соотносятся с затратами на внедрение доступных средств?
Непрерывное влияние новых технологий
По мере развития технологий и появления новых инструментов в экосистеме могут возникать затруднения в процессе принятия решений в пользу того или иного инструмента. В случае небольшой компании, выполняющей большие объемы незапланированных работ и имеющей постоянные технические долги, важно в первую очередь реализовывать наиболее важные проекты.
Гросс описал несколько проблем, с которыми столкнулась его команда в октябре 2013 года.
• Как правило, Django применялось для выполнения медленного неатомического развертывания со сложными сбоями. Приложение Django являлось одним из важнейших приложений пути запроса, которое имело серьезные требования к доступности и времени ожидания. Из-за использования клона git замедлялось развертывание, к тому же в процессе развертывания периодически случались сбои.
• Увеличение степени сложности развертывания. Новые приложения Go не могут быть развернуты при использовании существующих процессов. Для двоичных модулей и интерпретированного исходного кода имели место разные требования к поставке.
• Раздельное тестирование качества и процессов развертывания производства без каких-либо возможностей аудита.
• Различные среды разработки и непрерывной интеграции.
Гросс также описал дополнительные цели, которые преследовала его команда:
• переход от монолитного приложения к меньшим по размерам микросервисам;
• изоляция разных версий приложения на одном хосте в средах разработки и контроля качества.
Как говорит Гросс:
Эксплуатационная команда (состоящая из двух человек на то время) оценила несколько вариантов, основываясь на разных преимуществах, таких как подгонка процесса решения проблем, наш опыт работы с языком реализации, известные виды отказов и т. п. В результате был выбран Docker. Этот выбор был основан на перспективах использования обобщенного интерфейса развертывания, который позволил бы решить все проблемы.
Большой риск заключался в том, что в те времена Docker был весьма сырым проектом (в октябре 2013 года, версия 0.6). К тому же мы не развертывали в производственной среде проекты, не подготовленные к использованию в производстве. Мы знали, что в случае возникновения каких-либо проблем можем всегда вернуться к более зрелой базовой LXC-системе. Эту ситуацию мы изложили руководству команды разработчиков, чтобы получить «добро» на продолжение работы.
После выполнения испытаний в среде разработки/контроля качества мы развернули Docker для производства основного приложения Django. Только после завершения тестирования мы можем перейти к контейнеризации остальных приложений.
Как и в случае с любым другим внедрением технологии, возникают дополнительные проблемы, которые должны быть разрешены. Зачастую интеграция результатов работы в среде непрерывной интеграции (CI) осуществляется с помощью автоматизации. Каждое действие по интеграции верифицируется с помощью автоматизированного процесса, который создает и тестирует обязательный код. В результате ускоряется обнаружение ошибок. Как правило, это достигается путем развертывания среды и тестирования кода с последующим разрушением среды.
В среде CI часто возникали проблемы, связанные с дисками. Зачастую причина появления этих проблем заключалась в повышенной вибрации. Для устранения этой проблемы был заменен драйвер хранилища Docker (эта задача довольно сложная). Также возникали проблемы, связанные с масштабированием реестра Docker. Чтобы устранить технологические проблемы, связанные с реестром, выполнялось развертывание локального реестра хоста, при поддержке AWS S3 (вместо использования центрального сервера).
Третья проблемная область появилась после развертывания Docker в локальной среде разработки. По этому поводу Гросс сказал:
В случае выбора платформы AWS эксплуатация осуществлялась без особых проблем. Но мне не удалось найти хорошее решение, пригодное для выполнения Docker на локальной платформе. К тому же команда разработчиков была очень занята внедрением новых средств и не могла выделить время на изучение новой технологии. Когда мы развернули boot2docker в качестве варианта локальной среды разработки, у нас возникла серьезная «дыра» в обучении, которая сохранялась дольше, чем мы бы хотели, и привела к появлению серьезных внутренних трений. Это был хороший урок для нас, суть которого заключалась в том, что новые изменения должны вноситься в инфраструктуру при более непосредственном участии со стороны команды разработчиков.
Процесс тщательного отбора и оценки имеет значение как для новой, так и для существующей технологии. В случае новой технологии (новой вообще или новой для вашей организации) задайте себе следующие вопросы:
• Каковы известные риски новой технологии?
• С какими неизвестными моментами вы можете столкнуться?
• Какие проблемы невозможно решить в рамках существующей технологии?
Расширенное внедрение практик формирования близости
Безупречный постмортем (https://codeascraft.com/2012/05/22/blameless-postmortems/) с целью формирования культуры непрерывного улучшения.
– @0x74696d at @dramafeverМне очень приятно, когда @0x74696d ссылается на @codeascraft в дискуссии, посвященной трактовке сбоев со стороны @dramafever. Спасибо за помощь в обучении, Etsy!
– Bridget Kromhout (@bridgetkromhout)Эти твиты, написанные в феврале 2015 года, иллюстрируют нарастающую тенденцию формирования близости между компаниями, достигаемую посредством обмена знаниями. Кромхаут заявила, что DramaFever адаптировала
