5장 배포 구조 설계

이 장에서는 성능, 보안, 가용성 및 기타 시스템 품질에 대해 배포를 설계하는 방법에 대해 설명합니다. 또한 배포 설계를 최적화하는 방법도 설명합니다.

배포 구조는 논리적 구조를 물리적 환경에 매핑하는 것을 설명합니다. 물리적 환경에는 인트라넷이나 인터넷 환경의 컴퓨팅 노드, CPU, 메모리, 저장 장치 및 기타 하드웨어 및 네트워크 장치가 포함됩니다.

배포 구조 설계에서는 기술 요구 사항 단계에서 지정한 시스템 요구 사항을 충족시키는 데 필요한 물리적 자원을 결정하기 위해 배포 크기를 조정합니다. 또한 배포 크기 조정 결과의 분석을 통해 자원을 최적화하여 비즈니스 제약 조건 내에서 자원을 가장 잘 이용하는 설계를 작성합니다.

배포 구조 설계를 완료한 후 프로젝트 승인 동안에 배포의 실제 비용을 평가합니다. 프로젝트가 승인되면 배포 완료를 위한 계약에 서명하고 프로젝트를 구현하기 위한 자원을 구입합니다.

세부 설계 지정은 프로젝트 승인 전후에 수행됩니다. 세부 설계 지정은 구현 단계에서 설계를 작성하는 데 사용됩니다.

이 장에서는 4장의 예제 배포를 계속 사용하여 배포 구조 설계 과정의 여러 단계를 설명합니다.

계획된 배포의 크기 조정

계획된 배포의 크기 조정은 시스템 요구 사항을 이행하고 궁극적으로 비즈니스 목표를 충족시키는 데 필요한 하드웨어 자원 집합을 결정하는 과정입니다. 배포의 계획 및 설계 등의 다른 요소와 마찬가지로 크기 조정은 그리 과학적이지 않으며 공식이나 방법으로 규정할 수 없습니다. 성공적인 크기 조정은 과거의 설계 경험, 시스템 구조에 대한 지식, 도메인 지식 및 응용된 창조적 생각 등을 조합한 결과입니다.

크기 조정은 시스템 요구 사항에서 설명한 대로 다음과 같은 서비스 품질에 대해 기존에 결정한 시스템 요구 사항을 기준으로 수행됩니다. 배포 설계 이전 단계의 비즈니스 요구 사항, 사용 분석, 사용 사례도 시스템 크기 조정에서 중요한 역할을 수행합니다.

크기 조정 연습을 수행할 때 사용 사례와 사용 분석을 통해 사용 사례를 지원하는 데 필요한 자원을 결정할 수 있습니다. 일반적으로 가중치가 가장 높은 사용 사례(가장 일반적인 트랜잭션을 나타냄)부터 시작하여 가중치가 가장 낮은 사용 사례로 진행합니다. 이와 같이 가중치가 적용된 사용 사례를 사용하면 시스템에 예상되는 스트레스에 따라 자원을 할당할 수 있습니다.

다음 절에서는 다음과 같은 시스템 품질에 대해 배포의 크기를 조정하는 방법에 대한 일반적인 지침을 제공합니다.

성능을 위한 크기 조정

성능 및 로드 요구 사항을 위한 크기 조정은 배포된 시스템에서 서비스를 지원하는 데 필요한 CPU 수와 해당하는 메모리를 예상하는 반복적인 과정입니다. 서비스 지원에 필요한 CPU 수를 예상할 때 다음을 고려하십시오.

성능을 위한 크기 조정 과정은 대개 다음 단계로 구성됩니다. 이 단계의 순서는 중요하지 않으며 단지 최종 결과에 영향을 미치는 요소들을 고려하는 방법을 제공할 뿐입니다.

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

먼저 사용자 시작점인 각 구성 요소에서 예상되는 로드를 처리하는 데 필요한 CPU 개수를 예상합니다. 논리적 구조에 대한 레이아웃 설계에 이 예상 개수를 기록합니다.

다음 그림에서는 배포 계획 예에서 소개한 예제 배포를 사용하여 사용자 시작점인 구성 요소에 대한 초기 CPU 예상 개수를 보여 줍니다. 이 예상 개수는 시스템 요구 사항, 사용 사례 및 사용 분석에서 얻을 수 있는 수치를 나타냅니다.


주의	이 백서에서는 성능 크기 조정에 대해 자세히 설명하지 않습니다. 이 설명서에서 사용한 CPU 및 메모리 수치는 설명을 위한 임의적인 예상치입니다. 이 수치는 시스템을 설계할 때 사용할 수 있는 과정을 보여 주는 것 이외에 특정 구현 정보를 나타내지는 않습니다.

그림 5-1
사용자 시작점을 제공하는 구성 요소에 대한 기본 CPU 예상 개수

서비스 종속성에 대해 CPU 예상 개수 조정

사용자 시작점을 제공하는 구성 요소는 다른 Java Enterprise System 서비스에서 지원해야 합니다. 성능 요구 사항을 계속 지정하려면 다른 구성 요소에서 필요로 하는 지원을 고려하여 성능 예상치를 조정합니다.

예에서는 그림 4-4에서 설명한 대로 데이터의 논리적 흐름을 검토하고 다른 구성 요소에 지원을 제공하는 구성 요소를 조정합니다. 다음 표에서는 CPU 예상 개수에 대한 조정을 요약합니다. 예상에서 CPU 개수를 분수로 지정할 수 있습니다. 성능 예상이 완료되면 CPU 개수가 합산되어 반올림됩니다.

앞 절의 예상치와 같이 다음 표의 성능 예상치는 설명하기 위한 임의의 값입니다.

표 5-1
지원 서비스에 대한 CPU 예상 개수
서비스	예상 개수	설명
Portal Server	없음	다른 서비스를 지원하지 않습니다.
Calendar Server	1개의 CPU	다음을 지원합니다. Portal Server의 달력 채널
Messaging Server	1.5개의 CPU	다음을 지원합니다. Portal Server의 메시징 채널 Calendar Server의 전자 메일 알림 서비스
Identity Server	3개의 CPU	다음을 지원합니다. Portal Server Calendar Server Messaging Server
Directory Server	5개의 CPU	다음을 지원합니다. Identity Server Calendar Server Messaging Server

다음 그림에서는 표 5-1의 정보를 기준으로 성능에 대한 예상 개수를 업데이트합니다.

잠재 용량, 확장성 및 가용성에 대한 CPU 예상 개수 조정

성능에 대한 예상 개수의 크기 조정을 완료하면 CPU의 수치를 반올림합니다. 일반적으로 CPU 개수를 다음 짝수로 반올림합니다. CPU 예상 개수를 반올림할 때 다음 요소를 고려합니다.

다음 수치는 예제 배포의 CPU 예상 개수를 조정한 것입니다. 이 수치는 각 CPU의 메모리 요구 사항도 지정합니다. 이 예에서는 각 CPU에 2GB 메모리가 필요한 것으로 가정합니다. 예의 이 메모리 사양은 설명을 위한 임의의 숫자입니다. 각 CPU에 필요한 메모리 계산은 이 백서 범위를 벗어납니다.

보안을 위한 크기 조정

배포의 크기를 조정할 때 보안 문제는 다음과 같은 요소로 영향을 미칩니다.

데이터의 보안 전송에는 SSL(Secure Sockets Layer)과 같은 보안 전송 프로토콜을 통한 트랜잭션 처리가 포함됩니다. 사용자 인증에서도 보안 전송을 통해 트랜잭션을 처리해야 합니다.

보안 전송을 통해 처리된 트랜잭션은 일반적으로 첫째 보안 세션(핸드셰이크라고 함)을 설정하고, 둘째 전송된 데이터를 암호화 및 해독하기 위한 추가 컴퓨팅 성능을 필요로 합니다. 사용된 암호화 알고리즘(예: 40비트 또는 128비트 암호화 알고리즘)에 따라 추가 컴퓨팅 성능이 상당히 많이 필요할 수 있습니다.

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

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

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

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

보안 트랜잭션에 대한 성능 계산

이 절에서는 예제 배포를 계속 사용하여 보안 및 비보안 트랜잭션을 모두 포함하는 사용 사례의 CPU 요구 사항을 계산하기 위한 워크시트를 설명합니다.

CPU 요구 사항을 계산하려면 워크시트에 다음 계산을 만듭니다.

그림 5-4의 워크시트는 Portal Server에 대한 추가 사용 사례와 사용 분석을 기반으로 합니다. 추가 사용 사례와 사용 분석에서는 다음을 가정합니다.

이 예의 목적인 SSL 트랜잭션을 처리하기 위한 추가 컴퓨팅 성능을 고려하기 위해 이러한 트랜잭션을 처리하는 CPU 개수를 5배씩 늘립니다. 예의 다른 CPU 수치처럼 이 수치는 설명을 위한 임의의 숫자입니다.

그림 5-4
보안 트랜잭션의 CPU 예상 개수를 계산하기 위한 워크시트

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

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

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

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

가용성을 위한 크기 조정

성능을 위한 크기 조정을 완료한 후 가용성을 위해 시스템 크기를 조정할 수 있습니다. 여기서 논리 구조의 구성 요소를 호스트하는 특정 서버를 지정하고 다양한 Java Enterprise System 구성 요소에 대한 로드 균형 조정, 중복 및 페일오버 전략을 설계합니다.

사용 사례 및 사용 분석을 연구하여 고려할 가용성 솔루션을 결정합니다. 다음 항목은 가용성 전략을 결정하도록 도와주기 위해 수집한 정보 유형의 예입니다.

각 구성 요소에 대해 사용 사례를 분석하여 페일오버와 로드 균형 조정 요구 사항에 가장 잘 맞는 솔루션을 결정합니다. 또한 사용 사례와 사용 분석을 고려하여 로드 균형 서비스에 가장 적합한 방법을 결정합니다.

선택하는 가용성 전략에서는 서비스 가능성 문제점에 설명되어 있는 서비스 가능성 요구 사항도 고려해야 합니다. 관리하기 쉬운 시스템을 위하여 상당한 관리 및 유지 보수가 필요한 복잡한 솔루션은 피합니다.

복잡한 시스템의 디렉토리 설계

많은 수의 사용자에 대한 복잡한 배포의 경우 가용성 전략에 영향을 미칠 수 있는 Directory Server의 디렉토리 설계가 필요할 수 있습니다. 이는 LDAP 디렉토리 설계가 Identity Server 및 Messaging Server의 가용성 전략에 영향을 미치고, 차례로 다른 시스템 품질에도 영향을 미칠 수 있기 때문입니다.

복잡한 배포를 설계할 경우 가용성 설계를 지원하는 임시 디렉토리 설계를 작성하는 것을 고려해 봅니다. 나중에 세부 설계 지정이나 개발 단계에서 완전한 디렉토리 설계를 제공합니다.

하드웨어 및 소프트웨어 오류

가용성 설계에서는 하드웨어와 소프트웨어 오류를 방지해야 합니다. 일반적으로 소프트웨어 오류가 하드웨어 오류보다 비용이 높습니다. 소프트웨어 오류의 평균 시간이 하드웨어 오류보다 많습니다. 또한 소프트웨어 오류가 진단 및 복구가 더 어렵고 이를 방지하기 위한 관리 및 유지 보수 비용이 더 많이 듭니다.

가용성에 대한 일반적인 접근 방법

이 절에서는 가용성 요구 사항을 설계할 수 있는 일반적인 방법을 설명합니다. 특정 가용성 설계는 이 백서의 범위를 벗어납니다.

단일 서버 시스템

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

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

수평으로 중복된 시스템

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

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

복제 서버 설계의 장점은 페일오버 상황에서 100% 성능을 제공한다는 점입니다. 단점은 하드웨어 비용 증가에 해당하는 전체적인 성능 증가가 없는 것입니다.

다음 그림에서는 로드 균형 조정 및 페일오버를 위해 두 서버 간에 성능을 배포하는 시나리오를 설명합니다.

위 그림 5-7에서는 한 서버가 실패하더라도 전체 용량의 일부이긴 하지만 모든 서비스가 여전히 사용 가능합니다. 남은 서버에서 10개 CPU 요구 사항의 60%인 6개 CPU의 컴퓨팅 성능을 제공합니다.

이 설계의 장점은 두 서버를 모두 사용할 수 있는 경우 추가로 2개의 CPU 잠재 용량이 있다는 점입니다. 또한 한 서버가 실패할 경우 비록 감소된 성능으로라도 모든 서비스를 사용할 수 있습니다.

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

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

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

Sun Cluster

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

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

샘플 배포의 가용성 설계

다음 그림에서는 4장, "논리 구조 설계"에서 소개한 예제 배포의 달력 서비스 부분에 대한 가용성 설계를 보여 줍니다. 이 그림은 예제 배포에 대한 논리 구조의 Calendar Server 부분을 위한 가용성 솔루션을 설명합니다. 예제 배포의 전체 가용성 솔루션에 대한 분석은 이 백서의 범위를 벗어납니다.

이 장 앞 부분의 크기 조정 연습에서는 그림 5-3에서 설명한 것처럼 Calendar Server에 6개의 CPU와 12GB의 메모리가 필요한 것으로 결정했습니다. 다음 그림에서는 들어오는 요청과 나가는 요청의 로드 균형 조정을 위해 두 서버에 배포한 Calendar Server의 프런트 엔드를 보여 줍니다. Calendar Server의 백 엔드는 별도의 서버에 배포되며, 페일오버를 위해 Sun Cluster 3.1 4/04에 복제됩니다. 페일오버를 위해 Calendar Server 백 엔드에 필요한 CPU 및 메모리가 Sun Cluster 3.1 4/04에 복제됩니다.

서비스 가능성 문제점

가용성을 설계할 때 솔루션의 관리 및 유지 보수 비용도 고려해야 합니다. 이 비용은 하드웨어 구입과 특별히 관련이 없기 때문에 설계에서 이 비용을 빠뜨리는 경우가 종종 있습니다. 오히려 설계의 복잡도를 반영하는 진행 중인 숨겨진 비용일 수 있습니다.

예를 들어, 설계에 높은 가용성을 제공하는 수평으로 중복된 여러 서버를 포함시킬 수 있습니다. 그러나 서버 설정 및 구성 비용을 고려하지 않고 소프트웨어를 계속 업그레이드하며 시스템 상태를 모니터할 경우 가용성 증가가 손상될 수 있습니다.

서비스 가능성을 설계할 경우 다음과 같은 관리 및 유지 보수 비용을 고려합니다.

확장성을 위한 크기 조정

확장성은 대개 시스템 자원을 추가하지만 배포 구조는 변경하지 않고 시스템에 용량을 추가할 수 있는 기능을 나타냅니다. 이 절에서는 확장성을 설계할 때 고려해야 할 항목을 설명합니다.

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

잠재 용량

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

사용 사례를 신중하게 분석하면 비정상적인 최고 로드를 작성할 수 있는 시나리오(예를 들어, 필수 웹 캐스팅을 예약하는 B2E 배포)를 식별하는 데 도움이 될 수 있습니다. 예상치 않은 증가를 처리하고 시스템에 안전을 확립하는 잠재 용량을 설계하는 요소와 더불어 이와 같은 비정상적인 최고 로드를 분석합니다.

또한 잠재 용량이 배포 시스템에서 사용되는 방법을 모니터하여 언제 자원을 추가하여 시스템을 확장해야 할지를 결정할 수 있습니다.

시스템의 용량 업그레이드

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

비즈니스 또는 기술적인 이유로 시스템 일부의 배포를 지연하는 증분 배포를 수행할 경우 시스템의 새로운 기능을 포함하는 다른 업그레이드와 일치하도록 시스템의 용량 업그레이드를 예약할 수 있습니다.

자원 최적화

배포 크기 조정은 시스템 요구 사항을 충족시키기 위한 자원에 대한 예측일 뿐 아니라 위험 관리 및 자원 관리 모두에 대한 연습이기도 합니다. 설계에서 위험 관리와 자원 관리를 처리하는 방법이 비즈니스 목표를 충족시키는 열쇠가 되기도 합니다.

위험 관리

비즈니스 요구 사항과 사용량 분석 같은 크기 조정의 기반이 되는 정보 대부분은 경험적인 데이터가 아니라 예측과 예상을 기반으로 하는 데이터입니다. 계획된 배포의 크기 조정을 완료하기 전에 데이터를 다시 고려하여 크기 조정 설계에서 예측 또는 예상들 간의 적절한 편차를 고려하고 있는지 확인합니다.

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

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

덜 사용한 자원을 성공에 필수적인 다른 영역에 적용할 수 있는 기회를 잃기 때문에 자원을 지나치게 사용하면 설계가 실패할 수도 있습니다. 또한 지나친 솔루션도 계약을 성실하게 이행하지 못한 것으로 간주할 수 있습니다.

자원 관리

자원 관리는 사용 가능한 모든 크기 조정 옵션을 분석하고 비용을 최소화하면서도 시스템 요구 사항을 이행하는 가장 적합한 솔루션을 선택하는 과정입니다. 여기에는 한 영역의 이점이 다른 영역의 비용으로 상쇄되지 않도록 각 설계 결정 간의 균형을 조절하는 방법을 이해하는 것이 포함됩니다.

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

크기 조정 전략을 완료하기 전에 결정을 검토하여 자원 사용과 설계의 전체적인 이점 간의 균형이 맞는지 확인합니다. 여기에서는 일반적으로 한 영역의 시스템 품질이 다른 시스템 품질에 어떤 영향을 미치는지도 검토합니다. 다음 표에서는 자원 관리를 위해 고려할 수 있는 일부 항목을 나열합니다.

표 5-2
자원 관리 항목
항목	설명
성능	개별 서버의 CPU에 집중하는 성능 솔루션의 경우 서비스에서 컴퓨팅 성능을 효율적으로 이용할 수 있습니다. 예를 들어, 일부 서비스의 경우 효율적으로 사용할 수 있는 CPU 개수에 한계가 있습니다.
잠재 용량	성능 예상치를 초과하는 로드를 처리하기 위한 전략이 있습니까? 서버의 세로 확장, 다른 서버에 대한 로드 균형 조정 또는 둘 다를 사용하여 과도한 로드를 처리합니까? 배포 확장을 위한 다음 시점까지 비정상적인 최고 로드를 처리할 만큼 잠재 용량이 충분합니까?
보안	보안 트랜잭션을 처리하는 데 필요한 성능 오버헤드를 충분히 고려했습니까?
가용성	가로로 중복된 솔루션의 경우 장기 유지 보수 비용을 충분히 예상했습니까? 시스템을 유지 보수하는 데 필요한 예약된 중단 시간을 고려했습니까? 고성능 서버와 저성능 서버 간의 비용을 공정하게 고려했습니다?
확장성	배포를 확장하기 위한 중요 시점을 예상했습니까? 배포 확장의 중요 시점까지 예상되는 로드 증가를 처리할 충분한 잠재적 용량을 제공하는 전략이 있습니까?
서비스 가능성	가용성 설계에서 관리, 모니터링 및 유지 보수 비용을 고려했습니까? 관리 비용을 줄이기 위해 사용자가 직접 일부 관리 작업을 수행할 수 있도록 하는 위임 관리 솔루션을 고려해 보았습니까?

예제 배포 구조

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


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

세부 설계 지정

배포 구조를 완료한 후 고객이 검토하는 기간이 있고 프로젝트 승인이 뒤를 잇습니다. 일부 경우 고객이 승인하기 전에 배포 구조를 변경하라고 다시 지시할 수도 있습니다.

프로젝트 승인 후 배포 구현의 출발점이 되는 세부 설계 지정을 작성합니다. 설계 지정에는 자세한 LDAP 디렉토리 지정뿐만 아니라 특정 하드웨어 자원 및 네트워크 장치에 대한 세부 사항도 포함됩니다.

이전 목차 다음
Sun Java Enterprise System 배포 계획 백서