Yandex Cloud

Об electroNeek
Платформа программной роботизации (RPA, Robotic Process Automation) electroNeek является набором программ, которые устанавливаются на компьютер пользователя или на сервер. Эти программы позволяют пользователю без существенных знаний языков программирования запустить автоматизацию процессов любой сложности путем создания на основе бизнес-инструкции ботов, работающих на ПК или в Облаке. Работает electroNeek в сфере «программной роботизации» процессов, которую исследовательская компания Gartner недавно назвала самым быстрорастущим рынком корпоративного IT. С выходом технологии Yandex Vision (OCR, Optical Сharacter Recognition) создатели RPA-платформы увидели для себя новые возможности. Сотрудничество развивалось, и теперь пользователи electroNeek имеют возможность абсолютно бесплатно обрабатывать изображения с помощью Yandex Vision, вызывая сервис прямо из интерфейса программы.
www.electroneek.ru/
cloud.yandex.ru/services/vision

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

• повысить производительность труда сотрудников,
• автоматизировать бизнес-процессы.

Решение: робот + Yandex Vision
Работа команды electroNeek с заказчиком шла по типовому сценарию:
Процесс, который будет автоматизирован, имеет рабочую инструкцию. Первая задача, которую выполняет аналитик или программист, — перевод этой инструкции в алгоритм. Пример алогоритма проверки документов:


Далее в ПО electroNeek Studio, которое называется Dev Tool, алгоритм переводится в рабочий код робота. На этом этапе работа с алгоритмами и кодом завершается.

Команда выбирает, какой робот им нужен:

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

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

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

Реализация проекта от начала до старта заняла две недели, в процессе участвовало два разработчика.

Результаты
После внедрения роботов задачи по автоматизации процессов были выполнены. Итоги пилотного периода:

• время проверки документов сократилось с 30 минут до 1 минуты;
• вместо 6 человек, проверявших отсканированные документы, остался один сотрудник, обслуживающий систему (при этом его годовая зарплата и затраты на аренду робота составили лишь четверть от ФОТ существовавшего отдела).

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

Мнение

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

отмечает Сергей Юдовский, CEO electroNeek Robotics

Возможности
Наибольшей популярностью совместное использование Yandex Vision и electroNeek пользуется у клиентов при работе с финансовыми документами и договорами. Боты распознают информацию из счетов, накладных, договоров, таблиц и других финансовых документов и автоматически заносят ее в учетные и управленческие системы — 1С и прочие. А также готовят финансовые проводки, строят или обновляют excel-таблицы, посылают на основе считанной информации сообщения в мессенджерах.

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

Недавно была одобрена заявка на включение наших доменов в Public Suffix List (список публичных

• суффиксов). Список включённых доменов:
• yandexcloud.net
• storage.yandexcloud.net
• website.yandexcloud.net

Что меняется
Указанные домены получают свойства доменов верхнего уровня (top-level domain, TLD), как, например, домены .ru,.рф, .com. Это приведет к следующим изменениям:

• Браузеры не будут сохранять сookie, установленные на домены Yandex Object Storage. Это блокирует возможность влиять на логин-сессию пользователя.
• Браузеры не позволят поменять заголовок запроса origin страницы на корневые домены. Это лишает злоумышленников возможности получать доступ к контенту через смену origin страницы.

Ниже мы подробно рассказываем о том, какие возможные угрозы безопасности блокируются включением доменов в список публичных суффиксов.
cloud.yandex.ru/docs/storage/concepts/bucket

Управление файлами cookie для доменов Yandex Object Storage
Если раньше на сайте в Yandex Object Storage c помощью кода ниже можно было установить значение сookie для всех бакетов сразу, то теперь это не сработает.

<body>
    <script>document.cookie = 'CookieName=CookieValue;MaxAge=300;Domain=website.yandexcloud.net'</script>
</body>

Добавляя и управляя сookie на родительском домене можно манипулировать сессией, в которой окажется залогинен пользователь, или влиять на контент, который он видит. Блокируя эту возможность мы повышаем безопасность Yandex Object Storage.

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

<body>
    <script>document.domain='yandexcloud.net'</script>
</body>

Оказывается, данным кодом можно пользоваться на личных доменах для обхода правила ограничения домена (Same Origin Policy) при прямом обращении из javascript-кода страницы в iframе, расположенный на поддомене [1, 2]. Но в облаке бакеты могут принадлежать разным клиентам, и возможность сменить origin при использовании несёт риски безопасности.

К примеру, пусть у некой корпорации используется данная схема:

Для логина в систему пользователь заходит на corp-bucket1.website.yandexcloud.net, где ему показывается форма ввода пароля.

<!DOCTYPE html>
<html>
    <body>
        <h1>corp-bucket1<h1><hr>
        <iframe name="auth" src="https://corp-bucket2.website.yandexcloud.net/" frameborder="1" onload="setLocation()"></iframe>
        <script>
            document.domain = "website.yandexcloud.net";
            function setLocation() {
                auth.login_origin.value = document.location;
            }
            </script>
    </body>
</html>

Форма ввода пароля расположена на другом поддомене — // corp-bucket2.website.yandexcloud.net/

<!DOCTYPE html>
<html>
    <body>
        <h1>corp-bucket2<h1><hr>
        <div id="login-form">
            <form action="https://corp.example.com" method="POST">
                <input id="login" value="" placeholder="john.doe@corp.internal">
                <input id="password" value="" placeholder="************" type="password">
                <input id="login_origin" value="" type="hidden">
                <input type="submit" value="Sign In">
            </form>
        </div>
        <script>document.domain='website.yandexcloud.net';</script>
    </body>
</html>

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

Злоумышленник может создать страничку // evil-bucket.website.yandexcloud.net/ в своём бакете, которая так же меняет заголовок запроса origin, и получить полный доступ к контенту формы логина компании:

<!DOCTYPE html>
<html>
    <body>
        <h1>evil-bucket<h1><hr>
        <div id="login">Login: </div>
        <div id="password">Password: </div>
        <hr>
        <iframe name="auth" src="https://corp-bucket2.website.yandexcloud.net/" onload="setInterval(getCredentials, 1000)" style="width: 100vw; height: 80vh"></iframe>
        <script>
            document.domain='website.yandexcloud.net';
            function getCredentials() {
                window.login.innerText = "Login: " + auth.login.value;
                window.password.innerText = "Password: " + auth.password.value;
            }
        </script>
    </body>
</html>

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

Примечание

Поведение разнится от браузера к браузеру — на Firefox 68.0 пример работает без дополнительных действий, а в Chromium 75.0 (и других браузерах на том же движке — Яндекс.Браузер, Chrome и др.) для получения пользовательских паролей нужно вынудить пользователя кликнуть по фрейму с формой логина, что обычно не является проблемой

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

Что не меняется
Внутри бакета все политики работают как раньше. То есть, можно устанавливать cookie на домены

<your_bucket>.website.yandexcloud.net
<your_bucket>.storage.yandexcloud.net
и всё ещё можно менять origin в рамках своего бакета.

Сроки изменений
Теперь о главном — о сроках сроках принятия изменений в браузере. Изменения на уровне браузеров подтягиваются неравномерно. Для Chromium срок обычно 3-4 месяца, у Firefox список обновляется еженедельно, после чего должно пройти ещё некоторое время до выхода новой версии браузера. Релизные циклы других вендоров оценить сложно. Мы предполагаем, что в течение полугода новый список должен попасть во все актуальные браузеры.

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

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

Больше информации о сервисе Yandex Object Storage вы можете найти в документации.

Чтобы вам было удобнее работать с Yandex Container Registry, наша команда создала образ виртуальной машины, оптимизированный для запуска Docker-контейнеров — Container Optimized Image. Образ создан на основе Ubuntu 16.04 и включает в себя Docker и Docker Compose.

Чем хорош Container Optimized Image

• Управление контейнерами на виртуальной машине по модели «инфраструктура как код (Infrastructure as code, IaC)» позволяет настраивать инфраструктуру для ваших контейнеризованных приложений.
• Прозрачная аутентификация в Yandex Container Registry обеспечивает легкий доступ к реестрам Docker-образов.

Container Optimized Image может пригодиться в случаях

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

Сценарии использования

• Отказоустойчивый FrontEnd / L7 балансировщик для ваших сервисов.
• Приложения для активного сбора данных и метрик.
• Воркеры для систем мониторинга.

Container Optimized Image интегрирован с сервисами Yandex Container Registry и Yandex Instance Groups. Образ может быть использован на прерываемых виртуальных машинах и поддерживает управление через Terraform.

Вы можете выбрать образ Container Optimized Image при создании виртуальной машины или в Marketplace.

Инструкции по работе с Container Optimized Image читайте в документации.

С 1 августа 2019 года в Яндекс.Облаке на 40% снижены расценки на лицензию Windows на ВМ с гарантированной производительностью vCPU 50% и 20%. Цена за использование ОС Windows Server за 1 vCPU в час составит всего 0,7500 ₽ с НДС вместо 1,2691 ₽.
console.cloud.yandex.ru/
cloud.yandex.ru/docs/compute/quickstart/quick-create-windows

Теперь пользователи Yandex Compute Cloud могут работать с ВМ на платформе Intel Broadwell с vCPU 20% и с ВМ на платформе Intel Cascade Lake с vCPU 20% и 50% по сниженной цене. Так, конфигурация на платформе Intel Cascade Lake с Windows в 2 vCPU, 4 RAM, диском 25 ГБ и с гарантированной долей vCPU 20% стоит 2143 ₽ в месяц с НДС вместо 2891 ₽.
Разверните ВМ на Windows в Яндекс.Облаке — теперь это дешевле, а производительность машин выше: мы первыми в России предлагаем пользователям процессоры нового поколения Intel Xeon Gold (Cascade Lake).
Подробнее о том, из чего складываются цены на ВМ в Облаке, читайте в разделе тарифы.

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

AdsCompass начинала свою деятельность с нескольких десятков интернет-компаний, но за шесть лет развития партнерская сеть расширилась. Сегодня у AdsCompass более пяти тысяч рекламодателей, число которых ежемесячно растет примерно на 10—15%. Кроме этого, с 2018 года на платформе появилась возможность напрямую покупать интернет-рекламу через личный кабинет, а значит сеть пополнилась еще и за счет частных рекламодателей. Чтобы охватить всех партнеров из более чем 200 стран, сервисы, отвечающие за нагрузку, работают в двух ЦОД в Европе и США на собственном железе. На данный момент обрабатываемый трафик генерирует более 4 млрд записей статистики в сутки. Запись происходит с нескольких десятков серверов в один кластер ClickHouse. Ежемесячно происходит прирост объема трафика в среднем на 6-10%.

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

Компания поставила задачи:

• Увеличить стабильность работы кластера,
• Сократить затраты на поддержку и развитие инфраструктуры, чтобы сосредоточиться непосредственно на продукте.

Решение
«Толчком к переходу на Яндекс.Облако было именно появление Yandex Managed Service for ClickHouse, — объясняет Андрей Привалов, ведущий разработчик AdsCompass. — Если не ошибаюсь, есть и другие предложения на рынке, но тот факт, что Яндекс является разработчиком этой базы данных, сыграл большую роль в выборе в пользу Managed Service for ClickHouse».

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

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

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

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

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

AdsCompass планирует использовать в своей деятельности также Managed PostgreSQL, Compute Cloud, Container registry и Message Queue. Разработчики планируют написать скрипт для очистки партиций и рассчитывают на появление решений в этом направлении.

Мнение

Повышение стабильности и экономия — не единственные результаты этого проекта. Раньше были случаи, когда при остановке кластера ClickHouse у нас копилась статистика для последующей записи. Если на дисках заканчивается место и файлы статистики больше некуда писать, их как-то придется удалять. Удаление статистики — это прямые потери данных, в том числе финансовых. Потеря даже небольшого объема финансовых данных может привести к ухудшению отношений с клиентами, а это уже большие репутационные риски. С Yandex Managed Service for ClickHouse мы забыли о таких рисках.

уточняет Андрей Привалов, ведущий разработчик AdsCompass

Управляемые базы данных в Яндекс.Облаке
В чем разница между базой данных на «железе» и на виртуальных машинах? Чем самостоятельное обслуживание отличается от управляемого сервиса в облаке? Самое главное об управляемых базах данных.

Сегодня мы собрали в одном посте все самое важное о сервисах управляемых баз данных (Managed Databases). Рассказываем о плюсах размещения баз данных на виртуальных машинах. Смотрим, почему самостоятельное обслуживание может выйти дороже, чем кажется на первый взгляд. И небольшой спойлер: в конце поста вас ждёт полезный сюрприз. Тоже про базы данных.


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

Какую бы СУБД вы ни выбрали, её нужно где-то разместить. И в этот момент возникают два важных вопроса с точки зрения бизнеса:

• Развернуть СУБД на собственном железе или на виртуальной машине?
• Обслуживать самостоятельно или воспользоваться управляемым сервисомвот?

Мы возьмём в качестве примера условный, вполне типичный бизнес-проект, которому требуется доступность базы на чтение не меньше 99,99%, (простой не более 4 минут в месяц). Доступность на запись — не меньше 99,95% (простой не более 20 минут в месяц). А с нагрузкой на базу данных проекта справляется одна машина вот в такой конфигурации: 8 виртуальных ядер с частотой 2+ ГГц, 32 ГБ RAM и накопитель на 500 ГБ с пропускной способностью 2 000 IOPS.

А теперь посмотрим, какие плюсы и минусы есть у каждого варианта.

Железо или виртуальные машины?
«Железо» или baremetal, пожалуй, до сих пор самый популярный в России вариант размещения. Его преимущества: производительность и стоимость. Виртуализация неизбежно отъедает некоторую часть производительности серверов. А стоимость «железного» сервера ниже стоимости аналогичной виртуальной машины. Например, для выбранной нами конфигурации в дата-центрах Hetzner это будет 55 и 108 евро соответственно.

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

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

У развёртывания базы данных на виртуальных машинах есть несколько существенных плюсов по сравнению с «железным» вариантом.

Гибкость. На baremetal сервере не получится увеличить вычислительную мощность или дисковое пространство без простоя. Ресурсы нельзя добавить ровно в нужный момент. То же самое касается временного роста нагрузки. К наплыву посетителей в Чёрную пятницу придётся готовиться заранее. Масштабировать ресурсы виртуальных машин на короткий срок намного проще и менее затратно.

Скорость и удобство. Рабочую виртуальную машину с доступом по SSH можно получить намного быстрее, чем «железный» сервер. Примерно пара минут против 30-40, о которых говорят крупные провайдеры. Операции вне операционной системы на виртуальных машинах тоже выполнять значительно удобнее, чем на baremetal. Например, проводить отладку, когда не грузится операционная система.

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

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

Самостоятельное обслуживание или управляемая база данных?
У нас в Яндекс.Облаке базу данных можно разместить двумя способами. Первый: поднять виртуальные машины в Yandex Compute Cloud и развернуть на них СУБД своими силами. Второй: воспользоваться одним из сервисов управляемых баз данных.

В первом случае у вас будет несколько больше контроля и несколько меньше затрат. В управляемом сервисе у вас нет прав суперпользователя и доступа по SHH. Нельзя установить расширение, которое не поддерживается сервисом. Не все настройки СУБД можно поменять.

Для сравнения по затратам возьмём Yandex Managed Service for PostgreSQL. Он уже дешевле других аналогичных сервисов — 17 810 рублей в месяц. Можно добиться еще большей экономии: конфигурация, которую мы выбрали для нашего типичного бизнес-проекта, в Yandex Compute Cloud стоит 12 720, то есть разница составляет 40%.

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

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

Удобство в работе. Чтобы получить рабочую и правильно настроенную базу данных, в управляемом сервисе достаточно нажать одну кнопку и подождать пять минут. В комплекте вы получаете доступ к графическому отображению метрик СУБД и метрик использования системных ресурсов. Так же просто в управляемых сервисах Яндекс.Облака делаются реплики и наращиваются ресурсы БД.

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

Проблема в том, что минорные обновления могут включать в себя важные исправления безопасности и решения серьёзных проблем, например, приводящих к повреждению данных. В управляемых сервисах Яндекс.Облака минорные обновления устанавливаются без вашего участия. Это касается обновлений СУБД, ядра и библиотек.

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

Резервное копирование. Чаще всего о резервном копировании вспоминают, когда уже слишком поздно. Но даже регулярное создание резервных копий не защищает вас от ошибок на все 100%. Почему? Да потому что обычно никто не проверяет сами бэкапы. Именно так в своё время была потеряна база данных Gitlab.

Яндекс.Почта тоже однажды потеряла 3 терабайта данных из-за ошибки. История закончилась хорошо, базу данных удалось вернуть за счёт восстановления на момент времени (point-in-time recovery) непосредственно перед потерей. После этого мы вложили немало сил и ресурсов в развитие инфраструктуры резервного копирования и валидации бэкапов. Сейчас в управляемых сервисах Яндекс.Облака этот процесс налажен очень и очень хорошо.

Отказоустойчивость. Практически любой управляемый сервис позволяет повысить доступность базы данных на чтение за счёт добавления реплик БД. Но мало кто думает о доступности базы данных на запись и обеспечивает автоматическое аварийное переключение на случай отказа мастера. У нас реализованы обе функции.

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

Безопасность. В управляемых сервисах Яндекс.Облака все соединения с СУБД и резервные копии содержимого баз шифруются при помощи протокола TLS и технологии GPG. Кроме того, базы разных клиентов Яндекс.Облака полностью изолированы друг от друга. Благодаря отсутствию общих компонентов никто кроме вас не может получить доступ к вашим данным.

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

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

cloud.yandex.ru/promo-mdb/

Мы стараемся расширять возможности Облака и делать платформу по-настоящему удобной для пользователей. 1 августа Yandex Monitoring — сервис для сбора и визуализации метрик, — перешел в общий доступ.

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

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

Для общедоступной версии сервиса действует соглашение об уровне обслуживания (SLA). На момент публикации в рамках сервиса Yandex Monitoring тарифицируется только запись пользовательских метрик через API.

Если вы использовали Yandex Monitoring на стадии Preview, обратите внимание на изменения в работе с сервисом после запуска общедоступной версии. Параметры запросов к Yandex Monitoring API изменились, и вам может потребоваться перенестройка программ, обращающихся к API. Актуальные параметры запросов смотрите в справочнике API.

Вы можете узнать больше о работе с сервисом Yandex Monitoring на страницах:

• Документация;
• Тарифы.

Хорошие новости! Если вы ещё не успели попробовать управляемые БД в Яндекс.Облаке, то сейчас самое время начать. С 1 по 31 августа создайте кластер любой* базы данных в рамках пробного периода или на платной основе, используйте её регулярно вплоть до конца августа, а в сентябре 2019 года вы получите скидку до 40% на эту базу данных на 12 месяцев.
cloud.yandex.ru/promo-mdb/

Как получить скидку?

• У вас есть платный аккаунт в Облаке
• Пополните счёт на любую сумму и разверните кластер БД в Облаке.
• Используйте эту БД в течение месяца, включая 31 августа.
• C сентября подключится скидка: сервис по управлению базой данных будет доступен по цене со скидкой.

У вас нет платного аккаунта в Облаке

• Если вы работаете с сервисами Яндекс.Облака в рамках пробного периода и ещё не пробовали базы данных, то начните использовать с 1 августа.
• Используйте любую БД в течение месяца, включая 31 августа. Если средства стартового гранта закончатся раньше 31 августа, то вы должны перейти на платную версию и использовать БД по 31 августа в платной версии.
• C сентября подключится скидка: сервис по управлению базой данных будет доступен по цене со скидкой.

В акции* есть ограничения: она распространяется на базы данных, которые вы будете использовать в Облаке впервые.
Если вы уже приняли участие в акции в июле 2019 года, то при соблюдении условий акции с 1 августа в течение 3 рабочих дней подключится скидка на управляемую БД, которую вы начали использовать в июле. Для этой базы тарифы со скидкой будут действовать для вас в течение года с августа. Но вы можете принять участие в акции снова, если начнёте использовать другой сервис управляемых БД в Облаке — тогда скидка подключится для такой БД с сентября.
Подробнее про условия акции и тарифы
cloud.yandex.ru/promo-mdb/terms

Вы найдёте руководства по миграции баз данных в Яндекс.Облако в документации. Мы подробно описали, как это сделать:

• Yandex Managed Service for PostgreSQL
• Yandex Managed Service for MySQL
• Yandex Managed Service for ClickHouse
• Yandex Managed Service for MongoDB

По всем вопросам пишите в техподдержку в консоли управления.

С 1 августа 2019 года для всех пользователей сервиса Yandex Compute Cloud в Яндекс.Облаке снижаются расценки на виртуальные машины с операционной системой Windows. Цена меняется для виртуальных машин на платформе Intel Broadwell с гарантированной производительностью 20% vCPU и для виртуальных машин на платформе Intel Cascade Lake с гарантированной производительностью 20% vCPU и 50% vCPU.

Вот как изменится цена за использование ОС Windows Server за 1 vCPU в час:

Подробнее о том, из чего складываются цены на виртуальные машины, читайте в разделе Тарифы.
cloud.yandex.ru/docs/compute/pricing

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

Новая версия СУБД PostgreSQL 11
В Managed Service for PostgreSQL теперь доступна версия СУБД PostgreSQL 11.

Ключевые изменения в новой версии:

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

Вы можете выбрать PostgreSQL 11 при создании нового кластера в консоли управления, через API и CLI.
cloud.yandex.ru/docs/managed-postgresql/operations/cluster-create
www.postgresql.org/docs/11/release-11.html

Детальную информацию о новой версии PostgreSQL можно найти на официальной странице релиза.

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

Логическая репликация позволяет не только перенести БД между одинаковыми версиями СУБД, но и мигрировать базу данных с 10 на 11 версию PostgreSQL. Просто пройдите шаги миграции, настроив репликацию c сервера-источника с PostgreSQL 10 на сервер-приемник с PostgreSQL 11.

Расширенные настройки СУБД и настройки пользователей в консоли управления
Теперь вы можете просматривать и изменять расширенные настройки СУБД для кластеров PostgreSQL в консоли управления, а не только через CLI и API. Задать необходимые настройки можно как в процессе создания нового кластера БД, так и через кнопку Изменить кластер для существующего кластера.

Кроме того, в Managed Service for PostgreSQL доступны расширенные настройки для пользователей. Это позволяет задавать для отдельных пользователей значения параметров, которые превалируют над настройками кластера. Например, для всего кластера вы можете установить lock_timeout в 1 секунду, а для конкретного пользователя, из-под которого выполняете DDL-команды (изменения схемы), поставить lock_timeout побольше или отключить его вообще.

Обновление версий ClickHouse
Теперь вы можете изменить мажорную версию СУБД ClickHouse для существующих кластеров БД.

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

Шардирование в ClickHouse
В Managed Service for ClickHouse теперь есть возможность не только вертикального масштабирования кластеров БД, но и горизонтального за счёт автоматического создания шардов в кластерах ClickHouse.

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

Для распределения данных по шардам можно использовать разные механизмы, например ключи шардирования или веса шардов. При правильном распределении ключей пользователь сможет параллельного выполнять запросы над фрагментами данных на нескольких хостах, а скорость обработки данных существенно вырастет. Распределение по весам шардов позволяет сделать вставку данных прозрачной для пользователя.
Подобнее о шардировании таблиц в Managed Service for ClickHouse читайте в документации сервиса.
cloud.yandex.ru/docs/managed-clickhouse/tutorials/sharding

Обновление до High Availability конфигурации
Кластеры ClickHouse с одним хостом теперь можно обновить до конфигурации с высокой доступностью (High Availability, HA) без пересоздания. Раньше вы могли сразу создать кластер в HA-конфигурации, но поменять конфигурацию кластера с одним хостом на HA было нельзя.

Кластер с одним хостом не отказоустойчив и не обеспечивает репликацию данных. HA-конфигурация подразумевает наличие актуальных реплик данных на нескольких хостах кластера: между репликами можно распределить нагрузку; наличие реплик защитит от потери данных в случае сбоя в работе одного из хостов. Для обеспечения репликации ClickHouse использует Apache ZooKeeper. Теперь вы можете добавить хосты ZooKeeper к существующему кластеру БД с одним хостом.

Чтобы обновить ваш кластер до HA-конфигурации:

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

Managed Service for MongoDB

• Новая версия MongoDB 4.0
• Обновление версий
• Шардирование

Новая версия СУБД MongoDB 4.0
В Managed Service for MongoDB теперь доступна версия СУБД MongoDB 4.0.
Одна из ключевых новых функциональностей версии 4.0 — поддержка транзакций, удовлетворяющих требованиям ACID (атомарность, согласованность, изолированность, устойчивость). Транзакции работают в рамках replica set (т.е. внутри одного шарда). Также в новой версии улучшена работа с шардами. Благодаря этому мы поддержали шардирование для кластеров с версией MongoDB 4.0.

Детальную информацию о новой версии MongoDB можно найти на официальной странице релиза.

Обновление кластеров с версии 3.6 до 4.0
Теперь вы можете обновить версию MongoDB с 3.6 до 4.0 для существующих кластеров БД. Операция доступна через консоль управления, API и CLI.
cloud.yandex.ru/docs/managed-mongodb/operations/cluster-version-update

Шардирование в MongoDB
В Managed Service for MongoDB появилась возможность шардирования для кластеров MongoDB версии 4.0. Если ваш кластер развернут с версией 3.6, вы можете обновить его.
cloud.yandex.ru/docs/managed-mongodb/operations/cluster-version-update

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

Подробнее о шардировании коллекций в Managed Service for MongoDB читайте в документации сервиса.
cloud.yandex.ru/docs/managed-mongodb/tutorials/sharding