Yandex Cloud

О Зарплате.ру
Зарплата.ру входит в Hearst Shkulev Digital Regional Network и является одной из трех крупнейших интернет-площадок в России по поиску работы и подбору персонала. База сотрудников содержит около 7 000 000 резюме по всей России. В свою очередь, специалисты могут выбирать предложения работы из 114 000 опубликованных вакансий. Каждый день работодатели добавляют более 2 500 новых вакансий.

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

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

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

К началу проекта примерный объем позиций, требовавших актуализации, дошел до 10 000 в сутки. В этом году была внедрена система для обзвона клиентов на основе технологий Yandex SpeechKit и Dasha.ai.

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

• рассылка СМС не дала отклика;
• при использовании IVR люди не хотели долго слушать текст и разговаривать с интерактивным меню.

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

Робот-оператор. Оригинальное решение для обзвона клиентов создала компания «Dasha.AI». Система состоит из трех частей.

1. Распознавание речи — за это отвечает облачная технология Yandex SpeechKit.
2. После распознавания происходит обработка информации с помощью фирменной технологии Dasha.ai, извлечение из нее смысла и выбор ответа согласно скрипту.
3. Ответ собеседнику (для этого диктор записал 30 фраз).

Этапы реализации
Для компании Зарплата.ру актуализация базы вакансий и базы резюме — это две задачи, но решены они были одним и тем же путем, поэтому в данном проекте объединены два кейса.

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

Основной этап реализации проекта занял около трех месяцев:

• После получения скрипта разговора от заказчика создана тестовая модель.
• Проведены тестовые звонки: 60% состоявшихся разговоров заканчивались успешно с первого раза, в оставшихся случаях робот не понимал собеседника или разговор шел не туда.
• За 8 итераций модели добились снижения количества ошибок до 10%.
• К концу трех месяцев была создана модель, эффективность которой в процессе обзвона оказалась всего на 6,7% ниже, чем у оператора, живого человека.

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

Технические особенности: увеличить скорость распознавания
Использование технологии Yandex SpeechKit в режиме потокового распознавания (распознавание речи в реальном времени) — это стандартный процесс, все вопросы использования API описаны в документации. Тем не менее инженеры Яндекс.Облака и «Даша.АИ» отметили важный пункт — скорость распознавания. Изначально показатель Latency на коротких фразах (ответы «Да» или «Нет») составлял до 600 мс (обычно этот показатель составляет до 200 мс). В процессе работы, с одной стороны, инженерами была проведена оптимизация настроек, с другой — серверы Dasha.ai перенесены ближе к серверам Яндекса. В итоге сейчас распознавание происходит со скоростью 0—150 мс.

Итоги
По итогам внедрения системы для обзвона клиентов на базе технологий Yandex SpeechKit и Dasha.ai. портал Зарплата.ру сумел закрыть несколько существовавших вызовов:

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

Redis используют Airbnb, Slack, Twitter и Uber, а в недавнем опросе Stack Overflow Developer Survey 2019 первое место в категории самая любимая БД разработчиков с показателем 71,3% занял именно Redis. На платформе Яндекс.Облако сервис Yandex Managed Service for Redis доступен в публичном режиме с апреля. Рассказываем о причинах популярности, планах развития и возможности начать пользоваться со скидкой.

Что умеет Redis
Redis — это система управления БД класса NoSQL. Название является сокращением от remote dictionary server, то есть это сервер словарей, работающий со структурами данных типа «ключ — значение». Система целиком работает в оперативной памяти, но при этом умеет сохранять данные на диск, написана на Си и является решением с открытым исходным кодом. Важно, что Redis очень быстрый, многие операции хорошо оптимизированы и работают константное время. Система легко справляется с нагрузкой в несколько сотен тысяч запросов в секунду. Сейчас Redis чаще всего используется в качестве хранилища. Одно из главных преимуществ по сравнению с Memcached, которое используется для кэширования данных в оперативной памяти, — поддержка множества интересных структур данных, для которых доступны богатые API. Например, можно хранить координаты и делать запрос по радиусу. Также в списке структур данных:

• Строки
• Словари
• Списки
• Множества
• Сортированные множества
• Битовые маски
• Геоданные
• Потоки
• HyperLogLog

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

Redis в подаче Яндекса
Yandex Managed Service for Redis использует последнюю версию 5.0.4, все критически важные обновления устанавливаются своевременно. Реализованы Multi-AZ репликация (Cross-Datacenter) и автоматический failover на основе стандартного решения Sentinel. Также Sentinel используется как сервер конфигураций: клиент подключается к Sentinel и узнает, где сейчас текущий мастер. Yandex Managed Service for Redis позволяет создавать БД в нескольких конфигурациях:

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

По умолчанию в Yandex Managed Service for Redis заданы некоторые ограничения:

• Maxmemory=75% RAM: 25% памяти зарезервированы под служебные процессы, различные агенты, клиентские буферы.
• Rep-backlog-size=10% RAM: для кластера из нескольких хостов 10% памяти аллоцируется под буфер репликации, чтобы реплики успевали синхронизироваться с мастером. Яндекс берет на себя заботу о безопасности сервисов, и в Yandex Managed Service for Redis ей также уделено усиленное внимание, в связи чем на каждом хосте установлен firewall, используется AppArmor и стандартная аутентификация по паролю, запрещены некоторые опасные команды. На данный момент доступ дается только из виртуальной сети, которая была указана при создании, также возможен доступ по FQDN.

Yandex Managed Service for Redis для пользователя
Два самых популярных сценария использования Redis — это кэш, который помогает основному бэкэнду хранилища справляться с нагрузкой, либо хранилище сессий состояний. Но мы бы хотели обратить внимание и на такие сценарии, как брокер сообщений, сервер очередей, таблица лидеров, хранилище геоданных. В зависимости от потребностей клиентам Yandex Managed Service for Redis доступны два вида хостов:

• Burstable (2/4 Гб) с низкими гарантиями ресурсов для сценариев, не предполагающих отказоустойчивости, например, для тестирования.
• High-Memory (8-256 Гб) специальные классы хостов, которые оптимизированы по памяти, созданные для Redis.

Yandex Managed Service for Redis позволяет удобно масштабироваться, увеличивая или уменьшая flavor в несколько кликов.

Из настроек в настоящий момент пользователи могут менять только две:

• Политика вытеснения ключей (eviction-policy) — важна в сценарии реализации кэша, позволяет выбирать наименее часто используемые ключи, случайные, последние и т. п.
• Тайм-аут для спящих клиентов (timeout).

В веб-консоли Yandex Managed Service for Redis можно наблюдать за ключевыми метриками, отслеживать потребление ресурсов, количество подключенных клиентов, живость хостов. Отдельно показано потребление ресурсов каждого хоста.

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

Планы по развитию функциональности Yandex Managed Service for Redis
Команда Yandex Managed Service for Redis постоянно работает над улучшением возможностей сервиса. В планах развитие средств диагностики, повышение удобства использования, более тонкая настройка кластера (помимо политики вытеснения ключей), гибкая работа с бэкапами, SSL/TSL шифрование. Уже в работе отказоустойчивая конфигурация с двумя хостами, а также поддержка Redis Cluster, который позволяет горизонтально масштабировать Redis не только на чтение, но и на запись.

Совет
Начните знакомство с Yandex Managed Service for Redis с изучения документации.
Вы можете получить скидку до 40% на пользование Yandex Managed Service for Redis в течение целого года. Как это сделать, читайте здесь.

Об 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

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