kingsubin kingsubin

알림 시스템 설계 알림 시스템은 단순히 모바일 푸시 알림(mobile push notification)에 한정되지 않고 모바일 푸시 알림, SMS 메시지, 이메일 세 가지로 분류할 수 있다. 1. 요구사항 분석 어떤 종류의 알림 지원할 것인지? - 푸시 알림, SMS 메시지, 이메일 실시간 시스템(real-time) 시스템인가? - 연성 실시간(soft real-time) 어떤 종류의 단말 지원할 것인지? - iOS, Android, desktop 사용자에게 보낼 알림은 누가 만드는가? - 클라이언트 애플리케이션 프로그램 또는 서버 측에서의 스케쥴링 알림을 받지 않도록(opt-out) 설정 가능한가? - 가능해야 함. 하루에 몇 건의 알림이 필요한가? - 1,000만 건 모바일 푸시, 100만 건 SMS..

분산 시스템을 위한 유일 ID 생성기 설계 ‘auto_increment’ 속성이 설정된 RDB의 기본 키를 쓰면 되지 않을까? 라고 생각할 수 있다. 분산 환경에서 이 접근법은 통하지 않는다. DB 서버 한 대로는 그 요구를 감당할 수 없다. 여러 데이터베이스 서버를 쓰는 경우에는 지연 시간을 낮추기가 무척 힘들 것이다. 요구사항 책에서의 요구사항에 맞춰 구현해보자. ID는 유일해야 한다. ID는 숫자로만 구성되어야 한다. ID는 64비트로 표현될 수 있는 값이어야 한다. ID는 발급 날짜에 따라 정렬 가능해야 한다. 초당 10,000개의 ID를 만들 수 있어야 한다. 개략적인 설계안 다중 마스터 복제(multi-master replication) DB의 auto_increment 기능을 활용한다. 다만..

안정 해시 설계 수평적 규모 확장성을 달성하기 위해서는 요청 또는 데이터를 서버에 균등하게 나누는 것이 중요하다. 안정 해시는 이 목표를 달성하기 위해 보편적으로 사용하는 기술이다. 해시 키 재배치(rehash) 문제 N개의 캐시 서버가 있다고 할 때, 이 서버들에 부하를 균등하게 나누는 보편적 방법은 serverIndex = hash(key) % N이다. 이 방법은 server pool의 크기가 고정되어 있을 때, 데이터 분포가 균등할 때는 잘 동작한다. 하지만 서버가 추가되거나 기존 서버가 삭제되면 문제가 생긴다. server pool의 크기가 변하면 키에 대한 해시 값은 변하지 않지만 나머지 연산을 적용한 서버 인덱스 값은 변할 것이다. 그 결과 대부분의 키가 재 분배되며, 대규모 cache mis..

처리율 제한 장치의 설계 네트워크 시스템에서 처리율 제한 장치(rate limiter)는 클라이언트 또는 서비스가 보내는 트래픽의 처리율(rate)을 제어하기 위한 장치다. HTTP를 예시로 들자면 특정 기간 내에 전송되는 클라이언트의 요청 횟수를 제한한다. API 요청 횟수가 제한 장치에 정의된 임계치(threshold)를 넘어서면 추가로 도달한 모든 호출을 처리가 block 된다. 예시: 사용자는 초당 2회 이상 새 글을 올릴 수 없다. 같은 IP 주소로는 하루에 10개 이상의 계정 생성할 수 없다. 같은 디바이스로 주당 5회 이상 리워드(reward) 요청할 수 없다. API 처리율 제한 장치를 두면 좋은 점 DoS(Denial of Service) 공격에 의한 자원 고갈(resource starv..