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