우아한 레디스 요약 - boostcampwm-2021/WEB08-AgileStorming GitHub Wiki

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

작성자: 안주영

Redis 는 어떤 것이고 어떤 식으로 사용할 수 있는가?

  • In-memory Data Structure Store
    • Strings, set, sorted-set, hashes, list
    • Hyperloglog, bitmap, geospatial index
    • stream
  • Cache
    • 요청의 결과를 미리 저장했다가 다음에 같은 요청이 오면 그것을 반환
  • 왜 Collection이 중요한가?
    • 편의성
      • Sorted Set을 이용한 랭킹 구현
    • 난이도
      • 친구 리스트에 추가할 때 동시성 문제
      • Redis 자료구조는 Atomic해서 해당 Race Condition을 피할 수 있음.
        • 그래도 잘못짜면 발생함!
  • 사용처
    • Remote Data Store
    • 전역 변수를 쓰면 되지 않을까? Redis 자체로 아토믹 보장이 되고, 싱글스레드이다.
    • 인증 토큰 저장, 랭킹 보드로 사용, 유저 API limit, 잡 큐
  • Strings - key value
    • set get
    • key 설정 고민해보기
  • List
    • push pop
  • Set
    • SADD SMEMBERS SISMEMBER
  • Sorted Sets
    • ZADD <key> <score> <value> ZRANGE
    • score는 double 타입이기 때문에 값이 정확하지 않을 수 있다.
  • Hash
    • Hmset <key> <subkey1> <value1> <subkey2> <value2>
    • Hgetall <key>
    • Hget <key> <subkey>
    • Hmget <key> <subkey1> <subkey2>... <subkeyN>
  • Collection 주의 사항
    • 하나의 컬렉션에 너무 많은 아이템을 담으면 좋지 않음
      • 10000개 이하 수준으로 유지하는게 좋다.
    • Expire는 전체 Collection에 대해서만 걸림

Redis 운영

  • 메모리 관리를 잘하자.
    • Physical Memory 이상을 사용하면 문제가 발생
      • Swap이 있다면 쓰겠지만, 해당 메모리 page 접근시 마다 디스크를 읽어야 해서 늦어진다.
      • Swap이 없다면 죽을 수 있다.
    • Maxmemory를 설정하더라도 더 사용할 가능성이 크다.
      • 메모리 얼로케이터에 의존하기 때문에 Redis가 자신이 쓰고 있는 메모리를 정확히 알기가 어려움.
      • 근데 jemalloc보다 더 잘 짤 수는 없음.
      • 메모리 파편화
    • 메모리를 사용해서 swap을 쓰고 있다는 것을 모를 때가 많음.
    • RSS 값을 모니터링 해야함.
    • 적은 메모리를 사용하는 인스턴스 여러개가 더 안전함.
  • O(N) 관련 명령어는 주의하자.
    • 싱글 스레드
    • 동시에 여러 명령 처리할 수 없다
    • 단순 get set은 초당 10만 이상 가능
    • packet이 들어오면 processInputBuffer에서 패킷을 하나의 processCommand로 만듦. processCommand가 완성되면 실제로 실행.
    • KEYS FLUSHALL FLUSHDB Delete Collections Get All Collections : O(N)
    • KEYS는 scan 이라는 짧은 명령 여러 번으로 대체
  • Replication
    • Async Replication
      • Replication Lag이 발생할 수 있다.
      • Replicaof or slaveof 명령으로 설정 가능
      • DBMS로 보면 statement replication과 유사
    • 많은 대수의 redis 서버가 replica를 두고 있다면
      • 네트워크 이슈, 사람의 작업으로 동시에 replication이 재시도 되도록 하면 문제가 발생할 수 있음.
  • 설정 Tip
    • 기본적으로 Collection은 다음 자료구조를 씀
      • Hash → Hash Table 하나 더 사용
      • Sorted Set → Skiplist와 HashTable을 이용
      • Set → HashTable 사용
      • 해당 자료구조들을 메모리를 많이 사용함
    • Ziplist를 이용하자.
      • in-memoey 특성 상 적은 개수라면 선형 탐색도 빠르다.
      • List, hash, sorted set 등을 ziplist로 대체해서 처리를 하는 설정이 존재
        • hash-max-ziplist-entries, hash-max-ziplist-value
        • list-max-ziplist-size, list-max-ziplist-value
        • zset-max-ziplist-entries, zset-max-ziplist-value
    • Maxclient 설정 50000
    • RDB/AOF 설정 off
    • 특정 commands disable
      • keys

데이터 분산 방법

  • Application

    • Consistent Hashing
      • 서버가 한 대가 빠지거나 추가되어도 리밸런싱이 덜 일어나게
      • 해시값을 서버에 주어서 id가 해시값보다 작으면서 가장 가까운 곳에 배치
      • twemproxy를 사용하는 방법
    • sharding
      • 데이터를 어떻게 나눌 것인가?
      • 데이터를 어떻게 찾을 것인가?
      • 하나의 데이터를 모든 서버에서 찾아야 하면?
      • Range Sharding
        • 특정 range에 key가 속하면 거기에 할당
        • 이벤트 기간에 가입자가 몰렸다가 다 탈퇴하거나, 초창기 가입자가 더 활발히 활동하는 등의 경우가 있으면 서버 간 불균형
      • modular sharding
        • 서버를 추가할 때 한 대 씩이 아니라, 이전 modular 값의 두 배로 늘리면 됨
        • 서버를 너무 많이 늘려야 하는 순간이 온다.

  • Redis Cluster

    Untitled

⚠️ **GitHub.com Fallback** ⚠️