Русский
Русский
English
Статистика
Реклама

Google cloud

Парадокс доверия облачным решениям три сценария, в которых ключи шифрования хранятся не в облаке

16.03.2021 18:09:12 | Автор: admin

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

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

Сценарий 1. Данные, которые лучше не хранить в облаке

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

В каждой сфере и в каждой компании есть данные, которые попадают в эту категорию. Например, в одной международной организации действуют очень строгие правила в отношении хранения ключей. Чтобы использовать для этого облачные платформы, ей необходимо получать специальное разрешение. Другая организация руководствуется собственным вариантом стандарта PCI DSS. Кроме того, у нее есть внутренние требования по управлению главными ключами с помощью аппаратного модуля безопасности в соответствии со стандартом FIPS 140-2 (уровень 3).

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

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

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

Сценарий 2. Требования местного законодательства и проблемы, связанные с ними

С развитием облачных технологий порядок их использования во многом зависит от требований законодательства в тех или иных странах. В этом сценарии организация хочет использовать облачную платформу из другой страны, но ее не устраивает, что у поставщика услуг будут ключи шифрования для всех данных. Если в том же облаке будут обрабатываться незашифрованные данные, поставщик услуг получит доступ и к ним. Некоторые организации также не хотят хранить ключи на криптографических устройствах (например, аппаратных модулях безопасности), управляемых поставщиком услуг (физически или с помощью ПО). Они справедливо полагают, что такой подход не соответствует принципу Hold Your Own Key (HYOK).

Проблемы могут быть связаны как с требованиями законодательства, так и с описанными выше причинами. Кроме того, регулирующие органы ЕС, России, Японии, Индии, Бразилии и других стран постоянно принимают новые акты, запрещающие хранить незашифрованные данные и/или ключи шифрования за рубежом. В качестве примеров можно привести отраслевые стандарты (например, TISAX в Европе), которые указывают или подразумевают, что у поставщика облачных услуг ни при каких обстоятельствах не может быть доступа к данным, а во многих случаях и к ключам шифрования. Однакопредварительные результаты опросауказывают на то, что возможны варианты, когда ключи шифрования находятся только у клиента (в то время как зашифрованные данные могут храниться за рубежом).

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

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

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

Сценарий 3. Централизованное управление ключами шифрования

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

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

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

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

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

Дальнейшие действия

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

  • Прочитайтеэту статьюоб управлении ключами шифрования в облаке.

  • Оцените риски для данных с учетом уязвимостей, нормативных требований, отношений между странами ит.д.

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

Ознакомьтесь ссервисамиотGoogle Cloud EKM (External Key Manager) и партнеров (Ionic, Fortanix, Thales ит.д.), которые позволяют перенести управление ключами из облака в локальную среду.


Напоминаем что при первой регистрации в Google Cloud: вам доступны бонусы на сумму 300 долларов США, а более 20 бесплатных продуктов доступны всегда. Подробнее поспециальной ссылке.

А так же выражаем благодарность за помощь в подготовке материала коллегам: Антон Чувакин, Иль Сон Ли,Звиад Кардава

Подробнее..

Перевод Мой восьмилетний квест по оцифровке 45 видеокассет. Часть 1

23.10.2020 12:08:13 | Автор: admin
За последние восемь лет я перевозил эту коробку с видеокассетами в четыре разные квартиры и один дом. Семейные видеозаписи из моего детства.



Спустя более 600 часов работы я, наконец, оцифровал и нормально их организовал, так что кассеты можно выбросить.

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




Все семейные видео оцифрованы и доступны для просмотра с приватного медиасервера

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

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

Первая наивная попытка


Примерно в 2010 году моя мама купила какой-то конвертер VHS в DVD и прогнала через него все наши домашние видео.


Оригинальные DVD, которые записала мама (не знаю, что случилось с пропавшими буквами)

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

В 2012 году сестра подарила мне эти DVD-диски. Я скопировал видеофайлы и выложил всё в облачное хранилище. Проблема решена!


DVD-рипы семейных видео в хранилище Google Cloud

Через несколько недель я спросил, смотрел ли кто эти записи. Оказалось, что никто не смотрел. Даже я не смотрел. В эпоху YouTube глупо скачивать трёхчасовые файлы неизвестного содержания в поисках интересных кадров.

Только моя мама обрадовалась: Отлично, сказала она, теперь можно, наконец, выбросить все эти кассеты?

Ой-ёй. Это страшный вопрос. А если мы пропустили какие-то записи? Что, если кассеты можно оцифровать с более высоким качеством? Что, если на этикетках важная информация?

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

Я даже не подозревал, во что ввязываюсь.

Звучит не так уж и сложно


Если вы не понимаете, почему это заняло у меня восемь лет и сотни часов, я вас не виню. Я тоже думал, что всё будет легко.

Вот как выглядит процесс оцифровки от начала до конца:



Точнее, так он выглядит в теории. Вот как получилось на практике:



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

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

Шаг 1. Захват видео


Ладно, вернёмся в 2012 год. Маме очень хотелось выбросить кассеты, которые она хранила двадцать лет, поэтому при первой встрече она сразу вручила мне огромную картонную коробку. Так начался мой квест по оцифровке.

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

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

Спойлер: это оказалось действительно трудно.

Первая попытка захвата видео


У отца всё ещё хранился старый семейный видеомагнитофон, поэтому я попросил к следующему семейному ужину откопать его из подвала. Я купил дешёвый адаптер RCA-USB на Amazon и приступил к делу.


Устройство захвата видео TOTMC, первое из множества устройств A/V, которые я купил во время многолетнего квеста

Для обработки видео с устройства захвата USB я использовал программу VirtualDub, версия 2012 года немного устарела, но не критично.


Кадры в программе VirtualDub, как я в возрасте четырёх лет читаю книгу своему отцу

Напасть с искажением звука


Когда я начал процесс редактирования, то заметил небольшой рассинхрон аудио и видео. Ладно, без проблем. Я могу немного сдвинуть звук.

Через десять минут он снова рассинхронизировался. Разве я мало сдвинул его в первый раз?

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


Если ваша установка захватывает звук и видео с разной скоростью, то единственным решением является коррекция звука вручную каждые несколько минут

Представляете, как трудно отличить звук на 10 миллисекунд раньше или на 10 миллисекунд позже? Это действительно трудно! Судить сами.

На этом видео я играю со своим бедным, терпеливым котёнком, которого звали Black Magic. Звук немного не синхронизирован. Определите, он опережает картинку или идёт с опозданием?


Пример видеоклипа с рассинхроном звука и картинки

В этом месте Black Magic прыгает, фрагмент с замедлением в пять раз:


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

Ответ: звук идёт с опозданием в несколько миллисекунд.

Может, потратить лишнюю сотню долларов вместо сотен часов личного времени?


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


Моя вторая попытка приобрести устройство для видеозахвата

Даже с новым устройством рассинхрон никуда не исчез.

Видеомагнитофон с приставкой супер


Может, проблема в видеомагнитофоне. На форумах по оцифровке говорили, что рассинхрона не будет на видеомагнитофоне с корректором времени (time-based corrector, TBC), эта функция есть на всех видеомагнитофонах Super VHS (S-VHS).

Ну конечно! Зачем я возился с дурацким обычным видеомагнитофоном, когда есть супер-VCR, который решает проблему?

Никто уже не производит видеомагнитофоны S-VHS, но они по-прежнему доступны на eBay. За 179 долларов я купил модель JVC SR-V10U, которая вроде хорошо подходит для оцифровки VHS:


Винтажный видеомагнитофон JVC SR-V10U, который я купил на eBay за 179 долларов

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

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

Утомительный поиск, устранение неисправностей и многолетняя борьба


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

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

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

Я неизменно сдавался, всё отключал и прятал оборудование в шкаф ещё на несколько месяцев.

Сдаёмся и отдаём кассеты профессионалам


Наступил 2018 год. Я перетаскал видеокассеты и тонны оборудования по четырём разных квартирам и собирался переехать из Нью-Йорка в Массачусетс. Я не мог найти силы снова их везти, потому что уже понял, что самостоятельно никогда не закончу этот проект.

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

Я: Но это значит, что какая-то компания получит доступ ко всем нашим домашним видео. Тебя это устраивает?
Сестра: Да мне по барабану. Тебя одного это беспокоит. Погоди, так ты с самого начала мог просто заплатить кому-то?
Я: Э-э-э...

Оцифровка всех 45-ти кассет стоит $750. Кажется дорого, но к тому моменту я бы заплатил сколько угодно, лишь бы больше не разбираться с этим оборудованием.

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

Вот видео со сравнением профессиональной оцифровки и моих доморощенных попыток:


Сравнение профессиональной и самодельной оцифровки в видеоролике, где мама снимает мою первую попытку программирования

Шаг 2. Редактирование


В домашних съёмках около 90% материала скучны, 8% интересны, а 2% потрясающие. После оцифровки у вас ещё много работы.

Редактирование в Adobe Premiere


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

Для редактирования я использовал Adobe Premiere Elements, которая стоит меньше $100 за пожизненную лицензию. Его важнейшая фича масштабируемая временная шкала. Она позволяет быстро найти границы сцены, а затем увеличить масштаб, чтобы найти точный видеокадр, где начинается или заканчивается клип.


Важнейшая временная шкала с масштабированием в Adobe Premiere Elements

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

  1. Открыть сырой файл, который содержит 30-120 минут видео.
  2. Отметить границы отдельного клипа.
  3. Экспортировать клип.
  4. Подождать 2-15 минут, пока завершится экспорт.
  5. Повторять шаги 2-4, пока не закончится лента.

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

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

Автоматизация редактирования


После кучи времени, потраченного на ручную работу, я подумал, можно ли здесь как-то применить ИИ. Кажется, определение границ клипов подходящая задача для машинного обучения. Я знал, что точность будет не идеальной, но пусть он выполнит хотя бы 80% работы, а я исправлю последние 20%.

Я экспериментировал с инструментом под названием pyscenedetect, который анализирует видеофайлы и выдаёт временные метки, где происходят изменения сцены:

 $ docker run \    --volume "/videos:/opt" \    handflucht/pyscenedetect \    --input /opt/test.mp4 \    --output /opt \    detect-content --threshold 80 \    list-scenes[PySceneDetect] Output directory set:  /opt[PySceneDetect] Loaded 1 video, framerate: 29.97 FPS, resolution: 720 x 480[PySceneDetect] Downscale factor set to 3, effective resolution: 240 x 160[PySceneDetect] Scene list CSV file name format:  $VIDEO_NAME-Scenes.csv[PySceneDetect] Detecting scenes...[PySceneDetect] Processed 55135 frames in 117.6 seconds (average 468.96 FPS).[PySceneDetect] Detected 33 scenes, average shot length 55.7 seconds.[PySceneDetect] Writing scene list to CSV file:  /opt/test-Scenes.csv[PySceneDetect] Scene List:----------------------------------------------------------------------- | Scene # | Start Frame |  Start Time  |  End Frame  |   End Time   |----------------------------------------------------------------------- |      1  |           0 | 00:00:00.000 |        1011 | 00:00:33.734 | |      2  |        1011 | 00:00:33.734 |        1292 | 00:00:43.110 | |      3  |        1292 | 00:00:43.110 |        1878 | 00:01:02.663 | |      4  |        1878 | 00:01:02.663 |        2027 | 00:01:07.634 | ...

Инструмент действительно показал точность около 80%, но проверка его работы заняла больше времени, чем он сэкономил. Тем не менее, pyscenedetect сделал одно из самых важных открытий для всего проекта: определение границ сцены и экспорт клипов это отдельные задачи.

Я вспомнил, что я программист


До этого момента я считал редактированием всё, что делал в Adobe Premiere. Вырезание клипов из необработанных кадров казалось неразрывно связанным с поиском границ клипа, потому что именно так Premiere представлял эту задачу. Когда pyscenedetect распечатал таблицу метаданных, это заставило меня понять, что я могу отделить поиск сцен от экспорта видео. Это был прорыв.

Причина, по которой редактирование было таким утомительным и трудоёмким, заключалась в том, что мне приходилось ждать, пока Premiere экспортирует каждый клип. Если бы я записал метаданные в электронную таблицу и написал скрипт, который автоматически экспортирует видео, процесс редактирования пролетел бы незаметно.

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


Гигантская электронная таблица с метаданными о моих домашних видео

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


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

Успех автоматизированного решения


Имея электронные таблицы, я написал скрипт, который нарезал сырое видео на клипы на основе данных в CSV.

Вот запись как это выглядит в действии:



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

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

Часть 2


Оцифровка и редактирование видеоматериалов только половина дела. Нам ещё нужно найти удобный вариант публикации в интернете, чтобы все родственники смотрели семейное видео в удобном формате со стримингом как на YouTube.

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

P.S. От переводчика: Вторая часть выйдет сегодня во второй половине дня.



Подробнее..

Первое исследование состояния DevOps в России

11.08.2020 16:15:49 | Автор: admin
В 2019 году компания DORA и и Google Cloud выпустили совместный отчет The 2019 Accelerate State of DevOps: Elite performance, productivity, and scaling, из которого мы знаем, как в мире обстоят дела с DevOps. Это часть большого исследования DevOps, которым DORA занимается с 2013 года. За это время компания опросила уже 31 000 IT-специалистов по всему миру.



Исследование DORA проходит уже шесть лет и по нему видна динамика развития практик DevOps в мире. Но по этим результатам мы не можем объективно сказать в каком состоянии DevOps в России, сколько компаний внедрили практики, какие инструменты используют и получают ли пользу. Слишком мало данных за последние пару лет в опросах DORA поучаствовало меньше 60 человек из России. Мы хотим исправить эту ситуацию и запускаем исследование состояния DevOps в России.

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

Что это за исследование? Это изучение почти всего, что касается DevOps в российских компаниях в формате опроса. Задачу по составлению опроса и анализу данных взяла на себя компания Экспресс 42, а с запуском исследования помогает компания Онтико (Конференции Олега Бунина).

Для составления опроса и интерпретации результатов важны экспертиза и знание индустрии.

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

Зачем это нужно? Недавно Тимур Батыршин и Андрей Шорин поговорили с Product Ownerами для DevOps Live, и провели мини-исследование. Они выяснили, что скорость экспериментов определяет успех как стартапа, так и бизнеса со зрелым продуктом, что подтверждает важность DevOps для бизнеса. Своим исследованием мы копнем глубже, проверим какую еще выгоду получает бизнес и поймем, как развивается DevOps в России:

  • увидим срез индустрии на 2020 год;
  • поймём, помогли ли инженерные практики пережить пандемию;
  • узнаем, отличается ли DevOps в России и на Западе;
  • наметим зоны развития.

Как выглядит? Это анонимный опрос в SurveyMonkey из 60 вопросов на 30-35 минут.

О чём вас спросим? Например, об этом:

  • Какой размер вашей компании и в какой отрасли вы работаете?
  • Как ваша компания чувствует себя после пандемии?
  • Какие инструменты вы используете?
  • Какие практики используете в вашей команде?

Кто может участвовать? IT-специалисты любых компаний любого размера: инженеры, разработчики, тимлиды, CTO. Нам интересно посмотреть какие компании практикуют DevOps. Мы ждем ответы от каждого, кто знает слово DevOps участвуйте!

Как принять участие? Пройти опрос самому и пропиарить среди коллег в компании. Чем больше людей примут участие тем точнее результаты

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

Где появится результат? Отчет опубликуем на отдельной странице сайта Экспресс 42. Отдельно о результатах расскажем на конференции в специальном докладе. Идея конференции DevOps Live 2020 посмотреть на DevOps с разных сторон: с продуктовой, безопасности, со стороны разработчиков, инженеров и бизнеса, поэтому отчет будет как нельзя кстати.

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

  • Лотерея с ценными призами: 1 билет на конференцию HighLoad++, 5 билетов на конференцию DevOps Live и 30 книг по DevOps.
  • Скидка 42 тысячи рублей на годовую подписку курсов OTUS по программированию, управлению, Data Science, информационной безопасности и десяткам других.

Участвуйте в исследовании и делитесь ссылкой на него оставьте след в истории DevOps.
Подробнее..

Перевод TensorFlow на Google Cloud. Масштабируемый рабочий процесс

15.10.2020 16:12:34 | Автор: admin

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

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



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

  • Вам нужно создать высокопроизводительный дата-пайплайн? Изучите Apache Beam или Spark и буферы протоколов.
  • Нужно масштабировать обучение модели? Изучите AllReduce и многоузловые распределенные архитектуры.
  • Нужно развернуть свои модели? Изучите Kubernetes, TFServing, квантование и управление API.
  • Вам нужно отслеживать пайплайны? Настройте базу данных для метаданных, изучите Docker и станьте инженером DevOps.

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

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

  • TFRecorder (через Dataflow) : с легкостью превращайте данные внутри TFRecords в файл CSV. Для изображений предоставьте JPEG URI и метки в CSV. Масштабирование до распределенных серверов с помощью Dataflow без кода Apache Beam.
  • TensorFlow Cloud(через AI Platform Training): масштабируйте обучение модели TensorFlow для одно- и многоузловых кластеров графических процессоров на AI Platform Training с помощью простого вызова API.
  • AI Platform Predictions. Разверните свою модель в качестве конечной точки API для сервиса автомасштабирования (финансово поддерживаемого Kubernetes) с графическими процессорами, той самой, что используется Waze! О том, что это за компания можно почитать тут.
  • Weights & Biases. Логируйте наборы данных и модели, чтобы отслеживать версии и происхождение в пайплайне разработки. Дерево взаимосвязей между вашими экспериментами и артефактами создается автоматически.



Обзор рабочего процесса


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

  • Сохраните необработанные изображения JPEG в хранилище объектов, при этом каждое изображение находится в подпапке с указанием его метки.
  • Создайте файл CSV с URI изображений и метками в необходимом формате.
  • Преобразуйте изображения и метки в TFRecords
  • Создайте набор данных из TFRecords и обучите модель CNN с помощью Keras.
  • Сохраните модель как SavedModel и разверните как конечную точку API.
  • Изображения JPEG, TFRecords и SavedModels будут храниться в хранилище объектов.
  • Эксперименты и происхождение артефактов будут отслеживаться с помощью Weights & Biases.

Блокноты Jupyter Notebook и применяемые скрипты находятся в этом репозитории GitHub. Теперь давайте углубимся в каждый инструмент.

TFRecorder


TFRecords до сих пор запутывает меня. Я понимаю преимущество и обеспечиваемую производительность, но мне всегда было трудно с ними работать, когда я начинал работу с новым набором данных. Видимо, я не единственный, и, к счастью, проект TFRecorder недавно был выпущен. Работать c TFRecords еще никогда не было так просто, для этого требуется только (1) организация ваших изображений в виде логического каталога и (2) работа с фреймами Pandas и CSV. Вот предпринятые мной шаги:

  • Создание файла CSV с тремя столбцами, включая URI изображения, указывающий на расположение каталога каждого изображения.



  • Чтение CSV во фрейм данных pandas с вызовом функции TFRecorder для преобразования файлов в Dataflow с указанием выходного каталога.

dfgcs = pd.read_csv(FILENAME)dfgcs.tensorflow.to_tfr( output_dir=TFRECORD_OUTPUT, runner='DataFlowRunner', project=PROJECT, region=REGION, tfrecorder_wheel=TFRECORDER_WHEEL)

Вот оно! Менее 10 строк кода, которые масштабируются для преобразования миллионов изображений в формат TFRecord. Как Data Scientist, вы только что заложили основу для высокопроизводительного обучения. Взгляните на график и показатели задачи Dataflow в консоли Dataflow, если интересно узнать о волшебстве, происходящем в фоновом режиме.



Немного посмотрев код на GitHub, я выяснил схему tfrecorder:

tfr_format = {            "image": tf.io.FixedLenFeature([], tf.string),            "image_channels": tf.io.FixedLenFeature([], tf.int64),            "image_height": tf.io.FixedLenFeature([], tf.int64),            "image_name": tf.io.FixedLenFeature([], tf.string),            "image_width": tf.io.FixedLenFeature([], tf.int64),            "label": tf.io.FixedLenFeature([], tf.int64),            "split": tf.io.FixedLenFeature([], tf.string),        }

Затем вы можете прочитать TFRecords в TFRecordDataset для пайплайна обучения модели Keras с помощью такого кода:

IMAGE_SIZE=[150,150]BATCH_SIZE = 5def read_tfrecord(example):    image_features= tf.io.parse_single_example(example, tfr_format)    image_channels=image_features['image_channels']    image_width=image_features['image_width']    image_height=image_features['image_height']    label=image_features['label']    image_b64_bytes=image_features['image']        image_decoded=tf.io.decode_base64(image_b64_bytes)    image_raw = tf.io.decode_raw(image_decoded, out_type=tf.uint8)    image = tf.reshape(image_raw, tf.stack([image_height,    image_width, image_channels]))    image_resized = tf.cast(tf.image.resize(image, size=[*IMAGE_SIZE]),tf.uint8)    return image_resized, labeldef get_dataset(filenames):    dataset = tf.data.TFRecordDataset(filenames=filenames, compression_type='GZIP')     dataset = dataset.map(read_tfrecord)    dataset = dataset.shuffle(2048)    dataset = dataset.batch(BATCH_SIZE)    return datasettrain_dataset = get_dataset(TRAINING_FILENAMES)valid_dataset = get_dataset(VALID_FILENAMES)

TensorFlow Cloud (AI Platform Training)


Теперь, когда у нас есть tf.data.Dataset, передаем его в вызов обучения модели. Ниже приведен простой пример модели CNN, использующей Keras Sequential API.

model = tf.keras.models.Sequential([ tf.keras.layers.Conv2D(16, (3,3), activation='relu', input_shape=(150, 150, 3)), tf.keras.layers.MaxPooling2D(2, 2), tf.keras.layers.Conv2D(32, (3,3), activation='relu'), tf.keras.layers.MaxPooling2D(2,2), tf.keras.layers.Conv2D(64, (3,3), activation='relu'), tf.keras.layers.MaxPooling2D(2,2), tf.keras.layers.Conv2D(64, (3,3), activation='relu'), tf.keras.layers.MaxPooling2D(2,2), tf.keras.layers.Flatten(), tf.keras.layers.Dense(256, activation='relu'), tf.keras.layers.Dense(1, activation='sigmoid')])model.summary()model.compile(loss='binary_crossentropy', optimizer=RMSprop(lr=1e-4), metrics=['accuracy'])model.fit( train_dataset, epochs=10, validation_data=valid_dataset, verbose=2)

Сначала я запустил этот код в своей среде разработки на подмножестве изображений (в моем случае в блокноте Jupyter Notebook), но хотел масштабировать его для всех изображений и сделать это быстрее. TensorFlow Cloud позволяет мне использовать одну команду API, которая отправляет код в контейнер и на запуск в качестве распределенного задания GPU.

import tensorflow_cloud as tfctfc.run(entry_point='model_training.ipynb', chief_config=tfc.COMMON_MACHINE_CONFIGS['T4_4X'], requirements_txt='requirements.txt')

Это не первоапрельская шутка. Три строки кода это полноценный скрипт на Python, который нужно поместить в тот же каталог, что и ваш блокнот Jupyter. Самая сложная часть инструкция настройки, проверка того, что вы правильно аутентифицированы в своем проекте Google Cloud Platform. Углубимся в происходящее. Сначала создается контейнер Docker со всеми необходимыми библиотеками и блокнотом, который сохраняется в сервисе реестра контейнеров Google Cloud.



Затем этот контейнер передается в полностью управляемую бессерверную службу обучения AI Platform Training. Без необходимости настраивать инфраструктуру и устанавливать какие-либо библиотеки графических процессоров, я смог обучить эту модель на машине с 16 виртуальными ЦП и 60 ГБ оперативной памяти и 4 графическими процессорами Nvidia T4. Я использовал эти ресурсы только тогда, когда они мне были нужны (~15 минут), и могу вернуться к разработке в своей локальной среде с помощью IDE или Jupyter Notebook.



SavedModel, наконец, сохраняется в хранилище объектов, как указано в самом конце скрипта обучения.

MODEL_PATH=time.strftime(gs://mchrestkha-demo-env-ml-examples/catsdogs/models/model_%Y%m%d_%H%M%S)model.save(MODEL_PATH)

AI Platform Predictions


Имея свою модель SavedModel в хранилище объектов, я могу загрузить ее в свою среду разработки и выполнить несколько примерных прогнозов. Но что, если я хочу позволить другим работать с моделью без необходимости настраивать среду Python и изучать TensorFlow. Здесь на сцену выходит AI Platform Predictions. Он позволяет развертывать двоичные файлы модели в качестве конечных точек API, которые вызываются с помощью REST, простого Google Cloud SDK (gcloud) или других клиентских библиотек. Пользователи должны знать, что это требуемые входные данные (в нашем случае файл изображения JPEG, преобразованный в массив JSON [150,150,3]), а также знать, могут ли они встроить модель в свой рабочий процесс. Когда вы вносите изменения (заново обучите модель на новом наборе данных, новой архитектуре модели, возможно, даже используете новый фреймворк), то можете опубликовать новую версию. Приведенный ниже простой пример скрипта с SDK gcloud крайне полезен для развертывания моделей в этом сервисе автоматического масштабирования, поддерживаемом Kubernetes.

MODEL_VERSION="v1"MODEL_NAME="cats_dogs_classifier"REGION="us-central1"gcloud ai-platform models create $MODEL_NAME \    --regions $REGIONgcloud ai-platform versions create $MODEL_VERSION \  --model $MODEL_NAME \  --runtime-version 2.2 \  --python-version 3.7 \  --framework tensorflow \  --origin $MODEL_PATH

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

Weights & Biases


Я завершил эксперимент. Но как насчет будущих экспериментов? Мне может понадобиться:

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

Много работы делается на просторе ML пайплайнов. Это захватывающая, но только зарождающаяся область с лучшими практиками и отраслевыми стандартами, которые еще предстоит разработать. Некоторые замечательные проекты включают MLFlow, пайплайны Kubeflow, TFX и другие. Comet.ML для нужд моего рабочего процесса MLOps и непрерывная доставка находились вне поля зрения, и я хотел что-то простое. Я выбрал Weights & Biases (WandB) из-за простоты применения и легкой интеграции для отслеживания экспериментов и артефактов.

Начнем с экспериментов. WandB предлагает множество вариантов настройки, но если вы работаете с любым из популярных фреймворков, нужно сделать не много. В случае TensorFlow Keras API я просто (1) импортировал библиотеку python wandb (2) инициализировал запуск эксперимента и (3) добавил функцию обратного вызова в рамках шага обучения модели.

model.fit( train_dataset, epochs=10, validation_data=valid_dataset, verbose=2, callbacks=[WandbCallback()])

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





WandB также предоставляет API артефактов, который соответствует моим потребностям намного больше, чем некоторые из тяжелых инструментов, существующих сегодня. Я добавил короткие фрагменты кода по всему конвейеру, чтобы определить 4 ключевых элемента:

  1. Инициализация шага в моем пайплайне
  2. Использование существующего артефакта (когда он есть) в рамках этого шага
  3. Логирование артефакта, созданного на этом шаге
  4. Указание на завершение шага

run = wandb.init(project='cats-dogs-keras', job_type='data', name='01_set_up_data')<Code to set up initial JPEGs in the appropriate directory structure>artifact = wandb.Artifact(name='training_images',job_type='data', type='dataset')artifact.add_reference('gs://mchrestkha-demo-env-ml-examples/catsdogs/train/')run.log_artifact(artifact)run.finish()run = wandb.init(project='cats-dogs-keras',job_type='data', name='02_generate_tfrecords')artifact = run.use_artifact('training_images:latest')<TFRecorder Code>artifact = wandb.Artifact(name='tfrecords', type='dataset')artifact.add_reference('gs://mchrestkha-demo-env-ml-examples/catsdogs/tfrecords/')run.log_artifact(artifact)run.finish()run = wandb.init(project='cats-dogs-keras',job_type='train', name='03_train')artifact = run.use_artifact('tfrecords:latest')<TensorFlow Cloud Code>artifact = wandb.Artifact(name='model', type='model')artifact.add_reference(MODEL_PATH)run.log_artifact(artifact)

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



Заключение


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

  • Будьте практичны: нереально всем нам быть фулстек-инженерами в DevOps, Data и Machine Learning. Выберите одну или две области, которые вас интересуют, и работайте с другими для решения общесистемных проблем.
  • Сосредоточьтесь на своей проблеме: все мы увлекаемся новым фреймворком, новой исследовательской работой, новым инструментом. Начните с вашей бизнес-задачи, вашего набора данных, ваших требований к конечному пользователю. Не всем нужны 100 моделей ML в производстве, которые ежедневно переобучаются и обслуживаются миллионами пользователей (по крайней мере, пока).
  • Определитесь с инструментами найдите основной набор инструментов, действительно умножают эффективность, обеспечивают масштабируемость и устраняет сложность. Я прошелся по своему набору инструментов для Tensorflow (TFRecorder + TensorFlow Cloud + AI Platform Predictions + Weights & Biases), но нашел правильный инструментарий, который соответствует вашей проблеме и рабочему процессу.

Примеры Jupyter Notebook из этого поста можно найти на моем GitHub.

А прокачать себя по-максимуму в Data Science, аналитике или машинном обучении, можно под чутким руководством наших менторов.

image




Читать еще


Подробнее..

Хранение данных в кластере Kubernetes

15.09.2020 02:12:09 | Автор: admin

Настроить хранение данных приложений, запущенных в кластере Kubernetes, можно несколькими способами. Одни из них уже устарели, другие появились совсем недавно. В этой статье рассмотрим концепцию трёх вариантов подключения СХД, в том числе самый последний подключение через Container Storage Interface.



Способ 1. Указание PV в манифесте пода


Типичный манифест, описывающий под в кластере Kubernetes:



Цветом выделены части манифеста, где описано, какой том подключается и куда.


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


В разделе x перечисляют все тома, которые используются в поде. Указывают имя каждого тома, а также тип (в нашем случае: awsElasticBlockStore) и параметры подключения. Какие именно параметры перечисляются в манифесте, зависит от типа тома.


Один и тот же том может быть смонтирован одновременно в несколько контейнеров пода. Таким образом разные процессы приложения могут иметь доступ к одним и тем же данным.


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


При его использовании возникает несколько проблем:


  1. все тома надо создавать вручную, Kubernetes не сможет создать ничего за нас;
  2. параметры доступа к каждому из томов уникальные, и их надо указывать в манифестах всех подов, которые используют том;
  3. чтобы поменять систему хранения (например, переехать из AWS в Google Cloud), надо менять настройки и тип подключённых томов во всех манифестах.

Всё это очень неудобно, поэтому в реальности подобным способом пользуются для подключения только некоторых специальных типов томов: configMap, secret, emptyDir, hostPath:


  • configMap и secret служебные тома, позволяют создать в контейнере том с файлами из манифестов Kubernetes.


  • emptyDir временный том, создаётся только на время жизни пода. Удобно использовать для тестирования или хранения временных данных. Когда pod удаляется, том типа emptyDir тоже удаляется и все данные пропадают.


  • hostPath позволяет смонтировать внутрь контейнера с приложением любой каталог локального диска сервера, на котором работает приложение, в том числе /etc/kubernetes. Это небезопасная возможность, поэтому обычно политики безопасности запрещают использовать тома этого типа. Иначе приложение злоумышленника сможет замонтировать внутрь своего контейнера каталог HTC Kubernetes и украсть все сертификаты кластера. Как правило, тома hostPath разрешают использовать только системным приложениям, которые запускаются в namespace kube-system.



Cистемы хранения данных, с которыми Kubernetes работает из коробки приведены в документации.


Способ 2. Подключение к подам SC/PVC/PV


Альтернативный способ подключения концепция Storage class, PersistentVolumeClaim, PersistentVolume.


Storage class хранит параметры подключения к системе хранения данных.


PersistentVolumeClaim описывает требования к тому, который нужен приложению.
PersistentVolume хранит параметры доступа и статус тома.


Суть идеи: в манифесте пода указывают volume типа PersistentVolumeClaim и указывают название этой сущности в параметре claimName.



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


  • размер диска;
  • способ доступа: ReadWriteOnce или ReadWriteMany;
  • ссылка на Storage class в какой системе хранения данных мы хотим создавать том.

В манифесте Storage class хранятся тип и параметры подключения к системе хранения данных. Они нужны кублету, чтобы смонтировать том к себе на узел.


В манифестах PersistentVolume указывается Storage class и параметры доступа к конкретному тому (ID тома, путь, и т. д.).


Создавая PVC, Kubernetes смотрит, том какого размера и из какого Storage class потребуется, и подбирает свободный PersistentVolume.


Если таких PV нет в наличии, Kubernetes может запустить специальную программу Provisioner (её название указывают в Storage class). Эта программа подключается к СХД, создаёт том нужного размера, получает идентификатор и создает в кластере Kubernetes манифест PersistentVolume, который связывается с PersistentVolumeClaim.


Всё это множество абстракций позволяет убрать информацию о том, с какой СХД работает приложение, с уровня манифеста приложений на уровень администрирования.


Все параметры подключения к системе хранения данных находятся в Storage class, за который отвечают администраторы кластера. Всё, что надо сделать при переезде из AWS в Google Cloud, это в манифестах приложения изменить название Storage class в PVC. Persistance Volume для хранения данных будут созданы в кластере автоматически, с помощью программы Provisioner.


Способ 3. Container Storage Interface


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


Чтобы решить проблему, разработчики из Cloud Foundry, Kubernetes, Mesos и Docker создали Container Storage Interface (CSI) простой унифицированный интерфейс, который описывает взаимодействие системы управления контейнерами и специального драйвера (CSI Driver), работающего с конкретной СХД. Весь код по взаимодействию с СХД вынесли из ядра Kubernetes в отдельную систему.


Документация по Container Storage Interface.


Как правило, CSI Driver состоит из двух компонентов: Node Plugin и Controller plugin.


Node Plugin запускается на каждом узле и отвечает за монтирование томов и за операции на них. Controller plugin взаимодействует с СХД: создает или удаляет тома, назначает права доступа и т. д.


Пока в ядре Kubernetes остаются старые драйверы, но пользоваться ими уже не рекомендуют и всем советуют устанавливать CSI Driver конкретно для той системы, с которой предстоит работать.


Нововведение может напугать тех, кто уже привык настраивать хранение данных через Storage class, но на самом деле ничего страшного не случилось. Для программистов точно ничего не меняется они как работали только с именем Storage class, так и продолжат. Для администраторов добавилась установка helm chart и поменялась структура настроек. Если раньше настройки вводились в Storage class напрямую, то теперь их сначала надо задать в helm chart, а потом уже в Storage class. Если разобраться, ничего страшного не произошло.


Давайте, на примере, рассмотрим какие преимущества можно получить, перейдя на подключение СХД Ceph с помощью CSI драйвера.


При работе с Ceph плагин CSI даёт больше возможностей для работы с СХД, чем встроенные драйверы.


  1. Динамическое создание дисков. Обычно диски RBD используются только в режиме RWO, а CSI для Ceph позволяет использовать их в режиме RWX. Несколько pod'ов на разных узлах могут смонтировать один и тот же RDB-диск к себе на узлы и работать с ними параллельно. Справедливости ради, не всё так лучезарно этот диск можно подключить только как блочное устройство, то есть придётся адаптировать приложение под работу с ним в режиме множественного доступа.
  2. Создание снапшотов. В кластере Kubernetes можно создать манифест с требованием создать снапшот. Плагин CSI его увидит и сделает снапшот с диска. На его основании можно будет сделать либо бэкап, либо копию PersistentVolume.
  3. Увеличение размера диска на СХД и PersistentVolume в кластере Kubernetes.
  4. Квоты. Встроенные в Kubernetes драйверы CephFS не поддерживают квоты, а свежие CSI-плагины со свежим Ceph Nautilus умеют включать квоты на CephFS-разделы.
  5. Метрики. CSI-плагин может отдавать в Prometheus множество метрик о том, какие тома подключены, какие идут взаимодействия и т. д.
  6. Topology aware. Позволяет указать в манифестах, как географически распределён кластер, и избежать подключения к подам, запущенным в Лондоне системы хранения данных, расположенной в Амстердаме.

Как подключить Ceph к кластеру Kubernetes через CSI, смотрите в практической части лекции вечерней школы Слёрм. Так же можно подписаться на видео-курс Ceph, который будет запущен 15 октября.


Автор статьи: Сергей Бондарев, практикующий архитектор Southbridge, Certified Kubernetes Administrator, один из разработчиков kubespray.


Немного Post Scriptum не рекламы для, а пользы ради...

P.S. Сергей Бондарев ведёт два интенсива: обновлённый Kubernetes База 28-30 сентября и продвинутый Kubernetes Мега 1416 октября.


Подробнее..

Веб-клиент Google Cloud Text to Speech за завтраком в бастионе Сен-Жерве

13.04.2021 04:20:54 | Автор: admin

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

Вообще, если интерес возникнет, то это всегда 90% успеха, поверьте... ну, а если не возникнет, что ж. Сэкономите время: стало быть, не ваше. Сейчас, таким образом, самонадеянный и скорый на подъем аффтор, всегда готовый выхватить шпагу при виде гнусного тролля на любом интернет-форуме - предлагает всем dbutants потратить всего лишь полчаса-час на то, чтобы заинтересоваться сразу несколькими технологиями, в числе которых язык программирования Ruby, API Google Cloud Text to Speech, облачная PaaS-платформа Heroku и git.

К слову. Предвидя сделанные на языке растреклятых англичан, исконных врагов любого истинного француза комментарии в стиле "Is ruby dead?", в том смысле, а есть ли смысл вообще этим заниматься... автор предлагает всем любителям потрепаться-ни-о-чем-в-инете временно оставить эту животрепещущую тематику, сменив ее на рекомендации по изготовлению чудодейственного бальзама, наподобие того, что дала в путь-дорогу д`Артаньяну любящая его матушка, и который помог бы, в духе дня, раз и навсегда избавиться от спама за подписью того или иного эйчара, русскоговорящего или европейца/американца, несколько раз в неделю присылающих абсолютно ненужные автору инвайты на позицию Ruby Developer. Ненужные не потому, что автор, вволю напрактиковавшись и слегка "подточив" теорию, привык получать приглашения исключительно и самолично из рук аж самого CTO Armand-Jean du Plessis, duc de Richelieu... а потому, что за все годы работы - ни одного проекта, ни одной должности от HR он не получил, так уж сложилось.

Чего и вам от души желает. Если какой-либо институт и мертв, то это почти наверняка Human Resource, по крайней мере, у нас в России (как с этим обстоят дела у Бекингема - Бог весть, не знаю). Все остальное покамест работает... это была, так сказать, литературная прелюдия, ну а теперь сходу к практике, с места в карьер. "Сударь, вы ошиблись! Нас не трое, нас четверо!"

Итак. Цель сегодняшних наших упражнений - построение приложения, работающего с API Google Cloud Text to Speech, иными словами - конвертера текста в звук, и с очень неплохим качеством. Правда, все чаще раздаются голоса, дескать, IBM Text-to-Speech API круче, но это мы оставим, с вашего позволения, для следующей статьи... "голоса" обычно не скрывают, что IBM API обходится недешево, гугловский же сервис возможно использовать практически бесплатно (находим и внимательно читаем Terms of Service). Но вам понадобится волшебный ключ, нечто в стиле "то, что сделал предъявитель сего, сделано по моему приказанию и для блага государства" в формате JSON, для получения которого, вполне возможно, придется засветить ваш MasterCard здесь. Может быть, даже заморозят на недельку кровный ваш $1, ничего? - ну всяко это не так страшно, как в военное де-факто время совершать вояж за линию фронта, будучи вдохновленным одним лишь лукавым взглядом г-жи Бонасье, согласитесь.

Также зарегистрируйте Free account Heroku, куда мы с вами намереваемся пушить ваше первое приложение на основе фреймворка Ruby on Rails, скачайте и установите git и Heroku toolbelt для своей OS.

Немного о структуре приложения. Как уже сказано выше, это rails-app, полноценный веб-интерфейс для API Google Cloud Text to Speech: аутентификация реализована посредством device (полистайте доку, там немало интересного на случай, если захотите что-то изменить в предлагаемом техническом решении), сконфигурированного таким образом, что возможен лишь один пользователь. Что нам и нужно: сразу после деплоя приложения на Heroku вы зарегистрируетесь в нем, подтвердив указанный вами email, и дальнейшие регистрации будут невозможны (изменить или сбросить пароль вы, при необходимости, сможете).

Интерфейс выполнен в духе минимализма, под которым автор понимает Bootstrap 4 и кое-какие джаваскрипты; информационные flash-сообщения панели управления - средствами ajax, благо он как никто родной для Ruby on Rails. Заказчик-киевлянин, для которого был выполнен этот rails-app, он же старый мой приятель, скупой как кардинал Мазарини - очень просил "без излишеств, можно вообще без стилей", ну и вот... впрочем, помимо ожидания, получилось вполне элегантно. Представленный далее короткий ролик не самый новый, с момента его создания приложение было рефакторено и получило новые свойства, но какое-то визуальное представление способен дать.

Да, и "о фичах". На момент публикации этого материала Google-Cloud-TTS-Rails способен работать с текстом (также поддерживается SSML) на любом из 18 языков, конвертируя в один из следующих, по желанию, форматов: MP3 (MPEG Audio Layer III), WAV (LINEAR16) and OGG (OGG_OPUS), поддерживаются оба доступных voice type: WaveNet и Basic. Также интерфейс приложения позволяет корректировать скорость произношения...

...с чего, пожалуй, и начнем этот краткий экскурс в программный код. Меню регулировки скорости реализовано как хелпер, посредством которого получаем в HTML выпадающее меню (drop-down list), диапазон значений от 0.25 до 4.0 (обусловлено API), шаг 0.25, значение по-дефолту 1.0. Привыкайте, это рельсы:

module SoundHelper  def speaking_rate    select_tag 'speaking_rate', options_for_select(      0.25.step(by: 0.25, to: 4.0), selected: '1.0'    ), { class: 'btn' }  endend

Да, к слову. Те, кто не хотят вникать в код, возможно, им это сто лет не нужно... имеют возможность пропустить вышесказанное/поименованное мимо, соответственно, ушей и глаз, равно как и еще парочку фрагментов кода, воспоследующих далее. Имеете полное право, почему нет. Я сейчас сделаю краткую паузу на то, чтобы in two words рассказать, как залить из гитхаба на Heroku полностью готовое к работе приложение, вам понадобятся на вашем рабочем компе лишь Heroku CLI и git, как уже и говорил. Ruby и postgreSQL в этом случае без надобности.

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

git clone https://github.com/cmirnow/Google-Cloud-TTS-Rails.gitcd Google-Cloud-TTS-Rails

Бросьте файл, содержащий ваш персональный ключ YOUR_KEY_NAME.json, в корень директории приложения (название значения не имеет). Далее:

git add .   git commit -m "my first commit"heroku creategit push heroku masterheroku run rake db:migrate

Откройте панель администрирования Heroku, YOUR_NEW_APPLICATION -> 'Settings' -> 'Reveal Config Vars', и введите следующие пары key/value:


key: GOOGLE_APPLICATION_CREDENTIALS value: YOUR_KEY_NAME.json

key: DOMAIN_NAME value: YOUR_HEROKU_DOMAIN ### i.e 'https://***************.herokuapp.com' without quotes.

key: GMAIL_USER_NAME value: YOUR_GMAIL_LOGIN

key: GMAIL_PASSWORD value: YOUR_GMAIL_PASSWORD ### (An App Password is a 16-digit passcode that gives an app or device restricted access to your Google Account without having to divulge your personal password and complete access to your Google Account).


Как видите, потребуется указать доступ к почтовому серверу, чтобы Google-Cloud-TTS-Rails смог отослать вам письмо в ходе регистрации аккаунта, также на случай необходимости сброса забытого пароля. И - на этом все, после регистрации приложение полностью готово к работе. Лимит текста "за один раз" - 5000 знаков, обусловлено Google. Надеюсь, вам понравится.

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

class Validationinclude ActiveModel::Modelattr_accessor :requestvalidates :request, presence: true, length: {in:3..4999}end

Контроллер, как ему и предназначено судьбой, служит связующим звеном между интерфейсом пользователя и собсно сервисом, вызывая метод класса TtsConversion со следующими параметрами:

  def conversion    audio_format = TtsConversion.index(client, synthesis_input, voice, audio, params[:codec])    success_info(audio_format)  end  def client    Google::Cloud::TextToSpeech.text_to_speech  end  def synthesis_input    { params[:text_or_ssml] => params[:request] }  end  def voice    { language_code: params[:lang], name: params[:voicename] }  end  def audio    { audio_encoding: params[:codec], speaking_rate: params[:speaking_rate].to_f }  end
class TtsConversion  def self.index(*args)    response = args[0].synthesize_speech input: args[1], voice: args[2], audio_config: args[3]    File.open 'public/output/output.' + audio_format(args[4]).to_s, 'wb' do |file|      file.write response.audio_content      audio_format(args[4]).to_s    end  end  def self.audio_format(codec)  case codec  when "LINEAR16"  'wav'    when "OGG_OPUS"      'ogg'  else  'mp3'  end  endend

Всю работу свершает, по сути, gem 'google-cloud-text_to_speech', передавая конвертируемый текст и выбранные параметры в API Google Cloud Text to Speech и получая обратно звук в цифре. Вот, пожалуй, и все.

Подробнее..

Перевод Дорогой Google Cloud, отказ от обратной совместимости тебя убивает

15.09.2020 18:11:52 | Автор: admin
Чёрт возьми, Google, я не хотел снова писать в блог. У меня так много дел. Ведение блога требует времени, энергии и креатива, которые я мог бы использовать с пользой: мои книги, музыка, моя игра и так далее. Но ты меня достаточно разозлил, и придётся это написать.

Так что давай покончим с этим.

Начну с небольшой, но поучительной истории из тех времён, когда я только начал работать в Google. Знаю, что в последнее время я наговорил много плохого о Google, но меня расстраивает, когда родная компания регулярно принимает некомпетентные бизнес-решения. При этом нужно отдать должное: внутренняя инфраструктура Google действительно экстраординарная, можно смело утверждать, что сегодня нет ничего лучше. Основатели Google были гораздо лучшими инженерами, чем я когда-либо стану, и эта история только подтверждает данный факт.

Сначала немного предыстории: у Google есть технология хранения данных под названием Bigtable. Это было замечательное техническое достижение, одно из первых (если не первое) бесконечно масштабируемое хранилище пар ключ-значение (key-value store, K/V): по сути, начало NoSQL. В наши дни Bigtable всё ещё хорошо чувствует себя в довольно переполненном пространстве хранилищ K/V, но в то время (2005 год) оно было потрясающе крутое.

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

Еще одна интересная деталь заключается в том, что на какое-то время Bigtable стали популярными и вездесущими внутри Google, и у каждой команды было своё хранилище. Поэтому на одном из пятничных собраний Ларри Пейдж небрежно спросил мимоходом: А почему у нас больше одного Bigtable? Почему не обойтись только одним? Теоретически, одного хранилища должно было хватить для всех потребностей хранения Google. Конечно, они никогда не переходили только на одно по практическим причинам разработки (например, последствия потенциального сбоя), но теория была интересной. Одно хранилище для всей Вселенной (кстати, кто-нибудь знает, Amazon такое сделала со своим Sable?)

Так или иначе, вот моя история.

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

Уважаемый Стив,

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

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

Всего наилучшего,
Команда Bigtable

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

Уважаемый получатель,

Привет от какой-то команды. Мы хотим сообщить, что бла-бла-бла-бла-бла. Бла-бла-бла-бла-бла-бла, и бла-бла-бла немедленно.

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

Всего наилучшего,
Какая-то команда

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

Но это было странно.

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

Они явно назвали моё имя. И письмо отправлено на мой адрес электронной почты, а не на чей-то ещё, и это не cc: или bcc:. Тон очень личный и чёткий. Может, это какая-то ошибка?

Наконец, любопытство взяло верх и я пошёл взглянуть на консоль Borg в дата-центре, который они упомянули.

И конечно, у меня в управлении было хранилище BigTable. Что-что? Я взглянул на его содержимое, и надо же! Оно было из инкубатора Codelab, в котором я сидел первую неделю работы в Google в июне 2005 года. Codelab заставлял вас запустить Bigtable, чтобы вы записали туда некоторые значения, и я, видимо, так и не закрыл хранилище после этого. Оно всё ещё работало, хотя прошло более двух лет.

В этой истории есть несколько примечательных аспектов. Во-первых, работа Bigtable был настолько несущественна в масштабе Google, что только через два года лишнее хранилище кто-то заметил, да и то лишь потому, что версия бинарника устарела. Для сравнения, я когда-то рассматривал возможность использования Bigtable в Google Cloud для моей онлайн-игры. В то время эта услуга стоила примерно $16000 в год за пустую Bigtable на GCP. Я не говорю, что они вас обманывают, но, по моему личному мнению, это большие деньги за пустую грёбаную базу данных.

Ещё один примечательный аспект заключается в том, что хранилище по-прежнему работало через два года. WTF? Дата-центры приходят и уходят; они испытывают перебои, они проходят плановое техническое обслуживание, они всё время меняются. Железо обновляется, коммутаторы меняются местами, всё постоянно совершенствуется. Как, чёрт возьми, они смогли сохранить мою программу запущенной в течение двух лет с учётом всех этих изменений? Это может показаться скромным достижением в 2020 году, но в 2005-2007 годах оно было весьма впечатляющим.

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

Я поблагодарил их, удалил хранилище, и жизнь пошла своим чередом. Но тринадцать лет спустя я всё ещё думаю об этом письме. Потому что иногда мне приходят подобные письма от Google Cloud. Они выглядят так:

Уважаемый пользователь Google Cloud,

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

Мы стремимся к тому, чтобы это изменение минимально повлияло на всех пользователей платформы Google Cloud.

Лучшие друзья навсегда,
Облачная платформа Google

Но я почти не читаю такие письма, потому что на самом деле в них говорится следующее:

Уважаемый получатель,

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

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

Пожалуйста иди нах,
Облачная платформа Google

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

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

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

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

Первая система, которую я выберу, самая старая: GNU Emacs, это своего рода гибрид между Блокнотом Windows, ядром ОС и Международной космической станцией. Это немного сложно объяснить, но в двух словах Emacs это платформа, созданная в 1976 году (да, почти полвека назад) для программирования, чтобы повысить вашу продуктивность, но маскируется под текстовый редактор.

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

Я по-прежнему использую программное обеспечение, которое написал для Emacs ещё в 1995 году. И уверен, что кто-то используют модули, написанное для Emacs в середине 80-х, если не раньше. Время от времени они могут потребовать незначительной настройки, но это действительно довольно редко. Я не знаю ничего из того, что я когда-либо писал для Emacs (а я написал много), в чём пришлось бы перестроить архитектуру.

В Emacs есть функция под названием make-obsolete для устаревших сущностей. Терминология Emacs для фундаментальных компьютерных концепций (например, что такое окно) часто отличается от отраслевых конвенций, потому что Emacs ввёл их очень давно. Это типичная опасность для тех, кто опередил своё время: все ваши термины некорректны. Но в Emacs действительно есть концепция устаревания, которая на их жаргоне называется obsolescence.

Но в мире Emacs, похоже, другое рабочее определение. Другая основополагающая философия, если хотите.

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

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

Это всё равно что продавать подержанный автомобиль, который точно сломается через 1500 км.

Это два совершенно разных философских определения устаревания. Определение Google пахнет запланированным устареванием. Я не верю, что это на самом деле запланированное устаревание в том же смысле, как у Apple. Но Google определённо планирует сломать ваши программы, окольным путём. Я знаю это, потому что проработал там инженером-программистом более 12 лет. У них есть расплывчатые внутренние рекомендации, в какой мере следует соблюдать обратную совместимость, но в конечном итоге это зависит от каждой отдельной команды или службы. Нет никаких рекомендаций корпоративного или инженерного уровня, и самая смелая рекомендация с точки зрения циклов устаревания это попробуйте дать клиентам 6-12 месяцев на обновление, прежде чем сломать им всю систему.

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

На данный момент я собираюсь сделать смелое утверждение, что Emacs успешен в значительной степени и даже в основном потому, что они так серьёзно относятся к обратной совместимости. Собственно, это и есть тезис нашей статьи. Успешные долгоживущие открытые системы обязаны своим успехом микросообществам, которые десятилетиями живут вокруг расширений/плагинов. Это и есть экосистема. Я уже рассуждал о сути платформ и о том, насколько они важны, и о том, что Google никогда за всю свою корпоративную историю не понимала, что входит в создание успешной открытой платформы, не считая Android или Chrome.

Вообще-то я должен вкратце упомянуть Android, потому что вы наверняка подумали о нём.

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

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

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

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

За это я присуждаю Android заветную награду Ты не Google. Они действительно не хотят становится Google, которая не умеет создавать долговечные платформы, а вот Android знает, как это делать. И поэтому Google ведёт себя очень мудро в одном отношении: позволяет людям в Android делать всё по-своему.

Однако мгновенные приложения для Android были довольно глупой идеей. И знаете, почему? Потому что они требовали переписать и перепроектировать ваше приложение! Как будто люди просто так возьмут и перепишут два миллиона приложений. Предполагаю, что мгновенные приложения были идеей какого-то гуглера.

Но здесь есть разница. Обратная совместимость сопряжена с большими затратами. Android сам несёт бремя этих затрат, в то время как Google настаивает на том, чтобы это бремя несли вы, платный клиент.

Вы можете увидеть приверженность Android обратной совместимости в её API-интерфейсах. Когда у вас четыре или пять различных подсистем для выполнения буквально одного и того же, это верный признак, что в основе лежит приверженность обратной совместимости. Что в мире платформ является синонимом приверженности вашим клиентам и вашему рынку.

Главная проблема Google здесь их гордость своей инженерной гигиеной. Им не нравится, когда есть много разных способов делать одно и то же, причем старые, менее желательные способы сидят рядом с новыми, более причудливыми способами. Это увеличивает кривую обучения для новичков в системе, это увеличивает бремя поддержки устаревших API, это замедляет скорость новых функций, и главный грех это некрасиво. Google как Леди Эскот из Алисы в Стране чудес Тима Бертона:

Леди Эскот:
Алиса, знаешь, чего я боюсь больше всего?
Упадка аристократии?
Я опасалась, что у меня будут некрасивые внуки.

Чтобы понять компромисс между красивым и практичным, давайте взглянем на третью успешную платформу (после Emacs и Android) и посмотрим, как она работает: сама Java.

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

Если взять только один из тысяч примеров, закрытие потоков считается устаревшим. Оно устарело с момента выпуска Java 1.2 в декабре 1998 года. Прошло 22 года с тех пор, как это устарело.

Но мой реальный код в продакшне по-прежнему убивает потоки каждый день. Разве это хорошо? Абсолютно! Я имею в виду, конечно, если бы я переписал код сегодня, я бы реализовал это по-другому. Но код моей игры, которая за последние два десятилетия сделала счастливыми сотни тысяч людей, написана с функцией закрытия потоков, которые висят слишком долго, и мне никогда не приходилось его менять. Я знаю свою систему лучше всех, у меня буквально 25-летний опыт работы с ней в продакшне, и я могу точно сказать: в моём случае закрытие этих конкретных рабочих потоков совершенно безвредно. Не стоит тратить время и силы на переписывание этого кода, и хвала Ларри Эллисону (наверное), что Oracle не заставила меня переписывать его.

Наверное, Oracle тоже разбирается в платформах. Кто его знает.

Доказательства вы можете встретить по всем ключевым Java API, которые пронизаны волнами устаревания, подобно линиям ледника в каньоне. В библиотеке Java Swing можно легко найти пять или шесть различных менеджеров навигации с клавиатуры (KeyboardFocusManager). На самом деле трудно найти Java API, который не является устаревшим. Но они всё ещё работают! Думаю, команда Java по-настоящему удалит API только в том случае, если интерфейс вызовет вопиющую проблему безопасности.

Вот в чём дело, ребята: мы, разработчики программного обеспечения, все очень заняты, и в каждой области программного обеспечения мы сталкиваемся с конкурирующими альтернативами. В любой момент времени программисты на языке X рассматривают язык Y как возможную замену. О, вы мне не верите? Вы хотите назвать Swift? Мол, все мигрируют на Swift и никто от него не отказывается, верно? Ого, как мало вы знаете. Компании считают расходы на двойные команды мобильной разработки (iOS и Android) и они начинают понимать, что эти кросс-платформенные системы разработки со смешными названиями, такие как Flutter и React Native, действительно работают, и с их помощью можно сократить размеры своих мобильных команд вдвое или, наоборот, сделать их вдвое продуктивнее. На кону реальные деньги. Да, есть компромиссы, но, с другой стороны, де-е-еньги.

Предположим гипотетически, что Apple по глупости взяла пример с Гвидо ван Россума и объявила, что Swift 6.0 обратно несовместим со Swift 5.0, во многом как Python 3 несовместим с Python 2.

Наверное, я рассказывал эту историю лет десять назад, но лет пятнадцать назад я ездил в лагерь OReillys Foo Camp с Гвидо, сидел в палатке с Полом Грэмом и кучей больших шишек. Мы сидели в изнуряющей жаре и ждали, когда Ларри Пейдж вылетит на своём личном вертолете, а Гвидо монотонно бубнил о Питоне 3000, который он назвал по количеству лет, которое потребуется всем, чтобы туда мигрировать. Мы всё время спрашивали его, почему он нарушает совместимость, и он отвечал: Unicode. И мы спрашивали, если нам придется переписать наш код, то какие еще преимущества мы увидим? И он отвечал Yoooooooooooooouuuuuuuniiiiiiicoooooooode.

Если установить Google Cloud Platform SDK (gcloud), то вы получите следующее уведомление:

Уважаемый получатель,

Мы хотели бы вам напомнить, что поддержка Python 2 устарела, так что пошёёёёёёёёл тыыыыыыы

и так далее. Круг жизни.

Но дело в том, что у каждого разработчика есть выбор. И если заставить их переписывать код достаточно часто, то они могут подумать и о других вариантах. Они не ваши заложники, как бы вам этого ни хотелось. Они ваши гости. Python по-прежнему очень популярный язык программирования, но, чёрт побери, Python 3(000) создал у такой бардак у себя, в своих сообществах и у пользователей своих сообществ, что последствия не могут разгрести уже пятнадцать лет.

Сколько программ Python было переписано на Go (или Ruby, или какой-то другой альтернативе) из-за этой обратной несовместимости? Сколько нового программного обеспечения было написано на чём-то другом, кроме Python, хотя оно могло быть написано на Python, если бы Гвидо не сжёг всю деревню? Трудно сказать, но Python явно пострадал. Это огромный бардак, и все в проигрыше.

Итак, допустим, Apple берёт пример с Гвидо и нарушает совместимость. Как думаете, что будет дальше? Ну, может, 80-90% разработчиков перепишут своё программное обеспечение, если получится. Другими словами, 10-20% пользовательской базы автоматически уходят на какой-то конкурирующий язык, например, Flutter.

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

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

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

Это позволяет кодовой базе Google внутренне быть почти сверхъестественно чистой, так как у них эти роботизированные слуги снуют по всему дому и автоматически всё подчищают, если они переименовали SomeDespicablyLongFunctionName в SomeDespicablyLongMethodName, потому что кто-то решил, что это некрасивый внук, и его нужно усыпить.

И, честно говоря, это довольно хорошо работает для Google внутренне. Я имею в виду, да, сообщество Go в Google действительно по-доброму посмеивается с сообщества Java в Google из-за их привычки к непрерывному рефакторингу. Если вы что-то перезапускаете N раз, то это означает, что вы не только испортили это N-1 раз, но и через некоторое время становится совершенно ясно, что вы, вероятно, испортили это и с N-ой попытки. Но, по большому счету, они остаются выше этой суеты и сохраняют код чистым.

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

Я немного познакомил вас с Emacs, Android и Java; давайте посмотрим на последнюю успешную долгоживущую платформу: сам Веб. Можете представить, через сколько итераций прошёл HTTP с 1995 года, когда мы использовали мигающие теги <blink> и значки В разработке на веб-страницах.

Но это всё ещё работает! И эти страницы всё ещё работают! Да, ребята, браузеры мировые чемпионы по обратной совместимости. Chrome это ещё один пример редкой платформы Google, у которой головы привинчены правильно, и, как вы уже догадались, Chrome эффективно действует как изолированная компания отдельно от остального Google.

Я также хочу поблагодарить наших друзей среди разработчиков операционных систем: Windows, Linux, НЕ APPLE ПОШЛА Т APPLE, FreeBSD и так далее, за то, что они проделали такую большую работу по обратной совместимости на своих успешных платформах (Apple получает в лучшем случае тройку с минусом, так как они постоянно всё ломают без всякой уважительной причины, но каким-то образом сообщество справляется с этим в каждом релизе, и до сих пор контейнеры с OS X ещё не полностью устарели пока).

Но подождите, скажете вы. Разве мы не сравниваем яблоки с апельсинами автономные программные системы на одной машине, такие как Emacs/JDK/Android/Chrome, с многосерверными системами и API, как в облачных сервисах?

Ну, я написал об этом вчера в твиттере, но в стиле Ларри Уолла (создатель языка программирования Perl прим. пер.) по принципу отстой/рулез я поискал слово deprecated на сайтах для разработчиков Google и Amazon. И хотя у AWS в сотни раз больше предложений услуг, чем у GCP, документация разработчиков Google упоминает устаревание примерно в семь раз чаще.

Если кто-то из Google читает это, то наверняка они готовы вытащить диаграммы в показывая стиле Дональда Трампа, что на самом деле делают всё правильно, и что я не должен делать несправедливые сравнения, такие как количество упоминаний слова deprecated в зависимости от количества сервисов.

Но спустя столько лет Google Cloud по-прежнему остается сервисом 3 (я так и не написал статью о неудачной попытке стать 2), но если верить инсайдерам, есть некоторые опасения, что они могут скоро опуститься до 4.

У меня нет веских аргументов, чтобы доказать свой тезис. Всё, что у меня есть, это красочные примеры, которые я накопил за 30 лет работы в качестве разработчика. Я уже упоминал о глубоко философской природе этой проблемы; в некотором смысле она политизирована в сообществах разработчиков. Некоторые считают, что создатели платформ должны заботиться о совместимости, а другие считают, что это забота пользователей (самих разработчиков). Одно из двух. И в самом деле, разве это не политический вопрос, когда мы решаем, кто должен нести расходы за общие проблемы?

Так что это политика. И наверняка будут гневные ответы на моё выступление.

Как пользователь облачной платформы Google, а также как пользователь AWS в течение двух лет (работая в компании Grab), могу сказать, что существует огромная разница между философиями Amazon и Google, когда речь заходит о приоритетах. Я не веду активную разработку на AWS, поэтому не очень хорошо знаю, насколько часто они убирают старые API. Но есть подозрение, что это происходит далеко не так часто, как в Google. И я искренне верю, что этот источник постоянных споров и разочарований в GCP является одним из самых больших факторов, сдерживающих развитие платформы.

Знаю, что не назвал конкретные примеры систем GCP, поддержка которых прекращена. Могу сказать, что практически всё, что я использовал, от сетей (от самых старых до VPC) до хранилищ (Cloud SQL v1-v2), Firebase (теперь Firestore с совершенно другим API), App Engine (давайте даже не будем начинать), облачных конечных точек Cloud Endpoint и до я не знаю абсолютно всё это заставляло переписывать код максимум через 2-3 года, и они никогда не автоматизировали для вас миграцию, а часто не было никакого документированного пути миграции вообще. Словно так и положено.

И каждый раз, когда я смотрю на AWS, я спрашиваю себя, какого чёрта я до сих пор сижу на GCP. Им явно не нужны клиенты. Им нужны покупатели. Понимаете разницу? Давайте объясню.

У Google Cloud есть Marketplace, на котором люди предлагают свои программные решения, а чтобы избежать эффекта пустого ресторана, нужно было заполнить его некоторыми предложениями, поэтому они заключили контракт с компанией Bitnami, чтобы создать кучу решений, которые развёртываются одним щелчком мыши, или я сам должен написать решения, потому что эти ни черта не решают. Они просто существуют как флажки, как маркетинговый наполнитель, и Google никогда не заботило, работает ли какой-то из инструментов в реальности. Я знаю менеджеров по продукту, которые были за рулём, и могу вас заверить, что этим людям наплевать.

Возьмём, к примеру, решение с развёртыванием якобы одним щелчком мыши Percona. Мне до смерти надоели проделки Google Cloud SQL, так что я начал рассматривать в качестве альтернативы создание собственного кластера Percona. И на этот раз Google вроде сделала хорошее дело, они собирались сэкономить мне немного времени и усилий одним нажатием кнопки!

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

Но Google прямо призывает вас использовать их. Они хотят, чтобы ты их купил. Для них это транзакция. Они не хотят ничего поддерживать. Это не часть ДНК Google. Да, инженеры поддерживают друг друга, о чём свидетельствует моя история с Bigtable. Но в продуктах и услугах для обычных людей они всегда были безжалостны в закрытии любого сервиса, который не соответствует планке прибыльности, даже если у него миллионы пользователей.

И это представляет реальную проблему для GCP, потому что эта ДНК стоит за всеми облачными предложениями. Они не стремятся что-либо поддерживать; хорошо известно, что они отказываются размещать (как управляемый сервис) любое стороннее программное обеспечение до тех пор, пока AWS не сделает то же самое и не построит вокруг успешный бизнес, и когда клиенты буквально потребуют то же самое. Однако нужно приложить определённые усилия, чтобы заставить Google что-то поддерживать.

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

И это не очень хорошо, если вы хотите построить долгоживущую платформу.

Google, просыпайся, чёрт побери. Сейчас 2020 год. Ты всё ещё проигрываешь. Пришло время пристально посмотреть в зеркало и ответить, действительно ли ты хочешь остаться в облачном бизнесе.

Если хочешь остаться, то прекрати всё ломать. Ребята, вы же богатые. Мы, разработчики нет. Поэтому, когда дело доходит до того, кто взвалит на себя бремя совместимости, вам нужно взять это на себя. Не нам.

Потому что есть ещё по крайней мере три действительно хороших облака. Они манят к себе.

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

До следующего раза!

P. S. Обновление после прочтения некоторых обсуждений этой статьи (обсуждения великолепны, кстати). Поддержка Firebase не прекращена, и нет никаких планов, о которых я знаю. Тем не менее, у них есть неприятная ошибка потоковой передачи, которая заставляет Java-клиент останавливаться в App Engine. Один из их инженеров помог мне справиться с этой проблемой, когда я работал в Google, но они никогда реально не исправили баг, поэтому у меня есть паршивенький обходной путь, приходится каждый день перезапускать приложение GAE. И так уже четыре года! Теперь у них есть Firestore. Потребуется много работы, чтобы мигрировать на него, так как это совершенно другая система, а ошибка Firebase никогда не будет исправлена. Какой вывод можно сделать? Вы можете получить помощь, если работаете в компании. Наверное, я единственный, кто использует Firebase на GAE, потому что я записываю менее 100 ключей в родном на 100% приложении, и оно перестаёт работать каждые пару дней из-за известной ошибки. Что тут можно сказать, кроме как использовать его на свой страх и риск. Я перехожу на Redis.

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

Кроме того, я заметил, что 20 дней назад команда Google App Engine сломала хостинг критической библиотеки Go, закрыв приложение GAE от одного из основных разработчиков Go. Действительно, глупо получилось.

Наконец, я слышал, что гуглеры уже обсуждают этот вопрос и в целом согласны со мной (люблю вас, ребята!). Но похоже, что они считают проблему нерешаемой, потому что в культуре Google никогда не было правильной структуры стимулов. Думаю, хорошо бы выкроить немного времени, чтобы обсудить абсолютно удивительный опыт работы с инженерами AWS, когда я работал в компании Grab. Как-нибудь в будущем, надеюсь!

И да, в 2005 году у них действительно были разные виды акульего мяса на гигантском шведском столе в здании 43, и мне больше всего нравилось мясо молотоголовых акул. Однако к 2006 году Ларри и Сергей избавились от всех нездоровых закусок. Так что во время истории с Bigtable в 2007 году действительно не было никаких акул и я вас подло обманул.

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

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

Спасибо за чтение.

Апдейт 2, 19.08.2020. Stripe правильно выполняет обновление API!

Апдейт 3, 31.08.2020. Со мной связался инженер Google в Cloud Marketplace, который оказался моим старым другом. Он хотел выяснить, почему не работает C2D, и в конце концов мы выяснили: причина в том, что я создал свою сеть несколько лет назад, а C2D не срабатывает в устаревших сетях из-за отсутствующего параметра подсети в их шаблонах. Думаю, что потенциальным пользователям GCP лучше убедиться, что у них достаточно знакомых инженеров в Google
Подробнее..

Виртуальные машины А2 крупнейшие облачные образы с графическими процессорами NVIDIA A100 теперь доступны для всех

20.04.2021 12:16:22 | Автор: admin

Недавно, в нашем Google Cloud блоге, мы анонсировали, что в сервисе Compute Engine появились виртуальные машины A2 на базе графических процессоров NVIDIA Ampere A100 с тензорными ядрами. С их помощью пользователи смогут выполнятьмашинное обучениеивысокопроизводительные вычисленияна базе архитектуры NVIDIA CUDA, увеличивая рабочие нагрузки за меньшее время и цену.

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

Высочайшая производительность

Одна ВМ A2 поддерживает до 16графических процессоров NVIDIA A100. На сегодняшний день это самый производительный экземпляр графического процессора на одном узле среди всех конкурирующих решений от крупнейших поставщиков облачных услуг. В зависимости от масштабов рабочей нагрузкивы также можете выбрать виртуальные машины A2 с меньшим числом графических процессоров (1, 2, 4 и 8).

Конфигурации ВМ A2 доступные в сервисе Compute EngineКонфигурации ВМ A2 доступные в сервисе Compute Engine

Это позволяет исследователям, специалистам по обработке данных и разработчикам значительно увеличивать производительность масштабируемых рабочих нагрузок (например, машинное обучение, логический вывод и высокопроизводительные вычисления) на архитектуре CUDA. Семейство ВМ A2 на платформе Google Cloud Platform способно удовлетворить потребности самых требовательных приложений для высокопроизводительных вычислений, например при моделировании методами вычислительной гидродинамики вAltair ultraFluidX.

Для тех, кому нужны сверхпроизводительные системы, Google Cloud предлагает кластеры из тысяч графических процессоров для распределенного машинного обучения, а также оптимизированные библиотеки NCCL для горизонтального масштабирования. Версия ВМ с 16 графическими процессорами A100, объединенными через шинуNVIDIA NVLink, это уникальное предложение Google Cloud. Если вам нужно масштабировать требовательные рабочие нагрузки по вертикали, можно начать с одного графического процессора A100 и довести их число до 16 без настройки нескольких ВМ для машинного обучения на одном узле.

Новая ВМ A2-MegaGPU: 16 графических процессоров A100 со скоростью передачи данных 9,6 ТБ/с по интерфейсу NVIDIA NVLinkНовая ВМ A2-MegaGPU: 16 графических процессоров A100 со скоростью передачи данных 9,6 ТБ/с по интерфейсу NVIDIA NVLink

Чтобы удовлетворить потребности разных приложений, доступны и менее производительные конфигурации ВМ A2 с встроенным SSD-диском на 3ТБ, который ускоряет доставку данных в графический процессор. Так, графический процессор A100 в Google Cloud более чем в 10раз увеличивает скорость предварительного обучения модели BERT-Large по сравнению с NVIDIA V100 прошлого поколения. При этом в конфигурациях с числом графических процессоров от 8 до 16 наблюдается линейный рост производительности. Кроме того, разработчики могут использовать предварительно настроенное ПО в контейнерах из хранилища NVIDIANGCдля быстрого запуска экземпляров A100 в Compute Engine.

Отзывы пользователей

Мы стали предлагать ВМ A2 с графическими процессорами A100 нашим партнерам в июле 2020 года. Сегодня мы работаем со множеством организаций и помогаем им достигать новых высот в области машинного обучения, визуализации и высокопроизводительных вычислений. Вот что они говорят о виртуальных машинах А2:

КомпаниюDessaнедавно приобрел холдинг Square. Она занимается исследованиями в сфере ИИ и стала использовать ВМ A2 одной из первых. На базе ее экспериментов и инноваций Square разрабатывает персонализированные сервисы и умные инструменты для Cash App, которые с помощью ИИ помогают неспециалистампринимать более взвешенные финансовые решения.

"Благодаря Google Cloud мы получили необходимый контроль над своими процессами, говорит Кайл де Фрейтас, старший разработчик ПО в Dessa. Мы понимали, что предлагаемые в Compute Engine ВМ A2 на базе графических процессоровNVIDIA A100с тензорными ядрами способны радикально сократить время вычислений и значительно ускорить наши эксперименты. Процессоры NVIDIA A100, используемые в Google Cloud AI Platform, позволяют нам эффективно развивать инновации и воплощать в жизнь новые идеи для наших клиентов".

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

"Экземпляры A2 с новыми графическими процессорами NVIDIA A100 на платформе Google Cloud поднимают производительность на совершенно новый уровень при настройке моделей глубокого обучения. Мы легко перешли на них с прошлого поколения графических процессоров V100. Благодаря конфигурации ВМ A2-MegaGPU мы не только ускорили обучение более чем в два раза по сравнению с V100, но и получили возможность масштабировать по вертикали рабочие нагрузки с большими нейронными сетями в Google Cloud. Эти инновации помогут нам оптимизировать модели и повышать удобство использования сервисов Hyperconnect", говорит Ким Бемсу, исследователь по машинному обучению в Hyperconnect.

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

"DeepMind занимается искусственным интеллектом. Наши исследователи проводят различные эксперименты в этой сфере с применением аппаратных ускорителей. Благодаря Google Cloud мы получили доступ к новому поколению графических процессоров NVIDIA, а виртуальная машина A2-MegaGPU-16G позволяет проводить обучение моделей быстрее, чем когда-либо. Мы с радостью продолжаем работать с платформой Google Cloud, которая поможет нам создавать будущую инфраструктуру машинного обучения и ИИ", Корай Кавукчуоглу (Koray Kavukcuoglu), вице-президент DeepMind по исследовательской деятельности.

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

"Наша основная миссия расширение возможностей компьютеров. В связи с этим мы сталкиваемся с двумя фундаментальными проблемами. Во-первых, современные алгоритмы ИИ требуют огромных вычислительных мощностей. Во-вторых, специализированное оборудование и ПО в этой области быстро меняются. И с этим нужно что-то делать. Процессоры A100 в GCP в четыре раза производительнее наших нынешних систем, и для их использования не требуется серьезно перерабатывать программный код. По большому счету достаточно минимальных изменений. Графический процессор A100 в Google Cloud позволяет значительно увеличить количество вычислений на доллар. Соответственно, мы можем проводить больше экспериментов и использовать больше данных", говорит Дирк Груневельд, старший разработчик Allen Institute for Artificial Intelligence.

OTOY это компания, которая занимается облачными графическими вычислениями. Она развивает инновационные технологии создания и доставки контента для средств массовой информации и индустрии развлечений.

"Уже около десяти лет мы расширяем границы возможного в сфере графической визуализации и облачных вычислений и стремимся устранить ограничения для художественного творчества. Благодаря процессорам NVIDIA A100 в Google Cloud с большим объемом видеопамяти и самым высоким рейтингом OctaneBench за всю историю мы первыми достигли уровня, когда художникам при реализации своих замыслов больше не нужно задумываться о сложности прорисовки. Система визуализации OctaneRender снизила стоимость спецэффектов. Она позволяет любому разработчику с графическим процессором NVIDIA создавать великолепную картинку кинематографического качества. Виртуальные машины с процессорами NVIDIA A100 в Google Cloud предоставляют пользователям OctaneRender и RNDR доступ к современным графическим процессорам NVIDIA, прежде доступным только для крупнейших голливудских студий", говорит Джулз Урбах, основатель и генеральный директор OTOY.

Цены и доступность графических процессоров

Экземпляры NVIDIA A100 теперь доступны в следующих регионах: us-central1, asia-southeast1 и europe-west4. В течение 2021года к ним добавятся дополнительные регионы. ВМ A2 в Compute Engine доступны по запросу со скидкой за вытесняемые экземпляры и обязательство по использованию, а также полностью поддерживаются в Google Kubernetes Engine (GKE), Cloud AI Platform и других сервисах Google Cloud. A100 предлагаются по цене всего 0,87доллара США за один графический процессор в вытесняемых ВМ A2. С полным прейскурантом можно ознакомитьсяздесь.

Начало работы

Вы можете быстро развернуть работу, приступить к обучению моделей и выполнять рабочие нагрузки с логическим выводом на графических процессорах NVIDIA A100 с помощьюобразов ВМ для глубокого обученияв доступных регионах. В этих образах собрано все необходимое ПО: драйверы, библиотеки NVIDIA CUDA-X AI и популярные фреймворки для ИИ, такие как TensorFlow и PyTorch. Оптимизированныеобразы TensorFlow Enterpriseтакже включают поддержку A100 для текущих и прошлых версий TensorFlow (1.15, 2.1 и 2.3). Вам не нужно беспокоиться об обновлении ПО, совместимости и настройке производительности всё это мы берем на себя. Наэтой страницеприводятся сведения о доступных в Google Cloud графических процессорах.


Напоминаем что при первой регистрации в Google Cloud: вам доступны бонусы на сумму 300 долларов США, а более 20 бесплатных продуктов доступны всегда. Подробнее поспециальной ссылке.

А так же выражаем благодарность за помощь в подготовке материала коллегам: Бхарат Партасарати, Крис Клебан и Звиад Кардава

Подробнее..

Перевод Ускоряем разработку для Cloud Run с помощью Cloud Code

13.10.2020 10:19:44 | Автор: admin

При разработке сервисов для полностью управляемой контейнерной платформы Cloud Run, вы, скорее всего, быстро устанете постоянно переключаться между редактором кода, терминалом и Google Cloud Console. Мало того, вам ещё придется по много раз, при каждом развертывании, выполнять одни и те же команды. Cloud Code это набор инструментов, включающий все необходимое для написания, отладки и развертывания облачных приложений. Он повышает эффективность разработки в Google Cloud за счет использования плагинов для популярных сред разработки, таких как VS Code и IntelliJ. С его помощью вы сможете легко заниматься разработкой в Cloud Run. Подробнее под катом.


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


Примечание от автора. На виртуальной конференции Google Cloud Next 2020 OnAir мы анонсировали несколько новых функций и сервисов, призванных ускорить процесс доставки и разработки приложений, а также платформу Cloud для модернизации приложений (Cloud Application Modernization Platform или CAMP).

Создание новых сервисов Cloud Run


На первый взгляд контейнеризация и бессерверные сервисы могут казаться чересчур сложными. Если вы только начинаете знакомиться с Cloud Run, обратите внимание на обновленный список примеров Cloud Run в Cloud Code. Примеры доступны на языках Java, NodeJS, Python, Go и .NET. Опираясь на них, вы сможете сразу приступить к написанию собственного кода с учетом всех рекомендаций.
Все примеры включают файл Dockerfile, чтобы вам не пришлось тратить время, разбираясь в конфигурациях контейнеров. Если вы переносите в Cloud Run существующий сервис, то, возможно, вы ещё не работали с файлами Dockerfile. Ничего страшного! В сервисе Cloud Code есть поддержка объектов Google Cloud Buildpack, позволяющих контейнеризовать сервис прямо в коде. Файл Dockerfile при этом не требуется. Cloud Code содержит все необходимое для развертывания вашего сервиса в Cloud Run.



Разработка и отладка сервисов Cloud Run в локальной среде


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


В Cloud Code имеется эмулятор Cloud Run, позволяющий разрабатывать и отлаживать сервисы Cloud Run локально. Согласно исследованию, проведенному DevOps Research and Assessment (DORA), у команд, показавших высокую эффективность поставки ПО, сбои при внесении изменений случались в 7 раз реже, чем у менее эффективных команд. Благодаря возможности быстро выполнять итерацию кода локально и отлаживать его в репрезентативной среде, вы можете оперативно находить ошибки на ранних этапах разработки, а не во время непрерывной интеграции или, того хуже, в продакшене.


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


Первый запуск Cloud Run Emulator:

Отладка сервисов Cloud Run с помощью Cloud Code осуществляется так же, как в привычной вам среде разработки. Выполните команду "Debug on Cloud Run Emulator" в среде VS Code (или выберите конфигурацию "Cloud Run: Run Locally" и выполните команду "Debug" в среде IntelliJ) и просто установите точки останова кода. Как только точка останова будет активирована в вашем контейнере, вы сможете переключаться между командами, наводить курсор на свойства переменных и проверять журналы из контейнера.


Отладка сервиса Cloud Run с помощью Cloud Code в VS Code и IntelliJ idea:


Развертывание сервиса в Cloud Run


После того как вы протестируете в локальной среде все изменения, внесенные в код для сервиса Cloud Run, останется создать контейнер и развернуть его в Cloud Run.


Развернуть сервис из среды разработки не составит никакого труда. Мы добавили все параметры, необходимые для настройки сервиса перед развертыванием. Когда вы нажмете "Развернуть", Cloud Code выполнит все требуемые команды, чтобы создать образ контейнера, развернуть его в Cloud Run и передать URL-адрес сервису.


Развертывание сервиса в Cloud Run:

Управление сервисами Cloud Run


Благодаря Cloud Code в VS Code можно просматривать журналы версий и сервисов одним нажатием. Эта функция была перенесена из Cloud Console в среду разработки, чтобы вам не приходилось постоянно переключаться. На странице просмотра отображаются именно те журналы, которые имеют отношение к версиям и сервисам, выбранным в проводнике Cloud Run.



Кроме того, в проводнике Cloud Run можно быстро найти и просмотреть сведения обо всех управляемых сервисах Cloud Run и сервисах Cloud Run для Anthos в нужном проекте. Там же можно легко узнать, какой процент трафика перенаправляется и сколько выделено ресурсов ЦП.


Cloud Run explorer в VS Code и IntelliJ


Нажав на версию правой кнопкой мыши, можно посмотреть URL-адрес сервиса. В Cloud Console можно проверить трафик или настроить его перенаправление между сервисами.


Начало работы


Приглашаем вас поработать с Cloud Code в Cloud Run, чтобы оптимизировать процессы развертывания сервисов и ведения журналов. Дополнительные сведения можно найти в документации по Cloud Run для сред разработки Visual Studio Code и JetBrains. Если вы ещё не работали с этими средами, для начала установите Visual Studio Code или IntelliJ.


Присоединяйтесь к Google Cloud Next OnAir


Также хотелось бы напомнить нашим читателям, что прямо сейчас проходит онлайн конференция Google Cloud Next OnAir EMEA для которой мы подготовили контент как для разработчиков, так и для архитекторов решений и руководителей.


Более подробно узнать о сессиях, спикерах и получить доступ к контенту можно бесплатно зарегистрировавшись на странице Next OnAir EMEA. Вместе с уникальным контентом, который будет представлен для Next OnAir EMEA вы также получите полный доступ к более чем 250 сессиям с глобальной части Google Cloud Next 20: OnAir.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru