Given the information you provide, it is really hard to give you a concrete answer here. The above assumption of 1736 req/sec is too rough in my opinion, since that traffic could be 10x higher in peak time. Therefore it would be very interesting to know the number of requests per second in that time.
Since you also use memcached as a cache in front of Riak, the next question would be how your cache hit ratio looks like - how many of your requests will be served from memcached, how many will hit your database?
Then also, it will depend a lot on the hardware used, if you're expecting high read/write load on riak, then SSDs would be a must.
Having some experience with riak under high load (significally higher than yours) I can tell you that not the number of requests matters that much (it is amazing how much riak can handle), but more the amount of data you have in riak and the size of the objects you store. The bigger your objects the slower Riak will be. If your objects are definately above 1MB, then please do not consider riak - it's not going to work out. When using Riak, it's definately better to have fewer but faster servers.
If you want to go for riak, I would definately suggest you to do some heavy load testing with jmeter or apache ab to see if riak can handle your traffic. (and even then - maybe slowly fade traffic to your riak installation)
that way you can be 100% sure, that nothing is going to burst in production.
Finally, please be aware, that no software is perfect. Switching to Riak is replacing one beast by another one. however, mySQL is a known beast already. there are many people out there who can help you if something goes wrong in your MySQL cluster. If something is wrong with your Riak cluster, you might find little help on the net - and commercial Riak support is very expensive.
