웹 서비스 캐시 전략

웹 서비스 캐시 전략

1. 일반적으로는 스케일업이 더 쉽고 스케일 아웃이 비용이 적게 든다.

2. 캐시를 선택해야 하는 이유

   - 돈이 부족한데 성능을 더 높여야 할때, 돈은 있지만 성능을 더 높여야 할때..

3. use case : login

   - ( select * from users where id = 'bkjeon' )

     유저수가 적으면.. -> 충분히 빠르다.

     그러나 유저 수가 엄청 많으면.. -> DB도 인덱스 걸면 충분히 빠르다.(단, 읽기만 한다면 또한 디스크 읽는 수 가 적을때만)

     그래도 느리면 캐시를 적용하자.

 

4. use case : log

   - 쓰기용 캐시 적용

   - Log하나당 DB삽입( insert into clicklogs values(a,b,c); )

   - 모아서 쓰기..1024개 단위( Insert into clicklogs values(a1,b1,c1),(a2,b2,c2),(a3,b3,c3) )

   - 모아 쓰기를 위한 버퍼로 캐시 사용( 결과 : 10만건 기준 16~17 -> 1.4~1.5로 향상 )

 

5. 페이스북의 캐시 예시

   - login을 위한 유저정보, 첫 화면에 보여줄 피드 몇백개, 친구관계 등.. -> 이슈는 scale

   - 유저 로그인 관련 정보는 많아도 대부분 메모리에 올라감

   - 1k * 10,000,000 = 10G 그런데 1억명이면 한 서버당 100G? -> 이 또한 돈이 있으면 가능

   - 그럼 10억명이면? 1TB? -> 데이터의 분배가 필요함

     # 한대면 -> LRU등으로 자주쓰는 녀석들만. 조금씩 사용

     # 여러대면 -> 1~백만 : 1번, 백만1~2백만 : 2번 -> Range가 너무 크면 서버별 사용 리소스가 크게 치아닐 수 있음 서버 추가시에 range 조절이 없으면 데이터 이동이 없다.

       user #1000005 <-> server        user #1, user #10, #user #1000000 ...

                                      <->  user #1000001, user #1000100, user #2000000....

                                             user #2000001, user #2000200, user #3000000.....

   - modulo : ID % 서버대수 = k -> 서버 대수에 따라서 데이터의 이동이 많아짐 가능하면 2배씩 증가하는게 유리

     # user #1 <-> server <-> user #1, user #4, user #7...

                                   user #2, user #5, user #8...

                                   user #3, user #6, user #9...

   - Indexed : 해당 데이터가 어디 존재하는지 Index 서버가 따로 존재 -> Index의 변경으로 데이터 이동이 자유롭다(Index 서버에 대한 관리가 추가로 필요)

     # Index server(user 5000 is in 3), user #5000 <-> server <-> user #3, user #6, user#5000...

   - 서버의 목록은 zookeeper 등으로 관리하면 좋음​