확장성, 유용한 확장성
Dino Esposito
다음 문서는 MSDN 온라인 음성: Diving Into Data Access 컬럼에서 발췌한 것입니다.
여러
해 전부터 공식적 모임석상인지 또는 우연히 엿들었든지 간에 확장성이라는 단어를 수 없이 많이 들었습니다. "어떻게 확장성을 증대시킬 수
있을까?", "확장성 개념에 접근하기에 충분합니까?", 그리고 "중간 계층에 더 많은 확장성이 필요합니다."
확장성, 유용한 확장성. 그러면 확장성이란 무엇인가?
확장성이 무엇이든 간에 확장성이란 논점에 초점을 맞추려고 합니다.
또한 분산 시스템의 원리 및 기술을 설명하기 위해 많은 학술 서적에서 확장성이란 단어가 광범위하게 쓰인 것을 보았습니다. "확장성은 탁월한
설계에 있어서 결정적인 요소입니다."
확장성, 유용한 확장성. 확장성이란 대체 무엇인가?
최근에 분산 시스템 환경에서 모든 종류의 소트트웨어 기술의 기능을 확인하는 "도구"로서 확장할 수 있는이라는 용어가 대두되었습니다. 따라서
확장성에 대해 면밀히 검토해 볼 필요가 있습니다. 여기에 문제점이 있습니다. 확장성의 궁극적인 의미는 무엇입니까? 그리고 오늘날 데이터베이스
서버 및 하드웨어의 컨텍스트에서는 어떤 의미가 있습니까?
확장성의 장점
추상적으로 확장성의 특성을 사용하여 시스템을 향상시키는 두 가지 기본 방식이 있습니다. 그 중 한 가지 방식은 설계 수준에서 시스템을
논리적으로 최적화하는 것입니다. 모든 소프트웨어 도구 및 인프라 요소로부터 독립적으로 생각해보고 물리적으로 구체화해보십시오. 실용적인 측면에서,
어디서나 실행 가능한 효과적인 병렬 처리를 개발하여 병목 현상 및 중대한 리소스의 영향을 최소화함에 그 목적이 있습니다.
두 번째 접근 방식은 완전히 정반대입니다. 여러분은 특정한 하드웨어 및 소프트웨어의 기본 기능에 대한 특권이 제외되고 솔루션 및 개발에
중요하지 않은 역할을 부여받았습니다. 따라서 이러한 작업을 처리하기 위해 선택한 도구에 대한 확장성 및 상호 운용성의 책임이 없습니다.
그런데 전자의 접근법은 확장성이란 개념은 거의 무시되고 성능 및 견고성에 특히 관심있었던 인터넷 이전 시대부터 여러 해 동안 사용되어
왔습니다. (사실대로 말하자면 광범위한 인터넷 연결이 없었던 것이 상대적인 문제였습니다.)
여러 해 전에 여러 가지 기능을 포함하는 제한된 제공 및 사용 가능한 통합된 솔루션의 출현으로 데이터베이스 구조 및 다양한 작업에 대한
전산 비용에 중점을 두면서 설계 문제에 초점이 맞추어졌습니다.
이러한 하드웨어 독립적인 확장성 비전은 오늘날 무엇보다 중요한 요소로 자리잡았으며 상대적으로 저렴하고 강력한 하드웨어의 개발로 인해 최적화
및 설계 효율은 전체적인 프로젝트 관리 우선 순위에서 2차적 단계로 전락했습니다.
계산 복잡도의 핵심 규칙은 가장 속도가 빠른 알고리즘이 보다 빠른 하드웨어를 완전히 이용하는 것입니다. 여기에도 확장성이 필요하다는 것을
유념하십시오.
성장 요소
일반적인 면에서 보면 클라이언트 증가에 따라 성능이 대체로 향상되지 않은 경우 확장성은 시스템을 관리하는 기능이라 할 수 있습니다. 따라서
확장성은 단순하면서도 세련된 개념과 비슷합니다.
그러나 확장성은 추상적일 수도 있습니다. 불행하게도 프로그래밍 방식으로 전환하거나 직접적인 제어를 할 수 있는 시스템의 영역이 아닙니다.
반대로, 모든 다른 특성의 조합, 전체적인 설계와 구현 및 모델간의 상호 작용에서 파생된 시스템 특성입니다.
분산 시스템의 기본 확장성 수준은 모니터링 또는 분석 도구로 쉽게 검색할 수 없습니다. 반면, 일종의 제한된 확장성의 간접적인 증거를
구성하는 여러 가지 구현 측면(수 많은 중요한 리소스, 병목 설계, 필요한 작업 및 과도한 직렬화 작업)이 있습니다.
그러나 실제 제품 시나리오에서 시스템에 대한 장력 테스트를 하지 않으면 그 시스템은 확장성을 기대할 수 없습니다.
확장성은 성능과도 연관이 있으며 시스템이 잘 만들어지고 적합한 스키마를 적용하는 경우에는 해당이 없습니다.
어떻게 확장성과 같이 볼 수 없는 시스템 특성이 성능에 있어서 중요한 요소가 되었는지 알아보는 것도 흥미로운 일입니다. 앞으로 시스템이
어떻게 발전하든지 간에 전산 작업 비용을 염두에 두고 구성 요소를 설계하십시오.
확장성은 시스템 성장에 영향을 미치는 요소입니다. 간단히 말하면 성장이 필요한 시스템은 현재 성능이 예상되는 사용자 수에 부합하지 못하는
시스템입니다. 어떻게 이런 시스템의 성능을 구조적으로 향상시킬 수 있습니까? 보다 강력한 하드웨어 또는 보다 좋은 하드웨어 및 소프트웨어의
사용을 하는 것이 간단한 방법이긴 합니다.
현재 이러한 두 가지 옵션은 판매를 촉진하는 면이 강하다고 할 수 있습니다. 하드웨어 중심 접근 방법을 Scaling Up이라고 하고,
책략적으로 하드웨어와 소프트웨어를 조합한 것을 Scaling Out이라고 합니다.
시스템 성장을 제어하려면 Scaling Up 또는 Scaling Out이 필요합니다. 그러나 확장하기 위해서는
시스템 기능을 유지 관리해야 합니다.
확장성, 유용한 확장성. 이것이 가장 적합한 정의입니까?
Scaling Up
시스템을 확장한다는 것은 기본적으로 보다 강력한 새 하드웨어 시스템의 토대에서 모든 것을 마이그레이션한다는 것을 의미합니다. 새 시스템이
준비되면 테이블 및 응용 프로그램을 백업하고 온라인으로 이동하고 기존 코드 및 시스템 조직에 대한 영향을 최소화합니다.
시스템 확장 작업이 쉽지는 않습니다. Scaling Up에는 주의가 필요한 두 개의 포인트로 된 영역이 있습니다. 맨 먼저, Scaling
Up하는 시스템에는 실패한 하나의 포인트가 있으며 결국 일종의 하드웨어 제한을 받게 됩니다. Scaling Up을 수행하면 보다 강력한 시스템이
되므로 서비의 처리 능력을 증대시킬 수 있습니다. 현재의 쟁점 밖에 있는 사항이지만 하드웨어 하나의 처리 능력이 증대되어도 언젠가는 최대 물리적
임계값에 도달합니다.
둘째, 이러한 최대 제한 접근법은 시간적(지정한 제한 범위를 넘어 기술 개발에 여러 해가 소요됩니다.)으로나 전력 소모, 사무실 공간,
가격 측면 등에서 상당한 비용이 필요합니다.
따라서, Scaling Up은 기존 구조에 제한된 영향을 끼치므로 고려해야할 첫 번째 옵션입니다.
Scaling Out
Scaling Out은 전체적으로 시스템의 처리 능력을 증가시키므로 서버처럼 동작하는 단일 시스템 처리 능력의 증가와는 정반대입니다.
Scaling Out 시스템은 본질적으로 모듈 형식으로 되어 있으며 컴퓨터 클러스터에 의해 구성됩니다. 시스템을 Scaling Out한다는 것은
하나 이상의 컴퓨터를 네트워크에 추가한다는 의미입니다.
Scaling Out을 수행하고 고도로 분할된 환경에서는 더 추상적이고 하드웨어에 독립적인 처리 능력의 개념을 적용해야 합니다. 처리
능력의 총량은 노드상에서 수행되는 데이터 및 응용 프로그램 파티션으로 조정되는 각 컴퓨터에 대한 물리적 속도의 총량입니다.
Scaling Out은 시스템의 성장에 제한이 없습니다. 분명히 이것은 장점입니다. 하지만 Scaling Out은 재설계 및 재구현에
있어서 막대한 작업을 필요로 합니다. Scaling Out 요구 사항을 수행하기 위해 재심사하고 재구성해야 하는 단일 서버 논리에 따라 시스템이
결정됩니다.
여러 DBMS 서버에서 어떻게 데이터를 분할할 것인지 결정해야 합니다. 데이터에 대한 응용 프로그램 경로를 적합한 실행 계획을 통하여
신중하게 최적화해야 합니다. 사용자 활동에 대한 순향적이고 빈번한 분석은 순환 과정동안 시스템의 상태를 최적으로 유지하는 데 매우 중요합니다.
그리고 가상적으로 무한한 시스템을 보유할 수 있으므로, 증가하는 사용자 및 작업 부하 수에 부합하는 데이터 계층 뿐만 아니라 중간 계층에
프로세스 리소스를 추가할 수 있습니다.
확장성있는 시스템의 중요한 요소는 사용자가 얼마나 많이 증가하는지 예측하는 것이 아닙니다. 정말로 고려해야 할 점은 얼마나 빨리 사용자
수가 증가하는지 예측하는 것입니다. 사용자 수에 대한 상대적인 증가는 절대적 사용자 수보다 훨씬 중요합니다.
현재 사용자 수가 백명이고 시간이 지나면서 그 수가 배가 될지도 모르는 시스템을 설계하는 것이 일억명의 고정 사용자가 사용하고 있는
시스템을 설계하는 것보다 훨씬 어렵습니다. 여기서 확장성을 위해 필요한 것은 특히 산업 기반 및 전자 상거래 웹 응용 프로그램 분야에서
효과적입니다. 왜냐하면 이러한 시스템 형태는 갑작스런 사용자 증가에 대처해야 하기 때문입니다.
SQL Server 2000를 Scaling Out하는 방법
Scaling Up은 상대적으로 구현하기 쉽고 규모가 적은 데이터 및 사용자 시스템에서는 상대적으로 비용이 저렴하다는 것을 확인했습니다.
그리고 소프트웨어 관점에서 Scaling Out 기술을 적용하는 것은 해볼만한 일입니다. 백 엔드 계층에서 동작하는 소프트웨어 제품을 사용하지
않고는 올바르게 Scaling Out을 수행할 수 없습니다.
Scaling Out 모델은 클러스터링 모델로 COM+ 및 Windows® 2000에서 찾을 수 있습니다. 비지니스 계층의 모든 서버에는
COM+ 구성 요소의 동일한 복사본이 있습니다. 백그라운드에서 운영하는 Windows 2000 로드 균형 조정 서비스는 개별적인 작업 부하에
따라 구성 요소에 대한 새 요청 처리를 담당합니다.
응용 프로그램 관점에서 보면 COM+ 구성 요소 집합인 단일 엔티티입니다. 기본적인 로드 균형 조정 역할을 무시하고 구성 요소가 수행하는
여러 다른 서버의 수에 상관없이 구성 요소를 코드화합니다. 여기서 Scaling Out은 적합한 구성 요소 집합이 설치되어 완전히 구성된 새
Windows 2000 Server를 추가하는 것처럼 쉽습니다.
이러한 클러스터링 모델에서는 전혀 다른 두 개의 엔티티인 응용 프로그램의 구성 요소 및 시스템의 로드 균형 조정이 서로 작용합니다. 이와
같은 모델은 데이터 계층에 쉽게 적용할 수 없습니다. 사실상 DBMS가 유일한 소프트웨어 엔티티입니다.
SQL Server 2000은 연합된 서버라는 다른 클러스터링 모델을 지원합니다. 즉, 네트워크는 모든 SQL Server를 운영하는
서버의그룹을 응용 프로그램에 대해 보이게 합니다. 다른 테이블 및 다른 설정으로 되어 있는 SQL Server의 모든 공용 인스턴스는 자율적으로
작동하며 개별적으로 관리됩니다.
DBMS 작업 부하의 주요한 관점은 해당 데이터입니다. 여러 개의 서버에 데이터를 균등하게 분포해야 하는 것이 응용 프로그램의 기본적인
기능입니다. SQL Server 2000은 서버 자체에서 여러 개의 서버에 물리적으로 분할된 업데이트할 수 있는 데이터 뷰를 지원하는 기능이
내장되어 있습니다.
네트워크를 통해 사용할 수 있는 SQL Server의 여러 인스턴스를 통해 테이블의 범위를 확장할 수 있습니다. 그리고 이 데이터를 필요할
때마다 포장할 수 있습니다. SQL Server 2000의 런타임에서 특별히 지원하는 뷰로서 분할된 뷰를 사용하여 이 작업을 수행합니다.
분할된 뷰
분할된 뷰를 두 개 이상의 서버에서 범위를 확장하는 중요한 테이블인 연합된 테이블에 적용할 수 있습니다. 연합된 테이블은 행 분할이라는
프로세스를 통해 만들어지며 주어진 테이블을 크기가 작은 테이블의 연합으로 나눕니다. 응용 프로그램 측면에서 보면 연합된 테이블은 하나의 통일된
뷰처럼 표시됩니다.
작업 부하를 균형있게 조절하려면 구성원 테이블을 별도의 시스템에 두어야 합니다. 구성원 테이블은 원래의 형식과 동일하지만 각 테이블에는
행의 일부분만 들어있습니다. 구성원 테이블에 어떤 이름이나 부여할 수 있지만, 위치 투명성을 유지하기 위해 본래의 이름을 부여하는 것이
좋습니다.
구성 테이블은 데이터의 부분과 동일한 크기를 포함하기 위해 설계되었습니다. 이 테이블의 특성은 고유하고 업데이트할 수 없는 기본 키
기반에서 수행됩니다. 무결성 및 일관성을 보장하기 위해 레코드가 중복되지 않았는지 확인해야 합니다. 각 구성원 테이블의 CHECK 제약 조건은
기본 방식입니다. 분할 열은 널 또는 계산된 열을 허용하지 않습니다.
분할된 뷰는 동일한 테이블에 구조적으로 적용하는 분산 SELECT 구문에 관여하는 일반 뷰이며 UNION ALL 절을 통해 데이터를
통합합니다.
CREATE VIEW MyView AS
SELECT * FROM Server1.Database.Owner.MyTable
UNION ALL
SELECT * FROM Server2.Database.Owner.MyTable
UNION ALL
SELECT * FROM Server3.Database.Owner.MyTable
UNION ALL
SELECT * FROM Server4.Database.Owner.MyTable
이러한 분산 뷰는 관련된 해당 서버에서 만들어져야 합니다. 각 서버는 연결된 서버로서 다른 서버가 볼 수 있어야 합니다. 그리고 지연
스키마 유효성 옵션이 참으로 설정되어 있어야 합니다. 이러한 속성은 연결된 원격 테이블의 스키마가 검사되는 여부를
결정합니다. 속성을 참으로 설정하면 SQL Server는 검사를 생략하므로 성능이 향상됩니다. 특별한 경우로서 성능의 지연이 미묘한 부작용을
일으키지는 않습니다.
분할된 뷰는 SQL Server 7.0에서 처음 소개되었습니다. 그리고 SQL Server 2000 및 두
가지 중요한 개발로 인해 시스템을 Scaling Out하기 위한 중요한 도구로 발전되었습니다.
SQL Server 2000의 분할된 뷰는 업데이트할 수 있으며 쿼리 최적화 프로그램에서 최적화되며 교차 서버 처리에 대한 필요를
최소화합니다. 연합된 테이블의 주된 장점은 사용 가능한 서버 간의 작업 부하를 균형 조정하는 것입니다. 한 예로 모든 서버가 로컬로 할당된
작업을 수행할 수 있습니다.
분할된 뷰는 다음과 같은 조건에서 자동으로 업데이트할 수 있습니다.
- UNION ALL절을 사용하여 병합된 개별적인 SELECT 문의 결과로 형성된 경우
- 각 SELECT문이 단일 테이블에서 수행되는 경우(따라서 JOIN문 사용은 허용되지 않음)
- 테이블이 로컬 또는 연결된 테이블일 경우
- 테이블에 타임스탬프 열이 없는 경우
연결된 테이블은 완전히 인증된 이름(서버, 데이터베이스, 소유자, 테이블 이름 등), OPENROWSET 또는
OPENDATASOURCE 기능을 사용하여 참조되어야 합니다.
업데이트할 수 있는 분할된 뷰에서 수행하는 INSERT, UPDATE 및 DELETE 문은 여러 제약 조건을
수행할 수 있어야 합니다. 예를 들어 테이블에 ID 열이 있는 경우 새 행을 삽입할 수 없습니다. DEFAULT 제약 조건 등으로
모든 열을 지정해야 합니다. 뷰가 자체 조인되어 있거나 다른 구성원 테이블과 조인되어 있는 경우 업데이트 및 삭제는 허용되지 않습니다.
Scaling Out 실례
SQL Server 2000에서 제공하는 클러스터링 모델은 일반인 대상이 아니라, 고수준 OLTP 엔터프라이즈 시스템 및 웹 응용
프로그램을 지원하기 위해 특별히 설계되었습니다.
이 모델을 수행하려면 데이터의 분할이 필요하며 파티션은 논리 스키마를 따라야 합니다. 관련된 모든 데이터는 같은 서버에 상주해야 하며
데이터는 자체적으로 논리 분할에 포함되어야 합니다.
해당 데이터의 정확한 파악은 필수적입니다. 또한 데이터 모양을 많이 변경해서는 안됩니다. 변경할 계획이라면 미리 모양을 결정한 후 해당
파티션이 인식할 수 있도록 준비합니다.
동일한 노드상의 관련된 데이터는 실행 가능해야 합니다. 그렇지 않으면 로드 균형 조정 전략으로 얻은 네트워크 대기 시간이 그 만큼 빨리
손실됩니다.
아주 완벽하게 데이터 파티션 작업을 완료했다고 하더라도 일부분을 마친 것에 불과합니다. 데이터를 선택한 클러스터에 물리적으로 이동, 백업
조정, 솔루션 모니터링 등 수행해야 할 작업이 남아 있습니다.
Scaling Out 기술은 구현하기가 어려우며 Scaling Up을 수행하는 것보다 훨씬 복잡한 접근 방법이 필요합니다. 설계 문제는
단일 엔티티로 클러스터를 Scaling Out하는 것을 관리하는 데 필요한 특별한 도구의 부족과 같은 장애점으로 집약됩니다. 이러한 도구의
일부는 코드명 Yukon인 SQL Server 다음 버전의 일부로 제공될 계획입니다.
Scaling Out 확장성은 가망있고 흥미롭게 보이지만, 대부분의 경우 단일 서버상에서 Scaling Up을 수행하는 것이 아직까지는
안전한 것으로 알려져 있습니다.
Scaling Up 또는 Scaling Out을 수행하는 방법
제3세대 웹 서비스 개념으로 하드웨어 측면에서 매우 많은 요구 사항을 필요합니다. 먼저 Scaling Up 또는 Scaling Out에
대해 설명합니다.
Scaling Up은 단일 하드웨어 시스템의 처리 능력을 증대시킵니다. Scaling Out은 규모가 점차로 증가하는 다양하게 연결된
소규모 시스템을 대상으로 합니다.
Scaling Up 시스템은 내재된 결함성 및 특정 임계값으로 업데이트 불가능 등의 오류가 발생합니다. 또한 전력 소모, 공간 및 가격
면에서도 비용이 많이 듭니다. 반면, 시스템을 Scaling Up하는 것은 백업 및 복구를 하는 것처럼 쉽습니다.
시스템을 Scaling Out하면 보다 향상된 견고성, 확장성 및 전체적인 비용 절감 효과가 있습니다. 그리고 수 십대 또는 수 백대의
시스템을 처리하는 것 이상으로 단일 시스템을 처리할 수 있습니다.
그러나 이 두 접근 방법의 장점과 단점은 다소 상대적이며 완전히 특정 프로젝트에 따라 다릅니다.
Scaling Up 또는 Scaling Out은 시스템의 특성을 기반으로 합니다. Scaling Out은 데이터 액세스에 대한 비용을
지불하는 별도의 멀티프로세서 시스템에서 운영되는 SQL Server의 단일 인스턴스인 경우 권장됩니다. 이것은 웹 그룹 외의 확장성 모델입니다.
그러나 웹 그룹 Scaling Out 모델은 수평적 확장성을 고려할 수 있습니다. 많은 양의 동시 데이터(예를 들어 OLTP 시스템)를
처리할 경우 서로 작용하는 여러 서버가 필요합니다. 이 경우 해당 데이터를 재구성해야 합니다. 이것은 막대한 양의 작업이기 때문에 단순히
계획해서 수행할 수 없습니다. 프로젝트를 시작하기전에 시스템이 이와 같은 "대량의 도약"을 수행할 준비가 되어 있는지 확인해야 합니다. OLTP
시스템일 경우 특히 이 점을 고려해야 합니다.
다시 말해서 Scaling Out은 보다 현실적이며 Scaling Up은 항상 먼저 고려해야 하며 반드시 적합한 이유로 포기해야 합니다.
필수적인 확장성
지금까지 Scaling Out 및 Scaling Up 기술의 이론을 설명했지만 여기에 두 가지 고려 사항이 있습니다.
그러나 알고리즘의 개선, 쿼리 실행 계획 최적화 또는 병목 현상을
발견하고 제거하는 것보다 속도가 빠른 하드웨어를 도입하는 것이 더 신속한 방법이기는 합니다.
대화 상자: ADO Rock'n'Roll
누군가 "ADO와 ADO.NET의 차이점이 무엇입니까?"라고 물었을때, 저자는 장점과 단점을 완전히 아는 것은 아니지만
ADO.NET은 또 다른 액세스 계층으로 앞으로 사용하게 될 것이라고 대답했습니다. ADO 코드는 .NET에서 작동된다는 것을 압니다. 하지만
"ADO Rock'n'Roll" 기사는 저자의 확신을 불안하게 했습니다.
처음에는 ADO.NET을 "또 다른 데이터 액세스 계층"으로 정의했습니다. 그러나 검토해본 결과 ADO.NET은 .NET 토대에서 운영되는
데이터 처리 응용 프로그램에 권장되는 방법으로 처음 정의와는 다르게 접근했습니다.
최근 몇년 동안 사용자들은 최적화되고 잘 조정된 RDO 코드를 사용하는 대신 ADO를 애용했습니다. 모든것을 얻었을지는 몰라도 예외적인
결과를 예상하지 못했습니다. 그러나 기능이 뒤떨어진 ADO만 비난을 받았습니다.
이처럼 기능이 뒤떨어진 ADO.NET도 실패한 마이그레이션 프로젝트의 희생양이 될지도 모릅니다. 완벽한 코드는 없지만 시스템 코드는
프로그래머가 작성한 코드 이상입니다. RDO에서 ADO로의 업그레이드는 문제의 여지가 있습니다. 왜 접촉 코드는 ODBC에서 OLE DB 및 더
체계화된 개체 모델로 이동해도 수행이 잘 됩니까?
ADO.NET은 완전히 다른 개녑입니다. ADO.NET은 서버 플랫폼으로서 .NET을 위한 필수적인 선택입니다. ADO.NET은 데이터와
함께 수행하는 일련의 클래스일 뿐입니다.
ADO 사용을 고수할 수는 있지만 .NET에서 COM으로 마샬링할 경우에는 매우 비싼 비용을 지불해야 할지도 모릅니다. ADO.NET에
접근하기 위한 기본적인 방법은 실제 코드를 작성하기 전에 학습하고 제한된 환경에서 수행해 보는 것입니다. ADO로 이동할 때 얼마나 많은
사람들이 이렇게 해봅니까?
오늘날 웹 시대에서 ADO.NET은 ADO보다 적합한 모델입니다. 또한 ADO.NET 개체 모델은 가능한 한 많이 ADO 개념을
적용했습니다. ADO.NET을 시작하는 것은 어렵지 않습니다. 그리고 ADO.NET을 사용하기 위해 개발자들은 많은 새로운 개념을 학습할 필요가
없습니다.
그러나 ADO 방식에서 벗어나야 하며 다른 모델의 각도에서 이해해야 합니다. ADO.NET은 "단지 또 다른 데이터 액세스 계층"에
불과합니다. ADO와 ADO.NET의 선택에 고심할 필요가 없습니다. .NET 플랫폼을 선택할지 안할지가 중대한 결정입니다.
Top of Page
