[사용자 수에 따른 규모 확장성] 캐시

캐시는 값비싼 연산 결과 또는 자주 참조되는 데이터를 메모리 안에 두고, 뒤이은 요청이 보다 빨리 처리될 수 있도록 하는 저장소입니다.

캐시 계층

캐시 계층(cache tier)은 데이터가 잠시 보관되는 곳으로 데이터베이스보다 훨씬 빠릅니다. 별도의 캐시 계층을 두면 성능이 개선될 뿐 아니라 데이터베이스의 부하를 줄일 수 있고, 캐시 계층의 규모를 독립적으로 확장시키는 것도 가능해집니다.

(캐시 서버를 두는 방법 중 하나)

• 요청을 받은 웹 서버는 캐시에 응답이 저장되어 있는지를 봅니다.
• 만일 저장되어 있다면 해당 데이터를 클라이언트에 반환합니다.
• 없는 경우에는 데이터베이스 질의를 통해 데이터를 찾아 캐시에 저장한 뒤 클라이언트에 반환합니다.
• 이러한 캐시 전략을 읽기 주도형 캐시 전략(read-through caching strategy)이라고 부릅니다.

캐시 서버를 이용하는 방법은 간단한데 대부분의 캐시 서버들이 일반적으로 널리 쓰이는 프로그래밍 언어로 API를 제공하기 때문입니다.

memcached API 사용 예

SECOND = 1
cache.set('myKey', 'hi there', 3600 * SECONDS)
cache.get('myKey')

캐시 사용 시 유의할 점

• 데이터 갱신은 자주 일어나지 않지만 참조는 빈번하게 일어난다면 캐시를 고려해볼 만합니다.
• 캐시는 데이터를 휘발성 메모리에 두므로, 영속적으로 보관할 데이터를 캐시에 두는 것은 바람직하지 않습니다. 예를 들어, 캐시 서버가 재시작되면 캐시 내의 모든 데이터는 사라집니다. 중요 데이터는 여전히 지속적 저장소(persistent data store)에 두어야 합니다.
• 캐시에 보관된 데이터 만료(expire)에 대한 정책을 마련해 두는 것이 좋은 습관입니다. 만료된 데이터는 캐시에서 삭제되어야 합니다. 만료 정책이 없으면 데이터는 캐시에 계속 남게 됩니다. 만료 기한은 너무 짧으면 곤란한데, 데이터베이스를 너무 자주 읽게 될 것이기 때문입니다. 너무 길어도 곤란한데, 원본과 차이가 날 가능성이 높아지기 때문입니다.
• 일관성(consistency)은 데이터 저장소의 원본과 캐시 내의 사본이 같은지 여부입니다. 저장소의 원본을 갱신하는 연산과 캐시를 갱신하는 연산이 단일 트랜잭션으로 처리되지 않는 경우 이 일관성은 깨질 수 있습니다. 여러 지역에 걸쳐 시스템을 확장해 나가는 경우 캐시와 저장소 사이의 일관성을 유지하는 것은 어려운 문제가 됩니다.
• 캐시 서버를 한 대만 두는 경우 해당 서버는 단일 장애 지점(Single Point of Failure, SPOF)이 되어버릴 가능성이 있습니다. 결과적으로, SPOF를 피하려면 여러 지역에 걸쳐 캐시 서버를 분산시켜야 합니다.
  • 단일 장애 지점: 어떤 특정 지점에서의 장애가 전체 시스템의 동작을 중단시켜버릴 수 있는 경우, 우리는 해당 지점을 단일 장애 지점이라고 부릅니다.

(캐시 서버를 한 대만 두는 경우)

• 캐시 메모리가 너무 작으면 액세스 패턴에 따라서는 데이터가 너무 자주 캐시에서 밀려나버려(eviction) 캐시의 성능이 떨어지게 됩니다. 이를 막을 한 가지 방법은 캐시 메모리를 과할당(overprivision)하는 것입니다. 이렇게 하면 캐시에 보관할 데이터가 갑자기 늘어났을 때 생길 문제도 방지할 수 있게 됩니다.
• 캐시가 꽉 차버리면 추가로 캐시에 데이터를 넣어야 할 경우 기존 데이터를 내보내야 합니다. 이것을 캐시 데이터 방출(eviction) 정책이라 하는데, 그 가운데 가장 널리 쓰이는 것은 LRU(Least Recently Used - 사용된 빈도가 가장 낮은 데이터를 내보내는 정책)나 FIFO(First In First Out - 가장 먼저 캐시에 들어온 데이터를 가장 먼저 내보내는 정책) 같은 것도 있으며, 경우에 맞게 적용 가능합니다.

참조

• 가상 면접 사례로 배우는 대규모 시스템 설계 기초