Yandex Cloud

Плановое обновление сервиса Yandex Monitoring вносит концептуальные изменения и новые возможности для работы с метриками. Рассказываем обо всём по порядку.

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

• Убрали деление на папки.
• Все дашборды теперь можно найти в одном списке.
• Включили механизм удаления устаревших метрик (TTL).

Метрики, для которых не поступали новые значения в течение 30 дней, автоматически удаляются из Yandex Monitoring. Автоматическое удаление метрик запускается минимум раз в сутки. Метрики, по которым данные продолжают поступать, не удаляются. Подробнее об этом механизме читайте в документации.

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

Функции можно применять в строке запроса:


Также их можно применять в текстовом режиме:


Полный список функций с описанием доступен в документации.
cloud.yandex.ru/docs/monitoring/concepts/querying

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



Список параметров дашборда можно найти в документации.
cloud.yandex.ru/docs/monitoring/concepts/visualization/dashboard

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


Если у вас возникли вопросы или сложности в работе с Yandex Monitoring после планового обновления сервиса, напишите нам.

Среди управляемых сервисов для хранения и обработки данных появился новый сервис 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.

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


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

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

Валарм WAF помогает бороться с поиском уязвимостей и хакерскими атаками, которые могут привести к компрометации данных: SQL-инъекции, XSS, XXE, RCE и другие угрозы OWASP Top-10. Также разработчики получат защиту от брутфорса, кражи учетных записей и атак на логику приложения.

Для использования Валарм WAF клиентам не нужно вносить изменения в исходный код и архитектуру защищаемого приложения. Получить доступ к решению можно непосредственно из маркетплейса Яндекс.Облака. На момент запуска инструмент доступен пользователям Облака по модели BYOL (Bring Your Own License): подписку на услугу необходимо оформить напрямую у Валарм. В будущем приобрести лицензию можно будет в маркетплейсе Облака.
cloud.yandex.ru/marketplace/products/f2e6gba83h48oik7bla4

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

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

Валарм — платформа для автоматизации защиты и тестирования веб-приложений, микросервисов и API, созданная на базе машинного обучения. Разработчик платформы — компания «Онсек». Приложением Валарм WAF пользуются QIWI, HeadHunter, Avito и другие крупнейшие компании Рунета.

Мы рады поделиться ещё одной реализованной идеей сообщества Яндекс.Облака: создание и управление очередями сервиса Yandex Message Queue теперь возможно через популярный инструмент управления — Terraform.

Чтобы управлять своими сервисами и ресурсами с помощью Terraform, создайте конфигурационный файл и настройте провайдер Яндекс.Облака. Для этого воспользуйтесь пошаговой инструкцией.

С помощью Terraform вы можете создавать и удалять очереди сообщений, а также использовать ранее созданные очереди при помощи data source. Все параметры и атрибуты можно найти в документации и на странице Terraform-провайдера Облака.
www.terraform.io/docs/providers/yandex/r/message_queue.html
cloud.yandex.ru/docs/message-queue/instruments/terraform
cloud.yandex.ru/docs/solutions/infrastructure-management/terraform-quickstart

Примеры создания очередей сообщений
Конфигурационный файл для стандартной очереди:

provider "yandex" {
    token     = "<OAuth или статический ключ сервисного аккаунта>"
    folder_id = "<идентификатор каталога>"
    zone      = "ru-central1-a"
  }

resource "yandex_message_queue" "example_queue" {
  name                        = "ymq-terraform-example"
  visibility_timeout_seconds  = 600
  receive_wait_time_seconds   = 20
  message_retention_seconds   = 1209600
  access_key                  = "<идентификатор статического ключа доступа>"
  secret_key                  = "<секретная часть статического ключа доступа>"
}

Конфигурационный файл для очереди FIFO:

provider "yandex" {
    token     = "<OAuth или статический ключ сервисного аккаунта>"
    folder_id = "<идентификатор каталога>"
    zone      = "ru-central1-a"
  }

resource "yandex_message_queue" "example-fifo-queue" {
  name                        = "ymq-terraform-example.fifo"
  visibility_timeout_seconds  = 600
  receive_wait_time_seconds   = 20
  message_retention_seconds   = 1209600
  fifo_queue                  = true
  access_key                  = "<идентификатор статического ключа доступа>"
  secret_key                  = "<секретная часть статического ключа доступа>"
}

Пример создания очереди c политикой перенаправления недоставленных сообщений в DLQ c именем ymq_terraform_deadletter_example:

provider "yandex" {
    token     = "<OAuth или статический ключ сервисного аккаунта>"
    folder_id = "<идентификатор каталога>"
    zone      = "ru-central1-a"
  }

resource "yandex_message_queue" "example_fifo_queue" {
  name                        = "ymq-terraform-example"
  visibility_timeout_seconds  = 600
  receive_wait_time_seconds   = 20
  message_retention_seconds   = 1209600
  redrive_policy              = jsonencode({
    deadLetterTargetArn = yandex_message_queue.example_deadletter_queue.arn
    maxReceiveCount     = 3
  })
  access_key                  = "<идентификатор статического ключа доступа>"
  secret_key                  = "<секретная часть статического ключа доступа>"
}

resource "yandex_message_queue" "example_deadletter_queue" {
  name                        = "ymq_terraform_deadletter_example"
  access_key                  = "<идентификатор статического ключа доступа>"
  secret_key                  = "<секретная часть статического ключа доступа>"
}

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

Yandex Scale 2020
Ура! 23-25 сентября пройдет большая конференция Яндекс.Облака — Yandex Scale 2020. В этом году мероприятие пройдет онлайн.
Мы расскажем о будущих сервисах, а партнеры и клиенты поделятся историями о работе в Облаке. Вы сможете задать вопросы разработчикам платформы и поболтать с другими пользователями Облака.
cloud.yandex.ru/events/scale-2020/


Локдаун: Как IT помогает выжить бизнесу
Продолжаем вместе с РБК следить за тем, как изоляция повлияла на бизнес. Изменились ли потребности клиентов и требования к IT в июне — смотрите во второй серии онлайн-дискуссии.
lockdown.rbc.ru/live


JivoSite переехал в Облако
Ведущий сервис для общения с клиентами перенес российский контур из AWS в Яндекс.Облако. Мы разобрали все этапы переезда — от теста до продакшена.
cloud.yandex.ru/cases/jivosite

Другие истории наших пользователей
Blumenkraft: MongoDB для больших массивов данных
Blumenkraft создает цифровые системы учета, которые позволяют собирать и анализировать данные о бизнесе. С помощью методологии CQRS и MongoDB в Облаке компания настроила гибкую и выгодную систему хранения данных.
cloud.yandex.ru/cases/blumenkraft

Hacktory: как снизить задержки
Hacktory — это платформа для онлайн-обучения информационной безопасности. Как они переехали в Облако своими силами и снизили задержки с 30 мс до 5–6 мс — читайте в блоге.
cloud.yandex.ru/cases/hacktory

Предложения для бизнеса
Делимся полезными бизнес-продуктами Яндекса и партнеров Облака.
MTT VoiceBox: звонки на базе Yandex SpeechKit
В честь запуска сервиса автоматизации звонков компания МТТ дарит 5000 рублей на звонки: чтобы воспользоваться предложением, позвоните по номеру 8 (800) 505-81-78 и назовите промокод: yandex18_promo5
www.mtt.ru/ru/voicebox/

На прошедшем мероприятии, посвященном бессерверным технологиям и IoT мы анонсировали запуск нового сервиса для создания API-шлюзов — Yandex API Gateway. С помощью API-шлюзов вы можете создавать веб-сервисы в serverless-парадигме на базе платформы Яндекс.Облако. API Gateway находится на стадии Preview и не тарифицируется.

В чем преимущества Yandex API Gateway

• создавайте полностью управляемые прокси-серверы на базе OpenAPI Specification;
• используйте домены и TLS-сертификаты сервиса Yandex Certificate Manager;
• следите за основными показателями работы сервиса с Yandex Monitoring;
• просматривайте журнал вызовов.

На стадии Preview Yandex API Gateway интегрирован с сервисами

• Yandex Cloud Functions — отправляйте HTTP-запросы с помощью функций;
• Yandex Object Storage — обеспечивайте доступ к статическим данным напрямую из хранилища;
• Yandex Managed Service for Kubernetes — запускайте произвольные HTTP-сервисы в Яндекс.Облаке.

Запросить доступ к сервису можно через форму заявки на странице сервиса или в консоли управления.
cloud.yandex.ru/services/api-gateway
Подробнее о новом сервисе читайте в документации.

2 июля в 17:00 проведём онлайн-мероприятие about:cloud, во время которого:

• расскажем о новой функциональности Cloud-Native сервисов и планах развития направлений IoT и Serverless;
• представим новый сервис API Gateway;
• покажем примеры интеграции сервисов Yandex Message Queue и Yandex Monitoring;
• расскажем про алертинг в Yandex Monitoring;
• покажем Terraform-провайдер для Yandex Message Queue.

Бонус для участников: возможность первыми поучаствовать в тестировании новых сервисов Облака.
cloud.yandex.ru/events/145

Резюме по инциденту
В пятницу 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 — Мы начали оказывать помощь пострадавшим пользователям по их запросам.

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

Последствия для пользователей:

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

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

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

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

Меры для предотвращения повторения подобной ситуации в будущем

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

Мы также рекомендуем нашим клиентам:

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

cloud.yandex.ru/events/scale-2020/

«Транслинк» входит в топ-5 российских компаний в сфере профессионального перевода. Компания создает цифровые продукты, которые снижают стоимость и увеличивают скорость перевода, что позволяет оставаться одним из лидеров индустрии.
В начале 2020 года компания «Транслинк» запустила новый продукт TransМасhine — сервис на основе технологий машинного перевода от Яндекс.Облака.

Как устроен TransMachine
Сервис использует доменно-адаптивный движок машинного перевода. Он постоянно обучается на текстах выбранной тематики и на памяти переводов (translation memory). TransMachine создан на базе Yandex Translate — облачного сервиса машинного перевода с использованием нейронной сети. Алгоритм Yandex Translate постоянно самообучается на большом количестве параллельных текстов, что повышает качество машинного перевода.

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

Опыт применения
Одним из первых клиентов сервиса TransМасhine стал крупный холдинг, включающий десятки предприятий с сотнями сотрудников. Компании сотрудничают с зарубежными предприятиями. Количество общения с зарубежными партнерами выросло, что привело к росту объема документов на перевод.

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

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

Решение
Специалисты «ТрансЛинк» оценили эффективность ручного перевода, постредактуры машинного перевода (MT) и постредактуры перевода TransMachine. Они сравнили стоимость, временные затраты и качество результата и подготовили для заказчика следующую таблицу:



По подсчетам наиболее выгодным вариантом оказался сервис TransMachine: он в 2-3 раза быстрее на 30% дешевле ручного перевода, а качество готового текста примерно такое же.

Процесс
Специалисты «Транслинк» получали сканы документов компании в формате PDF, переводили их в читаемый формат и загружали в CAT-систему с подключенным облачным сервисом машинного перевода (MT).

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

Результаты
Результаты тестового периода показали, что клиент сэкономил 30% бюджета, а скорость перевода выросла в 2 раза. Заказчик получает переведенные документы на 12-24 часов раньше. За счет обучения алгоритма объем перевода с января по март вырос в два раза: с 30 до 60 страниц в день.

Сейчас «Транслинк» работает над улучшением распознавания отсканированных и электронных документов, чтобы ускорить процесс перевода с помощью TransMachine.

Попробовать TransMachine → www.transmachine.ru