(우아한 테크 세미나 강의를 보고 정리함)

[우아한테크세미나] 191121 우아한레디스 by 강대명님

Redis 소개

• In-Memory Data Structure Store : 프로세스로 존재
• Open Source(BSD 3 License) : 공개하지 않고, 수정해서 쓸 수 있다
• Support data structures
  • Strings, set, sorted-set, hashes, list
  • Hyperloglog, bitmap, heospatial index
  • Stream
• only 1 Committer

Cache

• Cache를 왜 쓰나?

  • 나중에 요청올 결과를 미리 저장해두었다가 빠르게 서비스를 해주는 것을 의미

• Factorial

  • 다이나믹 프로그램 : 앞의 연산을 미리 저장해 놓고 다음 번에 똑같은 연산을 하지 말자
  • 캐쉬의 목적!

• 접근 속도가 다를 때

  • CPU Cache

  

  • 용량은 위로 갈 수록 커지고 속도는 아래로 갈수록 빨라짐
  • Redis는 Memory에 있음
  • 디스크 접근 속도가 메모리에 비하면 큰 차이가 남
  • 메모리에 올려놓고 쓰는 것이 디스크에서 읽어 오는 것보다 훨씬 빠르다
  • 용량은 디스크가 더 크다

• 어디서 많이 사용하나?

  • 추상적인 웹서비스 구조

    Client → webserver(API) → DB(DB 안에는 많은 ㄷ이터들이 있고, 이 때 주로 디스크에 내용이 저장)

    DB도 내부적으로 캐시가 있다. 메모리 사이즈보다 크면 디스크를 사용.

• 파레토 법칙

  • 우리 사회에서 일어나는 현상의 80%는 20%의 원인으로 인하여 발생한다

  • 전체 요청의 80%는 20%의 사용자

    → 적은 메모리이지만 효율적으로 캐싱으로 할 수 있는 이유!

• Cashe 구조

  • Look aside Cache

    

  • Write Back

    인메모리가 쓰기나 읽기가 빠름. 쓰기가 빈번한 것은 디스크에 저장을 해야 하는데, 일단 캐시에 먼저 저장해두었다가 특정 시점마다 db에 저장함

    예를 들어, insert query를 한 번씩 500번 날리는 것과, 500개 붙인 것을 한 번 날리는 것 중 어느 것이 더 빠를까? 후자가 훨씬 빠르다!

    단점 : 메모리에 저장 되어 있기 때문에, 리부팅 되면 데이터가 사라질 수 있다

    로그를 캐쉬에 넣어 놨다가 특정 주기에 한번에 db에 저장함

• 왜 Collection이 중요한가?

  • 개발의 편의성

    • 파이썬 생산성이 높은 이유 : 제공해주는 라이브러리가 많다 기본적인 자료구조
    • redis도 만들어 진 것을 가져다 쓸 수 있음
    • 랭킹 서버를 직접 구현한다면?

      • 가장 간단한 방법 : DB 유저의 score를 저장하고 score를 order by로 정렬 후 읽어오기

        → 개수가 많아지면 속도에 문제가 발생할 수 있음(결국 디스크를 사용하기 때문)

      • In-Memory 기준으로 랭킹 서버의 기준으로 랭킹 서버의 구현이 필요함

      • Redis의 Sorted Set을 이용!

        → Replication도 가능

  • 개발의 난이도

    • 친구 리스트를 관리 해보자(Race Condition)

      • 친구 리스트를 key / value 형태로 저장해야 한다면?

        • 현재 유저 123의 친구 key는 friends : 123, 현재 친구 A가 있는 중

          GOOD

          시간순서	T1(친구 B 추가)	T2(친구 C 추가)	최종상태
          1	friends:123 읽기		A
          2	친구 B 추가		A
          3	friends:123 쓰기		A, B
          4		friends:123 읽기	A, B
          5		친구 C 추가	A, B
          6		friends:123 쓰기	A, B, C

          HOW?

          시간순서	T1(친구 B 추가)	T2(친구 C 추가)	최종상태
          1	friends:123 읽기		A
          2		friends:123 읽기	A
          3	친구 B 추가		A
          4		친구 C 추가	A
          5	friends:123 쓰기		A, B
          6		friends:123 쓰기	A, C

          HOW?

          시간순서	T1(친구 B 추가)	T2(친구 C 추가)	최종상태
          1	friends:123 읽기		A
          2		friends:123 읽기	A
          3	친구 B 추가		A
          4		친구 C 추가	A
          5		friends:123 쓰기	A, C
          6	friends:123 쓰기		A, B

          Context Switching 때문에 T1, T2가 어떻게 일어날지 모름

    • Redis의 경우는 자료구조가 Atomic 하기 때문에, 해당 Race Condition을 피할 수 있다

      그래도 잘못 짜면 발생한다 예) 따닥 (고급용엌ㅋㅋㅋㅋ)

  • 외부의 Collection을 잘 이용하는 것으로, 여러가지 개발 시간을 단축시키고, 문제를 줄여줌

• Redis는 어디서 사용하는가?

  • Remote Data Store
    • A서버, B서버, C서버에서 데이터를 공유하고 싶을 때
  • 한대에서만 필요하면 전역 변수를 쓰면 되지 않을까?
    • Redis 자체가 Atomic을 보장해준다(싱글 스레드라...)
  • 주로 많이 쓰는 곳들
    • 인증 토큰(string 또는 hash)
    • Rangking 보드로 사용(Sorted Set)
    • 유저 API Limit
    • 잡 큐(list)?????