책/가상 면접 사례로 배우는 대규모 시스템 설계 기초 정리 6

단일 메시지 브로커 설계하기 - (2) / 마이크로 서비스의 프로세스 간 통신 정리

단일 메시지 브로커 설계 메시지 순서 유지 메시지는 발생 순서에 맞게 서비스에 도착해야 함 중복 처리 되지 않아야 함 스케일 아웃(서비스 인스턴스 3개)가 동일한 메시지 채널을 구독 송신자가 주문 생성, 주문 수정, 주문 취소를 순서대로 게시 네트워크 지연, 가비지 컬렉션 등 여러가지 사유로 인해 → 순서대로 처리되지 않을 수 있음 샤드 채널(Sharded channel, partitioned Channel) 하나의 샤드 채널은 2개 이상의 샤드로 구성 송신자(sender)는 메시지 헤더에 임의의 문자열, 바이트 시퀀스를 사용한 샤드 키 명시 메시지 브로커는 이 샤드 키 → 특정 샤드, 파티션에 할당 Kafka와 Zookeeper의 관계 Kafka는 소비자 그룹(복수의 수신자 인스턴스를 하나로 묶어 동일..

단일 메세지 모델 설계 하기(kafka + STOMP + Cassandra)

현재 스케일 아웃이 용이한 채팅 서버 설계를 위해서 스터디를 진행중이다. 단일 메시지 모델 설계를 위해 어떤 DB를 쓰고, 어떤 스택을 사용할 지 고민한 흔적을 소개해보려고 한다. Reference Best database for a chat application? 채팅을 위한 Message Queue 선택과 DB 선택 Kafka, Redis, Web Socket, Stomp 를 활용한 채팅 서버 회고 [혼자왔니] 채팅 서버 구현을 통해 알아본 redis와 kafka의 차이점 Redis, RabbitMQ 차이점을 알아보자 [WebSocket] Spring Boot + STOMP + Redis Pub/Sub 이용한 채팅 서버 구현 Spring STOMP Spring Boot Web Chatting : 스프..

[가상면접 사례로 배우는 대규모 시스템 설계 기초] Chap3. 시스템 설계 공략법

본 글은 가상면접 사례로 배우는 대규모 시스템 설계 기초를 읽고 정리한 글입니다. 설계의 순수성(pu-rity)에 집착한 나머지 타협적 결정(tradeoff)을 도외시하고 과도한 엔지니어링(over-engineering)을 하고 있는 엔지니어들이 현업에 많다 → 엔지니어들은 과도한 엔지니어링의 결과로 시스템 전반의 비용이 올라감. 효과적 면접을 위한 4단계 접근법 구체적으로 어떤 기능을 만들어야 하나? 제품 사용자수는 얼마나 되나? 회사의 규모는 얼마나 빨리 커지리라 예상하나? 석 달, 여섯 달, 일년 뒤의 규모는 얼마가 되리라 예상하는가? 회사가 주로 사용하는 기술 스택(technology stack)은 무엇인가? 설계를 단순화하기 위해 활용할 수 있는 기존 서비스로는 어떤 것들이 있는가? 예제 지원자..

[가상면접 사례로 배우는 대규모 시스템 설계 기초] Chap2. 개략적인 규모 추정

본 글은 가상면접 사례로 배우는 대규모 시스템 설계 기초를 읽고 정리한 글입니다. 2의 제곱수 데이터 볼륨의 단위를 2의 제곱수로 표현하면 어떻게 되는가? 최소 단위는 1바이트이고, 8비트로 구성 ASCII 문자 하나가 차지하는 메모리 크기가 1바이트 2의 X 제곱 근사치 이름 축약형 10 1천 1킬로바이트 1KB 20 1백만 1메가바이트 1MB 30 10억 1기가바이트 1GB 40 1조 1테라바이트 1TB 50 1000조 1페타바이트 1PB 모든 프로그래머가 알아야 하는 응답지연 값 L1 캐시 참조 0.5ns 분기 예측 오류 5ns L2 캐시 참조 7ns 뮤텍스 락/언락 100ns 주 메모리 참조 100ns Zippy로 1KB 압축 10us 1 Gbps 네트워크로 2KB 전송 20us 메모리에서 1MB..

[가상면접 사례로 배우는 대규모 시스템 설계 기초] Chap12. 채팅 시스템

본 글은 가상면접 사례로 배우는 대규모 시스템 설계 기초를 읽고 정리한 글입니다. 페이스북 메신저와 유사한 채팅 앱을 설계해 볼 것이다. 응답지연이 낮은 일대일 채팅 기능 최대 100명까지 참여할 수 있는 그룹 채팅 기능 사용자의 접속상태 표시 기능 다양한 단말 지원. 하나의 계정으로 여러 단말에 동시 접속 지원 푸시 알림 5천만 DAU(Daily Acitve User)를 처리해야 함 2단계 개략적 설계안 제시 및 동의 구하기 클라이언트는 서로 직접 통신하지 않는다. 각 클라이언트는 채팅 서비스와 통신한다. 채팅 서비스는 아래 기능을 제공해야 함. 클라이언트로부터 메시지 수신 메시지 수신자(recipient) 결정 및 전달 수신자가 접속 상태가 아닌 경우, 접속할 때까지 해당 메시지 보관 채팅을 시작하려..

[가상면접 사례로 배우는 대규모 시스템 설계 기초] Chap01. 사용자 수에 따른 규모 확장성

https://hudi.blog/system-design-interview-alex-xu-1/ [가상면접 사례로 배우는 대규모 시스템 설계 기초] Chap01. 사용자 수에 따른 규모 확장성 이번장을 통해 사용자 수가 증가함에 따라 시스템의 규모를 확장해 나가는 과정을 개략적으로 공부해볼 것이다. 당장 각각의 내용을 깊게 이해하기는 어렵겠지만, 규모 확장과 안정적인 시스템 hudi.blog 본 글은 위 블로그의 포스팅된 글을 참조 및 재창조 한 글임을 알립니다. 단일서버 모든 컴포넌트가 단 한대에 서버에서 실행되는 간단한 시스템부터 설계 웹 서버가 클라이언트의 모든 요청 처리 과정 클라이언트는 DNS에 도메인 이름으로 IP를 질의함. 클라이언트는 DNS 조회 결과로 IP를 얻어온다. IP 주소는 웹 서버..