ActiveSupport::Cache를 이용한 레일스 캐싱

 

왜 캐싱을 고려할까? 아마도 뒤가 구린 뭔가를 사용자에게 가리는 가장 쉽고 빠른 방법이기 때문. 뭔가 캥기는게 있는게지.

 

과거를 묻지 마세요. 레일스 2.1 이전의 캐싱은 주로 Controller에서 View를 캐싱하는 용도. 단위는 fragment, action, page!

 

버뜨 그게 중요한게 아니더라. action, page 캐시는 거의 쓸 일 없음. 동적으로 렌더링되는 view를 캐싱하려고 해봤자 머리만 아픔.

 

답은 모델(M) 레이어에서 원본 데이터 캐싱.

 

그래서 내가 왔잖아! ActiveSupport::Cache. 특정 범위(애플리케이션 or 머신 or 클러스터)에서 사용할 수 있는 키-값 저장소. 하부 구조를 감춘 레이어 방식. 그래도 대세는 역시 MemCacheStore!

 

디테일은 http://inocrazy.com/docs/10 여기 다 있음

 

키값 저장소

1. >> Rails.cache.read('key')
   => nil
   >> Rails.cache.write('key', 'value')
   => "value"
   >> Rails.cache.read('key')
   => "value"

 

캐싱의 어려움

상한 데이터를 서비스하지 말자. 식중독 걸린다. 그러기 위해서는 캐시 만료 전략이 필요하다. 잘 만들려면 캐시하는 코드의 2~3배 정도 소요될지도 모른다. 이유는 특정 액션이 미치는 캐시들의 종류를 모두 찾아야하므로. ㄷㄷㄷ

 

좀 쉽게 가자 1. 시한폭탄

1. >> Rails.cache.write('key', 'value', :expires_in => 5.seconds )
   => "value"

 

이 메시지는 5초후에 자동 폭파됩니다.

 

좀 쉽게 가자 2. 만료~ 난 그런거 몰라. 무시!

캐시 키 이름만 잘 지으면 가능하다.

 

1. >> Person.find(5).cache_key
2. => "people/5-20071224150000"

 

cache_key에 Person#updated_at에 담겨있다.

 

1. "#{self.class.name.tableize}/#{id}-#{updated_at.to_s(:number)}"

 

이 말의 의미는? Person#updated_at 필드가 바뀌면 캐시가 자동으로 업데이트 된다.

 

여 기서 좀 더 발전되면? 특정 사용자와 관계된 모든 캐시에 Person#updated_at 필드를 담자. 예를 들어 사용자의 친구들을 캐싱할 때 키는 "Person/5-20071224150000/friends"와 같은 식이다. 그리고 친구 관계가 업데이트되면 Person#updated_at 필드를 갱신해서 이 사람과 관련된 모든 캐시가 만료되도록 한다. 이 방법이 직접 연관된 캐시를 찾는 것보다 훨씬 쉬운 방법이다.

 

 

논란

무비판적인 수용을 경계하자. 은총알 같은 것은 절대 없다.

• Strategy: Drop Memcached, Add More MySQL Servers - partition until all data resides in memory and then you may not need an additional memcached layer.

 

루비 언어 자체 또는 Runtime에서 키-값 저장소를 지원하면 어떨까?

• Avi Bryant on MagLev and GemStone
• http://delicious.com/byblue/maglev