수명이 긴 정보 시스템에는 반드시 확장성(~ 크기 조정)이 필요합니다. 즉, 모든 것을 다시 작성하지 않고도 어느 정도 성장할 수 있습니다. 프로그램 코드그리고 모든 장비를 교체합니다.
시스템은 세 가지 방향으로 확장될 수 있습니다: 1) 크기( 추가 사용자, 자원), 2) 지리적 의미의 범위, 3) 관리(많은 행정적으로 독립된 조직에서).
즉, 확장성에는 네트워크 사용자 수, 데이터베이스 크기, 트랜잭션 복잡성, 새로운 애플리케이션 출현 등 여러 유형의 성장이 포함됩니다.
네트워크의 사용자 수입니다. 두 배로 증가하면 네트워크와 데이터베이스의 로드도 두 배로 늘어날 가능성이 높습니다.
데이터베이스 크기. 데이터베이스가 수십, 수백 기가바이트로 증가하면 백업, 복원, 다운로드 작업에 병목 현상이 발생하게 됩니다.
거래 복잡성. 애플리케이션 개발자들은 애플리케이션을 점점 더 "스마트"하게 만들어 사용자가 더 쉽게 작업하고 데이터를 분석할 수 있도록 하고 있습니다. 그러나 동시에 데이터 관계의 수가 기하급수적으로 증가하고 그 결과 첫째로 쓰기의 복잡성이 증가하여 오류 가능성이 증가합니다. 둘째, 이러한 트랜잭션을 수행할 때 시스템은 많은 양의 데이터를 처리해야 하는데, 이는 특정 프로세서 성능, RAM 용량 등으로 인해 실질적으로 불가능할 수 있습니다. 결과적으로 데이터 언로드, 캐싱 등을 위한 몇 가지 특수 알고리즘을 작성해야 합니다.
새로운 애플리케이션의 출현. 사용자는 새로운 영역에서 컴퓨터를 사용하기 시작하여 기존 서버의 로드가 증가합니다. 또한, 애플리케이션 통합을 구성하는 것도 필요합니다.
확장형 시스템은 전력 확장 원리 중 하나(또는 둘 다!)를 사용할 수 있습니다. 컴퓨팅 시스템: 멀티프로세싱, 클러스터 기술.
확장 가능한 시스템은 단순히 하드웨어를 추가하여 네트워크, 서버, 데이터베이스 및 애플리케이션의 크기와 성능을 증가시켜 위에서 식별된 중앙 집중화 문제를 해결합니다. 확장 가능 IC는 애플리케이션을 다시 프로그래밍하지 않거나 최소한 완전히 다시 프로그래밍하지 않고도 전력 증가가 발생하는 성장 경로를 제공합니다.
확장성에 방해가 되는 상황
중앙 집중식 서비스
중앙 집중식 데이터
중앙 집중식 알고리즘.
중앙 집중식 서비스는 특정 서비스(프로그램)가 한 대의 컴퓨터에만 있다고 가정합니다. 다른 클라이언트에서 이 서비스에 대한 호출이 자주 발생하지 않고 동시에 발생하지 않는 경우 이는 완전히 허용되는 솔루션입니다. 그렇지 않으면 이러한 서비스는 시스템의 병목 현상이 됩니다. 중앙화된 서비스가 문제를 덜 일으키기 위해서는 고속 통신 회선을 사용해야 하며, 이 서비스가 위치한 컴퓨터는 충분히 빨라야 합니다. 램그리고 충분한 버퍼. 이러한 서비스의 확실한 장점은 업데이트가 더 쉽다는 것입니다. 서비스가 작동하기 위해 많은 양의 컴퓨팅 리소스가 필요한 프로세스인 경우 해당 리소스를 여러 클라이언트가 아닌 하나의 컴퓨터에서만 사용할 수 있도록 하는 것이 훨씬 더 비용 효율적일 수 있습니다. 그러나 반면에 중앙 집중식 서비스가 붕괴되면 시스템 전체가 기능을 상실하는 경우가 많습니다.
중앙 집중식 서비스의 예로는 네트워크에 진입하는 사용자의 권리와 권한을 결정하는 프로세스를 들 수 있습니다. 많은 사용자가 아침에 동시에 네트워크에 로그온하면 일시적인 것처럼 느껴진다는 사실을 눈치채셨을 것입니다. ㅏ 지연됐어요. 만약 당신이 낮 시간에 네트워크에 로그인한다면, 이런 일이 빠르게 일어날 것입니다. 도메인 컨트롤러에 오류가 발생하면 로컬 컴퓨터에서 작업할 수 있는 기능만 남습니다.
확장 가능한 시스템에서는 분산형 서비스를 사용하는 것이 제안됩니다. 이는 두 가지 방법으로 수행할 수 있습니다. 서비스를 여러 컴퓨터에 복제(복사)하거나 (가능한 경우) 서비스를 별도의 작업으로 나누고 해당 조각을 여러 컴퓨터에 배포하는 것입니다. 예: 충분히 크다 지역 네트워크 IP 주소 임대와 관련된 DHCP 서버, 로밍 프로필 저장소는 도메인 컨트롤러가 아닌 다음 위치에 위치하는 것이 좋습니다. 별도의 컴퓨터(물론 적절한 시간에 켜집니다).
중앙 집중식 서비스는 중앙 집중식 데이터와 연결되는 경우가 많습니다. 중앙 집중화된 데이터는 보호하기가 더 쉬운 경우가 많습니다(구성하기가 더 쉽습니다). 지원). 그러나 그러한 데이터의 양이 너무 커서 합리적인 컴퓨팅 성능만으로는 충분하지 않을 수 있습니다. 중앙 집중식 저장소에서는 필요한 데이터를 찾는 것이 더 어려워지는 경우가 많습니다. 한편, 스토리지가 증가함에 따라 검색 시간도 증가합니다. 반면에 중앙 집중식 저장소의 경우 많은 사람들이 데이터를 사용하기 때문에 기능 세트(검색 매개변수)가 늘어납니다. 다양한 작업. 중앙화된 데이터의 경우 다음을 수행하는 것이 매우 중요합니다. 보관 사본줄이기 위해 손실 가능성중앙 집중식 저장소가 고장난 경우. 중앙 집중식 데이터의 예로는 데이터베이스 서버(MY SQL, MS SQL 등)가 있습니다.
확장 가능한 시스템은 분산된 데이터와 함께 작동해야 합니다. 좋은 예– 네트워크 리소스의 기호 이름을 해당 IP 주소와 일치시키는 DNS 서비스입니다. DNS 서버 트리의 아키텍처를 사용하면 정보를 조각으로 나눌 수 있으며 각 조각은 하나의 서버에서 지원됩니다. 서버 간에 연결이 설정되었으며 상호 작용을 위한 프로토콜이 정의되었습니다. 이 연결을 제공하는 것은 분산형 저장소를 사용하는 데 드는 비용입니다. 분산형 저장소에는 정보에 대한 액세스 시간이 동일하지 않다는 몇 가지 흥미로운 특성이 있습니다. 이러한 차이를 완화하기 위해, 즉 원격 데이터에 대한 최소한 반복적인 액세스 속도를 높이기 위해 DNS 서버는 정보 캐싱을 사용합니다. 그러나 캐싱으로 인해 데이터 불일치 문제가 발생한다는 것을 기억합니다. 데이터 분산화로 인해 발생하는 문제 중 가장 큰 문제는 데이터의 불일치입니다. 다른 컴퓨터, 잠시 후에 살펴보겠습니다. 13가지 일관성 모델을 살펴보겠습니다.
중앙 집중식 알고리즘은 분산 시스템에도 좋지 않습니다. 알고리즘을 완료하기 위해, 즉 결정을 내리기 위해 다음이 필요한 경우 알고리즘은 중앙집중화된 것으로 간주될 수 있습니다. 전체 정보, 직접 출처에서 얻은 것입니다. 강좌에서 공부한 라우팅 알고리즘을 기억해 봅시다. 정보 네트워크" 중앙 집중식 알고리즘의 예로 "채널 상태 프로토콜"을 고려해 보겠습니다. 이 알고리즘은 테이블 라우터가 각 라우터와 통신한다고 가정합니다. 이로 인해 엄청난 수의 서비스 패킷이 전송됩니다. 이 알고리즘은 라우터가 사라지는 것에 약하게 민감하지만 라우터 리소스와 네트워크를 요구합니다. "거리 벡터 프로토콜" 알고리즘은 중앙 집중식 알고리즘에 속하지 않습니다. 결정을 내리기 위해(라우팅 테이블 구축) 라우터는 이웃에게만 연락하면 됩니다. 이 알고리즘은 네트워크를 훨씬 적게 차지하지만 라우터가 사라지면 잘못된 결정을 내릴 수 있습니다(거리를 무한대로 늘리는 문제).
확장 가능한 시스템을 만드는 데 사용되는 기술: 통신 대기 시간, 배포, 복제를 숨깁니다.
시간 초과 숨기기는 응답이 도착할 때까지 원격 서비스를 요청한 프로세스가 예상 응답과 관계없이 일부 작업을 수행하는 비동기 통신을 통해 구현되는 경우가 많습니다. 이를 구현하기 위해 멀티스레드 애플리케이션을 구성하는데, 요청 시 스레드(스레드) 중 하나가 차단되어 응답을 기다리는 즉, 원격 서비스와 동기적으로 작동하며, 나머지 스레드는 비동기적으로 작동합니다. 즉, 실행을 계속합니다. 그러나 비동기 실행을 준비하는 것이 항상 가능한 것은 아닙니다. 예를 들어 다음과 같은 경우입니다. 대화형 작업원격 데이터베이스를 가진 사용자. 이 경우 스크립트를 사용하여 클라이언트 측에서 최소한 부분적인 데이터 검증을 준비하여 원격 데이터베이스에 대한 호출 수를 줄이고 클라이언트 대기 시간을 줄이는 것이 좋습니다.
두번째 중요한 기술확장 – 배포. 분산 DNS 서비스에 대해서는 이미 언급했습니다. 데이터 배포 구현의 중요한 측면은 이름 지정입니다. 문제는 이름이 고유해야 한다는 것입니다. 즉, 네임스페이스는 어떤 방식으로든 구성되어야 합니다. 파일과 마찬가지로 각 인터넷 개체에는 고유한 개체가 있어야 합니다. 성명, 이름 포함 DNS 서버개체에서 DSN 루트로.
그리고 마지막으로 세 번째 기술은 복제입니다. 복제를 사용하면 공유 데이터의 전부 또는 일부가 여러 컴퓨터에 복사됩니다. 결과적으로 데이터를 사용자에게 더 가까이 다가갈 수 있어 액세스 시간이 줄어들고 스토리지를 지원하는 컴퓨터의 부하가 줄어듭니다. 이러한 솔루션의 대가는 데이터 일관성을 보장해야 한다는 것입니다. 복제와 캐싱을 구별해야 합니다. 복제는 데이터 서버(소유자)의 주도로 발생하고, 캐싱은 클라이언트(사용자)의 주도로 발생합니다.
캐싱을 처리하는 경우 클라이언트(예: 인터넷 익스플로러)는 데이터의 관련성을 독립적으로 모니터링해야 합니다. 이를 위해 사용되는 메커니즘: a) 특정 시간 이후 데이터 업데이트 요청, b) 관련성(서버의 일관성) 요청. 첫 번째 경우에는 변경되지 않은 데이터가 전송되어 네트워크에 불필요하게 부하를 줄 수 있습니다. 그리고 두 번째에서는 클라이언트가 먼저 데이터가 변경되었는지 확인하고 변경된 경우에만 데이터 전송 요청을 보냅니다. 분명히 데이터가 거의 변경되지 않으면 두 번째 방법을 사용하는 것이 바람직하고 그렇지 않으면 첫 번째 방법을 사용하는 것이 좋습니다. 이제 일관성에 대해 몇 마디 말씀드리겠습니다. 분산 시스템에는 다양한 데이터에 대해 다양한 수준의 "최신성"을 요구하는 다양한 클라이언트가 있을 수 있고, 다양한 데이터는 업데이트 시간과 기타 특성이 다르며, 데이터 전송은 비용이 많이 드는 즐거움입니다. 다른 경우일관성을 보장하기 위해서는 다양한 방법이 필요합니다.
확장성 정보 시스템– 수평 및 수직 모두 – 가장 많은 것 중 하나입니다. 중요한 요소, 조직의 활동을 자동화하는 수단을 선택할 때 주의해야 할 사항입니다. 선택한 솔루션을 확장할 수 없거나 비즈니스 성장의 각 단계에서 해당 솔루션을 유지하고 개발하는 데 어려움을 겪을 경우 소프트웨어 제품, 그렇다면 사용을 시작해서는 안됩니다. 우리는 높은 확장성 요구 사항을 고려하여 LETOGRAF EDMS를 개발했습니다.
수천 또는 수만 명의 사용자를 고용하는 기업의 고부하 IT 시스템 구축과 관련하여 수평적 또는 수직적 확장의 필요성이 발생합니다. 그러나 모든 EDMS가 많은 사용자의 동시 작업을 지원할 수 있는 것은 아닙니다. 아키텍처 수준의 EDMS에 성능 저하 없이 사용자 수를 늘릴 수 있는 기능이 포함된 경우에만 이 경우에만 확장이 성공합니다. 우리가 만든 LETOGRAF 시스템은 수평 및 수직 모두 이상적으로 확장 가능하도록 설계되었습니다. 이는 시스템 자체의 아키텍처와 우리가 개발한 애플리케이션 코드, 그리고 우리의 EDMS가 구축된 InterSystems Caché DBMS의 기능을 통해 달성됩니다.
Caché DBMS는 신속한 애플리케이션 개발을 위한 최신 데이터베이스 관리 시스템 및 환경입니다. 본 DBMS는 성능을 보장하는 기술을 기반으로 하며, 고성능, 확장성 및 신뢰성. 동시에 시스템의 하드웨어 요구 사항은 매우 적당합니다.
Caché DBMS는 분산 시스템에서 엄청난 양의 데이터와 다수의 서버를 처리하는 경우에도 높은 성능을 유지합니다. 이 경우 데이터는 개체, 고성능 SQL 쿼리 및 다차원 데이터 구조의 직접 처리를 통해 액세스됩니다.
수직 확장
수직적 확장에는 서버의 성능과 관련 기능을 높이는 것이 포함됩니다. 디스크 하위 시스템. LETOGRAF는 최신 프로세서 아키텍처를 지원하므로 여러 스레드에서 대량의 데이터를 처리할 수 있습니다. 동시에 EDMS의 데이터 자체는 스토리지 시스템 전체에 쉽게 배포될 수 있도록 구성되어 있습니다. 다른 디스크. 이 접근 방식을 사용하면 데이터 저장소의 부하를 고르게 분산하고 데이터베이스에서 직접 데이터를 읽을 때 부하를 최소화할 수 있습니다. 즉, 많은 수의 사용자가 동시에 작업하는 경우에도 시스템 성능 저하를 방지할 수 있습니다.
플랫폼 개발 단계에서도 우리는 수직적 확장이 시스템의 핵심 기능 중 하나이며 시간이 지남에 따라 그 필요성이 증가할 것이라는 점을 이해했습니다. 우리는 각 사용자의 업무 프로세스를 별도의 업무 프로세스로 분리하는 방식으로 시스템을 개발했습니다. 시스템 프로세스, 데이터베이스가 정보에 대한 액세스를 효과적으로 공유한다는 사실로 인해 중복되지 않습니다. 동시에 LETOGRAF EDMS의 데이터 잠금 횟수가 최소화되고 데이터를 읽거나 쓸 때 병목 현상이 발생하지 않습니다.
EDMS LETOGRAF의 아키텍처를 사용하면 여러 물리적 서버 또는 가상 서버에 데이터를 배포할 수 있습니다. 이러한 배포 덕분에 각 사용자는 격리된 프로세스에서 실행되며 필요한 데이터는 Caché DBMS 기술을 사용하여 효율적으로 캐시됩니다. 데이터 잠금 시간이 최소화됩니다. 모든 트랜잭션은 매우 짧은 시간 동안만 데이터를 독점 액세스 모드로 전환하는 방식으로 구성됩니다. 동시에 로그, 인덱스, 개체 데이터, 스트림, 사용자 작업 로그 등 디스크 액세스 횟수 측면에서 로드가 많은 데이터라도 하위 시스템의 평균 로드가 일정하게 유지되는 방식으로 분산됩니다. 지연으로 이어지지 않습니다. 이 접근 방식을 사용하면 시스템을 수직으로 효과적으로 확장하여 서버나 가상 디스크 간에 로드를 분산할 수 있습니다.
수평적 확장
수평적 확장은 여러 서버에 걸쳐 사용자 세션을 배포하는 것(애플리케이션 서버 로드 및 추가 애플리케이션 서버 연결 기능 포함)과 여러 데이터베이스 서버에 데이터를 배포하는 것입니다. 이는 내결함성을 줄이지 않고 높은 시스템 성능을 보장합니다. 수평 확장의 경우 LETOGRAF 시스템은 다양한 가능성을 제공합니다.
우선 InterSystems Caché DBMS에서 사용하는 프로토콜인 Enterprise Cache Protocol(ECP, 분산 캐시 프로토콜) 덕분에 로드 스케일링이 가능해졌습니다. ECP의 장점은 데이터 캐싱에 대한 혁신적인 접근 방식입니다. 이내에 이 프로토콜의 DBMS의 애플리케이션 서버(또는 ECP 클라이언트)에서 실행되고 쿼리를 제공하는 사용자 프로세스는 최근에 사용된 데이터의 로컬 캐시에 대한 액세스 권한을 얻습니다. 그리고 이 데이터가 충분하지 않은 경우에만 ECP 클라이언트가 데이터베이스에 액세스합니다. ECP 프로토콜을 사용하여 수행됩니다. 자동 제어캐시: 가장 자주 액세스하는 데이터는 캐시에 저장되고, 자주 업데이트되는 데이터는 주기적으로 복제되어 항상 모든 ECP 클라이언트에서 데이터 무결성과 정확성을 보장합니다. 이 경우 내부 InterSystems Caché 알고리즘은 데이터베이스가 ECP 클라이언트와 ECP 서버 간에 동기화된다고 가정합니다.
실제로 Caché DBMS 기술을 사용하면 애플리케이션 서버 전반에 걸쳐 로드를 쉽고 빠르게 확장할 수 있으므로 ECP 프로토콜을 사용하여 많은 수의 사용자를 하나의 데이터베이스 서버에 연결할 수 있습니다.
특정 사용자가 요청한 정보는 여러 ECP 클라이언트에서 사용될 수 있으므로 짧은 시간 동안 데이터를 차단하고 내부 계산을 수행하지 않고 빠르게 트랜잭션을 수행해야 합니다. 그리고 우리는 이것을 성공적으로 구현했습니다. 이 기술하나의 데이터베이스 서버와 사용자 프로세스를 실행하는 여러 서버를 사용하는 상황에서 시스템을 효과적으로 확장할 수 있습니다. Caché DBMS의 기술적 특징은 연결된 ECP 클라이언트 수에 관계없이 하나의 ECP 서버 내에서 트랜잭션의 정확성을 유지한다는 것입니다. 하나의 ECP 서버와 많은 ECP 클라이언트가 있는 경우 모든 트랜잭션이 하나의 데이터베이스 서버에서 발생하기 때문에 이 문제는 완벽하게 해결됩니다.
경험에 따르면 로드가 높은 시스템에서도 특정 특성에 따라 데이터베이스 서버 간에 데이터를 명확하게 구분하는 것이 항상 가능합니다. 예를 들어 여러 조직이 하나의 지주로 통합된 경우 한 구조 단위의 사용자가 다른 단위와 관련된 데이터를 요구할 가능성은 거의 없습니다. 이를 통해 알고리즘 수준에서 이러한 데이터를 서로 다른 데이터베이스 서버에 분리하고 저장할 수 있으므로 수평적 확장 가능성이 높아집니다.
EDMS LETOGRAF는 프로그래밍을 사용하지 않고 시스템 설정 수준에서 여러 데이터베이스 서버에 데이터 자체를 배포하는 규칙과 원칙을 설명할 수 있는 샤딩 메커니즘을 구현합니다. 데이터베이스 구조의 관점에서 볼 때 각 서버에 저장되는 정보는 동일하지만, 정보 자체는 조직이나 특정 작업에 중요한 기타 특성에 따라 근본적으로 다릅니다. 샤딩 기술을 사용하면 95-99%의 경우 사용자가 자신의 "데이터 부분"으로만 작업하고 세션 내에서 다른 데이터베이스 서버에 액세스할 필요가 없게 되는 것을 달성할 수 있습니다.
LETOGRAF EDMS의 확장 기능은 데이터가 다르게 처리될 수 있다는 사실에도 영향을 받습니다. 예를 들어, 문서(몇 년 전에 작성된 문서도 포함)를 변경할 수 있지만 항목은 사용자 활동 로그에만 추가할 수 있습니다(단일 항목을 삭제하거나 변경할 수는 없음). LETOGRAF EDMS에 사용되는 메커니즘을 사용하면 단일 서버 및 다중 서버 구성의 경우 모두 별도의 데이터베이스 서버에 이러한 로그를 유지함으로써 시스템 성능을 더욱 향상시키고 확장성을 향상시킬 수 있습니다. 이 접근 방식은 기본 데이터베이스 서버의 로드를 줄이는 것을 목표로 합니다.
콘텐츠(EDMS의 "정보 콘텐츠")에서도 유사한 상황이 발생합니다. LETOGRAF 시스템은 테라바이트 단위의 데이터, 수백만 개의 파일 및 문서와 같은 대용량 콘텐츠를 처리하므로 시스템에 입력된 콘텐츠는 어떤 상황에서도 손상되지 않아야 한다고 가정하는 것이 합리적입니다. 따라서 파일 스토리지도 별도의 데이터베이스 서버로 이동하여 추가적인 수평 확장을 제공합니다.
프런트엔드 소프트웨어
LETOGRAF EDMS는 Apache 및 HAProxy를 프런트 엔드로 사용합니다. HAProxy는 Apache 웹 서버 간의 로드 밸런싱을 담당합니다. 시스템 경험에서 알 수 있듯이 HAProxy는 많은 수의 사용자를 지원하고 내결함성에 필요한 제어를 제공할 수 있는 가장 효과적인 솔루션으로 자리매김했습니다.
사용자가 브라우저를 열고 시스템에 연결하면 HAProxy는 이를 애플리케이션 서버 중 하나에 "배포"합니다. 또한 이 사용자로부터 오는 모든 요청은 동일한 프로세스의 동일한 애플리케이션 서버로 전송됩니다.
우리는 다양한 시스템을 시도했고 테스트 결과 HAProxy가 애플리케이션 서버의 무료 슬롯 전체에 사용자를 균등하게 분산시키는 가장 효과적인 로드 밸런싱 장치인 것으로 나타났습니다. HAProxy에는 각 애플리케이션 서버의 상태를 추적하고 배포하지 않는 데 필요한 모든 메커니즘이 있습니다. 새로운 트래픽어떤 이유로 장애가 발생한 애플리케이션 서버에. 또한 HAProxy는 정적(사용자 작업 중에 변경할 수 없는) 데이터(예: 스타일, 아이콘 등) 캐싱 측면에서 다양한 기능을 추가로 제공하여 인터페이스를 구성할 수 있습니다.
프로젝트 구현 예시
LETOGRAF 아키텍처를 사용하면 응답 시간을 줄이고 시스템 성능을 향상시키는 중요한 결과를 얻을 수 있습니다. 우리 프로젝트 중 하나의 일환으로 23.5TB의 데이터가 EDMS에 저장됩니다. 이 중 14.7TB(63%)는 스트림(“카드에 첨부된 파일”)이고, 3.5TB(15%)는 보고서 테이블과 같은 보고 양식입니다. 이는 비동기 모드로 생성되고 일정과 시간에 따라 실행될 수 있습니다. 사용자의 요청을 처리하고 개체까지 자세히 설명할 수 있는 모든 데이터를 요약 테이블로 표시합니다. 또 다른 1.6TB(7%)는 사용자 트랜잭션 로그이고 나머지(16%)는 카드 데이터 및 인덱스입니다.
이 시스템에는 11,000명 이상의 사용자가 근무하고 있으며 그 중 2,000명이 동시에 작업하고 있으며 피크일에는 EDMS에서 동시에 작업하는 직원 수가 3,000명을 초과합니다. 로그 항목 수는 이미 55억 개를 초과했으며 등록 카드 수는 이미 초과했습니다. 거의 5억에 이르렀습니다.
이 프로젝트에는 두 개의 장애 조치 클러스터가 데이터베이스 서버로 설치되어 있습니다. 물리적 서버세 개의 DBMS 설치와 백업 서버가 있습니다. 10개의 애플리케이션 서버(및 1개의 백업)가 사용자 세션을 처리하고 비동기 보고를 제공합니다. 2개의 HAProxy 서버는 밸런서 역할을 합니다. 서버 중 하나에 문제가 발생하면 해당 IP 주소가 자동으로 다른 서버로 이전됩니다. 파일 인덱싱 서버와 인식 서버(전자 이미지를 시스템에 배치할 때 스캔한 종이 문서의 텍스트 인식 제공)도 있습니다.
요약
EDMS LETOGRAF는 다양한 스케일링 메커니즘을 제공합니다. 우리는 운영 체제가 설치된 서버(물리적 또는 가상)를 기반으로 하는 일종의 파이를 제공합니다. 그 위에 플랫폼 코드가 위치한 InterSystems Caché DBMS가 있습니다. 그리고 그 위에는 이미 EDMS가 완전히 구성되어 있는 LETOGRAF 시스템의 설정이 있습니다. 그리고 그러한 파이는 모든 서버에 배치됩니다. 서버는 선택한 구성으로 인해 특정 방식으로 서로 연결됩니다. 그리고 마지막 계층은 서버 간에 사용자 요청을 분산시키는 HAProxy입니다. 이 아키텍처를 통해 확장성을 지원하고 필요한 모든 모니터링 메커니즘을 제공할 수 있습니다. 결과적으로 최종 사용자는 빠르게 실행되는 EDMS를 받고 IT 전문가는 로드가 많은 애플리케이션의 경우 지속적으로 모니터링하고 관리해야 하는 엄청난 수의 구성 요소 없이 관리 및 유지 관리가 쉬운 통합 시스템을 받게 됩니다. . 또한 조직의 변화하는 요구 사항에 따라 새로운 서버나 디스크 기능을 추가하여 LETOGRAF EDMS를 쉽게 재구성할 수 있습니다.
이 자료는 Club.CNews 커뮤니티 회원의 비공개 게시물입니다.
CNews 편집자는 해당 내용에 대해 책임을 지지 않습니다.
2012년 말까지 x86 플랫폼에서 실행되는 애플리케이션의 50% 이상이 가상화되었습니다. 그러나 비즈니스에 중요한 애플리케이션 중 가상화되는 비율은 20%에 불과합니다.
IT 부서가 가상화 플랫폼을 신뢰하지 않기 때문일까요? 그들은 가상화 플랫폼이 미션 크리티컬 애플리케이션을 지원할 만큼 안정적이지 않다고 생각합니까?
지난 10년 동안 VMware는 가상화가 현실임을 입증했으며 실제로 가상화된 애플리케이션은 VMware 관리 인프라에서 실행될 때 더 안정적인 경우가 많습니다.
그렇다면 신뢰나 안정성이 문제가 되지 않는다면 IT 부서가 아직 나머지 애플리케이션을 가상화하지 않은 이유는 무엇일까요?
규모 확장
수평 확장 또는 수평 확장 - 클러스터의 서버와 같은 인프라에 새 리소스를 추가합니다.
가격이 계속 하락하고 성능이 계속 상승함에 따라 저렴한 상용(널리 소비되는) 서버가 이상적인 솔루션수평적 확장을 위해 대규모 클러스터로 조립되어 컴퓨팅 리소스를 풀링할 수 있습니다.
지난 7년 동안 VMware 인프라 설계자들은 수평적 확장을 위해 기도해 왔습니다. 어떤 사람들은 이 특정 접근 방식을 사용해야 한다고 주장할 수도 있지만, 여기에도 고유한 뉘앙스가 있으며 모두 비즈니스 요구 사항에 따라 다릅니다. 수평적 확장의 장점은 상용 서버의 가격이 저렴하고, 서버에 장애가 발생하면 소수의 VM에 영향을 미친다는 점이다. 단점은 vSphere 라이센스 비용이 높고 데이터 센터 공간에 대한 요구 사항이 크며 일반적으로 이러한 상용 서버에는 대규모 컴퓨팅 리소스가 없다는 것입니다.
확장
수직 확장은 이미 사용된 서버에 컴퓨팅 리소스를 추가하는 것입니다. 일반적으로 이는 프로세서 또는 RAM입니다.
일반적으로 이러한 서버는 4개의 프로세서와 512GB의 메모리를 지원하여 매우 강력합니다. 또한 8개의 프로세서와 1TB의 메모리를 탑재한 시스템도 있고, 일부는 4TB의 메모리를 탑재한 16개의 프로세서 서버까지 볼 수 있는 행운을 누리기도 합니다. 아니요, 이들은 메인프레임이나 그와 유사한 것이 아닙니다. 이들은 클래식 x86 아키텍처를 기반으로 하는 서버입니다.
이 기술이 비즈니스 크리티컬 애플리케이션에 제공하는 유연성을 제공하는 두 번째 가상화 물결로의 전환은 다음과 같은 문제로 인해 현재 사용 중인 VMware 인프라에 엄청난 압박을 가하고 있습니다.
- 확장 기능이 부족합니다. 저가형 상용 서버에서 사용할 수 있는 리소스 양이 제한되어 있기 때문에 컴퓨팅 집약적인 워크로드는 어려운 문제입니다.
- 신뢰성이 부족합니다. 이러한 구성요소를 사용하는 상용 장비나 하드웨어는 신뢰성이 떨어질 수 있습니다. 안정성 문제는 다음 기사에서 설명할 기능을 사용하여 해결할 수 있습니다.
- 관리 복잡성이 증가하고 운영 비용이 증가합니다. 1000대가 아닌 100대의 서버를 관리하는 것이 더 쉽고, 결과적으로 10대의 서버가 100대보다 관리하기 쉽습니다. 운영 비용에도 동일하게 적용됩니다. 서버 10대가 100대보다 유지 관리 비용이 훨씬 저렴합니다.
vSphere 5가 출시되면서 하나의 VM에서 사용할 수 있는 리소스 수가 4배 증가했습니다.
그리고 vSphere 5.1의 출시로 괴물 같은 VM은 더욱 괴물이 될 수 있습니다.
vSphere 5.1이 몬스터 VM을 시작할 수 있으려면 스케줄러에 64개의 물리적 프로세서에서 실행될 스레드가 있어야 하고 예약해야 합니다. 이렇게 많은 코어를 지원할 수 있는 서버는 많지 않으며, 16소켓과 160코어를 지원하는 서버는 더욱 적습니다.
서버 수직 확장에는 글루리스와 글루드라는 두 가지 유형이 있습니다. 이 단어는 각각 기술을 통합하지 않고 기술을 통합하여 다음과 같이 러시아어로 번역됩니다.
글루리스 아키텍처
이 아키텍처 Intel에서 개발하여 Intel Xeon E7에 도입되었습니다.
I/O 장치 간의 통신을 위해서는 네트워크 인터페이스프로세서는 특별히 설계된 QPI 버스를 사용합니다.
4개의 프로세서가 있는 서버에서는 모두 이 버스를 통해 서로 직접 연결됩니다. Glueless 프로세서는 채널 중 하나를 사용하여 프로세서를 I/O 인터페이스에 연결하고 나머지 세 개는 인접 프로세서에 연결합니다.
8 프로세서 서버에서 각 프로세서는 3개의 인접 프로세서에 직접 연결되고 다른 프로세서를 통해 다른 4개 프로세서에 연결됩니다.
이 아키텍처의 장점:
- 서버 제조사의 특별한 개발이나 전문화가 필요하지 않습니다.
- 모든 서버 제조업체는 8 프로세서 서버를 생산할 수 있습니다.
- 4개 및 8개 프로세서 서버 비용이 모두 절감됩니다.
- 규모를 확장하면 총 소유 비용이 증가합니다.
- 8개의 프로세서 서버로 제한된 아키텍처
- 소켓이 증가함에 따라 캐시 무결성을 유지하기가 어렵습니다.
- 비선형 생산성 증가
- 가격 대비 성능 비율이 하락하고 있습니다.
- 대규모 VM을 사용할 때 최적이 아닌 성능
- 버스 대역폭의 최대 65%가 채팅 QPI 프로토콜 브로드캐스트에 사용됩니다.
QPI 프로토콜의 단점으로 인해 성능이 저하되는 주요 애플리케이션은 Java 애플리케이션, 대규모 데이터베이스 및 대기 시간에 민감한 애플리케이션입니다.
수직 확장의 결과는 병목 현상이 없어야 하며 그렇지 않으면 아키텍처가 의미가 없게 됩니다. 따라서 생산성 증가의 선형성은 자원 추가의 선형성과 일치해야 합니다.
접착식 아키텍처
위에서 설명한 문제를 해결하기 위해 하드웨어 개발자는 접착 아키텍처를 개발했습니다. 이 아키텍처는 외부 노드 컨트롤러를 사용하여 QPI 아일랜드(프로세서 클러스터)의 상호 연결을 구성합니다.
Intel QPI는 확장 가능한 특별한 솔루션인 eXternal Node-Controller(또는 XNC)를 제공합니다. 실질적인 구현타사 OEM 회사에서 개발한 제품입니다. 내장형 메모리 컨트롤러와 함께 Intel Xeon E7-4800부터 사용되는 외부 노드 컨트롤러에는 ccNUMA(Cache Coherent Non-Uniform Memory Access) 시스템도 포함되어 있으며, 이 시스템의 작업은 데이터의 관련성을 모니터링하는 것입니다. 프로세서 캐시 메모리의 각 라인에 있습니다.
ccNUMA의 프로세서와 메모리 사이의 대기 시간은 서로 관련된 두 구성 요소의 위치에 따라 달라지므로 XNC 컨트롤러가 중요한 서버 구성 요소가 되고 확장 가능한 서버를 설계할 수 있는 서버 제조업체는 거의 없습니다.
단일 정보 시스템일반적으로 독립형 개인용 컴퓨터에서 구현됩니다(네트워크는 사용되지 않음). 이러한 시스템에는 공통 정보 기금으로 연결된 여러 개의 간단한 애플리케이션이 포함될 수 있으며 한 사용자 또는 하나를 공유하는 사용자 그룹의 작업을 위해 설계되었습니다. 직장. 이러한 응용 프로그램은 소위를 사용하여 생성됩니다. 데스크탑, 또는 현지의, 데이터베이스 관리 시스템(DBMS). 로컬 DBMS 중에서 가장 유명한 것은 Clarion, Clipper, FoxPro, Paradox, dBase 및 Microsoft Access입니다.
그룹 정보 시스템작업 그룹 구성원의 집단적 정보 사용에 중점을 두고 있으며 대부분 로컬 컴퓨터 네트워크를 기반으로 구축됩니다. 이러한 애플리케이션을 개발할 때 작업 그룹에는 데이터베이스 서버(SQL 서버라고도 함)가 사용됩니다. 상업용 및 무료로 배포되는 다양한 SQL 서버가 상당히 많이 있습니다. 그 중 가장 유명한 데이터베이스 서버로는 Oracle, DB2, Microsoft 등이 있습니다. SQL 서버, 인터베이스, 사이베이스, 인포믹스.
기업 정보 시스템작업 그룹을 위한 시스템 개발에 중점을 두고 있습니다. 대기업지리적으로 분산된 노드나 네트워크를 지원할 수 있습니다. 기본적으로 그들은 여러 수준의 계층 구조를 가지고 있습니다. 이러한 시스템은 서버 전문화 또는 다중 레벨 아키텍처를 갖춘 클라이언트-서버 아키텍처가 특징입니다. 이러한 시스템을 개발할 때 그룹 정보 시스템을 개발할 때와 동일한 데이터베이스 서버를 사용할 수 있습니다. 그러나 대규모 정보 시스템에서 가장 널리 사용되는 서버는 Oracle, DB2 및 Microsoft SQL Server입니다. 그룹 및 기업 시스템의 경우 안정적인 운영 및 데이터 보안에 대한 요구 사항이 크게 높아졌습니다. 이러한 속성은 데이터베이스 서버의 데이터, 참조 및 트랜잭션의 무결성을 유지함으로써 제공됩니다.
중앙 집중식 또는 분산형 데이터베이스.
디자인 특징편물현재 지향적인 시스템
스크럼엄격하게 고정된 짧은 기간을 허용하는 개발 프로세스가 구축된 일련의 원칙입니다( 스프린트 2~4주) 최종 사용자에게 우선순위가 가장 높은 새로운 기능을 갖춘 작동 가능한 소프트웨어를 제공합니다. 다음 스프린트 구현을 위한 소프트웨어 기능은 스프린트 시작 시 계획 단계에서 결정되며 전체 기간 동안 변경될 수 없습니다. 동시에, 엄격하게 고정된 짧은 스프린트 기간은 개발 프로세스에 예측 가능성과 유연성을 제공합니다.
ORM데이터베이스를 객체지향 프로그래밍 언어의 개념과 연결하여 "가상 객체 데이터베이스"를 생성하는 프로그래밍 기술입니다.
문제: 객체 지향 프로그래밍에서 프로그램의 객체는 실제 세계의 객체를 나타냅니다. 문제의 본질은 그러한 객체를 객체의 속성과 객체 간의 관계를 유지하면서 파일이나 데이터베이스에 저장할 수 있고 나중에 쉽게 검색할 수 있는 형식으로 변환하는 것입니다. 이러한 개체를 "저장된" 개체라고 합니다. 지속성 있는). 역사적으로 이 문제를 해결하기 위한 여러 가지 접근 방식이 있었습니다.
모델-뷰-컨트롤러- 애플리케이션 데이터 모델, 사용자 인터페이스 및 제어 로직이 세 개의 개별 구성요소로 분리되어 한 구성요소를 수정해도 다른 구성요소에 최소한의 영향을 미치는 소프트웨어 아키텍처입니다.
확장성(Scalability) - 장치의 성능을 향상시키는 능력
가능성
기능 블록의 수를 늘려,
혼자 공연하고
동일한 작업.
Glossary.ru
일반적으로 사람들은 스케일링에 대해 생각하기 시작합니다.
서버가 할당된 작업을 처리할 수 없습니다. 그 사람은 정확히 무엇을 가지고 있지 않습니까?
코프? 모든 웹 서버의 운영은 크게 기본으로 귀결됩니다.
컴퓨터의 직업은 데이터 처리입니다. HTTP(또는 기타) 요청에 대한 응답
일부 데이터에 대해 일부 작업을 수행하는 작업이 포함됩니다. 각기,
우리는 두 가지 주요 엔터티, 즉 데이터(볼륨으로 특징지어짐)와
계산 (복잡성이 특징). 서버가 이에 대처하지 못할 수도 있습니다.
많은 양의 데이터로 인해 작업(물리적으로 맞지 않을 수 있음)
서버) 또는 과도한 컴퓨팅 부하로 인해 발생합니다. 여기서 얘기는
물론 총 부하에 대해서는 하나의 요청을 처리하는 복잡성이
규모는 작지만 그 수가 많으면 서버를 압도할 수 있습니다.
주로 예제를 사용하여 스케일링에 대해 이야기하겠습니다.
일반적으로 성장하는 웹 프로젝트이지만 여기에 설명된 원칙은 다음에도 적합합니다.
다른 적용 분야. 먼저 프로젝트 아키텍처와 간단한 내용을 살펴보겠습니다.
여러 서버에 구성 요소를 배포한 다음
컴퓨팅 및 데이터 확장.
일반적인 사이트 아키텍처
일반적인 웹사이트의 삶은 매우 단순한 아키텍처로 시작됩니다.
- 이것은 하나의 웹 서버입니다(보통 Apache가 그 역할을 합니다).
HTTP 요청을 처리하는 모든 작업을 처리합니다.
방문객으로부터 받았습니다. 그는 고객에게 소위 "정적"을 제공합니다.
처리가 필요하지 않은 파일이 서버 디스크에 있습니다. 사진(gif,
jpg, png), 스타일 시트(css), 클라이언트 스크립트(js, swf). 동일한 서버
계산이 필요한 쿼리에 응답 - 일반적으로 형성
html 페이지이지만 때로는 이미지와 기타 문서가 즉시 생성되기도 합니다.
대부분의 경우 이러한 요청에 대한 응답은 PHP로 작성된 스크립트에 의해 생성됩니다.
펄이나 다른 언어.
이러한 간단한 작업 계획의 단점은 다음과 같습니다.
요청의 성격(디스크에서 파일 업로드 및 스크립트 계산 작업)
동일한 웹 서버에서 처리됩니다. 계산 쿼리에는 다음이 필요합니다.
서버 메모리에 많은 정보를 보관합니다(스크립트 언어 해석기,
스크립트 자체, 작업하는 데이터) 그리고 많은 부분을 차지할 수 있습니다.
컴퓨팅 리소스. 반대로 정적 데이터를 발행하는 데에는 리소스가 거의 필요하지 않습니다.
프로세서가 필요하지만 클라이언트의 성능이 낮을 경우 시간이 오래 걸릴 수 있습니다.
통신 속도. Apache 서버의 내부 설계에서는 각
연결은 별도의 프로세스에 의해 처리됩니다. 스크립트를 실행할 때 편리합니다.
그러나 처리에는 최적이 아닙니다. 간단한 쿼리. 그것은 무거운 것으로 밝혀졌습니다 (에서
스크립트 및 기타 데이터) Apache 프로세스는 대기하는 데 많은 시간을 소비합니다(수신할 때 먼저
요청한 후 응답을 보낼 때) 서버 메모리를 낭비합니다.
이 문제에 대한 해결책은 처리 작업을 분산하는 것입니다.
두 사람 사이의 요청 다양한 프로그램- 즉. 프론트엔드와
백엔드 경량 프런트엔드 서버는 정적 콘텐츠를 제공하는 작업을 수행하고 나머지는
요청은 형성이 수행되는 백엔드로 리디렉션(프록시)됩니다.
페이지. 느린 클라이언트를 기다리는 것도 프런트엔드에서 처리합니다.
멀티플렉싱(하나의 프로세스가 여러 클라이언트에 서비스를 제공하는 경우 -
예를 들어 nginx 또는 lighttpd와 같이 작동하면 대기 시간이 거의 없습니다.
소송 비용.
사이트의 다른 구성 요소 중에서 데이터베이스에 주목해야 합니다.
일반적으로 기본 시스템 데이터를 저장합니다. 여기서 가장 인기 있는 것은 다음과 같습니다.
무료 DBMS MySQL 및 PostgreSQL. 스토리지는 종종 별도로 할당됩니다.
그림이 포함된 바이너리 파일(예: 기사 삽화)
사이트, 아바타, 사용자 사진) 또는 기타 파일.
따라서 우리는 다음으로 구성된 아키텍처 다이어그램을 받았습니다.
여러 구성 요소.
일반적으로 사이트 수명이 시작될 때 아키텍처의 모든 구성 요소는
같은 서버에 위치합니다. 부하에 대한 대처가 중단되면
간단한 해결책이 있습니다. 가장 쉽게 분리된 부품을 다른 부품으로 옮기는 것입니다.
섬기는 사람. 데이터베이스를 시작하는 가장 쉬운 방법은 데이터베이스를 별도의 서버로 이동하고
스크립트에서 액세스 세부 정보를 변경합니다. 그런데 지금 이 순간 우리는 다음과 같은 상황에 직면해 있습니다.
적절한 코드 아키텍처의 중요성. 데이터베이스로 작업하는 경우
에 제출됨 별도의 모듈, 전체 사이트에 공통 - 그런 다음 매개변수를 수정합니다.
연결이 쉬울 것입니다.
구성 요소를 추가로 분리하는 방법도 명확합니다. 예를 들어 프런트엔드를 별도의 서버로 이동할 수 있습니다. 하지만 일반적으로 프론트엔드
시스템 리소스가 거의 필요하지 않으며 이 단계에서는 제거해도 큰 도움이 되지 않습니다.
생산성 향상. 대부분의 경우 사이트는 성능으로 인해 제한됩니다.
스크립트 - 응답(html 페이지) 생성에 시간이 너무 오래 걸립니다.
따라서 다음 단계는 일반적으로 백엔드 서버를 확장하는 것입니다.
계산 분포
성장하는 사이트의 일반적인 상황 - 데이터베이스가 이미
별도의 머신으로 옮겨지면 프론트엔드와 백엔드의 분할이 완료되고,
그러나 트래픽이 계속 증가하고 백엔드에서 처리할 시간이 없습니다.
요청. 이는 계산을 여러 곳에 분산해야 함을 의미합니다.
서버. 이는 쉽습니다. 두 번째 서버를 구입하여 설치하면 됩니다.
백엔드가 작동하는 데 필요한 프로그램과 스크립트가 포함되어 있습니다.
그런 다음 사용자 요청이 분산되었는지 확인해야 합니다.
(균형) 수신된 서버 간에. 에 대한 다른 방법으로균형을 맞추다
아래에서 논의하겠지만 지금은 이 작업이 일반적으로 프런트엔드에서 수행된다는 점을 참고하세요.
요청을 균등하게 분배하도록 구성됩니다.
서버.
모든 백엔드 서버가 올바르게 작동할 수 있는 것이 중요합니다.
요청에 응답합니다. 이를 위해서는 일반적으로 각자가 함께 작업해야 합니다.
동일한 최신 데이터 세트. 모든 정보를 하나의 파일에 저장한다면
데이터베이스가 있으면 DBMS 자체가 제공합니다. 나누는그리고 데이터 일관성.
일부 데이터가 서버에 로컬로 저장된 경우(예: PHP 세션
클라이언트), 그런 다음 공유 저장소로 전송하는 것을 고려해야 합니다.
복잡한 요청 분배 알고리즘.
작업을 여러 서버에 분산시킬 수 있을 뿐만 아니라
스크립트뿐만 아니라 데이터베이스에서 수행되는 계산도 포함됩니다. DBMS가 많은 성능을 발휘하는 경우
서버 CPU 시간을 차지하는 복잡한 쿼리는 여러 개를 생성할 수 있습니다.
다른 서버에 있는 데이터베이스 복사본. 이로 인해 동기화 문제가 발생합니다.
변경 시 데이터 및 여러 접근 방식을 여기에 적용할 수 있습니다.
- 동기화 애플리케이션 수준에서. 이 경우 우리의
스크립트는 데이터베이스의 모든 복사본에 변경 사항을 독립적으로 기록합니다.
데이터의 정확성에 대한 책임). 아니다 최선의 선택왜냐하면 그는
구현 시 주의가 필요하며 오류에 대한 내성이 매우 높습니다. - 복제- 즉, 자동 복제
한 서버의 변경 사항은 다른 모든 서버에 영향을 미칩니다. 보통 언제
복제를 사용할 때 변경 사항은 항상 동일한 서버에 기록됩니다. 이를 마스터라고 하고 나머지 복사본을 슬레이브라고 합니다. 대부분의 DBMS는
복제 구성을 위한 내장 또는 외부 도구. 구별하다
동기 복제 - 이 경우 데이터 변경 요청이 대기합니다.
데이터가 모든 서버에 복사될 때까지만 성공적으로 완료되고 비동기식으로 완료됩니다. 이 경우 변경 사항은 다음에서 슬레이브 서버로 복사됩니다.
지연되지만 쓰기 요청이 더 빨리 완료됩니다. - 다중 마스터복제. 이 접근 방식은 비슷합니다.
이전 것이었지만 여기서는 액세스하지 않고도 데이터를 변경할 수 있습니다.
하나의 특정 서버가 아닌 데이터베이스의 모든 복사본에 연결됩니다. 그와 동시에 변화도
동기식 또는 비동기식으로 다른 복사본으로 전송됩니다. 때때로 이 계획은 다음과 같이 불립니다.
"데이터베이스 클러스터"라는 용어.
서버에 시스템을 배포하는 데는 다양한 옵션이 있습니다.
예를 들어 하나의 데이터베이스 서버와 여러 개의 백엔드(매우
일반적인 구성표) 또는 그 반대 - 하나의 백엔드와 여러 데이터베이스. 규모를 확장하면 어떨까요?
백엔드 서버와 데이터베이스가 모두 있는 경우 백엔드와 데이터베이스 복사본을 결합할 수 있습니다.
차 한 대. 어쨌든 복사본이 여러 개 있으면 바로
어떤 서버에서든 서버 간에 올바르게 배포하는 방법에 대한 문제가 발생합니다.
짐.
밸런싱 방법
요청을 처리할 수 있는 여러 서버(http, 데이터베이스 등 어떤 목적으로든)를 만들어 보겠습니다. 전에
우리는 그들 사이에 작업을 분배하는 방법, 어떤 것이 무엇인지 알아내는 방법에 대한 과제에 직면해 있습니다.
서버가 요청을 보내나요? 요청을 배포하는 방법에는 크게 두 가지가 있습니다.
- 밸런싱 유닛. 이 경우 클라이언트는 다음 중 하나에 요청을 보냅니다.
그에게 알려진 고정 서버가 있고 이미 요청을 다음 중 하나로 리디렉션합니다.
작동하는 서버. 일반적인 예는 하나의 프런트엔드와 여러 개의 프런트엔드가 있는 사이트입니다.
요청이 프록시되는 백엔드 서버입니다. 그러나 "클라이언트"는
우리 시스템 내부에 있어야 합니다. 예를 들어 스크립트는 다음으로 요청을 보낼 수 있습니다.
요청을 DBMS 서버 중 하나에 전달하는 데이터베이스 프록시 서버로.
밸런싱 노드 자체는 별도의 서버와 하나의 서버 모두에서 작동할 수 있습니다.
작업 서버에서.이 접근 방식의 장점은 다음과 같습니다.
클라이언트는 시스템의 내부 구조, 즉 수량에 대해 아무것도 알 필요가 없습니다.
서버, 해당 주소 및 기능에 대해 -
밸런서 그러나 단점은 밸런싱 유닛이 단일이라는 것입니다.
시스템 장애 지점 - 장애가 발생하면 전체 시스템이 중단됩니다.
작동 불능. 또한 부하가 심한 경우 밸런서가 정지할 수도 있습니다.
작업에 대처하므로 이 접근 방식이 항상 적용 가능한 것은 아닙니다. - 클라이언트 측 밸런싱. 우리가 피하고 싶다면
단일 실패 지점, 서버 선택을 위임하는 대체 옵션이 있습니다.
클라이언트 자신에게. 이 경우, 고객은 당사의 내부 구조에 대해 알아야 합니다.
접속할 서버를 올바르게 선택할 수 있는 시스템입니다.
의심할 여지 없는 이점은 실패 지점이 없다는 것입니다.
클라이언트가 다른 서버에 연락할 수 있게 됩니다. 그러나 이것의 가격은
클라이언트 로직이 더 복잡해지고 균형 유연성이 떨어집니다.
물론 이러한 접근 방식을 조합한 방법도 있습니다. 예를 들어,
DNS 밸런싱과 같은 잘 알려진 부하 분산 방법은 다음을 기반으로 합니다.
사이트의 IP 주소를 결정할 때 클라이언트는
여러 개의 동일한 서버 중 하나의 주소입니다. 따라서 DNS는 다음과 같은 역할을 합니다.
클라이언트가 "분배"를 받는 균형 노드의 역할. 하지만
DNS 서버의 구조 자체가 다음으로 인한 장애 지점이 없음을 의미합니다.
복제 - 즉, 두 가지 접근 방식의 장점이 결합됩니다. 물론, 이것은
균형 조정 방법에는 단점도 있습니다. 예를 들어 이러한 시스템은 동적으로 수행하기 어렵습니다.
재건축.
사이트 작업은 일반적으로 하나의 요청으로 제한되지 않습니다.
따라서 디자인할 때 순차적 쿼리가 가능한지 여부를 이해하는 것이 중요합니다.
클라이언트는 다른 서버에서 올바르게 처리되어야 합니다. 그렇지 않으면 클라이언트가
사이트 작업을 하는 동안 하나의 서버에 묶여 있습니다. 이는 다음과 같은 경우에 특히 중요합니다.
사이트는 사용자 세션에 대한 임시 정보를 저장합니다(이 파일에는
이 경우 무료 배포도 가능하지만 저장이 필요합니다.
세션(모든 서버에 공통된 저장소). 방문자를 "바인딩"
IP 주소로 특정 서버를 지정할 수 있습니다(단, 변경될 수 있음).
또는 쿠키(서버 식별자가 미리 기록되어 있음) 또는 심지어
원하는 도메인으로 리디렉션하기만 하면 됩니다.
반면에 컴퓨팅 서버는 동등한 권리를 갖지 못할 수도 있습니다.
어떤 경우에는 반대로 별도의 서버를 할당하는 것이 유리할 수도 있습니다.
한 가지 유형의 요청을 처리하고 수직 분할을 얻습니다.
기능. 그런 다음 클라이언트 또는 균형 노드는 서버를 선택합니다.
접수된 요청 유형에 따라 다릅니다. 이 접근 방식을 통해 우리는
다른 사람의 중요한(또는 그 반대, 중요하지는 않지만 어려운) 요청입니다.
데이터 배포
우리는 계산을 분배하는 방법을 배웠습니다.
출석은 우리에게 문제가 되지 않습니다. 하지만 데이터의 양은 계속해서 증가하고 있으며,
이를 저장하고 처리하는 것이 점점 더 어려워지고 있습니다. 즉, 이제 구축할 시간이 되었음을 의미합니다.
분산 데이터 저장. 이 경우 우리는 더 이상 하나 또는
데이터베이스의 전체 복사본을 포함하는 여러 서버. 대신, 데이터
여러 서버에 분산됩니다. 어떤 배포 방식이 가능한가요?
- 수직분포(수직 분할) - 가장 간단한 경우
개별 데이터베이스 테이블을 다른 서버로 전송하는 것을 나타냅니다. ~에
이 경우 다른 서버에 액세스하려면 스크립트를 변경해야 합니다.
다른 데이터. 한도 내에서 각 테이블을 별도의 서버에 저장할 수 있습니다.
(실제로는 이것이 유익할 것 같지는 않지만). 분명히 이것으로
배포하면 다음의 데이터를 결합하는 SQL 쿼리를 만드는 능력이 상실됩니다.
서로 다른 서버에 있는 두 개의 테이블. 필요한 경우 구현할 수 있습니다.
애플리케이션에서 로직을 병합하지만 DBMS만큼 효율적이지는 않습니다.
따라서 데이터베이스를 파티셔닝할 때에는 테이블 간의 관계를 분석해야 하며,
가능한 한 독립적인 테이블로 배포합니다.더 복잡한 경우
수직 기반 분포는 부분적으로 하나의 테이블을 분해하는 것입니다.
해당 열 중 일부는 한 서버에 있고 일부는 다른 서버에 있습니다. 이 기술
덜 일반적이지만 예를 들어 작은 항목을 분리하는 데 사용할 수 있습니다.
거의 사용되지 않는 대량의 데이터에서 자주 업데이트되는 데이터입니다. - 수평적 분포(수평 분할) - 다음으로 구성됩니다.
한 테이블의 데이터를 여러 서버에 분산합니다. 실제로,
각 서버는 동일한 구조의 테이블을 생성하고 저장합니다.
특정 데이터 조각. 다양한 방법으로 서버 전체에 데이터를 배포할 수 있습니다.
기준: 범위별(ID가 있는 레코드< 100000 идут на сервер А, остальные - на сервер Б), по списку значений (записи типа «ЗАО» и «ОАО» сохраняем на сервер
A, 나머지 - 서버 B) 또는 특정 필드의 해시 값
기록. 데이터를 수평으로 분할하면 무제한으로 저장할 수 있습니다.
그러나 레코드 수가 많으면 선택이 복잡해집니다. 가장 효과적인 선택 방법
어떤 서버에 저장되어 있는지 알려진 경우에만 기록합니다.
올바른 데이터 배포 방식을 선택하려면 다음을 수행해야 합니다.
데이터베이스의 구조를 주의 깊게 분석하십시오. 기존 테이블(그리고 아마도
개별 필드) 기록에 대한 접근 빈도, 빈도별로 분류할 수 있습니다.
업데이트 및 관계(여러 항목 중에서 선택해야 함)
테이블).
위에서 언급했듯이 사이트에는 데이터베이스 외에도 종종 다음이 필요합니다.
바이너리 파일을 위한 저장소. 분산 파일 저장 시스템
(실제로 파일 시스템)은 두 가지 클래스로 나눌 수 있습니다.
- 일하고 있는 수준에서 운영 체제
. 더욱이,
응용 프로그램에서 이러한 시스템의 파일 작업은 일반적인 작업과 다르지 않습니다.
파일. 서버 간의 정보 교환은 운영 체제에 의해 처리됩니다.
그러한 예로 파일 시스템우리는 오랫동안 알려진 것을 인용할 수 있습니다
NFS 제품군 이하로 알려져 있지만 그 이상 현대 시스템광택. - 구현됨 애플리케이션 수준에서분산
저장소는 정보 교환 작업이 자체적으로 수행됨을 의미합니다.
애플리케이션. 일반적으로 스토리지 작업을 위한 기능은 다음 위치에 배치됩니다.
별도의 도서관. 이러한 스토리지의 놀라운 사례 중 하나는 MogileFS입니다.
LiveJournal의 제작자가 제작했습니다. 또 다른 일반적인 예는
WebDAV 프로토콜 및 이를 지원하는 저장소입니다.
데이터 배포는 데이터 배포뿐만 아니라
저장 문제일 뿐만 아니라 부분적으로는 부하 분산 문제도 있습니다.
서버에 있는 레코드가 적으므로 처리 속도가 더 빠릅니다.
계산과 데이터를 분산시키는 방법을 결합하면 다음과 같은 구축이 가능합니다.
잠재적으로 무제한으로 확장 가능한 아키텍처
모든 양의 데이터와 로드.
결론
말한 내용을 요약하기 위해 간단한 논문 형식으로 결론을 공식화하겠습니다.
- 두 가지 주요(및 관련) 확장 과제는 컴퓨팅 배포와 데이터 배포입니다.
- 일반적인 사이트 아키텍처에는 역할 분리와
프런트엔드, 백엔드, 데이터베이스 및 때로는 파일 저장소가 포함됩니다. - 데이터 양이 적고 로드가 많은 경우 다음을 사용하세요.
데이터베이스 미러링 - 동기 또는 비동기 복제 - 대용량 데이터의 경우 데이터베이스 분산 필요 - 분할
수직으로든 수평으로든 - 바이너리는 분산 파일 시스템에 저장됩니다.
(OS 수준 또는 애플리케이션에서 구현됨) - 균형 조정(요청 분산)은 균일하거나
기능별로 나누어집니다. 밸런싱 노드를 사용하거나 클라이언트 측에서 - 올바른 방법 조합을 사용하면 모든 하중을 견딜 수 있습니다.)
연결
흥미로운 영어 사이트와 블로그에서 이 주제를 계속 공부할 수 있습니다.
