test

Sun Java Enterprise System 2005Q4 배포 계획 설명서

5장 배포 설계

솔루션 라이프 사이클의 배포 설계 단계 중에 높은 수준의 배포 구조와 낮은 수준의 구현 사양을 설계하고 솔루션을 구현하는데 필요한 일련의 계획과 사양을 준비합니다. 배포 설계 단계에서 프로젝트 승인이 발생합니다.

이 장의 내용은 다음과 같습니다.

배포 설계 정보

배포 설계는 솔루션 라이프 사이클의 논리적 설계와 기술적 요구 사항 단계 중에 생성된 배포 시나리오로 시작합니다. 배포 시나리오에는 솔루션의 논리적 구조와 서비스 품질(QoS) 요구 사항이 포함됩니다. 논리적 구조에서 식별된 구성 요소를 물리적 서버와 기타 네트워크 장치에 매핑하여 배포 구조를 생성합니다. 서비스 품질 요구 사항은 성능과 가용성, 확장성 및 기타 관련 서비스 품질 사양의 하드웨어 구성에 대한 지침을 제공합니다.

배포 구조를 설계하는 것은 반복 프로세스입니다. 일반적으로 서비스 품질 요구 사항을 다시 확인하고 예비 설계를 재점검합니다. 균형 조정 및 소유 비용 문제의 균형을 유지하면서 서비스 품질 요구 사항의 상호 관계를 고려해야 궁극적으로 프로젝트의 비즈니스 목표를 달성할 수 있습니다.

프로젝트 승인

배포 설계 단계 중에 일반적으로 배포 구조를 생성한 이후에 프로젝트 승인이 발생합니다. 배포 구조 및 아래 설명된 구현 사양을 사용하여 배포의 실제 비용을 추정하고 이해 관계자의 승인을 위해 제출합니다. 프로젝트가 승인되면 배포 완료를 위한 계약에 서명하고 프로젝트를 구현하기 위한 자원을 취득하고 할당합니다.

배포 설계 출력

배포 설계 단계 중에 다음과 같은 사양 및 계획을 준비해야 합니다.

배포 설계에 영향을 미치는 요소

일부 요소는 배포 설계 동안 결정에 영향을 줍니다. 고려해야 할 주요 요소는 다음과 같습니다.

배포 설계 방법

배포 계획의 다른 요소와 마찬가지로 배포 설계는 과학일 뿐만 아니라 예술이며 특정 절차와 과정으로는 모두 설명될 수는 없습니다. 성공적인 배포 설계에 기여하는 요소는 과거 설계 경험과 시스템 구조에 대한 지식, 도메인 지식, 응용된 창조적 생각입니다.

배포 설계는 일반적으로 서비스 품질 요구 사항을 충족함과 동시에 성능 요구 사항을 달성하는 것이 중요합니다. 사용하는 전략은 솔루션을 최적화할 수 있도록 설계 결정의 균형 조정을 유지해야 합니다. 사용하는 방법은 일반적으로 다음과 같은 작업을 포함합니다.

프로세서 요구 사항 예상

이 절에서는 배포 설계의 서비스를 지원하는데 필요한 CPU 프로세서와 해당 메모리 수를 예상하기 위한 과정을 설명합니다. 이 절은 예제 통신 배포 시나리오에 대한 예상 과정의 간략한 설명을 포함합니다.

CPU 컴퓨터 성능의 예상은 반복 프로세스로 다음과 같은 사항을 고려합니다.

예상 과정은 다음 단계를 포함합니다. 이 단계의 순서는 중요하지 않으며 단지 최종 결과에 영향을 미치는 요소들을 고려하는 방법을 제공할 뿐입니다.

  1. 시스템에 대한 사용자의 시작점으로 식별된 구성 요소를 위한 기본 CPU 예상 개수를 결정합니다.

    설계 결정의 하나는 CPU를 완전히 또는 부분적으로 로드할 것인지 하는 문제입니다. 완전히 로드된 CPU는 시스템 용량을 최대화합니다. 용량을 증가하려면 유지 보수 비용과 CPU를 추가함으로써 발생할 수 있는 중단 시간을 감수해야 합니다. 일부 경우에는 증가하는 성능 요구 사항을 충족하기 위해 시스템을 추가하도록 선택할 수 있습니다.

    부분적으로 로드된 CPU는 유지 보수 비용을 즉시 감수하지 않고도 초과 성능 요구 사항을 처리할 여지를 줄 수 있습니다. 그러나 사용되지 않는 시스템을 위한 선불 비용이 추가됩니다.

  2. 구성 요소 간의 상호 작용을 고려하여 CPU 예상 개수를 조정해야 합니다.

    논리적 구조의 구성 요소 간 상호 작용을 연구하여 종속 구성 요소로 인한 추가 로드를 결정하십시오.

  3. 특정 사용 사례에 대한 사용 분석을 연구하여 시스템의 최고 부하를 판별하고 최고 부하를 처리할 구성 요소를 조정합니다.

    대부분의 로드를 필요로 하는 가장 과중한 사용 사례로부터 시작하여 각 사용 사례를 계속하며 예상되는 모든 사용 시나리오를 고려했는지 확인합니다.

  4. 보안, 가용성, 확장성 요구 사항을 반영하여 CPU 예상 개수를 조정합니다.

이 예상 과정은 필요한 실제 처리 능력을 판별하기 위한 출발점을 제공합니다. 일반적으로 이 예상치를 기반으로 프로토타입 배포를 만든 다음 예상되는 사용 사례에 대해 정밀한 테스트를 수행합니다. 반복 테스트를 한 후에만 배포 설계를 위한 실제 처리 요구 사항을 판별할 수 있습니다.

프로세서 요구 사항 예상 예

이 절에서는 예제 배포에서 요구되는 처리 능력을 예상하기 위한 한 방법을 보여줍니다. 배포 예는 신원 기반 통신 예 절에서 설명한 대로 약 1,000명에서 5,000명까지의 직원을 가진 중소 기업을 위한 신원 기반 통신 솔루션에 대한 논리적 구조를 기반으로 합니다.

이 예에서 사용한 CPU 및 메모리 수치는 설명을 위한 임의적인 예상치입니다. 이 수치는 이론적인 예가 기반으로 하는 임의적인 데이터를 기반으로 합니다. 다양한 요소에 대한 철저한 분석은 프로세서 요구 사항 예상에 필수적입니다. 이 분석은 다음과 같은 정보를 포함하지만 여기에 제한되지는 않습니다.

주의 – 주의 –

이 예에서 나타난 정보는 시스템을 설계할 때 사용할 수 있는 과정을 보여 주는 것 이외에 특정 구현 정보를 나타내지는 않습니다.

사용자 시작점에 대한 기본 CPU 예상치 결정

먼저 사용자 시작점인 각 구성 요소에서 예상되는 로드를 처리하는 데 필요한 CPU 개수를 예상합니다. 다음 수치는 앞서 신원 기반 통신 예에서 설명한 신원 기반 통신 시나리오에 대한 논리적 구조를 보여 줍니다.

그림 5–1 신원 기반 통신 시나리오의 논리적 구조

다중 계층 구조에 배포된 신원 기반 통신 시나리오의 논리적 구성 요소를 보여주는 다이어그램

다음 표는 배포의 최종 사용자와 직접 상호 작용하는 논리적 구조의 프리젠테이션 계층의 구성 요소를 나열합니다. 표에는 기술적 요구 사항 분석, 사용 사례, 특정 사용 분석 및 해당 배포 유형에 대한 과거 경험에 기초한 기본 CPU 예상 개수가 포함되어 있습니다.

표 5–1 사용자 시작점 액세스를 포함하는 구성 요소에 대한 CPU 예상 개수

구성 요소 

CPU 수 

설명 

Portal Server 

4 

사용자 시작점인 구성 요소 

Communications Express 

2 

Portal Server 메시징 및 달력 채널로 데이터 경로를 지정합니다. 

서비스 종속성에 대한 CPU 예상 개수 포함

사용자 시작점을 제공하는 구성 요소는 다른 Java Enterprise System 구성 요소에서 지원해야 합니다. 성능 요구 사항을 계속 지정하려면 다른 구성 요소에서 필요로 하는 지원을 고려하여 성능 예상치를 포함합니다. 구성 요소 간 상호 작용 유형은 논리적 구조 예 절에서 논리적 구조의 예로 설명한 바와 같이 논리적 구조를 설계할 때 자세히 나타내야 합니다.

표 5–2 지원 구성 요소에 대한 CPU 예상 개수

구성 요소 

CPU 

설명 

Messaging Server MTA(인바운드) 

1 

Communications Express에서 들어오는 메일 메시지 및 전자 메일 클라이언트의 경로를 지정합니다. 

Messaging Server MTA(아웃바운드) 

1 

수신자에게 보내는 메일 메시지 경로를 지정합니다. 

Messaging Server MMP

1 

전자 메일 클라이언트에 대한 Messaging Server 메시지 저장소에 액세스합니다. 

Messaging Server STR(메시지 저장소)

1 

전자 메일 메시지를 검색하고 저장합니다. 

Access Manager

2 

권한 부여 및 인증 서비스를 제공합니다. 

Calendar Server(백엔드)

2 

Communications Express, Calendar Server 프런트엔드에 대한 달력 데이터를 검색하고 저장합니다.  

Directory Server

2 

LDAP 디렉토리 서비스를 제공합니다. 

Web Server

0 

Portal Server 및 Access Manager에 대해 웹 컨테이너 지원을 제공합니다. 

(추가 CPU 사이클이 필요 없습니다.) 

최고 부하 사용에 대한 사용 사례 연구

사용 사례와 사용 분석으로 돌아가서 최고 부하 사용 영역을 식별하고 CPU 예상 개수를 조정합니다.

예를 들어 다음과 같이 최고 부하 조건을 식별하는 예를 가정합니다.

최고 부하 사용을 고려하려면 이러한 서비스를 제공하는 구성 요소를 조정해야 합니다. 다음 표는 이러한 최고 부하 사용을 고려할 수 있는 조정에 대해 설명합니다.

표 5–3 최고 부하를 위해 CPU 예상 개수 조정

구성 요소 

CPU(조정됨) 

설명 

Messaging Server MTAinbound 

2 

받는 전자 메일의 최고 부하를 위해 CPU 1개 추가 

Messaging Server MTAoutbound 

2 

보내는 전자 메일의 최고 부하를 위해 CPU 1개 추가 

Messaging ServerMMP 

2 

추가 로드를 위해 CPU 1개 추가 

Messaging Server STR(메시지 저장소) 

2 

추가 로드를 위해 CPU 1개 추가 

Directory Server 

3 

추가 LDAP 조회를 위해 CPU 1개 추가 

기타 로드 조건에 대한 예상치 수정

다음과 같이 로드에 영향을 줄 수 있는 기타 서비스 품질 요구 사항을 고려하여 CPU를 계속 예상합니다.

CPU 예상 개수 업데이트

일반적으로 CPU 개수를 짝수로 반올림합니다. 짝수로 반올림하면 두 개의 물리적 서버를 균등하게 나눌 수 있으며 잠재 용량을 위해 적은 요소를 추가할 수 있습니다. 그러나 서비스 복제에 필요한 특정 요구에 따라 반올림해야 합니다.

일반적으로 각 CPU 당 2GB의 메모리가 필요합니다. 필요한 실제 메모리는 특정 사용에 따라 다르며 테스트 중에 결정할 수 있습니다.

다음 표는 신원 기반 통신 예에 대한 최종 예상치를 나열합니다. 이 예상치에는 보안 및 가용성을 위해 추가할 수 있는 기타 추가 컴퓨팅 성능은 포함되지 않습니다. 보안 및 가용성을 위한 전체는 다음 절에서 추가될 것입니다.

표 5–4 구성 요소 지원을 위한 CPU 예상 개수 조정

구성 요소 

CPU 

메모리 

Portal Server 

4 

8GB 

Communications Express 

2 

4GB 

Messaging Server(MTA, 인바운드) 

2 

4GB 

Messaging Server(MTA, 아웃바운드) 

2 

4GB 

Messaging Server(MMP) 

2 

4GB 

Messaging Server(메시지 저장소) 

2 

4GB 

Access Manager 

2 

4GB 

Calendar Server 

2 

4GB 

Directory Server 

4 

8GB(3CPU/6GB 메모리에서 반올림됨) 

Web Server 

0 

0 

보안 트랜잭션을 위한 프로세서 요구 사항 예상

데이터의 보안 전송에는 SSL(Secure Sockets Layer) 또는 Transport Layer Security와 같은 보안 전송 프로토콜을 통한 트랜잭션 처리가 포함됩니다. 보안 전송을 통해 처리된 트랜잭션은 일반적으로 먼저 보안 세션(핸드셰이크라고 함)을 설정하고, 그 다음 전송된 데이터를 암호화 및 해독하기 위한 추가 컴퓨팅 성능을 필요로 합니다. 사용된 암호화 알고리즘(예:40비트 또는 128비트 암호화 알고리즘)에 따라 추가 컴퓨팅 성능이 상당히 많이 필요할 수 있습니다.

비보안 트랜잭션과 동일한 수준에서 보안 트랜잭션을 수행하려면 추가 컴퓨팅 성능을 마련해야 합니다. 트랜잭션과 이를 처리하는 Sun JavaTM Enterprise System 서비스에 따라 보안 트랜잭션에는 비보안 트랜잭션보다 네 배 이상의 컴퓨팅 성능이 필요할 수 있습니다.

보안 트랜잭션을 처리하기 위한 처리 능력을 예상할 때는 먼저 사용 사례를 분석하여 보안 전송이 필요한 트랜잭션의 비율을 결정합니다. 보안 트랜잭션의 성능 요구 사항이 비보안 트랜잭션과 동일한 경우 보안 트랜잭션에 필요한 추가 컴퓨팅 성능을 고려하여 CPU 예상 개수를 수정합니다.

일부 사용 시나리오에서는 보안 전송이 인증에만 필요할 수 있습니다. 사용자가 시스템에 인증되면 데이터 전송을 위한 추가 보안 조치가 필요하지 않습니다. 다른 시나리오의 경우 보안 전송이 모든 트랜잭션에 필요할 수 있습니다.

예를 들면 온라인 전자 상거래의 제품 카탈로그를 찾아볼 때, 고객이 선택을 마치고 “지불”할 준비가 될 때까지 모든 트랜잭션이 비보안 상태일 수 있습니다. 그러나 은행이나 중개업의 배포와 같은 일부 사용 시나리오에서는 모든 또는 대부분의 트랜잭션이 보안되어야 하고 보안 및 비보안 트랜잭션 모두에 동일한 성능 표준이 적용되어야 합니다.

보안 트랜잭션의 CPU 예상 개수

이 절에서는 보안 및 비보안 트랜잭션을 포함하는 이론적 사용 사례를 위한 CPU 요구 사항을 계산하는 방법을 설명하는 배포 예제가 계속됩니다.

보안 트랜잭션을 위한 CPU 요구 사항을 예상하려면 다음과 같이 계산하십시오.

  1. 앞 절 프로세서 요구 사항 예상 예에서 설명한 대로 CPU 예상 개수에 대한 기본 수치로 시작합니다.

  2. 보안 전송이 필요한 트랜잭션의 비율을 계산한 다음 보안 트랜잭션에 대한 CPU 예상 개수를 계산합니다.

  3. 비보안 트랜잭션에 대해서는 감소된 CPU 예상 개수를 계산합니다.

  4. 총 CPU 예상 개수를 계산하려면 보안 예상치 및 비보안 예상치를 계산합니다.

  5. 총 CPU 예상 개수를 짝수로 반올림합니다.

보안 트랜잭션의 CPU 예상 개수는 다음을 가정한 상태에서 Portal Server의 사용 사례 및 사용 분석을 기반으로 한 계산 예를 보여줍니다.

표 5–5 보안 트랜잭션에 대한 CPU 예상 개수 수정

단계 

설명 

계산 

결과 

1 

모든 Portal Server 트랜잭션에 대한 기본 예상으로 시작합니다. 

최고 부하 사용에 대한 사용 사례 연구의 기본 예상치는 CPU 4개입니다.

- - - - - 

2 

보안 트랜잭션의 추가 CPU 예상 개수를 계산합니다. 보안 트랜잭션이 비보안 트랜잭션보다 4배의 성능을 필요로 한다고 가정합니다. 

보안 전송은 기본 예상치의 10배가 필요합니다. 

 

0.10 x 4 CPUs = 0.4 CPUs

 

보안 트랜잭션의 CPU 성능을 4배수로 증가합니다. 

 

4 x 0.4 = 1.6 CPUs

1.6개의 CPU 

3 

비보안 트랜잭션의 감소된 CPU 예상 개수를 계산합니다. 

기본 예상치의 90%는 비보안입니다. 

 

0.9 x 4 CPUs = 3.6 CPUs

3.6개의 CPU 

4 

보안 및 비보안 트랜잭션의 조정된 총 CPU 예상치를 계산합니다.  

보안 예상치 + 비보안 예상치 = 전체. 

 

1.6 CPUs + 3.6 CPUs = 5.2 CPUs

5.2개의 CPU 

5 

짝수로 반올림합니다.  

5.2 CPUs ==> 6 CPUs

6개의 CPU 

이 예의 보안 트랜잭션 계산에서 Portal Server의 다음과 같은 총 개수를 구하려면 추가로 두개의 CPU와 4GB의 메모리를 추가함으로써 보안 트랜잭션의 CPU 예상 개수의 총 CPU 예상 개수를 수정할 수 있습니다.

구성 요소 

CPU 

메모리 

Portal Server 

6 

12GB 

SSL 트랜잭션을 처리하는 특수 하드웨어

SSL 가속기 카드 및 기타 장치와 같은 특수한 하드웨어 장치를 사용하여 보안 세션 설정 및 데이터의 암호화 및 해독을 처리할 컴퓨팅 성능을 제공할 수 있습니다. SSL 작업을 위해 특수한 하드웨어를 사용할 경우 계산 성능은 SSL 계산의 일부, 일반적으로 보안 세션을 설정하는 “핸드셰이크” 작업에만 사용됩니다.

이 하드웨어는 최종 배포 구조에 좋은 영향을 줄 수 있습니다. 그러나 하드웨어의 특수성 때문에 먼저 CPU 성능 면에서 보안 트랜잭션 성능 요구 사항을 예상한 다음 특수 하드웨어를 사용하여 추가 로드를 처리할 때의 이점을 고려하는 것이 좋습니다.

특수 하드웨어를 사용할 경우 고려해야 할 요소로는 사용 사례에서 이 하드웨어 사용을 지원하는지 여부(예를 들어 많은 수의 SSL 핸드셰이크 작업이 필요한 사용 사례)와 이 하드웨어 유형으로 인해 설계에 추가되는 복잡도 계층을 들 수 있습니다. 이러한 복잡도에는 이 장치의 설치 구성 테스트 및 관리가 포함됩니다.

가용성 전략 결정

가용성 요구 사항을 위한 전략을 개발하는 경우 고려할 가용성 솔루션이 어떤 것인지 결정하기 위한 구성 요소 상호 작용 및 사용 분석을 연구합니다. 가용성 및 페일오버 요구 사항을 위한 최적의 솔루션을 판별하여 구성 요소별로 분석합니다.

다음 항목은 가용성 전략을 결정하도록 도와주기 위해 수집한 정보 유형의 예입니다.

선택하는 가용성 전략에서는 최적의 자원 사용을 위한 설계에 설명되어 있는 서비스 가능성 요구 사항도 고려해야 합니다. 상당한 관리 및 유지 보수가 필요한 복잡한 솔루션은 피합니다.

가용성 전략

Java Enterprise System 배포의 가용성 전략은 다음과 같습니다.

다음 절에서는 다양한 수준의 로드 균형 조정, 페일오버 및 서비스 복제를 제공하는 가용성 솔루션의 예를 설명합니다.

단일 서버 시스템

서비스를 위한 모든 컴퓨팅 자원을 단일 서버에 배치합니다. 서버에 오류가 발생할 경우 전체 서비스가 실패합니다.

그림 5–2 단일 서버 시스템

성능 요구 사항을 충족시키는 10개의 CPU가 있는 단일 서버를 표시합니다.

Sun에서는 다음 이점을 제공하는 고성능 서버를 제공합니다.

고성능 서버는 일반적으로 비슷한 다중 서버 시스템보다 비용이 더 많이 듭니다. 그러나 단일 서버인 경우 데이터 센터의 서버에 대한 관리, 모니터링 및 호스팅 비용을 절약할 수 있습니다. 로드 균형 조정, 페일오버 및 단일 실패 지점 제거는 다중 서버 시스템에서 더 유연합니다.

수평으로 중복된 시스템

로드 균형 조정과 페일오버를 제공하는 병렬로 중복된 서버의 가용성을 늘릴 수 있는 몇 가지 방법이 있습니다. 다음 그림에서는 N+1 페일오버 시스템을 제공하는 두 개의 복제 서버를 설명합니다. N+1 시스템에는 한 서버가 실패할 경우 100% 용량을 제공하는 추가 서버가 있습니다.

그림 5–3 두 서버를 가진 N+1 페일오버 시스템

10개 CPU 성능 요구 사항을 충족시키기 위해 각각 10개의 CPU가 있는 2개의 복제 서버를 보여줍니다.

위 수평으로 중복된 시스템에서 각 서버의 컴퓨팅 성능은 동일합니다. 하나의 서버만 성능 요구 사항을 처리합니다. 다른 서버는 백업으로 서비스에 호출된 경우 100%의 성능을 제공합니다.

N+1 페일오버 설계의 장점은 페일오버 상황에서 100%의 성능을 유지하는 것입니다. 단점은 하드웨어 비용은 증가하면서도 그에 따른 성능을 모두 얻지 못한다는 것입니다(왜냐하면 한 서버는 오직 페일오버 상황에서만 사용하기 위해 대기하고 있기 때문입니다).

다음 그림은 두 서버 간 성능을 분산하도록 로드 균형 조정에 페일오버를 더하여 구현한 시스템을 보여줍니다.

그림 5–4 두 서버 간 로드 균형 조정 및 페일오버

10개 CPU 성능 요구 사항을 충족시키기 위해 각각 6개의 CPU가 있는 두 서버를 보여줍니다.

위 수평으로 중복된 시스템에서 설명한 시스템에서 한 서버가 실패하더라도 전체 용량의 일부이긴 하지만 모든 서비스가 여전히 사용 가능합니다. 남은 서버에서 10개 CPU 요구 사항의 60%인 6개 CPU의 컴퓨팅 성능을 제공합니다.

이 설계의 장점은 두 서버를 모두 사용할 수 있는 경우 추가로 2개의 CPU 잠재 용량이 있다는 점입니다.

다음 그림에서는 성능 및 로드 균형 조정을 위한 여러 서버 간의 배포를 보여줍니다.

그림 5–5 n개의 서버 간 로드 배포

10개 CPU 성능 요구 사항을 충족시키기 위해 각각 2개의 CPU가 있는 다섯 개의 서버를 보여줍니다.

수평으로 중복된 시스템과 같이 이 설계에 다섯 개의 서버가 있기 때문에 한 서버가 실패할 경우 나머지 서버에서 10개 CPU 성능 요구 사항의 80%인 총 8개 CPU의 컴퓨팅 성능을 제공합니다. 설계에 2개 CPU 용량을 가진 서버를 추가할 경우 결과적으로 N+1 설계가 됩니다. 한 서버가 실패하면 나머지 서버에서 성능 요구 사항의 100%를 충족시킵니다.

이 설계에는 다음과 같은 장점이 있습니다.

그러나 서버를 추가할 경우 관리 및 유지 보수 비용이 상당히 늘어날 수 있습니다. 또한 데이터 센터에 서버를 호스팅하는 비용을 고려해야 합니다. 일정 시점이 되면 서버 추가에 따른 수익이 줄어들기 시작합니다.

Sun Cluster 소프트웨어

높은 수준의 가용성이 필요한 경우(예: 4개 또는 5개의 9) Sun Cluster 소프트웨어를 가용성 설계의 일부로 고려할 수 있습니다. 클러스터 시스템은 저장소 및 기타 네트워크 자원이 있는 중복 서버를 연결한 것입니다. 클러스터의 서버들은 서로 계속해서 통신합니다. 한 서버가 오프라인이 될 경우 클러스터의 나머지 장치에서 해당 서버를 격리하고 실패한 노드의 응용 프로그램이나 데이터를 다른 노드로 페일오버합니다. 이 페일오버 프로세스는 시스템 사용자의 서비스를 방해하지 않고 비교적 빠르게 수행됩니다.

Sun Cluster 소프트웨어는 추가 전용 하드웨어와 구성, 관리 및 유지 보수를 위한 특수 기술이 필요합니다.

가용성 설계 예

이 절에서는 신원 기반 통신 예에서 이미 설명한 대로 1,000명에서 5,000명의 직원이 있는 중소 기업을 위한 신원 기반 통신 솔루션을 기반으로 하는 가용성 전략의 두 가지 예가 설명됩니다. 첫 번째 가용성 전략은 Messaging Server를 위한 로드 균형 조정을 보여줍니다. 두 번째는 Sun Cluster 소프트웨어를 사용하는 페일오버 솔루션을 보여줍니다.

Messaging Server를 위한 로드 균형 조정 예

다음 표에는 논리적 구조에 있는 각 논리적 Messaging Server 구성 요소의 CPU 성능에 대한 예상치가 나열되어 있습니다. 이 표에는 CPU 예상 개수 업데이트 절에서 계산한 최종 예상치가 반복되어 있습니다.

표 5–6 구성 요소 지원을 위한 CPU 예상 개수조정

구성 요소 

CPU 

메모리 

Messaging Server(MTA, 인바운드) 

2 

4GB 

Messaging Server(MTA, 아웃바운드) 

2 

4GB 

Messaging Server(MMP) 

2 

4GB 

Messaging Server(메시지 저장소) 

2 

4GB 

예를 들면 기술적 요구 사항 단계 중에 서비스 품질 요구 사항이 다음과 같이 지정되었다고 가정합니다.

가용성 요구 사항을 성취하기 위해 각 Messaging Server의 구성 요소가 각각 별개 하드웨어 서버에 있는 두 개의 인스턴스를 제공합니다. 한 구성 요소를 가진 서버가 실패하는 경우 다른 서버가 서비스를 제공합니다. 다음 그림은 이러한 가용성 전략을 위한 네트워크 다이어그램을 보여줍니다.

Messaging Server MMP 및 MTA 구성 요소에 대한 가용성을 나타내는 구조 다이어그램

이전 그림에서 CPU 수가 원래 예상치의 두 배가 됩니다. CPU는 다음 이유로 두 배가 됩니다.

Sun Cluster 소프트웨어를 사용하는 페일오버 예

다음 그림은 Calendar Server 백엔드 및 Messaging Server 메시징 저장소에 대한 페일오버 전략 예를 나타냅니다. Calendar Server 백엔드 및 메시징 저장소는 별개 하드웨어 서버에 복제되며 Sun Cluster 소프트웨어와 함께 페일오버를 위해 구성됩니다. CPU 수와 해당 메모리는 Sun Cluster의 각 서버에 복제됩니다.

그림 5–6 Sun Cluster 소프트웨어를 사용하는 페일오버 예

페일오버를 위한 Sun Cluster 소프트웨어와 함께 배포된 Calendar Server 및 Message Server 저장소를 나타내는 구조 다이어그램

디렉토리 서비스 복제 예

디렉토리 서비스를 고가용성을 제공하면서 다른 서버 간 트랜잭션을 분산하기 위해 복제할 수 있습니다. Directory Server는 다음을 포함하여 서비스 복제의 다양한 전략을 제공합니다.

Directory Server를 위한 가용성 전략은 복잡한 내용으로서 이 설명서 범위를 벗어납니다. 다음 절인 단일 마스터 복제 및 다중 마스터 복제에서는 기본 복제 전략에 대한 수준 높은 설명을 제공합니다. 자세한 내용은 Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide를 참조하십시오.

단일 마스터 복제

다음 그림은 기본 복제 개념을 보여 주는 단일 마스터 복제 전략을 나타냅니다.

그림 5–7 단일 마스터 복제 예

단일 마스터 복제 전략을 위한 데이터 흐름을 보여주는 다이어그램

단일 마스터 복제에서는 Directory Server의 한 인스턴스가 모든 변경 사항을 기록하면서 마스터 디렉토리 데이터베이스를 관리합니다. 마스터 데이터베이스는 모든 수의 사용자 데이터베이스에 복제됩니다. Directory Server의 사용자 인스턴스는 읽기 및 검색 작업을 위해 최적화되어 있습니다. 사용자가 수신한 모든 읽기 작업은 마스터에게 돌아가 참조됩니다. 마스터는 주기적으로 사용자 데이터베이스를 업데이트합니다.

단일 마스터 복제의 장점은 다음과 같습니다.

다중 마스터 복제

다음 그림은 디렉토리 액세스를 전세계적으로 분산하는데 사용할 수 있는 다중 마스터 복제 전략을 나타냅니다.

다중 마스터 복제에서는 Directory Server의 한 개 이상의 인스턴스가 마스터 디렉토리 데이터베이스를 관리합니다. 각 마스터에는 마스터 데이터베이스를 동기화하기 위한 절차를 지정하는 복제 계약이 있습니다. 각 마스터는 모든 사용자 데이터베이스에 복제합니다. 단일 마스터 복제와 같이 Directory Server의 사용자 인스턴스는 읽기 및 검색 액세스를 위해 최적화되어 있습니다. 사용자가 수신한 모든 읽기 작업은 마스터에게 돌아가 참조됩니다. 마스터는 주기적으로 사용자 데이터베이스를 업데이트합니다.

그림 5–8 다중 마스터 복제 예

다중 마스터 복제 전략을 위한 데이터 흐름을 보여 주는 다이어그램

다중 마스터 복제 전략은 단일 마스터 복제의 모든 장점에 더하여 마스터에 업데이트할 경우 로드 균형을 제어할 수 있는 가용성 전략을 제공합니다. 또한 전세계적으로 분산된 데이터 센터가 있는 기업에 있어서 중요한 고려 사항인 디렉토리 작업의 로컬 제어를 제공하는 가용성 전략도 구현할 수 있습니다.

확장성에 대한 전략 결정

확장성은 대개 시스템 자원을 추가하지만 배포 구조는 변경하지 않고 시스템에 용량을 추가할 수 있는 기능을 말합니다. 요구 사항 분석 시 일반적으로 비즈니스 요구 사항과 그 후의 사용 분석을 기준으로 예상되는 시스템 증가를 예상합니다. 시스템의 사용자 수에 대한 이 예측과 이들 사용자의 요구 사항을 충족시키기 위한 시스템의 용량은 배포된 시스템의 실제 수치와는 크게 다른 경우가 많습니다. 예측의 차이를 수용할 수 있도록 설계에 융통성이 있어야 합니다.

확장 가능한 설계는 시스템이 추가 자원과 함께 업그레이드할 수 있을 때까지 증가된 로드를 처리할 수 있는 충분한 잠재 용량을 포함합니다. 확장 가능 설계는 시스템을 다시 설계하지 않고도 증가하는 로드를 처리하도록 즉시 확장될 수 있습니다.

잠재 용량

잠재 용량은 추가 성능과 가용성 자원을 시스템에 포함시켜서 비정상적인 최고 로드를 쉽게 처리할 수 있도록 하는 확장성의 한 요소입니다. 또한 잠재 용량이 배포 시스템에서 사용되는 방법을 모니터하여 언제 자원을 추가하여 시스템을 확장해야 할 지를 결정할 수 있습니다. 잠재 용량은 설계에 안전을 확립하는 한 가지 방법입니다.

사용 사례 분석으로 비정상적인 최고 로드를 만들 수 있는 시나리오를 식별할 수 있습니다. 예상치 않은 증가를 처리하고 시스템에 안전을 확립하는 잠재 용량을 설계하는 요소와 더불어 이와 같은 비정상적인 최고 로드를 분석합니다.

시스템 설계는 일반적으로 운영의 처음 6-12 개월 동안 합리적인 시간에 예상된 용량을 처리할 수 있어야 합니다. 유지 보수 주기를 사용하여 자원을 추가하거나 필요한 용량을 늘릴 수 있습니다. 시스템 업그레이드를 정기적으로 예약할 수 있는 것이 가장 좋지만 필요한 용량 증가를 예측하는 것은 종종 어렵습니다. 시스템 업그레이드 시기를 결정하기 위해서는 비즈니스 예측뿐만 아니라 자원에 대한 신중한 모니터링에 의존합니다.

솔루션을 증분 단계에 구현하려고 하는 경우 각 증분 단계에 대해 예약된 다른 향상과 일치하도록 증가하는 시스템 용량을 예약해야 합니다.

확장성 예

이 절의 예는 Messaging Server를 구현하는 솔루션을 위한 수평 및 수직 확장을 설명합니다. 수직 확장의 경우 서버에 CPU를 추가하여 증가하는 로드를 처리할 수 있게 합니다. 수평 확장의 경우 로드 분산을 위한 서버를 추가하여 증가하는 로드를 처리합니다.

이 예는 기본적으로 로드 균형 조정을 위해 분산된 메시지 저장소 인스턴스 2개가 50,000 사용자를 지원한다고 가정합니다. 각 서버가 CPU를 2개씩 가지고 있어 총 CPU는 4개가 됩니다. 다음 그림은 250,000 사용자 및 2,000,000 사용자에 대해 증가하는 로드를 처리할 수 있도록 이 시스템을 확장할 수 있는 방법을 나타냅니다.

주 –

확장성 예는 수평 확장 및 수직 확장 간의 차이를 나타냅니다. 이 그림에서는 로드 균형 조정, 페일오버 및 사용 패턴 변경과 같이 확장 시 고려해야 할 기타 요소는 보여주지 않습니다.

그림 5–9 수평 및 수직 확장 예

기본 구조와 비교하여 수평 및 수직 확장을 나타내는 구조 다이어그램.

성능 병목 현상 식별

배포 설계를 성공으로 이끄는 열쇠 중 하나는 잠재적인 성능 병목 현상을 식별하여 그것을 피하는 전략을 개발하는 것입니다. 성능 병목 현상은 어떤 데이터를 액세스하는 비율이 지정된 시스템 요구 사항에 미치지 못할 때 발생합니다.

병목 현상은 다음 표의 시스템 간 데이터 액세스 지점에서 나열한 대로 다양한 하드웨어 클래스에 따라 범주화할 수 있습니다. 또한 이 표는 각 하드웨어 클래스의 병목 현상에 대한 가능한 해결 방법을 제시합니다.

표 5–7 데이터 액세스 지점

하드웨어 클래스 

상대 액세스 속도 

성능 향상을 위한 해결 방법 

프로세서 

10억분의 1초 

수직 확장: 처리 능력 추가 및 프로세서 캐시 향상 

수평 확장: 로드 균형 조정을 위한 병렬 처리 능력 추가 

시스템 메모리(RAM) 

100만분의 1초 

시스템 메모리를 특정 작업 전용으로 사용 

수직 확장: 메모리 추가 

수평 확장: 병렬 처리 및 로드 균형 조정을 위한 추가 인스턴스 생성 

디스크 읽기 및 쓰기 

밀리초 

디스크 배열(RAID)로 디스크 액세스 최적화 

디스크 액세스를 읽기 및 쓰기 전용과 같이 특정 기능 전용으로 사용 

자주 액세스하는 데이터를 시스템 메모리에 캐시 

네트워크 인터페이스 

네트워크 노드의 대역폭 및 액세스 속도에 따라 다양화 

대역폭 증가 

보안 데이터 전송 시 가속기 하드웨어 추가 

데이터를 즉시 사용할 수 있도록 네트워크 간 노드의 성능 향상 

주 –

성능 병목 현상 식별에서는 디스크와 같은 느린 액세스 지점이 병목 현상의 원인이 될 수 있음을 나타내면서 상대적인 액세스 속도에 따라 하드웨어 클래스를 나열합니다. 그러나 대형 로드를 처리하기에 성능이 떨어지는 프로세서 또한 병목 현상의 원인이 될 수 있습니다.

일반적으로 배포 및 해당 종속성의 각 구성 요소에 대한 기본 처리 능력 예상치로 배포 설계를 시작합니다. 그 다음에 시스템 메모리 및 디스크 액세스와 관련된 병목 현상을 피하는 방법을 결정합니다. 마지막으로 잠재적인 병목 현상을 결정할 수 있도록 네트워크 인터페이스를 검사하고 극복할 전략에 집중합니다.

디스크 액세스 최적화

배포 설계의 중요한 구성 요소는 LDAP 디렉토리와 같이 자주 액세스하는 데이터 집합에 대한 디스크 액세스 속도입니다. 디스크 액세스는 데이터로 가장 느리게 액세스하여 성능 병목 현상의 원인이 될 수 있습니다.

디스크 액세스를 최적화하는 한 방법은 읽기 작업과 쓰기 작업을 분리하는 것입니다. 쓰기 작업은 읽기 작업보다 비용이 많이 들 뿐 아니라 읽기 작업(LDAP 디렉토리 조회 작업)은 일반적으로 쓰기 작업(LDAP 디렉토리의 데이터 업데이트)보다 상당히 자주 발생합니다.

디스크 액세스를 최적화하는 또 다른 방법은 다른 유형의 I/O 작업에 대해 전용 디스크를 두는 것입니다. 예를 들면 트랜잭션 로그와 이벤트 로그, LDAP 읽기 및 쓰기 작업과 같은 Directory Server 로깅 작업을 위해 별개 디스크를 제공합니다.

또한 읽기 및 쓰기 작업 전용인 Directory Server에 한 개 이상의 인스턴스를 구현하고 로컬 서버로 분산된 복제 인스턴스를 읽기 및 검색 액세스를 위해 사용할 것을 고려합니다. 연쇄 및 연결 선택 사항 또한 디렉토리 서비스 액세스를 최적화하는데 사용할 수 있습니다.

Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide에서는 디스크 액세스 계획의 다양한 요소를 설명합니다. 이 장의 내용은 다음과 같습니다.

최적의 자원 사용을 위한 설계

배포 설계가 단지 서비스 품질 요구 사항을 충족하는데 필요한 자원을 예상하는 것만은 아닙니다. 배포 설계 중에 모든 사용 가능한 선택 사항을 분석하고 비용을 최소화하면서도 서비스 품질 요구 사항을 계속 충족하는 최상의 솔루션을 선택합니다. 한 영역의 이점이 다른 영역의 비용으로 상쇄되지 않도록 각 설계 결정 간의 균형을 조절하기 위한 분석을 해야 합니다.

예를 들어 가용성을 가로로 확장할 경우 전체적인 가용성이 증가할 수 있지만 유지 보수 및 서비스 비용이 증가됩니다. 성능을 세로로 확장하면 컴퓨팅 성능을 저렴한 비용으로 확장할 수 있지만 일부 서비스에서 추가 성능을 비효율적으로 사용할 수 있습니다.

설계 전략을 완료하기 전에 결정을 검토하여 제안된 솔루션에 대해 전체적으로 이익이 되도록 자원 사용의 균형을 유지하는지 확인합니다. 이 분석은 일반적으로 한 영역의 시스템 품질이 다른 시스템 품질에 어떤 영향을 미치는지도 검토합니다. 다음 표는 자원 관리를 위한 시스템 품질 및 해당 고려 사항을 나열합니다.

표 5–8 자원 관리 고려 사항

시스템 품질 

설명 

성능

개별 서버의 CPU에 집중하는 성능 솔루션의 경우 서비스가 컴퓨팅 성능을 효율적으로 이용할 수 있습니까? (예를 들어 일부 서비스의 경우 효율적으로 사용할 수 있는 CPU 개수에 한계가 있습니다.) 

잠재 용량 

전략이 성능 예상치를 초과하는 로드를 처리합니까? 

서버의 세로 확장, 다른 서버에 대한 로드 균형 조정 또는 둘 다를 사용하여 과도한 로드를 처리합니까? 

배포 확장을 위한 다음 시점까지 비정상적인 최고 로드를 처리할 만큼 잠재 용량이 충분합니까? 

보안

보안 트랜잭션을 처리하는 데 필요한 성능 오버헤드를 충분히 고려했습니까? 

가용성

수평으로 중복된 솔루션의 경우 장기 유지 보수 비용을 충분히 예상했습니까? 

시스템을 유지 보수하는 데 필요한 예약된 중단 시간을 고려했습니까?  

고성능 서버와 저성능 서버 간의 비용을 공정하게 고려했습니다. 

확장성

배포를 확장하기 위한 중요 시점을 예상했습니까? 

배포 확장의 중요 시점까지 예상되는 로드 증가를 처리할 충분한 잠재적 용량을 제공하는 전략이 있습니까? 

실용성

가용성 설계에서 관리, 모니터링 및 유지 보수 비용을 고려했습니까? 

관리 비용을 줄이기 위해 사용자가 직접 일부 관리 작업을 수행할 수 있도록 하는 위임 관리 솔루션을 고려해 보았습니까? 

위기 관리

서비스 품질 요구 사항 및 사용 분석 같은 배포 설계의 기반이 되는 정보 대부분은 경험적인 데이터가 아니라 궁극적으로 비즈니스 분석으로부터 이끌어낸 예측과 예상을 기반으로 하는 데이터입니다. 이러한 예상은 비즈니스 운영 중 예기치 못한 상황, 데이터 수집의 잘못된 방법 또는 단순하게 사람의 실수 등의 여러 이유로 인해 정확하지 않을 수 있습니다. 배포 설계를 완료하기 전에 설계의 기반이 되는 분석을 재검토하고 예측 또는 예상으로부터 모든 합리적인 이탈을 고려하여 설계했는지 확인합니다.

예를 들면 사용 분석이 시스템의 실제 사용량에 못 미칠 경우 발생하는 트래픽 양을 처리할 수 없는 시스템을 구성할 위험이 있습니다. 제 성능을 내지 못하는 설계는 결단코 실패로 간주해야 합니다.

한편 필요한 것보다 몇 곱절 더 강력한 시스템을 구성하는 경우 다른 곳에서 사용할 수 있는 자원을 유용하는 것입니다. 요구 사항을 초과하는 여분의 안전을 포함시키면서도 자원을 지나치게 사용하는 것은 피하는 것이 열쇠입니다.

지나친 자원 사용은 설계를 실패하게 합니다. 왜냐하면 사용되지 않은 자원을 다른 영역에 적용할 수도 있기 때문입니다. 또한 지나친 솔루션은 이해 관계자에게 계약을 성실하게 이행하지 못한 것으로 간주될 수 있습니다.

예제 배포 구조

다음 그림에서는 백서 앞 부분에서 소개한 예제 배포의 전체 배포 구조를 보여줍니다. 이 그림은 배포 구조를 제공하는 방법에 대한 개념을 설명합니다.

주의 – 주의 –

다음 그림의 배포 구조는 설명을 위한 것입니다. 실제로 설계, 구축 또는 테스트한 배포를 나타내지 않으며 배포 계획에 대한 유용한 정보로 간주해서는 안 됩니다.

그림 5–10 예제 배포 구조

이 그림은 배포 구조에 대한 레이아웃 예를 나타냅니다.