Делай как вGoogle
 Скачать 5.77 Mb.
|
|
Итоги y Скорость — это командная победа: чтобы получить оптимальный рабочий процесс для большой команды, работающей с единой базой кода, необходимо использовать модульные архитектуры и почти непрерывную интеграцию. y Оценивайте изолированные изменения: добавляйте защитные флаги к любым функциям, чтобы иметь возможность изолировать проблемы на раннем этапе обновления. y Сделайте реальность эталоном: используйте приемы поэтапного внедрения, чтобы справиться с проблемой разнообразия устройств и широкого круга поль- зователей. Специализация версии для искусственной среды, не похожей на 508 Глава 24. Непрерывная поставка продакшен, может привести к появлению неприятных сюрпризов на поздних стадиях обновления. y Поставляйте только то, что используется: контролируйте стоимость и ценность любой существующей функции, чтобы знать, имеет ли она достаточную актуаль- ность и ценность для пользователей. y Сдвиг влево позволяет быстрее принимать обоснованные решения на более ран- них этапах обновления с помощью непрерывной интеграции и непрерывного развертывания. y Чем быстрее, тем безопаснее: поставляйте новые версии чаще и с небольшим количеством изменений, чтобы снизить риски каждого конкретного выпуска и минимизировать время выхода версии на рынок. ГЛАВА 25 Вычисления как услуга Автор: Онуфрий Войтащик Редактор: Лиза Кэри Я не пытаюсь понять компьютеры, я пытаюсь понять программы. Барбара Лисков После того как код будет написан, вам понадобится оборудование для его запуска. То есть вы должны будете купить или арендовать это оборудование. По сути, это и есть вычисления как услуга (CaaS, compute as a service), где под словом «вычисле- ния» подразумеваются вычислительные мощности, необходимые для фактического выполнения ваших программ. В этой главе мы расскажем, как простая идея «взять оборудование для выполнения кода» 1 отображается в жизнеспособную систему, которая будет масштабироваться по мере роста и развития организации. Глава получилась довольно длинной, потому что описывает сложную тему, и поэтому разделена на четыре раздела: y «Приручение вычислительной среды» описывает, как компания Google приручила вычислительную среду, и объясняет некоторые ключевые понятия CaaS. y «Написание ПО для управляемых вычислений» показывает, как решение для управляемых вычислений влияет на подходы к разработке ПО. Мы считаем, что подход «скот, а не домашние любимцы» (гибкое планирование) сыграл важней- шую роль в успехе Google и является необходимым инструментом в арсенале программистов. y «CaaS во времени и масштабе» более подробно рассматривает некоторые уроки, извлеченные компанией Google из применения разных вариантов вычислительной архитектуры, и их влияние на рост и развитие организации. 1 Оговорка: для некоторых приложений под «оборудованием для выполнения» подразуме- вается оборудование ваших клиентов (представьте, например, игру в упаковке, которую вы купили десять лет назад). Это совсем другая проблема, которая не рассматривается в этой главе. 510 Глава 25. Вычисления как услуга y Наконец, раздел «Выбор вычислительной услуги» предназначен в первую очередь для инженеров, которые будут принимать решение о выборе вычислительной услуги для своей организации. Приручение вычислительной среды Система Borg 1 , разработанная в Google для внутренних нужд, стала предшествен- ницей многих современных архитектур CaaS (таких, как Kubernetes или Mesos). Чтобы лучше понять, как ее отдельные аспекты отвечают потребностям растущей и развивающейся организации, мы проследим, как развивалась Borg и как инженеры Google приручали вычислительную среду. Автоматизация труда Представьте, что вы студент университета на рубеже веков. Чтобы развернуть новый код, вы должны переслать его по SFTP на одну из машин в компьютерной лабора- тории университета, выполнить вход на эту машину через SSH, скомпилировать и запустить его. Это решение подкупает своей простотой, но с течением времени и увеличением масштаба оно сталкивается со значительными проблемами. Однако поскольку с него начинаются многие проекты, часто организации создают процессы, представляющие упрощенную эволюцию этой системы, по крайней мере для неко- торых задач — количество машин увеличивается (вы используете SFTP и SSH для работы со многими из них), но основная технология остается неизменной. Например, в 2002 году Джефф Дин, один из старших инженеров Google, так охарактеризовал выполнение задач автоматической обработки данных в процессе подготовки к вы- пуску новой версии: [Выполнение задачи] — это логистический кошмар, отнимающий много времени. В настоящее время требуется получить список из 50+ машин, и на каждой из 50+ машин запустить процесс и следить за его выполнением. Отсутствует возможность автоматического переноса вычислений на другую машину, если одна из машин выйдет из строя, а мониторинг выполнения заданий осуществляется ситуатив- но <...> Кроме того, поскольку процессы могут мешать друг другу, существует сложный, реализованный человеком файл «регистрации» для ограничения ис- пользования мощности машин, что приводит к неоптимальному планированию и усилению конкуренции за использование ограниченных машинных ресурсов. Названные сложности стали одним из первых стимулов для Google направить усилия на приручение вычислительной среды. Они демонстрируют, как простое решение становится неудобным с увеличением масштаба. 1 Verma A., Pedrosa L., Korupolu M. R., Oppenheimer D., Tune E., Wilkes J. Large-scale cluster management at Google with Borg. EuroSys, Article No.: 18 (April 2015): 1–17. Приручение вычислительной среды 511 Простая автоматизация Организация может предпринять довольно простые шаги, чтобы немного ослабить проблемы выполнения задач. Процесс развертывания двоичного файла на каждой из 50+ машин и его запуск можно автоматизировать с помощью простого сценария командной оболочки или — если это должно быть многоразовое решение — с ис- пользованием более надежного инструмента, чтобы получить более простое сред- ство, которое будет выполнять развертывание параллельно (тем более что «50+» со временем наверняка увеличится). Мониторинг каждой машины тоже можно автоматизировать. Прежде всего инженер, ответственный за процесс мониторинга, должен иметь возможность своевременно узнавать о проблемах, возникающих на машинах. Показатели (например, «процесс активен» и «количество обработанных документов») он должен получать из процесса и записывать в общее хранилище или передавать в службу мониторинга, чтобы потом быстрее находить аномалии в процессе. Для этой цели можно использовать решения с открытым исходным кодом, такие как Graphana или Prometheus, позволяющие создавать панели мониторинга. Типичная последовательность действий при обнаружении аномалии: подключиться к машине по SSH, прервать процесс (если он продолжает выполняться) и запустить его снова. Это утомительно, и есть риск допустить ошибку (нужно убедиться, что подключение выполняется к нужной машине и прерывается нужный процесс), по- этому эти действия тоже желательно автоматизировать: y Вместо мониторинга сбоев вручную можно запустить программу-агент на машине, которая будет определять аномалии (например, «процесс не сообщал о работо- способности в течение последних 5 минут» или «процесс не обработал ни одного документа за последние 10 минут») и завершать процесс. y Чтобы избавиться от необходимости входить в систему для повторного запуска процесса после его аварийной остановки, можно заключить его запуск в простой сценарий оболочки while true; do run && break; done Эквивалент этой процедуры в облачном мире — определение политики автомати- ческого восстановления (уничтожение и повторное создание виртуальной машины или контейнера после того, как они не пройдут проверку работоспособности). Эти относительно простые улучшения решают часть проблем, упомянутых Джеффом Дином и описанных выше. Но ручное регулирование и автоматический перенос за- дания на новые машины требуют более сложных решений. Автоматизация планирования Следующий шаг — автоматизация распределения заданий между машинами. Для это- го нужна первая настоящая «услуга», которая в итоге вырастет в CaaS. То есть, чтобы автоматизировать планирование, нужна некая центральная служба, которая имеет полный список доступных машин и может по запросу выбрать незанятые машины и автоматически развернуть на них двоичный файл. Это избавлит от необходимости 512 Глава 25. Вычисления как услуга вручную поддерживать файл «регистрации» и делегировать эту работу компьюте- рам. Такая система сильно напоминает ранние архитектуры с разделением времени. Продолжением этой идеи является объединение планирования с реакцией на отказ. Сканируя журналы машин на наличие выражений, сигнализирующих о пробле- мах (например, массовых ошибках чтения с диска), можно выявить проблемные машины, сообщить (сотрудникам) о необходимости ремонта таких машин и одновре- менно исключить планирование каких-либо работ на этих машинах. Для избавления от рутинного труда можно сначала попробовать автоматически исправить проблемы, прежде чем привлекать к их устранению инженера, например перезагрузить машину в надежде, что проблема исчезнет, или запустить автоматическое сканирование диска. Последнее замечание в цитате Джеффа касается необходимости вручную переносить вычисления на другую машину, если машина, на которой они выполнялись до этого, вдруг сломается. Эта проблема имеет простое решение: поскольку уже существуют автоматизация планирования и возможность выявлять неработоспособные маши- ны, можно просто заставить планировщик выделить новую машину и запустить задание на ней. Сигнал к этому может исходить от демона мониторинга машины или отдельного процесса. Все эти улучшения напрямую связаны с растущим масштабом организации. Когда парк состоял из одной машины, SFTP и SSH были идеальными решениями, но в мас- штабе сотен или тысяч машин без автоматизации не обойтись. Цитата, с которой мы начали, взята из проектного документа 2002 года «Global WorkQueue» — раннего внутреннего решения по применению CaaS для некоторых рабочих нагрузок в Google. Контейнерная и многоарендная архитектура До сих пор мы неявно предполагали взаимно-однозначное соответствие между ма- шинами и программами, выполняющимися на них. Это очень неэффективно с точки зрения потребления вычислительных ресурсов (ОЗУ, ЦП): y Количество разных типов заданий (с разными требованиями к ресурсам) почти наверняка будет превышать количество типов машин (с разным объемом до- ступных ресурсов), поэтому для многих заданий придется использовать машины одного и того же типа (пригодного для выполнения заданий, самых требователь- ных к ресурсам). y Потребности в программных ресурсах со временем растут, а на развертывание новых машин требуется много времени. Если на приобретение новых, более круп- ных машин в организации уходят месяцы, то вы должны приобретать достаточно мощные машины, чтобы удовлетворить ожидаемый рост потребностей в ресурсах. Это приведет к напрасным расходам, потому что первое время мощности новых машин не используются полностью 1 1 Этот и следующий пункты не так актуальны, если ваша организация арендует машины у поставщика облачных услуг. Приручение вычислительной среды 513 y После поступления новых машин старые никуда не денутся (выбрасывать их, вероятно, будет слишком расточительно), поэтому вам придется управлять раз- нородным парком, плохо адаптирующимся к вашим потребностям. Естественное решение — определить для каждой программы ее требования к ресур- сам (ЦП, ОЗУ, дисковое пространство), а затем попросить планировщик подыскать для программы подходящий набор машин. Соседская собака лает в моем ОЗУ Решение, описанное выше, отлично работает, если все компоненты действуют сла- женно. Но если я укажу в конфигурации, что каждая программа в моем конвейере обработки данных потребляет один ЦП и 200 Мбайт ОЗУ, а затем — из-за ошибки или естественного роста — они начнут потреблять больше, то возникнет риск ис- черпания ресурсов на машинах, на которых эти программы запланированы. В случае нехватки процессоров соседние задания будут испытывать всплески задержек, а в случае нехватки ОЗУ — процесс может быть аварийно завершен ядром или испы- тывать жуткие задержки из-за подкачки с диска 1 Две программы могут плохо уживаться друг с другом на одном компьютере и по другим причинам. Многие программы требуют установки зависимостей какой-то конкретной версии, и эти требования могут противоречить требованиям к версиям другой программы. Программа может ожидать, что определенные системные ре- сурсы (например, /tmp ) будут доступны ей для монопольного использования. В от- ношении безопасности программа может обрабатывать конфиденциальные данные и должна быть уверена, что другие программы на том же компьютере не смогут получить к ним доступ. То есть многоарендная вычислительная услуга должна обеспечивать определенную степень изоляции, своего рода гарантию, что процесс сможет безопасно выполняться, не вступая в конфликты с другими арендаторами машины. Классическим решением проблемы изоляции является использование виртуальных машин (ВМ). Однако оно сопряжено со значительными накладными расходами 2 с точки зрения ресурсов (необходимы ресурсы для запуска полноценной ОС внутри каждой ВМ) и времени запуска (требуется загрузить полную ОС). Это делает их не самым идеальным решением для контейнеризации пакетных заданий, быстро вы- полняющихся и требующих небольшой объем ресурсов. По этой причине инженеры Google, разработавшие Borg в 2003 году, начали искать другие решения и в итоге пришли к контейнерам — легковесному механизму, основанному на контрольных группах (cgroups, предложенных инженерами Google для включения в ядро Linux 1 В Google уже давно решили, что задержки из-за подкачки с диска настолько ужасны, что в случае нехватки памяти лучше прервать процесс и перенести его на другую машину, по- этому в Google нехватка памяти всегда вызывает завершение процесса. 2 Несмотря на значительное количество исследований, направленных на снижение наклад- ных расходов, эти расходы никогда не будут такими же низкими, как в случае процесса, выполняющегося непосредственно. 514 Глава 25. Вычисления как услуга в 2007 году) и chroot-клетках (chroot jails), который использует технологию мон- тирования связей (bind mounts) и/или объединения/наложения файловых систем для их изоляции. В числе известных реализаций контейнеров с открытым исходным кодом можно назвать Docker и LMCTFY. С течением времени и развитием организации будет возникать все больше проблем, связанных с недостаточной изоляцией. Вот конкретный пример: в 2011 году инжене- ры, работающие над Borg, обнаружили, что исчерпание пространства идентифика- торов процессов (которое по умолчанию ограничивалось 32 000 идентификаторов) вызывает ошибки изоляции и ограничивает общее количество процессов (потоков) в одной реплике. Чутьпозже мы рассмотрим этот пример подробнее. Выбор оптимальной конфигурации и автоматическое масштабирование В 2006 году система Borg планировала задания, опираясь на параметры, такие как количество реплик и требования к ресурсам, которые определялись инженером. Если взглянуть на проблему со стороны, то идея просить людей определить потреб- ности в ресурсах выглядит ошибочной, потому что это не те величины, с которыми они имеют дело ежедневно. То есть со временем эти параметры конфигурации сами стано- вятся источником неэффективности. Инженеры должны потратить время на их опре- деление при первом запуске службы, и по мере того как организация накапливает все больше и больше услуг, стоимость их определения будет расти. Более того, с течением времени программы тоже развиваются (и, вероятно, увеличиваются их потребности), а параметры конфигурации не успевают за ними. В конце концов возникает аварийная ситуация, при разборе которой выясняется, что новые выпуски требовали все больше ресурсов и уменьшили резерв, остававшийся на случай неожиданных всплесков, а когда такой всплеск произошел, оставшегося резерва оказалось недостаточно. Естественное решение — автоматизировать настройку этих параметров. К сожале- нию, реализовать его на удивление сложно. Например, в Google лишь недавно была достигнута точка, когда более половины потребностей ресурсов всего парка Borg стали определяться автоматически. Тем не менее, несмотря на то что охвачена только половина, она включает большую часть конфигураций, а это означает, что большин- ству инженеров не нужно тратить силы и время на определение потребностей своих контейнеров. Мы рассматриваем это как успешное применение идеи «простое долж- но быть легким, а сложное — возможным» — сам факт, что некоторая доля рабочих нагрузок Borg слишком сложна для автоматического управления их параметрами, совсем не означает, что автоматизация не дает преимуществ в простых случаях. Итоги По мере роста организации и популярности продуктов будут расти и эти направления: y Количество приложений, которыми необходимо управлять. y Количество копий приложений, которые требуется запускать. y Размер наибольшего приложения. Написание ПО для управляемых вычислений 515 Для эффективного управления масштабом необходима автоматизация, охватывающая все эти направления роста. Со временем можно ожидать, что сама автоматизация станет более активной как в обработке новых типов требований (например, распре- деление заданий между графическими и тензорными процессорами — это одно из существенных изменений в Borg за последние 10 лет), так и в увеличении масштаба. Действия, которые легко выполнить вручную в меньшем масштабе, необходимо автоматизировать, чтобы избежать коллапса организации с увеличением нагрузки. Один из примеров — продолжающийся в Google процесс автоматизации управле- ния центрами обработки данных. Десять лет назад каждый центр был отдельным объектом. Мы управляли ими вручную. Включение центра обработки данных было сложным и рискованным ручным процессом, требующим специальных навыков и занимавшим недели (при полной готовности машин). Однако с увеличением числа центров обработки данных Google мы перешли к модели, в которой включение центра превратилось в автоматизированный процесс. |