Page 29 -
P. 29

부하를 바탕으로 ‘배치 처리는 어느 정도의 처리 시간까지 허용할지’, ‘업무 처리는 어느 정도의 응
               답 시간까지 허용할지’ 같은 요구사항을 의미합니다.

               또 성능 목표치는 각 업무의 작업 내용에 따라 그 값이 달라집니다.
               예를 들어 야간에 하는 백업 배치 작업이라면 오전 업무 시작 전까지 배치 작업을 완료해야 한다

               는 요구사항을 충족해야 합니다. 또 온라인 작업 중에서도 조회 작업인지, 갱신 작업인지에 따라
               요구하는 응답 시간의 성능 목표치가 달라집니다. 조회 작업 시스템은 데이터를 조회만 하기에 처
               리 속도가 빠르지만, 갱신 작업 시스템은 데이터베이스 레코드 삽입이나 갱신 처리가 들어가므로

               조회 작업 시스템에 비해 처리 속도가 느립니다. 따라서 작업 내용에 따라 목표치를 설정해야 합
               니다.

               성능 목표치를 잘못 정의하면 처리 능력이 부족한 시스템이 가동되어 충분한 서비스를 제공하기
               어려울 수 있습니다. 그 결과 나중에 리소스를 추가하는 등 추가 비용이 발생하는 리스크가 나타
               납니다.



               3. 리소스 확장성

               리소스 확장성은 시스템이 가동을 시작한 후 시스템 리소스가 부족할 때의 대책에 대한 요구사항
               입니다. 리소스 확장성도 앞서 설명한 성능 목표치와 마찬가지로 업무 처리량으로 구한 정보를 바
               탕으로 요구사항을 정의합니다. 예를 들어 ‘3년 후에는 시스템 사용자가 급증한다는 주장을 근거

               로 시스템의 부하 증가량을 예측하여 어느 정도의 리소스 확장이 가능한 시스템을 구축할지’ 같은
               내용을 검토해야 합니다.
               시스템 가동 3년 후 시스템에 접속하는 사용자 수가 현재의 2배로 증가할 것으로 예상한 경우에

               는 3년 후를 내다보고, 구축 초기 시점에 CPU나 메모리의 리소스 용량을 손쉽게 스케일업할 수
               있는 모델을 선정하거나 스케일아웃할 수 있는 아키텍처를 선정해야 합니다.

               이런 리소스 확장성을 잘못 예측하면 나중에 리소스가 부족할 때 리소스를 강화하지 못하고 시스
               템을 교체하거나 재구축해야 하는 등 작업 비용이 많이 드는 리스크가 발생합니다. 반대로 필요
               이상으로 고비용 시스템을 구축하면 하드웨어의 과잉 투자로 이어질 수 있습니다. 따라서 리소스

               확장성 요구사항을 결정할 때는 미래를 내다본 예측치를 제대로 조사하고 요구사항을 정의해야
               합니다.








         60





     인프라_07.indd   60                                                                       2020-12-09   오전 11:21:31
   24   25   26   27   28   29   30   31   32   33   34