Повышение эффективности использования ресурсов с помощью микроразмера

По данным Gartner , средняя загрузка центров обработки данных в мире составляет от 10 до 15 процентов, что не очень хорошо для эффективности использования ресурсов. Лидеры в использовании ресурсов, в частности Google и Netflix, работают намного лучше — от 50 до 70 процентов.

К сожалению, эффективность ресурсов, вероятно, будет ухудшаться, если мы ничего не сделаем с этим. Публичное облако и инструменты автоматизации упрощают перерасход. Зачастую это единственный способ справиться со сложностью и непредсказуемым спросом (в конце концов, как правило, лучше переоценивать, чем перепадать).

Спрос на общедоступное облако растет по мере перехода предприятий к нему и добавления новых рабочих нагрузок, таких как IoT . По оценкам, к 2020 году прогнозируемый рост спроса на емкость центров обработки данных составит от 50 до 300 процентов .

Как мы можем улучшить эффективность использования ресурсов в технологии?

В марте 2016 года The Economist оценил центры обработки данных в 2% мирового потребления энергии . Для сравнения, авиационная отрасль использует от 2 до 2,5 процентов мировой энергии , и люди проводят кампании против новых взлетно-посадочных полос. Может быть, это несправедливо, учитывая, что авиация является довольно энергоэффективным сектором. Расходы на топливо составляют значительную долю расходов авиационного бизнеса, а снижение энергопотребления является прямым конкурентным преимуществом.

В то же время в технологическом секторе мы менее заинтересованы в экономии средств и более заинтересованы в скорости внедрения новых функций или продуктов. Популярная архитектура микросервисов позволяет автономным командам быстро отправлять функции. Однако развертывание одного микросервиса на виртуальную машину часто снижает нагрузку на сервер по сравнению с монолитом старого стиля.

Контейнерная оркестровка

Хорошей новостью является то, что оркестровка может значительно повысить эффективность центра обработки данных. Именно так Google и Netflix достигают лучших результатов.

Контейнеры можно масштабировать в режиме реального времени, тогда как для увеличения емкости виртуальных машин требуются минуты. Таким образом, вместо добавления новых машин, вы можете просто переназначить существующую инфраструктуру, чтобы сосредоточиться на временно срочных задачах. Мы называем это «микромасштабом», чтобы отличать его от традиционного автомасштабирования с виртуальными машинами. Используя микро-масштабирование, Netflix и Google одновременно сократили потребление энергии и затраты на хостинг.

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

Микромасштабный двигатель

Orchestrators позволяют вам создавать полезные инструменты для управления вашими контейнерными рабочими нагрузками. Все оркестраторы (Docker Swarm, Mesos, Kubernetes, Nomad, ECS) имеют чистые API-интерфейсы RESTful, которые позволяют вам видеть, что работает во всем вашем кластере, а также останавливать и запускать задачи.

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

Некоторые из оркестраторов поддерживают микромасштабирование на основе процессора и памяти. Это может быть полезно, но есть и проблемы — контейнер может использовать много ЦП, потому что, например, код неэффективен. Вместо использования процессора и памяти лучше использовать показатели, связанные с активностью клиентов.

Для этого вам потребуется доступ к показателям спроса в реальном времени. CloudWatch и подобные сервисы часто отстают на несколько минут, что недостаточно быстро. Первоначально, в качестве метрики спроса, мы используем длины очередей прямо из действующих систем, таких как балансировщики нагрузки (NGINX), или очередей, таких как SQS или Rabbit.

Если длина очереди выше цели, мы уменьшаем размеры контейнеров, а затем уменьшаем их, как только обрабатывается отставание. Любая свободная емкость может быть использована для задачи с более низким приоритетом. До сих пор мы поддерживаем Docker Remote API и Marathon / Mesos с появлением большего количества оркестровщиков.

Вы можете попробовать это сами с помощью Docker Compose, запустив наш механизм масштабирования для масштабирования локальной очереди NSQ. Вы можете найти код на GitHub в microscale / microscaling .

Метаданные, контейнеры и оркестровка

Но мы быстро столкнулись с проблемой микромасштабирования. Как мы узнаем, подходит ли конкретный образ контейнера для жизненно важной службы или что-то некритическое, например, для пакетной службы? Также оркестровщики должны знать пределы процессора и памяти, которые должны применяться к контейнеру. Разработчик контейнера должен иметь четкое представление о ресурсах, которые ему потребуются. Но как передать эту информацию оркестратору, которым может управлять отдельная команда?

Нам нужен какой-то способ добавить метаданные в изображения-контейнеры, чтобы рассказать нам о таких вещах. К счастью, у Dockerfiles есть официальный способ сделать это. При разработке нашего механизма масштабирования мы поняли, что метаданные и метки являются ключом к масштабированию и эффективному использованию оркестраторов.

В Docker v1.6 Red Hat предоставила механизм добавления метаданных к изображениям контейнера Docker: метки . Это был стандартный способ добавления заметок или условий лицензирования, например, к изображению. Фактически, единственная проблема с метками — они не используются чаще (менее 20 процентов времени).

Схема и форматирование

Метки являются свободными текстовыми парами ключ / значение. Это гибко, но потенциально неопрятно, небезопасно и непоследовательно, особенно потому что:

• Вы можете пометить изображение или контейнер несколько раз.
• Контейнеры наследуют метки для своих изображений.
• Новые ключи перезаписывают старые ключи с тем же именем.

К счастью, Docker определил некоторые рекомендации по форматированию для меток :

• Имена пространства ваших имен ключей с обратным обозначением DNS вашего домена ( например , com.mydomain.mykey ).
• Не используйте com.docker.x , io.docker.x или org.dockerproject.x в качестве пространства имен в ваших именах ключей. Те защищены.
• Используйте строчные буквенно-цифровые символы . и - (как в [a-z0-9-.] ) в именах ключей и начинаются и заканчиваются буквенно-цифровыми.
• Не используйте последовательные точки и тире в именах ключей.
• Не добавляйте ярлыки по одному с отдельными командами ярлыков. Каждая метка добавляет новый слой к изображению, так что это неэффективно. Добавьте несколько ярлыков за один звонок, где вы можете:

Эти рекомендации не соблюдаются, но, несомненно, появятся инструменты для этого ( например , github.com/garethr/docker-label-inspector ).

Ярлыки для использования

Было много споров о метках по умолчанию и специфичных для оркестровщиков (см. Раздел «Ссылки» в конце этого поста). Чтобы начать, мы решили добавить минимальный начальный набор меток к нашим собственным изображениям. Эти метки должны быть полезны для большинства общедоступных изображений Docker. Они еще не включают метаданные микромасштабирования.

Label-Schema.org

Мы также помогли настроить и присоединились к сообществу label-schema.org, чтобы помочь определить пространство имен по умолчанию для стандартных меток. Мы хотели получить соглашение сообщества о правильных, наиболее полезных ярлыках для добавления в любой контейнер по умолчанию.

К сожалению, вы не можете использовать динамические метки в Dockerfile. Вы можете просто жестко закодировать значения меток, но они могут легко устареть, и это немного неприятно. Docker рекомендует использовать команду ARG для передачи этих динамических меток в Dockerfile.

В нашем случае мы создали make-файл для автоматизации передачи динамических меток в наш Dockerfile, который также находится в нашем репозитории GitHub . Не стесняйтесь взглянуть.

MicroBadger

Чтобы поощрить стандартное использование меток, мы также создали веб-сайт ( microbadger.com ) для отображения метаданных общедоступных изображений на DockerHub. Если вы поддерживаете общедоступные изображения, веб-сайт позволяет добавлять значки на страницу DockerHub и в GitHub Readme. На DockerHub вы можете показать своим пользователям точный коммит git, который был использован для создания образа. Это стало возможным благодаря меткам, которые вы добавляете к своему изображению.

Вывод

Комбинация контейнеров и оркестровки является мощной, поэтому Docker только что поставил их оркестратор Swarm. С помощью оркестровки контейнеров мы можем более эффективно использовать инфраструктуру и перейти от 10–15-процентного использования ресурсов, которого мы сейчас достигаем, к более чем 50-процентному. Это жизненно важно, если центры обработки данных не собираются становиться новыми загрязнителями и неэффективными пользователями энергии в XXI веке.

Первым шагом в эффективном использовании оркестраторов и инструментов после оркестрации будут метаданные контейнера. Подумай о:

• Добавление основных меток к вашим изображениям.
• Вклад в сообщество label-schema.org и предложение добавления стандартных ярлыков.

Наконец, подумайте об использовании энергии в ваших приложениях. Они раздутые или в виртуальных машинах больше, чем нужно? Ваша планета нуждается в вас!

использованная литература

• Гарет Рашгров в DockerCon EU
• Руководство по маркировке докера
• OpenShift — Метки для оркестровки с Kubernetes
• Project Atomic — Предложение для универсальных этикеток
• Список лицензий SPDX