Джош Эванс рассказывает о хаотичном и ярком мире микросервисов Netflix, начиная с самых основ — анатомии микросервисов, проблем, связанных с распределенными системами и их преимуществ. Опираясь на этот фундамент, он исследует культурные, архитектурные и операционные методы, которые ведут к овладению микросервисами.
Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 1
Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 2
Восстановить сеть поможет автомасштабирование групп. Уверен, что вы с ним знакомы, но должен подчеркнуть его фундаментальность и крайнюю важность для запуска микросервисов в облачной среде.
У вас есть минимум и максимум, есть метрики, которыми вы пользуетесь, когда увеличиваете свою группу. Если нужен новый экземпляр, вы просто вытягиваете и раскручиваете любой образ из S3. В этом есть ряд преимуществ. Во-первых, это эффективное использование компьютерных мощностей, поскольку вы изменяете их по требованию. Вышедшие из строя узлы легко замещаются новыми. Но самое важное то, что при всплесках трафика, например, во время DDoS-атак или вследствие ошибок производительности, автомасштабирование позволяет сохранять работоспособность системы в то время как вы разбираетесь с причинами и устраняете неполадки. Я настоятельно рекомендую использовать это масштабирование, потому что оно неоднократно спасало нас от серьезных сбоев.
И конечно же, вы хотите убедиться в его постоянной работе с помощью Chaos. Обезьянка Хаоса Chaos Monkey – это наш инструмент, который случайным образом уничтожает экземпляры AWS или процессы на серверах, которые обслуживают сервис Netflix. Этот инструмент подтверждает, что если один из узлов узел «умирает», то все остальное продолжает работать без проблем. После внедрения Chaos Monkey мы получили возможность круглосуточно убеждаться в том, что все ноды имеют избыточное дублирование, падение одного узла не приводит ни к каким последствиям, а каждая неполадка документируется для того, чтобы впоследствии для ее устранения можно было применить готовое решение.
Давайте рассмотрим, что же представляют собой Stateful-сервисы. Это базы данных, кэши и пользовательские приложения, использующие внутренние кэши с большим объемом данных. Когда мы внедряли мультирегиональную архитектуру и пытались использовать общие стратегии репликации данных, такие приложения создали большую проблему. Поэтому я настоятельно рекомендую по возможности избегать хранения вашей бизнес-логики и состояний внутри одного приложения. Stateful-сервисы характеризуются тем, что потеря одного узла является значимым для системы событием. Замена этого узла новым может занять несколько часов.
Существует два различных подхода к кэшированию. Как я уже говорил, в наш коллектив влились бывшие сотрудники Yahoo, имевшие большой опыт работы с кэшами ha-proxy. Они использовали шаблон из выделенных серверов для пользователей. То есть пользователь всегда попадал на один и тот же узел, где располагался кеш с единственной копией данных. Проблема заключалась в том, что при поломке этого узла пользователь терял доступ ко всему сервису. На ранней стадии существования сервиса, еще до внедрения HYSTRIX, возникали ситуации, когда выход из строя одного узла обрушивал весь сервис Netflix. Устранение неполадки занимало 3,5 часа, в течение которых мы ждали, пока кеш сам себя наполнит, чтобы можно было выполнить запрос.
На следующем слайде показана схема выделенных сегментов Dedicated Shards, представляющая собой отказ от использования шаблона пользовательского dedicated-сервера.
Возвращаясь к биологии, можно сказать, что избыточность является фундаментальным фактором. У нас есть две почки, и если одна откажет, мы сможем жить за счет другой, у нас два легких, но мы можем просуществовать и с одним. Netflix подошел к решению проблем, используя принцип архитектуры человеческого тела. Мы не сможем увеличить нагрузку, но сможем прожить на одном из «органов».
Основной технологией в этом сценарии является совместное использование записи в EVCache. Данные записываются не только на несколько узлов, но и в несколько зон доступности. Чтение из них происходит локально, но опять же приложение может читать из нескольких зон, если это необходимо.
Это очень успешная модель, которую использует практически каждый виртуальный сервис Netflix.
Давайте поговорим о гибридных сервисах, представляющих собой комбинацию stateless и stateful сервисов. В данном случае очень легко использовать EVCache как наиболее подходящую технологию обеспечения отказоустойчивости.
Она позволяет обрабатывать 30 миллионов запросов в секунду, это 2 триллиона запросов в день. В EVCache могут храниться сотни миллиардов объектов и десятки тысяч экземпляров класса memcashed. Огромным преимуществом этой архитектуры является линейная масштабируемость, благодаря чему запросы возвращаются в течение нескольких миллисекунд независимо от нагрузки. Конечно, вам необходимо создать достаточно узлов, но сам процесс масштабирования чрезвычайно прост.
Несколько лет назад мы использовали сценарий, когда наш сервис Subscribers полагался на EVCache в несколько большей степени, чем это было необходимо, то есть имелся антипаттерн, о котором мы уже говорили. К Subscribers обращались практически все остальные сервисы. Я имею ввиду, что все хотели о нем знать, всем нужен был ID клиента, то, как получить доступ к аккаунтам и другая информация. Все оффлайн и онлайн вызовы поступали в один и тот же кластер.
Во многих случаях имели место многократные вызовы одного и того же приложения, получалось, что вы могли вызывать EVCache так часто, как вам хотелось, и на пике активности мы наблюдали от 800 тысяч до миллиона запросов в секунду. Fallback был бы логичным, если думать о нем в сиюминутном аспекте: если кеш дал сбой, дайте мне возможность вызвать сервис. Однако и с Fallback существовала проблема: когда весь уровень EVCache давал сбой, то все запросы поступали к сервису и базе данных и возникал антипаттерн — сервис с базой данных не мог справиться с той нагрузкой, которую принимал на себя EVCache. Получалось, что вроде бы правильный подход тоже приводил к неудаче – сбой EVCache вызывал отказ всего сервиса Subscribers.
Решение этой проблемы носит комплексный характер:
- прекратить «долбежку» одного и того же кластера системы оффлайн-запросами и вызовами в режиме реального времени, разделив рабочую нагрузку на онлайн и оффлайн сегменты;
- организовать Request-level cashing, то есть всегда привязывать жизненный цикл записи к текущей области запроса, чтобы стало невозможно вызывать один и тот же сервис снова и снова;
- встраивание в устройства пользователей токенов безопасности Fallback.
Последнее — это то, чего у нас пока нет и что будет внедрено в ближайшее время. Если клиент обращается к сервису Subscribers, когда он недоступен, будет осуществлен Fallback к данным, которые хранятся в этом зашифрованном токене. Токен содержит достаточно информации, чтобы идентифицировать пользователя и предоставить ему возможность совершать основные операции для использования нашего сервиса.
Рассмотрим вариации – различные варианты архитектуры сервиса. Чем больше таких вариантов, тем больше можно решить проблем, возникающих при увеличении масштаба системы, операционных отклонениях Operational drift, при которых эксплуатационные показатели отличаются от базовых показателей работы сервиса, или при внедрении новых языков или контейнеров.
Operational drift — это неизбежное старение различных факторов поддержания сложной системы, которое происходит неумышленно. Отклонения выражаются в периодическом возникновении пороговых нагрузок, таймаутов, задержек, падении производительности при добавлении нового функционала. Однако ручной труд по устранению проблем в данной области не особо эффективен и часто требует повторения одних и тех же манипуляций с небольшими отличиями исходных данных. Можно сказать, что этот процесс основан на голом энтузиазме команды разработчиков.
Если вернутся к биологии, то можно провести аналогию с человеческой нервной системой. Она автономна и автоматизирована, так что вы не задумываетесь о жизненно важной деятельности типа пищеварения или дыхания. Поэтому мы захотели создать такую среду, в которой можно автоматически внедрять наилучшие практики, не задумываясь о том, как это сделать. В Netflix мы достигли этого путем непрерывного обучение персонала и быстрого извлечения уроков из инцидентов по мере их возникновения, и автоматизировали внедрение в инфраструктуру передовых методов исправления проблем.
Непрерывное обучение и автоматизация представляет собой цепочку последовательных действий: инцидент – фиксация события – всестороннее рассмотрение причин возникновения инцидента — восстановление работоспособности – анализ – нахождение наилучшего решения – автоматизация – внедрение. Таким образом «знания становятся кодом», который интегрируется непосредственно в архитектуру микросервиса.
В течение нескольких лет мы аккумулировали лучшие практики и сформулировали общие принципы, которые назвали «Production Ready», или «Готовый продукт». Это чеклист, или программа действий Netflix. Каждый из принципов основан на автоматизации и постоянном улучшении модели взаимодействия с сервисом:
- Оповещения Alerts
- Apache & Tomcat
- Автоматический canary-анализ
- Автоматическое масштабирование
- Модель хаоса
- Согласованные, непротиворечивые наименования
- ELB config
- Проверка работоспособности Healthchek
- Неизменяемые образы машин
- Squeeze – тестирование. Оно состоит в запуске определенных тестов или бенчмарков для того, чтобы увидеть изменения в производительности и вычислить критическую точку приложения. Затем проверяется, было ли это последнее изменение неэффективным, или же оно определяет рекомендуемые параметры автоматического масштабирования перед развертыванием.
- Red/Black развертывания, заключающиеся в релизе, который сокращает время простоя и риски за счет запуска двух идентичных производственных сред, Red и Black. В любой момент времени только одна из сред является «живой», причем она обслуживает весь трафик.
- Тайм-ауты, повторные попытки, fallback.
Продолжение будет совсем скоро…
Немного рекламы
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Автор: ua-hosting.company
