0개의 memcache 서버

  • 소수의 DB로도 load를 감당하기에 충분함.
  • 데이터는 여러 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 hasing 으로 분산된다.
  • 문제:
    • 모든 웹서버와 모든 memcache 서버가 다대다 통신을 한다.
    • 1개의 사용자 요청에 대해 100여개의 memcache 서버에서 가져온다.
    • 네트워크 스위치의 버퍼가 넘쳐서 패킷이 손실됨.
    • 해결: 슬라이딩 윈도우로 동시 요청 제한

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

  • 1000대의 서버, 초당 1억 오퍼레이션
  • 캐시의 consistent 를 유지해야하고, 데이터 over-replication 도 관리해야함.
  • 캐시된 데이터는 DB가 업데이트 되면 캐시가 제거 되어야 함.
  • 해결:
    • mysql commit log 를 tail 하고, 캐시를 제거하는 프로그램을 만들어 각 DB서버에서 돌아가게 함. (McSqueal)

지리적으로 분산된 여러개의 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에서 데이터를 읽음.

링크