• 1. Тема и целевая аудитория
• 2. Расчёт нагрузки
• 3. Глобальная балансировка нагрузки
• 4. Локальная балансировка нагрузки
• 5. Логическая схема базы данных
• 6. Физическая схема базы данных
• 7. Алгоритмы
• 8. Технологии
• 9. Обеспечение надёжности
• 10. Схема проекта
• 11. Расчёт ресурсов
• Список использованных источников

Google Calendar — сервис для планирования встреч, событий и дел.

MAU = 500 млн. [1], [2], [4]

Информация о DAU отсутствует, поэтому примем его, равным 500 млн. пользователей, т.е. MAU = DAU, т.к. данный тип сервиса используется для планирования встреч, событий и дел, а также для синхронизации данных на устройствах. [3]

• Регистрация, авторизация;
• Создание, редактирование календарей;
• Каждый календарь можно сделать общедоступным либо предоставить отдельным людям доступ к нему (просмотр или редактирование) через приглашение по электронной почте;
• Уведомления о предстоящих событиях по почте;
• Создание и редактирование событий.

Базовый функционал этого приложения включает в себя следующие типы данных:

• Примем число личных календарей, равным 5 и число календарей, в которые пользователь может быть приглашён, равным 10.
• Максимальное число пользователей, которых можно пригласить на событие примем равным 200 [14].
• Число событий, создаваемым пользователем в день примем равным 3 (при общем числе событий в 1,5 млрд [3] и DAU = 500 млн. число событий 1500/500 = 3) и хранятся 5 лет, поэтому за 5 лет у пользователя накопится 5 * 365 * 3 = 5475.
• Все символы будут храниться в кодировке UTF-8, где каждый символ занимает около 3-х байт [15].

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

В виду сложности оценки пересылаемой информации в уведомлении примем размер дополнительной полезной нагрузки, равным 1 KiB.

В виду сложности оценки пересылаемой информации в напоминании примем размер дополнительной полезной нагрузки, равным 1 KiB.

• Общий размер здесь проведён приближённо, для оценки размера хранилища.

Т.к. количество зарегистрированных аккаунтов в Google Workspace равно 3 млрд [1]-[4] и, учитывая, что Calendar создаётся для каждого пользователя, примем количество зарегистрированных пользователей равным 3 млрд.

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

Здесь также не учтены приглашённые пользователи, т.к. это динамически меняющийся массив и можно установить лишь ограничение на присоединение к календарю в течение короткого промежутка времени [16].

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

1. Средний RPS

   DAU * количество действий * количество запросов для действия / 86400 сек

2. Средний суточный трафик:

   DAU * количество действий * количество байт пересылаемых запросами для совершения действия / 86400 сек

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

Допущения

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

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

• Просмотр календарей, кроме запроса на получение данных самого календаря, включает запрос на получение данных пользователя, поэтому суммарное количество запросов равно (1 + 1) * 15 = 30, а количество данных равно соответственно (17400 + 965) * 15 = 275475 B.
• Взаимодействие с календарями включает лишь создание/обновление события, поэтому суммарное количество запросов равно 3, а количество данных равно соответственно 3 * 17400 = 52200 B.
• Получение уведомлений включает лишь один запрос, поэтому суммарное количество запросов на получение уведомлений равно 15, а количество данных уведомления соответственно данным о событии, т.е. получим 15 * 1040 = 15600 B.
• Получение ответа на уведомление включает лишь запрос на отправку ответа на уведомление, поэтому получим 15 * 264 = 3960 B.
• Получение напоминания составляет столько пересылаемой информации, как и получение уведомления, поэтому 15 * 1040 = 15600 B.

Для получения пиковых значений RPS и трафика умножим среднее потребление трафика в два раза (возьмём коэффициент запаса, равный 2-м).

Для анализа основных регионов потоков трафика были выбраны следующие статистики:

Similarweb.com был выбран, несмотря на свою неточность для обобщения с остальными статистиками, т.к. это позволит увеличить выборку.

Обобщим эти статистики (Китай был исключён из этой выборки ввиду особенностей доступности и использования в нём иностранных сервисов):

1. USA — 42.93%
2. India — 10.7%
3. Japan — 8.17%
4. United Kingdom — 3.68%
5. Canada — 3.56%
6. France — 3.43%
7. Iran — 3%
8. Russia — 2.9%
9. Brazil — 2.8%
10. Other — 25.26%

Исходя их этой статистики можно сделать вывод, что основная часть дата-центров должна располаться в США, остальные — региональные.

Возможные города распложения дата-центров возьмём из [13].

Для анализа возможного расположения дата-центров учтём то, что факт задержки (Latency) не важен для данного сервиса, поэтому лучше выбрать немного дата-центров, но сделать их максимально надёжными. Следовательно, их необходимо располагать в городах, в которых находятся наиболее крупные дата-центры (это можно сделать, анализируя, например, их энергопотребление) и максимально близкими к основной аудитории.

Из вышесказанного следует, что дата-центры будут расположены следующим образом:

• Основные дата-центры в США:
  • Вирджиния (Северо-восток)
  • Лос-Анджелес (Юго-запад)
• Дополнительные дата-центры:
  • Индия (Мумбаи)
  • Германия (Франкфурт)

Расположение в США двух дата-центров обосновано тем, что США — основной потребитель трафика подобного сервиса, в Индии — потому что следующим регионом по аудитории данного сервиса после США является Индрия, а в Лондоне, который является очень крупным хабом для датацентров Европы, — для обеспечения покрытия Европы, которая суммарно составляет также крупный регион потребления трафика.

Ссылка на карту (https://yandex.ru/maps/?um=constructor%3Aaea556dba6be4bcec4779f984ed8f4823e591b580d93639704395d6a6a3eb012&source=constructorLink)

Отсюда можно заключить, что наиболее целесообразно будет использовать следующие технологии:

• BGP Anycast
• Geo-based DNS

Выбор BGP Anycast обоснован тем, что пользователя будет направлять в оптимальный по расположению дата-центр в пределах региона (с точки зрения BGP), т.к. позволяет распределить нагрузку с помощью настройки anycast-сетей, которая позволит гранулярно "отправлять" пользователей в различные дата-центры. Использование Geo-based DNS целессобразно для разграничения пользователей по регионам с помощью настройки GeoIP-базы, что может использоваться для персонализации контента, например, региональной рекламы.

Также откажемся технологий:

• Latency-based DNS
• Использование CDN в качестве хаба для обеспечения более стабильного соединения

Как уже было сказано, задержка (Latency) для данного сервиса не важна, поэтому Latency-based DNS здесь не имеет смысл. Использование CDN в качестве хаба для обеспечения более стабильного соединения не нужен, т.к. нет необходимости в стабильном и качественном подключении для создания событий календаря.

Для обеспечение надёжности необходимо решить несколько вопросов:

• резервирование ДЦ в случае отказа всех в данном регионе (это возможно ввиду небольшого их числа).
• пропускная способность ДЦ в случае прилива аудитории (например, в случае отказа одного из ДЦ).

Резервирование в рамках одного региона будет осуществляться BGP Anycast, который будет перенаправлять трафик из одного ДЦ в другой в рамках одного региона (это актуально для США). В случае остальных регионов балансировка будет осуществляться с помощью Geo-based DNS, который будет перенаправлять трафик из одного региона в другой.

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

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

Входящий трафик будем балансировать с помощью протокола HSRP.

Один из способов добиться доступности сети, близкой к 100%, — использование протокола HSRP, который обеспечивает избыточность IP-сетей, предоставляя возможность немедленного прозрачного восстановления пользовательского трафика в случае отказа первого перехода в оконечных сетевых устройствах или каналах доступа.

Благодаря совместному использованию IP-адреса и MAC-адреса (уровень 2), два и более маршрутизаторов могут действовать как единый "виртуальный" маршрутизатор. Члены группы виртуальных маршрутизаторов непрерывно обмениваются сообщениями о состоянии. Это позволяет маршрутизаторам подменять другие маршрутизаторы при их запланированном или незапланированном отключении. Узлы продолжают переадресовать IP-пакеты на согласованный IP- и MAC-адрес, и аварийное переключение устройств, производящих маршрутизацию, происходит незаметно для пользователей и приложений.

Межсервисные запросы будут балансироваться с помощью Sticky Session. В качестве стратегии балансировки выберем алгоритм Round Robin в nginx из его Ingress-контроллера, т.к. предполагается, что будет использоваться неблокирующий ЯП для backend-сервисов.

Для улучшения производительности будет использоваться Session Cache, который будет кэшировать SSL-сессии.

Для уменьшения пересылаемого трафика будет осуществляться сжатие gzip.

Также используем оркестрацию сервисов через K8, что позволит:

• выполнять auto-scaling для полного использования ресурсов доступных машин.
• service discovery для оценки работоспособности сервиса.
• распределять экземпляры сервиса по узлам.

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

• Программным монитором доступности нод.
• Сигнализирует балансеру при падении/подъёме ноды.
• Умеет VRRP/CARP резервирование нод между собой для обеспечения отказоустойчивости самих балансировщиков.

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

Балансеров устанавливаем в 2 раза больше, чем нужно для пикового трафика, ставим их попарно.

Проверку работоспособности сервиса будем проводить с помощью livenessProbe в K8.

Т.к. уже используется L7 балансировщик nginx, то терминацию SSL также осуществляем с помощью nginx.

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

Наибольшую сложность для оценки представляют данные об участниках календарей и событий, поэтому проведём оценку по нижней границе, предположив, что пользователей в календаре не превышает 10, а количество событий в день составляет около 5 при числе участников, не превышающих 10, откуда за 5 лет получим 5 * 10 * 5 * 365 = 91250 шт. Для оценки размера таблицы Error необходимо знать количество уведомлений и напоминаний, которые будут возвращать ошибку. Для приблизительной оценки примем, что это 5% от общего числа, т.е. 2 * 173612 (пиковый RPS) * 0.05 = 17361.2 (примем 17632).

В следующей таблице приведены примерные данные о суммарном объёме данных в БД.

Для оценки нагрузки на чтения для таблиц User, Calendar и Event возьмём данные пикового RPS.

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

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

Для денормализации БД проведём следующие преобразования:

1. Уберём таблицу Timezone, чтобы не делать дорогостоящий JOIN, и будем хранить информацию о временной зоне в таблицах User и Calendar напрямую в виде строки name и timespampz time_zone.
2. Пользователей, приглашённых на событие, добавим в качестве массива members в таблицу Event.
3. Пользователей, приглашённых в календарь, и их уровни доступа добавим в качестве словаря members_with_access в таблицу Calendar.

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

Для хранения сессий пользователей будем использовать неряляционную СУБД Redis, т.к. она осуществяет хранение данных in-memory, имеет поддержку неблокирующей репликации master-slave и возможность организации кластера Redis cluster. Сессии наиболее рационально хранить в in-memory базе, т.к. данный тип данных довольно часто меняется и важно получать быстро данные о сессии пользоваталей, при этом в случае падения базы не произойдёт потери критически важной информации, как, например, данных пользователей. Использование SQL-решения здесь неэффективно, т.к. при одинаковом оборудовании разница в производительности будет примерно в 10 раз быстрее в сторону Redis.

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

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

• Таблицу User шардируем по ключу id.
• Таблицу Calendar шардируем по ключу id.
• Таблицу Event шардируем по ключу id.

Ключами шардирования для каждой из таблиц выступают id, чтобы обеспечить псевдоравномерное распределение нагрузки между шардами и избежать случая, когда несколько шардов перегружены в сравнении с остальными (например, случая, когда один шард нагружен на 70%, а другой — на 30%).

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

Индексирование проведём, исходя из критического функционала приложения.

• Индекс на email для быстрого поиска и проверки уникальности.

• Индекс на owner_id для поиска календарей, созданных пользователем.

• Индекс на start_date и end_date (комбинированный индекс) для быстрого поиска событий в определённый период времени.
• Индекс на calendar_id для поиска событий календаря.
• Индекс на owner_id для поиска событий, созданных пользователем.

Для резеврного копирования используем следующие подходы [17]:

• Еженедельное полное резервное копирование.
• Ежедневное непрерывное инкрементное резервное копирование.

Для обеспечения лучшей производительности будет использоваться язык программирования Go на стороне backend, поэтому используем следующие клиентские бибилотеки:

• Для PostgreSQL: pgx.
• Для Redis: go-redis.

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

Для решения этой проблемы было принято решение испльзовать в качестве ключа шардирования id для каждой из таблиц User, Calendar и Event, т.к. ввиду псевдослучайной генерации id между пользователями с разной активностью будет создано псевдоравномерное распределение нагрузки между шардами.

В календаре для двух типов данных (уведомление и напоминание) необходимо использовать Apach Kafka, т.к. каждый из них требует отправки в определённое время. Под уведомлением здесь следует понимать сообщение, оправленное на почту со временем события и опросом о готовности пользователя прийти на ней, а под напоминанием — такое же уведомление, но за небольшое время до начала встречи, например, 15 минут.

При использовании Kafka возникают сразу несколько проблем:

• Возможность "торможения" очереди из-за возможных ошибок при отправке.
• Определение событий, для которых нужно оправить напоминание.

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

Для решения второй проблемы существует несколько вариантов:

• Хранить все напоминания, которые создаются при создании события, а при редактировании также редактируются.
• Генерировать их динамически.

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

1. TypeScript — статически типизируемый язык программирования для frontend, который транслируется в JavaScript код. Основное преимущество данного языка в том, что при масштабировании проекта могут возникать ошибки, которые намного проще заметить на этапе компиляции. Также данный язык поддерживает новые функции ECMAScript и модульность, как и JavaScript.
2. React — один из самых распространённых framework для frontend-разработки, с помощью которого можно существенно ускорить разработку приложения и улучшить его производительность за счёт реактивности из коробки. Также благодаря своей популярности данный framework имеет огромную кодовую базу, довольно невысокий порог вхождения и хорошую масштабируемость дл поддержки крупных проектов, что делает его применение наиболее рационалным.
3. Go — компилируемый многопоточный язык программирования backend, который благодаря своей неблокирующей модели многопоточности очень хорошо подходит для разработки высоконагруженных проектов, что, учитывая довольно простой порог вхождения в него, делает данный язык программирования хорошим выбором для высоконагруженного сервиса.
4. PostgreSQL — реляционная СУБД с открытым исходным кодом, которая очень хорошо масштабируется и хорошо работает с нагрузкой в случае, когда запросов на чтение существенно больше, чем запросов на запись. Также обеспечивает надёжноси, т.к. обладает механизмами сохранения целостности данных, транзакционной безопасности и отказоустойчивости.
5. Redis — неряляционная in-memory СУБД, которая в случае данного приложения находится перед "настоящей" базой данных. Данная СУБД используется для хранения сессий пользователей, т.к. они относительно редко меняются и к ним часто обращается приложение и они не относятся к критически важным. Также, в отличие от Memcached имеет поддержку транзакций, очереди, поддерживает репликацию и кластеризацию.
6. nginx — используется в качестве L7 балансировщика нагрузки, т.к. очень хорошо изучен сообществом, имеет очень высокую производительности и гибкость настройки.
7. Apach Kafka — используется для создании очереди отправки уведомлений и напоминаний пользователям. В качестве основных критериев выбора данного решения: масштабируемость (позволяет распределять данные по нескольким серверам), скорость (разеляет потоки данных), надёжность (разделы распространяются и реплицируются на многих серверах).
8. Prometheus — сбор метрик с их последующим хранением.
9. Grafana — платформа для визуализации собранных данных.
10. Kubernetes — открытое программное обеспечение для оркестровки контейнеризированных приложений, автоматизации их развёртывания, масштабирования и координации в условиях кластера.

• Использование Graceful Shutdown для обеспечения безопасного релизов новых версий приложения (не должно запускаться никаких новых процессов и не должно приниматься никаких новых веб-запросов и закрытия всех открытых соединений с внешними сервисами и базами данных).
• Использование Graceful Degradation для обработки отказов определённых компонентов, чтобы при отказе одних микросервисов не происходил отказ всего приложения.
• Использование на стороне клиента offline-логики для более бесшовной работы в случае обрыва интернет соединения.
• Использование на стороне сервера для уменьшения посылаемых запросов на проблемный хост и использование curcuit breaker паттерна для предотвращения каскадного отказа сервисов.
• Использование кеширования данных на стороне сервиса в случае отказа БД с последующей их записью при восстановлении её работоспособности.
• Использование логирования, мониторинга и оповещений для своевременного реагирования на возможные ошибки со стороны сервисов.

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

Микросервисы:

• Авторизации (auth).
• Пользователей и календарей (users and calendars).
• Событий (event).
• Уведомлений (notification).
• Ошибок (error).

Микросервис auth пользователей отвечает, соответственно, за авторизацию пользователей, что выражается также в виде взаимодействия с БД Users Storage, в которой хранятся сессии пользователей.

Микросервис users and calendars объединяет в себе логику получения данных пользователя и логику обработки данных календаря. Решение объединить эти две функции в один микросервис обусловлено тем, чтобы не плодить искуссвенные микросервисы, т.к. никогда данные календаря не запрашиваются отдельно от данных пользователя и наоборот. Этот микросервис взаимодействует с БД, в которой хранятся данные о пользователях и их календарях.

Микросервис events вынесен отдельно от пользователей и календарей по причине того, что именно события в отличие от календарей ежеминутно посылают запрос в БД для нахождения тех событий, для которых нужно отправить напоминание. Также этот микросервис ответственен за оправку таких событий в брокер сообщений Apach Kafka. Следовательно, добавление этой логики, а также логики взаимодействия с событиями, привело бы к не нужным усложнениям и созданию монолита в случае объединения с микросервисом users and calendars. Этот микросервис взаимодействует с БД, в которой хранятся данные о событиях.

Микросервис notifications отвечает за отправку уведомлений (при создании/изменении) и напоминаний (за определённое время до) о предстоящих событиях. Он напрямую взаимодействует с микросервисом error, т.к. в некоторых случаях возможны ошибки отправки.

Как указано выше, при отправке уведомлений возможны некоторые ошибки, которые обрабатывает сервис error. В зависимости от кода ошибки он принимает решение о повторной попытке либо о удалении этого уведомления/напоминания. Все будущие уведомления/напоминания, для которых будет предпринята ещё одна попытка отправки, кладутся в соответствующую БД. Эта БД также, как и в случае БД с событиями, ежеминутно сканируется и передаёт извлечённые данные обратно в микросервис error. Далее микросервисом эти данные передаются снова в брокер сообщений Apach Kafka.

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

1. Случай возможного отказа ДЦ в одном из регионов.

Как было описано в п.3 про глобальную балансировку, такой сценарий должен обрабатываться механизмом Geo-based DNS, который перенаправляет пользователей из одного региона в другой.

2. Резервирование информации при отказе одного из ДЦ.

Описанный выше сценарий обработки отказа ДЦ в одном из регионов невозможен без резервирования информации, т.к. иначе может сложиться такая ситуация, что при хранении данных всех пользователей, например, из азиатского региона на сервере в Мумбаи (Индия) и отказе этого сервера, всех пользователей перенаправит, например, на европейский сервер во Франкфурте (Германия), но их данных там не окажется. Т.о., сложится ситуция, при которой пользователям не будут доступны их данные, а это сильно повлияет на репутацию продукты и, следовательно, доходы бизнеса.

Поэтому необходимо резервировать ДЦ попарно, учитывая фактор катастрофоустойчивости, т.е. что ДЦ должны находиться друг от друга на расстояни не менее 1000 км. Следовательно, в этом случае для ДЦ в Мумбаи (Индия) назначим резервным ДЦ во Франкфурте (Германия) и наоборот. Для ДЦ в Нью-Йорке (восточное побережье США) назначим резервным ДЦ в Лос-Анджелесе (западное побережье США) и наоборот.

Пересылка информации будет осущетвляться по внутренним 100 Гбит/с линиям, как на серверах Amazon, что возможно, учитывая общую тенденцию роста данных, т.к. данные не будут копироваться все сразу, а лишь те, которые изменились.

Для оценки производительности Go будем опираться на таблицу из методических указаний [19]

Учтём, что согласно бенчмарку [20] производительности C++ и Go ориентировочно равны (если брать одинаковый уровень написания приложения), однако по памяти Go затратнее, чем C++, поэтому примем ориентировочно, что для Go требуется на 20% больше памяти, чем для C++.

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

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

Допущения:

• Пусть cookies выдаётся пользователю каждый день в течение первого захода на сайт [18].

• Данные о нагрузке на сервис по RPS возьмём из пункта про расчёт нагрузки.

• Данные по нагрузке на сервис auth возьмём, как RPS для просмотра календарей, т.к. это всегда требует обращения в этот сервис.

• Нагрузку на сервисы, совмещающие несколько функций, например, как микросервис users and calendars, представим в виде суммы нагрузок.

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

• Данные о нагрузке на БД возьмём из пункта про логическую схему БД.

• Для компенсации возможной неточности расчёта между средней и лёгкой бизнес-логикой в плане RAM установим минимальное значение RAM в 8 GiB.

• Все данные дублируются и для учёта возможных неточностей умножим данные для диска, RAM и CPU минимум на 2.5.
• Минимальный объём диска установим в 4 GiB.
• Нагрузку на запись примем 25% от нагрузки на чтение, учитывая дополнительно пересылку данных для резервирования между ДЦ.

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

1. https://explodingtopics.com/blog/google-workspace-stats
2. https://zipdo.co/statistics/google-calendar/
3. https://marketsplash.com/google-workspace-statistics/
4. https://www.patronum.io/key-google-workspace-statistics-for-2023/
5. https://www.similarweb.com/website/calendar.google.com/#geography
6. https://emaillistvalidation.com/blog/demystifying-email-validation-understanding-the-maximum-length-of-email-addresses/#:~:text=Defining%20the%20Maximum%20Length&text=Domain%20Part%3A%20The%20domain%20part,email%20address%20is%20320%20characters.
7. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
8. https://www.geekslop.com/technology-articles/2016/here-are-the-recommended-maximum-data-length-limits-for-common-database-and-programming-fields#:~:text=35%20chars%20(US)%2C-,50%20(other),-Last%20name
9. https://www.postgresql.org/docs/8.2/datatype-datetime.html
10. https://stackoverflow.com/questions/24138581/what-is-the-maximum-allowed-expiration-time-for-a-google-notification-channel
11. https://hypestat.com/info/calendar.google.com
12. https://webstatsdomain.org/d/calendar.google.com
13. https://www.visualcapitalist.com/cp/top-data-center-markets/
14. https://support.google.com/calendar/answer/37161?hl=en&co=GENIE...&co=GENIE.Platform%3DDesktop#zippy=%2Cguest-limit-for-invitations
15. https://stackoverflow.com/questions/10229156/how-many-characters-can-utf-8-encode
16. https://support.google.com/a/answer/2905486?hl=en
17. https://backupsolution.ru/backup-types/
18. https://developer.chrome.com/blog/cookie-max-age-expires?hl=ru
19. https://github.com/init/highload/blob/main/highload_l11_hosting.md
20. https://www.techempower.com/benchmarks/#section=data-r22&test=json&hw=ph&l=zii9rz-cn3