test

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

서비스 품질 요구 사항 적용

서비스 품질(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 서비스 가능성 요구 사항 항목

항목 

설명 

중단 시간 계획 

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

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

사용 패턴 

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

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

가용성 

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

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

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

진단 및 모니터링 

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

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