Обработка 350 тыс. Запросов в секунду и сохранение данных в Google Cloud Storage

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

Все, что ему нужно сделать, это принять данные JSON, проверить их в соответствии с простыми правилами и записать в Google Cloud Storage в виде файлов JSON. Доступно множество облачных сервисов и API Google, но мне сложно выбрать правильный стек и конвейер, потому что у меня не было большого опыта работы с ними, а также с высокой нагрузкой.

Я просматриваю пример https://cloud.google.com/pubsub/docs/pubsub-dataflow

Поток следующий:

PubSub > Dataflow > Cloud Storage

Он делает именно то, что мне нужно (кроме проверки даты), но похоже, что Dataflow ограничен Java и Python, и я бы предпочел использовать PHP.

Другой подходящий пример - https://medium.com/google-cloud/cloud-run-using-pubsub-triggers-2db74fc4ac6d.

Он использует Cloud Run с поддержкой PHP и PubSub для запуска рабочей нагрузки Cloud Run. Итак, это выглядит так:

PubSub > Cloud Run 

а работа с облачным хранилищем в Run выглядит довольно просто.

Я на правильном пути? Может ли у меня работать что-то подобное, или мне нужно что-то другое?


comment
Вы хотите создать 1 файл для каждого запроса или сгруппировать запрос в сообщениях (например, 1 файл в минуту)? Какая цель у ваших файлов? Что ты будешь с ними делать после?   -  person guillaume blaquiere    schedule 02.06.2020
comment
Лучшим вариантом будет группировка сообщений в интервалы фиксированного размера (как это происходит во втором примере). Файлы служат хранилищем необработанных данных для дальнейшего использования с BigQuery. Но пока это не существенно. Теперь он бессилен подобрать подходящие услуги. Должны ли мы прослушивать запросы с помощью App Engine или Cloud Run - или лучше публиковать напрямую в PubSub (и что будет дальше, GAE, GCR) ..   -  person Vlad    schedule 02.06.2020


Ответы (1)


Моя первая интуиция, когда я увидел 350 тыс. Запросов в секунду и PubSub, была такая:

Pubsub > Dataflow > BigTable

Мой вопрос подтверждает выбор BigTable, потому что вы можете запросить таблицу BigTable из BigQuery для более поздний анализ.

Конечно, это дорого, но у вас здесь очень масштабируемая система.

Альтернативный вариант, если ваш процесс соответствует квотам потоковой передачи BigQuery, - это потоковая передача непосредственно в BigQuery вместо BigTable < / а>.

Pubsub > Dataflow > BigQuery

Проблема с решением Cloud Run или App Engine заключается в том, что вам нужно будет запустить процесс извне (например, с помощью Cloud Scheduler), и в этом процессе вы выполните цикл для получения сообщения из подписки PubSub. Вы справитесь с несколькими трудностями

  • PubSub выполняет по крайней мере одну доставку, и двойные сообщения могут быть проблемой. Dataflow управляет этим автоматически
  • Ограничение памяти App Engine и Cloud Run может быть проблемой, особенно если ваш язык неэффективен с точки зрения памяти.
  • Скорость вытягивания может быть проблемой, а параллелизм может быть проблемой.
  • Продолжительность извлечения ограничена несколькими минутами (из-за максимальной продолжительности запроса в Cloud Run и App Engine), и вам нужно аккуратно выйти и дождаться следующего триггера Cloud Scheduler, чтобы снова запустить извлечение PubSub.

ИЗМЕНИТЬ

Я забыл, что вы не хотите писать код на Java или Python. Я могу предложить вам 2 альтернативы, если ваш процесс действительно прост:

Личное мнение: язык программирования не имеет значения, используйте правильный инструмент для правильной работы. Использование Cloud Run или App Engine для этого создаст гораздо более нестабильную и сложную в обслуживании систему, чем обучение написанию 10 строк кода Java

person guillaume blaquiere    schedule 02.06.2020
comment
Я отредактировал свой ответ с помощью решения с низким кодом 2 Dataflow. И мое мнение о том, чтобы делать нестандартные вещи, опять же, мое мнение, по плохой причине (язык) - person guillaume blaquiere; 02.06.2020