토스 서버기술 용어 정리

토스 서버 기술 영상을 보면서 정확히 알지 못하는 용어들에 대해서 정리한다

단어 또는 개념

Route53

간략한 순서

1. 사용자가 www.example.com  을 요청하면 ISP (인터넷 서비스 제공업체) 가 관리하는 DNS 해석기로 요청이 전달된다
2. DNS 해석기는 .com 도메인의 TLD (Top level domain) 서버 중 하나에 다시 전달한다
3. .com 도메인 서버는 example.com 과 연관된 4개의 Amazon Route 53 을 응답한다
4. ISP DNS 해석기는 route 53 중 하나를 선택해 www.example.com 에 대한 요청을 해당 서버로 전달한다
5. route 53 은 IP 주소를 응답하며, DNS 해석기는 TTL 만큼 캐싱을 해둔다

 

Memcached 보다 redis cluster 가 lock 구현이 안전한 이유?

memcahced 를 이용한 lock 을 ghetto lock 으로 칭하기도 한다

ghetto lock 이란 덜 세련되고 정교하지 않은 lock 을 칭한다

• 구현이 단순하다
• race condition 에 취약하다. 락 해제 실패 또는 크리티컬 세션 종료전 락 만료되면 2개 이상의 프로세스가 크리티컬 세션에 접근할 수도 있다

1개의 memcached 인스턴스를 활용한 분산락의 경우, 클러스터 운영에서 락을 소유한 memcached 가 죽으면 락이 정상적으로 동작할 수 없느 문제가 발생할 수 있다

redis 에서는 이런 문제를 맞기 위해 redis cluster 에서 redlock 이라는 알고리즘을 사용한다

 

Redis Redlock

redis cluster 에서 안전한 분산락을 걸기 위한 알고리즘이며 직접 구현해야 한다

효율성 보다는 정확성을 위해 분삭락을 사용할 때 적합하다 (효율성 목적이라면 1개의 redis 인스턴스에 lock 을 걸어서 사용하라)알고리즘

1. 5개의 서로 독립적인 redis 가 존재하는 상황에서 분산락을 건다고 가정하자
2. 클라이언트가 5개의 redis 에 락 요청을 보내며, value 로는 클라이언트 마다 unique 한 값을 사용한다. 그리고 현재 요청을 시작한 시간을 저장해둔다
3. 과반수 이상의 redis 에서 락을 거는게 성공했고, (요청응답시간 - 요청시작시간) 이 TTL 시간 보다 짧다면 락 거는 것을 성공한 것이다
4. 위의 케이스가 아니라면 락 획득에 실패한 것으로 판단해서 락 해체를 요청해야 한다

MIN_VALIDITY = TTL - (T2 - T1) - CLOCK_DRFIT 라는 식이 나오는데, 의역하면 다음과 같다. MIN_VALDITY 는 락이 유효한 최소한의 시간이며, (T2 - T1) 은 최악의 redis 네트워크 통신시간이다. 즉 MIN_VALIDITY 만큼은 lock 이 보장된다고 보면 될 것 같다.

 

Redis Redlock 이 문제가 되는 경우

문제가 되는 상황

1. 5개의 인스턴스 중 3개의 인스턴스에서 락이 획득됨
2. 락이 잡힌 3개의 인스턴스 중 1개가 비정상적으로 종료됨
3. 종료된 redis 인스턴스가 다시 올라옴
4. 현재 같은 키에 대해서 락을 다시 잡을 수 있는 상황이 됨. 왜냐하면 5개 중 2개의 인스턴스에 대해서만 락이 잡혀있는 상황이기 때문이다

문제가 되는 상황을 해결하기 위한 방법

1. fsync = always 설정을 통해 매번 명령을 디스크에 기록하고, 재시작할 때 해당 파일을 읽어서 복구할 수 있도록 함
   1. 위의 방법은 성능이 떨어진다는 문제점이 있음
2. 서버 재시작을 할 때 최대 TTL 이후에 서버를 재시작함
3. 깨끗한 종료일 경우 fsync = always 옵션이 아니더라도 AOF 설정을 해뒀다면 종료전 파일에 저장되므로 문제 없다

 

Memcached 를 이용해서 Redlock 알고리즘 구현이 안되는 이유

개인적인 생각으로 불가능해 보이진 않으나 redis 에 비해 관리가 힘든 측면이 있을 것 같다

1. 메모리에 내용을 disk 에 영속화 하는 기능이 존재하지 않아서 crash 에서 복구할 때 번거롭다
2. 애초에 redlock 이라는 이름의 유래가 redis 분산 락이라는 의미니까 의미상 안 맞지 않을까?

참고

https://aws.amazon.com/ko/route53/what-is-dns/

https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html

https://redis.io/docs/latest/develop/use/patterns/distributed-locks/