0개의 memcache 서버

소수의 DB만으로도 부하를 감당하기에 충분한 단계입니다. 데이터는 이미 여러 DB로 샤드되어 있는 상태입니다. 이 단계의 문제는 high fanout과 multiple rounds of data fetching입니다.

조금의 memcache 서버

읽기 성능을 더 개선해야 하는 단계입니다. 서버 10대로 초당 100만 오퍼레이션을 처리합니다. 이 단계에서는 look-aside caching 문제가 발생합니다. 여러 웹서버가 병렬로 memcache set을 할 때 충돌이 일어나는 것입니다. 이를 해결하기 위해 memcache 프로토콜 확장인 lease를 사용합니다. cache miss가 발생하면 lease-id를 발급하고, 이 id를 가진 곳만 set을 할 수 있도록 합니다.

1개의 cluster 안에 많은 memcache 서버

읽기 성능을 더더욱 개선해야 하는 단계입니다. 서버 100대로 초당 1천만 오퍼레이션을 처리합니다. 아이템은 여러 memcache 서버에 consistent hashing으로 분산됩니다. 이 단계의 문제는 모든 웹서버와 모든 memcache 서버가 다대다 통신을 한다는 점입니다. 사용자 요청 하나에 대해 100여 개의 memcache 서버에서 데이터를 가져오게 되고, 그 과정에서 네트워크 스위치의 버퍼가 넘쳐 패킷이 손실됩니다. 해결책은 슬라이딩 윈도우로 동시 요청을 제한하는 것이었습니다.

여러 개의 cluster 안의 많은 memcache 서버

서버 1000대로 초당 1억 오퍼레이션을 처리하는 단계입니다. 캐시의 consistency를 유지해야 하고, 데이터의 over-replication도 관리해야 합니다. 캐시된 데이터는 DB가 업데이트되면 함께 제거되어야 합니다. 해결책은 mysql commit log를 tail하면서 캐시를 제거하는 프로그램(McSqueal)을 만들어 각 DB서버에서 돌게 한 것입니다.

지리적으로 분산된 여러 개의 cluster

서버 1000대로 초당 10억 오퍼레이션을 처리하는 단계입니다. Replica를 다른 지역에 구성합니다. 여기서 문제가 발생합니다. 웹서버에서 마스터 DB로 데이터를 쓰고, 마스터 DB에서 Replica DB로 replication이 완료되기 전에, 다른 웹서버에서 cache miss가 일어나면 Replica DB에서 잘못된 값으로 cache set이 되어 버리는 것입니다. 해결책은 Remote Markers입니다. 마스터 DB에 쓰기 전에 remote marker를 set하고, remote marker가 set되어 있는 동안에는 replica DB가 아닌 master DB에서 데이터를 읽도록 합니다.

링크