Голосовой помощник Алиса

Содержание

1. Тема и целевая аудитория
   1.1 Основная аудитория
   1.2 MVP
   
2. Метрики
   2.1 Продуктовые метрики
   2.2 Технические метрики
   
3. Глобальная балансировка
   3.1 Расположение
   3.2 Нагрузка на дата центры
   3.3 Балансировка
   3.3 Итоговое покрытие
   
4. Локальная балансировка
   4.1 Вход в дата центр
   
5. Базы данных
   5.1 Логическая схема
   5.2 Связь с API
   5.3 Размер данных
   
6. Физическая схема баз данных
   
7. Софт
   8 Технологии
   8.1 Сервисы
   
8. Надежность
   
9. Рассчет оборудования
   
10. Список использованной литературы
    

1. Тема и целевая аудитория

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

1.1 Основная аудитория

Голосовой помощник Алиса расчитан на аудитория из России и странах СНГ. Поддерживается только русский язык. MAU = 57 млн.[^1]

1.2 MVP

Основными задачами голосового помощника являются[^2]:

• Поиск информации в интернете
• Прогноз погоды
• Управление музыкой
• Запуск фильмов
• Навигация с использованием голоса

Описание функционала

1. Возможность получить информацию из интернета на заданный вопрос.
2. Возможность узнать прогноз погоды на заданный день и город.
3. Возможность запустить в другом приложении музыкальный трек, который назван пользователем.
4. Возможность запустить в другом приложении фильм, который назван пользователем.
5. Возможность построить маршрут с использованием голоса.

2 Расчет нагрузки

2.1 Продуктовые метрики

2.1.1 Расчеты

MAU = 57 млн.

В 2019 году Яндекс раскрывал информацию о ежедневной аудитории[^5]. При месячной аудитории в 30 млн., дневная была 8 млн, то есть 26%. Из этого мы можем приблизительно подсчитать, что сейчай дневная аудитория Алисы составляет 57 * 26% ~= 15 млн. пользователей.

DAU ~= 15 млн.

Данные одного пользователя

Алиса должна хранить диалоги с пользователем. Так как возможность общаться есть только в одном чате, то хранит она один чат. Пользователи задают в месяц 3.3 млрд. запросов в месяц, а значит один пользователь задаёт 3 300 млн. / 57 млн. = 58 запросов в месяц.

Алиса хранит диалоги 14 дней[^14], после чего, если пользователь не запросил, удаляет их. Предположим, что Алиса отправляет аудио и принимает аудио от пользователей. Также пользователь может общаться с ней при помощи чата.

Рассчитаем количество занимаемой памяти для текстового запроса. В среднем ответ голосового помощника составляет 29 слов[^4]. Так как нет информации по средней длине запроса, то можем предположить около 10 слов. Большой процент всех запросов делается[^6] по категориям, которые содержат в запросе не больше 5 слов.

Средняя длина слова составляет 5.28 букв[^7]. Вес одного символа 2 байта. Значит один текстовое запрос весит (29 + 10) 5.28 2 / 1024 = 0.4 КБ.

Средний размер хранилища одного пользователя за 14 дней равно 14 (58 0.4 КБ) = 324 КБ.

2.1.2 Финальные результаты

Метрика	Статистика
MAU	57 млн.
DAU	15 млн.
Среднее хранилище одного пользователя	324 КБ

2.2 Технические метрики

2.2.1 Расчеты

Хранение

У самой Алисы хранятся только записи диалогов, поэтому размер хранения равен 324 КБ * 57 млн. = 18 468 000 000 КБ или 17 ТБ.

RPS Суточный трафик равен 3 300 млн. / 30 = 110 млн. запросов в день.

Из суточного трафика найдём средний RPS за день, который равен 110 млн. / 86 400 = 1 273. Из этих данных можно предположить, что пиковый RPS будет равен 1 273 * 2 = 2 546.

Из доклада [^12] можно узнать, что в пиковые дни, например, Новый год, люди обращаются намного чаще к Алисе. Предположим, что в эти дни пиковый RPS равен 1 273 * 3 = 3 819.

Сетевой трафик

В докладе[^12] говорится, что Алиса постоянно передаёт речь пользователя для её анализе на сервере, поэтому из пикового RPS рассчитаем нагрузку на сервер. Предположим, что битрейт у Алисы и у Яндекс Музыки одинаковый и равный 192 Кбит/c[^11]. Среднее время в секунд на запрос, которые нужно озвучить = (29 + 10) (60/80) = 30 сек, как на разговор пользователя, так и на ответ Алисы. Тогда получается, что пропускная способность Алисы должна быть равной 192 Кбит/c 3 819 RPS * 30 сек / 1024 = 21 481 Мбит/с или 21 Гбит/с.

Рассчитаем количество трафика, потребляемое для связи с пользователями за день, используя информацию с расчетов текстовых запросов. Тогда вес одного запроса будет равен 30 192 / 8 = 720 КБ. Тогда за день получаем 720 110 млн. / (1024^2^) = 75 531 ГБ.

Также стоит учитывать, что для всех тем, кроме поиска информации Алиса осуществляет перевод текста пользователя, а также распознавание его намерения. В поиске Алиса должна ещё узнать информацию для пользователя. Предположим, что такой запрос весит 0.3 КБ. Тогда, с каждым запросом на поиск, Алиса дополнительно ищет информацию на 0.3 КБ.

2.2.2 Финальные результаты

Метрика	Статистика
Размер хранения диалогов	17 ТБ
Суммарный суточный трафик	75 547 ГБ
Пиковое потребление	21 Гбит/с
Количество запросов за день	110 млн.

RPS

Тип запроса	Средний
RPS средний	1 273
Пиковый RPS	2 546
RPS в особые дни	3 819

3. Глобальная балансировка

3.1 Расположение

Так как Алиса нацелена в первую очередь на рынок РФ, то сервера будут распологаться только в данной стране для лучшего подключения.

Изучив плотность населения по регионам в РФ[^17], прохождение магистральных кабелей[^20], а также население федеральных округов[^21], можно выбрать следующие локации для размещения дата центров:

• Москва
• Санкт-Петербург
• Екатеринбург
• Хабаровск
• Краснодар

3.2 Нагрузка на дата центры

Рассчитаем процент пользователей для Алисы от всех жителей России. В России проникновение интернета составляет 88.2%[^19]. Также процент проникновения Алисы равен 57 / (127 88%) 100% = 50%, тогда коэффициент для пользователей Алисы равен 0,441 или 44%

Рассчитаем среднее количество пользователей на каждый федеральный округ России[^21].

Федеральный округ	Пользуется Алисой человек тыс.
Центральный	15 662
Приволжский	11 164
Сибирский	6 478
Южный	6 477
Северо-Западный	5 397
Уральский	4 771
Северо-Кавказский	3 972
Дальневосточный	3 076

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

Дата центр	Пользователи тыс.	Средний RPS за день	Пиковый RPS
Москва	15 662	350	1051
Санкт-Петербург	5 397	120	362
Екатеринбург	15 935	356	1069
Хабаровск	9 554	213	641
Краснодар	10 449	233	701

3.3 Балансировка

Для распределения трафика между дата центрами будет использоваться система Latensy-based DNS. Будут осуществляться запросы ко всем дата центрам, а они будут обмениваться информацией и в итоге клиент будет перенаправлен на тот дата центр, к которому меньше всего задержка.

Собственный Latensy-based DNS будет описан в следующих пунктах.

3.4 Итоговое покрытие

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

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

При данном расположении дата центров задержка от пользователя будет состовлять в западной части не больше 13 мс, а в восточной не более 43, при учете, что 700 км дают 10 мс задержки.

Дата центр	Максимальная Задержка мс
Москва	7
Санкт-Петербург	14
Екатеринбург	28
Хабаровск	35
Краснодар	14

4. Локальная балансировка

4.1 Вход в дата центр

DNS отдаёт адрес "Big Balancer", поэтому весь входящий трафик сначала попадает на "Big Balancer". "Big Balancer" определеяет минимально загруженный балансировщик по принципу минмальных подключений к балансировщику. Перенаправление будет выполнино при помощи 302 редирект.

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

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

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

Из-за данного алгоритма, можно разделить всю нагрузку с упавших балансировщиков равномерно по времени, поэтому нагрузка будет рассчитана по формуле (трафик с упавших балансировщиков) / 6.

Дата центр	Big Balancer нагрузка в тыс	Количество Big Balancer
Москва	261	26
Санкт-Петербург	89	8
Екатеринбург	265	26
Хабаровск	159	15
Краснодар	174	17

Для балансировки "Big Balancer" использована технология BGP Anycast. Большие балансировщики подключены к базе "Live BD", которая раз в секунду опрашивает балансеры о нагрузке и записывает в себя.

При максимальном количестве переподключений большой балансер должен обладать из 24 ядер минимум[^28].

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

Схема устройства входа в дата центр

Схема подключения к балансировщику и получения ответа от сервера

4.2 Балансировка до сервера

После того, как трафик попадает в дата центр, будет организована балансировка при помощи L7 балансировщика. Плюсом данного типа балансировки является то, что у нас будет возможность просматривать конкретные протоколы, а также ставить timeout и следить за падениями определенных серверов. Также, он будет поддерживать persistent connection с серверами, что уберёт задержку при отправке запросов.

Для связи серверов внутри дата центра будет использоваться Server Mesh c Proxy, установленным на каждый сервер. Так как приложения будту запущены в контейнерах, то также будет использоваться eBPF[^24][^26][^27] для связи приложений друг с другом, если они находятся на одном сервере.

На роль L7 балансировщика, а также Proxy будет выбран Envoy[^22][^23], так как он быстрее работает с HTTPS, может обработать больше запросов, а также поддерживает динамическое изменение конфигурации по gRPC запросам.

Один Envoy(nginx) сервер может выдержать 100 000 соединений[^25]. Количество серверов на каждый регион:

Дата центр	Серверы
Москва	156
Санкт-Петербург	53
Екатеринбург	159
Хабаровск	95
Краснодар	104

Схема устройства внутри.

5. Базы данных

5.1 Логическая схема

Алиса хранит диалоги в базе данных в таблице Questions. Пользователем может быть либо устройство с browserSession, который выдаётся, либо с аккаунтом, где есть login и password.

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

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

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

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

По статистике, только около 5-10% клиентов оставляют отзыв[^32]. Исходя из этого можно рассчитать количество запросов на запись в AnswersQuality таблицу. Чтение данных будет происходить при обучении моделей.

Для рассчета количества записей возьмем два финансовых отчета яндекса и найдём количество новых пользователей. За октябрь[^33] 61.5 млн, а за июль [^1] 57. Получим RPS на запись в таблицу равный (61.5 млн - 57 млн) / (4 30 24 60 60) = 0.5 RPS

Таблица	Нагрузка чтение	Нагрузка запись
ML	X в неделю	1 раз в неделю
Audios	M	3 819
Users	3 819	0.5 RPS
Sessions	3 819	0.5 RPS
Questions	3 819	M
AnswersQuality	381	M

5.2 Связь с API

Каждый запрос к Алиcе должен быть записан в БД, при этом, также должен быть записан и ответ. Можно предположить, что при больших нагрузках, можно позволить отставания в записи, так как ответ должен будет отправиться пользователю и быть прослушан им.

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

5.3 Размер данных

Размер индексов рассчитаем из того, что пользователь в среднем делает 58 запросов в месяц, а храним только 14 дней, и того получаем (58 / 2) 8 байт = 232 байта на пользователя или 57 млн 232 = 12 ГБ.

Пусть логин будет состоять максимум из 32 знаков. Для хранения индексов о логине или сессии будет использовано 57 000 000 (32 16) = 27 ГБ.

В пункте 2.1 получаем, что средний запрос к Алисе составляет 7.5 секунд. Алисы составляет 192 Кбит/с. Тогда средняя запись голоса весит 180КБ. Тогда за 1 месяц получаем 553 ТБ данных. Предположим, что записи голоса хранятся два года. Тогда хранение голоса занимает 553 12 3 = 19 915 ТБ.

Пусть одна модель по размеру будет равна 200 МБ. Допустим, что каждую неделю релизится новая модель(для озвучивания и расшифровки). Тогда вес всех моделей равен 200МБ 2 318 = 124 ГБ.

Данные	Размер
Хранение вопросов в текстовом виде	17 ТБ
Индексы	39 ГБ
Голосовые записи	19 915 ТБ
Вес моделей	124 ГБ

6. Физическая схема баз данных

Общая схема

В скобках указаны физические таблицы.

Субд	Таблица из логической схемы	Функционал	Нагрузка чтение	Нагрузка запись	Занимаемое место
Hadoop	Audios, Questions, AnswerQuality(AudioStore)	Хранение голосовых сообщений пользователя. Расшифровки сообщений. Качество ответов. 2 запроса в 12 часлов, для загрузки данных в ClickHouse и Nvidia AIStore 7ГБ	1 запрос раз в 5 минут из Kafka 252ГБ	попытка записи за раз ограничение на скорость накладывается оборудованием, на котором запущен Hadoop	19 915 ТБ
ClickHouse	AnswerQuality И отдельно темы запросов(QuestionsTheme)	Загрузка данных для аналитиков	Ограничивать доступ по объёму запроса и количеству запросов в день. Поддерживает шардирование	Запись раз в 12 часов 7 ГБ за раз	2ТБ за 3 месяца
Kafka	Audios, Questions, AnswerQuality(AudioStore)	Хранит временные данные для записи раз в 5 минут в Hadoop. Получает от сервера записи голоса полностью вместе с расшифровкой[^31]	Раз в 5 минут	3 819 RPS 90MB/s	138 ТБ
Tarantool	Users(Users, Sessions)	Хранит данные о пользователях и их сессиях	3 819RPS 240KB/s	0.5	27ГБ индексы 125ГБ данные

Надежность и эффективность

БД	Надежность	Эффективность
Hadoop	Hadoop 3 Erasure Encoding, позволяет хранить вместо копий "parity cells" Hadoop data node будут размещаться на разных серверах, разных рядах, для обеспечения надёжности системы при падения. Для Name Node будет использована "Backup Node".	Flint будет использован для однократной записи в систему, так как может проверять
ClickHouse	Создается Backup раз в день автоматически.	Ограничивать доступ по объёму запроса и количеству запросов в день. Создано шардирование.
Kafka	Для обеспечения сохранности данных будет использоваться фактор репликации 3. Данные будут храниться неделю, на случай выхода из строя Hadoop	Создание Kafka-broker с помощью Kafka Raft metadata[^43], чтобы выдерживать нагрузку
Tarantool	На каждом ДЦ создаются свои реплики. Между всеми репликами ставится связь Master-Master[^40]. Таким образом данные о пользователях будут на всех ДЦ.	Будет использовано круговое шардирование, для возможности добавления новых шардов в будущем. Индекс на логин пользователя, на сессию пользователя.

AIStore и S3

AIStore[^41] это object database, и в ней будут храниться подборки голосовых записей для обучения моделей.

AIStore был выбран за следующие качества:

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

Также ML модели хранятся в S3, где все параметры зависят от поставщика S3 хранилища.

7. Софт

7.1 Latency-based DNS

Будет разработан алгоритм Latency-based DNS, который будет работать по следующему принципу:

1. Пользователь подключается к ДЦ, который получил от DNS
2. Пользователь получает данные о всех ДЦ
3. Пользователь отправляет запросы во все ДЦ
4. ДЦ обмениваются информацией о задержках от пользователя
5. ДЦ, где сейчас подключен пользователь перенаправляет его на ДЦ с минимальной задержкой, свободными ресурсами для клиента(Prometheus).

Если упал один из ДЦ, то:

1. Если информация из ДЦ не приходит в течении 5 секунд, то ближайший ДЦ меняет настройки ДНС.
2. Настройки меняются по принципу, что распределение трафика на ближайшие ДЦ(карта ДЦ будет зашита внутри у каждого ДЦ).
3. ДЦ принимает поступающие соединения, при этом включается работа собственного алгоритма Latency-based DNS, который будет распределять нагрузку на ближайшие ДЦ к клиенту.

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

8 Технологии

Технология	Применение	Обоснование
Go	Backend, основной язык сервисов	Простота языка, удобные тулзы из коробки, высокая утилизация CPU
C	Backend, высоконагруженные сервисы	Оптимизация узких мест, ускорение высоконагруженных частей проекта
Python	Работа с ML, обучение моделей	Единый язык для ML задач
TypeScript, React	Frontend	Типизация, сокращение человеко-часов не отладку, ускорение процесса разработки, компонентный подход
ELK[^38][^39]	Автоматизация работы с логами. Хранение и поиск данных, обработка и фильтрация, интерфейс для администрирования	Масштабируемость, отказоустойчивость, гибкость поиска, REST API, универсальность
Jaeger[^35]	Система трассировки	-
VictoriaMetrics	Хранение метрик и работа с метриками	Производительность, меньший объем для хранения, чем в Prometheus [^36]
Grafana[^37]	Визуализация графиков, мониторинг и алерты	-
GitHub	Система контроля версий, командная разработка, CI/CD.	-
Kubernetes	Deploy	Масштабирование, отказоустойчивость, утилизация ресурсов
MPEG-DASH [^34]	Передача и разбиение аудио	Может разбивать и отправлять сразу по маленьким сегментам. Открытый протокол, из-за чего нет стандартов.
FastPitch + Hifi-GAN	Озвучивание текста	Данная модель выбрана за небольшое количество ошибок, а также за скорость работы
wav2vec 2.0	Перевод аудио в текст	Данная модель выбрана за небольшое количество ошибок, а также за скорость работы

8.1 Сервисы

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

9 Надежность

Система

Под большой нагрузкой постепенная деградация распознавания речи(уменьшения дискретности распознования). Допускается долгий ответ.

Включение и настройка Alert оповещений, при сбоях в системе, по собираемой статистике(см. 8.1).

БД

БД	Меры
Hadoop	Будет для надежности включена настройка на Hadoop 3 Erasure Encoding для восстановления файла при потери копий. Hadoop data node будут размещаться на разных серверах, разных стойках, для обеспечения надёжности системы при падения.
ClickHouse	Создается Backup раз в день автоматически
Tarantool	На каждом ДЦ создаются свои реплики. Между всеми репликами ставится связь Master-Master[^40]. Таким образом данные о пользователях будут на всех ДЦ.
Kafka	Для обеспечения сохранности данных будет использоваться фактор репликации 3.Также создание Kafka-broker с помощью Kafka Raft metadata, чтобы выдерживать нагрузку. Данные будут храниться неделю, если Hadoop упадёт.
Flint	Записывает данные всегда только один раз, при помощи опроса Hadoop о записи(2-ух фазовый коммит)

ДЦ

Наличие нескольких ДЦ по стране, в случае отказа одного, трафик перейдёт на другой.

Вместе с Victoria Metrics для просмотра статистики по ДЦ внутри ДЦ, будет использоваться Prometheus Federation^42, для передачи метрик между ДЦ. Если метрики не приходят в течении 5 секунд, то ближайший ДЦ меняет настройки ДНС.

Данные между Prometheus будут удаляться раз в 4 дня.

Наличие 2 входных роутеров, а также дублирование всех критических компонентов в системе

10 Рассчет оборудования

Из пункта 3.2 таблица таблица с пиковым RPS.

Дата центр	Пиковый RPS
Москва	1051
Санкт-Петербург	362
Екатеринбург	1069
Хабаровск	641
Краснодар	701

Работа логики

Сервис	Ядер и RAM(МБ) МСК	Ядер и RAM(МБ) СПБ	Ядер и RAM(МБ) ЕКБ	Ядер и RAM(МБ) Хабаровск	Ядер и RAM(МБ) Краснодар
Авторизации	11 - 1100	4 - 400	11 - 1100	7 - 700	7 - 700
Взаимодействия	110 - 11 000	36 - 3600	110 - 11 000	65 - 6500	70 - 7 000
Распознование интента	110 - 11 000	36 - 3600	110 - 11 000	65 - 6500	70 - 7 000
Поиска информации	11 - 1100	4 - 400	11 - 1100	7 - 700	7 - 700
Выгрузки данных	110 - 11 000*	36 - 3600*	110 - 11 000*	65 - 6500*	70 - 7 000*
Обучения моделей	110 - 11 000	36 - 3600	110 - 11 000	65 - 6500	70 - 7 000
Логики	110 - 11 000	36 - 3600	110 - 11 000	65 - 6500	70 - 7 000
Hadoop	110 - 11 000*	36 - 3600*	110 - 11 000*	65 - 6500*	70 - 7 000*
Kafka	110 - 11 000*	36 - 3600*	110 - 11 000*	65 - 6500*	70 - 7 000*
ClickHouse	110 - 11 000*	36 - 3600*	110 - 11 000*	65 - 6500*	70 - 7 000*
Tarantool	110 - 11 000*	36 - 3600*	110 - 11 000*	65 - 6500*	70 - 7 000*
S3	11 - 11 000*	4 - 4000*	11 - 11 000*	7 - 7000*	7 - 7000*

*Для быстроты работы максимальный объём памяти.

Распознование

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

Распознование аудио

Из пункта 2.1 можно понять, что средняя продолжительность речи пользователя 7.5 секунд.

Модель для озвучивания wav2vec 2.0 выбрана за приемлимое количество ошибок и большую пропускную способность.

Из статьи[^44] можно получить, что скорость равна 224с аудио в секнуду работы.

Карта для работы взята A100.

Сервис	Cuda	Память	Штук
Москва	374 550	2 627	131
Санкт-Петербург	129 007	905	45
Екатеринбург	380 964	2 672	133
Хабаровск	228 436	1 602	80
Краснодар	249 818	1 752	87

Озвучивание текста

Для расчета перевода из текста в аудио, возьмём данные из статьи^45.

Модель для озвучивания FastPitch + Hifi-GAN, за большую пропускную способность. В 10 потоков обрабатывает 464.114 секунд за 1 секунду работы.

Из пункта 2.1 можно понять, что озвученный текст в среднем 22.5 секунды. Получаем, что одновременно нужно озвучить для каждого ДЦ.

Сервис	Штук
Москва	51
Санкт-Петербург	18
Екатеринбург	52
Хабаровск	32
Краснодар	34

Конфигурация

Сервис	Конфигурация	Cores	Видеокарты	Cnt(МСК)	Cnt(СПБ)	Cnt(ЕКБ)	Cnt(Хаб)	Cnt(Кра)	Покупка	Аренда
Авторизация	A2SDi-8C-HLN4F- 8-Core C3758 Atom/2x 4GB 2400MHz DDR4/CyberServe Atom-104i	8	-	2	1	2	1	1	$175	--
Взаимодействия	2x Intel Xeon Gold 6448Y Processor/2x16GB 4800MT/s DDR5/CyberServe Xeon SP2-104S NVMe G4	64	-	2	1	2	2	2	$1 777	--
Распознование речи	AMD EPYC 7702P/8x64GB/500GBSamsung 970 EVO PLUS NVME M.2/CyberServe EPYC EP1-G292-Z20 GPU Server	64	A100	16(8)	6(8)	16(8)	10(8)	11(8)	€135 603	$658 312
Распознование интента*	AMD EPYC 7702P/8x64GB/500GBSamsung 970 EVO PLUS NVME M.2/CyberServe EPYC EP1-G292-Z20 GPU Server	64	A100	7(8)	3(8)	7(8)	4(8)	5(8)	€57 801	$280 592
Поиска информации	A2SDi-8C-HLN4F- 8-Core C3758 Atom/2x 4GB 2400MHz DDR4/CyberServe Atom-104i	8	-	2	1	2	1	1	$175	--
Озвучивания	AMD EPYC 7702P/8x64GB/500GBSamsung 970 EVO PLUS NVME M.2/CyberServe EPYC EP1-G292-Z20 GPU Server	64	A100	7(8)	3(8)	7(8)	4(8)	5(8)	€57 801	$280 592
Выгрузки данных	2x Intel Xeon Gold 6448Y Processor/16x128GB 4800MT/s DDR5/CyberServe Xeon SP2-104S NVMe G4	64	-	2	2	2	2	2	$7 695	--
Логики	2x Intel Xeon Gold 6448Y Processor/2x16GB 4800MT/s DDR5/CyberServe Xeon SP2-104S NVMe G4	64	-	2	2	2	2	2	$1 975	--
Балансировщики	AMD EPYC 7443P/2x 8GB 3200MHz DDR4/CyberServe EPYC EP1-102	24	-	182	64	185	110	121	€27 589	-

• Возьмём, что распознование интента будет работать также, как и озвучивание текста.

Отдельно в каждом ДЦ будут следующие сервисы.

Сервис	Конфигурация	Cores	Cnt	Покупка	Аренда
Hadoop	2x Intel Xeon Gold 6346 Processor/18x 128GB/72x 15.36TB Samsung Enterprise/CyberStore 472S 12GB/s Storage Server	16	19	€79 183	--
Kafka	2x Intel Xeon Gold 6338 Processor/16x128GB 3200MHz DDR4/4x 20TB/CyberStore 212S 12GB/s Storage Server	64	2	€848	--
ClickHouse	2xIntel Xeon Gold 6338/20x 128GB 3200MHz DDR4/2x 1.9TB SSD/CyberServe Xeon SP2-108NS G3	64	2	€930	--
Tarantool	2xIntel Xeon Gold 6338/20x 128GB 3200MHz DDR4/2x 240GB SSD/CyberServe Xeon SP2-108NS G3	64	2	€915	--
Minio	2xIntel Xeon Gold 6338/2x 64GB 3200MHz DDR4/2x 240GB SSD/CyberServe Xeon SP2-108NS G3	64	2	€915	--

Также сервис для обучения моделей.

Сервис	Конфигурация	Cores	Видеокарты	Cnt	Покупка	Аренда
Обучения моделей	AMD EPYC 7702P/8x64GB/500GBSamsung 970 EVO PLUS NVME M.2/CyberServe EPYC EP1-G292-Z20 GPU Server	64	A100	10(8)	€22 232	$107 920

Для увеличения надежности, все данные в таблицах нужно умножить на 1.5, чтобы было резервирование n/2, чтобы при падении ДЦ, другие ДЦ могли осилить нагрузку.

---

Список использованной литературы

[^1]: Отчёт за квартал 2023 года Яндекс [^2]: Навыки Алисы [^4]: Voice Search Statistics: Smart Speakers, Voice Assistants, and Users in 2023 [^5]: "Яндекс" назвал ежедневную аудиторию голосового помощника "Алиса" [^6]: Больше денег – больше слов: как голосовые помощники завоевывают рынок [^7]: Статистика слов в русском языке

[^9]: Голосовые помощники: что это и зачем они HR [^10]: Большая российская энциклопедия 2004-2017 [^11]: Yandex Support [^12]: Доклад HighLoad [^13]: Voice report 2019 [^14]: Ответ Алисы [^15]: Яндекс ИТ-инфраструктура [^16]: «Яндекс» начал строительство четвёртого дата-центра в России [^17]: Плотность населения РФ [^18]: Округа РФ [^19]: Global Statistics Russia [^20]: Магистральные сети связи в России [^21]: Население федеральных округов России [^22]: Kubernetes Gateway Selection: Nginx or Envoy? [^23]: Benchmarking Envoy Proxy, HAProxy, and NGINX Performance on Kubernetes [^24]: Hello eBPF! Goodbye Sidecars? [^25]: What is keepalive in Nginx [^26]: eBPF в production-условиях / Дмитрий Евдокимов, Александр Трухин (Luntry) [^27]: How eBPF will solve Service Mesh – Goodbye Sidecars [^28]: Testing the Performance of NGINX and NGINX Plus Web Servers [^29]: Mongo Backup [^30]: Clickhouse perfomance [^31]: Kafka perfomance [^32]: Online Review Statistics: The Definitive List (2023 Data) [^33]: Яндекс. Презентация о компании Октябрь 2023 [^34]: HLS Vs. DASH [^35]: Просто о сложном: трассировки в микросервисах [^36]: Бенчмарк Prometheus vs VictoriaMetrics на метриках node_exporter [^37]: Monitoring as Code на базе VictoriaMetrics и Grafana [^38]: Graylog vs ELK [^39]: Advantages of Graylog+Grafana Compared to ELK Stack [^40]: Репликация в Tarantool: конфигурирование и использование [^41]: AIStore: an open system for petascale deep learning

[^43]: KRaft — The Next Generation Kafka Architecture [^44]: Benchmarking Top Open Source Speech Recognition Models: Whisper, Facebook wav2vec2, and Kaldi

Методические Указания