어흥

장애 처리 우선 장애 감지와 장애 해소 전략을 살펴보자 장애 감지 분산 시스템에선 한 대 서버가 "서버 A 다운"이라고 말해도 서버 A를 장애처리 하지 않는다. 보통 2 대 이상의 서버가 같이 서버 A의 장애를 보고해야 처리한다. 노드간 멀티캐스팅 채널을 구축하는것이 서버 장애를 감지하는 가장 쉬운 방법이지만 서버가 많을때는 비효율적이다. 가십 프로토콜(Gossip Protocol) 같은 분산형 장애 감지를 채택하는 것이 나으며 동작원리는 다음과 같다 - 각 노드는 멤버십 목록을 유지. 멤버십 목록은 멤버ID와 그 박동 카운터 쌍의 목록 - 각 노드는 주기적으로 자신의 박동 카운터를 증가 - 각 노드는 무작위로 선정된 노드들에게 주기적으로 자기 박동 카운터 목록을 보냄 - 박동 카운터 목록을 받은 노드는..

키-값 저장소는 키-값 데이터베이스라고도 불리는 비 관계형 데이터베이스다. 그리고 저장소에 저장되는 값은 고유 식별자를 키로 가져야 한다. 대표적인 키-값 저장소로 아마존 다이나모, memcached, 레디스가 존재한다. 문제 이해 및 설계 범위 확정 읽기, 쓰기 그리고 메모리 사용량 사이에 어떤 균형을 갖고, 데이터와의 일관성과 가용성 사이에서 타협적 설계를 해야 한다 - 키-값 쌍의 크리는 10KB 이하 - 큰 데이터를 저장할 수 있다 - 높은 가용성을 제공. 시스템은 장애가 있더라도 빨리 응답해야 한다 - 높은 규모 확장성을 제공. 트래픽양에 따라 자동적으로 서버 증설/삭제가 이뤄져야 한다 - 데이터 일관성 수준은 조정이 가능해야 한다 - 응답 지연시간(latency)가 짧아야 한다 단일 서버 키-..

3단계: 상세 설계 개략적인 설계에서 알 수 없는 점 - 처리율 제한 규칙은 어떻게 만들어지고 어디에 저장되는가? - 처리가 제한된 요청들은 어떻게 처리되는가? 리프트(Lyft)는 처리율 제한에 오픈 소스를 사용한다. domain: messaging descriptions: - key: message_type Value: marketing rate_limit: unit: day requests_per_unit: 5 이런 규칙들은 보통 설정 파일(configuration file) 형태로 디스크에 저장된다 처리율 한도 초과 트래픽의 처리 어떤 요청이 한도 제한에 걸리면 API는 HTTP 429(Too many requests) 응답을 클라에게 보낸다. 시스템 과부하로 인해 처리 못한 경우, 한도 제한에 걸..

명심할 점: 정해진 결말이나 정답은 없다 1단계: 문제 이해 및 설계 범위 확정 - 깊이 생각하고 질문하여 요구사항과 가정들을 분명히 하라 - 올바른 질문, 적절한 가정 그리고 시스템 구축에 필요한 정보를 모아라. 가정을 한다면 종이나 화이트보드에 꼭 메모해둔다 올바른 질문 예시 1. 구체적으로 어떤 기능을 만들어야 하는가? 2. 제품 사용자 수는 얼마나 되는가? 3. 회사의 규모는 얼마나 빨리 커지는가? 3,6,12개월 뒤의 규모는 어느정도인가? 4. 회사가 주로 사용하는 기술 스택은 무엇인가? 설계를 단순화하기 위해 활용할 수 있는 기존 서비스로는 어떤 것이 있는가? 예제 뉴스 피드(news feed) 시스템을 설계하라는 요구를 받았다. 이때 다음과 같은 순서로 질문 할 수 있다 1. 모바일 앱 웹 ..