해당 포스팅은 알렉스 쉬 작가님의 가상 면접 사례로 배우는 대규모 시스템 설계 기초 (P.13~17)를 읽고 정리한 글입니다. 콘텐츠 전송 네트워크 (CDN)CDN은 정적 콘텐츠를 전송하는 데 쓰이는, 지리적으로 분산된 서버의 네트워크이다. 이미지, 비디오, CSS, JavaScript 파일 등을 캐시 할 수 있다. 어떤 사용자가 웹 사이트를 방문하면, 그 사용자에게 가장 가까운 CDN 서버가 정적 콘텐츠를 전달하게 된다. 직관적으로, 사용자가 CDN 서버로부터 멀면 멀수록 웹사이트는 천천히 로드될 것이다. CDN이 어떻게 동작하는지 설명하면 다음과 같다. 사용자 A가 이미지 URL을 이용해 image.png에 접근한다.CDN 서버의 캐시에 해당 이미지가 없는 경우, 서버는 원본 서버에 요청하여 파일을 ..

해당 포스팅은 알렉스 쉬 작가님의 가상 면접 사례로 배우는 대규모 시스템 설계 기초 (P.11~13)를 읽고 정리한 글입니다. 캐시캐시는 값비싼 연산 결과 또는 자주 참조되는 데이터를 메모리 안에 두고, 뒤이은 요청이 보다 빨리 처리될 수 있도록 하는 저장소다. 웹 페이지를 새로고침 할 때마다 표시할 데이터를 가져오기 위해 한 번 이상의 DB 호출이 발생한다. 애플리케이션 성능은 DB를 얼마나 자주 호출하느냐에 크게 좌우되는데, 캐시는 그런 문제를 완화할 수 있다.캐시 계층캐시 계층을 사용하면성능 향상 : 데이터베이스보다 훨씬 빠르다.데이터베이스 부하를 줄일 수 있다.캐시 계층의 규모를 독립적으로 확장시킬 수 있다.위 그림과 같은 캐시 전략을 읽기 주도형 캐시 전략이라고 부른다. 이것 이외에도 다양한 캐..

해당 포스팅은 알렉스 쉬 작가님의 가상 면접 사례로 배우는 대규모 시스템 설계 기초 (P.5~10)를 읽고 정리한 글입니다. 수직적 규모 확장 vs 수평적 규모 확장스케일 업이라고도 하는 수직적 규모 확장 프로세스는 서버에 고사양 자원을 추가하는 행위를 말한다. 반면 '스케일 아웃'이라고 하는 수평적 규모 확장 프로세스는 더 많은 서버를 추가하여 성능을 개선하는 행위를 말한다. 서버로 유입되는 트래픽의 양이 적을 때는 수직적 확장이 좋은 선택이며, 이 방법의 가장 큰 장점은 단순함이다. 그러나 몇 가지 단점이 있다.수직적 규모 확장에는 한계가 있다.수직적 규모 확장법은 장애에 대한 자동복구 방안이나 다중화 방안을 제시하지 않는다. 즉, 서버에 장애가 발생하면 웹사이트/앱은 완전히 중단된다.이런 단점 때문..

해당 포스팅은 알렉스 쉬 작가님의 가상 면접 사례로 배우는 대규모 시스템 설계 기초 (P.4~5)를 읽고 정리한 글입니다. 데이터베이스사용자가 늘면 서버 하나로는 충분하지 않아서 여러 서버를 두어야 한다. 하나는 웹/모바일 트래픽 처리 용도(웹 계층)고, 다른 하나는 데이터베이스용(데이터계층)이다. 이렇게 분리하면 그 각각을 독립적으로 확장해 나갈 수 있다. 어떤 데이터베이스를 사용할 것인가?전통적인 관계형 데이터베이스와 비-관계형 데이터베이스 사이에서 고를 수 있다. 관계형 데이터베이스관계형 데이터베이스 관리 시스템(RDBMS)이라고도 부른다.MySQL, 오라클, PostgreSQL 등이 있다.관계형 데이터베이스 자료를 테이블과 열, 칼럼으로 표현한다.데이터를 관계에 따라 조인하여 합칠 수 있다.비관..

해당 포스팅은 알렉스 쉬 작가님의 가상 면접 사례로 배우는 대규모 시스템 설계 기초 (P.1~3)를 읽고 정리한 글입니다. 단일 서버단순하게 모든 컴포넌트가 단 한 대의 서버에서 실행되는 간단한 시스템부터 설계해 보자. 웹, 앱, 데이터베이스, 캐시 등이 전부 서버 한 대에서 실행된다. 시스템 구성을 이해하기 위해서는 사용자의 요청이 처리되는 과정과 요청을 만드는 단말에 대해서 이해할 필요가 있다. 먼저 사용자 요청 처리 흐름에 대해 살펴보자.사용자는 도메인명을 이용해서 웹사이트에 접속한다. 이 접속을 위해서는 도메인 이름을 도메인 이름 서비스에 질의하여 IP 주소로 변환하는 과정이 필요하다.DNS 조회로 IP 주소가 반환된다. 해당 IP 주소로 HTTP 요청이 전달된다.요청을 받은 웹 서버는 HTML..

해당 포스팅은 최범균 작가님의 도메인 주도 개발 시작하기 (P.344~352)를 읽고 정리한 글입니다. 단일 모델의 단점주문 내역 조회 기능을 구현하려면 여러 애그리거트에서 데이터를 가져와야 한다. 조회 화면 특성상 조회 속도가 빠를수록 좋은데 여러 애그리거트의 데이터가 필요하면 구현 방법을 고민해야 한다. 식별자를 이용해서 애그리거트를 참조하는 방식은 사용하면 즉시 로딩 방식과 같은 JPA의 쿼리 관련 최적화 기능을 사용할 수 없다. 이는 한 번의 SELECT 쿼리로 조회 화면에 필요한 데이터를 읽어올 수 없어 조회 선능에 문제가 생길 수 있다. 애그리거트 간 연관을 식별자가 아니라 직접 참조하는 방식으로 연결해도 고민거리가 생긴다. 조회 화면 특성에 따라 같은 연관도 즉시 로딩이나 지연 로딩으로 처..

해당 포스팅은 최범균 작가님의 도메인 주도 개발 시작하기 (P.338~341)를 읽고 정리한 글입니다. 이벤트 적용 시 추가 고려 사항EventEntry에 이벤트 소스 추가 여부앞서 구현한 EventEntry는 이벤트 발생 주체에 대한 정보를 갖지 않는다. 따라서 'Order가 발생시킨 이벤트만 조회하기'처럼 특정 주체가 발생시킨 이벤트만 조회하는 기능을 구현할 수 없다. 이 기능을 구현하려면 이벤트에 발생 주체 정보를 추가해야 한다. 포워더 전송 실패 허용 횟수포워더는 이벤트 전송에 실패하면 실패한 이벤트로부터 다시 읽어와 전송을 시도한다. 그런데 특정 이벤트에서 계속 전송에 실패하면 어떻게 될까? 이렇게 되면 그 이벤트 때문에 나머지 이벤트를 전송할 수 없게 된다. 따라서 포워더를 구현할 때는 실패..

해당 포스팅은 최범균 작가님의 도메인 주도 개발 시작하기 (P.323~337)를 읽고 정리한 글입니다. 비동기 이벤트 처리이벤트 저장소를 이용한 비동기 처리이벤트를 비동기로 처리하는 또 다른 방법은 이벤트를 일단 DB에 저장한 뒤에 별도의 프로그램을 이용해서 이벤트 핸들러에 전달하는 것이다. 이벤트가 발생하면 핸들러는 스토리지에 이벤트를 저장한다. 포워더는 주기적으로 이벤트 저장소에서 이벤트를 가져와 이벤트 핸들러를 실행한다. 포워더는 별도의 스레드를 이용하기 때문에 이벤트 발행과 처리가 비동기로 처리된다. 이 방식은 도메인의 상태와 이벤트 저장소로 동일한 DB를 사용한다. 즉, 도메인의 상태 변화와 이벤트 저장이 로컬 트랜잭션으로 처리된다. 이벤트가 물리적 저장소에 보관하기 때문에 핸들러가 이벤트 처리..