The logging for that many hits will definitely be having an effect, but how much effect depends on the size and amount of the actual requests - if the files being served are large than the logging will be making little difference overall and it is just the act of needing to read the files to serve them that is causing I/O contention. If the content requests tends to follow the usual pattern (many people requesting the latest few files with a relatively small number of requests for older content) then adding more RAM may help by letting the OS hold more of the content in cache. If the requests don't follow a useful pattern like that (i.e. the content requests over any given time period has no chance of fitting in a realistic amount of RAM) then this isn't going to help, of course.
If logging activity is significant in your I/O bottleneck, then moving the logs to another device will certainly help. That device could be another drive/array on the same machine or over the network. Unless you are half way saturating the servers NIC at any point in normal activity (which is unlikely - your external bandwidth will be the bottleneck there) then this will not need an extra NIC unless keeping the logging activity away from the interface the public web service is on makes it easier to secure (or otherwise fits in better with your network arrangement). An unsaturated network link is not going to see latency issues in, or due to, Apache logging activity though if there are times when the link is heavily used for long periods Apache processes may end up blocking for extra time (meaning more RAM being used in busy times) while waiting for log writes to complete.
If the reading of content is as much (or more) of a problem as the writing of logs, then you might consider using RAID0 for the content. You may need to beef up your backup arrangements to copy with the extra risk of a single drive death taking out the entire array. You could mitigate this with RAID10 but that will mean using four drives not 2. RAID5 may be an option too as for reads it will perform similarly to RAID0 and would only need one extra disk, but this is not recommended if the content changes often because RAID5s write performance issues [each block write becomes at least one extra read (the neighbour block(s) and an extra write (for the parity block)] will kick you. Also you are better not having your log files going to RAID5 for the same reason.
In summary: moving the logs to other drives (in the same machine or over the network) may help, as will moving the main content to RAID0, RAID10 or RAID5 (beef up your backup arrangements if using R0, be careful of write performance issues with R5). More RAM may also help by reducing the need for the actual I/O operations if most requests in a given time period are for a subset of your data that is of could-fit-in-RAM-with-a-chunk-to-spare size.