Что означает обучение нейронных сетей?

В предыдущем сообщении блога мы обсудили общие концепции глубокого обучения. В этом сообщении блога мы углубимся в основные концепции обучения (глубокой) нейронной сети.



Откуда взялось «Neural»?

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

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

С другой стороны, искусственные нейронные сети построены по принципу биомимикрии. Внешние стимулы (данные), мощность сигнала которых регулируется весами нейронов (помните синапс ?), Циркулируют в нейрон (место, где будет выполняться математический расчет) через дендриты. Результат расчета, называемый выходом, является затем повторно передается (через аксон) нескольким другим нейронам, затем объединяются последующие слои и так далее.

Следовательно, это явная параллель между биологическими нейронами и искусственными нейронными сетями, как показано на рисунке ниже.



Рецепт искусственной нейронной сети

Для создания хорошей искусственной нейронной сети (ИНС) вам понадобятся следующие ингредиенты.

Ингредиенты:

Искусственные нейроны (узел обработки), состоящие из:
  • (много) входных нейронов, соединений (дендритов)
  • вычисления блок (ядро) состоит из:
    • линейная функция (ах + Ь)
    • функция активации (эквивалентно синапс )
  • выход (аксон)

Подготовка к получению ИНС для обучения классификации изображений:

  1. Определитесь с количеством классов вывода (имеется в виду количество классов изображений — например, два для кошки против собаки)
  2. Нарисуйте столько вычислительных единиц, сколько выходных классов (поздравляю, что вы только что создали выходной слой ИНС)
  3. Добавьте столько скрытых слоев, сколько необходимо в рамках определенной архитектуры (например, vgg16 или любой другой популярной архитектуры ). Совет. Скрытые слои  — это просто набор соседних вычислительных единиц , они не связаны друг с другом.
  4. Сложите эти скрытые слои на выходной слой с помощью нейронных соединений.
  5. Важно понимать, что входной уровень  — это, по сути, уровень приема данных.
  6. Добавьте уровень ввода, который адаптирован для приема ваших данных (или вы адаптируете формат данных к заранее определенной архитектуре)
  7. Соберите множество искусственных нейронов таким образом, чтобы выход (аксон) нейрона на данном слое был (одним) входом другого нейрона на последующем слое . Как следствие, входной слой связан со скрытыми слоями, которые затем связаны с выходным слоем (как показано на рисунке ниже) с помощью нейронных соединений (также показанных на рисунке ниже).
  8. Приятного аппетита



Что означает обучение искусственной нейронной сети?

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

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

Параллельно теории управления и глубокому обучению

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

Общие понятия теории управления

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



Теория управления применительно к радиатору

Возьмем, к примеру, сопротивление (управляемую систему) в радиаторе. Представьте, что вы решили установить комнатную температуру на 20 ° C (заданное значение) . Радиатор запускается, подает сопротивление с определенной интенсивностью, определяемой контроллером . Затем датчик (термометр) измеряет температуру окружающей среды ( элементы обратной связи ), которая затем сравнивается (компаратор) с заданным значением (желаемой температурой) и регулирует (контроллер) электрическую напряженность, передаваемую на сопротивление. Регулировка новой интенсивности осуществляется через шаг постепенной регулировки.

Теория управления применительно к обучению нейронной сети

Обучение нейронной сети аналогично обучению излучателя, поскольку управляемая система является моделью обнаружения кошки или собаки.

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


Для достижения этого система должна будет посмотреть на вход ( заданное значение ) и вычислить выход ( управляемая система ) на основе параметров, определенных в алгоритме. Этот этап называется прямым проходом.


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

Параллельно между системой управления электротехникой и процессом обучения нейронной сети

Одна вещь, которую следует учитывать: проблема долины

При обучении системы обратное распространение приведет к тому, что система уменьшит количество ошибок, которые она допускает, чтобы наилучшим образом соответствовать поставленным вами целям (обнаружение, что собака есть собака…).

Выбор скорости обучения, с которой вы будете регулировать свои веса (то, что в теории управления называется этапом корректировки ).

Как и в теории управления, система управления может столкнуться с несколькими проблемами, если она неправильно спроектирована:

  • Если шаг коррекции (скорость обучения) слишком мал, это приведет к очень медленной сходимости (то есть потребуется очень много времени, чтобы разогреть вашу комнату до 20 ° C…).
  • Слишком низкая скорость обучения также может привести к тому, что вы застрянете в локальных минимумах
  • Если шаг коррекции (скорость обучения) слишком высок, это приведет к тому, что система никогда не сойдется (биение вокруг куста) или хуже (то есть радиатор будет колебаться между слишком горячим или слишком холодным)
  • Система могла войти в резонансное состояние ( дивергенцию ).



В конце концов, для обучения искусственной нейронной сети (ИНС) требуется всего несколько шагов:

  1. Сначала для ИНС потребуется инициализация случайного веса.
  2. Разделить набор данных на партии (размер партии)
  3. Отправляйте партии 1 на 1 в GPU
  4. Рассчитайте прямой проход (каким будет результат с текущими весами)
  5. Сравните рассчитанный выход с ожидаемым выходом (убытком)
  6. Отрегулируйте веса (используя приращение или уменьшение скорости обучения ) в соответствии с обратным проходом (обратное распространение градиента) .
  7. Вернуться на квадрат 2

Дальнейшего уведомления

Вот и все, теперь вы готовы прочитать нашу будущую запись в блоге, посвященную распределенному обучению в контексте глубокого обучения.

Путешествие в чудесную страну машинного обучения, или «Меня ограбили?» (Часть 1)

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



Но как именно я пришел к этой предполагаемой «подходящей цене»? Ну, я видел много объявлений о большом количестве квартир. Я обнаружил, что некоторые объекты недвижимости были желательными и, следовательно, востребованными (с балконом, хорошим видом, безопасным районом и т. квартира.
Другими словами, я узнал из опыта , и это знание позволило мне построить ментальную модель , сколько квартира должна стоить в зависимости от его характеристик.



Но, как и любой другой человек, я подвержен ошибкам и поэтому постоянно задаю себе один и тот же вопрос: «Меня ограбили?». Что ж, оглядываясь назад на процесс, который привел меня к этому, становится очевидным, что есть способ следовать тому же процессу, но с большим количеством данных, меньшими предвзятостями и, надеюсь, в лучшее время: машинное обучение.

В этой серии сообщений в блоге я собираюсь изучить, как машинное обучение могло помочь мне оценить стоимость купленной мной квартиры; какие инструменты вам понадобятся для этого, как вы будете действовать и с какими трудностями вы можете столкнуться. Теперь, прежде чем мы окунемся в эту чудесную страну, сделаем небольшое заявление об отказе от ответственности: путешествие, которое мы собираемся пройти вместе, служит иллюстрацией того, как работает машинное обучение и почему оно, по сути, не является магией.

Вы не закончите это путешествие с помощью алгоритма, который сможет с максимальной точностью оценить любую квартиру. Вы не будете следующим магнатом недвижимости (если бы все было так просто, я бы продавал курсы о том, как стать миллионером на Facebook, за 20 евро). Надеюсь, однако, если я выполнил свою работу правильно, вы поймете, почему машинное обучение проще, чем вы думаете, но не так просто, как может показаться.

Что вам нужно, чтобы построить модель с помощью машинного обучения?



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

Что ж, вот наш набор данных. Если вы просмотрите веб-страницу, вы увидите, что существует множество вкладов сообщества, которые обогащают данные, делая их пригодными для макроанализа. Для наших целей мы можем использовать набор данных, предоставленный Etalab, общественной организацией, ответственной за поддержку платформы открытых данных.

Программного обеспечения
Здесь все становится немного сложнее. Если бы я был одаренным специалистом по данным, я мог бы просто положиться на среду, такую ​​как TensorFlow, PyTorch или ScikitLearn, чтобы загрузить свои данные и выяснить, какой алгоритм лучше всего подходит для обучения модели. Отсюда я мог определить оптимальные параметры обучения и затем тренировать их. К сожалению, я не одаренный аналитик данных. Но, к моему несчастью, мне все же повезло: есть инструменты, обычно сгруппированные под названием «AI Studios», которые разработаны именно для этой цели, но не требуют никаких навыков. В этом примере мы будем использовать Dataiku, одну из самых известных и эффективных AI Studios:

Инфраструктура
Очевидно, что программное обеспечение должно работать на компьютере. Я мог бы попробовать установить Dataiku на свой компьютер, но, поскольку мы находимся в блоге OVHCloud, кажется целесообразным развернуть его в облаке! Как оказалось, вы можете легко развернуть виртуальную машину с предварительно установленным Dataiku в нашем публичном облаке (вы также можете сделать это в публичном облаке некоторых наших конкурентов) с бесплатной лицензией сообщества. С помощью инструмента Dataiku я смогу загрузить набор данных, обучить модель и развернуть ее. Легко, правда?

Работа с вашим набором данных
После того, как вы установили свою виртуальную машину, Dataiku автоматически запускает веб-сервер, доступный через порт 11000. Чтобы получить к нему доступ, просто зайдите в свой браузер и введите. http://<your-VM-IP-address>:11000.После этого появится экран приветствия, предлагающий вам зарегистрироваться для получения бесплатной лицензии сообщества. Как только все это будет сделано, создайте свой первый проект и следуйте инструкциям по импорту вашего первого набора данных (вам просто нужно перетащить несколько файлов) и сохранить его.



Как только это будет сделано, перейдите к представлению «Поток» вашего проекта. Вы должны увидеть там свой набор данных. Выберите его, и вы увидите широкий спектр возможных действий.

А теперь перейдем к делу и обучим модель. Для этого перейдите к действию «Лаборатория» и выберите «Быстрая модель», затем «Прогнозирование» с «valeur_fonciere» в качестве целевой переменной (поскольку мы пытаемся предсказать цену).

Поскольку мы не являемся экспертами, давайте попробуем автоматическое машинное обучение, предложенное Dataiku, с интерпретируемой моделью и обучим его. Dataiku должен автоматически обучать две модели, дерево решений и регрессию, причем одна из них имеет лучшую оценку, чем другая (выбранная метрика по умолчанию — это оценка R2, одна из множества метрик, которые можно использовать для оценки производительности модели).. Щелкните по этой модели, и вы сможете ее развернуть. Теперь вы можете использовать эту модель в любом наборе данных по той же схеме.



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

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

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

Как только этот новый набор данных будет построен, просто загрузите его, как в первый раз, и вернитесь в представление потока. Там должен появиться ваш новый набор данных. Щелкните модель справа от потока, а затем действие «Оценка». Выберите образец набора данных, используйте параметры по умолчанию и запустите задание. Теперь у вас должен появиться новый набор данных в вашем потоке. Если вы изучите этот набор данных, вы увидите, что в конце есть новый столбец, содержащий прогнозы!



В моем случае для моей квартиры за 100 евро прогнозируемая цена составляет 105 евро. Это может означать две вещи:

  • Модель, которую мы обучили, довольно хороша, а недвижимость была хорошей сделкой!

Или…

  • Модель сделала удачную догадку.

Давайте попробуем другие транзакции, которые произошли на той же улице и в том же году. Что ж, на этот раз результат не впечатляет: очевидно, каждая квартира, купленная на моей улице в 2018 году, стоит ровно 105 евро, независимо от их размера и характеристик. Если бы я знал это, я бы, наверное, купил квартиру побольше! Казалось бы, наша модель не так умна, как мы изначально думали, и нам еще есть над чем поработать…

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

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

Прокачай мой Makefile

Чтобы не повторяться, рекомендуется поместить все задачи, которые вы можете выполнить дважды, где-нибудь в своем проекте. Makefile — идеальное место, а также исполняемая документация: вместо документирования процесса сборки вы должны записать его в цель сборки



Make почти везде — либо установлен, либо на расстоянии одной команды во всех дистрибутивах Linux. Но он далек от совершенства: например, нет встроенной справки или какой-либо опции для перечисления доступных целей для выполнения завершения Bash.

Помощь по целям

Рассмотрим следующий Makefile:

BUILD_DIR=build

clean: # Clean generated files and test cache
	@rm -rf $(BUILD_DIR)
	@go clean -testcache

fmt: # Format Go source code
	@go fmt ./...

test: clean # Run unit tests
	@go test -cover ./...

.PHONY: build
build: clean # Build binary
	@mkdir -p $(BUILD_DIR)
	@go build -ldflags "-s -f" -o $(BUILD_DIR)/hello .


В приведенном выше примере Make не предоставляет возможность перечислить доступные цели или документацию, извлеченную из комментариев. Давай сделаем это:

BUILD_DIR=build

help: # Print help on Makefile
	@grep '^[^.#]\+:\s\+.*#' Makefile | \
	sed "s/\(.\+\):\s*\(.*\) #\s*\(.*\)/`printf "\033[93m"`\1`printf "\033[0m"`	\3 [\2]/" | \
	expand -t20

clean: # Clean generated files and test cache
	@rm -rf $(BUILD_DIR)
	@go clean -testcache

fmt: # Format Go source code
	@go fmt ./...

test: clean # Run unit tests
	@go test -cover ./...

.PHONY: build
build: clean # Build binary
	@mkdir -p $(BUILD_DIR)
	@go build -ldflags "-s -f" -o $(BUILD_DIR)/hello .


Теперь вы можете создавать справку по целям, набрав:

$ make help
help       Print help on Makefile []
clean      Clean generated files and test cache []
fmt        Format Go source code []
test       Run unit tests [clean]
build      Build binary [clean]


Target help анализирует Makefile с помощью регулярного выражения, чтобы извлечь целевые имена, описания и зависимости, чтобы распечатать их на терминале. Поскольку эта цель является первой в Makefile, она используется по умолчанию, и вы можете получить помощь, набрав make .

Завершение удара по целям

Некоторые дистрибутивы предоставляют пакет для добавления завершения Bash в цели Make, другие — нет. Если у вас нет завершения при вводе make [TAB] , вы можете добавить его, используя следующий файл (например, в вашем файле ~ / .bashrc ):

# /etc/profile.d/make

complete -W "\`grep -oEs '^[a-zA-Z0-9_-]+:([^=]|$)' ?akefile | sed 's/[^a-zA-Z0-9_.-]*$//'\`" make


В примере файла сборки завершение будет напечатано:

$ make [TAB]
build  clean  fmt    help   test
$ make t[TAB]est


Это удобно для больших Make-файлов с несколькими целями.

Включение Makefile

Можно включить дополнительные файлы Makefile, которые включают директивы. Одним из примеров этого может быть включение Makefile help.mk в тот же каталог:

help: # Print help on Makefile
	@grep '^[^.#]\+:\s\+.*#' Makefile | \
	sed "s/\(.\+\):\s*\(.*\) #\s*\(.*\)/`printf "\033[93m"`\1`printf "\033[0m"`	\3 [\2]/" | \
	expand -t20


Его можно импортировать в основной Makefile следующим образом:

include help.mk

BUILD_DIR=build

clean: # Clean generated files and test cache
	@rm -rf $(BUILD_DIR)
	@go clean -testcache

fmt: # Format Go source code
	@go fmt ./...

test: clean # Run unit tests
	@go test -cover ./...

.PHONY: build
build: # Build binary
	@mkdir -p $(BUILD_DIR)
	@go build -ldflags "-s -f" -o $(BUILD_DIR)/hello .


Это будет включать в себя help.mk с целевой помощью. Но поскольку целевой справки больше нет в основном файле Makefile, она больше не будет отображаться при печати справки:

$ make help

$ make help
clean      Clean generated files and test cache []
fmt        Format Go source code []
test       Run unit tests [clean]
build      Build binary [clean]


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

Сделать инструменты

Make Tools используются для решения этих проблем с включением. Таких инструментов два:

Сделайте помощь
Инструмент Make Help сканирует текущий каталог в поисках make-файла, а затем анализирует его, чтобы извлечь информацию о целях. Включенные make-файлы анализируются рекурсивно. Таким образом, чтобы распечатать справку в предыдущем примере, вы должны ввести:

$ make-help
build Build binary [clean]
clean Clean generated files and test cache
fmt   Format Go source code
help  Print help on Makefile
test  Run unit tests [clean]


Мы знаем, что цели отсортированы и что цель справки включена в печатную справку.

Вы можете включить эту цель справки в make-файл со следующим определением:

.PHONY: help
help: # Print help on Makefile
	@make-help


Сделать цели
Этот инструмент рекурсивно перечисляет цели make-файла в текущем каталоге и все включенные. В предыдущем примере:

$ make-targets
build clean fmt help test


Таким образом, чтобы выполнить завершение bash, вы должны указать:

# /etc/profile.d/make

complete -W "\`make-targets\`" make


Известные ошибки
Эти инструменты работают так же, как и make:

  • Включенные файлы относятся к текущему каталогу, а не к соответствующему make-файлу.
  • Для включений нет бесконечного цикла обнаружения.

Этот инструмент с открытым исходным кодом, не стесняйтесь вносить свой вклад и улучшать его.

Наслаждайтесь!

Гибкая телеметрия в OVHCloud - Часть III

Эта статья является третьей в серии статей, мы рекомендуем сначала прочитать часть 1 и часть 2:

  • Рождение гибкой телеметрии в OVHcloud — Часть I
  • Гибкая телеметрия в OVHCloud — Часть II

В последнем посте, посвященном гибкой телеметрии, мы сосредоточимся на микровидении. В любом проекте разделение микро и макро видения жизненно важно для эффективного общения.

Макро и Микровидение

Для команд разработчиков микровидение имеет решающее значение. В то время как макроэкономическая перспектива важна для достижения таких целей, как сроки поставки, наблюдение за микродетализацией разработки обеспечивает хорошее качество продукта. Вот как нам удалось достичь этой важной цели:



Микровидение



Три блока данных

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



BurdownChart

(1) Это прогресс текущего спринта и его процент завершения. Процент выполнения просто вычисляется:



(2) Это показывает, сколько раз команда разработчиков выходила из спринта, чтобы что-то исправить, и время завершения. На прилагаемом графике показаны пиковые дни, когда команда была мобилизована.



Чтобы сообщить об этом типе информации:

  • Команды добавляют в поле «Ярлык» JIRA заголовок: препятствие.
  • Они регистрируют время, проведенное в поле «Журнал работы» в JIRA.



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

NB: Важно отделить спринт от препятствий. Эти две части информации позволяют сравнить «ожидаемое» и «неожиданное». Это позволяет предложить 2 типа графиков.

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



Природа препятствия

Пример: мы предоставляем 30 часов на исправление ошибок во время спринтов; должны ли мы сосредоточиться на создании чего-то нового или сокращении технического долга?

Вывод: Сегодня Agile-телеметрию используют 19 команд в OVHCloud. Это облегчает и позволяет нам измерять производительность и прогресс команд удаленно и в режиме реального времени. Он также предоставляет нам актуальную информацию, необходимую для реализации наших проектов. Именно эта методология получила награду Innovations Awards для сотрудников OVHCloud.

Если вы хотите погрузиться в Agile Telemetry, вы можете сделать это прямо сейчас!!! Просто возьмите нашу панель инструментов с открытым исходным кодом и нашего бота Jerem — github.com/ovh/jerem.

ML Serving: облачный инструмент для развертывания машинного обучения

Сегодня мы рады объявить о выпуске нового продукта Public Cloud . Чтобы ускорить и упростить ваши проекты машинного обучения, мы вводим ML Serving .

В OVHcloud мы используем несколько моделей машинного обучения, которые помогают принимать решения; начиная от борьбы с мошенничеством и заканчивая улучшением обслуживания нашей инфраструктуры. В недавнем сообщении в блоге мы представили  платформу машинного обучения,  которая ускоряет создание прототипов. Одна из ключевых особенностей платформы — возможность напрямую предоставлять прототипы через надежный веб-API .



Однако для конкретных случаев использования — или для изучения современных компонентов машинного обучения — практики не могут ограничиться использованием только этой платформы. Таким образом, перед этими проектами стоит одна из основных проблем машинного обучения : переход от стадии прототипа к реальной системе производственного уровня , которая является надежной и доступной для бизнес-приложений. Чтобы восполнить этот пробел , мы разработали ML Serving  — инструмент для управления процессом индустриализации.

Используя преимущества стандартных  форматов с открытым исходным кодом, таких как Tensorflow SavedModel, ML Serving позволяет пользователям легко развертывать свои модели, используя при этом важные функции, включая инструментарий, масштабируемость и управление версиями моделей . В этой статье мы познакомим вас с основными компонентами и функциями инструмента.

Дизайн обслуживания ML

Служба ML была разработана для удовлетворения следующих требований:

  • Легкость использования
  • Управление версиями модели
  • Стратегии развертывания
  • Простота доступа
  • Высокая доступность
  • Обратимость
  • Безопасность

Для достижения этих целей мы основали наш дизайн на микросервисной архитектуре, опирающейся на инфраструктуру Kubernetes. Проект разделен на два основных компонента:

  • Среда выполнения обслуживания: обрабатывает фактический вывод модели.
  • Центр обслуживания: обеспечивает оркестровку модели и управление

Время выполнения обслуживания

Компонент Serving Runtime является автономным и нацелен на упрощение использования и доступа. Таким образом, его две основные задачи — загрузить модели и раскрыть их.

Простота доступа

Мы обнаружили, что самый простой способ раскрыть модель — использовать HTTP API. Затем он легко интегрируется в любое бизнес-приложение. Среда выполнения обслуживания предоставляет API, ограниченный тем, что важно — конечную точку для описания модели и другую для ее оценки.

Входные данные API по умолчанию отформатированы как тензоры JSON. Ниже приведен пример входной полезной нагрузки для набора данных Титаника при оценке шансов на выживание двух пассажиров:

{
  "fare" : [ [ 7 ], [ 9 ] ],   
  "sex" : [ [ "male" ], [ "female" ] ],   
  "embarked" : [ [ "Q"], ["S" ] ],   
  "pclass" : [ [ "3" ], [ "2" ] ],   
  "age" : [ [ 27 ], [ 38 ] ] 
}


Тензоры используются для универсальной адресации всех обслуживающих моделей. Однако представление может быть трудным для понимания и в некоторых случаях может быть упрощено. В случае вывода только для одного пассажира JSON выглядит так:

{   
  "fare" : 7,   
  "sex" : "male",   
  "embarked" : "Q",   
  "pclass" :"3",   
  "age" : 27 
}


ML Serving также поддерживает распространенные форматы изображений, такие как JPG и PNG.

Легкость использования

Теперь, когда мы определили API, нам нужно загрузить модели и оценить их. Модели загружаются на основе стандартов сериализации, из которых поддерживаются следующие:

  • Tensorflow SavedModel
  • HDF5
  • ONNX
  • PMML

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

Гибкость

Среду выполнения обслуживания можно запускать непосредственно из экспортированных файлов модели или из более гибкой точки входа — манифеста. Манифест — это описание последовательности нескольких моделей или оценщиков. Используя манифест, пользователи могут описать последовательность оценщиков, выходные данные которой могут быть переданы непосредственно последующим оценщикам. Другими словами, специалисты-практики могут объединить их в уникальное развертывание модели.

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

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

Центр обслуживания

Компонент Serving Hub направлен на удовлетворение всех требований производственного уровня: управление версиями, безопасность, развертывание и высокая доступность.

Его основные задачи — это упаковка Serving Runtime с экспортированными моделями в образ Docker, а затем их развертывание в кластере Kubernetes. В глобальном масштабе компонент во многом полагается на свои функции Kubernetes. Например, для концентратора не требуется база данных, поскольку вся информация о моделях и развертываниях хранится в виде настраиваемых ресурсов Kubernetes.

Центр обслуживания предоставляет два API — API аутентификации, который защищает доступ к модели и управление ею с помощью токенов JWT, и второй, предназначенный для самого управления моделью.



При использовании API управления моделями развертывание модели так же просто, как предоставление имени и пути к файлам модели в серверной части хранилища. Затем Serving Hub запускает рабочий процесс для создания образа Docker, который упаковывает файл с экземпляром Serving Runtime перед его отправкой в ​​реестр. Образ является автономным, и его можно просто запустить с помощью Docker.

Центр обслуживания обеспечивает управление версиями посредством добавления тегов к изображениям моделей; он также обрабатывает развертывание с использованием встроенных возможностей Kubernetes; настраивает всю модельную аппаратуру; и обеспечивает автоматическое масштабирование модели. Всякий раз, когда модель перегружается, создается новый экземпляр — это извлекает образ из реестра, чтобы помочь выдержать новую рабочую нагрузку. Как только рабочая нагрузка уменьшается, дополнительные экземпляры удаляются, а потребляемые ресурсы адаптируются к реальной рабочей нагрузке.

Предустановленные изображения

Хотя некоторые модели могут быть специфичными только для бизнеса, другие могут использоваться совместно. В этой степени Serving Hub также управляет списком предварительно созданных моделей для удовлетворения общих сценариев использования.

В настоящее время в OVHCloud доступны две модели: анализ тональности для английского языка и еще одна для французского языка. Оба основаны на знаменитой архитектуре BERT (и ее французского аналога CamemBERT), поддерживаемой Hugging Face, и тонко настроены для анализа настроений с использованием Stanford Sentiment Treebank (1).

Другие модели со временем расширят текущий список предустановленных изображений, поэтому, пожалуйста, свяжитесь с нами, если вы считаете, что конкретная задача будет полезным дополнением (например, некоторые из моделей, доступных на OVHcloud AI MarketPlace ).

Следующие шаги

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

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

Еще одна важная особенность постановки — интерпретируемость. Хотя обычно это требует больших вычислительных затрат, интерпретируемость может иметь решающее значение; либо для целей отладки (например, для понимания того, почему модель так плохо себя ведет на определенных образцах), либо с точки зрения бизнеса. В самом деле, не всегда желательно слепо доверять алгоритму, не осознавая его ограничений или процесса принятия решения.

Обслуживание OVHcloud ML:

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

Конфиденциальность и удаленная работа - не забывайте о безопасности ваших данных

Сейчас, когда меры ограничения применяются во все большем числе стран, мы действительно можем видеть, в какой степени технологии помогают нам бороться с изоляцией. Технологии — это то, что позволяет нам продолжать учиться, оставаться на связи с близкими и развлекаться. Мы даже наблюдаем появление новых способов общения, таких как электронные напитки! Это совершенно новое испытание глобальной инфраструктуры Интернета. Несмотря на то, что он наводнен потоком потокового видео и аудио, онлайн-игр, видеоконференций и онлайн-уроков, до сих пор он смог выдержать возросший спрос.



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

С точки зрения защиты стратегических и конфиденциальных данных европейских компаний важно обеспечить соответствие используемой вами услуги европейским законам. Таким образом, вы можете быть уверены, что ваши данные не могут быть перехвачены и проанализированы властями за рубежом. Например, с помощью Закона об облачных технологиях американские правоохранительные органы могут получить доступ к определенным типам данных, размещенных операторами США по всему миру, и они могут делать это, даже не сообщая об этом компании. Независимо от того, где географически хранятся данные, действует закон США, если эти данные размещены игроком из США.

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

В дополнение к этому, кибербезопасность больше не может считаться необязательной. Мы уже наблюдаем, как хакеры атакуют наиболее уязвимые инфраструктуры — а также самые чувствительные из них, такие как ИТ-услуги в больницах, — в разгар пандемии. За последние несколько недель компании радикально изменили способ своей работы. Видеоконференцсвязь сейчас используется более широко, чем когда-либо, а удаленная работа стала нормой. Многие люди сейчас используют технические инструменты, но, читая статьи в прессе, мы обнаруживаем, что какими бы практичными ни были эти инструменты, иногда они не соответствуют правилам защиты личных данных. Некоторые даже не предлагают никакой защиты или шифрования. Видеосвязь стала настоящей уязвимостью для безопасности компании!

GDPR (Общий регламент по защите данных) дал первоначальный ответ на это в 2018 году, но сейчас, как никогда ранее, решения, принимаемые предприятиями в отношении использования их данных, остаются актуальной проблемой. Для каждого из используемых инструментов мы должны учитывать следующие моменты:

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

Если говорить более глобально, у Европы есть только один реальный путь к достижению стратегической и суверенной автономии с точки зрения облачной инфраструктуры. Это потребует создания экосистемы технологических игроков, основанной на европейских ценностях, гарантирующих основные права для бизнеса. OVHcloud осознает эту проблему и выступил с широкой инициативой по цифровой помощи под названием #Open_solidarity. Его цель — быстро объединить сообщество технических игроков и предоставить бесплатные решения для удаленной работы, совместной работы (образование / безопасность) и здравоохранения — с гарантией, что данные, созданные локально, обрабатываются также и локально.



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

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

  • Если вы тоже хотите присоединиться к этому акту цифровой солидарности, вы можете подать заявку на то, чтобы стать официальным участником, заполнив нашу онлайн-форму здесь .
  • Если вы ищете бесплатное решение, посетите нашу специальную платформу: https://open-solidarity.com/

Еще один день в жизни ProxySQL: делиться заботой

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



В этом посте я объяснил, как нам пришлось продвинуть proxySQL за его пределы.

Жюльен объяснил здесь, насколько сложно перехватить часть программы и заставить ее работать для очень специфического случая использования. Один настолько специфический, что мы просто не могли продвинуть его вверх по течению, поскольку мы нарушали некоторые предположения в базовом коде (что-то вроде «смотри, мы не используем это, может быть, мы можем отклонить его, чтобы он соответствовал нашему использованию»).

Но иногда, копаясь все глубже и глубже в строках кода, расширяя границы программ с открытым исходным кодом все дальше и дальше, мы обнаруживаем ошибки.

Вот два реальных случая, когда у нас было неожиданное поведение ProxySQL, в результате чего появился патч для MariaDB / MySQL.

1. Важность цитирования


Неожиданное поведение

Когда мы впервые начали использовать ProxySQL, у нас было неожиданное поведение. ProxySQL раньше зависал. Ни предупреждения, ни предвестника. Зависание означает, что ProxySQL не может обрабатывать ваши запросы, в результате чего ваши веб-сайты становятся недоступными.

Копать

Системные администраторы знают, что в случае сомнений проверяйте журналы. Вот что мы сделали и заметили вот это:

[ОШИБКА] Обнаружено разорванное соединение во время SET NAMES на 192.168.59.272, 3306: 2019, Невозможно инициализировать набор символов (null) (путь: compiled_in)


ОШИБКА 1064 (42000): у вас есть ошибка в синтаксисе SQL; проверьте руководство, которое соответствует вашей версии сервера MySQL, чтобы найти правильный синтаксис для использования рядом с «двоичным» в строке 1


Это явно ошибка, возвращенная сервером MySQL. Поскольку эта строка журнала была создана на ProxySQL, это означает, что ошибка произошла между нашим ProxySQL и сервером MySQL.

В поисках золота

Жюльен много работал — он прочитал тонны журналов, отследил множество PID и отследил проблему вплоть до ИСПОЛЬЗОВАНИЯ триггерного случая, выполнив эту команду:

set names binary COLLATE binary;


Сопоставление — это своего рода набор правил для сравнения строк. Он может определять, например, при сортировке по алфавиту, если Aидет раньше a, éследует ли рассматривать как eили нет, или где œдолжно быть в алфавите.

Вы можете узнать больше об этом в Базе знаний MariaDB.

Исправление

Отправив сообщение об обнаруженной нами проблеме в системе отслеживания ошибок ProxySQL и предложив исправление, автор ProxySQL взглянул и подтвердил ошибку.

При написании ProxySQL Рене Канна делал то же, что и все разработчики, — следовал документации коннектора MariaDB. И ошибка была отсюда:

According to the documentation on SET NAMES syntax (https://dev.mysql.com/doc/refman/5.7/en/set-names.html) :

charset_name and collation_name may be quoted or unquoted

This doesn't seem true for "SET NAMES binary COLLATE binary" , that requires the collation name to be quoted.


(https://bugs.mysql.com/bug.php?172id=93692)

Эффект бабочки

Итак, из-за зависания нашей инфраструктуры мы сообщили об ошибке создателю проекта, который затем отследил ее до ошибки в коннекторе MariaDB, проследил ее до родительского MySQL и исправил в восходящем направлении. Ошибка была закрыта в начале 2020 года.

Тем временем мы работали с г-ном Канна, чтобы найти обходной путь (в основном, заставляя имя сортировки указывать в коде ProxySQL).

2. Когда провода перекрещиваются

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

Неожиданное поведение

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

MySQL_Session.cpp:2964:handler(): [WARNING] Error during query on (42,192.168.59.272,3306): 1267, Illegal mix of collations (utf8_general_ci,IMPLICIT) and (dec8_swedish_ci,COERCIBLE) for operation '='


Копать

Конечно, в первую очередь мы проверили, что мы используем настоящую и допустимую кодировку и соответствующее сопоставление. Мы дважды и трижды проверили, что нам разрешено использовать dec8_swedish_ci.

Мы решили взглянуть на исходный код коннектора.

В поисках золота

Если вам интересно, вы можете взглянуть на более старые версии кода libmariadb / my_charset.c, начиная со строки 541. Вы заметите, что dec8_swedish_ci нигде не найти. Но если вы присмотритесь, вы заметите dec8_swedisch_ci. Дорогие друзья из Швеции, опечатка была сделана не только вами.

Исправление

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

Мы разделили репозиторий GitHub mariadb-corporation / mariadb-connector-c , исправили несколько опечаток и предложили запрос на перенос, который затем был объединен в середине февраля.

Эффект бабочки

Все склонны к опечаткам и ошибкам. С некоторыми мы столкнулись, они были исправлены и портированы для всех.



Вывод

Как ведущий поставщик веб-хостинга в Европе, мы сталкиваемся с законом действительно больших чисел ( en.wikipedia.org/wiki/Law_of_truly_large_numbers ). TL; DR: произойдет каждое событие с ненулевой вероятностью.

У нас размещено более 1,3 миллиона веб-сайтов. Предположим, что 0,0001% наших клиентов могут вызвать одну конкретную ошибку — у нас есть по крайней мере 1 клиент, который ее вызовет. Вопрос не в том, если, а в том, когда нам придется с этим бороться и как это сделать.

Хотите знать, как мы заметили, что попали в Закон действительно больших чисел? Следите за обновлениями, ведь мы скоро напишем об этом.

Поделиться заботой

OVHCloud любит открытый исходный код и любит делиться. Это не первый раз, когда мы вносим свой вклад в мир открытого исходного кода, и определенно не последний.

Защитите себя и защитите свою ИТ-инфраструктуру

20 марта 2020 года ENISA (Агентство Европейского Союза по кибербезопасности) опубликовало статью, в которой содержится призыв к компаниям и частным лицам проявлять бдительность после попыток мошенничества, которые извлекают выгоду из кризиса здравоохранения, вызванного COVID-19. Различные организации, такие как ANSSI (Национальное агентство кибербезопасности Франции), NCSC (Национальный центр кибербезопасности) и CISA.(Агентство по кибербезопасности и безопасности инфраструктуры) предупреждают, что хакеры используют кризис COVID-19 для увеличения объема мошенничества (фишинг, мошенничество с личными данными, выдача себя за медицинские учреждения и т. Д.) И распространения вредоносных программ (вымогателей, вирусов троянских коней) ). Последние иногда приписывались экспертам в группах APT (продвинутые постоянные угрозы).



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

Чтобы устранить основные риски, мы основываем наши рекомендации на структуре ATT & CK, предложенной Mitre, которая ссылается на различные тактики, методы и процедуры, используемые хакерами для достижения успеха в своих попытках. Следующая матрица ATT & CK объединяет наши наблюдения и устанавливает наиболее часто используемые методы получения доступа к ИТ-системе. Мы пытаемся предложить базовые меры по снижению рисков для 9 из этих 11 методов, чтобы вы могли снизить риски. Перечисленные нами матрицы предлагаются в качестве примера для иллюстрации предложений и ни при каких обстоятельствах не исключают анализ рисков, адаптированный к вашему сектору, инфраструктуре или специализации.



Предвидеть атаки, используя полномочия

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

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

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

Конкретно, эти действия положительно влияют на большое количество потенциально действенных хакерских приемов.



Ограничение воздействия на ИТ-систему

Это универсальное правило защиты от непредвиденных обстоятельств — обеспечение строгого минимума воздействия для ИТ-систем путем настройки брандмауэра для закрытия всех несущественных открытых служб. Открытый порт — это дверь, которую хакеры могут использовать для доступа к инфраструктуре и взлома ее.

Срочность настройки политики удаленной работы побудила некоторые команды открывать службы RDP (протокол удаленного рабочего стола), SSH (Secure Shell) и SMB (обмен файлами) непосредственно в Интернете, чтобы сотрудники без VPN также могли подключаться. Между тем, пока они настраивают работающую VPN, жизненно важно ограничить доступ к этим сервисам только для сотрудников, например, путем настройки доверенных IP-адресов в брандмауэре, чтобы заблокировать любых роботов, которые могут непрерывно сканировать Интернет. Протоколы RDP и SMB по-прежнему являются наиболее уязвимыми (например, вспомните Wannacry или уязвимость BlueKeep ).

Когда VPN настроен, попросите своих пользователей установить надежные пароли и, если возможно, настроить двухфакторную аутентификацию.

Эти действия положительно влияют на:



Обнаружение необычного поведения

Просить пользователей настроить надежный пароль — это одно, но вряд ли возможно полагаться на этот базовый совет для обеспечения общей безопасности организации. Вот почему важно дополнять эти меры механизмами обнаружения.

Независимо от того, говорим ли мы о SIEM (Security Event Management), принцип один и тот же — он включает обнаружение необычной активности. И это начинается с обнаружения сильных сигналов. Пользователь входит в систему ночью или в выходные? Пользователь подключается через необычного или неавторизованного интернет-провайдера?
Вы также можете контролировать использование машин в нерабочее время, чтобы обнаружить необычно интенсивное использование ЦП, которое может указывать на зараженную машину (криптомайнинг, программы-вымогатели и т. Д.).

Вы знали?

Вы можете использовать объявления BGP через 
pyasn
инструмент
 с открытым исходным кодом, предлагаемый Технологическим университетом Делфта, для обогащения данных IP.
Инструменты Sysmon также очень полезны для мониторинга вашей среды Windows.

Даже если он слишком реактивен, обнаружение очень важно для ограничения ущерба. В 2019 году среднее время обнаружения вторжений в мире составляло 56 дней.

Эти действия положительно влияют на:



Вывод

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

Анонс Kafka-on-Pulsar: добавление поддержки протокола Kafka в Apache Pulsar

Этот пост был опубликован в блогах StreamNative и OVHcloud, его соавторами являются Сиджи Го, Цзя Чжай и Пьер Земб. Спасибо Горацио Гонсалесу за иллюстрации!



Мы рады сообщить, что StreamNative и OVHcloud открывают исходный код «Kafka on Pulsar» (KoP). KoP обеспечивает поддержку протокола Apache Kafka в Apache Pulsar, вводя обработчик протокола Kafka на брокерах Pulsar. Добавив обработчик протокола KoP в существующий кластер Pulsar, вы теперь можете перенести существующие приложения и службы Kafka в Pulsar без изменения кода. Это позволяет приложениям Kafka использовать мощные функции Pulsar, такие как:

  • Оптимизация операций благодаря многопользовательской среде корпоративного уровня 
  • Упрощенные операции с архитектурой без ребалансировки 
  • Бесконечное хранение потока событий с помощью Apache BookKeeper и многоуровневого хранилища
  • Бессерверная обработка событий с помощью функций Pulsar

Что такое Apache Pulsar?

Apache Pulsar — это платформа потоковой передачи событий, изначально разработанная для облачных вычислений и обеспечивающая развертывание многоуровневой и сегментно-ориентированной архитектуры. Архитектура разделяет обслуживание и хранение на разные уровни, что делает систему удобной для контейнеров. Облачная архитектура обеспечивает масштабируемость, доступность и отказоустойчивость и позволяет компаниям расширять свои предложения с помощью решений с поддержкой данных в реальном времени. Pulsar получил широкое распространение с тех пор, как в 2016 году был открыт исходный код, а в 2018 году он был признан проектом Apache верхнего уровня.

Необходимость КОП

Pulsar предоставляет унифицированную модель обмена сообщениями как для очередей, так и для потоковых рабочих нагрузок. Pulsar реализовал собственный двоичный протокол на основе protobuf, чтобы обеспечить высокую производительность и низкую задержку. Такой выбор protobuf делает удобным реализацию клиентов Pulsar, и проект уже поддерживает языки Java, Go, Python и C ++ наряду с сторонними клиентами, предоставляемыми сообществом. Однако существующие приложения, написанные с использованием других протоколов обмена сообщениями, пришлось переписать, чтобы принять новый унифицированный протокол обмена сообщениями Pulsar.

Для решения этой проблемы сообщество Pulsar разработало приложения, упрощающие переход на Pulsar с других систем обмена сообщениями. Например, Pulsar предоставляет оболочку Kafka для API Kafka Java, которая позволяет существующим приложениям, которые уже используют клиент Kafka Java, переключаться с Kafka на Pulsar без изменения кода. Pulsar также имеет богатую экосистему соединителей, соединяющую Pulsar с другими системами данных. Тем не менее, все еще существовал высокий спрос со стороны тех, кто хотел перейти с других приложений Kafka на Pulsar.

Сотрудничество StreamNative и OVHcloud

StreamNative получал много входящих запросов о помощи по переходу с других систем обмена сообщениями на Pulsar и осознавал необходимость поддержки других протоколов обмена сообщениями (таких как AMQP и Kafka) изначально на Pulsar. StreamNative начал работу над внедрением общей структуры обработчиков протоколов в Pulsar, которая позволила бы разработчикам, использующим другие протоколы обмена сообщениями, использовать Pulsar.

Внутри OVHcloud уже много лет работает Apache Kafka, но, несмотря на их опыт работы с несколькими кластерами с миллионами сообщений в секунду на Kafka, возникают болезненные проблемы при эксплуатации. Например, объединить тысячи тем от тысяч пользователей в один кластер без мультитенантности было сложно.

В результате OVHcloud решила сместить и построить основу своего продукта «тема как услуга» под названием ioStream на Pulsar вместо Kafka. Мультиарендность Pulsar и общая архитектура с Apache Bookkeeper упростили операции по сравнению с Kafka.

Создав первый регион, OVHcloud решила реализовать его в качестве прокси-сервера для проверки концепции, способного на лету преобразовывать протокол Kafka в Pulsar. В ходе этого процесса OVHcloud обнаружил, что StreamNative работает над внедрением протокола Kafka в Pulsar, и они объединили усилия для разработки KoP.



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

Распределенный журнал

И Pulsar, и Kafka используют очень похожую модель данных для журналов как для обмена сообщениями pub / sub, так и для потоковой передачи событий. Например, оба они построены поверх распределенного журнала. Ключевое различие между этими двумя системами заключается в том, как они реализуют распределенный журнал. Kafka реализует распределенный журнал в архитектуре на основе разделов, где распределенный журнал (раздел в Kafka) предназначен для хранения в наборе брокеров, в то время как Pulsar развертывает архитектуру на основе сегментов для реализации своего распределенного журнала, используя Apache BookKeeper как его масштабируемый уровень хранения сегментов. Архитектура Pulsar на основе * сегментов * обеспечивает такие преимущества, как отсутствие перебалансировки, мгновенная масштабируемость и неограниченное хранение потоков событий. Вы можете узнать больше о ключевых различиях между Pulsar и Kafka вэтот блог Splunk и в этом блоге проекта Bookkeeper.

Поскольку обе системы построены на схожей модели данных, распределенном журнале, очень просто реализовать обработчик протокола, совместимый с Kafka, используя распределенное хранилище журналов Pulsar и его подключаемую структуру обработчика протоколов (введенную в выпуске 2.5.0).

Реализации

Реализация осуществляется путем сравнения протоколов между Pulsar и Kafka. Мы обнаружили, что между этими двумя протоколами есть много общего. Оба протокола состоят из следующих операций:

  • Поиск темы : все клиенты подключаются к любому брокеру для поиска метаданных (то есть брокера-владельца) тем. После получения метаданных клиенты устанавливают постоянные TCP-соединения с брокерами-владельцами.
  • Производство : клиенты обращаются к брокеру- владельцу тематического раздела, чтобы добавить сообщения в распределенный журнал.
  • Потребление : клиенты обращаются к брокеру- владельцу раздела темы, чтобы прочитать сообщения из распределенного журнала.
  • Смещение : сообщения, создаваемые для тематического раздела, назначаются со смещением. Смещение в Pulsar называется MessageId. Потребители могут использовать смещения для поиска заданной позиции в журнале для чтения сообщений.
  • Состояние потребления : Обе системы поддерживают состояние потребления для потребителей в рамках подписки (или группы потребителей в Kafka). Состояние потребления хранится в теме __offsets в Kafka, а состояние потребления хранится в виде курсоров в Pulsar.

Как видите, это все примитивные операции, обеспечиваемые масштабируемым распределенным хранилищем журналов, таким как Apache BookKeeper. Основные возможности Pulsar реализованы поверх Apache BookKeeper. Таким образом, довольно легко и просто реализовать концепции Kafka, используя существующие компоненты, которые Pulsar разработал для BookKeeper.

На следующем рисунке показано, как мы добавляем поддержку протокола Kafka в Pulsar. Мы представляем новый обработчик протоколов, который реализует проводной протокол Kafka, используя существующие компоненты (такие как обнаружение тем, распределенная библиотека журналов — ManagedLedger, курсоры и т. Д.), Которые уже есть в Pulsar.



Темы

В Kafka все темы хранятся в одном плоском пространстве имен. Но в Pulsar темы организованы в иерархические мультитенантные пространства имен. Мы вводим параметр kafkaNamespace в конфигурацию брокера, чтобы администратор мог отображать темы Kafka в темах Pulsar.

Чтобы пользователи Kafka могли использовать функцию мультитенантности Apache Pulsar, пользователь Kafka может указать клиент Pulsar и пространство имен в качестве своего имени пользователя SASL, когда он использует механизм аутентификации SASL для аутентификации клиента Kafka.

Идентификатор сообщения и смещение

В Kafka каждому сообщению присваивается смещение после его успешного создания в разделе темы. В Pulsar каждому сообщению присваивается «MessageID». Идентификатор сообщения состоит из 3 -х компонентов, главная книга-ID , начальные идентификаторы и пакетный индекс . Мы используем тот же подход в оболочке Pulsar-Kafka для преобразования Pulsar MessageID в смещение и наоборот.

Сообщения

И сообщение Kafka, и сообщение Pulsar имеют ключ, значение, временную метку и заголовки (примечание: в Pulsar это называется «свойствами»). Мы автоматически конвертируем эти поля между сообщениями Kafka и сообщениями Pulsar.

Поиск по теме

Мы используем тот же подход поиска тем для обработчика запросов Kafka, что и обработчик запросов Pulsar. Обработчик запросов выполняет обнаружение темы для поиска всех владений для запрошенных тематических разделов и отвечает информацией о владении как часть Kafka TopicMetadata обратно клиентам Kafka.

Создавать сообщения

Когда обработчик запросов Kafka получает созданные сообщения от клиента Kafka, он преобразует сообщения Kafka в сообщения Pulsar, сопоставляя поля (т.е. ключ, значение, временную метку и заголовки) одно за другим, и использует API добавления ManagedLedger для добавления этих преобразованных сообщений Pulsar. в BookKeeper. Преобразование сообщений Kafka в сообщения Pulsar позволяет существующим приложениям Pulsar использовать сообщения, созданные клиентами Kafka.

Потреблять сообщения

Когда обработчик запросов Kafka получает запрос потребителя от клиента Kafka, он открывает непостоянный курсор для чтения записей, начиная с запрошенного смещения. Обработчик запросов Kafka преобразует сообщения Pulsar обратно в сообщения Kafka, чтобы существующие приложения Kafka могли использовать сообщения, созданные клиентами Pulsar.

Координатор группы и управление взаимозачетами

Самая сложная часть — внедрить управление групповым координатором и зачетами. Потому что Pulsar не имеет централизованного координатора группы для назначения разделов потребителям группы потребителей и управления смещениями для каждой группы потребителей. В Pulsar назначением разделов управляет брокер для каждого раздела, а управление смещением осуществляется путем сохранения подтверждений в курсорах брокером-владельцем этого раздела.

Модель Пульсара сложно согласовать с моделью Кафки. Следовательно, для обеспечения полной совместимости с клиентами Kafka мы реализовали координатор группы Kafka, сохраняя изменения и смещения группы координаторов в системной теме под названием public / kafka / __ offsets в Pulsar.

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

Соедините две популярные экосистемы обмена сообщениями

В обеих компаниях мы ценим успех клиентов. Мы считаем, что предоставление собственного протокола Kafka на Apache Pulsar снизит барьеры для людей, использующих Pulsar для достижения успеха в бизнесе. Интегрируя две популярные экосистемы потоковой передачи событий, KoP открывает новые варианты использования. Клиенты могут использовать преимущества каждой экосистемы и создать действительно унифицированную платформу потоковой передачи событий с Apache Pulsar, чтобы ускорить разработку приложений и сервисов в реальном времени.

С помощью KoP сборщик журналов может продолжать собирать данные журналов из своих источников и отправлять сообщения в Apache Pulsar, используя существующие интеграции с Kafka. Последующие приложения могут использовать функции Pulsar для обработки событий, поступающих в систему, для выполнения бессерверной потоковой передачи событий.

Попробуй это

Исходный код KoP открыт под лицензией Apache License V2 по адресу https://github.com/streamnative/kop .

Мы с нетерпением ждем ваших вопросов и PR. Вы также можете присоединиться к каналу #kop в Pulsar Slack, чтобы обсудить все о Kafka-on-Pulsar.

StreamNative и OVHcloud также проводят веб-семинар по KoP 31 марта. Если вы хотите узнать больше о KoP, зарегистрируйтесь . С нетерпением жду встречи с вами онлайн.



Спасибо

Первоначально проект KoP был инициирован StreamNative. Команда OVHcloud присоединилась к проекту для совместной работы над проектом KoP. Большое спасибо Пьеру Зембу и Стивену Ле Ру из OVHcloud за их вклад в этот проект!

Семейство Open Source Metrics приветствует Catalyst и Erlenmeyer

В OVHcloud Metrics мы любим открытый исходный код! Наша цель — предоставить всем нашим пользователям полноценный опыт . Мы полагаемся на базу данных временных рядов Warp10, которая позволяет нам создавать инструменты с открытым исходным кодом для наших пользователей. Давайте взглянем на некоторые из них в этом блоге.



Инструмент для хранения

Наша инфраструктура основана на базе данных временных рядов с открытым исходным кодом: Warp10 . Эта база данных включает две версии: автономную и распределенную . Распределенный полагается на распределенные инструменты, такие как Apache Kafka, Apache Hadoop и Apache HBase .

Неудивительно, что наша команда вносит свой вклад в платформу Warp10 . Из-за наших уникальных требований мы даже вносим свой вклад в базовую базу данных с открытым исходным кодом HBase !

Прием данных метрик

Собственно говоря, мы были первыми, кто застрял в процессе приема ! Мы часто создаем адаптированные инструменты для сбора и отправки данных мониторинга на Warp10 — так появился noderig . Noderig является адаптированным инструментом , который способен собрать в простое ядро метрик с любого сервера или любой виртуальной машины . Также можно безопасно отправлять метрики на бэкэнд. Beamium , инструмент Rust, может передавать метрики Noderig одному или нескольким бэкэндам Warp 10 .



Что, если я хочу собирать собственные специальные показатели ? Во-первых, вам нужно будет разоблачить их по «модели Прометея». Beamium затем может подручных приложений на основе их файл конфигурации и вперед все данные в сконфигурированной Деформация 10 бэкэндом (ов)!

Если вы хотите отслеживать определенные приложения с помощью агента Influx Telegraf (чтобы предоставить необходимые вам метрики), мы также предоставили соединитель Warp10 Telegraf , который был недавно объединен!

Пока это выглядит великолепно, но что, если я обычно нажимаю метрики Graphite, Prometheus, Influx или OpenTSDB ; как я могу просто перейти на Warp10 ? Наш ответ - Catalyst : прокси-уровень, который может анализировать метрики в связанных форматах и ​​преобразовывать их в родной для Warp10.

Катализатор

Catalyst  — это HTTP-прокси Go, используемый для анализа нескольких записей в базе данных TimeSeries с открытым исходным кодом. На данный момент он поддерживает несколько операций записи в базу данных TimeSeries с открытым исходным кодом; такие как OpenTSDB, PromQL, Prometheus-remote_write, Influx и Graphite. Catalyst запускает HTTP-сервер, который прослушивает определенный путь ; начиная с имени временного ряда протокола, а затем с собственного запроса . Например, чтобы собрать данные о притоке, вы просто отправляете запрос на адрес 
influxdb/write
. Catalyst автоматически проанализирует 
influx
данные и преобразует их в собственный формат приема Warp 10 .



Запросы метрик

Сбор данных — важный первый шаг, но мы также рассмотрели, как существующие протоколы мониторинга запросов могут быть использованы поверх Warp10. Это привело нас к внедрению TSL. TSL подробно обсуждался во время встречи по временным рядам в Париже, а также в этом сообщении в блоге.

Теперь давайте возьмем пользователя, который использует Telegraf и отправляет данные в Warp10 с помощью Catalyst. Они захотят использовать встроенную панель управления Influx Grafana, но как? А как насчет пользователей, которые автоматизируют запросы с помощью протокола запросов OpenTSDB? Нашим ответом было разработать прокси: Эрленмейер

Эрленмейер

Erlenmeyer  — это HTTP-прокси Go, который позволяет пользователям запрашивать Warp 10 на основепротокола запросовс открытым исходным кодом . На данный момент он поддерживает несколько форматов TimeSeries с открытым исходным кодом; такие как PromQL, удаленное чтение Prometheus, InfluxQL, OpenTSDB или Graphite. Эрленмейер запускает HTTP-сервер, который прослушивает определенный путь ; начиная с имени временного ряда протокола, а затем с собственного запроса . Например, чтобы выполнить запрос promQL, пользователь отправляет запрос в
prometheus/api/v0/query
. Эрленмейер изначально проанализирует
promQL
запрос, а затем создаст собственный запрос WarpScript, который может поддерживатьлюбойбэкэнд Warp10 .



Продолжение следует

Сначала Erlenmeyer и Catalyst представили быструю реализацию собственных протоколов, призванную помочь внутренним группам выполнять миграцию, при этом используя знакомый инструмент . Теперь мы интегрировали множество встроенных функций каждого протокола и чувствуем, что они готовы к совместному использованию. Это время , чтобы сделать их доступными для Warp10 сообщества , поэтому мы можем получить обратную связь и продолжать работать в поддержке протоколов с открытым исходным кодом. Вы можете найти нас в игровой комнате OVHcloud Metrics !

Другим пользователям Warp10 может потребоваться нереализованный протокол. Они смогут использовать Erlenmeyer и Catalyst для поддержки их на собственном сервере Warp10.

Добро пожаловать, Erlenmeyer и Catalyst — Metrics Open Source проекты!