글 수 47
페이스북의 강용성(http://www.facebook.com/xympl)님은 “내가 서비스에 캐시 붙이는 걸 싫어하는 이유는 다음과 같다“를 통해서 캐시 구현에 있어서의 고려사항을 소개하고 있다.
1. 첫째 쿼리 튜닝과 DB 설계가 우선이라는 것이다. 이 기본적인 요소만 견고하게 구성해도 캐시 없이 빠른 서비스를 일정부분 구현 할 수 있다. 그래도 안 될 경우 역정규화를 이용해 구성을 통해 문제점을 해결하는 방법이다. 그래도 안될 경우 파티셔닝을 진행하며 캐시처리 이전에 최소한의 소프트웨어 튜닝이 선행되어야 한다.
2. 둘째 캐시처리를 남발하면 데이터 오류를 발생시킬 수 있다. memcache나 redis 같은 오픈소스를 이용할 경우 atomic operation을 지원하더라도 DB에 직접직접 바인딩(각종 값들이 확정되어 더 이상 변경할 수 없는 구속(bind) 상태가 되는 것)되어 있지 않고, 일일이 transaction을 만들어서 데이터를 맞춰줘야 하는데 이때 설정을 잘못할 경우, 잘못 캐시된 값으로 인해 데이터가 꼬일 수 있다.
3. 셋째 캐시를 투명한 레이어에 얹는 문제이다. 데이터 접근에 대한 추상화가 잘되어 있다면 모르겠지만, 그렇지 않은 경우 코드가 지저분해지는 것은 물론 코드의 복잡도를 향상 시킬 수 있다. ORM(Object Relational Mapping)을 사용하고 안하고의 문제가 아니라, 순수한 백엔드 개발자 역량에 달려 있는 문제라는 것이다. .
4. 넷째 캐시의 마법에 취하지 말아야 한다. 캐시는 만능이 아니다. 따라서 cache invalidate 혹은 expire 될 경우, workaround, fallback에 대한 고려를 잘 못 하게 된다. 그러다 캐시에 문제가 생기면 서버는 죽었다고 보면된다.
1. 첫째 쿼리 튜닝과 DB 설계가 우선이라는 것이다. 이 기본적인 요소만 견고하게 구성해도 캐시 없이 빠른 서비스를 일정부분 구현 할 수 있다. 그래도 안 될 경우 역정규화를 이용해 구성을 통해 문제점을 해결하는 방법이다. 그래도 안될 경우 파티셔닝을 진행하며 캐시처리 이전에 최소한의 소프트웨어 튜닝이 선행되어야 한다.
2. 둘째 캐시처리를 남발하면 데이터 오류를 발생시킬 수 있다. memcache나 redis 같은 오픈소스를 이용할 경우 atomic operation을 지원하더라도 DB에 직접직접 바인딩(각종 값들이 확정되어 더 이상 변경할 수 없는 구속(bind) 상태가 되는 것)되어 있지 않고, 일일이 transaction을 만들어서 데이터를 맞춰줘야 하는데 이때 설정을 잘못할 경우, 잘못 캐시된 값으로 인해 데이터가 꼬일 수 있다.
3. 셋째 캐시를 투명한 레이어에 얹는 문제이다. 데이터 접근에 대한 추상화가 잘되어 있다면 모르겠지만, 그렇지 않은 경우 코드가 지저분해지는 것은 물론 코드의 복잡도를 향상 시킬 수 있다. ORM(Object Relational Mapping)을 사용하고 안하고의 문제가 아니라, 순수한 백엔드 개발자 역량에 달려 있는 문제라는 것이다. .
4. 넷째 캐시의 마법에 취하지 말아야 한다. 캐시는 만능이 아니다. 따라서 cache invalidate 혹은 expire 될 경우, workaround, fallback에 대한 고려를 잘 못 하게 된다. 그러다 캐시에 문제가 생기면 서버는 죽었다고 보면된다.
I see
no changes, wake up in the
morning and I ask myself Things would never be the same.