You are correct that the communication between lms and lms-worker happens via Redis as a Celery backend.
Strictly from edx-platform’s point of view (i.e. not considering Tutor), there’s no need for lms and lms-worker to run on the same server. They do need the same code and similar configuration settings, but edx.org has long run them as separate scaling groups. The lms servers render web requests to users and stick tasks onto Redis, and the lms-worker servers pick up those tasks and execute them.
You shouldn’t have to add a load balancer for lms-worker specifically–the workers will all connect to your Redis instance and take advantage of Redis’s queue-like facilities to distribute work between them.
I know much less about Tutor, but my understanding is that you’ll need to start using k8s to actually spread your load across multiple physical servers. I may be misinterpreting this, but it sounds like you might be considering an attempt to run a separate, non-k8s Tutor instance to host your lms-workers, and have it talk to your existing Tutor instance via a shared Redis. If you are not considering this please ignore the rest of this post.
If you are considering the above, I think it will be very painful. I guess it technically might work if you spin up a separate non-k8s Tutor instance with mostly just lms-worker instances and used config to point it to a shared Redis + shared MongoDB + shared file/object store (S3?) + shared MySQL + shared Elasticsearch (i.e. everything that persists data)… but I don’t know of anyone who runs it like that, and I imagine any such setup would be fragile and break in weird ways in practice because there’s going to be a bunch of non-obvious config that will need to be just right (e.g. encryption/signing keys).
So I think if you want to scale out up LMS workers, the practical path forward is either going to be scaling up your hardware to be a much bigger instance, or to start venturing in to Kubernetes.