Page 29 -
P. 29
부하를 바탕으로 ‘배치 처리는 어느 정도의 처리 시간까지 허용할지’, ‘업무 처리는 어느 정도의 응
답 시간까지 허용할지’ 같은 요구사항을 의미합니다.
또 성능 목표치는 각 업무의 작업 내용에 따라 그 값이 달라집니다.
예를 들어 야간에 하는 백업 배치 작업이라면 오전 업무 시작 전까지 배치 작업을 완료해야 한다
는 요구사항을 충족해야 합니다. 또 온라인 작업 중에서도 조회 작업인지, 갱신 작업인지에 따라
요구하는 응답 시간의 성능 목표치가 달라집니다. 조회 작업 시스템은 데이터를 조회만 하기에 처
리 속도가 빠르지만, 갱신 작업 시스템은 데이터베이스 레코드 삽입이나 갱신 처리가 들어가므로
조회 작업 시스템에 비해 처리 속도가 느립니다. 따라서 작업 내용에 따라 목표치를 설정해야 합
니다.
성능 목표치를 잘못 정의하면 처리 능력이 부족한 시스템이 가동되어 충분한 서비스를 제공하기
어려울 수 있습니다. 그 결과 나중에 리소스를 추가하는 등 추가 비용이 발생하는 리스크가 나타
납니다.
3. 리소스 확장성
리소스 확장성은 시스템이 가동을 시작한 후 시스템 리소스가 부족할 때의 대책에 대한 요구사항
입니다. 리소스 확장성도 앞서 설명한 성능 목표치와 마찬가지로 업무 처리량으로 구한 정보를 바
탕으로 요구사항을 정의합니다. 예를 들어 ‘3년 후에는 시스템 사용자가 급증한다는 주장을 근거
로 시스템의 부하 증가량을 예측하여 어느 정도의 리소스 확장이 가능한 시스템을 구축할지’ 같은
내용을 검토해야 합니다.
시스템 가동 3년 후 시스템에 접속하는 사용자 수가 현재의 2배로 증가할 것으로 예상한 경우에
는 3년 후를 내다보고, 구축 초기 시점에 CPU나 메모리의 리소스 용량을 손쉽게 스케일업할 수
있는 모델을 선정하거나 스케일아웃할 수 있는 아키텍처를 선정해야 합니다.
이런 리소스 확장성을 잘못 예측하면 나중에 리소스가 부족할 때 리소스를 강화하지 못하고 시스
템을 교체하거나 재구축해야 하는 등 작업 비용이 많이 드는 리스크가 발생합니다. 반대로 필요
이상으로 고비용 시스템을 구축하면 하드웨어의 과잉 투자로 이어질 수 있습니다. 따라서 리소스
확장성 요구사항을 결정할 때는 미래를 내다본 예측치를 제대로 조사하고 요구사항을 정의해야
합니다.
60
인프라_07.indd 60 2020-12-09 오전 11:21:31