Давайте масштабировать только CPU-часть. Для этого вынесем ее в отдельный HTTP-сервис и сделаем столько реплик сервиса постпроцессинга, сколько нужно, чтобы CUDA-часть не простаивала (рис. 2 (а)). При таком подходе у нас не простаивает GPU и мы масштабируемся за счет относительно дешевых CPU (дешевых относительно видеокарт).
Можно посылать все полигоны (по условию их сотни) с картинки в сервис постпроцессинга. Но лучше разбивать полигоны на батчи и уже батчи асинхронно слать в сервис постпроцессинга (рис. 2 (б)). Такой подход позволит нам лучше утилизировать CPU-часть и лучше масштабироваться.
Это легко понять на простом примере: пусть к нам пришла только одна картинка и на ней 100 полигонов. Если мы пошлем все полигоны одним запросом, то будем ждать, пока один из зеленых сервисов их прожует. То есть мы вообще ничего не получили от масштабирования CPU-части. Но если мы разбили на пять батчей и каждый послали отдельным запросом, то над ними будут трудиться уже пять зеленых сервисов и мы ускоримся в пять раз.
Далее, когда докидывание CPU-сервисов перестает давать прирост к производительности, мы начнем докидывать еще и GPU-сервисы (рис. 2 (c)).
Можно заметить, что у нас появились накладные расходы на сеть, но будем считать, что они малы по сравнению с временем работы постпроцессинга.
Скорее всего, нагрузка на такой сервис не будет равномерной. Это значит, например, что в одно время суток нам нужно будет сто зеленых сервисов, а в другое время мы обошлись бы и десятью. Здесь, например, нас может выручить HPA. Он позволит нам автоматически разворачивать новые зеленые сервисы, например, тогда, когда утилизация CPU становится больше некоторого порога.
Еще можно сказать, что подход с HTTP-запросами и сервисами может быть заменен на подход с промежуточной очередью и воркерами. Он будет спасать нас, например, от резких всплесков нагрузки. Но в условиях несложной задачки будем считать этот пункт не очень важным 😉
Можно посылать все полигоны (по условию их сотни) с картинки в сервис постпроцессинга. Но лучше разбивать полигоны на батчи и уже батчи асинхронно слать в сервис постпроцессинга (рис. 2 (б)). Такой подход позволит нам лучше утилизировать CPU-часть и лучше масштабироваться.
Это легко понять на простом примере: пусть к нам пришла только одна картинка и на ней 100 полигонов. Если мы пошлем все полигоны одним запросом, то будем ждать, пока один из зеленых сервисов их прожует. То есть мы вообще ничего не получили от масштабирования CPU-части. Но если мы разбили на пять батчей и каждый послали отдельным запросом, то над ними будут трудиться уже пять зеленых сервисов и мы ускоримся в пять раз.
Далее, когда докидывание CPU-сервисов перестает давать прирост к производительности, мы начнем докидывать еще и GPU-сервисы (рис. 2 (c)).
Можно заметить, что у нас появились накладные расходы на сеть, но будем считать, что они малы по сравнению с временем работы постпроцессинга.
Скорее всего, нагрузка на такой сервис не будет равномерной. Это значит, например, что в одно время суток нам нужно будет сто зеленых сервисов, а в другое время мы обошлись бы и десятью. Здесь, например, нас может выручить HPA. Он позволит нам автоматически разворачивать новые зеленые сервисы, например, тогда, когда утилизация CPU становится больше некоторого порога.
Еще можно сказать, что подход с HTTP-запросами и сервисами может быть заменен на подход с промежуточной очередью и воркерами. Он будет спасать нас, например, от резких всплесков нагрузки. Но в условиях несложной задачки будем считать этот пункт не очень важным 😉