В нашем предыдущем посте мы говорили о том, как наша технология водоблоков развивалась с 2003 по 2014 год. Сегодня мы продолжим эту тему, исследуя эту технологию после 2015 года. Мы сосредоточимся на текущем поколении водоблоков и дадим вам краткий обзор доработки впереди.

2015 г.

В 2015 году приблизился, наша ключевой целью заключалась в разработке водных блоков с производительностью оптимального по 120W и температурой воды 30 ° С .



Чтобы упростить процесс и снизить затраты, мы заменили металлическую крышку на АБС-пластик.



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



Как и в предыдущих итерациях, мы также производили водоблоки меньшего форм-фактора. Например, вот вам водоблок GPU:

3D-печать водяных блоков

Использование пластиковых крышек для водоблоков также открыло двери для нового процесса прототипирования, включая 3D-печать. Мы начали экспериментировать с 3D-печатными водоблоками из АБС-пластика, тестируя различные типы крышек.

Варианты обложек, напечатанных на 3D-принтере:

CFD моделирование

Впервые в истории OVHcloud мы использовали расширенное моделирование CFD (вычислительная гидродинамика). Это позволило нам оптимизировать теплогидравлику пластин с медным основанием и дополнительно улучшить характеристики водоблока.

Резервирование

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

2017 г.

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



К 2017 году мы были в состоянии использовать водные блоки с оптимальной производительностью от 200Вт и температурой воды 30 ° C , и все было полностью разработано и изготовлено внутри на OVHcloud .

После крышек из АБС-пластика пришло время протестировать другие пластики, включая полиамиды.

Два примера водоблоков: один для стандартных процессоров, другой для графических процессоров, с белыми полиамидными крышками:





Водоблок для процессоров высокой плотности с черной крышкой из полиамидного пластика:



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

2018-2019

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

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



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



На этих водоблоках трубопроводы полностью выполнены из медных сварных труб.



Как обычно, мы также производим водоблоки для определенных форм-факторов, таких как графические процессоры или процессоры высокой плотности.

2020-…

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



Мы работаем над водоблоками следующего поколения tier-4, используя нашу запатентованную технологию. Наши водоблоки 4-го уровня больше не являются прототипами, они готовы к производству, и мы активно работаем над моделированием и тестами для повышения производительности.



Мы стремимся к водоблокам мощностью 400 Вт с температурой воды 30 ° C и полностью резервным водоснабжением.

А кроме водоблоков?

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



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

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



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

libvirt

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

Архитектура NVMe для наших экземпляров Public Cloud

Чтобы обеспечить максимальную производительность хранилища, мы работали с рядом наших клиентов над PoC, в котором использовалась та же функция PCI Passthrough, чтобы включить самое быстрое устройство хранения в наши экземпляры Public Cloud: карты NVMe с 1,8 ТБ пространства .

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



Очистите устройство перед его перераспределением

Вы говорите быстро, но как быстро?

Давайте перейдем к некоторым конкретным примерам и не пожалеем времени, чтобы оценить потрясающую скорость этих новых экземпляров! Мы воспользуемся моделью самого большого экземпляра и запустим тест ввода-вывода на RAID 0. Таким образом, мы увидим, каковы ограничения, когда мы стремимся создать самое быстрое решение для хранения данных на простом экземпляре Public Cloud.

Сначала создайте экземпляр i1-180, используя OpenStack CLI.

$ openstack server create --flavor i1-180 --image "Ubuntu 19.04" \
  --net Ext-Net --key-name mykey db01

Проверьте устройства NVMe на экземпляре.

$ lsblk | grep nvme
nvme2n1 259:0    0  1.8T  0 disk
nvme1n1 259:1    0  1.8T  0 disk
nvme0n1 259:2    0  1.8T  0 disk
nvme3n1 259:3    0  1.8T  0 disk

У нас есть четыре устройства NVMe, поэтому давайте создадим с ними RAID 0.

$ mdadm --create /dev/md1 --level 0 --raid-devices 4 \
  /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started

Теперь отформатируем рейд-устройство.

$ mkfs.xfs /dev/md1
meta-data=/dev/md1               isize=512    agcount=32, agsize=58601344 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=0, rmapbt=0, reflink=0
data     =                       bsize=4096   blocks=1875243008, imaxpct=5
         =                       sunit=128    swidth=512 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=8 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

После монтирования файловой системы на / mnt мы готовы запустить тест.

Прочитать тест

Мы начнем с теста чтения, используя блоки размером 4 КБ, и поскольку у нас 32 виртуальных ядра в этой модели, мы будем использовать 32 задания. Пошли!

$ fio --bs=4k --direct=1 --rw=randread --randrepeat=0 \
  --ioengine=libaio --iodepth=32 --runtime=120 --group_reporting \
  --time_based --filesize=64m --numjobs=32 --name=/mnt/test
/mnt/test: (g=0): rw=randread, bs=® 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
[...]
fio-3.12
Starting 32 processes
Jobs: 32 (f=32): [r(32)][100.0%][r=9238MiB/s][r=2365k IOPS][eta 00m:00s]
/mnt/test: (groupid=0, jobs=32): err= 0: pid=3207: Fri Nov 29 16:00:13 2019
  read: IOPS=2374k, BW=9275MiB/s (9725MB/s)(1087GiB/120002msec)
    slat (usec): min=2, max=16031, avg= 7.39, stdev= 4.90
    clat (usec): min=27, max=16923, avg=419.32, stdev=123.28
     lat (usec): min=31, max=16929, avg=427.64, stdev=124.04
    clat percentiles (usec):
     |  1.00th=[  184],  5.00th=[  233], 10.00th=[  269], 20.00th=[  326],
     | 30.00th=[  363], 40.00th=[  388], 50.00th=[  412], 60.00th=[  437],
     | 70.00th=[  465], 80.00th=[  506], 90.00th=[  570], 95.00th=[  635],
     | 99.00th=[  775], 99.50th=[  832], 99.90th=[  971], 99.95th=[ 1037],
     | 99.99th=[ 1205]
   bw (  KiB/s): min=144568, max=397648, per=3.12%, avg=296776.28, stdev=46580.32, samples=7660
   iops        : min=36142, max=99412, avg=74194.06, stdev=11645.08, samples=7660
  lat (usec)   : 50=0.01%, 100=0.02%, 250=7.41%, 500=71.69%, 750=19.59%
  lat (usec)   : 1000=1.22%
  lat (msec)   : 2=0.07%, 4=0.01%, 10=0.01%, 20=0.01%
  cpu          : usr=37.12%, sys=62.66%, ctx=207950, majf=0, minf=1300
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=284924843,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32
 
Run status group 0 (all jobs):
   READ: bw=9275MiB/s (9725MB/s), 9275MiB/s-9275MiB/s (9725MB/s-9725MB/s), io=1087GiB (1167GB), run=120002-120002msec
 
Disk stats (read/write):
    md1: ios=284595182/7, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=71231210/1, aggrmerge=0/0, aggrticks=14348879/0, aggrin_queue=120, aggrutil=99.95%
  nvme0n1: ios=71231303/2, merge=0/0, ticks=14260383/0, in_queue=144, util=99.95%
  nvme3n1: ios=71231349/0, merge=0/0, ticks=14361428/0, in_queue=76, util=99.89%
  nvme2n1: ios=71231095/0, merge=0/0, ticks=14504766/0, in_queue=152, util=99.95%
  nvme1n1: ios=71231096/4, merge=0/1, ticks=14268942/0, in_queue=108, util=99.93%

2370 тыс. Операций ввода-вывода в секунду. Потрясающие цифры, не правда ли?

Написать тест

Готовы к тесту записи?

$ fio --bs=4k --direct=1 --rw=randwrite --randrepeat=0 --ioengine=libaio --iodepth=32 --runtime=120 --group_reporting --time_based --filesize=64m --numjobs=32 --name=/mnt/test
/mnt/test: (g=0): rw=randwrite, bs=® 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
[...]
fio-3.12
Starting 32 processes
Jobs: 32 (f=32): [w(32)][100.0%][w=6702MiB/s][w=1716k IOPS][eta 00m:00s]
/mnt/test: (groupid=0, jobs=32): err= 0: pid=3135: Fri Nov 29 15:55:10 2019
  write: IOPS=1710k, BW=6680MiB/s (7004MB/s)(783GiB/120003msec); 0 zone resets
    slat (usec): min=2, max=14920, avg= 6.88, stdev= 6.20
    clat (nsec): min=1152, max=18920k, avg=587644.99, stdev=735945.00
     lat (usec): min=14, max=18955, avg=595.46, stdev=736.00
    clat percentiles (usec):
     |  1.00th=[   21],  5.00th=[   33], 10.00th=[   46], 20.00th=[   74],
     | 30.00th=[  113], 40.00th=[  172], 50.00th=[  255], 60.00th=[  375],
     | 70.00th=[  644], 80.00th=[ 1139], 90.00th=[ 1663], 95.00th=[ 1991],
     | 99.00th=[ 3490], 99.50th=[ 3949], 99.90th=[ 4686], 99.95th=[ 5276],
     | 99.99th=[ 6521]
   bw (  KiB/s): min=97248, max=252248, per=3.12%, avg=213714.71, stdev=32395.61, samples=7680
   iops        : min=24312, max=63062, avg=53428.65, stdev=8098.90, samples=7680
  lat (usec)   : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.86%, 50=11.08%
  lat (usec)   : 100=15.35%, 250=22.16%, 500=16.34%, 750=6.69%, 1000=5.03%
  lat (msec)   : 2=17.66%, 4=4.38%, 10=0.44%, 20=0.01%
  cpu          : usr=20.40%, sys=41.05%, ctx=113183267, majf=0, minf=463
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,205207842,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32
 
Run status group 0 (all jobs):
  WRITE: bw=6680MiB/s (7004MB/s), 6680MiB/s-6680MiB/s (7004MB/s-7004MB/s), io=783GiB (841GB), run=120003-120003msec
 
Disk stats (read/write):
    md1: ios=0/204947351, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/51301962, aggrmerge=0/0, aggrticks=0/27227774, aggrin_queue=822252, aggrutil=100.00%
  nvme0n1: ios=0/51302106, merge=0/0, ticks=0/29636384, in_queue=865064, util=100.00%
  nvme3n1: ios=0/51301711, merge=0/0, ticks=0/25214532, in_queue=932708, util=100.00%
  nvme2n1: ios=0/51301636, merge=0/0, ticks=0/34347884, in_queue=1089896, util=100.00%
  nvme1n1: ios=0/51302396, merge=0/0, ticks=0/19712296, in_queue=401340, util=100.00%

1710 тыс. Операций ввода-вывода в секунду при записи ... Представьте, что вы могли бы сделать с таким решением для ваших баз данных или других высокоинтенсивных транзакционных сценариев использования .

Конечно, для этого примера мы представляем оптимальный сценарий. RAID 0 по своей природе опасен, поэтому любой сбой на одном из устройств NVMe может повредить ваши данные. Это означает, что вы обязательно должны создавать резервные копии критически важных данных, но это само по себе открывает множество новых возможностей. Так что мы на 100% уверены, что ваши базы данных полюбят эти экземпляры! Вы можете найти более подробную информацию о них на нашем  веб-сайте Public Cloud .

Одним из успехов OVHcloud является наша способность разрабатывать и продвигать инновации как в ИТ, так и в промышленных практиках. В течение двух десятилетий мы ставили инновации в центр нашей стратегии, это часть нашей ДНК. Мы постоянно исследуем и разрабатываем новые технологии, чтобы оптимизировать работу наших услуг.

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



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

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

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

2003-2008 гг.

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



Наши первые поколения технологии водоблоков были разработаны нашими командами и изготовлены на стороне. Эти водоблоки имели оптимальную производительность 60 Вт при температуре воды 30 ° C.

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



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

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

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



На разрезе водоблока показана ранняя структура теплогидравлики, где полностью гладкая поверхность основания образует резервуар с крышкой:

2011 г.

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



В течение этого периода мы по-прежнему разрабатывали наши водоблоки внутри и производили их внешне. Оптимальная мощность для этого поколения водоблоков — 60 Вт при температуре воды 30 ° C.

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

2013-2014 гг.

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



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

Прочие факторы

На этом этапе мы начали делать вариации водоблока, например адаптировать их к меньшим форм-факторам GPU:



Здесь вы можете сравнить стандартный водоблок процессора и более компактный водоблок графического процессора:



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



Хорошим примером является водоблок, который мы разработали для процессоров высокой плотности IBM Power 8. На следующем снимке вы можете увидеть крышку и опорные плиты этого специального водоблока:



Крышка и опорные пластины водяного блока, используемые в процессорах IBM Power8 высокой плотности

2015 и далее

В предыдущих абзацах описывалась наша технология водоблоков в 2014 году. С тех пор мы прошли долгий путь. Мы использовали новые технологии, такие как 3D-печать, и внесли некоторые фундаментальные изменения в дизайн.

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

Следите за нашей следующей публикацией, чтобы узнать больше о водяном охлаждении OVHcloud!

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



Совместное исследование в OVH через диссертацию

Тезис CIFRE означает на французском языке « Convention Industrielle de Formation par la Recherche», буквально « Промышленная конвенция для обучения через исследования». Цель состоит в том, чтобы поощрять исследовательское сотрудничество между частными и государственными организациями. Для предпринимателей и аспирантов CIFRE — это средство обучения посредством исследований и приобретения серьезных научных знаний. Для ученых это средство управления новым кандидатом наук и применения результатов исследований в экономическом кейсе. ANRT ассоциация управления CIFRE диссертацию.

OVH и ORKAD, исследовательская группа, специализирующаяся на комбинаторной оптимизации и извлечении знаний, начали сотрудничество в рамках диссертации CIFRE.

AutoML, как пример тезиса AI

настройки конвейеров машинного обучения ». MO расшифровывается как Multi-Objective и AutoML для автоматизированного машинного обучения.

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

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

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

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

OVH и AI

Конечно, тезис AutoML будет иметь множество последствий для OVH. С этого момента наша работа над машинным обучением позволила нам запустить Prescience в наших лабораториях. Prescience — это распределенная и масштабируемая платформа, которая позволяет пользователю создавать, развертывать и запрашивать модели машинного обучения.

В результате тесного сотрудничества с частным партнером NVIDIA, OVH предоставляет программную платформу NVIDIA GPU Cloud (NGC) в качестве эксклюзивного европейского продукта. Целью этого партнерства является облегчение доступа к искусственному интеллекту, позволяя пользователям запускать свою обработку через NGC на продуктах NVIDIA, размещенных в инфраструктуре OVH.

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



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

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

Начало Предвидения

В какой-то момент все проекты машинного обучения сталкиваются с одной и той же проблемой: как преодолеть разрыв между прототипом системы машинного обучения и ее использованием в производственном контексте. Это было краеугольным камнем при разработке платформы машинного обучения в OVH.

Производственные ноутбуки

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

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

Расширенное прототипирование

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

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

Расширение возможностей

В такой компании, как OVH, многие проблемы можно решить с помощью методов машинного обучения. К сожалению, невозможно назначить специалиста по данным для каждой из этих проблем, особенно если не установлено, стоит ли инвестировать в нее. Несмотря на то, что наши бизнес-специалисты не владеют всеми методами машинного обучения, они обладают обширным знанием данных. Основываясь на этих знаниях, они могут дать нам минимальное определение проблемы. Автоматизация предыдущих шагов (подготовка данных и выбор модели) позволяет специалистам быстро оценить возможные преимущества подхода машинного обучения. Затем для потенциальных проектов можно применить процесс быстрой победы / быстрой неудачи. Если это удастся, при необходимости мы можем привлечь к работе специалиста по данным.

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

Архитектура Prescience и рабочие процессы машинного обучения

По сути, платформа Prescience построена на технологиях с открытым исходным кодом, таких как Kubernetes для операций, Spark для обработки данных и Scikit-learn, XGBoost, Spark MLlib и Tensorflow для библиотек машинного обучения. Большая часть разработок Prescience заключалась в объединении этих технологий. Кроме того, все промежуточные выходные данные системы — такие как предварительно обработанные данные, этапы преобразования или модели — сериализуются с использованием технологий и стандартов с открытым исходным кодом. Это предотвращает привязку пользователей к Prescience на случай, если когда-нибудь возникнет необходимость в использовании другой системы.

Взаимодействие пользователя с платформой Prescience стало возможным за счет следующих элементов:

• пользовательский интерфейс
• клиент python
• REST API

Давайте рассмотрим типичный рабочий процесс и дадим краткое описание различных компонентов ...

Прием данных

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

• CSV, отраслевой стандарт
• Паркет, который довольно крутой (плюс автодокументированный и сжатый)
• Временные ряды, благодаря OVH Observability, на платформе Warp10

Необработанные данные, предоставленные каждым из этих источников, редко используются алгоритмами машинного обучения как есть. Алгоритмы обычно ожидают, что числа будут работать. Таким образом, первый шаг рабочего процесса выполняется компонентом Parser. Единственная задача парсера — обнаруживать типы и имена столбцов в случае текстовых форматов, таких как CSV, хотя исходники Parquet и Warp10 включают схему, что делает этот шаг спорным. После ввода данных парсер извлекает статистику, чтобы точно охарактеризовать ее. Полученные данные вместе со статистикой хранятся в нашем серверном хранилище объектов — публичном облачном хранилище на базе OpenStack Swift.

Преобразование данных

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

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

Выбор модели

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

Байесовская оптимизация

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

1. Модель находится в холодном состоянии. Оптимизатор возвращает контроллеру набор начальных конфигураций по умолчанию.
2. Контроллер распределяет начальные конфигурации по кластеру учащихся.
3. По завершении начальных настроек контроллер сохраняет результаты
4. Оптимизатор запускает вторую итерацию и обучает модель доступным данным.
5. На основе полученной модели оптимизатор выводит лучших претендентов, которые можно попробовать. Учитываются как их потенциальная эффективность, так и объем информации, которую они предоставят для улучшения модели выбора.
6. Контроллер распределяет новый набор конфигураций по кластеру и ожидает новой информации, также известной как недавно оцененные конфигурации. Конфигурации оцениваются с использованием перекрестной проверки в K-кратном порядке, чтобы избежать переобучения.
7. Когда становится доступной новая информация, запускается новая итерация оптимизации, и процесс начинается снова с шага 4.
8. После заданного количества итераций оптимизация останавливается.

Проверка модели

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

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

Модель сервировки

На этом этапе модель обучена, экспортируется и готова к обслуживанию. Последний компонент платформы Prescience — это Prescience Serving. Это веб-сервис, который использует PMML и сохраненные модели, а также предоставляет REST API поверх. Поскольку преобразования экспортируются вместе с моделью, пользователь может запросить новую развернутую модель, используя необработанные данные. Прогнозы теперь готовы к использованию в любом приложении.

Мониторинг модели

Кроме того, одной из характерных черт машинного обучения является его способность адаптироваться к новым данным. В отличие от традиционных, жестко заданных бизнес-правил, модель машинного обучения способна адаптироваться к базовым шаблонам. Для этого платформа Prescience позволяет пользователям легко обновлять источники, обновлять наборы данных и переобучать модели. Эти шаги жизненного цикла помогают поддерживать актуальность модели в отношении проблемы, которую необходимо решить. Затем пользователь может сопоставить свою частоту переобучения с генерацией новых квалифицированных данных. Они могут даже прервать процесс обучения в случае аномалии в конвейере генерации данных. Каждый раз, когда модель переобучается, вычисляется новый набор оценок и сохраняется в OVH Observability для мониторинга.

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

Переход к компании, управляемой искусственным интеллектом

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

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

Разработкой Prescience занимается команда Machine Learning Services. MLS состоит из четырех инженеров по машинному обучению: Маэля, Адриана, Рафаэля и меня. Команду возглавляет Гийом, который помог мне разработать платформу. Кроме того, в команду входят два специалиста по данным, Оливье и Клеман, которые занимались внутренними сценариями использования и предоставляли нам отзывы, и, наконец, Лоран: студент CIFRE, работающий над многоцелевой оптимизацией в Prescience в сотрудничестве с исследовательской группой ORKAD.