Яндекс клауд что это за программа

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

Привет! Меня зовут Максим Гореликов, я Backend Tech Lead в M2. Несколько вещей, которые надо знать об этой статье, прежде чем углубляться в нее:

эта статья — расшифровка моего доклада на конференции Yandex Scale 2021 с некоторыми доработками;

данные собирали с разных участников переезда и набрали много интересного, но доклад был в слоте про Yandex Data Platform, поэтому оставили кейсы только на эту тему;

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

События, описанные в статье, происходили в 2020 году, сейчас входим в топ-5 клиентов по объему потребляемых сервисов Yandex.Cloud. Когда переезжали, ещё не все процессы в Yandex.Cloud были хорошо налажены, поэтому расскажу о самых ярких воспоминаниях — проблемах, с которыми столкнулись. Хороших моментов тоже хватало, но проблемы всегда интереснее обсудить.

Почему мы решили переехать в облако

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

Инфраструктура сейчас

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

Третья причина — сертификация по персональным данным. Yandex Data Platform предоставляет готовые решения, где большинство проблем уже решены. Остается позаботиться о каких-то мелочах, а не проходить все с нуля.

Как не сломать всё и сразу

Чтобы собрать все проблемы и не получить массу недовольных пользователей на production, решили опробовать всё на dev-окружении.

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

Кластеры для хранилищ

До этого наша система выглядела так: под каждый сервис развернута виртуальная машина и на ней же — хранилище для этого сервиса. Топорно, но просто и работает — то, что нужно на старте компании. Но на момент переезда в Yandex.Cloud и развертывания там своей dev-среды у нас уже было порядка 150 сервисов и около 5 сред, от dev до prod. Получается 750 кластеров одного хранилища — если пересчитать по ценнику на ресурсы, выходит достаточно дорого.

Поэтому мы немного оптимизировали кластеры. Для dev- и test-сред выбрали единый подход: один кластер для бэкенда, один — для фронтенда и один — для иных нужд. Для prod, stage и perf всё немного сложнее: выделили по кластеру на каждый бизнес-блок, кластер для общих сервисов и кластер для каждого критичного сервиса, чтобы на них ничего не влияло. Получили первый плюс — некий пинок, мотивирующий задуматься о ресурсах и оптимизировать их.

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

Несовместимость библиотек и версий

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

«Кажется, дело в правах», — подумали мы, когда посмотрели на новую схему и получили в логах ошибки вида not authorized to execute command. «Надо бы обновить Mongock».

«Не надо меня обновлять, не нужны мне эти права, — подумал Mongock, — лучше сходи разберись, зачем вы используете заброшенный Mongobee».

Оказалось, что пара сервисов у нас использовала Mongobee с давних времён. Ещё когда команд и сервисов было не так много и всё это вполне себе жило по принципам «работает — не трогай». При миграции в облако все сервисы естественным путем переехали на единую версию MongoDB и стрельнули конструкции, которые были отмечены как deprecated ещё в MongoDB 4.2.

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

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

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

Решилась проблема просто — пошли поискать какие-то зацепки в документации Yandex.Cloud и нашли там список рекомендованных клиентов для Redis. Среди них был Jedis. Он, конечно, на Java, но это всё JVM-языки, и Jedis нам вполне подошёл.

Вывод (очевидный, когда уже найдёшь решение): на всякий случай перечитайте документацию перед переездом — можете зацепиться за что-то нужное.

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

S3 compatible storage != S3 compatible storage

Представьте S3 Compatible Storage как иерархию кластера, бакета, директории и файлов. Надеюсь, у вас получилось что-то похожее на картинку ниже. Сейчас, глядя на нее, рассмотрим проблемы, с которыми мы сталкивались.

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

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

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

Проблема на бэкенде

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

Логичным решением проблемы было перейти на подход bucket per service, так ограничений старого провайдера уже не было. Пришлось немного поправить код части приложений, но, с другой стороны, упростили свои процессы работы с S3.

Бэкенд пофиксили — сломался фронтенд

Наши проблемы были связаны с тем, что в Yandex.Cloud кластер Object Storage — один на всех. В рамках любого S3 Object Storage имя бакета уникально, поэтому возникают большие риски, связанные с тем, что при переезде нужное имя бакета будет уже занято кем-то другим.

Так и вышло. К моменту нашего переезда бакет с именем assets, откуда наши фронтовые приложения забирали множество ресурсов (картинки, CSS и т. д.), был уже занят. Ведь если заглянуть в network в браузере, то на большом количестве сайтов вы найдете использование assets в пути ресурсов.

Решилась проблема просто: поверх Object Storage у нас работал CDN, в рамках которого можно было настроить rewrite адресов.

Ещё один промежуточный вывод: будьте готовы к тому, что при переезде вам потребуется не только адаптироваться к изменениям самой инфраструктуры, но и поправить свои приложения, иногда обновить или заменить библиотеки. Надо просто учитывать, что какие-то трудозатраты в этом месте понадобятся.

Переезд данных

Как минимум, для переезда клиентских сервисов и данных требовалось переместить MongoDB, PostgreSQL и Apache Kafka. Во время нашего переезда уже был Yandex Data Transfer, но работал он в preview-режиме и поддерживал только миграцию PostgreSQL, чего нам было недостаточно. Поэтому мы перевозили свои данные стандартными инструментами самих БД, поверх которых написали набор скриптов.

Насколько мне известно, сейчас Yandex Data Transfer вышел из preview и у него появилась дополнительная поддержка MySQL и MongoDB. Кроме того, у него есть режим «Копировать и реплицировать», при котором сначала переливаются старые данные, а потом включается постоянная репликация. Это позволяет переключать ваши приложения со старого кластера на новый практически без даунтайма.

В случае с Apache Kafka все было сложнее, потому что Yandex Data Transfer ее не поддерживал. Сейчас в preview-режиме есть поддержка Kafka как источника при миграции, но это может помочь скорее при миграции БД, но не одного кластера Kafka в другой . Кроме того, было нам нужно было перенести не только данные в топиках, но и offset. Мы не хотели, чтобы при потере offset у нас перечитались все данные из топиков (идемпотентность — наше все, но нагрузку при перечитывании никто не отменял). Для миграции использовали Mirror Maker 2.0 — удобная штука и рекомендован официальным гайдом Yandex.Cloud. К моменту миграции в нём уже был KIP на миграцию offset и его даже уже успели вмерджить в мастер, но релиз вышел уже после нашего переезда. Поэтому то, что нам было нужно «из коробки», мы не получили.

В итоге одной из самых сложных для нас была миграция именно Kafka. Решения получились достаточно топорные, но рабочие. Мы переключили настройки consumer в наших приложениях на чтение с offset=latest в момент их инициализации на новом кластере, чтобы не было перечитывания. При этом пришлось остановить всех producer до тех пор, пока consumer не вычитали все сообщения, и только потом переключили приложения на новый кластер. Естественно, это привело к увеличенному времени недоступности в процессе переезда.

Сейчас с этим проще: mirror maker 2.0 поддерживает миграцию offset «из коробки».

Жизнь в Yandex.Cloud и использование PaaS

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

Разработчик может быстро попробовать что-то новое

Раньше мы боялись пробовать ClickHouse, потому что он несколько сложнее в части поддержки, чем другая наша инфраструктура. Ведь мы ещё старались экономить усилия наших operations-инженеров — они делали ещё много чего необходимого. Сейчас мы просто развернули его PaaS, испытали и начали использовать. Да, усилия на поддержку есть, но сильно меньше, чем для on-premise-решений.

Похожая ситуация с PostgreSQL. Он был у нас и до этого, но после переезда мы решили развернуть связку PostgreSQL + 1С. Те, кто знаком с этой связкой, понимают, что надо вложиться в настройку параметров дисковой подсистемы, настройку оптимизаторов, установить дополнительные модули и ещё покопаться в оптимизациях. Но если вы живёте в Yandex.Cloud, то имеете доступ к подготовленным образам определенных версий.

В нашем случае даже удалось получить сборку с нужной версией и переехать на неё. Это решает большинство проблем.

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

Живешь по принципам Infrastructure as code? Часть кода тебе уже подготовили

У Яндекса заготовлена пачка ресурсов для terraform-провайдера. Посмотреть список можно тут. Весомый плюс в том, что не надо писать базовые шаги вроде корректного рестарта кластера (когда мастер рестартует последним, чтобы не скакать по нодам) после обновления конфигов — всё это уже реализовано, бери и делай только те вещи, которые нужны конкретно тебе.

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

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

Переезжая на PaaS- и SaaS-решения, вы снимаете с себя бремя поддержки, но теряете некоторые возможности кастомизации и контроль своей инфраструктуры. Как это проявляется, рассмотрим на примере с MongoDB.

В некоторых частях нашей системы используется Mongo Change Streams. Штука достаточно удобная, когда надо и данные обновить, и гарантированно откинуть об этом ивент куда-то ещё.

Mongo change streams

Вся эта связка разворачивается достаточно просто и работает. Что надо понимать про change streams:

Mongo Change Streams основан на OpLog;

OpLog работает по принципу циклического буфера, новые ивенты пишутся поверх старых.

Как все это может работать в облаке:

Если планируется хранить небольшой объем данных в кластере MongoDB, скорее всего, выберете диск поменьше (подешевле);

размер OpLog в Yandex.Cloud определяется автоматически исходя из размеров диска, и задать его отдельно нельзя.

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

Посмотрим ещё один пример про возможности конфигурации связки ClickHouse и Kafka.

ClickHouse Kafka Engine. Наша схема

Как писал выше, использовать ClickHouse мы решились только после переезда в Yandex.Cloud. Если вы сами поднимаете ClickHouse (не как PaaS), то связка настраивается достаточно просто и поддерживает работу с Protobuf «из коробки» — достаточно подложить proto-контракт в директорию ClickHouse и сделать пару настроек.

У нас в системе достаточно широко используется gRPC с proto-контрактами, поэтому и тут нам было бы удобно передавать данные в Protobuf. Проблема состоит в том, что ни в UI, ни в API в момент поднятия нами этой связки на PaaS-решениях не было возможности передать proto-контракт. Способ «написать в поддержку» будет работать и тут, но если контракт меняется достаточно часто, то способ не слишком удобный.

Хорошая новость состоит в том, что спустя достаточно небольшое количество времени после поднятия нами этой связки в Yandex.Cloud всё-таки появилась возможность передавать proto через API.

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

Как всё это поддерживается

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

Бэкапы

Для PaaS-решений они есть, делаются автоматически, восстановление запускается простым нажатием кнопочки (ну или пары кнопочек) в UI.

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

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

Если немного отойти от Yandex Data Platform и предположить, что какой-то инфраструктуры в PaaS вам не хватило и вы пошли сами разворачивать ее в Compute Cloud, то тут с бэкапами всё немного хуже.

Опять же можно создавать снимки с виртуальной машины, но настроить это на периодической основе «из коробки» нельзя. Специальный человек должен периодически нажимать кнопочку — шучу. Специальный человек с прямыми руками (а у наших ребят в компании они прямые) может достаточно быстро собрать на том, что есть в облаке, систему с автоматическими бэкапами:

Message Queue и Cloud Functions вполне позволяют автоматизировать этот процесс.

В момент переезда это было неприятной проблемой: логи PaaS нельзя было посмотреть ни в UI, ни в CLI. И тут опять пригодился стандартный способ «запросить у поддержки». За прошедший год CLI был сильно доработан, и сейчас эти самые логи от того или иного PaaS можно удобно получить.

Кроме того, в preview-режиме стал доступен Yandex Cloud Logging и в перспективе можно будет попробовать переехать на него. Пока вопрос в возможности и удобстве работы с логами приложений через этот инструмент.

Мониторинг и Алерты

Для PaaS они есть.

заготовленный набор дашбордов вполне себе удобный и есть возможность настройки;

есть алерты по имейлу и SMS;

метрики PaaS-решений можно выгружать по API.

в редких случаях экспортируемого набора метрик не хватает (добавить самим нельзя);

нет возможности отправлять алерты в мессенджеры (Telegram, Slack).

Сейчас мы выбрали гибридную схему работы: метрики инфраструктуры выгружаются по API в наш кластер Prometheus в дополнение к метрикам наших приложений, и работаем в основном с дашбордами в нашей Grafana. Алерты также настраиваются через наш alertmanager. Иногда используются дашборды в Yandex.Cloud, но в основном для общения с поддержкой и обсуждения проблем инфраструктуры. Возможно, в дальнейшем мы и перейдем на встроенный в облако мониторинг, но всё будет зависеть от того, как он будет доработан.

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

Обзор платформы «Яндекс. Облако»: как пользоваться, зарегистрироваться и управлять сервисами

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

Что такое «Яндекс. Облако»

В 2018 году российской интернет-компанией в тестовом режиме была запущена специальная облачная платформа, которая, по сути, является неким набором связанных сервисов. Работа с облачной платформой доступна, как корпоративным юзерам, так и частным лицам в предусмотренном формате «as a service».Функционирование обеспечивается за счет использования компанией «Яндекс» собственных дата-центров и программных решений.

Архитектура облака Яндекс

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

Виртуальная инфраструктура масштабируемого формата может управляться:

• с использованием графического интерфейса;
• с помощью командной строки;
• инструментами разработки Python или Go.

«Яндекс.Облако» представляет собой сервис по управлению таких баз данных, как: MongoDB, PostgreSQL, ClickHouse, который способен перенять функции администрирования нужных систем. Он создан на основе современного опыта машинного интеллекта, потому предоставляет целый комплекс работ по синтезу и распознаванию речи и автоматического машинного перевода.

Основы работы с облачным хранилищем

Под основами работы с облачным хранилищем подразумевается: регистрация, создание и удаление «Яндекс. Облака».

Чтобы знать, как зарегистрироваться в «Облаке. Яндекс», совершите ряд последовательных действий:

Работа с панелью управления:

Чтобы завести облако на Яндексе, нажмите на надпись «default».

Чтобы удалить «Яндекс. Облако»:

• Перейдите в раздел «Яндекс. Паспорт».
• Пролистайте страницу в самый низ.
• Выберите пункт «Удалить аккаунт».

После этих действий аккаунт будет деактивирован.

Сервисы «Яндекс. Облака»

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

• комфортно и беспрепятственно работать с наиболее обширными массивами информации («Big Data»);
• надежно хранить и производить резервные копии данных;
• развертывать, как обычные, так масштабные проекты, сайты, приложения, прочее;
• производить сложные вычисления по более упрощенной схеме;
• постоянно увеличивать, как мощность, так и объем серверов.

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

Все сервисы разделены на два типа:

• инфраструктурные;
• платформенные.

Общая инфраструктура разделена на три независимые зоны, которые находятся в изоляции друг от друга: «A», «B», «C». Именно таким образом и достигается повышенная надежность, отказоустойчивость от сбоев и возможность сохранять копии данных. Пользователи имеют право самостоятельно определять, в какой именно зоне желают разместить «облако».
Давайте рассмотрим подробнее каждый сервис и его основной функционал.

Инфраструктурные

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

К подобным типам сервисов относятся:

1. Yandex Compute Cloud. Дает возможность использовать необходимые масштабируемые вычислительные мощности для самых разнообразных задач. Пользователь может самостоятельно настраивать количество имеющихся ядер, а также объём памяти или данные дисков: размер и количество. Более того, можно сделать выбор нужной ОС и зоны доступности виртуальной машины. Управление осуществляется при помощи консоли, SKD, API, CLI (командную строку).

В процессе применения данного сервиса пользователь получает ряд возможностей:

• указывает количество ядер в процессоре, настраивает объёмы памяти и выбирает ОС из предложенного семейства: Windows Server, Linux, исходя из своих задач;
• имеет возможность избежать установки ПО с нуля и выбрать из предложенных протестированных образов с наличием ПО для различных задач;
• изменяет количество применяемых виртуальных машин на основании текущей загрузки, что отнимет не более пары минут и позволяет максимально точно контролировать расходы;
• размещает созданную виртуальную машину в любой из предоставленных географических областей (всего три области);
• имеет подключение сетевых SSD-диски для дальнейшего хранения информации, а также возможность резервного копирования данных после создания снимка подключенного диска.

2. Yandex Object Storage. Является универсальным решением для масштабного хранения данных. Может применяться серверами с высокой нагрузкой для быстрого и надежного доступа к информации, а также для других проектов с менее высокими требованиями к вопросу хранения. Чтобы получить доступ к информации можно использовать современные инструменты, которые предназначены для подобных объектных хранилищ. API полноценно совместим с Amazon S3 API.

• неограниченность места для хранения, которое постоянно расширяется;
• резервное копирование в облако Яндекс: высокая степень сохранности информации за счет копирования и размещения файлов на различных географически распределенных зонах;
• двутиповое объектное хранилище: стандартное – для наиболее часто используемых файлов и холодное – для редко используемых;
• обмен данных производится с помощью интерфейса командной строки, графического клиента, Python SDK, HTTP API, Java.

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

Yandex Object Storage

3. Yandex Virtual Private Cloud. С помощью сервиса можно быстро создать облачную сеть, которая в дальнейшем будет использоваться для передачи данных между облачными ресурсами, а также для связи различных ресурсов с интернетом.

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

4. Yandex Identity and Access Management. Позволяет управлять доступами к нужным облачным ресурсам и виртуальным машинам. С его помощью можно назначать участников команды, их ролевые полномочия, создавать специальные сервисные аккаунты и настраивать аутентификацию.

• аутентификация производится через обычные учетки @yandex.ru, что позволяет избежать проблем с переключениями между рабочими и личными аккаунтами и устраняет необходимость дополнительного создания учетных записей;
• за счет двухфазной аутентификации доступы получат только члены команды, которые используют «Яндекс. Облако» для андроид или «Яндекс. Облако» для айфона и установили мобильное приложение «Яндекс.Ключ»;
• зависимо от того кому и какие задачи распределены, можно настраивать полномочия: на уровне самого облака, сервисного аккаунта либо каталога;
• возможность создать сразу несколько и больше сервисных аккаунтов.

5. Yandex Resource Manager. Создан для структурирования имеющихся в облачной платформе ресурсов. Например: осуществлять управлением доступом к различным ресурсам, создавать новые каталоги или назначать роли тем, кто участвует в работе.

Сервис дополнительно позволяет:

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

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

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

Yandex Instance Groups поможет быстро создать тестовую инфраструктуру и более просто управлять производительными мощностями web-сервиса при уменьшении или увеличении нагрузки.

Yandex Instance Groups

7. Yandex Load Balancer. Сервис отвечает за параметр отказоустойчивости приложения пользователя и дополнительно помогает создать и настроить балансировщика, распределять трафик.

Load Balancer поможет:

• обработать любые, даже резко меняющиеся, объемы входящего трафика;
• обрабатывать все сетевые пакеты без задержки за счет третьего уровня сетевой модели OSI – повысить до максимума производительность;
• автоматически, с помощью балансировщика, определить, готов ли ресурс к приему нового трафика и, при отсутствии готовности, отменить запросы клиента;
• правильно распределить нагрузку на имеющиеся целевые ресурсы – адресное распределение;
• хранить IP-адреса в нужном сетевом пакете запроса.

Сервис отлично справляется с правильным распределением веб-трафика и обеспечивает необходимый уровень отказоустойчивости.

Yandex Load Balancer

8. Yandex Message Queue. Является универсальным решением для быстрой и надежной передачи сообщений между различными приложениями. Полностью совместим с Amazon SQS API.

• двутиповые очереди: FIFO, стандартные;
• копирование и хранений в нескольких дубликатах;
• сообщения с Yandex Message Queue сохраняются при помощи твердотельных накопителей, что ускоряет производительность и снижает время ожидания отклика при одномоментной отправке большого потока данных;
• для работы используются интерфейсы командной строки, HTTP API, библиотеки для самых разнообразных языков программирования.

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

Yandex Message Queue

9. Yandex Container Registry. Позволяет в облачной инфраструктуре управлять и развертывать, а также хранить Docker-образы.

Container Registry используется для:

• улучшения скорости скачивания или же загрузки при снижениях расходов на внешний трафик;
• для хранения Docker-образов в отказоустойчивом хранилище Яндекса – Object Storage, которое обеспечивает реплики при каждом новой действии: после редактирования, удаления, создания образа;
• определения, кому именно будет дан доступ, чтобы просматривать, удалять или выполнять иные функции с образами – настройка доступа;
• легко и быстро скачивать нужные образы в любой момент.

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

Yandex Container Registry

Платформенные

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

К платформенным сервисам относятся:

Yandex Managed Service for PostgreSQL. Работает с базами данных основанных на СУБД PostgreSQ: разворачивает и поддерживает их кластеры.

С данным сервисом можно:

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

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

2. Yandex Managed Service for ClickHouse. Разработан для поддержания и разворачивания кластеров баз данных, основанных на ClickHouse. В свою очередь ClickHouse выполняет обработку более чем миллиарда строк и десятки гигабайт информации только для одного сервера за 1 секунду. Хорошо применяется для обработки аналитических запросов в режиме реального времени на структурированных больших данных.

Что дает сервис:

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

С Managed Service for ClickHouse от Яндекс можно решить задачи по аналитике логов, а также внутренней аналитике и не только.

3. Yandex Managed Service for MongoDB. Работа заключается в поддержании и разворачивании баз данных, которые основаны на СУБД MongoDB.

К основным достоинствам можно отнести:

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

Managed Service for MongoDB решает задачи с машинным обучением, размещением кэша, классическим способом хранения и может быть использован как брокер очередей.

4. Yandex Translate. Позволяет интегрировать алгоритмы переводчика от Яндекс в приложениях, веб-проектах для конечных пользователей. Распознает не менее 90 языков мира, а также переводит как целые тексты, так и отдельные слова.

К основным положительным характеристикам можно отнести:

• автоопределитель языка;
• точный перевод за счет статистической схемы трансляции;
• улучшение качества переводы за счет машинного обучения.

С Yandex Translate можно упростить коммуникацию, максимально увеличить аудиторию ресурса (сайта), построить платформу для создания контента, произвести предварительный перевод.

5. Yandex SpeechKit. Использовался как основа для голосового помощника Алисы и является уникальной технологией по синтезу, а также распознаванию речи.

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

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

6. Yandex Managed Service for MySQL. Разворачивает, а также поддерживает базы данных СУБД MySQL. В сервисе можно разместить данные CMS или бэкенд своего web-проекта.

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

Сервис позволяет хранить данные для CMS и использовать в бэкенде веб-проект.

Yandex Managed Service for MySQL

7. Yandex Managed Service for Redis. Поддерживает, а также разворачивает базы данных, основанных на СУБД Redis. Может быть использовано в момент построения рейтингов или в качестве ресурса для систем анализа контента в реальном времени.

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

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

Yandex Managed Service for Redis

Итоги

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