Do SQL Sharding or Cluster help speed up slow queries, or just concurency?
Sharding requires a bunch of changes to the infrastructure, connections, etc.  The product "Spider" makes most of that transparent.
Sharding may improve scaling and concurrency for simple queries.  But for table scans and JOINs, it is likely to make performance worse.
Partitioning is excellent for "deleting old data".  See my blog.  Otherwise, the DELETE competes with other queries, making the whole system suffer when you do the purging.  (For 3 years, I would PARTITION BY RANGE(TO_DAYS(...)) and hav 38 partitions.)  DROP PARTITION for the old month is essentially instantaneous, regardless of size.
Loading data can be a bottleneck.  Do you use LOAD DATA?  That is probably the best.  Second best would be batched INSERTs of 100-1000 rows per batch.
If you just need read scaling, then adding Slaves gives you unlimited read scaling.
If you need write scaling, a Galera-based cluster might help some, but Sharding is the only real solution.
A few Summary tables, as you allude to, is an excellent way to get performance from a Data Warehouse setup.  I blog on that, too.
"I can't afford to rewrite everything for now" -- Any shortcut will take just as long.  And then you will still have to "rewrite everything" to take the next step.
Manually splitting data onto different devices is not as good as RAID striping of all the drives into one large drive.
A RAID controller with Battery Backed Write Cache makes writes appear to be instantaneous, without losing data.
Normalization can be used to keep the tables smaller, hence cacheable.  Are you doing a reasonable amount of that, and using reasonably small ids (eg, SMALLINT UNSIGNED instead of BIGINT where appropriate)?
Slow queries -- There are too many variables to make a general statement.  Let's see some specifics.


I would be happy to discuss any of these further.  Since you have not said what you really need, I don't know what to focus on.