목차
4. 분리/마스터-슬레이브 분리 아키텍처 읽기 및 쓰기
8. 컨테이너화 도입 - 컨테이너 오케스트레이션 아키텍처
1. 독립형 아키텍처
초기 단계에서는 유능한 기술팀을 활용하여 비즈니스 시스템을 시장에 신속하게 출시하여 테스트하고 변화하는 요구 사항에 신속하게 대응해야 합니다. 하지만 다행스럽게도 초기 단계의 사용자 방문 횟수는 매우 적었고 성능, 보안 등에 대한 높은 요구 사항도 없었으며 시스템 아키텍처가 간단하고 전문적인 운영 및 유지 관리 팀이 필요하지 않으므로 독립형 아키텍처를 선택하는 것이 적합합니다.
사용자는 브라우저에 www.baidu.com을 입력하고, 먼저 DNS 서비스를 통해 도메인 이름을 IP 주소 10.102.41.1로 확인한 후, 브라우저는 해당 IP에 해당하는 응용 서비스에 접속합니다.
장점: 간단한 배포, 저렴한 비용
단점: 심각한 성능 병목 현상이 있으며, 데이터베이스와 애플리케이션이 리소스를 놓고 서로 경쟁합니다.
2. 데이터 분리 아키텍처 적용
시스템이 온라인화되면서 예상대로 성공을 거두었습니다. 충성스러운 사용자 그룹이 시장에 등장하여 시스템 방문 횟수가 점차 증가하여 하드웨어 자원의 한계에 가까워지고 동시에 팀은 이 기간 동안 비즈니스 프로세스에 많은 경험을 축적했습니다. 현재의 성능 압박에 직면하여 시스템의 운반 능력을 향상시키기 위해 시스템 재구성 및 아키텍처 과제를 수행하기 위한 예방 조치를 취해야 합니다. 그러나 여전히 예산이 매우 부족하기 때문에 우리는 애플리케이션과 데이터를 분리하기로 결정했습니다. 그러면 최소한의 비용으로 시스템의 수용 능력을 높일 수 있습니다.
이전 아키텍처와의 가장 큰 차이점은 데이터베이스 서비스가 동일한 데이터센터 내 다른 서버에 독립적으로 배포되고, 애플리케이션 서비스가 네트워크를 통해 데이터에 접근한다는 점이다.
장점: 비용을 상대적으로 제어할 수 있고, 단일 머신에 비해 성능이 향상되며, 데이터베이스가 별도로 격리되어 있고, 애플리케이션으로 인해 데이터베이스가 손상되지 않으며, 특정 재해 복구 기능이 있습니다.
단점: 하드웨어 비용이 높아지고 성능에 병목 현상이 발생하며 대규모 동시성을 처리할 수 없습니다.
3. 애플리케이션 서비스 클러스터 아키텍처
우리 시스템은 사용자들의 환영을 받으며 대중화되었으며 단일 애플리케이션 서버로는 더 이상 수요를 충족할 수 없습니다. 우리의 독립형 애플리케이션 서버에서 처음으로 병목 현상이 발생했습니다. 기술팀에는 두 가지 옵션이 있었습니다. 모두가 솔루션의 장단점에 대해 열띤 토론을 벌였습니다.
• 수직 확장 / 수직 확장 Scale Up. 더 나은 성능과 더 높은 가격의 애플리케이션 서버를 구매하여 더 많은 트래픽을 처리하십시오. 이 솔루션의 장점은 시스템 소프트웨어를 조정할 필요가 없다는 것입니다. 그러나 단점도 분명합니다. 즉, 하드웨어 성능과 가격 상승 사이의 관계는 비선형적입니다. 즉, 성능이 2배인 하드웨어를 선택하면 비용이 많이 들 수 있습니다. 가격이 4배 이상 비싸다., 둘째, 하드웨어 성능 향상에는 명확한 상한선이 있다.
• 스케일 아웃/스케일 아웃. 소프트웨어 아키텍처를 조정하고, 애플리케이션 계층 하드웨어를 추가하고, 사용자 트래픽을 다양한 애플리케이션 계층 서버에 할당함으로써 시스템의 전송 용량을 향상시킬 수 있습니다. 이 솔루션의 장점은 비용이 상대적으로 낮고 개선의 상한선도 크다는 것입니다. 그러나 단점은 시스템이 더 복잡해지고 기술팀의 경험이 더 많이 필요하다는 것입니다. 팀의 연구, 연구 및 토론 끝에 우리는 이 문제를 해결하기 위해 마침내 수평 확장 솔루션을 선택했지만 이를 위해서는 새로운 구성 요소인 로드 밸런싱이 필요했습니다. 사용자 트래픽이 어느 애플리케이션 서버에 분산되는지에 대한 문제를 해결하기 위해 , 특수 시스템 구성 요소가 트래픽 분산을 수행합니다. 실제로 로드 밸런싱은 애플리케이션 계층뿐만 아니라 다른 네트워크 계층에서도 수행될 수 있습니다. 동시에 많은 종류의 트래픽 스케줄링 알고리즘이 있는데 다음은 몇 가지 일반적인 것입니다:
• 라운드 로빈 폴링 알고리즘. 즉, 요청이 매우 공정하게 여러 애플리케이션 서버에 분산됩니다.
• Weight-Round-Robin 라운드 로빈 알고리즘. 다양한 서버(예: 성능이 다른 서버)
와 더 많은 작업을 수행할 수 있는 서버에 서로 다른 가중치를 부여합니다.
• 일관된 해시 해싱 알고리즘. 사용자의 특성값(IP 주소 등)을 계산하여 해시값을 구하고, 그 결과를 바탕으로 배포하는데, 동일한 사용자의 요청이 항상 지정된 서버에 할당된다는 장점이 있습니다. 우리가 흔히 접하는 특별계좌관리 서비스가 그것이다.
장점: 응용 서비스의 고가용성: 응용 프로그램은 고가용성을 충족하며, 하나의 서비스에 문제가 있어도 전체 사이트가 중단되지 않습니다. 응용 서비스는 일정한 높은 성능을 갖습니다. 데이터베이스에 액세스하지 않으면 응용 프로그램 관련 처리를 지원할 수 있습니다. 대규모 요청에 대한 확장을 통한 신속한 대응, 애플리케이션 서비스는 확실한 확장성: 수평적 확장 지원
단점: 데이터베이스가 성능 병목 현상이 되어 데이터베이스의 대량 쿼리에 대처할 수 없음, 데이터베이스가 단일 지점이므로 고가용성이 없음, 운영 및 유지 관리 작업이 증가하고 이후 배포 및 운영 및 유지 관리 작업이 증가함 확장이 필요하며 빠른 배포에 대응하기 위해 해당 도구를 개발해야 하며 하드웨어 비용이 높습니다.
4. 분리/마스터-슬레이브 분리 아키텍처 읽기 및 쓰기
앞서 언급했듯이 로드 밸런싱을 통해 사용자 요청을 여러 애플리케이션 서버에 분산시킨 후 병렬로 처리할 수 있으며, 비즈니스가 성장함에 따라 서버 수를 동적으로 확장하여 부담을 줄일 수 있습니다. 그러나 현재 아키텍처에서는 서버가 아무리 확장되더라도 이러한 요청은 결국 데이터베이스에서 데이터를 읽고 쓰게 되며, 일정 수준 이후에는 데이터에 대한 압박이 시스템 수용 능력의 병목 현상이 됩니다. 애플리케이션 서버를 확장하는 것과 동일한 방식으로 데이터베이스 서버를 확장할 수 있습니까? 대답은 '아니요'입니다. 왜냐하면 데이터베이스 서비스에는 고유한 특성이 있기 때문입니다. 즉, 데이터가 다양한 서버에 배포되는 경우 데이터의 일관성이 보장될 수 없습니다. 여기에서 소위 데이터 일관성이란 동일한 시스템에 대해 언제, 어디서든 일관된 데이터를 확인해야 함을 의미합니다. 은행에서 관리하는 계좌 금액을 가정해 보면, 이체를 받은 후 한 데이터베이스의 데이터가 수정되고 다른 데이터베이스의 데이터는 수정되지 않으면 사용자가 받은 입금액이 잘못됩니다. 우리가 채택한 솔루션은 하나의 기본 데이터베이스를 쓰기 데이터베이스로 유지하고 다른 데이터베이스를 슬레이브 데이터베이스로 유지하는 것이었습니다. 슬레이브 데이터베이스의 모든 데이터는 마스터 데이터베이스의 데이터에서 가져오며, 동기화 후 슬레이브 데이터베이스는 마스터 데이터베이스와 데이터를 일관성 있게 유지할 수 있습니다. 그런 다음 데이터베이스에 대한 부담을 공유하기 위해 모든 쓰기 데이터 요청을 처리를 위해 메인 라이브러리에 넘길 수 있지만 읽기 요청은 다양한 슬레이브 라이브러리로 분산됩니다. 대부분의 시스템에서 읽기 및 쓰기 요청은 불균형적이므로(예: 100개의 읽기와 1개의 쓰기) 읽기 요청이 슬레이브 라이브러리 간에 공유되는 한 데이터베이스에 대한 부담은 그리 크지 않습니다. 물론 이 과정에는 비용이 들지 않는 것은 아니며 마스터 데이터베이스에서 슬레이브 데이터베이스로의 데이터 동기화에는 실제로 시간 비용이 들지만 당분간 이 문제에 대해서는 더 이상 논의하지 않겠습니다.
장점: 데이터베이스의 읽기 성능이 향상되고, 읽기가 다른 서버와 공유되어 쓰기 성능이 간접적으로 향상되며, 데이터베이스에 슬레이브 라이브러리가 있어 데이터베이스의 가용성이 향상됩니다.
단점: 핫스팟 데이터를 자주 읽으면 데이터베이스 부하가 높아지고, 동기화가 실패하거나 동기화 지연이 상대적으로 클 경우 데이터베이스에 기록된 데이터와 읽기 데이터베이스가 일치하지 않으며, 서버 비용을 추가로 늘려야 합니다.
5. 캐시 소개 - 핫 및 콜드 분리 아키텍처
방문 횟수가 지속적으로 증가함에 따라 비즈니스 내 일부 데이터의 읽기 빈도가 다른 데이터의 읽기 빈도보다 훨씬 높은 것으로 나타났습니다. 우리는 데이터의 이 부분을 콜드 데이터(Cold Data)에 해당하는 핫 데이터(Hot Data)라고 부릅니다. 핫 데이터의 경우 읽기 응답 시간을 향상시키기 위해 로컬 캐시를 추가하고 외부 분산 캐시를 추가하여 인기 제품 정보나 인기 제품의 HTML 페이지 등을 캐시할 수 있습니다. 캐싱을 통해 데이터베이스를 읽고 쓰기 전에 대부분의 요청을 가로챌 수 있으므로 데이터베이스 부담이 크게 줄어듭니다. 관련된 기술에는 Memcached를 로컬 캐시로 사용하고 Redis를 분산 캐시로 사용하는 것이 포함되며, 캐시 일관성, 캐시 침투/고장, 캐시 사태, 핫스팟 데이터 중앙 집중식 오류와 같은 문제도 포함됩니다.
장점: 데이터베이스에 대한 액세스 요청이 크게 줄어들고 성능 향상이 매우 분명합니다.
단점: 캐시 일관성, 캐시 고장, 캐시 오류, 캐시 사태 등의 문제가 발생하고, 서버 비용을 더욱 증가시켜야 하며, 비즈니스 규모가 증가함에 따라 데이터가 계속 증가하고, 단일 데이터베이스가 너무 크고, 단일 테이블도 크기가 크며, 너무 크면 데이터 쿼리가 매우 느려지고 데이터베이스가 다시 시스템 병목 현상을 일으키게 됩니다.
6. 수직 하위 라이브러리
비즈니스 데이터의 양이 증가함에 따라 동일한 데이터베이스에 많은 양의 데이터를 저장하는 것이 다소 부담스러워졌기 때문에 비즈니스에 따라 데이터를 별도로 저장할 수 있습니다. 예를 들어 댓글 데이터의 경우 제품 ID에 따라 해싱하여 해당 테이블로 라우팅하여 저장할 수 있고, 결제 기록의 경우 시간별로 테이블을 생성하고 각 시간별 테이블을 작은 테이블로 분할할 수 있으며, 사용자 ID 또는 레코드 번호를 사용하여 데이터를 라우팅할 수 있습니다. 실시간으로 운영되는 테이블 데이터의 양이 충분히 적고 여러 서버의 작은 테이블에 요청이 고르게 분산될 수 있다면 데이터베이스의 수평적 확장을 통해 성능을 향상시킬 수 있습니다. 앞서 언급한 Mycat은 큰 테이블이 작은 테이블로 분할될 때 접근 제어도 지원합니다. 이 접근 방식은 데이터베이스 운영 및 유지 관리의 어려움을 크게 증가시키며 DBA에 대한 요구도 더 높아집니다. 이러한 구조로 데이터베이스를 설계하면 이미 분산 데이터베이스라고 부를 수 있지만 이는 전체적으로는 논리적 데이터베이스에 불과하며, 데이터베이스의 여러 구성 요소는 하위 관리 및 요청과 같은 여러 구성 요소에 의해 별도로 구현됩니다. 데이터베이스 및 하위 테이블 배포는 Mycat에 의해 구현되고, SQL 구문 분석은 독립형 데이터베이스에 의해 구현되며, 읽기-쓰기 분리는 게이트웨이 및 메시지 큐에 의해 구현될 수 있으며, 쿼리 결과 요약은 데이터베이스 인터페이스 계층에 의해 구현될 수 있습니다. 이 아키텍처는 실제로 MPP(대규모 병렬 처리 구현 클래스) 아키텍처입니다.
장점: 데이터베이스 처리량이 크게 향상되었으며 더 이상 병목 현상이 발생하지 않습니다.
단점: 교차 데이터베이스 조인, 분산 트랜잭션 등의 문제를 적절히 해결해야 함 현재 mpp에는 해당 솔루션이 있으며 데이터베이스와 캐시의 조합은 현재 대규모 요청을 견딜 수 있지만 전체 응용 프로그램 코드가 함께 결합되어 있습니다., 한 줄 수정 코드 전체를 다시 게시해야 함
7. 비즈니스 분할 - 마이크로서비스
인원이 늘어나고 사업이 발전함에 따라 사업을 여러 개발팀으로 나누어 유지관리를 하고 있으며, 각 팀은 독립적으로 마이크로서비스를 구현한 후 서로 데이터에 대한 직접적인 접근을 격리합니다. 게이트웨이, 메시지 버스 등의 기술은 , 상호 호출 연관을 달성하기 위해 사용됩니다. 사용자 관리와 같은 일부 서비스를 공용 서비스로 전환할 수도 있습니다.
장점: 높은 유연성: 독립적인 테스트, 배포, 서비스 업그레이드 및 릴리스, 독립적인 확장: 각 서비스를 독립적으로 확장할 수 있음, 향상된 내결함성: 하나의 서비스 문제로 인해 전체 시스템이 마비되지 않음, 새로운 기술의 손쉬운 적용: 여러 프로그래밍 언어 지원
단점: 운영 및 유지 관리의 복잡성이 높음: 비즈니스가 지속적으로 발전함에 따라 애플리케이션과 서비스의 수가 계속 증가하고 애플리케이션과 서비스의 배포가 복잡해집니다. 동일한 서버에 여러 서비스를 배포하는 경우에도 문제 해결이 필요합니다. 실행 환경 충돌 문제 또한, 예를 들어 대규모 프로모션과 같이 동적 확장 및 축소가 필요한 시나리오에서는 서비스 성능의 수평적 확장이 필요하며, 이는 새로운 서비스에 대한 운영 환경 준비, 서비스 배포 등이 필요합니다. 매우 어렵습니다. 리소스 사용량이 증가합니다. 독립적으로 실행되는 모든 마이크로서비스는 메모리와 CPU를 점유해야 합니다. 오류를 처리하기 어렵습니다. 요청은 여러 서비스 호출에 걸쳐 있으며 문제 위치를 완료하려면 다양한 서비스의 로그를 확인해야 합니다.
8. 컨테이너화 도입 - 컨테이너 오케스트레이션 아키텍처
사업이 성장함에 따라 시스템의 자원 활용률이 높지 않다는 사실을 알게 되었고, 단기간의 높은 동시성을 처리하기 위해 많은 자원이 사용되어 평상시에는 유휴 상태가 되었으며, 동적 확장과 축소가 필요하다는 것을 알게 되었다. 서버를 직접 오프라인화해야 하고 개발, 테스트, 생산 과정에서 매일 모든 환경이 격리되어야 하는 환경에서는 운영 및 유지 관리 작업량이 매우 커집니다. 컨테이너화 기술의 출현은 이러한 문제를 해결하기 위한 새로운 아이디어를 가져왔습니다.
현재 가장 각광받는 컨테이너화 기술은 도커(Docker)이며, 가장 많이 활용되는 컨테이너 관리 서비스는 쿠버네티스(K8S)이며, 애플리케이션/서비스를 도커 이미지로 패키징할 수 있으며, K8S를 통해 해당 이미지를 동적으로 배포 및 배포할 수 있다. Docker 이미지는 애플리케이션/서비스를 실행할 수 있는 최소한의 운영체제로 이해될 수 있으며, 애플리케이션/서비스의 실행 코드가 포함되어 있으며, 실제 필요에 따라 운영 환경이 설정됩니다. 전체 "운영 체제"를 이미지로 패키징한 후 관련 서비스를 배포해야 하는 머신에 배포할 수 있으며, Docker 이미지를 직접 시작하여 서비스를 시작하고 서비스의 배포 및 운영, 유지 관리를 수행할 수 있습니다. 단순한. 서비스에는
일반적으로 공개적으로 공유되지 않는 생산 및 R&D k8s 클러스터가 있습니다. R&D 클러스터는 네임스페이스를 사용하여 애플리케이션 격리를 완료합니다. 일부 회사는 R&D 목적에 따라 R&D 클러스터와 테스트 클러스터로 구분되며, 일부 회사는 조직 구조를 통해 부서 간 리소스를 완성합니다. .재사용.
장점: 배포, 운영 및 유지 관리가 간단하고 빠릅니다. 하나의 명령으로 수백 가지 서비스의 배포 또는 확장 및 축소를 완료할 수 있습니다. 좋은 격리성: 컨테이너 간의 파일 시스템, 네트워크 등이 서로 격리되어 있습니다. 환경 충돌 없음, 쉬운 지원 롤링 업데이트: 단일 명령으로 버전 간 전환을 업그레이드하거나 롤백할 수 있습니다.
단점: 기술 스택 수가 증가하고 R&D 팀에 대한 요구 사항이 높으며, 기계는 여전히 회사 자체에서 관리해야 하며, 대규모 프로모션이 없을 때 대처하기 위해 많은 양의 기계 자원이 여전히 유휴 상태여야 합니다. 대대적인 프로모션으로 인해 기계 자체의 비용과 운영 및 유지 관리 비용이 극도로 높음 리소스 활용도가 높거나 낮은 문제는 클라우드 공급업체로부터 서버를 구입하여 해결할 수 있습니다.
요약하다
이 시점에서 합리적인 고가용성, 고동시성 시스템의 기본 프로토타입이 등장했습니다. 위에서 언급한 아키텍처 진화 순서는 특정 측면에 대한 별도의 개선일 뿐이며, 실제 시나리오에서는 동시에 해결해야 할 여러 가지 문제가 있을 수도 있고, 다른 측면이 먼저 병목 현상에 도달할 수도 있습니다. 실제 문제에 따라 실제적인 문제를 해결해야 합니다. 예를 들어, 동시성 양은 크지 않지만 비즈니스가 매우 부유할 수 있는 정부 시나리오에서 높은 동시성은 해결해야 할 핵심 문제가 아니며, 이때 우선 순위는 풍부한 요구를 충족하는 솔루션일 수 있습니다. 한 번 구현되고 명확한 성능 지표가 있는 시스템의 경우 시스템의 성능 지표 요구 사항을 지원하도록 아키텍처를 설계하는 것으로 충분하지만, 긴급 상황에 대비해 아키텍처를 확장하기 위한 인터페이스는 남겨두어야 합니다. 전자상거래 플랫폼과 같이 지속적으로 발전하는 시스템의 경우 다음 단계의 사용자 규모 및 성능 지표 요구 사항을 충족하도록 설계해야 하며, 비즈니스 성장에 따라 아키텍처를 반복적으로 업그레이드하여 더 높은 동시성과 더 풍부한 서비스를 지원해야 합니다. 소위 '빅데이터'는 실제로 대규모 데이터 수집, 정리 및 변환, 데이터 저장, 데이터 분석, 데이터 서비스 등의 시나리오 솔루션을 총칭하는 용어로, 각 시나리오에는 Flume, Sqoop 등 다양한 선택 기술이 포함되어 있습니다. , Kettle 등, 데이터 저장에는 분산 파일 시스템 HDFS, FastDFS, NoSQL 데이터베이스 HBase, MongoDB 등이 포함되며, 데이터 분석에는 Spark 기술 스택, 기계 학습 알고리즘 등이 포함됩니다. 일반적으로 빅데이터 아키텍처는 비즈니스 요구에 따라 다양한 빅데이터 구성요소를 통합한 아키텍처로 일반적으로 분산 스토리지, 분산 컴퓨팅, 다차원 분석, 데이터 웨어하우스, 기계 학습 알고리즘 및 기타 기능을 제공합니다. 서버 측 아키텍처는 애플리케이션 조직 수준의 아키텍처를 더 많이 의미하며 기본 기능은 빅 데이터 아키텍처에서 제공되는 경우가 많습니다.