2023-08-03-TIL
2023-08-03-TIL
Today I Learned
Why Use Redis?
Redis는 데이터를 메모리에 두는 키-값 저장소다. 디스크를 거치지 않으니 읽기와 쓰기가 빠르고, 값으로 문자열뿐 아니라 해시, 리스트, 셋, 정렬된 셋 같은 자료구조를 그대로 쓸 수 있다. 그래서 DB 앞단의 캐시, 세션 저장소, 카운터와 요청 제한, 순위표처럼 빠른 응답이 필요하고 데이터 모양이 단순한 곳에 주로 쓰인다. 반대로 메모리 크기가 곧 저장 용량의 한계이고, 장애 시 데이터 유실을 어디까지 허용할지는 영속화 설정에 달려 있다는 점을 같이 고려해야 한다.
- https://www.linkedin.com/pulse/why-when-use-redis-hamed-moayeri/
Redis Sentinel
Redis를 마스터 하나와 레플리카 여러 대로 운영할 때, 마스터가 죽으면 누군가 레플리카를 마스터로 올리고 클라이언트에 새 주소를 알려야 한다. Redis 공식 문서는 Sentinel의 역할을 네 가지로 정리한다.
- 모니터링: 마스터와 레플리카가 정상 동작하는지 계속 확인한다.
- 알림: 문제가 생기면 API로 관리자나 다른 프로그램에 알린다.
- 자동 장애 조치(failover): 마스터가 응답하지 않으면 레플리카 하나를 마스터로 승격하고 나머지 레플리카가 새 마스터를 바라보게 바꾼다.
- 설정 제공자: 클라이언트는 Sentinel에게 현재 마스터 주소를 묻고, 장애 조치 후에는 새 주소를 받는다.
설정의 quorum은 마스터가 실패했다고 판단하는 데 동의해야 하는 Sentinel 수다. 문서는 quorum이 실패 감지에만 쓰이고, 실제 장애 조치는 Sentinel 프로세스 과반의 투표로 리더가 뽑혀야 진행된다고 설명한다. 같은 이유로 견고한 구성에는 Sentinel이 최소 3개 필요하다고 권한다.
- https://co-de.tistory.com/15
- https://ossian.tistory.com/39#:~:text=Redis%20Sentinel%EC%9D%80%20Redis%EA%B0%80,Port%EB%A7%8C%20%EC%82%AC%EC%9A%A9%ED%95%98%EB%A9%B4%20%EB%90%A9%EB%8B%88%EB%8B%A4.
Phantom Read
팬텀 리드는 한 트랜잭션 안에서 같은 범위 조건으로 두 번 조회했을 때, 그사이 다른 트랜잭션이 넣은 행이 두 번째 결과에 새로 나타나는 현상이다. 이미 읽은 행의 값이 바뀌는 non-repeatable read와 달리, 없던 행이 생긴다는 점이 다르다. 표준 격리 수준에서는 SERIALIZABLE에서만 막힌다고 정의된다.
MySQL InnoDB는 조금 다르게 동작한다. MySQL 문서는 READ COMMITTED에서는 갭 잠금이 꺼지기 때문에 다른 세션이 빈 구간에 행을 넣을 수 있어 팬텀 행 문제가 생길 수 있다고 설명한다. 기본값인 REPEATABLE READ에서는 잠금 읽기에 next-key 잠금을 걸어 범위 안의 삽입을 막는다.
- https://nesoy.github.io/articles/2019-05/Database-Transaction-isolation
Today I Studied
Alex Xu의 『System Design Interview』를 읽으면서 나온 개념을 정리했다.
- https://github.com/G33kzD3n/Catalogue/blob/master/System%20Design%20Interview%20An%20Insider%E2%80%99s%20Guide%20by%20Alex%20Xu%20(z-lib.org).pdf
Bloom Filter
블룸 필터는 어떤 원소가 집합에 있는지를 아주 적은 메모리로 확인하는 확률적 자료구조다. 위키백과에 따른 동작은 이렇다.
- m비트 배열을 0으로 초기화하고, 서로 다른 해시 함수 k개를 준비한다.
- 원소를 넣을 때 k개 해시 값이 가리키는 비트를 모두 1로 만든다.
- 조회할 때 k개 위치 중 하나라도 0이면 그 원소는 확실히 없다. 모두 1이면 있을 수도 있다.
즉 “없다”는 답은 항상 맞고 “있다”는 답은 틀릴 수 있다(false positive). 기본 형태에서는 비트를 다른 원소와 공유하므로 삭제도 할 수 없다. Redis 블로그는 이미 쓰인 사용자 이름 확인을 예로 든다. 필터가 없다고 답하면 DB를 조회하지 않아도 되므로, 대부분의 요청이 DB에 닿기 전에 걸러진다. 삭제가 필요하면 Cuckoo filter를 대안으로 소개한다.
- https://ko.wikipedia.org/wiki/%EB%B8%94%EB%A3%B8_%ED%95%84%ED%84%B0
- https://namu.wiki/w/%EB%B8%94%EB%A3%B8%20%ED%95%84%ED%84%B0
- https://velog.io/@chlvlftn22/%EB%B8%94%EB%A3%B8%ED%95%84%ED%84%B0
- https://meetup.nhncloud.com/posts/192
- https://redis.com/blog/bloom-filter/
Base64
Base64는 바이너리 데이터를 텍스트로만 다룰 수 있는 곳(메일 본문, JSON, URL 등)에 실어 보내기 위한 인코딩이다. RFC 4648에 따르면 입력을 24비트(3바이트)씩 묶고, 이를 6비트씩 4덩어리로 나눠 각각 64개 문자 중 하나로 바꾼다. 마지막 묶음이 3바이트가 안 되면 =로 패딩한다. 그래서 인코딩 결과는 원본보다 약 3분의 4배 커진다. 기본 알파벳의 +와 /는 URL에서 의미가 있는 문자라, 같은 RFC에 -와 _를 쓰는 URL·파일명 안전 변형(base64url)도 정의되어 있다.
- https://namu.wiki/w/BASE64
Base62
Base62는 숫자 10개와 영문 대문자 26개, 소문자 26개만 쓰는 인코딩이다. Base64에서 +와 /를 뺀 것이라 URL에 그대로 넣어도 이스케이프가 필요 없다. 그래서 URL 단축기처럼 숫자 ID를 짧은 문자열로 바꾸는 곳에 많이 쓰인다. ID를 62진수로 바꾸는 방식이라 같은 ID는 항상 같은 문자열이 되고 충돌이 없다. 다만 ID가 순차적이면 결과도 예측 가능하다는 점은 감안해야 한다.
- https://en.wikipedia.org/wiki/Base62
- https://medium.com/@anabhishek.jha/base-62-text-encoding-decoding-b43921c7a954
댓글
아직 댓글이 없습니다