If you want to keep your budget down, I would recommend you look into EJBCA which is open-source and free to use, though a lot of the fancy enterprise functionality is in their pay version. They make the following claims about throughput:
Since EJBCA uses standard relational databases, suitable for large scale and high performance you can easily scale EJBCA to hundreds of millions issued certificates, and with some care even billions. Depending on the architecture and interfaces chosen you can reach very low latency (sub 100ms) and very high throughput (>100 certs/sec). [source]
Though independent testing has found that this drops off pretty quickly when you get above 1 million certs issued.
Addressing the second part of your question:
Is there any benefit to using a "real" CA to issue my server cert and generate my client certs for me?
It really depends what you are using the certs for. I know that a lot of Internet of Things (IoT) manufacturing processes use client certificates to allow the devices to authenticate to the corporate network during manufacturing to do things like first-time config, firmware download, and other things that you want to do securely. At the end of manufacturing, those certs are destroyed / never used again. In the case it's perfectly ok to use a private internal CA that is hidden from the outside internet.
If, on the other hand, the certs you issue during fab will remain on the device into production and need to be publicly verifiable, then that's a different story. [For example, if you make lightbulbs, and you need users' iPhones to be able to verify that they are talking to an authentic IPBulb, Inc lightbulb, or the bulbs need to be able to authenticate to a IPBulb, Inc server to periodically retrieve updates.] In this case you will need to have a public-facing CA that does all the key-update and revocation status checking stuff. This gets complicated fast and it may be worth your while to partner with a commercial CA just to avoid the hassle.
EDIT: Pulling in the comments bellow to make the Answer self-contained.
My reason for advocating to outsource your certificate issuance is mainly due to server load and response times when you have to deal with revocation and certificate updates. For most small-medium companies, it's cheaper to outsource this to a specialist than to hire top-notch datacenter engineers.
Revocation: The tricky part is that the server that's verifying the certs needs to be able to ask the CA "is this cert still valid?" and get a response back very quickly (like < 25 ms). This is called the Online Certificate Status Protocol (OCSP). As your infrastructure grows, a single OCSP server won't be able to handle the traffic, so you now you need live database replication, and load-ballancers, and good datacenter engineers to keep the response times low. This is beyond the scope of most small-medium companies, and cheaper to outsource.
For certificate update / re-issue: There's no problem with the client dowloading its new/re-issued cert before the old one expires, but you have to have servers that are actively managing this, that have certificate management ports open to the public internet (potential attack surface / hacking point). Also, for ~30k certificates all expiring in a short time-period of each other, the server load will be huge. Again, how good are your company's datacenter engineers?
