[Redis] ch.18 동시성 문제 이해하고 해결하기

https://github.com/HongHyeongJu/StudySpace/blob/main/database/Redis/Redis_%ED%95%99%EC%8A%B5%EB%85%B8%ED%8A%B8_05.md

유데미 Redis : 개발자를 위한 Redis 완벽 가이드

ch.18 - 동시성 문제 이해하고 해결하기

동시성 문제 다시보기

• 입찰 상황에서 $10로 변경하고 나면 key변경으로 인해서 $15 입찰 요청의 트랜잭션이 취소됨
• 이런 상황에 대한 솔루션
  • 유효헌 트랜잭션이 실패했을 경우 재시도 매커니즘을 구현할 수 있게 해주기
  • 블록 전체가 WATCH 오류로 인해 실패해도 다시 실행을 시도할 수 있음
    • 문제점
      • 이 접근법을 쉽게 확장할 수 없음. WATCH 명령어를 쓰면 Redis 서버가 느려짐
      • 이걸 재시도하면 정보를 받기 위한 추가적인 요청으로 인해 Redis 서버에 추가적인 부하를 가하게됨
• WATCH는 너무 많은 요청이 유입되면 트랜잭션이 너무 많이 실패하게됨

느슨한 스크립트를 이용하는 약간 더 우수한 동시성 처리 방법

• Redis 안에서 어떤 값을 업데이트하려는, 혹은 읽기 작업을 하고 쓰기 작업을 하려는 두 개의 프로세스가 있을 때 오직 한 프로세스만 어떤 시점에 어떤 값을 수정할 수 있도록 하기
• lock이라는 기법을 이용하면 됨
  • 프로세스 1이나 프로세스 2가 이 해시에 연계된 무언가를 업데이트하려고 하면
  • 먼저 Redis에서 아주 특수한 키를 설정하기(별도의 키, 키 이름은 상관 없음)
  • 같은 키 이름으로 무작위 단어를 저장하도록 함 + NX 옵션 붙여서!
    • 먼저 도착한 요청이 SET 명령어 전송 - > HASH에 작업 가능함 (우리가 구체적으로 막으려고 하는 건, 다른 프로세스가 읽기를 하고 이어서 쓰기 작업을 하는 것)
    • 두번째로 도착한 요청은 SET 명령에 실패함
    • 어떤 시점에서 프로세스 1이 모든 작업(읽기/쓰기)을 마무리 -> lock:item:a1에 저장된 키를 삭제
    • 프로세스 2가 SET 명령을 전송하고 성공하게 되고, 프로세스 2가 item:a1에 대한 배타적인 접근권을 갖게 됨!
• lock이라는 기법을 이용해서, 오직 한 프로세스만 어떤 시점에 어떤 주어진 키에 관련된 읽기와 쓰기 작업 또는 책임을 갖도록 할 수 있음

Redlock의 단순화 버전 예시

• Redlock은 운영 등급의 동시성 잠금 알고리즘
  • 실무에서 사용함
  • 구축할 필요 없고 대신 Redlock 알고리즘을 자동으로 구현해주는 유명한 라이브러리 사용하기
  • https://redis.io/docs/manual/patterns/distributed-locks/
    • Redisson (Java implementation).
    • https://github.com/redisson/redisson

Redlock의 단순화 버전 함수 구현

• 단순화 버전
  • 인수1: 키(잠그려는 대상)
  • 인수2: 콜백함수(잠금에 성공한 뒤에 실행할 모든 논리 구현하기. 항목 fetching -> 검증 수행 -> 데이터 작업)
    • 재시도 간격
    • 재시도 횟수
    • 해시로 토큰 만들기
    • 반복문으로 시도(현재 값이 설정되지 않은 경우에만 값을 설정)
    • SET 작업을 할 때마다 우리는 Redis가 무얼 리턴하는지 확인 -> 그걸 acquired라는 변수에 할당
    • acquired가 null인지 확인 : if(!acquired)라고 하면 일시정지하고 재시도( await pause()를 호출하고 retryDelayMS 동안 일시정지)

Redlock의 단순화 버전의 문제점 해결하기 [1] -> 자동으로 lock 만료 시키기

• 오류로 인해 lock을 풀지 않고 프로세스가 끝나버리면 다음 요청들은 시도횟수를 모두 소진하고 끝나버림
• PX 옵션을 쓰면 일정시간 지나고 만료됨
• 함수 안에 오류 처리를 넣어서 어떤 이유에서든콜백 함수를 호출할 때 뭔가 잘못되면 어떤 일이 있어도 결국 delete를 호출하기

lock에 관한 또 다른 문제 [2]

• 데이터 프로세싱 단계에 약간의 시간이 걸릴 수 있음 -> 자동으로 만료되는 키를 갖고 있기 때문에 만일 시간이 지체되면 키(lock)의 값을 삭제하게됨
• 하지만 예상대로 작업이 진행되지 않는 일종의 중간 지대가 있을 수도 있음
• 서버를 다루고 Redis와 통신할 때는 서버에서 Redis로 명령을 전송하고 그게 실제로 처리될 때까지 얼마나 오래 걸릴지에 대한 보장이 전혀 없다는 점을 염두해두어야함
• lock 값을 확인 안하고 삭제하는 문제
  • GET으로 lock의 값을 가져오고 확인해서 삭제하기(당연한거 아닌가 머야...)

우발적인 lock 해제 문제 해결하기 : lock 해제 스크립트 추가하기

• Lua 문제를 해결하기 위해 아주 간단한 루아 스크립트 사용하기

  루아 스크립트

• Redis에서 루아 스크립트를 실행할 때 Redis는 다른 어떠한 명령도 처리하지 않게됨
• 스크립트는 다른 건 아무것도 하지 않고 처음부터 끝까지 실행됨
• 앞의 문제 해결방법
  • 데이터 처리를 모두 마쳤고 lock을 해제할 준비가 되었다면, 곧바로 delete를 호출하지 않고 대신 스크립트를 활용
  • 배후에서 Node redis를 통해 스크립트를 실행
    • EVALSHA를 직접 실행하지 않고 Node redis가 실행(EVALSHA, 스크립트 ID 그리고 우리가 제공할 1개의 키인 lock:item:a1, 그리고 토큰을 인수로 넣어주기)
      • lock:item:a1이라는 KEYS[1]을 전송하고, 'hi'라는 ARGV[1]을 전송
      • GET('lock:item:a1')이 'hi'라는 문자열과 같은지 확인하고
      • 만일 그렇다면 DEL('lock:item:a1') 실행
    • 실제로 하는 역할 : 이 토큰만을 삭제하도록함
    • 만일 자동 lock 만료가 이미 개입했고 이미 그 값을 삭제했다면 루아 스크립트는 아무것도 삭제하지 않을 것임
      • 타이밍 문제로 인해 이걸 우발적으로 해제하지 않게됨

마지막으로 남은 문제

• 콜백 함수를 호출하면 그 시점 이후에는 아무런 통제력이 없음
• 콜백에 넣은 코드는 다른 규칙에 따라 움직이게 됨, 데이터를 읽거나 쓸지의 여부를 우리가 결정하지 못함
• 데이터 처리 시간은 아무렇게나 길어질 수도 있고 짧아질 수도 있음 => 통제력 없음
• 데이터 처리가 오래 걸리고 lock이 만료되면 다른 프로세스가 그 lock을 획득할 수 있습니다
  • 그 프로세스는 항목 해시에 대하 완벽한 통제력을 갖고 있다고 생각하지만, 실제론 그렇지 않음
• 따라서 콜백 함수 안에는 이론적으로, 여기에 lock에 남은 시간이 얼마나 되는지, lock이 아직 유효한지 묻는 것이 필요함

만료 신호 제공하기

• signal객체
  • "유감입니다만 lock이 만료되었습니다. 그러니 더 이상 데이터 쓰기를 시도하지 마십시오, 왜냐면 실제로 lock을 갖고 있다는 걸 보장할 수 없으니까요" ㅋㅋ
• 그러나 이것도 완전한 해결은 아님

만료에 대한 또 다른 해법 Redis

• 누군가 Redis 클라이언트에서 메서드를 사용하려고 시도하면 우리는 lock이 만료되었는지 확인하기
• lock을 갖고 있다면 오류를 낼 것, 만료되지 않았다면 우린 그 사람이 액세스하려는 어떤 메서드나 호출할 수 있게 허용
• 흠... 나중에 다시 한번 더 복습