kingsubin kingsubin

1장. 타입스크립트 알아보기 아이템 1~5 아이템 1. 타입스크립트와 자바스크립트의 관계 이해하기 모든 JS 프로그램은 이미 TS 프로그램이다. 반대로, TS는 일반적으로 유효한 JS프로그램이 아니다. 코드의 의도가 무엇인지 타입 구문을 통해 타입스크립트에게 알려줄 수 있기 때문에 코드의 동작과 의도가 다른 부분을 찾을 수 있다. TS는 JS 런타임 동작을 모델링하는 타입 시스템을 가지고 있기에 런타임 오류를 발생시키는 코드를 찾아내려고 한다. 모든 오류를 찾아낼 순 없다. 타입 체커를 통과하면서도 런타임 오류를 발생시키는 코드는 존재할 수 있다. 아이템 2. 타입스크립트 설정 이해하기 cli 가 아닌 설정 파일(tsconfig.json)을 사용하자. 팀원과 공유하기 위함. 엄격한 체크를 하고 싶다면 s..

알림 시스템 설계 알림 시스템은 단순히 모바일 푸시 알림(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..

3장. HTTP 메시지 3.1 메시지의 흐름 HTTP 메시지는 HTTP 애플리케이션 간에 주고받은 데이터들의 블록들이다. 요청, 응답 관계없이 모든 메시지는 다운스트림으로 흐른다. 발송자는 수신자의 업스트림이다. 3.2 메시지의 각 부분 메시지는 시작줄, 헤더 블록, 본문 세 부분으로 이루어진다. 시작줄, 헤더는 줄 단위로 분리된 아스키 문자열이다. 줄바꿈 문자열은 ‘CRLF’라고 쓴다. 본문은 선택적인 데이터 덩어리이다. 시작줄이나 헤더와 달리 본문은 텍스트나 이진 데이터를 포함할 수도 있고 비어있을 수도 있다. 메시지 문법 // 요청 메시지 형식 // 응답 메시지 본문 헤더나 본문이 없더라도 HTTP 헤더의 집합은 항상 CRLF 로 끝나야 함을 주의하라. 규칙을 잘 지키지 않는 구현체와의 호환을 위해..

2장. URL과 리소스 키워드 정리 URL 문법 다양한 스킴 기본 사용자 이름과 브라우저별 패스워드 조각 파라미터 인코딩 체계 다룰 내용 URL 문법, URL 컴포넌트가 어떤 의미를 가지며 무엇을 수행하는지 여러 웹 클라이언트가 지원하는 상대 URL과 확장 URL 같은 단축 URL에 대해 URL의 인코딩과 문자 규칙 여러 인터넷 정보 시스템에 적용되는 공통 URL 스킴 기존 이름은 유지하면서 객체들을 다른 장소로 옮기는 것을 가능하게 해주는 URN을 포함한 URL의 미래 2.1 인터넷의 리소스 탐색하기 ex) http://www.joes-hardware.com/seasonal/index-fall.html http: URL의 scheme 스킴은 웹 클라이언트가 리소스에 어떻게 접근하는지 알려준다. 이 경우..

1장. HTTP 개관 1.1 HTTP: 인터넷의 멀티미디어 배달부 HTTP는 신뢰성 있는 데이터 전송 프로토콜을 사용하기 때문에, 데이터가 전송 중 손상되거나 꼬이지 않음을 보장한다. 1.2 웹 클라이언트와 서버 HTTP 클라이언트와 HTTP 서버는 월드 와이드 웹의 기본 요소다. 1.3 리소스 웹 서버는 웹 리소스를 관리하고 제공한다. 웹 리소스는 웹 컨텐츠의 원천이다. 가장 단순한 리소스는 파일 시스템의 정적 파일이다. (텍스트, HTML, 워드, 이미지, 동영상 그 외 모든 종류의 파일) 그러나 리소스는 반드시 정적 파일이어야 할 필요는 없다. 요약하자면, 어떤 종류의 콘텐츠 소스도 리소스가 될 수 있다. 미디어 타입 HTTP 는 웹에서 전송되는 객체 각각에 MIME(Multipurpose Inte..