정보시스템 운영관리지침 4.성능관리지침 2)성능관리 프로세스

연재중인 이전 글 보기

앞서, 성능관리지침의 개요에 대해서 알아보았습니다. 이번 글은 성능관리 프로세스 세부내용에 대한 글입니다.

4. 정보시스템 성능관리

4. 성능관리 프로세스
image002

가) 사전준비

① 계획수립 및 요구사항 검토

: 계획 수립시, 최적의 조건(합당한 비용으로 적재적소, 적절한 성능과 용량을 유지)으로 사용되고 합의된 성능 및 처리율이 달성되어 유지되도록 한다.

– 현황분석

· 대상 IT인프라 시스템에 대한 현황분석
· 시스템의 서비스 아키텍처, 업무목표, 하드웨어 구성현황, 사용자들의 정보시스템을 사용하는 경향에 대한 분석
· ‘업무 관점에서 성능 요구사항’을 분석
· 성능계획 수립의 기준 설립 (SLA 및 사용자 만족도에 대한 현실적인 업무특성 고려)

– SLA(Service level Agreement:서비스수준협약)의 요구 성능 수준
: 서비스사용자가 요구하는 응답시간 또는 처리량, 가동률, 성능장애율 등을 수치화하여 서비스 수준에 대한 명확한 기대치를 제공

– 사용자의 만족도 및 요구사항

· 사용자의 만족도와 요구사항을 가장 적극적으로 반영
· 사용자의 만족도는 최대한 수치와 정량화 하여 성능상의 임계치로 환산하여 적용하거나 조직의 업무 프로세스를 유지하기 위한 목표로 설정

– 성능 평가 기준치(Baseline) 설정

· 성능관리 모니터링은 서비스가 정상적으로 운영될 때와 성능상의 문제점이 발생한 기간 모두 실시

– 기대효과

· 성능관리를 통하여 시스템자원의 사용률, 응답시간, 처리량과의 상관관계를 분석할 수 있게 되며, 따라서 비정상적으로 사용되는 자원을 튜닝하게 되어 비용의 개선효과를 가져올 수 있음.

※ 또한 성능관리 계획수립에 다음 내용이 포함되어야 합니다.

– 성능 병목현상 방지 및 해소 방안
– 용량계획 수립에 반영
– 서비스에 대한 관리보고
– 성능 모니터링 및 진단
– 작업 재분배(로드 밸런싱)
– 성능 추이 분석, 미래의 자원 요구 추정 자료 수집
– 서비스에 대한 처리량, 응답속도의 측정
– 성능 조정(튜닝) 및 장애 해결
– 문제가 발생하기 전에 미리 예측된 성능 문제를 예방

② 성능 측정 및 분석 방안 수립

성능관리의 반복적인 활동
성능관리의 반복적인 활동

– 성능관리 대상 및 측정항목 설정

· 서비스중인 각각의 IT인프라 자원에 대해 처리량, 응답시간, 자원사용량, 효율성을 구분하여 데이터 수집할 수 있도록 측정항목 설정
· 수집된 데이터를 바탕으로 총 자원 사용과 각각의 서비스가 특정자원에 부여하는 부하에 대한 세부 프로파일 작성

– 임계치 설정시 고려요소

· 제작사(Vendor)의 성능 판단 기준 자료 및 권고사항
· SLA 기준
· IT 인프라 업무 목적에 따른 활용 형태
· 사용자의 만족도(응답시간, 처리량) 평가 결과
· 운영상태 관리 분야로부터의 피드백
· 성능관리 책임자는 연계분야와의 인터페이스를 통하여 임계치를 유연하게 판단
※ 임계치는 다양한 환경적 요소를 반영하여 변경 및 조정될 수 있으며, 주변요소(Server, Network, DBMS, Application)의 영향을 받아 변경될 수 있다)

③ 성능측정 환경 구현

– 성능측정 환경의 구현요건

· 측정 가능한 항목

– 성능측정을 위한 자동화 도구 활용 방법

· 성능 추이 분석, 성능 계획, 시스템 용량 증설에 대한 예측 기능이 제공 되도록 자동화 도구를 설정
· 성능 정보를 다양한 테이블, 그래프 형태로 모니터링
· 복수시스템 및 복수항목에 대한 성능정보를 동일한 화면에서 모니터링
· 모니터링된 성능 측정치에 대해 실시간으로 산술 연산 및 논리 연산을 통해 가공된 성능 정보를 제공할 수 있도록 자동화 도구를 설정
· 사용자 요구에 따라 각 관리대상 서버의 상황에 맞게 관리항목을 추가, 수정, 삭제
· 각 대상 시스템에 대한 성능항목 및 측정 주기, 측정 방법, 저장방법을 적용
· 성능 데이터의 상대적 변동량에 대한 임계치를 설정하여 임계치 초과 이벤트 정보는 성능 관리자에게 전달
· 임계치 초과 이벤트 정보는 자동 통보 기능 이용

– 성능 측정의 영향도 분석

: 성능측정을 위해 설정된 측정환경이 시스템 성능상태를 저하시켜 정상적인 어플리케이션 자원을 빼앗지 않도록 주의하며, 어쩔 수 없는 경우에는 Peak Time을 피하여 실행

– 성능 측정 항목별 성능 추이 및 성능 수준 분석

· 개별적 측정 항목별 성능 데이터의 기록 누적
· 누적 개별데이터 추이분석을 통한 일별, 주간별, 월별 성능상태분석
· 각각의 측정 항목별 분석 기록 기반 DBMS 전반의 통합적인 성능분석을 위한 종합 분석

– 성능 측정 결과를 이용한 성능 분석 주기

· 안정된 성능상태를 보이는 측정항목에 대해서는 성능 분석주기를 조절
· 분석 주기를 조정하여 데이터 수집을 할 수 있으며, 이 때 시스템 과부하에 주의

– 종합적인 관점에서의 성능 추이 분석 보고서를 작성, 기록 및 유지

· 성능 측정을 통하여 분석된 각 구성요소별 데이터는 추후 통합성능관리 분야에서 취합되어 업무서비스 관점의 종합 성능 분석을 위해 사용

나) 분야별 성능 관리 프로세스

① 서버

– 데이터 수집 및 분석

· 측정항목은 (CPU 측정, 메모리 측정, 디스크 측정, 프로세스 측정, 커널 측정, 파일시스템 측정, 네트워크 I/O 측정 등)이 있으며, 세부적인 측정항목과 설명은 지침 본문을 참고하세요.
· 측정방법은 각각의 서버와 서버의 구성요소들에 대해 성능 측정이 가능한 환경을 구성하고, OS에서 제공하는 명령어나 시스템 성능 측정도구를 설치하여 데이터를 수집합니다.
· 성능데이터 수집을 위해 OS에서 제공하는 명령들에는 sar, vmstat, iostat, netstat 등이 있습니다.
· 분석방법 : 모니터링으로부터 수집된 데이터 분석을 통해 다음과 같은 문제점들을 식별할 수 있다.

· 경합(Contention) : 데이터, 파일, 메모리, 프로세서
· 사용가능한 자원에 대한 부적절한 워크로드(Workload)분배
· 부족한 자원 : CPU, 메모리, 디스크 등 충분하지 않은 구성요소들
· 메모리의 비효율적인 사용
· I/O의 조각화 현상
· 어플리케이션, DBMS 설계에 있어서 비효율성
· 트랜잭션 비율의 예상치 못한 증가

· 기준치 설정시 고려사항
: 일반적으로 사용률의 80% 이하에서 기준치를 설정합니다.

· 요구사항 검토 결과
· 각각의 서버가 제공하는 서비스의 특성(온라인, 배치 등)
· 서비스의 Peak 시간대, 사용자 수 등
· 과거 서버의 성능 데이터 분석을 통해 얻어진 결과치
· 시스템에 설치되어 운영되는 어플리케이션의 특성
· 분석주기

분석종류내용
일간
성능분석
각 측정항목별 시간대별 성능 추이 및 특정 경향을 벗어나는 성능 요소를 분석한다.
주간
성능분석
업무 특성상 주간 단위의 성능 추이 분석이 필요할 때 실시한다
월간(분기)
성능분석
일간, 주간 데이터를 취합하여 해당 월간(분기) 성능추이를 분석하고 지나간 월간(분기) 성능분석 자료와 비교하여 성능 권고안을 작성한다.
연간
성능분석
서버 용량에 대한 개선안 및 월간(분기) 단위로 작성된 개선안을 요약한 자료를 작성한다.
단, 작성 시기는 업무계획이나 예산 주기를 고려하여 정한다
비정규적인
성능 분석
SLA를 위반하는 현상이 발생하거나, 사용자의 요구가 있다면, 특정 IT서비스에 대해 비정규적인 성능 측정 및 분석을 실시한다. 특정 IT서비스에 영향을 주는 특정 하드웨어나 소프트웨어 자원을 식별하는 능력은 정확하고, 종합적인 성능분석 자료를 통해서 가능하다.

· 분석방법
: 주로 성능분석 자동화 도구를 이용하거나, 성능관리자에 의해 OS에서 제공하는 모니터링 도구를 이용하여, 수집된 성능측정 데이터를 각 항목별로 권장하는 기준치에 대한 성능과 비교분석한다.

· CPU성능분석 : CPU사용율(%), Run Queue Size 등을 분석한다.
· 메모리성능분석 : Physical Memory 사용량, Swap 사용율(%) 등을 분석한다.
· 디스크성능분석 : Disk Busy(%), Disk Usage(%) 등을 분석한다.
· 네트워크 성능분석 : 네트워크 패킷 비율(%), 네트워크 Collision 비율(%), 네트워크 트래픽 등을 분석한다.

– 성능 개선 방안 수립
: 임계치 초과, 사전예방, 성능개선을 수행하기 위한 개선 대상을 선정

· 성능저하 원인 파악
: 자원부족, 성능조정 부족, I/O 조각화 현상, 데이터 이동, 프로그래밍 오류, DB설계의 오류, 악성코드, 버그, 하드웨어down, 외부적요인, 구성요소의 부조화 등
· 방안수립
: 우선순위와 영향도를 고려하여, 각 담당자가 협의하여 개선대상 및 방안을 작성

image005

· 성능개선방안 수립 기초자료

 시스템 구성 환경(H/W 구성도, CPU 타입, 디스크 타입 등)
 데이터베이스 환경 구성 및 사용현황
 주요 어플리케이션 목록 및 사용현황
 네트워크 구성 및 사용현황
 시스템 구성 변경사항
 워크로드의 특성
 시스템의 처리량 변화
 시스템 사용자 수 및 동시 사용자 수
 프로세스 종류 및 사용 상태
 성능 장애 및 예외 사항 보고서

– 성능 개선 실행 및 검증

· 성능조정

· 구성조정하기 : 구성조정 및 가상메모리 Setup 조정하기
· 캐싱 : 자주 사용되는 메모리 데이터 영역의 확보
· 작업로드의 균형 조정 : 시작위치에 따라 특정게이트웨이에 있는 서버에 도달할 수 있으며, 게이트웨이에 대한 시작 지점 비율을 균형적으로 재배분
· 효율적인 메모리 사용 : 상황에 따라 메모리를 더 많이 또는 더 적게 사용하도록 한다.
· 스타라이핑 하드디스크 : 읽기와 쓰기가 동시에 일어나는 HDD의 영역을 논리적으로 구분해서 나누어 사용
· 압축 : 데이터 전송시 데이터 압축은 CPU 용량에 여유가 있을 경우 사용
· OS 파라미터 셋에 의한 성능조정
· 인프라스트럭쳐 병목현상 완화 : 특정구역의 병목현상을 줄이면 전체적인 성능을 높일 수 있음.

· 용량증설
: 기본적으로 사용자수, 응용프로그램이나 서비스의 사용자 증가하면 해당시스템의 용량을 늘려야 함. 그렇기 때문에 당연한 이야기이지만 미래의 필요한 용량을 산정하여 미리 준비하여야 합니다.

· 용량산정시 서버 및 디스크는 20~30% 여유율을 적용하여 산정

② 네트워크

– 데이터 수집 및 분석

· 측정항목

· 성능관리 항목별 관점의 측정항목

층정항목측정요소측정방법측정주기
가용성
(Availability)
네트워크 장비PING실시간
 응답시간
(Response Time)
네트워크 장비PING 응답시간실시간
어플리케이션패킷 캡쳐실시간
 장애율
(Error Rate)
회선(LAN-collision)SNMP실시간
회선(WAN)SNMP실시간
어플리케이션
분포
어플리케이션패킷 캡쳐실시간
사용률
(Utilization)
회선(LAN/WAN)SNMP/패킷 캡쳐실시간
네트워크 장비
(CPU, Memory, Buffer)
SNMP 실시간

※ 지침에서는 네트워크 데이터 측정은 WAN, CSU/DSU, LAN, 이더넷/RMON 등을 구분하여 측정예를 설명하고 있습니다.  예로, WAN은 평균사용률이 30%를 넘어가면 경고이며, 70%를 넘어가면 치명적 임계치로 하고 있으며, 오류율은 0.1%를 넘어가면 경고, 1%를 넘어가면 치명적으로 하고 있습니다. 자주 사용하는 것들을 표로 설명하면,

평균사용률(%)최고사용률(%)오류(%)포기(%)
경고치명경고치명경고치명경고치명
WAN307090980.110.11
CSU / DSU80100150200
LAN107025500.110.11
이더넷 / RMON152025400.11
FastEthernet255040800.11

·측정방법 : 간단한 성능데이터의 경우, OS제공 명령어를 이용하지만, 주로 NMS(Network management System) 도구를 이용하여 측정함
·분석방법

·Ping : 특정 IP Address에 접근가능여부 체크
·Ping 응답시간 : 짧을수록 좋지만, 테스트 당시 네트워크 부하에 따라 조금씩 차이가 날 수 있음.
·SNMP(Simple Network Management Protocol) : 네트워크 장비 모니터링 및 제어, 장애, 성능 관련 통계 수집 및 보안 등의 관리를 위한 프로토콜
·패킷캡쳐(Packet Capture) : 네트워크 성능관리 도구 이용

– 성능개선 방안 수립

·대상선정

·실시간 성능문제 : 성능문제현상으로 갑작스럽게 인터넷 접속이 느려지거나, ping은 되는데 메일 접속이 안되는 현상 등.
·비 실시간 성능문제 : 지난주에는 괜찮았는데, 오늘아침에 서비스가 너무 느리다. 혹은 주기적으로 인터넷 접속이 느린 현상 등

·방안수립

·실시간 성능 문제 : 단계별 성능 취약점 분석을 통한 성능 문제점 해결. 일시적인 네트워크 성능 문제 현상으로서 네트워크 장애와 연관됨
·비 실시간 성능 문제 : 기존의 네트워크 자료를 통해 접근해야 함. 성능문제 판단하기 위한 Base-line 작업이 필요, 네트워크 용량과 연관됨

– 성능개선 실행 및 검증

·성능조정(튜닝)

image008

· Configuration 재구성
· 사용율 초과로 인한 전송속도 및 대역폭 증설
· 장비 에러로 인한 장비 교체
· 장비별 MIB 수정
· 기타 타당성을 검토하여 성능조정을 시행합니다.

· 용량증설
: 용량증설 및 네트워크 관련 작업 필요 시 작업요청서를 통하여 요청하며, 필요시 타당성 검토를 수행한 후 진행할 수 있으며, 해당사안이 전산시스템 전체에 영향을 미치는 경우, 또는 IT팀장의 승인이 필요한 경우, IT팀장의 승인을 득한다.

③ DBMS

image010

– 데이터 수집 및 분석

· 측정항목
: DBMS 성능관리 대상은 일반적으로 스키마(Schema), SQL 문장/저장 프로시저, 공유 메모리 영역, DB파일관리, 세그먼트관리, 정렬 영역, 롤백 세그먼트, Locking관리, 세션관리영역으로 분류할 수 있으며, 각 대상별로 세부적인 측정항목을 선정한다. 이러한 대상 분류는 운영상태관리 분야의 대상과 중복되는 부분도 있으나, DBMS의 성능(Performance)을 대변하는‘응답시간 (Response Time)’및‘처리량(Throughput)’과 관련된 항목을 세부 측정 항목으로 선정하는 것이 일반적이다.

· 측정방법

· DBMS 측정 항목별 임계치 설정

: DBMS제작사 성능판단 기준자료 및 권고사항, SLA기준, DBMS활용형태, 사용자 만족도, 운영상태관리분야로부터 피드백 등을 반영하여 임계치를 설정한다.

· DBMS 성능측정 및 분석주기

· 일간, 주간, 월간 주기로 측정 대상을 분류하여 성능데이터의 수집과 분석을 진행하며, DBMS를 이용하는 비즈니스 순환주기에 그 근간을 둔다.

· 분석방법

· 분석 항목은 운영환경 및 성능 측정 환경의 특성에 따라 조정 가능하며, 일반적으로 DBMS 메모리분야, 데이터의 저장영역, 어플리케이션 지향적인 SQL 문장 및 Locking 관련 분야로 크게 나누어 분석한다.
※ 좀더 자세한 내용은 성능관리지침 p.132를 참고하세요.

– 성능 개선 방안 수립

· 대상 선정

· 단순하게 임계치를 초과하는 기준으로 하지 말고, 업무목표를 달성할 수 없는 상태의 근본원인을 선정하여 그 자원의 효율성을 개선할 수 있는 것을 대상으로 삼아야 한다.

· 방안 수립

· 일반적으로 DBMS의 성능개선 효과는 어플리케이션 로직 및 DB 스키마 설계 레벨에서 가장 큰 효과를 볼 수 있습니다만, 운영 상태에서 변경/조정하기는 매우 힘듭니다. 따라서 2차적으로 가장 큰 효과를 볼 수 있는 어플리케이션 튜닝(SQL문장 및 저장 프로시져)을 고려하는 것이 바람직합니다. 그 다음으로 하드웨어 증설을 통한 용량 변경 성능조정이 그 다음으로 영향력이 크며, 오라클 서버의 파라미터 튜닝 및 DB파일의 재배치, 그리고 운영체제 튜닝 등이 따릅니다.
· 개선방안에는 성능 개선이 업무대상에 미치는 영향도 분석 및 성능 개선을 위한 참여자를 포함시켜야 합니다. 또한 한 항목의 성능을 개선하였을 경우, 다른 항목의 성능이 나빠질 수 있으므로, 반드시 Trade Off를 고려하여 성능 개선 방안을 수립하며, 성능개선의 목표 및 연계분야와의 인터페이스를 포함시켜야 합니다.

– 성능 개선 실행

· 단계별 성능 조정(튜닝)

· DBMS 구축 및 운영단계별 성능관리

단계튜닝포인트체크포인트
계획/분석– 업무프로세스 최적화
– 시스템 구조
– 용량산정
– 연계 업무간 데이터 흐름분석
– 요구 응답시간 기준 설정
– 트랜잭션의 처리량, 안정성, 유지보수성 고려
설계– 데이터의 물리적 설계
– 어플리케이션 설계
– 설계 표준 설정
– 물리적 설계 전환시 성능관점 견지
개발/테스트– 인덱스 정책
– SQL, PL/SQL 구사의 효율성
– 옵티마이저의 이해 및 적용도
– 개발 표준 설정
– 개발자 교육
– 운영환경에 가까운 개발환경 구축
(충분한 데이터양 확보)
– 개발 장비 튜닝
운영– 운영체제의 튜닝
– 네트워크의 튜닝
– 데이터베이스 튜닝
– 어플리케이션의 튜닝
– 응답시간 관점에서 성능평가 수행
– 계층 요소별 종합적 시각
– 지속적인 모니터링 및 튜닝

④ 응용소프트웨어

: 응용소프트웨어는 다양한 도구 및 기법들이 있으며, 아래는 그 중 하나 입니다. 또한 지침상에는 세부적인 측정항목이나 측정방법, 성능테스트를 위한 시나리오 등이 있으니 참고하시기 바랍니다.
– 데이터 수집 및 분석

· 측정항목

image011

· 측정방법

구분설명도구예제용도
시스템
모니터링
도구
 운영 체제에 기본적으로 포함되어 있거나 추가가 가능한 도구로 시스템 자원 사용량, 관련 이벤트에 대한 실시간 및 통계 정보 제공 top, glance, topas, sar, vmstat, iostat, mpstat, prstat, lockstat, trapstat, netstat, nfsstat, system monitor (윈도우) 등 CPU, 메모리, 디스크 I/O 및 프로세스, 쓰레드 등의 자원 사용량 수집
 네트워크
모니터링
도구
 네트워크 패킷 또는 트래픽 부하에 대한 실시간 및 통계 정보 제공 Ntop, sniffer, ethereal,snoop, iptrace, MRTG 등 네트워크 패킷 및 트래픽 부하량 수집 및 분석
 시스템
관리도구
 시스템 운영 상태를 종합적으로 모니터링하여 실시간 통계정보를 제공하고 수집 정보와 정의된 임계치에 따라 자동 통보 등의 기능 제공 OpenView, Patrol, Tivoli, uniCenter, NetIQ 등 시스템 전반적 운영 상태 정보수집 및 분석
 어플리케이션
플랫폼 관리
도구
 어플리케이션 플랫폼에서 기본적으로 제공하는 모니터링 도구로 기본적인 성능정보 제공 실시간 기반의 시간당 처리량, 응답시간 등 기본적
성능정보수집 및 분석
 Profiler 어플리케이션 워크로드모델링, 런타임CPU/메모리 사용 패턴, 쓰레드 실행 정보 및 병목지점 분석 제공 Optimizeit, JProfiler, HP jmeter, .NET CLR profiler 등 JVM 및 CLR을 기반으로 하는 어플리케이션 실행정보 수집, 분석 및 튜닝
 APM 솔루션 어플리케이션 운영 상태 모니터링 및 상세 Profile 정보 제공 Topaz, Wily, i3, APM Suite, Strobe 등 어플리케이션 전반적 성능 정보 수집, 분석 및 튜닝
 End User
성능 관리
도구
 분산된 Agent를 통해 주기적으로 최종 사용자 측면의 응답 시간 측정 및 분석 정보 제공 ApplicationVantage 등 최종 사용자 측면 응답시간 수집 및 분석
 성능테스트
도구
 워크로드모델에 따른 테스트 스크립트 작성 및 가상 사용자 기반의 부하 테스트 기능 제공 Loadrunner, SilkPerformer, e Load, QALoad 등 시간당 처리량, 응답 시간 등 수집, 병목 지점 분석 및 용량 관리 지원
 로그분석기 워크로드, 어플리케이션 사용량 및 오류/ 예외 정보 제공 WebTrends 등 워크로드모델, 시간당 처리량, 응답 시간 및 오류 및 예외 분석
 코드
Instrumentation
 응용 어플리케이션에 관련 코드를 추가하여 특정 실행정보 제공 응용 어플리케이션 프로파일링 및 커스텀 성능 지표(예:주문처리 응답 시간 등) 수집

– 성능 개선 방안 수립

image014

· 방안수립

: 구체적인 개선 항목, Trade Off, 예상되는 개선효과, 우선순위, 개선항목 수행에 소요되는 시간 및 인원, 기타 고려사항 기술

– 성능 개선 실행

· 성능 조정(튜닝)

·  결과분석 후 수립된 개선방안 중 우선순위가 높은 것부터 한번에 하나씩 적용
·  개선항목 적용 후 다시 성능테스트 또는 모니터링을 통해 성능 데이터를 수집하고 분석하는 과정 반복
·  분석결과 정의된 성능 목표 만족시 성능조정(튜닝) 종료
·  성능조정(튜닝) 종료 시 측정값 및 환경 구성 정보(파라미터 등)를 새로운 기준치(Baseline)로 관리
· 용량 증설
·  응용소프트웨어의 용량 증설은 서버 및 네트워크 용량증설을 필수적으로 요구하게 됨

다) 검증 및 결과 관리

① 개선효과 검증

구분내용
측정지표성능개선 대상 선정 건수
정의성능개선 대상 (튜닝 적용) 건수
관련절차서성능 관리 절차서에 사례 반영
계산 방법(Σ성능개선 대상 적용 건수 / Σ성능개선 목표 건수)×100
데이터 수집자운영파트
데이터 분석자운영파트
측정주기반기 1회
보고주기반기 1회
특기사항성능개선 항목 수는 월 성능 분석 결과 도출된 성능개선 항목으로 계산

– 사용자로부터의 검증

· 사용자의 반응을 통하여 업무 목표를 달성여부 검증

– 연계분야로부터의 검증

· 운영상태관리와 서비스데스크관리, 장애관리, 용량관리 연계 분야로부터 직/간접적인 피드백

② 결과 관리

– 성능관리 계획 단계 : 성능관리 대상 및 방법 명시
– 성능 데이터 수집 및 분석 : 성능 측정 대상별, 항목별 측정 방법 및 주기, 분석 방법 기록관리
– 성능 조정 및 연계분야 관리 : 성능 분석 결과를 근거로 한 성능 조정(튜닝) 대상 선정 및 조정(튜닝) 실시
– 성능관리 결과 처리 시 고려사항

· 데이터는 정확하게 분석되었는가?
· 간결한 리포트 작성
· 성능조정에 대한 최종결정권자
· 다양한 시각에서의 성능분석/관리
· 비용 효율적인 성능 분석 실시

③ KPI(Key Performance Indicator)의 적용
: 성능관리 성공요소 및 주요 성과지표(예시)

핵심성공요소성과지표
정확한 성능
요구사항 분석
– 시기 적절한 자원요구 예측 생성
– 자원 사용 추세를 정확히 예측
– 적절한 비즈니스 계획과 용량 계획 조합
– 비즈니스 계획과 용량 계획 불일치 건수 감소
현재와 미래의
I T기술에 대한 지식
– 모든 서비스와 컴포넌트 성능과 처리량 모니터 능력 증대
– 비즈니스 요구(시간, 비용, 기능)에 맞는 신기술 구현
– 기존 기술 성능과 관련된 문제로 인한 SLA 위반 건수 감소
비용 효율성– 성능 유지를 위한 비용 최소화
– 초과 용량산정 억제
– 투자비용의 정확한 예측
성능 요구사항을
충족하기 위한
성능관리 수행 능력
– 성능 저하로 인해 발생된 사고 건수의 감소
– 부족한 용량 또는 성능으로 인해 SLA 위반 건수 감소
– 성능 분석 결과로 만들어진 권고사항(용량증설) 수행 성공율

5 통합적 성능관리

가) 구축절차

① 구축계획 수립 단계 : 구현 옵션 선정, 적용시스템 선정, 벤더 선정, 상세 구축계획 수립
② 구축 1단계 : 통합적 성능관리시스템 기반 구축 및 장애감시/성능관리 역량 구축
③ 구축 2단계 : 통합백업/스토리지 역량 증대 및 통합 모니터링 역량 확대 구축, 서비스수준 및 운영현황 역량 구축(워크플로우 기능 포함)

나) 구축방안

① 요구사항

– 자동화도구 통합 요구사항 : 통합운영관리 시스템의 통합 기반이 필요한 정보(이벤트, 데이터, 업무 프로세스) 통합, 기술 통합, 운영환경 관리, 기타로 분류하여 정의

· 이벤트 통합기반 : 효과적인 이벤트 수집 기반이 제공되어야 하며, 여러 성능관리 도구의 모니터링 기능에서 수집된 이벤트를 중앙 콘솔에 제공하여 통합관리 할 수 있어야 함
· 데이터 통합 기반 : 효과적인 데이터 수집 기반이 제공되어야 하며, 여러 운영관리 도구에서 생성/수집되는 데이터 중에서 서비스수준 평가와 운영현황 파악을 위한 데이터를 통합관리 할 수 있어야 함
· 데이터 관리 요건

· 지원 가능한 기존 관리도구의 데이터 수집 방법을 제공
· 데이터 생성/수집에 대해서 타 운영기능에 필요한 정보를 자동으로 전달
· 기존/신규 관리도구의 중복수집데이터에 대한 처리방안
· 업무 프로세스 통합 기반
· 장애, 자산, 서비스수준, 변경, 구성, 보안관리 도구 등이 업무 프로세스 통합이 필요성이 있는 기능
· 업무 프로세스 통합 요건
· 통합 모니터링과 보안관리와의 연계
· 장애 관리와 서비스 문의/요청관리와의 연계
· 서비스 문의/요청관리와 장애관리와의 연계
· 통합모니터링과 장애관리와 연계
· 변경관리와 구성관리와의 연계
· 장애관리 프로세스의 효율화
· 성능관리 프로세스의 효율화
· 용량관리 프로세스의 효율화
· Job 스케쥴링 프로세스의 효율화
· 스토리지관리 프로세스의 효율화
· 변경관리 프로세스의 효율화

– 기능별 자동화도구 요구사항 : 자동화도구 기능이 필요한 기능별과 인터페이스가 필요한 기능으로 분류하여 정의

· 시스템 성능 분석을 요청할 수 있는 기능이 제공
· 어플리케이션, 데이터베이스, 네트워크, 서버의 구성 요소에 대한 성능 모니터링 기능
· 어플리케이션, 데이터베이스, 네트워크, 서버의 구성요소에 대하여 임계값을 설정하고 이에 해당하는 이벤트 관리
· 심각도 정도에 따라 해당 이벤트 분류
· 이벤트와 필터링에 따라 이벤트 정보를 해당 담당자에게 SMS/E-mail 등으로 공지
· 성능 항목을 설정한 주기에 따라 성능 정보를 수집
· 성능 이벤트에 대한 관련 이슈 파악을 위해서 발생한 성능 이벤트 수집 시에 관련 성능 정보를 함께 수집/분석
· 성능 모니터링에 의해 production에 미치는 성능 정도를 파악하여 어플리케이션 성능 정보 수집 주기 및 정보량을 조절
· 수집된 성능 데이터/이벤트를 그래픽 형태로 분석
· What-if 모델 등의 성능 분석을 위한 다양한 모델링 기능을 제공
· 수집된 서버, DB, 어플리케이션, 네트워크 성능 정보를 표준으로 사용하는 Office 포맷으로 추출이 가능
· 성능 임계값에 대해 발생하는 성능 이벤트를 통합 콘솔에 연동
· 서비스 수준 분석과 운영현황 파악을 위한 정보를 통합 운영현황정보 DB에 연동
· 어플리케이션, 서버, 데이터베이스, 네트워크 성능 분석을 통하여 용량 계획수립에 참고할 수 있도록 수집된 성능 정보를 용량 관리 도구에 연동
· 성능보고서 연동

② 구축 전략

– 현실적인 관리체계 구축
– 통합성을 고려한 구축
– 미래지향적 아키텍처 구성
– 사전예방에 중점을 둔 관리환경 구축
– 철저한 품질보증 및 지원
– 수집 항목 선정 작업
– 철저한 공정관리를 통한 효과적인 구축
– 검증된 성능 관리의 노하우 적용

③ 구축 방법

– 통합적 성능관리 시스템 구축시 고려사항

· 일관된 시스템 관리체계 구축
· 문제 해결보다는 예방에 중점을 둔 관리환경을 구축
· 전산자원의 가용성 극대화로 유지비용 절감
· 확장성 있는 관리체계 구축

– 단계별 구축방법

· 제1단계 : 요구사항 분석(Requirement Analysis)
· 제2단계 : 설계(Conceptual/Detail Design)
· 제3단계 : 커스터마이징(Customizing/Programming)
· 제4단계 : 구현(Implementation)
· 제5단계 : 운영테스트 및 사후지원(Post Implementation)

다) 운영방안

① 운영 개념도

image016

② 고려사항

– 성능 자료 수집 대상에 대한 분류를 명확히 한다.
– 관리 대상에 대한 명확한 분류를 한다.
– 성능 관리 대상에 대한 그룹핑 기준을 정의한다.(부문별/업무별/서버별)
– 누적치 데이터의 보관 주기를 설정한다.
– 통합 성능 관리 절차를 수립한다.
– 성능관리의 일원화를 한다.

③ 운영방안

– 자동 리포팅 구현
– 성능 저하 요인 파악.
– 확장성 고려

성능관리지침에 대해서 3회에 걸쳐 게시글을 올렸습니다. 짧게 정리하면, “성능관리에 대해 사용자와 SLA 기준을 정해서 관리하며, 기준에 미치지 못하면 성능개선을 위한 데이터를 수집하고, 원인을 파악 한 뒤, 튜닝이나 용량 증설로 개선을 실시하며, 개선 전/후를 비교하여 결과보고서를 남긴다.” 뭐 이 정도가 될 것 같습니다.

지침상에는 행정적인 절차나 성능관리 시 필요한 항목들에 대해서 잘 정리를 하고 있으며, 기술적인 부분이 약간 포함이 되어 있습니다.
지침상에는 이 이외에도 성능관리와 타 분야와의 연계, 용어정의에 상당페이지를 할당하고 있으니 참고하시면 도움이 되실 것입니다.

성능관리를 하는데 어려운 점은, 성능향상을 요구하는 사람들과 실제 시스템 운영과의 차이가 크다는 것입니다. 사용자 입장에서는 일반적으로 “시스템이 너무 느리다.”, “더 빠르게 해달라”고 요구하지만, 운용시스템 상에는 한계가 있기 때문입니다.

따라서 계획 수립단계에서 사용자 요구사항을 수집하여 목표설정을 할 시점에 사용자의 요구사항을 적절히 조절하는 것이 중요할 것입니다. 또한 투입금액과 결과값 사이의 적정한 타협도 해야 할 것이고요. 말씀 드렸다시피, 이런 성능관리에 시간과 예산을 투자하는 것보다 상위시스템을 도입하는 것이 비용이 더 낮을 수도 있습니다.
실제로 튜닝을 하거나, 용량증설을 해서 속도가 빨라졌어도 사용자들에게 물어보면 “어, 좀 빨라진 거 같네.” 이런 시큰둥한 반응이 대부분입니다. 그리고 한 일주일만 지나도 다시 느리다고 습관처럼 이야기를 하죠.
성능향상을 요구하는 것은 결국은 사용자 입니다. 사용자에게 적절한 만족도를 주는 것은 수치상 향상도 있지만, 적절한 응대가 아닐까 싶습니다.

지침상에서는 이전에 튜닝을 한번 하였다면, 다시 튜닝을 할 경우에 이전 튜닝의 2배로 비싼 가격에 이전 튜닝 효과의 절반정도의 성능향상을 기대할 수 있다고 합니다. 튜닝을 할수록 비용은 높아지지만 효과는 점점 감소하게 되는 것이죠.

튜닝에 제약이 많은 부분이 응용소프트웨어 성능관리입니다. 응용소프트웨어 같은 경우 특정 어플리케이션의 특정 기능상에서 문제가 되는 경우 해당 기능에 대해 수정을 하면 되지만, 혼합된 경우가 대부분입니다. 시스템과 네트워크와 함께 문제를 풀어야 하는 것이죠.

하지만 복합적인 장애 처리시에도 그렇지만, 프로그램 개발자와 시스템엔지니어, 네트워크 엔지니어가 만나면 서로 “우리 부분에는 이상이 없다.”라고 말합니다. 개발자는 개발자대로 프로그램상에는 이상이 없다고 하고, 엔지니어는 엔지니어대로 시스템에는 이상에 없다고 하죠. 이게 참 힘듭니다.

주기적으로 점검을 잘 하고 계신다면, 성능관리도 역시 잘 하는 것입니다. 장비도 손을 타는지 주기적으로 로그도 확인하고 이것저것 이상이 있는지 확인을 해야만 성능도 유지가 되더군요. 특히나 이전에 비해 급격하게 속도가 느려지는 경우에는 주기적으로 하는 점검이 그 원인을 찾는데 도움이 됩니다. 또한 이런 경우에는 어플리케이션이 변경된 것이 있는지, 시스템변경사항이 있는지 확인하여 해당 부분을 중점적으로 확인해 봐야 합니다.

다음에는 ‘장애관리지침’에 대해서 알아보도록 하겠습니다.
감사합니다.

참고자료 : 정보시스템 성능관리지침(발행처 : 국무조정실, 정보통신부 발행:2005.12)

    About 부루스타

    부루스타

    Leave a Reply

    4 개의 댓글이 있습니다 - "정보시스템 운영관리지침 4.성능관리지침 2)성능관리 프로세스"

    메일 알림 설정
    정렬:   최신 | 오래된 | 추천
    netcat

    이런 훌륭한 게시물에 왜 스크랩 기능이 없는건가요. 좋은 내용 잘 봤습니다.

    비밀번호

    이번엔 좀 어렵네요 찬찬히 잘 보겠습니닷^^

    SharedIT

    전산꿀팁 이벤트 +5,000 Gpoint 가 제공되었습니다:)

    wpDiscuz