폴링 방식과 롱폴링 방식에 대해 알아보자.. 아래는 시퀀스 다이어그램으로 그렸다.. 숫자는 무시하고 보자 폴링 방식 클라이언트의 주기적 요청에 의해 클라이언트가 업데이트된다. 클라이언트에 대기시간이 존재한다. 특징 클라이언트가 주기적 요청을 하기 때문에.. 실시간성이 그리 높지 않다. 같은서버에 다른 요청도 보내야 할 경우 사용되는 방식 롱폴링 방식 서버가 커넥션을 가지고 있으면서 대기시간을 가진다. 이벤트가 발생되는 순간 클라이언트에 응답을 내려주고 클라이언트는 업데이트 되는 방식이다. 특징 서버측에서 이벤트가 발생하는 즉시 클라이언트에 응답을 내려보내기 때문에 실시간성이 높다. 커넥션을 서버에서 유지하고 있어야 하므로.. 서버의 부담이 높은 편이다. 이벤트가 발생되면 관련된 모든 클라이언트에 응답을 ..

데이터 센터 이전 포스팅의 GSLB 개념에서 잠깐 알 수 있다. 아래 그림에서.. 사용자는 두개의 데이터 센터가 장애 없는 상황이라면 가장 가까운 데이터 센터로 안내된다. (GSLB, 지리적 라우팅) 위와 같이 Data center를 두군데 구축 해놨을 때... 한군데에 심각한 장애가 발생 했을 경우 다른 한 군데로 매핑 될 것이다. 주의사항 위 그림에서 무상태 아키텍처를 위한 사용자 상태의 저장소는 하나의 공유 저장소를 바라보고 있어서 갑자기 다른 데이터 센터로 변경 매핑될 지라도 문제가 없을 것이다. DB DB의 경우는 서로 연결이 되어있지 않아 문제가 발생한다. 따라서 여러 데이터 센터에 걸친 데이터 다중화 방법을 검토 해봐야 한다. TEST 웹 서버의 TEST는 반드시 모든 데이터 센터에서 수행 ..

무상태(Stateless) 웹 계층 여러 클라이언트에 대응하는 서버는 단순하게 생각했을때, 로그인과 같은 클라이언트의 상태 정보를 서버가 가지고 있어야 할 것이라 생각된다. 이러한 구조를 가지게 되면.. N대의 서버를 가진 시스템은 사용자가 어떤 한 대의 서버에 종속적으로 연결 시켜 줘야한다. (다른 서버로 연결되면.. 상태정보가 없을 것이기 때문이다.) -> 로드 밸런서에 부담이 된다. (sticky sestion, 고정 세션 기능) 이러한 문제점을 해결하기 위한 아키텍처는 아래와 같다. 무상태 아키텍처로 인해 자동 규모 확장(Autoscaling)이 가능해 졌다. 서버 트래픽 양, 시스템 자원의 메트릭에 따라 서버를 자동으로 스케일 아웃/인 할 수 있다. (AWS) 보통 Redis와 같은 In mem..

위는 HTTP/1.0, HTTP/1.1, HTTP/2의 특징들을 간단하게 보여준다.. 그림 먼저 보고 들어가자.. HTTP/1에서 HTTP/1.1로 가면서.. TCP 연결에 대한 부담과 요청/응답 속도(RTT)를 많이 개선하게 되었다. persistent, pipelining 방법으로 커넥션을 유지하고 연속적으로 보낼 수 있게 된 것이다. 하지만 여전히 문제는 많았다.. persistent TCP 한번의 연결로 여러 요청/응답을 처리한다. (커넥션 재사용) pipelining 한번 요청하면 그 응답 대기하고를 반복하지 말고.. 여러번의 요청을 보내고 대기함 (latency 낮춤) (이론적으로는, 두 개의 HTTP 요청을 하나의 TCP 메시지 안에 채워서(be packed) 성능 향상 할 수 있다고 한다...

캐시 캐시는 값비싼 연산 결과 또는 자주 참조되는 데이터를 메모리 안에 두고, 뒤이은 요청이 보다 빨리 처리 될 수 있도록 하는 저장소이다. (DB 호출되는 양을 줄이면 어플리케이션의 성능이 좋아진다는 개념에서 출발) 장점 DB 부하 줄이기 캐시 규모를 독립적으로 조절 가능 DB 접근하는 횟수를 줄여서 성능 향상 주의사항 휘발성 메모리이므로 영속 보관 데이터는 DB에 꼭 저장해줘야 한다. 만료 정책 적절한 만료 정책을 세워야한다. 만료 기한이 너무 길다면.. DB와 차이가 많이 날 것이다. 만료 기한이 너무 짧다면.. DB를 읽는 횟수가 늘어난다. 일관성 DB와 캐시의 데이터가 동일 한지에 대한 문제이다. 단일 트랜잭션으로 처리 되지 않는다면.. 일관성이 깨진다. 장애 대응 캐시 서버를 여러 대로 분산 ..

데이터 베이스 다중화 많은 DBMS가 다중화를 지원한다. DB 서버 사이에 master - slave 관계를 설정하여.. 원본은 master에 사본은 slave에 저장하는 방식이다. write 연산은 master에 하고.. (데이터를 변경하는 명령어, insert / delete / update 등) slave는 read 연산만을 지원하며, master로 부터 사본을 전달 받는다. 대부분의 어플리케이션은 읽기 연산의 비중이 쓰기 연산 보다 훨씬 높다. 따라서 slave 수가 master보다 많을 것이다. 장점 읽기 연산이 분산 되어 병렬로 처리 되므로.. 성능이 좋아 진다. DB서버 일부가 자연재해로 파괴되어도 데이터가 보존된다. DB서버 일부에 장애가 발생하여도 서비스를 지속할 수 있다. master가..

DNS (Domain Name System) 사용자가 naver.com을 검색한다면.. 컴퓨터는 naver.com 질의를 어디로 요청해야 할지 모른다. 이때, DNS서버는 보통 라운드로빈 알고리즘으로 해당 서버의 IP주소를 반환 해준다. DNS서버는 도메인 네임과 매핑할 수 있는 IP주소 테이블을 가진다. GSLB (Global Server Load Balancing) DNS에서 발전된 개념이다. 네이버 서버는 전세계에 N개가 있다. 사용자의 위치에 따라 응답성이 높은 서버로 매핑을 시켜줄 필요가 있다. DNS서버는 서버 IP주소를 매핑 시켜줄때, 단순 라운드 로빈으로 매핑 시켜주지만, GSLB는 사용자의 IP주소를 보고 위치기반 으로 가장 응답성이 높고, 정상 운영중인 서버로 매핑 시켜줄 수 있다. G..

[가상 면접 사례로 배우는 대규모 시스템 설계 기초] 책을 정리하면서 자체적으로 좀 더 내용을 추가 하였습니다. 단일 서버 모든 컴포넌트가 단 한 대의 서버에서 실행되는 시스템 (웹 앱, 데이터 베이스, 캐시 등) 데이터 베이스 사용자가 늘면 서버 하나로는 충분하지 않아 여러 서버를 두어야 한다. 두가지 용도의 서버로 나누어 보자. 웹/모바일 트래픽 처리 용, 데이터 베이스 용 이렇게 웹 계층과 데이터 계층을 나누게 되면 독립적으로 확장해 나갈 수 있다. 수직적 규모 확장 vs 수평적 규모 확장 수직적 규모 확장 : 스케일 업, 서버에 고사양 자원(CPU, RAM)을 추가하여 그 서버 자체의 성능을 개선 성능을 무한대로 끌어 올릴 수는 없어 한계점이 명확하다. Single Point of Failure(..