Supposing that all data is in RAM, that's a huge and expensive machine.
Fortunately in most applications, you don't need to keep all your data in memory but only your live / active data.
Cassandra is able to retrieve automatically data from HD to RAM when the entry is missing from memory. Conversely, when the record in not accesses is expelled from memory ("cold" data). You might compare Cassandra as an application level cache, where entries are account rows. Cache hits/misses in this case can be interpreted as records on the cassandra filesystem disk which have to be brought back in memory.
So in terms of sizing:
- HDD is dimensioned for the total dataset
- RAM is dimensioned in order to reduce "cache misses"
- Replication factor affects throughput and resiliency
So talking about RAM: You only need to keep enough data in memory in order to avoid unnecessary re-fetch from disk. It's very application dependent. I would suggest to run some benchmarking to verify how many active sessions you get per day wrt to the total amount of sessions you have stored on the system. This applies well if your system is read dominated and reads exhibit temporal locality.
Check also this thread for further inspiration https://stackoverflow.com/questions/4924978/cache-design-question
This ratio of live data vs total data determines the RAM requirements for your system. Essentially, it's a tradeoff of cassandra misses vs RAM costs. Similar considerations - at a different level - apply to cpu cache design.