가용성 및 확장성 향상
많은 응용 프로그램에서 높은 가용성과 높은 읽기 확장성을 모두 제공하는 것은 중요합니다. 복제는 이러한 두 가지를 제공하는 해결 방법에서 주요한 역할을 할 수 있습니다. 일부 응용 프로그램의 경우 복제를 통해 가용성이나 확장성 중 하나를 향상시키는 것이 목표일 수 있습니다. 이러한 영역 중에서 하나만 해결해야 하는 경우 다음 시나리오 중 하나를 고려해 보십시오.
다음 다이어그램에서는 복제를 통해 가용성과 확장성을 향상시키는 두 개의 응용 프로그램을 설명합니다. 이 두 경우에서 다이어그램에 있는 3개의 데이터베이스는 서로 피어이므로 동일한 스키마와 데이터를 포함합니다. 이러한 데이터베이스에 대한 쓰기 작업은 분할되어야 합니다. 예를 들어 데이터베이스에 제품 카탈로그가 포함되어 있는 경우 A-I로 시작하는 제품 이름에 대해서는 첫 번째 데이터베이스, J-R에 대해서는 두 번째 데이터베이스, 그리고 S-Z에 대해서는 3번째 데이터베이스로 업데이트 내용을 전송할 수 있습니다. 그런 다음 업데이트 내용을 다른 데이터베이스로 복제합니다.
첫 번째 다이어그램은 각 웹 및 응용 프로그램 서버가 특정 캐싱 서버의 데이터를 사용하는 구성을 설명합니다. 지정한 사용자에 대한 읽기 및 업데이트 내용은 특정 응용 프로그램 서버로 이동된 다음 특정 캐싱 서버로 이동됩니다. 응용 프로그램 서버가 캐시를 직접 업데이트하므로 중앙 원본 서버는 필요 없습니다. 각 캐시에서의 업데이트 내용은 다른 캐시로 전파됩니다.
.gif "복제를 사용하여 읽기 작업 확장")
두 번째 다이어그램은 지역적으로 분산되어 있으면서 데이터 흐름이 있는 3대의 서버를 보여 줍니다. 각 서버는 읽기 요청을 지원하며 가용성을 향상시킬 수 있습니다.
.gif "여러 위치로 피어 투 피어 복제")
Adventure Works Cycles 예
Adventure Works Cycles는 데이터베이스 개념 및 시나리오를 설명하는 데 사용되는 가상 제조 회사입니다. 자세한 내용은 AdventureWorks 예제 데이터베이스를 참조하십시오.
Adventure Works Cycles는 LA, 런던, 타이베이를 비롯하여 전 세계에 많은 지사를 가지고 있습니다. 고객 주문 정보는 각 위치에서 수집된 다음 다른 위치로 복제됩니다.
주문 정보는 어느 위치에서나 읽을 수 있으므로 런던 지사에 읽기 작업이 너무 많은 경우 내부 응용 프로그램은 이 작업 중 일부를 다른 두 지사로 배포할 수 있습니다.
예를 들어 런던 지사에서 유지 관리를 위해 서버가 다운된 경우 다른 위치에서 주문을 계속 검색할 수 있으므로 런던 지사의 직원들은 계속 데이터를 읽고 입력할 수 있습니다. 런던 서버가 다시 온라인 상태가 되면 다운된 동안 받은 변경 내용이 런던 서버로 전파되므로 최신 내용을 유지하게 됩니다.
이 시나리오의 일반적인 요구 사항
확장성과 가용성을 위해 복제를 사용하는 응용 프로그램의 요구 사항은 일반적으로 다음과 같습니다. 이러한 요구 사항은 적절한 복제 솔루션에서 해결해야 합니다.
시스템에서는 모든 서버에서의 변경을 허용하고 변경 내용을 다른 모든 서버로 복제해야 합니다.
시스템에서는 트랜잭션 일관성을 유지해야 합니다.
시스템의 대기 시간이 짧아야 합니다. 즉, 한 서버에서 수행된 업데이트 내용이 다른 서버로 빠르게 전달되어야 합니다.
시스템의 처리량이 많아야 합니다. 즉, 많은 수의 트랜잭션에 대한 복제를 처리해야 합니다.
복제 처리 시 오버헤드가 최소로 발생해야 합니다.
이 시나리오에 사용할 복제 유형
MicrosoftSQL Server에서는 복제 시스템의 구성 요소를 기술하는 데 게시 관련 산업의 메타포를 사용합니다. 구성 요소에는 게시자, 구독자, 게시 및 아티클과 구독이 포함됩니다.
위의 다이어그램에서 모든 캐시 서버는 게시자와 구독자입니다. 각 서버에 있는 복제 데이터베이스의 모든 데이터는 게시에 포함되며 데이터의 각 테이블은 아티클입니다. 아티클은 저장 프로시저와 같은 다른 데이터베이스 개체일 수도 있습니다. 각 서버는 다른 서버의 게시를 구독하며 스키마와 데이터를 구독으로 받습니다. 시스템 구성 요소에 대한 자세한 내용은 복제 게시 모델 개요를 참조하십시오.
SQL Server는 다양한 응용 프로그램 요구 사항을 위해 스냅숏 복제, 트랜잭션 복제 및 병합 복제와 같은 여러 복제 유형을 제공합니다. 이 시나리오는 이전 섹션에서 설명한 요구 사항을 해결하기에 가장 적합한 피어 투 피어 트랜잭션 복제를 통해 최적으로 구현됩니다. 피어 투 피어 트랜잭션 복제에 대한 자세한 내용은 피어 투 피어 트랜잭션 복제를 참조하십시오.
[!참고]
응용 프로그램이 두 개 이상의 노드에서 동시에 지정한 행을 수정해야 하는 경우 데이터 충돌이 발생할 수 있습니다. 이러한 경우 충돌 처리에 적합한 병합 복제를 사용합니다. 병합 복제에 대한 자세한 내용은 병합 복제 개요를 참조하십시오.
기본적으로 트랜잭션 복제는 다음과 같은 이 시나리오의 주요 요구 사항을 처리합니다.
모든 서버에서 변경 가능
트랜잭션 일관성
짧은 대기 시간
높은 처리량
최소 오버헤드
트랜잭션 복제의 피어 투 피어 옵션을 사용하여 서버는 같은 데이터를 게시하고 구독할 수 있습니다. 피어 투 피어 토폴로지의 모든 노드는 피어입니다. 각 노드는 동일한 스키마와 데이터를 게시하고 구독합니다. 모든 노드에서 변경(삽입, 업데이트 및 삭제)한 다음 해당 변경 내용을 다른 노드로 복제할 수 있습니다.
이 시나리오 구현을 위한 단계
이 시나리오를 구현하려면 우선 게시와 구독을 만든 다음 각 구독을 초기화해야 합니다. 자세한 내용은 아래의 항목을 참조하십시오.
SQL Server Management Studio: 방법: 피어 투 피어 트랜잭션 복제 구성(SQL Server Management Studio)
복제 Transact-SQL 프로그래밍: 방법: 피어 투 피어 트랜잭션 복제 구성(복제 Transact-SQL 프로그래밍)
구독이 초기화되고 피어 간 데이터 흐름이 시작된 후 일반적인 관리 및 모니터링 작업에 대한 정보를 보려면 다음 항목을 참조하십시오.