Is AES-GCM suitable for per chunk encryption? I was looking through Google's encryption flow and noticed that they split each file into chunks and then encrypt each chunk individually with AES-GCM with its own key.

Since AES-GCM starts to get vulnerable around $2^{48}$ messages (though, some people suggest $2^{36}$), how can they keep things secure if they have millions of users uploading files constantly? 

I'm new to cryptography, so excuse my ignorance. Does the $2^{48}$ limit only actually matter on a per user basis or is it in general? I wanted to do try something similar using AES-CBC with a SecureRandom IV and HMAC for per chunk encryption since you don't have to worry about the collision. However, seeing their encryption flow, I wanted to learn more about what is the proper way of going about things.
The limit is on a per-key:nonce basis. As long as the key or nonce are changed between messages before the limit, there will not be any problems. Different users are using different TLS sessions (which uses 96-bit nonces), which means different keys and nonces. From Wikipedia's page on GCM:


  GCM has been proven secure in the concrete security model. It is secure when it is used with a block cipher that is indistinguishable from a random permutation; however, security depends on choosing a unique initialization vector for every encryption performed with the same key (see stream cipher attack). For any given key and initialization vector combination, GCM is limited to encrypting 239−256 bits of plain text (64 GiB). NIST Special Publication 800-38D includes guidelines for initialization vector selection.


If TLS is not the protocol in use, then it depends on a few factors such as the size of the nonce (bigger is better) and whether or not it is random or sequential (sequential is better). In general, a competent cryptographer will not select insecure parameters. If you are trying to design your own encryption utility, you should be using an easy to use and foolproof library, such as libsodium.