웹사이트 아키텍처의 확장성 설계

웹사이트 개발 초기에는 모든 코드를 하나의 프로젝트에 작성하는 데 익숙했습니다.

프런트엔드, 백엔드, 캐시, 데이터베이스, 정적 리소스...등등.

웹사이트 시스템의 물리적 분리

시스템은 점점 더 커질 것입니다. 당연히 많은 사용자의 높은 동시접속과 대용량 데이터 저장이 필요합니다.

하나의 서버에서 많은 사용자 요청을 완료할 수 없습니다.

캐시된 많은 데이터와 데이터베이스 데이터는 하나의 서버에서 완성할 수 없습니다.

이 시점에서는 웹사이트의 확장성 아키텍처가 특히 중요해집니다.

아래와 같습니다.

원칙

클러스터에 지속적으로 서버를 추가함으로써 증가하는 사용자 동시성을 완화할 수 있습니다. 액세스 압력과 증가하는 데이터 스토리지 요구.

아키텍처의 확장성을 측정하는 주요 기준:

클러스터에 새 서버를 추가하는 것이 얼마나 쉬운가.

새 서버를 추가해도 원래 서버와 동일한 서비스를 제공할 수 있나요?

클러스터에 수용할 수 있는 총 서버 수에 제한이 있나요?

응용 서버 클러스터

서버에 데이터가 저장되지 않는 한 모든 서버는 동일하며 로드 밸런싱 장치를 통해 서버를 클러스터에 추가할 수 있습니다.

관계형 데이터베이스 클러스터(MYSQL)

관계형 데이터베이스의 클러스터 확장성 솔루션은 데이터베이스 외부에 구현되어야 합니다. 여러 데이터가 배포된 서버는 라우팅 파티셔닝 등을 통해 클러스터로 구성됩니다. .

예: MySQL 등

비관계형 데이터베이스 클러스터(NOSQL)

비관계형 데이터베이스는 본질적으로 대용량 데이터베이스를 위해 준비되어 있어 확장성을 매우 잘 지원합니다.

예: Redis, Memcache 등

캐시 서버 클러스터

새 서버를 추가하면 캐시 라우팅이 무효화되어 클러스터에 캐시된 대부분의 데이터에 액세스할 수 없게 될 수 있습니다.

배포하기 전에 캐시된 데이터에 대한 접근성을 보장하기 위해 캐시 라우팅 알고리즘을 개선해야 합니다.

정적 리소스 서버 클러스터

CSS, JS, Img 등의 리소스를 서버 클러스터에 배포하여 트래픽을 줄이고 페이지 렌더링 속도를 높입니다.

웹사이트의 수직적 분리

비즈니스 처리 프로세스의 여러 부분을 분리하고 배포하여 시스템 확장성을 확보합니다.

아래와 같습니다.

웹사이트 수평 분리

시스템 확장성을 위해 다양한 비즈니스 모듈을 별도로 배포합니다.

아래와 같습니다.

단일 함수는 클러스터 크기에 따라 확장됩니다.

다양한 기능을 분리하여 배포하면 어느 정도 확장성은 달성할 수 있지만, 웹사이트 방문이 점차 증가함에 따라 최신 세분화로 분리된 단일 서버를 독립적으로 배포하더라도 비즈니스 규모의 요구 사항을 충족할 수 없습니다.

따라서 서버 클러스터를 사용해야 합니다. 즉, 동일한 서비스를 여러 서버에 배포하여 전체 외부 서비스에 대한 클러스터를 구성해야 합니다.

예: 검색 기능.

서버가 초당 1,000건의 요청 서비스를 제공할 수 있다면, 웹사이트가 피크 시간대에 있을 때 초당 검색 방문 횟수는 10,000건이 됩니다.

그런 다음 클러스터를 구성하려면 서버 10대를 배포해야 합니다.

마찬가지로 캐시 서버에서도 이런 상황이 발생합니다.

실제로 서비스의 클러스터 크기를 계산할 때 가용성, 성능 및 관련 서비스 클러스터에 미치는 영향을 고려해야 합니다.

요약

클러스터 확장성은 애플리케이션 서버 클러스터 확장성과 데이터 서버 클러스터 확장성으로 나눌 수 있습니다.

데이터 상태 관리가 다르기 때문에 두 클러스터의 기술적 구현도 매우 다릅니다.

누구나 구체적인 건축 디자인을 바탕으로 심층적인 연구를 진행할 수 있습니다.

이 기사는 "대규모 웹사이트의 기술 아키텍처"라는 책에서 빌려온 것입니다.