![[발표 회고록] "Cache 개인 발표"](https://cdn.hashnode.com/res/hashnode/image/upload/v1712815523078/c601ac99-6d35-426a-b642-4db66543301e.jpeg?w=1600&h=840&fit=crop&crop=entropy&auto=compress,format&format=webp)
1) 서론
이전 팀운영시 팀원 충원 및 어느정도 팀원들간에 업무 호흡 및 신뢰가 채워진 후부터는 격주로 테크세션을 운영 및 진행 하였습니다. 격주 금요일 바쁜 업무가 없는경우 발표 및 준비를 진행해 왔으며 늘 업무 및 테크세션 준비로인한 피로감을 줄이고자 현재 진행하는 업무 위주로 진행하였고 너무 빠르게 순번이 온다 싶으면 시청각 자료를 준비하여 (개발관련) 같이 youtube를 시청하고 시청소감을 서로 이야기하는 시간으로 대체하는등 업무 외에 개인 능력 향상을 위해 테크세션을 진행했었습니다.
[팀장일때 테크세션 히스토리]
저도 역시 세션 발표자로 발표 준비 및 발표진행했으며 발표한 내용중 (총 3번을 했었네요 ㅎㅎ) 하나를 기록에 남길까 합니다.
2) 발표내용 "Cache를 사용하여 캐시를 버는 기술"
웹서비스에 데이터 관리에 대하여
IT서비스는 기본적으로 고객에게 “많은” 데이터를 제공하기위해 데이터베이스나 파일시스템을 사용합니다. 우리가 제공하는 웹서비스에서 기본적으로 데이터를 보관하는 장소이며 이장소는 I/O 를 통해 작업이 이루어지는데 이 부분은 반드시 blocking 구조로 데이터를 송수신하게 됩니다.
먄약 데이터를 가져오는데 0.5초가 걸리는 데이터베이스 connection pool 100개인 API 서버에서 동시 접속자수에 1만이 모인다면?
⇒ API 속도 저하로 고객들은 않좋은 경험을 하게 됩니다. (pending)
이전 회사에서 예약 시스템을 운영 개발 했었던 경험이 있습니다. 구조는 예약가능 시간 설정에 대해 raw 데이터를 Insert 하는 구조로 되어있었습니다. 아와 관련 문제로 인해 DB에서 transaction lock 으로 인해 서비스가 중단된 사례가 많았습니다. (제가 생각한 부분으로 수정되진 못했지만) 구조가 만약 raw 데이터 insert 구조가 아닌 재고를 생성하여 그 재고를 캐싱하는 구조였다면(예약 진행시 그 캐싱데이터를 삭제하고 진행예약 실패시 다시 캐싱하고) 손 쉽게 문제를 해결했을수도 있었겠다라는 생각을 했습니다.
아래의 그림을 이해하시겠습니까? 비용적인 측면에서 어느것을 선택하시겠습니까?
식당에서 김밥 주문 vs 집에서 김밥 만들기 상상해 볼까요?
상상해 보셨나요? 어떠셨나요?
김밥 만들어지는 속도의 차이가 있습니다. 김밥 전문점에서는 모든재료를 미리 만들어 놓고 주문과 동시에 깁밥을 말아 드리는 반면 집에서는 만들때 모든재료 준비 후 김밥을 말기 때문이죠
식당 vs IT ??
점심시간 식당앞에서 식사를 기다리는 경험을 해보신 경우가 있으신가요?
→ 매장의 규모(식사 가능한 테이블수, 직원수, 주방장) / 모인 손님규모 / 고객이 식사하는 시간 ⇒ 기다리게 될지가 결정되게 됩니다.
IT 용어로 바꾸어 볼까요?
매장의 규모 (직원수): 서버 규모(Backend WAS Server)
주방장 : 데이터베이스 (레시피를 통한 고객이 원하는 데이터(음식) 제공) 또다른 관점으로 WAS Connection pool로도 생각할수 있습니다.
모인 손님 규모 : 사용자, 트래픽 (Request)
으로 생각 가능할수 있겠네요
고객이 식사하는 시간은??? 대화를 하면서 식사를 하다보면 늦어질수도 있고 개개인마다 식사 시간이 다르니 이점을 빼고 나면 “음식이 고객에게 나오는 속도” 생각할수 있을것 같습니다. 만약 음식을 주문과 동시에 재료 손질부터 시작한다면??? 해당 매장은 망할 확률이 58000%!! (음식 시켰는데 1시간 뒤에 나오는 음식점은 가고 싶지 않으니까요)
식당에서는 식사시간(점심시간) 이전에 미리미리 재료손질 / 육수 / 밥짓기 등 미리미리 준비해두어 주문시 미리 준비된 재료로 고객에게 제공하고 있습니다. (음식을 만드는 생산속도는 조금더 빨라지겠죠?)
식당 대부분 회전율을 높이기 위해 고객이 식사시간을 줄이는 방법을 많이 고려하게 될것입니다. 식당에서 할수 있는 일은 당연히 주문시 음식이 빠르게 나오는 것에 초점이 마춰질 것이라고 생각합니다.
⇒ 이부분이 오늘 우리가 이야기할 cache 목적과 매우 유사합니다.
또다른 생각을 해볼까요? 매장 or 주방장을 늘려볼까? (DataBase 의 규모 + connection pool + WAS scale out)
과연 음식을 미리 준비해 테이블 회전율을 높이는 것에 비해 비용적인 측면으로 생각하면 어떠할까요?
어떻게 “더 많은 고객에게” 서비스를 제공할수 있을까?
키워드는 “더 많은 고객에게”로 : 대용량 트래픽 과 밀접한 관계가 있다고 생각하면 이해하면 쉬울것 같습니다.
이부분을 해소하기 위해 캐시를 사용해야 합니다. 많은 Request로 Database에 직접 접근하기 전에 메모리에 임시로 저장된 데이터 셋을 제공하여 보다 빠르게 서비스를 제공한다라고 생각할수 있겠습니다.
어떻게 혹은 얼마만큼 데이터를 유지해야 할까요?
캐시에 데이터가 얼마만큼 유지할지도 매우 중요한 요소중 하나 입니다.
하나 예를 들어 볼까요
쇼파에 앉아 가족이 모여 매주 토요일 오후 로또 추첨하는 프로그램을 시청하고 있습니다. 물론 매주 회차가 변경되면서 제공되지만 우선 회차에 대해서는 신경쓰지 않도록 할게요
알고있는내용은 언제까지 기억해야 할까요?
다음주 토요일 이후 다시 로또프로그램을 시청하지 않았을 경우도 생각해 봅시다.
여기에서 가족은 request(사용자) 라 생각하면되고 TV 는 서버, 로또프로그램은 데이터가 되겠네요. 만약 첫주 시청후 다음주 시청하지 않고 확인했을때 만약 지난 프로그램에 기억이 남아 로또를 마추게 된다면 커다란 오류가 발생될 것입니다. (만약 그게 맞는다면 ….. ㅠㅠ)
그 동안 서버에서 메모리 캐시에 대해 이야기를 나누었습니다. 또한 클라이언트 캐시에 대해서도 한번 생각해볼까요?
위의 로또 프로그램을 쇼파에서 본후 일주일동안 (다음 당첨까지) 노트**(오프라인에서도 사용가능한 휴대폰앱)**에 적어두었다고 가정해볼게요. 다른사람이 물어보거나 할때를 비교해 봅시다. 한사람이 아니라 학교나 직장에서 많은 사람들이 물어본다 가정했을때
노트에 적어둔 내용을 전달
다시 인터넷을 검색해서 읽어온후 내용을 전달.
여기서 인터넷을 서버, 본인을 클라이언트로 가정해보겠습니다. 물어보는 사람은 요청(Request) 로 생각할게요 매번 인터넷(서버)에서 조회해오는 방식이랑 본내용을 노트에 적어둔 방식에서 비용적인 측면에서 또한 속도면에서 어느것이 좀더 효율적일까요?
결론
Cache란 자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다.
물론 데이터베이스 자체에서도 캐싱이 존재합니다. Query 자체를 데이터베이스 시스템 내에서 캐싱되기도 하며 JPA 통해 자주 사용되는 쿼리도 캐싱 되기도합니다.
아래와 같은 저장공간 계층 구조에서 확인할 수 있듯이, 캐시는 저장 공간이 작고 비용이 비싼 대신 빠른 성능을 제공한다.
물론 저희는 소프트웨어 엔지니어링 에서 나오는 여러 캐시영역(L1 캐시메모리, L2[공유형] 캐시메모리등, L3 , CPU) 이해하는 부분은 자세히 다루진 않을 겁니다. (저도 더 공부해야함 ㅎㅎ)
캐시에 사용목적은 간단합니다. 고객요청에 보다 빠르게 대응할수 있는 방법 즉 이번 세션에 목적이라 생각하시면 됩니다. 필요한 유지시간동안 데이터베이스에 접근을 막고 비용적인 측면에서 효율을 높이고 더 나아가 많은 사용자 많은 요청(Request) 대응하기 용이하도록 사용할 예정입니다.
디비 증설보다는 메모리가 훨씬 저렴하거든요 **
Cache는 아래와 같은 경우에 사용을 고려하면 좋을것 같습니다.
접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우(서버의 균일한 API 데이터)
반복적으로 동일한 결과를 돌려주는 경우 (자주 변경되는 데이터는 조금 캐싱과는 맞지 않을수도)
데이터 보존기관
기술적인 내용(간략히 적을게요 ㅎㅎ) : 앞으로 같이 공부해 나가 봅시다.
client cache : 브라우저 & 브라우저 저장소등 캐시로 사용이 가능합니다.
local / session storage
react query cache
redux
cookie
server side cache
local cache : 서버에서 생성하고 관리되는 캐시 (앞으로 기본적으로 사용할 캐시)
ehcache
caffeine cache
node-cache
2대 이상(scale out) 각 서버별로 캐시를 클러스터링 하기 위해 다른 기술이 반드시 필요
Eveuntual Consistency vs strong consistency : 비관계형 데이터베이스 즉 pub/sub 구조 처럼 non blocking 시스템 에서의 최신데이터 [가용성의 문제]/ cahcing 후 동기화[일관성 문제] 의 균형적인 구조에 대한 고민
-
- global cache(분산캐시) : cache 공유 가능한 캐시(클러스터링이 적용된 캐싱)
redis
hazelcast
독립적인 캐시 서버 구축(대용량 데이터의 경우)
3) 발표후 결론
아직 업무적으로 그리고 팀원 구성원은들은 대부분 주니어 개발자로서 발표에 대한 고민, 경험을 많이 해보지 못한 상태였습니다. 현재 업무적으로 저희 서비스가 매우 많은 트래픽을 발생시키는 서비스도 아니었고 업무하다 보면 고려할 사항에서 제외되는 케이스가 많았습니다. 아예 아무런 준비를 하지 않는것 보단 캐싱에 대한 인식과 필요성에 대해 인식하고자 하는 목표로 발표하였고 해당 발표 이후 저희 서비스에도 적용시키기 위한 노력과 준비를 할수 있는 상태가 되었다라고 저는 생각했습니다.
또한 개발자이기 전에 팀장이다 보니 front / backend 개발자 분들이 공통적으로 습득할수 있는 주제를 선정하는것도 쉽진 않았습니다. 되도록 모두가 이해하고 습득했을때 좋은 시너지 낼수 있는 주제로 선정했었습니다.
끝으로 테크세션을 운영하면서 개발자들의 피로도도 조금 늘긴 했지만 흩어져 있는 팀원들이 가끔씩 테크세션을 통해 배워오거나 들었던 내용들을 자신의 발전에 도움이 되었으면 좋겠다라는 생각을 하며 이글을 마칩니다.
[참고문헌]
캐시
캐시(Cache)와 캐싱(Caching) 정리 from 10분 테크톡
react query & cache 자료
[React Query] useQuery 동작원리(1)