В заголовке и тексте найдено точное совпадение:

Опыт сервиса «Где мои дети»: перенос геоданных в Yandex Managed Service for ClickHouse



О сервисе
Сервис «Где мои дети», принадлежащий компании «Рефреш», позволяет родителю в любой момент времени определять, где находится его ребенок. Для работы сервиса нужна оперативная обработка и хранение огромного количества зашифрованных геоданных. На данный момент сервис «Где мои дети» локализован на 32 языка и имеет зарегистрированных пользователей в 209 странах мира, в 30 из которых зарегистрировались более 10 000 человек. Сейчас у приложения 800 000 активных пользователей, при этом на Россию и СНГ приходится лишь половина из них, вторая половина преимущественно из таких стран, как Бразилия, Турция, Израиль, США и Индия.
findmykids.org

Рубеж масштабирования
Сервис «Где мои дети» предлагает разные возможности. Например, при помощи приложения можно позвонить ребенку, и он услышит звонок, даже если он забыл отключить бесшумный режим после урока. А чтобы узнать, закончился ли у ребенка урок, родитель может прослушать звук вокруг его телефона. Но основной функцией приложения является отслеживание местоположения ребенка плюс взаимосвязанные опции вроде уведомления о выходе ребенка из обозначенной зоны и автоматического сохранения истории посещений. Сервис использует функцию GPS-трекинга. В качестве клиентского устройства может выступать смартфон с установленным на него приложением либо GPS-аксессуар в виде наручных часов. На данный момент клиентские устройства присылают более 1 000 наборов зашифрованных геоданных каждую секунду. Сервис подошел к тому рубежу, когда дальнейшее масштабирование становилось невозможным из-за технологических ограничений текущей инфраструктуры. В итоге перед командой встала необходимость решения следующих задач:
Сократить расходы на серверную инфраструктуру.Повысить стабильность решения за счет меньшей требовательности к скорости дисков.Организовать масштабирование ресурсов для хранилища геоданных «на лету».Получить возможность выполнять более сложные запросы и извлекать больше пользы из данных.
Переход на Yandex Managed Service for ClickHouse
Решение о переходе на Yandex Managed Service for ClickHouse было обусловлено предшествующим опытом. Изначально в компании геоданные хранили в MySQL, используя виртуальные серверы одного из облачных провайдеров. Несмотря на использование самых дорогих облачных дисков на базе SSD, вскоре был достигнут барьер производительности записи текущего дискового решения. Следующим этапом стал горизонтальный шардинг данных на несколько БД серверов, но даже при непиковой скорости записи специалисты компании периодически сталкивались с тем, что производительность дисков в облаке некоторых серверов сильно деградировала без каких-либо причин, что приводило к аварийным ситуациям. В разные периоды времени с разной частотой специалисты компании сталкивались с ситуацией, когда очередь на запись начинала расти быстрее, чем рассасываться. Приходилось экстренно переносить данные на другие шарды и жертвовать надежностью хранения в угоду временному увеличению производительности. Помимо этого, в определенный момент обнаружилось, что только на облачные диски приходится более половины всех расходов на инфраструктуру и оборудование.

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

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

Результаты
По итогам проекта сразу удалось решить три из четырех поставленных задач. Затраты на решение для хранения геоданных сократились более чем в три раза. С момента переезда в Яндекс.Облако uptime сервиса составляет 100%, повысились удобство работы с геоданными и стабильность решения в целом. В настоящий момент сотрудничество продолжается. После того как в компании попробовали ClickHouse для хранения геоданных, было принято решение перевести в него данные внутренней продуктовой аналитики.

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

Опыт AdsCompass: оптимальная поддержка кластера в Yandex Managed Service for ClickHouse



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

Как настроить управляемую базу ClickHouse с данными для Graphite




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

Graphite удобно настроить так, чтобы данные хранились в столбцовой аналитической базе ClickHouse. Специально для этого разработан один из множества движков — GraphiteMergeTree. Он лучше всего подходит для прореживания и агрегирования (либо усреднения) содержимого БД. Саму базу полезно разместить в Яндекс.Облаке через платформенный сервис Yandex Managed Service for ClickHouse. Тогда её не потребуется обслуживать и обновлять — все подобные функции сервис возьмёт на себя.

В этом посте мы опишем процесс настройки Yandex Managed Service for ClickHouse специально под Graphite.

1. Регистрация конфигурации rollup в ClickHouse
Создание конфигурации rollup в существующем кластере Managed Service for Clickhouse можно произвести через CLI или API.

CLI
Если вы выбрали интерфейс командной строки, подготовьте yaml-файл с описанием параметров rollup, например:
graphite-rollup.yaml: name: test_rollup patterns: - regexp: click_cost function: max retention: - age: 86400 precision: 60
Указанные в файле параметры соответствуют конфигурации, описанной в документации.

Далее выполните команду, указав ID кластера ClickHouse и имя файла конфигурации, созданного на предыдущем шаге:
$ yc managed-clickhouse cluster add-graphite-rollup <CLUSTER_ID> --rollup-file-name graphite_rollup.yaml

API
Используйте метод update для кластера ClickHouse, передав в теле запроса требуемые параметры rollup:
"graphiteRollup": [ { "name": "test_rollup", "patterns": [ { "regexp": "click_cost", "function": "max", "retention": [ { "age": "86400", "precision": "60" } ] } ] } ]

2. Создание таблицы на основе GraphiteMergeTree
Подключитесь к хосту ClickHouse и выполните запрос на создание таблицы на основе GraphiteMergeTree. В качестве параметра передайте имя секции rollup, описанной на предыдущем этапе. Вот пример:
CREATE TABLE GraphiteTable ( metric String, time DateTime, value Int64, version UInt64 ) ENGINE = GraphiteMergeTree('test_rollup') PARTITION BY time ORDER BY cityHash64(version, metric)
Теперь можно настроить Graphite для сохранения значений метрик на выбранном хосте ClickHouse. При этом прореживание данных будет проводиться автоматически средствами сервера ClickHouse в соответствии с параметрами, которые вы указали.
В тексте найдено точное совпадение:

Новый управляемый сервис Managed Service for Apache Kafka



Среди управляемых сервисов для хранения и обработки данных появился новый сервис Yandex Managed Service for Apache Kafka. С его помощью вы можете создавать кластеры Apache Kafka в инфраструктуре Яндекс.Облака. Managed Service for Apache Kafka находится на стадии Preview и не тарифицируется.
cloud.yandex.ru/services/managed-kafka

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

Сценарии использования Managed Service for Apache Kafka
Каноничный брокер для доставки данных между различными компонентами приложения. Так, приложения могут писать в топики Kafka некоторые данные: бизнес-данные, метрики, журналы.


В Облаке потребители способны реализовать следующие сценарии:
Построение онлайн-аналитики или реакции на событие c использованием технологий стриминга, например Kafka Streams, Spark Streaming с использованием Yandex Data Prос;Перенаправление сообщений в Object Storage, Managed Service for ClickHouse, HDFS или любое другое подходящее для оффлайн-аналитики хранилище.
Использование Kafka для реализации захвата изменения потоковой передачи данных (change data capture) в онлайн-режиме в базах данных для последующей их передачи в хранилище (ClickHouse, HDFS) или пользовательские приложения.


С чего начать
Запросите доступ к сервису через форму заявки на странице сервиса или в консоли управления.
cloud.yandex.ru/services/managed-kafka

Создайте кластер Managed Service for Apache Kafka.

Создайте и настройте топик и разделы. Настройте фактор репликации.


Подробнее о сервисе читайте в документации.

Проблемы при работе с дисками 19 июня 2020 года



Резюме по инциденту
В пятницу 19 июня некоторым клиентам были частично или полностью недоступны сервисы Compute Cloud, Managed Service for ClickHouse, Managed Service for Kubernetes, Managed Service for MongoDB, Managed Service for MySQL, Managed Service for PostgreSQL, Managed Service for Redis в зоне ru-central-b Яндекс.Облака. Проблема была локализована в 10:15, после чего наша команда точечно помогала пользователям устранять последствия инцидента.

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

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

Ход событий:
8:40 — Выход из строя первого сервера, он признан невосстановимым. Ситуация штатная.
9:48 — Второй сервер того же сегмента признан невосстановимым. Сразу после этого сработала автоматика, оповещающая об угрозе потери данных. Команда сервиса сразу же приступила к поиску проблемы, поскольку это является опасной ситуацией, и потеря данных становится возможной, если в скором времени откажет третий сервер из сегмента.
10:09 — Вышел из строя третий сервер из этого же сегмента отказа. Локализовать проблему до выхода из строя третьего сервера не удалось. Сразу после этого автоматика была принудительно остановлена на всех серверах Яндекс.Облака.
10:15 — Вышел из строя сервер в другом сегменте отказа, который был упомянут в изначальном сообщении о проблеме. Но так как это был первый неработающий сервер в другом сегменте, то с данными в этом сегменте ничего не произошло. К тому же автоматика была уже остановлена и сервер был возвращен в строй.
10:15 — Мы начали оказывать помощь пострадавшим пользователям по их запросам.

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

Последствия для пользователей:
В Compute Cloud сбой затронул часть дисков пользователей, находящихся в зоне ru-central-b. Часть данных на этих дисках была утрачена, что привело к частичной или полной потере диска. Пострадавшим пользователям были высланы рекомендации провести аварийное восстановление диска по инструкции. Все затронутые диски были отмечены в консоли Яндекс.Облака. При этом часть дисков мы смогли восстановить самостоятельно без участия пользователей, где пострадавшей оказалась внутренняя системная часть диска. С таких дисков отметка в консоли была снята, так что если сейчас в консоли Яндекс.Облака нет отметок о возможном повреждении жестких дисков, то никаких действий со стороны пользователя не требуется.Управляемые базы данных, кластера которых были развёрнуты с сетевыми дисками в нескольких зонах доступности, были недоступными на запись в течение нескольких минут. При этом потери данных не было. Такая недоступность — это внештатная ситуация, так как не была предусмотрена обработка частичной, а не полной, потери диска. Подобное поведение системы будет улучшено, переключение из-за длительных проблем с диском будет осуществляться за десятки секунд.Управляемые базы данных Managed Service for PostgreSQL и Managed Service for MySQL, кластера которых были развёрнуты только в пострадавшей зоне доступности ru-central-b, были восстановлены без потери данных из последней резервной копии, но с недоступностью сервиса на время восстановления.Управляемые базы данных Managed Service for ClickHouse, Managed Service for MongoDB и Managed Service for Redis, кластера которых были развёрнуты только в пострадавшей зоне доступности ru-central-b, были восстановлены из последней резервной копии с потерей данных за последний бизнес-день.Инцидент затронул только нескольких пользователей Managed Service for Kubernetes, которые использовали не отказоустойчивый тип мастеров. Во время инцидента для них был недоступен control plane Kubernetes, при этом запущенные в кластерах сервисы клиентов продолжали штатно функционировать. Эти мастера были восстановлены из последней резервной копии.
Причины
Причина сбоя нами была первоначально ошибочно идентифицирована как исключительно аппаратная, поскольку сбой произошел на уровне нашей базовой инфраструктуры. Автоматика в наших дата-центрах самостоятельно находит возможные проблемы с физическим оборудованием, после чего принимает решение о том, как исправить ситуацию. В зависимости от проблемы автоматическая система может дать указание на замену диска, перезагрузку сервера или полную перенастройку сервера, если другие меры не помогли. При этом пользователи Яндекс.Облака не замечают выход из строя сервера или диска и для них все сервисы продолжают работать в штатном режиме: виртуальные машины и данные автоматически переносятся на другие серверы.

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

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

Меры для предотвращения повторения подобной ситуации в будущем
Мы уже исправили ошибку в автоматической процедуре, которая неверно определяла уровень аппаратной проблемы.Перед отправкой сервера или диска в полную перенастройку по любой причине мы добавили обязательную задержку в одни сутки. Это позволит инженерам вручную обработать эту ситуацию и вернуть физические диски в кластер без потери данных.Будет добавлен дополнительный уровень проверки — теперь система хранения данных в Яндекс.Облаке будет явно подтверждать любое действие с оборудованием. Так мы сможем отложить работы с вышедшим из строя физическим диском или сервером на любой необходимый срок, пока не будем уверены в безопасности этого действия. В произошедшем инциденте это позволило бы не отправлять второй и третий серверы в перенастройку, а заморозить их до восстановления первого сервера.Мы введём обязательное резервное копирование мастеров Managed Service for Kubernetes с частотой несколько раз в сутки.
Мы также рекомендуем нашим клиентам:
Для повышения отказоустойчивости приложений использовать либо наши кросс-зональные решения, либо иметь резервную копию критичных данных в других зонах доступности Яндекс.Облака.Проработать систему активного мониторинга вашего сервиса, размещенного на нашей платформе, с целью повышения контроля доступности вашего сервиса. Если вам нужна помощь, мы всегда готовы помочь вам с подбором подходящего партнёра или же с настройкой мониторинга самостоятельно через обращение в службу поддержки.

Новое в документации за апрель



Yandex Certificate Manager
Certificate Manager — сервис для получения и обновления TLS-сертификатов от Let’s Encrypt®, а также для загрузки собственных сертификатов. Подробнее в документации.
cloud.yandex.ru/services/certificate-manager
cloud.yandex.ru/docs/certificate-manager/

Сервисы управляемых баз данных
Новое:
Добавлены новые классы хостов на платформе Intel Cascade Lake: m2.7xlarge (56 vCPU, 448 ГБ) и m2.8xlarge (64 vCPU, 512 ГБ).
Обновлены описания классов хостов и правила тарификации для следующих сервисов:
Managed Service for PostgreSQL,Managed Service for ClickHouse,Managed Service for MongoDB,Managed Service for MySQL.
Сценарии использования
Новое:
Добавлен сценарий визуализации геоданных из CSV-файла.

Data Proc
Новое:
Добавлен сценарий использования Запуск заданий с удаленных хостов, не входящих в кластер Data Proc.

DataLens
Новое:
Добавлены новые типы связей в дашбордах.
Добавлен раздел, описывающий типы данных и их соответствие с типами из источников.
Описаны новые типы чартов — линейчатая и нормированная линейчатая диаграммы.
Улучшения:
Описаны обновленные настройки датасета.
Добавлена инструкция о том, как скачать данные с дашборда Коронавирус: дашборд.

Изменения в API:
Новые возможности:
Во время загрузки данных можно заменить существующие данные в таблице по ключу.
Перед загрузкой данных можно очистить таблицу, в которую данные загружаются с помощью заголовка X-DL-Force-Truncate.
Изменились пути во всех методах, где используются таблицы в качестве path-параметра:
/provider/v1/connection/{ИД соединения}/{имя таблицы}/ -> /provider/v1/connection/{ИД соединения}/table/{имя таблицы}/

IoT Core
Новое:
Добавлены сценарии использования IoT Core на разных языках программирования: C#, Java.
Поддержка Terraform для создания и удаления реестров и устройств.

Managed Service for Kubernetes
Новое:
Обновлен список версий Kubernetes, доступных на релизных каналах.

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

Object Storage
Новое:
Добавлена инструкция как добавить сертификат для хостинга статического сайта из сервиса Certificate Manager.

Защита от уязвимостей Meltdown и Spectre и лимиты на пропускную способность сетевых дисков



В сентябре прошлого года мы ввели лимиты на количество операций чтения и записи (input/output operations per second, IOPS) и на пропускную способность (bandwidth) сетевых SSD-дисков. Чтобы гарантировать производительность и безопасность при работе с виртуальными машинами и дисками в Облаке, мы переходим к следующим шагам.

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

С 12 мая 2020 года мы фиксируем лимиты на блоки размещения (allocation unit) для дисков:
SSD, пропускная способность на чтение: 15 МБ/с на блок размещения (32 ГБ).SSD, пропускная способность на запись: 15 МБ/с на блок размещения (32 ГБ).HDD, пропускная способность на чтение: 30 МБ/с на блок размещения (256 ГБ).HDD, пропускная способность на запись: 30 МБ/с на блок размещения (256 ГБ).Это отразится на пропускной способности для следующих сценариев:
Чтение с SSD-диска размером менее 1 ТБ;Запись на SSD-диск размером менее 320 ГБ;Чтение с HDD-диска размером менее 2 ТБ;Запись на HDD-диск размером менее 1,25 ТБ.Лимиты на IOPS на данный момент соответствуют значениям в документации

Вводим ограничения на количество vCPU
Это ограничение связано с аппаратными уязвимостями Meltdown и Spectre, затрагивающими микропроцессоры Intel. Из-за этих уязвимостей вредоносный код может получить несанкционированный доступ на чтение к памяти других виртуальных машин на сервере. Поэтому использование виртуальных машин с определённым количеством ядер — 1, 18, 22, 26, 30 — мы считаем потенциально небезопасным и будем планово вводить ограничения на работу с такими конфигурациями. Ограничения будут применены не только к консоли управления, но и к интерфейсу командной строки CLI, API, SDK и Terraform.

Конфигурации с большим числом ядер менее востребованы, в то время как ВМ с 1 vCPU популярны за счёт низкой цены. Вводимые ограничения в первую очередь затронут вычислительные ресурсы с 1 vCPU на платформе Intel Broadwell (standard-v1).

Отказ от создания конфигураций с 1 vCPU
Управляемые базы данных
В первую очередь мы отказались от использования хостов с 1 vCPU на платформе Intel Broadwell в сервисах управляемых баз данных:
Managed Service for PostgreSQLManaged Service for ClickHouseManaged Service for MongoDBManaged Service for MySQLManaged Service for RedisData Proc (кластеры Apache Hadoop)Уже сейчас при создании кластера БД минимальный класс хоста — b1.nano (5% × 2 vCPU Intel Broadwell, 2 ГБ RAM), для кластера Data Proc — b1.small (20% × 2 vCPU Intel Broadwell, 4 ГБ RAM).


Все запущенные кластеры БД с конфигурациями с 1 vCPU продолжат работать. Добавить новые хосты в такие кластеры невозможно, пока не будут изменены хосты с 1 vCPU. Вы сможете изменить конфигурацию хостов самостоятельно до 1 июля 2020 года, затем они будут изменены на стороне сервиса.

Yandex Managed Service for Kubernetes
С 1 июля 2020 года при создании группы узлов кластера Managed Service for Kubernetes нельзя будет выбрать 1 vCPU на платформе Intel Broadwell (standard-v1) в блоке Вычислительные ресурсы для группы узлов.


С этого момента перестанет работать автоматическое масштабирование и нельзя будет внести изменения в группу узлов. Группу узлов необходимо будет обновить с новой конфигурацией CPU/RAM со сменой платформы на Intel Cascade Lake (standard-v2).

Yandex Instance Groups
С 1 июля 2020 года вы не сможете выбрать шаблон виртуальной машины с 1 vCPU на платформе Intel Broadwell (standard-v1) при создании групп виртуальных машин в Instance Groups.

Для групп виртуальных машин, уже созданных на Intel Broadwell (standard-v1) с 1 vCPU, будет недоступно ручное и автоматическое масштабирование и автоматическое восстановление. Группу виртуальных машин необходимо будет обновить с новой конфигурацией CPU/RAM со сменой платформы на Intel Cascade Lake (standard-v2).

Совет
Если у вас в настоящее время используются виртуальные машины с 1, 18, 22, 26, 30 vCPU на платформе Intel Broadwell (standard-v1), мы рекомендуем до 1 июля 2020 года запланировать переход на конфигурацию с 2 vCPU или на платформу Intel Cascade Lake (standard-v2).
Ограничение на количество vCPU в Yandex Compute Cloud
С 1 июля 2020 года в сервисе Compute Cloud вы не сможете выбрать 1, 18, 22, 26, 30 vCPU при создании новых и изменении существующих виртуальных машин. Это ограничение будет применено ко всем инструментам в Облаке — консоли управления, интерфейсу командной строки CLI, API, SDK и Terraform. При этом вы сможете остановить, изменить и запустить существующие ВМ таких конфигураций.

Дальнейшие действия
До 1 июля 2020 года мы свяжемся с пользователями, использующими виртуальные машины с 1, 18, 22, 26, 30 vCPU в сервисах управляемых баз данных, Instance Groups и Managed Service for Kubernetes.

После 1 июля 2020 года такие ВМ будут принудительно остановлены и изменены одним из способов:
будет изменено количество vCPU:
с 1 на 2,с 18 на 20,с 22 на 24,с 26 на 28,с 30 на 32;или будет изменена платформа со Intel Broadwell (standard-v1) на Intel Cascade Lake (standard-v2) с сохранением значений CPU и RAM.

О конфигурациях, которые будут использоваться при переходе, мы сообщим заранее. Виртуальные машины с 1, 18, 22, 26, 30 vCPU, созданные в сервисе Compute Cloud, будут изменены в последнюю очередь. О точной дате мы сообщим в отдельном посте.

Библиотека AI-программ от Облака и NVIDIA, алертинг и другие новости



Библиотека AI-программ от Яндекс.Облака и NVIDIA
NVIDIA GPU Cloud (NGC) — бесплатная библиотека ПО, в которой доступно более 80 приложений для работы с искусственным интеллектом, машинным обучением, нейронными сетями и высокопроизводительными вычислениями.
Теперь разработчики моделей машинного обучения могут сразу перейти к обучению и тренировке алгоритмов, не тратя время на настройку специализированного ПО.
hosting.kitchen/yandex-cloud/yandeksoblako-i-nvidia-delayut-vnedrenie-iskusstvennogo-intellekta-bolee-dostupnym-dlya-rossiyskih-kompaniy.html


Сервис автоматической миграции от Яндекс.Облака и Hystax
Теперь вы можете мигрировать через приложение Hystax Acura, которое есть в маркетплейсе Облака. Автоматизированный перенос данных с любой платформы без простоев и потери данных — теперь в 8 раз быстрее.
И можно настроить автоматическое восстановление приложения, размещённого на другой площадке, в Облако.
hosting.kitchen/yandex-cloud/yandeksoblako-i-hystax-zapuskayut-servis-avtomaticheskoy-migracii.html

Миграция Cartaxi
Крупнейший сервис по эвакуации автомобилей в России переехал в Облако.
Из статьи вы узнаете о том, какие задачи они решили с помощью миграции, как оптимизировали сервис и почему выбрали Яндекс.Облако.
cloud.yandex.ru/cases/cartaxi

Другие истории наших пользователей
Первый в России PLM-as-a-Service
Connective PLM внедряет технологии управления жизненным циклом продукции (PLM). В статье мы рассказали, как компания провела цифровизацию типовых задач в нефтегазовой компании, используя первый в России облачный PLM-сервис.
Подробнее cloud.yandex.ru/cases/connective-plm

Сбор показаний с помощью Yandex SpeechKit
«Газпром межрегионгаз Ухта» автоматизировали сбор показаний счетчиков по телефону. Раньше расшифровка разговоров занимала много времени. Теперь Yandex SpeechKit обрабатывает 75% звонков, и время приема показаний сократилось в два раза.
Подробнее cloud.yandex.ru/cases/gazprom

Новое в Облаке
Познакомьтесь с ClickHouse, не создавая тестовый кластер
Встречайте сайт-песочницу play.clickhouse.tech на базе Yandex Managed Service for ClickHouse. Там вы можете оценить возможности ClickHouse, не разворачивая базу данных. На сайте есть тестовые датасеты.
На play.clickhouse.tech можно:
познакомиться с синтаксисом запросов;попробовать примеры из документации;разобрать специфичные сценарии.Облачный сервис Managed Service for ClickHouse поможет легко развернуть кластер БД и масштабировать его. Обслуживание БД мы берем на себя. Подробнее в документации.
Алертинг в Yandex Monitoring
Теперь вы можете настраивать уведомления об изменении метрик. Укажите пороговые значения, по достижении которых вы получите письмо или SMS.
Лицензии Microsoft Remote Desktop Services в Облаке
Служба удалённых рабочих столов Microsoft Remote Desktop Services позволяет централизованно управлять приложениями и пользователями. С помощью лицензий вы можете устанавливать более двух удаленных Remote Desktop подключений к вашим серверам одновременно.

Стабильное использование Облака с экономией до 49%


Мы снижаем цены на резервируемый объём ресурсов (Committed Volume of Services, СVoS) — зарезервируйте определённый объём облачных сервисов на один год или на три года и платите меньше.

Скидка доступна всем пользователям — а экономия достигает 49 %. Стоимость ресурсов не изменится на протяжении всего срока действия скидки.

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

Скидка предоставляется на сервисы управляемых баз данных:
Managed Service for PostgreSQLManaged Service for MySQLManaged Service for ClickHouseManaged Service for MongoDBиспользующие платформу с процессорами Intel Cascade Lake

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

Услуги сервисов Яндекс.Облака, на которые не распространяются условия CVoS, оплачиваются по стандартным тарифам. Например, вы используете хост s2.medium и зарезервировали 8 CPU и 32 ГБ RAM, и теперь вам необходимо увеличить его до m2.xlarge с конфигурацией 12 CPU и 96 ГБ RAM. Вы можете:
увеличить его в консоли управления и тогда на 8 CPU и 32 ГБ RAM и дальше будет работать скидка, а остальные 4 CPU и 64 ГБ RAM оплачивать по стандартным тарифам;или
зарезервировать дополнительно 4 CPU и 64 ГБ RAM и получить скидку на все необходимые мощности.Как получить скидку
В разделе Биллинг вы увидите, сколько сэкономите, если подключите CVoS на те ресурсы, которые используете сейчас. Там же вы сможете рассчитать ежемесячные платежи для разного количества CPU и RAM, чтобы выбрать наиболее выгодный план.


Подключить CVoS можно в консоли управления. Для этого:
Перейдите в раздел Биллинг и выберите платёжный аккаунт.Перейдите в раздел Специальные предложения.Укажите нужное количество ядер, объем памяти и срок резервирования.Нажмите кнопку Подключить CVoS.

Подробнее о подключении CVoS читайте в документации.
cloud.yandex.ru/docs/billing/concepts/cvos
Стоимость хостов со скидкой можно найти в действующих правилах тарификации для каждого из сервисов.
cloud.yandex.ru/prices#services

Что мы сделали для вас в феврале



Обычно мы рассказываем вам о новостях платформы Mail.ru Cloud Solutions за прошедший месяц, но в этот раз не удержались и решили поделиться и самыми свежими новостями марта.

Провайдер Terraform для MCS
Возможно, вы не знали, но у MCS уже давно есть полноценная поддержка Terraform. С помощью него вы можете создавать сложные облачные топологии, включающие виртуальные машины, диски, сети, балансировщики нагрузки, правила firewall, а также PaaS-сервисы, например кластеры Kubernetes и БД.

Начать работу с Terraform в MCS теперь стало проще: можно скачать файл провайдера Terraform прямо в портале MCS.
Об управлении инфраструктурой в MCS с помощью Terraform.
mcs.mail.ru/help/iaas-api/infrastructure-terraform


Kubernetes 1.16
Теперь в MCS можно развернуть кластеры Kubernetes версии 1.16. Крупные изменения в этой версии:
Эфемерные контейнерыМенеджер топологии узлаПроверка контейнеров при их запускеПоддержка двойного сетевого стека IP4 + IP6Новый API для endpointsmcs.mail.ru/help/kubernetes/clusterfast

Webhooks для S3
Webhooks для S3 — это возможность настраивать отправку HTTP/S запросов по событиям для бакета, используя API. Например, вы можете:
Настроить обработку и конвертирование файлов после загрузкиИнтегрироваться с любыми внешними системамиНастроить логирование для объектного хранилищаmcs.mail.ru/help/storage-api/webhooks-s3

Подключение расширения мониторинга для баз данных
Для управляемых баз данных теперь можно подключить мониторинг с помощью Prometheus. Для этого мы добавили возможность устанавливать различные расширения ко всем поддерживаемым СУБД. Сейчас поддерживается установка Prometheus exporters в качестве расширений для MySQL, PostgreSQL, MongoDB, ClickHouse и Redis. В следующих релизах будут также доступны специализированные расширения для PostgreSQL и других БД.

Для подключения зайдите в инстанс базы данных и перейдите на вкладку Расширения.
mcs.mail.ru/help/db-faq/db-extensions

Новые сервисы на платформе MCS
Анти-DDoS, защита от DDoS и других атак.Web Application Firewall, фильтрация трафика и защита от атак.CDN, географически распределённая инфраструктура доставки контента.mcs.mail.ru/app/auth/

Простой доступ к дополнительным сервисам
Оставьте заявку в разделе Специальные сервисы, чтобы подключить:
Аварийное восстановление, резервирование инфраструктуры на случай сбоев.Автоматическая миграция с любых железных или облачных серверов на MCS.Cloud Managed Services — администрирование вашей облачной IT-инфраструктуры «под ключ».Виртуальное частное облако, инфраструктура публичного облака MCS на изолированных физических серверах.mcs.mail.ru/app/special-services/

VPNaaS в веб-интерфейс
Теперь VPN доступен в виде отдельного сервиса в разделе Облачные вычисления. Тип VPN — site-to-site IPsec.
Подробнее о работе с VPN.
mcs.mail.ru/help/network/vpn-mcs

Доступ к машинам через RDP в два клика
Для доступа к Windows-машине можно скачать конфиг RDP. На машине под Windows его запуск открывает настроенную панель удалённого доступа. Такой файл доступен для машин, подключенных к внешней сети.
mcs.mail.ru/help/iaas-create/rdp-connect

Инкрементальные бэкапы для виртуальных машин
Раньше инкрементальные бэкапы можно было настроить только при создании виртуальной машины. Теперь их можно включить в любой момент. Инкрементальные бэкапы занимают меньше места и быстрее создаются.
mcs.mail.ru/help/settings/servers-backup

Стоп и старт кластера для Kubernetes через веб-интерфейс
Теперь можно сделать через веб-интерфейс. Если вы остановите кластер, то не будете платить за использование памяти и процессорной мощности, пока он остановлен. Это может сэкономить вам до 60% для тестовых сред и является хорошей альтернативой спотовым инстансам.

Оперативно получать новости платформы MCS можно в нашем Telegram-канале.
t.me/mcsnews

Почитать
Хабр: Устройство Helm и его подводные камни
Завтра облачно: Managed Services: как аутсорс поможет сэкономить на зарплате IT-отдела
Завтра облачно: Что угрожает безопасности бизнеса: 4 главные киберугрозы 2020 года
Следите за выпусками «‎Завтра облачно»:
t.me/zavtra_oblachno
www.facebook.com/Mail.ruCloudSolutions/

С уважением, Илья Летунов
Руководитель платформы
Mail‌.ru Cloud Solutions

Новое в документации за январь



Добавлены справочники gRPC API во всех сервисах, кроме DataLens, Message Queue, Monitoring, Object Storage, SpeechKit и Yandex Database.

С 1 февраля следующие сервисы переходят на новую схему ценообразования:
Managed Service for MongoDBManaged Service for MySQLManaged Service for RedisManaged Service for PostgreSQL
Помимо этого обновились документы:
Cloud FunctionsCompute CloudData ProcManaged ClickHouseManaged Service for KubernetesCloud Functions
Подробнее
cloud.yandex.ru/blog/posts/2020/01/docs-digest

Новое в документации за декабрь



Yandex Database
Сценарии использования
Новое:
Установка Mikrotik Cloud Hosted Router.
Сайт на WordPress с кластером БД MySQL.

Cloud Functions
Новое:
Описаны новые типы триггеров:
Таймер.
Триггер для Object Storage.
Изменены лимиты.
Добавлены справочник API Functions и справочник API Triggers.

DataLens
Новое:
Добавлен раздел про вычисляемые поля.

Identity and Access Management
Новое:
Добавление федеративных пользователей с помощью консоли управления.
Получение IAM-токена для федеративного пользователя с помощью CLI.

Instance Groups
Улучшения:
Добавлено подробное описание того, как работает автоматическое восстановление в Instance Groups.

IoT Core
Новое:
Описана авторизация по логину и паролю: концепции;
инструкция Управление паролями устройства;
инструкция Управление паролями реестра.
Добавлен справочник API.
Улучшения:
Добавлена инструкция про создание X.509-сертификата.

Managed Service for ClickHouse
Новое:
Поддержка Terraform.

Managed Service for PostgreSQL
Новое:
Создание кластера PostgreSQL для «1С: Предприятия».

Managed Service for Redis
Новое:
Поддержка Terraform.

Object Storage
Новое:
Теперь можно добавлять собственные сертификаты безопасности для своих доменов при хостинге статического сайта.
Расширились возможности по управлению публичным доступом к бакету в консоли управления.
Добавилась операция для изменения класса хранилища с помощью конфигурации жизненных циклов объектов.

SpeechKit
Новое:
Изменения в потоковом режиме распознавания:
В сообщении с настройками распознавания добавились параметры singleUtterance и rawResults.
В сообщении с результатами распознавания добавился флаг endOfUtterance.
Изменения в распознавании длинных аудио:
Установлен лимит на максимальную длительность аудио — 4 часа.
Добавлен раздел про особенности использования gRPC.

Vision
Новое:
Новая модель для распознавания отдельной строки текста: инструкция, концепции.
cloud.yandex.ru/docs/vision/operations/ocr/text-detection#string
cloud.yandex.ru/docs/vision/concepts/ocr/

Yandex Database
Улучшения:
Обновлен список публичных материалов.
cloud.yandex.ru/docs/ydb/public_talks

Что мы сделали для вас в ноябре



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

У нас активно готовятся к запуску целых 3 новых облачных сервиса, следите за нашими новостями. А пока расскажем, что нового MCS приготовил для вас в ноябре.

Про фичи


Управление SSH-ключами теперь доступно в кабинете администратора. Здесь ключи можно посмотреть, а также загрузить новые.
mcs.mail.ru/help/network/keypair_rules

Как создать отказоустойчивое приложение на MCS
Мы создали для вас перечень рекомендаций для построения отказоустойчивых приложений. Здесь собраны общие моменты, настройка зон доступности, отказоустойчивости баз данных, блочных хранилищ, QoS, балансировке.
mcs.mail.ru/help/infra/fault-tolerant-guidelines

Хелп: мониторинг инфраструктуры с помощью Prometheus
Рассказываем, как настроить мониторинг серверов на основе Prometheus, Grafana и Node_exporter. Описаны экспортеры для MySQL, Redis, PostgreSQL и Clickhouse.
mcs.mail.ru/help/monitoring-with-prometheus

Про контент
Хабы и раздел подкастов в журнале «Завтра облачно»
Мы, кстати, выпускаем онлайн-журнал «Завтра облачно». И в ноябре в нём появились хабы по разным тематикам: технологии, разработка, бизнес и так далее.


А подкасты «Завтра облачно» теперь можно послушать прямо из журнала.
mcs.mail.ru/blog/hubs/podcasts

Оперативно получать новости платформы можно в нашем телеграм-канале.
t.me/mailrucloudsolutionsbot
До связи!

Новое в документации c августа по октябрь



Обзор платформы
Улучшения:
Обновили список инструкций по началу работы с Яндекс.Облаком и список список справочников API.
Описание технической поддержки
Новое:
Уведомления от Яндекс.Облака.Запросы данных у технической поддержки.
Сценарии использования
Новое:Непрерывное развертывание контейнеризованных приложений с помощью GitLab.Развертывание Active Directory.Развертывание Microsoft Exchange.Загрузка состояний Terraform в Object Storage.Автоматизация сборки образов с помощью Jenkins и Packer.
Compute Cloud
Новое:
Как аутентифицироваться в Яндекс.Облаке изнутри виртуальной машины.Виртуальные машины с GPU:Концепции.Как создать ВМ с GPU.Добавить GPU к существующей ВМ.Изменить количество GPU.Установкай NVIDIA драйверов.Подключать и отключать диски теперь можно не останавливая виртуальную машину.Улучшения:
Написали о том, как происходит динамическая миграция.Написали подробнее про операции чтения и записи для дисков.
DataLens
Новое:
Добавили возможность предоставлять доступ к дашбордам и чартам для любых пользователей.Добавили разграничение доступа на уровне строк (RLS).Добавили новые инструкции: материализация датасета, назначение, удаление, запрос прав доступа, а также публикациии чартов и дашбордов.Обновили существующие и добавили новые сценарии использования: теперь вы можете изучить, как визуализировать данные из AppMetrica, Metrica Logs API и опубликовать данные из CSV-файла.
Identity and Access Management
Новое:
Рекомендации по безопасному использованию Яндекс.Облака.Пример создания JSON Web Token на Ruby. JWT необходим для получения IAM-токена для сервисного аккаунта.Новые роли для сервисов Cloud Functions, Container Registry и DataLens.Улучшения:
Написали подробнее про IAM-токен и OAuth-токен в концепциях, в частности про время жизни токенов.Сервисные аккаунты: начало работы и отличия от пользовательских аккаунтов.
Managed Service for ClickHouse
Новое:
Словари: концепции и инструкция по подключению внешних словарей.
Managed Service for Redis
Новое:
Redis Cluster (Шардирование) + инструкции.Изменение настроек кластера
Message Queue
Новое:
Отложенная доставка сообщений в очереди.Примеры использования с помощью разных инструментов: Python, Node.js, PHP, Celery, JMS, Laravel.
Resource Manager
Новое:
Переименование облака.
SpeechKit
Новое:
Синтез речи:
Премиум-голоса: концепции, список, цены.3 новых стандартных голоса: silaerkan, erkanyavas, nick.Написали, как выбор голоса и другие параметры влияют на качество произношения.Изменились правила тарификации для распознавания в потоковом режиме: тарификация начинается с отправки сообщения с настройками распознавания.Новый пример распознавания в потоковом режиме для Node.JS.Уменьшились лимиты для распознавания коротких аудио: максимальная длительность аудио в запросе теперь составляет 30 секунд.
Virtual Private Cloud
Новое:
Инструкция по включению NAT в интернет.Улучшения:
Расширенный пример тарификации DDoS Protection.
Vision
Новое:
Автоматическое определение языка: инструкция, концепции.

Интернет-магазин без проблем



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

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

В этой статье обсуждаем:
Как проблемы в обслуживании интернет-магазина связаны с выбором хостингаПреимущества платформы Яндекс.Облако для интернет-магазинаС чего начать подготовку к запуску интернет-магазина и как составить требования к ИТ-инфраструктуреНам помогает Алексей Васильев, директор и владелец веб-студии «Интернет-Эксперт», партнёра Яндекс.Облака. Компания с 2007 года запускает и сопровождает интернет-магазины и устраняет потери лидов, автоматизируя все этапы процесса интернет-продаж. Последние 5 лет специализируется на обслуживании магазинов, у которых несколько тысяч товаров в каталоге, больше двадцати заказов в день и требуются личные кабинеты пользователям. На момент публикации статьи на обслуживании 70 таких проектов и больше 300 созданных сайтов и магазинов в портфолио.

Студия «Интернет-Эксперт» выбирает 1С-Битрикс как одну из самых функциональных CMS и платформу Яндекс.Облако для создания надежных, отказоустойчивых и легко масштабируемых интернет-магазинов.

Как проблемы в обслуживании интернет-магазина связаны с выбором хостинга
Сбор данных для каталога товаров и другие периодические задачиПоддержка актуальности каталога товаров и ценМониторинг работы магазинаПодготовка к масштабированиюДоступность интернет-магазина для клиентов 24/7
1. Сбор данных для каталога товаров и другие периодические задачи
По опыту студии «Интернет-Эксперт» разработка интернет-магазина длится 2-3 месяца. К этому моменту сайт может быть готов к старту маркетинговых кампаний и привлечению трафика.

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

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

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

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

2. Поддержка актуальности каталога товаров и цен
Если в магазине больше 1000 товаров, есть склад, остатки в учётной системе и многофакторная система ценообразования, обязательно необходим корректный обмен данными между 1С и CMS.

Что такое обмен данными и как он работает
В 1С есть штатный модуль обмена данными с сайтом. Он отправляет на сайт информацию о товарном каталоге и выгружает с сайта заказы. Обменом также называют саму выгрузку данных большого объёма. Есть два типа обмена: полный — загружает каталог полностью; выгрузка только изменений — сохраняет изменения с предыдущей выгрузки и требует меньше ИТ-ресурсов и времени.
В нашей практике самый долгий обмен на 100 тысяч товаров длился 28 часов. А цены магазина были привязаны к валюте и обновлялись в 1С каждые 20 минут. При этом каждая выгрузка изменений становилась полной, так как менялись все цены, это требовало много ресурсов. Мы разбили выгрузки на несколько отдельных обменов (самостоятельных выгрузок): товары, свойства, картинки, контрагенты, заказы, цен, ценовые группы и т. д. Благодаря тому, что выгрузки стали проходить отдельно и сливаться на сайте, время разовой выгрузки сократилось до 7 минут, а полной — до часаприводит пример Алексей Васильев

Что важно для работы обменов:
На стороне сайта — производительный сервер, достаточное количество памяти и времени выполнения для интерпретатора скриптов.На стороне 1С — также производительный сервер и грамотная настройка под специфику магазина, которая, по мнению Алексея Васильева, требуется в каждом случае.
В каталоге товаров порядка 1500 номенклатурных единиц и включен учет в разрезе характеристик. У каждой модели одежды есть номенклатурный номер, и, допустим, 30 цветов на 8 размерных рядов — это дает 240 комбинаций торговых предложений для сайта. В результате 1,5 тысячи товаров дают порядка 360 000 комбинаций характеристик. А покупатели на сайте выбирают именно комбинацию характеристик, наличие которой еще нужно проверить на складе адресного хранения. Чтобы обмен учитывал все это, требуется изменение стандартных настроек модуля обмена или доработкаразъясняет Алексей специфику магазина одежды

Алексей также поясняет, что стандартный обмен рассчитан на обработку 5-7 характеристик. При этом его алгоритм использования памяти сейчас реализован так, что требования к памяти геометрически растут с ростом характеристик. Никто не поручится, что после добавления нескольких единиц нового товара или новых характеристик обмен будет корректно работать и своевременно подгружать данные, не забирая ресурсы у сервера сайта. Когда ресурсов не хватает, обмен «тормозит» и «падает», а на сайте отражается неактуальная информация.

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

Что мешает обмену на массовых хостингах На массовых хостингах есть ограничения, которые прерывают обмен при превышении лимитов времени на операцию, лимитов нагрузки на CPU или объема используемой памяти. Когда лимит превышен, хостинг расценивает это как длинный «connect» и прерывает операцию. В среднем на популярных хостингах типовое ограничение по выполнению обмена 120 секунд и меньше. Максимально допустимое время на операцию, которое встречала команда Алексея Васильева на массовых хостингах, 300 секунд. На практике же обмен может длиться от 20 минут до нескольких часов.

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

Если мелкие интернет-магазины (до 15 заявок в день) при запуске чаще всего фокусируются на видимой пользователю части сайта (дизайн, фронтенд), то более опытные — выдвигают требования к функциональности «админки» сайта, чтобы управлять заказами и автоматизировать работу магазина. Часто популярные CMS сравнивают по функциональности «админки» и необходимости ее доработок.

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

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

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

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

Алексей Васильев, владелец веб-студии «Интернет-Эксперт»
Часто встречаю ситуации, когда публичные хостинги принудительно останавливают работу сайтов из-за высокой нагрузки на свою инфраструктуру
Частые лимиты массовых хостингов, которые ограничивают интернет-магазины:
Лимит на количество объектов файловой системы ограничивает количество картинок, которые необходимы в интернет-магазине в больших количествах. Каждый товар в среднем требует 6 превью (для списка товаров, для корзины, для карточки товара и т. д.). Кроме того, для ускорения работы фильтров в каталогах товаров, CMS интернет-магазина генерируют большое количество файлов кэша. Если сайт упирается в лимит объектов файловой системы — это резко сказывается на его производительности и функционировании в целом.Лимиты на время выполнения скриптов. Для CMS бывают отдельные тарифы с расширенными лимитами и повышенной стоимость, но также существуют ограничения.Лимит на количество запросов.Лимит на количество одновременных процессов.Алексей приводит другой пример
Компания запускает 150 поддоменов своего сайта для разных городов. С точки зрения нагрузки даже от поисковых роботов-индексаторов — это десятикратный рост, потому что каждый поддомен обходит отдельный индексатор. И требуется 4 типа таких сайтов под нишевые продукты, это увеличит нагрузку еще в 4 раза. Сравнили железный сервер и облако, поняли, что облако для них в 2 раза дешевле. И облако даёт возможность поэтапно развернуть ресурсы под такую задачу без покупок в прок и ограничений массовых хостингов
5. Доступность интернет-магазина для клиентов 24/7
Есть разные способы сократить время простоя в случае инцидентов и их количество. Рассмотрим некоторые из них.
Как заложить отказоустойчивость на этапе разработкиОб отказоустойчивости и бэкапахКак база данных влияет на производительность интернет-магазинаОтказоустойчивое хранение и раздача контента
1. Как заложить отказоустойчивость на этапе разработки
Работоспособность может пострадать при внесении изменений, накатывании нового функционала. Например, видите посторонние артефакты на экране, или не открываются картинки. Даже минорное отличие версий программного обеспечения и окружения при разработке, тестировании и в рабочей среде магазина может вызывать сбои. Например, обновление библиотеки обработки графики создает сбой в показе картинок.

Мы решаем эту проблему с помощью Docker-контейнеров. Они позволяют нам создать изолированную среду и на единой архитектуре разрабатывать тестировать и запускать очень разнородные сервисы с разными требованиями к этой инфраструктуре. Например, сервис генерации печатных форм в формате PDF использует среду исполнения, включающую Headless Chrome и библиотеки рендеринга графики и шрифтов. Его окружение никак не связано со средой исполнения сайта, включающей интерпретатор кода, базу данных и веб-сервер. Но мы можем запустить рядом, на одном сервере 2 контейнера с изолированными приложениями и нужной им средой исполнения. Таким образом сервис генерации печатных форм становится доступен для сайтаговорит Алексей Васильев

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

Docker-контейнеры по мнению студии «Интернет-Эксперт» расширяют возможности масштабирования: при миграции с одной виртуальной машины на кластер система сохраняет стабильность.

2. Об отказоустойчивости и бэкапах
Алексей продолжает: «Каждый день наши заказчики просят нас восстановить данные (удалённые пункты меню, страницы, данные клиентов). Где бы ни размещался клиент, мы не полагаемся на обещания хостингов о частоте и качестве бэкапов. Мы не раз убеждались, что обещанные хостинг-провайдерами бэкапы либо не создаются, либо копии могут быть устаревшими, например, трехмесячной давности. Поэтому для каждого клиента мы настраиваем сервис резервного копирования.
Наше инфраструктурное решение по хранению бэкапов, развернуто в Object Storage Яндекс.Облака. Для создания резервных копий используется утилита duplicity. Мы храним в Object Storage ежедневные инкрементальные данные как минимум за последние 90 дней и можем восстановить копию файла, актуальную на любой день из этого периода. Утилита duplicity позволяет разрабатывать гибкую стратегию резервного копирования: можно выбрать расписание создания полных и инкрементальных копий. Программа сама вычисляет изменения, сжимает и складывает их в архив. Она использует библиотеку librsync и утилиту rdiffdir для рекурсивной обработки директорий, что позволяет создавать бэкапы очень быстро и многопоточно. Мы создали для себя удобный интерфейс для восстановления файлов и таблиц базы данных, но обнаружили что его простота стимулирует клиентов пользоваться сервисом самостоятельно, и мы даем к нему доступ по запросу».

3. Как база данных влияет на производительность интернет-магазина
От базы данных зависит 80% работы интернет-магазина. В проектах по-разному устроен каталог товаров, который хранится в базе, требуется разный объём памяти под профиль выполнения запросов конкретного интернет-магазина. Поэтому возможность настройки базы данных под проект радикально влияет на производительность сервиса.

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

4. Отказоустойчивое хранение и раздача контента
Хранение и раздача статического контента могут тратить ресурсы сервера, которые часто ограничены по объёмам, и это может увеличивать время отклика сайта. В качестве альтернативы можно использовать объектное хранилище (например, Object Storage Яндекс.Облака), которое не ограничено по размеру и не создаёт дополнительную нагрузку на веб-сервер, где «размещён» сайт. Это позволяет создавать несколько потоков раздачи контента, а хранение и раздача стоят дешевле.

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

Алексей Васильев делится, как студия «Интернет-Эксперт» оптимизирует раздачу контента с помощью Object Storage
Мы привязываем Object Storage к сайту как отдельный домен. Такое разделение позволяет браузеру поддерживать два отдельных параллельных потока загрузки ассетов. С хоста сайта грузится динамика, а с хоста Object Storage — статика. Это можно отследить в панели сети браузера. Технически сложно вручную сделать распределение по нескольким хостам, а с Object Storage мы получаем эту функциональность без лишних затрат на разработку
Подробнее о способах создания и поддержания отказоустойчивости интернет-магазина — в записи нашего вебинара.

Преимущества Яндекс.Облака для интернет-магазина
Гибкие конфигурации и прозрачное масштабированиеАвтоматическая загрузка данных без переплаты за ИТ-ресурсыНадежная управляемая база данных для стабильной работы интернет-магазинаОтказоустойчивое безлимитное хранение в Object StorageУдобный мониторинг, диагностика неисправностей и оценка затратПодробная документация и помощь проверенных партнёров
1. Гибкая настройка виртуальных машин и баз данных, прозрачное масштабирование
Благодаря тому, что Яндекс.Облако предоставляет виртуальные машины с гибкими настройками, конфигурация серверов на старте сразу соответствует требованиям интернет-магазина. По мере роста проекта ресурсы можно прозрачно масштабировать: добавлять ядра процессора, память и диски, запускать новые виртуальные машины и сервисы.

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

Возможности выбора параметров виртуальных машин, дисков и баз данных в Яндекс.Облаке:
2 платформы Intel Broadwell и Intel Cascade Lake (с увеличенной производительностью);возможность выбрать чётное количество ядер в диапазоне 1-32 для Intel Broadwell и 2-48 для Intel Cascade Lake;от 1 до 16 Гб RAM без привязки к количеству ядер процессора;виртуальные машины с частичным использованием ядра 5-20-50-100%;прерываемые виртуальные машины с жизненным циклом 24 часа;выбор объема HDD/SSD диска от 1 до 4096 Гб.Алексей Васильев
Цена старта в Яндекс.Облаке такая же как на других площадках или ниже. При этом доступны более функциональные и мощные сервисы и цена масштабирования существенно ниже. Не нужно мигрировать сайт, достаточно добавить ресурсы работающим сервисам и увеличить производительность
2. Автоматическая загрузка данных о товарах и другие периодические задачи без переплаты за ИТ-ресурсы
Яндекс.Облако позволяет экономить на всех периодических задачах и не только, благодаря гибким тарифам и ресурсам под разные сценарии:
Все машины доступны по требованию (on demand). Это подходит при значительных колебаниях в уровне загрузки процессора и неизвестных темпах роста. Клиент платит только за используемые ресурсы. Тарификация посекундная.Прерываемые ВМ подходят для высокопроизводительных и кратковременных вычислений и тестирования. Могут быть прерваны в течение 24 часов по инициативе Яндекс.Облака. Скидка 60-70% от цены по требованию.Если вы уверены в прогнозе ваших нагрузок, то можете оставить заявку на вычислительные мощности на 1 или 3 года вперёд и получить скидку не менее 20% (фиксированное потребление предоставляется по запросу).
3. Надежная управляемая база данных для стабильной работы интернет-магазина
В Яндекс.Облаке доступны управляемые базы данных PostgreSQL, MongoDB и MySQL, ClickHouse, Redis™. Можно создать кластеры с синхронной репликацией для всех доступных БД (от 2 до 7 хостов в любой зоне доступности). Пользователь сам может решить, какой уровень отказоустойчивости для него важен, создать хосты в нескольких зонах доступности или в одной. Хосты можно добавлять в процессе эксплуатации. Вам также доступно автоматическое и ручное резервное копирование баз данных.

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

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

4. Отказоустойчивое безлимитное хранение и раздача контента на базе Object Storage
Object Storage — универсальное масштабируемое решение для хранения данных. Оно подходит как для высоконагруженных сервисов, которым требуется надёжный и быстрый доступ к данным, так и для проектов с невысокими требованиями к инфраструктуре хранения. Для доступа к данным можно использовать популярные инструменты для работы с объектными хранилищами — API сервиса совместим с Amazon S3 API.

В Yandex Object Storage предоставляется столько места, сколько нужно интернет-магазину. Данные автоматически сохраняются в трёх географически распределённых зонах доступности. Для всех этих данных действует репликация: при редактировании, создании и удалении файла меняется каждая копия.

Пример от студии Интернет-Эксперт
Агентство элитной недвижимости размещалось на голландском хостинге: VPS с диском на 50ГБ, из которых сайт занимал 35 ГБ. Все файлы хранили на диске виртуальной машины. Объектов недвижимости стало больше и понадобилось увеличить количество картинок в 6 раз. Объём картинок превысил объём диска на виртуальной машине. VPS не масштабируется, она не облачная. Мы описали клиенту варианты решения: покупка дополнительной VPS, масштабируемый сетевой диск в Яндекс.Облаке или объектное хранилище Object Storage. Когда клиент согласился на миграцию в Яндекс.Облако и хранение контента в Object Storage, место на диске перестало быть ограничивающим фактором. Стоимость хранения сократилась на 20%
5. Удобный мониторинг инфраструктуры, диагностика неисправностей и оценка затрат
Сервис Yandex Monitoring подходит для сбора метрик состояния ресурсов и загрузки сервисов. Собрав метрики на одном дашборде, можно контролировать работу приложений, быстрее находить причины неисправностей и взаимосвязи между различными показателями. Анализируя преднастроенные дашборды, вы можете планировать ресурсы и затраты на них.

Отследить затраты помогает сервис Yandex DataLens. Данные о потреблении за день можно выгружать в формате csv-файлов. Yandex DataLens позволяет настроить дашборды на основе этих датасетов и ежедневно отслеживать затраты на вашу инфраструктуру до уровня каждого сервиса.

6. Подробная документация и помощь проверенных партнёров
Вы можете самостоятельно развернуть интернет-магазин и инфраструктуру для него или воспользоваться помощью партнёра Яндекс.Облака.

Полезные статьи в документации для запуска интернет-магазина:
Интернет-магазин на 1С-Битрикс: Управление сайтомИнтернет-магазин на платформе OpenCartС чего начать подготовку к запуску интернет-магазина и оценку требований к ИТ-инфраструктуре
Определите
поставщиков, объём и формат предоставления данных о товаре и его источники;куда будете заливать данные: в базу 1С или в базу сайта;частоту обмена данными и актуализации цен и валют;варианты хостинга.Тот, кто разрабатывает и сопровождает сайт, обязан решать следующие задачи: конфигурация серверов и баз данных под текущие требования, мониторинг роста требований, выбор площадки с возможностью быстрого масштабирования.

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

cloud.yandex.ru

Что мы сделали для вас в августе



В августе мы провели второй @DevOps Meetup и собрали 400 участников. Что они узнали:
Как «Райффайзенбанк» ушёл от зоопарка инструментов CI/CD к централизованному конвейеру на базе стека Atlassian.Как блочное хранилище Mail.ru Cloud Solutions перестало быть обычной инсталляцией Ceph (повышаем производительность наших PaaS-сервисов, как можем).Лучшие практики DevOps’а в «Росгосстрахе».Приходите к нам в следующий раз, следите за анонсами наших мероприятий в Telegram-канале k8s_mail.

А если о продуктах, то…

Mail.ru Cloud Managed Services
Мы готовы администрировать IT-инфраструктуру любой сложности и конфигурации, построенную на облаке MCS: и сервисы, и ваши приложения на них. В услугу входит администрирование, поддержка, мониторинг, реагирование на инциденты, а также аудит, консалтинг и помощь во внедрении.
mcs.mail.ru/managed-services/

Базы данных: создание кластеров ClickHouse
ClickHouse — теперь в конфигурации кластера! За счет кластеризации и горизонтального масштабирования аналитические запросы теперь летают. Для кластеров есть автоматический бэкап в наше объектное хранилище.
mcs.mail.ru/help/db-create/clickhouse

Kubernetes: прокачан мониторинг кластеров


Prometheus обновили до версии 2.9.1. Для мониторинга кластеров теперь нужно меньше ресурсов. Во встроенном мониторинге теперь много удобных возможностей: Prometheus Operator, ServiceMonitor, предустановленные дашборды в Grafana для мониторинга etcd, calico, coreDNS, более подробные дашборды о состоянии работы Kubernetes.

Сети: управление подключениями инстансов через UI
Мы сделали так, чтобы управление подключением ВМ к сетям было под рукой. В свойствах машины появилась вкладка «Информация о сетях», где есть всё, что нужно — в том числе, настройки подключений к публичной сети.


Ещё сети: настройка роутеров подсетей
При создании новой сети для роутера (шлюза) теперь можно сразу задать внутренний IP-адрес. Раньше он автоматически задавался через DHCP, и нельзя было задать свой вариант.


Поиск нужного инстанса: теперь по тегам

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

Почитать
→ Аудит безопасности облачной платформы MCS
Наш системный администратор рассказывает, как безопасность MCS проверяли внешние аудиторы, что они нашли и норм ли наше облако.

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

→ Китайское чудо через IT-перископ: как Китай вырвался вперед в сфере технологий
Текстовая версия выпуска подкаста «Завтра облачно» про Китайское Чудо и китайский ИТ-рынок. Почему китайское — это теперь не «фу», а «ого-го» и нужно ли срочно учить китайский?

Оперативно получать новости платформы MCS можно в нашем телеграм-канале: t.me/mcsnews

Cкидки до 40% на управляемые БД теперь до 31 августа 2019 года



Хорошие новости! Если вы ещё не успели попробовать управляемые БД в Яндекс.Облаке, то сейчас самое время начать. С 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 PostgreSQLYandex Managed Service for MySQLYandex Managed Service for ClickHouseYandex Managed Service for MongoDBПо всем вопросам пишите в техподдержку в консоли управления.

Новые возможности сервисов управления базами данных



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

Новая версия СУБД 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

Скидки до 40% на управляемые БД



С 1 июля по 31 июля 2019 года разверните и используйте управляемую базу данных в Облаке в платной версии и получите скидку до 40% на эту базу данных с 1 августа 2019 года на 12 месяцев. cloud.yandex.ru/promo-mdb/

Как получить скидку?
Пополните счёт на любую сумму и разверните кластер БД в Облаке.
Используйте эту БД в течение месяца, включая 31 июля.
C 1 августа подключится скидка: сервис по управлению базой данных будет доступен по цене со скидкой.
В акции есть ограничения: она распространяется на базы данных, которые вы будете использовать платно в Облаке впервые.
Подробнее про условия акции и тарифы cloud.yandex.ru/promo-mdb/termsВы найдёте руководства по миграции баз данных в Яндекс.Облако в документации. Мы подробно описали, как это сделать:
Yandex Managed Service for PostgreSQLYandex Managed Service for MySQLYandex Managed Service for ClickHouseYandex Managed Service for MongoDBПо всем вопросам пишите в техподдержку в консоли управления.
Если после 12 месяцев работы с базами данных в Облаке со скидкой вы останетесь недовольны качеством работы сервиса, мы предоставим вам консультацию нашего инженера, чтобы помочь провести обратную миграцию из Яндекс.Облака.

Облако растёт: новости сервисов





Встречайте Yandex Managed Service for Kubernetes
Мы рады объявить, что в Облаке появился сервис для управления кластерами Kubernetes!
Он подходит для запуска контейнеризованных приложений микросервисов. С помощью Yandex Managed Service for Kubernetes вы также можете мигрировать ваши приложения в Облако без рефакторинга кода и разработки дополнительных инструментов.
Сейчас Yandex Managed Service for Kubernetes находится на стадии Preview — оставьте заявку на сайте, чтобы использовать его в работе.
cloud.yandex.ru/services/managed-kubernetes

Новые сервисы в Яндекс.Облаке
Yandex Message Queue
Это масштабируемое решение для обмена сообщениями между приложениями теперь доступно всем пользователям Облака.
Настройте эффективную коммуникацию между приложениями без разработки своего протокола и обработки ошибок. Приложения с очередями сообщений легче масштабируются и обладают повышенной отказоустойчивостью. Подробнее о том, как устроен сервис, читайте в нашей статье.
Создать очередь сообщений
cloud.yandex.ru/services/message-queue
cloud.yandex.ru/docs/message-queue/

Yandex Managed Service for MySQL
Наконец-то! Теперь все пользователи Яндекс.Облака могут управлять базами данных на основе одной из самых популярных СУБД — MySQL.
MySQL отлично подходит для размещения бэкенда веб-проекта или системы управления контентом (CMS).
С сервисом Yandex Managed Service for MySQL легко создавать read-реплики. Кроме того, сервис непрерывно делает снимки БД и поддерживает технологию Point-in-Time Recovery (PITR), которая позволяет восстановить БД на любой момент времени за последние 7 суток.
Развернуть кластер MySQL в Облаке
cloud.yandex.ru/services/managed-mysql
cloud.yandex.ru/docs/managed-mysql/

Yandex Data Proc
Мы запустили сервис, который помогает разворачивать кластеры Apache Hadoop и Apache Spark в Яндекс.Облаке.
Yandex Data Proc сам создаёт хосты и настраивает их по вашим параметрам. Вы сможете изменить количество и мощности хостов в любой момент. Вы также сможете загружать свои приложения и необходимые сервисы Hadoop.
Доступ к новому сервису предоставляется по заявке — заполните её на нашем сайте.
Попробовать Yandex Data Proc
cloud.yandex.ru/services/data-proc
cloud.yandex.ru/docs/data-proc/

Yandex Instance Groups
Этот компонент сервиса Yandex Compute Cloud позволяет создавать группы однотипных виртуальных машин в инфраструктуре Яндекс.Облака.
Yandex Instance Groups поможет настроить развёртывание и горизонтальное масштабирование ваших ресурсов.
Создать группу ВМ
cloud.yandex.ru/services/instance-groups
cloud.yandex.ru/docs/compute/concepts/instance-groups/

Новые возможности
Калькулятор тарифов
Создавать виртуальные машины и базы данных на основе Intel Xeon Gold (Cascade Lake) выгоднее — производительность новых процессоров выше, а цены ниже. Убедитесь в этом — рассчитайте, сколько стоит нужная вам конфигурация ВМ или БД в калькуляторе!
Например, самая популярная конфигурация виртуальной машины в Облаке с 2 vCPU, 4 RAM и диском 13 ГБ обойдётся в 1673.88 ₽ в месяц с НДС на процессорах новой линейки (вместо 1740.56 ₽). Развернуть управляемую базу данных с частичным использованием ядра (burstable) стоит от 530 ₽ в месяц.
Перейти в калькулятор
cloud.yandex.ru/prices

Список управления доступом (ACL)
Списки управления доступом в Yandex Object Storage позволяют регулировать доступы к бакетам и объектам. Этот механизм не зависит от Yandex Identity and Access Management.
По умолчанию ACL пустой. Владелец Облака может добавить в него пользователей, сервисные аккаунты или системную группу.
Узнать больше про ACL
cloud.yandex.ru/docs/storage/concepts/acl

Другие новые функциональности сервисов
Доступна возможность обновления ранее созданных кластеров ClickHouse в Облаке.
Документация cloud.yandex.ru/docs/managed-clickhouse/operations/cluster-version-update
SQL-запросы к базам данных ClickHouse в Облаке.
Документация cloud.yandex.ru/docs/managed-clickhouse/operations/web-sql-query
CName для Yandex Managed Service for MySQL.
Документация cloud.yandex.ru/docs/managed-mysql/operations/connect
Подключение к базе данных в кластере PostgreSQL с драйвером, поддерживающим только один хост.
Документация cloud.yandex.ru/docs/managed-postgresql/operations/connect
Логическая репликация для управляемой PostgreSQL в Облаке.
Документация cloud.yandex.ru/docs/managed-postgresql/operations/data-migration
Автоматическое восстановление виртуальных машин в группе.
Документация cloud.yandex.ru/docs/compute/concepts/instance-groups/autohealing

Сценарии
Мы добавили два новых сценария по управлению инфраструктурой в Yandex Object Storage и рассказали, как установить Active Directory в Яндекс.Облаке с помощью Terraform и создать образ диска с помощью Packer.
Начало работы с Packer cloud.yandex.ru/docs/solutions/infrastructure-management/packer-quickstart
Развертывание Active Directory cloud.yandex.ru/docs/solutions/infrastructure-management/active-directory

Вебинары и мероприятия
Yandex DataLens: визуализация и анализ данных в Облаке:
Посмотреть запись
Сервисы ML и AI API в Яндекс.Облаке:
Посмотреть запись
Митап Яндекс.Облака в Санкт-Петербурге 2 июля:
Регистрация events.yandex.ru/events/meetings/jul-2