test

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

3장 기술 요구 사항

솔루션 라이프 사이클의 기술 요구 사항 단계 중에 사용 분석을 수행하고 사용 사례를 식별하며 제안된 배포 솔루션에 대한 서비스 품질 요구 사항을 결정합니다.

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

기술 요구 사항 정보

기술 요구 사항 분석은 솔루션 라이프 사이클의 비즈니스 분석 단계 중에 작성된 비즈니스 요구 사항 문서로 시작됩니다. 비즈니스 분석을 기반으로 하여 다음을 수행합니다.

사용 분석

사용 분석에서는 설계하려는 솔루션의 다양한 사용자를 식별하고 이러한 사용자들의 사용 패턴을 판별합니다. 수집한 정보는 시스템의 로드 조건을 예상하기 위한 기반을 제공합니다. 또한 사용 분석 정보는 사용 사례에 설명되어 있는 사용 사례에 가중치를 할당할 때 사용할 수 있습니다.

사용 분석 동안에는 가능하면 사용자를 인터뷰하고 사용 패턴에 대한 기존 데이터를 조사하며 이전 시스템의 설계자와 관리자도 인터뷰해야 합니다. 다음 표에서는 사용 분석을 수행할 때 고려해야 할 요소를 나열합니다.

표 3–1 사용 분석 요소

항목 

설명 

사용자 수 및 유형 

솔루션에서 지원해야 할 사용자 수를 식별하고 필요하면 해당 사용자를 범주화합니다. 

예를 들면 다음과 같습니다. 

  • B2C(기업-사용자) 솔루션에는 방문자가 많을 수 있지만 비즈니스 트랜잭션에 등록 및 관여하는 사용자 수는 적습니다.

  • B2E(기업-직원) 솔루션에는 일부 직원이 기업 네트워크 밖에서 액세스할 필요가 있을 수도 있겠지만 일반적으로 각 직원을 수용합니다.B2E 솔루션에서 관리자는 정규 직원이 액세스할 수 없는 영역에 대한 권한 부여가 필요할 수 있습니다.

활성 및 비활성 사용자 

활성 및 비활성 사용자의 사용 패턴과 비율을 식별합니다. 

활성 사용자는 시스템에 로그인하여 시스템의 서비스와 상호 작용하는 사용자입니다. 비활성 사용자는 로그인하지 않은 사용자, 로그인했지만 시스템 구성 요소와 상호 작용하지 않는 사용자 또는 데이터베이스에는 있지만 한 번도 로그인하지 않은 사용자입니다. 

관리 권한이 있는 사용자 

배포된 시스템을 액세스하는 배포를 모니터, 업데이트 및 지원하는 사용자를 식별합니다. 

기술 요구 사항에 영향을 미칠 수 있는 특정 관리 사용 패턴(예를 들면 방화벽 밖에서 배포 관리)을 판별합니다.  

사용 패턴 

다양한 유형의 사용자가 시스템을 액세스하고 예상되는 사용의 대상을 제공하는 방법을 식별합니다. 

예를 들면 다음과 같습니다. 

  • 사용이 급상승하는 최고 시간이 있습니까?

  • 업무 시간은 언제입니까?

  • 사용자가 전 세계에 분산되어 있습니까?

  • 예상되는 사용자 연결 시간은 얼마입니까?

사용자 증가 

사용자 기반 크기가 고정되어 있는지 또는 배포에서 사용자 수의 증가를 예상하는지 여부를 결정합니다. 

사용자 기반이 증가할 것으로 예상되는 경우 이러한 증가를 합리적으로 예측해 봅니다. 

사용자 트랜잭션 

지원해야 할 사용자 트랜잭션 유형을 식별합니다. 이 사용자 트랜잭션을 사용 사례로 변환할 수 있습니다. 

예를 들면 다음과 같습니다. 

  • 사용자가 수행할 작업은 무엇입니까?

  • 사용자가 로그인하면 로그인한 상태로 남아 있습니까? 대개 몇 가지 작업을 수행하고 로그아웃합니까?

  • 공통 달력, 웹 회의실 및 내부 웹 페이지 배포가 필요한 사용자 간에 중요한 공동 작업이 있습니까?

사용자 연구 및 통계 데이터 

기존 사용자 연구 및 기타 소스를 사용하여 사용자 동작 패턴을 결정합니다. 

종종 기업이나 산업 조직에서는 사용자에 대한 유용한 정보를 추출할 수 있는 사용자 조사 연구를 수행합니다. 기존 응용 프로그램의 로그 파일에는 시스템 예측을 하는 데 유용한 통계 데이터가 포함되어 있을 수 있습니다. 

사용 사례

사용 사례에서는 설계 중인 솔루션과 사용자 간의 일반적인 상호 작용을 모델링하여 최종 사용자 관점에서 전체 작업 흐름을 설명합니다. 사용 사례의 전체 집합과 관련하여 설계의 우선 순위를 정하면 예상되는 기능의 제공에 계속 초점을 맞출 수 있습니다. 사용 사례는 논리적 설계에 대한 중요한 입력이 됩니다.

가중치가 가장 높은 사용 사례가 가장 일반적인 사용자 작업을 나타내도록 상대적인 가중치를 사용 사례에 할당합니다. 사용 사례 가중치는 가장 많이 사용되는 시스템 서비스의 설계 결정에 초점을 맞출 수 있게 합니다.

다음 두 가지 수준으로 사용 사례를 설명할 수 있습니다.

서비스 품질 요구 사항 적용

서비스 품질(QoS) 요구 사항은 성능, 가용성, 확장성 및 서비스 가능성과 같은 기능의 시스템 품질을 지정하는 기술 사양입니다. 서비스 품질 요구 사항은 비즈니스 요구 사항에 지정된 비즈니스 요구에 의해 구성됩니다. 예를 들면 서비스를 일년 내내 24시간 사용할 수 있어야 하는 경우 가용성 요구 사항에서 이 비즈니스 요구 사항을 처리해야 합니다.

다음 표에서는 일반적으로 서비스 품질 요구 사항의 기반을 구성하는 시스템 품질을 나열합니다.

표 3–2 서비스 품질 요구사항에 영향을 미치는시스템 품질

시스템 품질 

설명 

성능 

사용자 로드 조건에 따른 응답 시간 및 처리 능력 측정 

가용성 

최종 사용자가 시스템의 자원 및 서비스에 액세스할 수 있는 빈도에 대한 측정이며 대개 시스템의 가동 시간으로 표시됩니다.

가용성 

시간에 따라 배포된 시스템에 용량 및 사용자를 추가할 수 있는 기능. 확장성은 일반적으로 시스템에 자원을 추가하는 것을 포함하지만 배포 구조 변경을 요구해서는 안 됩니다. 

보안 

시스템과 그 사용자의 무결성을 설명하는 요소들의 복잡한 조합. 보안은 사용자의 권한 부여 및 인증, 데이터 보안 및 배포된 시스템으로의 보안 액세스를 포함합니다. 

잠재 용량 

추가 자원 없이 비정상적인 최고 로드 사용을 처리할 수 있는 시스템의 기능. 잠재 용량은 가용성, 성능 및 확장성 품질의 요소입니다.  

서비스 가능성 

시스템 모니터링, 발생하는 문제 처리, 하드웨어 및 소프트웨어 구성 요소 업그레이드 등을 포함하여 배포된 시스템의 관리 용이성.  

시스템 품질은 서로 밀접하게 관련되어 있습니다. 한 가지 시스템 품질의 요구 사항이 다른 시스템 품질의 요구 사항 및 설계에 영향을 미칠 수 있습니다. 예를 들어 높은 수준의 보안은 성능에 영향을 미칠 수 있고 성능은 다시 가용성에 영향을 미칠 수 있습니다. 가용성 문제를 처리하기 위해 서버를 추가하면 서비스 가능성(유지 보수 비용)에 영향을 미칠 수 있습니다.

시스템 품질이 어떻게 연관되어 있는지 이해하고 다른 품질 간의 균형을 조절하는 것이 비즈니스 요구 사항과 비즈니스 제약 조건을 모두 성공적으로 충족시키는 시스템을 설계할 수 있는 비결입니다.

다음 절에서는 서비스 품질 요구 사항을 구성할 때 고려할 요소에 대한 지침을 제공하면서 더 나아가 배포 설계에 영향을 미치는 시스템을 설명합니다. 서비스 수준 계약의 기반을 구성하는 서비스 수준 요구 사항에 관한 절도 포함됩니다.

성능

비즈니스 요구 사항은 일반적으로 비기술적 용어로 응답 시간을 지정하는 성능을 표현합니다. 예를 들어 웹 기반 액세스에 대한 비즈니스 요구 사항에서 다음과 같이 기술할 수 있습니다.

사용자는 로그인 시 일반적으로 4초 이하의 적당한 응답 시간을 기대합니다.

이 비즈니스 요구 사항을 출발점으로 하여 모든 사용 사례를 조사하고 이 요구 사항을 시스템 수준으로 표현하는 방법을 결정합니다. 어떤 경우에 사용 분석 중에 결정된 사용자 로드 조건을 포함하고자 할 수도 있습니다. 각 사용 사례의 성능 요구 사항을 지정한 로드 조건에 따른 응답 시간이나 응답 시간 및 처리 능력으로 표현합니다. 허용 가능한 오류 수를 지정할 수도 있습니다.

다음은 성능에 대한 시스템 요구 사항을 지정하는 방법의 두 가지 예입니다.

성능 요구 사항은 가용성 요구 사항(페일오버가 성능에 어떤 영향을 미치는지) 및 잠재 용량(비정상적인 최고 로드를 처리하기 위한 용량이 얼마나 있는지)과 밀접하게 관련되어 있습니다.

가용성

가용성은 시스템의 가동 시간을 지정하는 한 방법으로 일반적으로 사용자가 시스템을 액세스할 수 있는 시간 백분율로 측정합니다. 시스템에 액세스할 수 없는 시간(중단 시간)은 하드웨어, 소프트웨어 또는 네트워크의 오류나 시스템을 중단시키는 기타 요소(예: 정전)로 인한 것일 수 있습니다. 서비스의 예정된 중단 시간(유지 보수 및 업그레이드)은 중단 시간으로 고려하지 않습니다. 시스템 가용성을 계산하는 기본 등식을 가동 시간에 대한 백분율로 보면 다음과 같습니다.

Availability = uptime / (uptime + downtime) * 100%

대개 사용자가 달성할 수 있는 “9의 개수”로 가용성을 측정합니다. 예를 들어 99% 가용성은 9가 두 개입니다. 9를 추가로 지정하면 배포 설계에 상당한 영향을 미칩니다. 다음 표는 하루 24시간 365일(총 8,760시간) 실행되는 시스템의 가용성에 9를 추가하여 예정되지 않은 중단 시간을 계산한 것입니다.

표 3–3 1년 내내(8,760시간) 실행되는 시스템의 예정되지 않은 중단 시간

9의 개수 

사용 가능한 백분율 

예정되지 않은 중단 시간 

2 

99% 

88시간 

3 

99.9% 

9시간 

4 

99.99% 

45분 

5 

99.999% 

5분 

고장 허용 시스템

9가 네 개 또는 다섯 개인 가용성 요구 사항에서는 일반적으로 고장 허용 시스템을 요구합니다. 고장 허용 시스템은 하드웨어나 소프트웨어 오류 중에도 서비스를 계속할 수 있어야 합니다. 일반적으로 고장 허용은 중요 서비스를 제공하는 하드웨어(예:CPU, 메모리 및 네트워크 장치)와 소프트웨어 모두의 중복을 통해 달성됩니다.

단일 오류 지점은 중요 경로의 일부이지만 중복 구성 요소가 백업하지 않는 하드웨어 또는 소프트웨어 구성 요소입니다. 이 구성 요소의 실패는 시스템의 서비스가 손실을 일으킵니다. 고장 허용 시스템을 설계할 때는 잠재적인 단일 오류 지점을 식별하여 제거해야 합니다.

고장 허용시스템은구현 및 유지 보수 비용이 많이들 수 있습니다. 가용성에 대한 비즈니스 요구 사항 특성을 이해하고 이러한 요구 사항을 충족시키는 가용성 솔루션의 전략과 비용을 고려해야 합니다.

서비스 가용성 우선 순위 지정

사용자 관점에서 가용성은 종종 전체 시스템의 가용성보다는 서비스별로 적용합니다. 예를 들면 Instant Messaging Service의 비가용성은 대개 다른 서비스의 가용성에 영향을 적게 미치거나 영향을 미치지 않습니다. 그러나 많은 다른 서비스가 종속된 서비스(예: Directory Server)의 비가용성은 보다 폭 넓은 영향을 미칩니다. 높은 가용성 사양은 가용성 증가가 필요한 특정 사용 사례 및 사용 분석을 확실하게 참조해야 합니다.

정렬된 우선 순위 집합에 따라 가용성 요구 사항을 나열하는 것이 도움이 될 수 있습니다. 다음 표에서는 여러 서비스 유형의 가용성에 대한 우선 순위를 지정합니다.

표 3–4 우선 순위별 서비스 가용성

우선 순위 

서비스 유형 

설명 

1 

임무 결정적 

항상 사용 가능해야 하는 서비스예를 들면 응용 프로그램에 대한 데이터베이스 서비스(예:LDAP 디렉토리)입니다. 

2 

사용 가능해야 함 

사용 가능해야 하지만 성능은 떨어져도 관계 없는 서비스예를 들면 메시지 서비스 가용성은 일부 비즈니스 환경에서는 중요하지 않을 수도 있습니다. 

3 

연기할 수 있음 

지정한 기간 내에 사용 가능해야 하는 서비스예를 들면 달력 서비스 가용성은 일부 비즈니스 환경에서 필수적이지 않을 수도 있습니다. 

4 

선택 사항 

무기한 연기할 수 있는 서비스예를 들면 일부 환경에서는 Instant Messaging Service가 유용하지만 필수적이지는 않다고 간주할 수 있습니다. 

서비스 손실

가용성 설계는 가용성이 문제가 될 때 또는 구성 요소를 손실했을 때 발생하는 상황에 대한 고려를 포함합니다. 이것은 연결된 사용자가 세션을 재시작해야 하는지 및 한 영역의 실패가 시스템의 다른 영역에 어떻게 영향을 미치는지에 대한 고려를 포함합니다. 서비스 품질 요구 사항은 이러한 시나리오를 고려하여 이러한 상황에서 배포가 반응하는 방법을 지정해야 합니다.

가용성

확장성은 시스템에 용량을 추가하여 시스템이 기존 사용자 또는 증가된 사용자 기반으로부터의 추가 로드를 지원할 수 있도록 하는 기능입니다. 대개 확장성은 자원 추가를 요구하지만 배포 구조의 설계 변경이나 자원 추가에 필요한 시간으로 인한 서비스 손실을 요구해서는 안 됩니다.

가용성처럼 확장성도 전체 시스템보다는 시스템에서 제공하는 개별 서비스에 적용되는 경우가 많습니다. 그러나 Directory Server처럼 다른 서비스가 종속되어 있는 서비스의 경우 확장성은 시스템 전체에 영향을 미칠 수 있습니다.

비즈니스 요구 사항에서 예상되는 배포의 증가를 명확하게 기술하지 않는 경우 서비스 품질 요구 사항과 함께 확장성 요구 사항을 지정할 필요는 없습니다. 그러나 솔루션 라이프 사이클의 배포 설계 단계 중에 배포 구조는 확장성을 위한 서비스 품질 요구 사항을 지정하지 않았다고 하더라도 시스템을 확장하기 위한 일부 허용을 추가해야 합니다.

증가 예상

확장성 요구 사항을 결정하기 위한 시스템 증가 예상은 달성할 수 없을지도 모르는 예상, 예측 및 추측 작업을 포함합니다. 확장 가능한 시스템 요구 사항을 개발하기 위한 세 가지 비결은 다음과 같습니다.

다음 표에서는 확장성 요구 사항을 결정하는데 고려할 요소를 나열합니다.

표 3–5 확장성 요소

항목 

설명 

사용 패턴 분석 

기존 데이터를 조사하여 현재 또는 예상된 사용자 기반의 사용 패턴을 이해합니다. 현재 데이터가 없을 경우 산업 데이터나 시장 예측을 분석합니다.  

합리적인 최대 규모에 대한 설계 

알려진 요구와 가능한 요구 모두에 대한 최대 필수 규모와 관련된 목표를 사용하여 설계합니다. 

종종 이 규모는 기존 사용자 로드와 합리적으로 예상된 장래 로드에 대한 성능 평가를 기준으로 24개월에 대해 예측하는 양입니다. 예측 기간은 예상의 신뢰성에 따라 상당히 다릅니다. 

적절한 중요 시점 설정 

예상치 못한 증가를 수용하는 버퍼가 포함된 단기간 요구 사항을 충족시키기 위한 증분 배포 설계를 구현합니다. 시스템 자원을 추가할 중요 시점을 설정합니다.  

예를 들면 다음과 같습니다. 

  • 자본 취득(예:분기별 또는 연별)

  • 하드웨어 및 소프트웨어 구입 선행 시간(예:1주일에서 6주까지)

  • 버퍼(증가 예상에 따라 10% - 100%)

최신 기술 통합 

최신 기술(예:더 빠른 프로세서와 웹서버)과 이 기술이 기본 구조의 성능에 어떻게 영향을 미칠 수 있는지 이해합니다. 

보안 요구 사항

보안은 배포된 시스템의 모든 수준과 관련된 복잡한 사안입니다. 보안 요구 사항 개발은 보안 위협 식별 및 그 위협을 해결할 전략 개발을 고려합니다. 이 보안 분석은 다음과 같은 단계를 포함합니다.

  1. 중요 자산 식별

  2. 해당 자산에 대한 위협 식별

  3. 조직에 대한 위기를 일으키는 위협을 드러내는 취약점 식별

  4. 조직에 대한 위기를 완화시키는 보안 계획 개발

보안 요구 사항 분석은 관리자, 비즈니스 분석자 및 정보 기술 직원을 비롯한 모든 이해 관계자의 크로스섹션을 포함해야 합니다. 종종 어떤 조직에서는 보안 설계자를 정하여 보안 방법의 설계 및 구현에서 선두에 섭니다.

다음 절에서는 보안 계획의 일부 영역을 설명합니다.

보안 계획 요소

시스템 보안 계획은 구현 성공에 필수적인 배포 설계의 일부입니다. 보안 계획 시 다음을 고려하십시오.

잠재 용량

잠재 용량은 자원을 추가하지 않고 비정상적인 최고 로드 사용을 처리할 수 있는 배포 기능입니다. 일반적으로 잠재 용량과 관련된 서비스 품질 요구 사항을 직접 지정하지는 않지만 이 시스템 품질은 시스템의 가용성, 성능 및 확장성 요구 사항의 한 요소입니다.

서비스 가능성 요구 사항

서비스 가능성은 시스템 모니터링, 발생한 문제 복구, 시스템에 사용자 추가 및 제거, 하드웨어 및 소프트웨어 구성 요소 업그레이드 등을 포함하여 배포된 시스템을 얼마나 쉽게 유지 보수할 수 있는가를 말합니다.

서비스 가능성 요구 사항을 계획할 때는 다음 표에 나열된 항목을 고려합니다.

표 3–6 서비스 가능성 요구 사항 항목

항목 

설명 

중단 시간 계획 

특정 서비스를 사용할 수 없게 하거나 부분적으로 사용할 수 없게 해야 하는 유지 보수 작업을 식별합니다. 

일부 유지 보수 및 업그레이드는 사용자 중단 없이 이루어지지만 서비스를 중단해야 하는 경우도 있습니다. 가능하면 사용자와 함께 중단 시간이 필요한 유지 보수 작업을 예약하여 사용자가 중단 시간을 대비할 수 있도록 합니다. 

사용 패턴 

유지 보수 일정을 예약하기 위한 최상의 시간을 결정하는 사용 패턴을 식별합니다.  

예를 들면 일반 업무 시간 중에 사용량이 최고인 시스템은 저녁이나 주말에 유지 보수 일정을 예약합니다. 지리적으로 분산된 시스템의 경우 이 시간을 식별하기가 더 어려울 수 있습니다. 

가용성 

서비스 가능성은 종종 가용성 설계를 반영합니다. 유지 보수 및 업그레이드를 위한 중단 시간을 최소화하기 위한 전략의 중요한 부분은 가용성 전략입니다. 높은 수준의 가용성을 요구하는 시스템에서는 유지 보수, 업그레이드 및 복구를 할 기회가 훨씬 적습니다. 

가용성 요구 사항을 처리하기 위한 전략은 유지 보수 및 업그레이드를 처리하는 방법에 영향을 미칩니다. 예를 들어 지리적으로 분산된 시스템의 경우 서비스 가능성은 유지 보수 기간 중에 작업 로드를 원격 서버에 라우트할 수 있는 기능에 달려있을 수 있습니다. 

또한 높은 수준의 가용성이 필요한 시스템에는 사용자 간섭 없이도 시스템을 자동으로 다시 시작하는 더 복잡한 솔루션이 필요할 수 있습니다. 

진단 및 모니터링 

정기적으로 진단 및 모니터링 도구를 실행하여 문제 영역을 식별하면 시스템의 안정성을 개선할 수 있습니다. 

시스템을 정규적으로 모니터링하면 문제가 발생하기 전에 방지하고 가용성 전략에 따라 작업 로드의 균형을 조정하며 유지 보수 및 중단 시간을 더 잘 계획할 수 있습니다. 

서비스 수준 요구 사항

서비스 수준 계약(SLA)은 최소 성능 요구 사항과 해당 요구 사항 달성 실패, 제공되어야 할 고객 지원의 수준 및 범위에 대해 지정합니다. 서비스 수준 계약은 SLA가 기반으로 하는 조건을 지정한 시스템 요구 사항입니다.

서비스 품질 요구 사항과 마찬가지로 서비스 수준 계약은 비즈니스 요구 사항에서 나오며 배포된 시스템이 달성해야 할 전반적인 시스템 품질에 대한 보증을 나타냅니다. 서비스 수준 계약은 계약으로 간주되기 때문에 서비스 수준 요구 사항의 사양은 모호하지 않아야 합니다. 서비스 수준 요구 사항에서는 요구 사항을 검사하는 기준과 요구 사항을 충족시키는 데 실패한 것으로 간주되는 경우 정확하게 정의해야 합니다.