[정보 처리] 13. 소프트웨어 성능 분석, 품질 평가

[소프트웨어 성능 분석]

- 소프트웨어의 성능은 사용자가 요구하는 기능을 수행하기 위하여 최소한의 자원을 사용하면서 최대한 빠르고 정확하고 많은 작업을 처리할 수록 좋은 것입니다.

 

- 소프트웨어 성능 측정 지표는 아래와 같습니다.

1. 처리량(Throughput) : 주어진 시간에 처리할 수 있는 단위 작업(트랜젝션)의 수

2. 응답 시간(Response Time) : 사용자 입력에 대한 응답이 나타날 때까지의 시간

3. 경과 시간(Turnaround Time) : 사용자 입력에 대한 결과 출력이 완료될 때까지의 시간

4. 자원 사용률(Resource Usage) : 작업 처리를 위해 사용한 CPU, 메모리, 네트워크 등의 사용량

 

- 소프트웨어 성능 분석 도구 유형

1. 성능(Performance)/부하(Load)/스트레스(Stress) 점검 도구 :

소프트웨어를 사용하는 도구입니다.

소프트웨어 기능에 요청을 보내서 성능 지표를 파악하고,

막대한 요청을 발생시켜 견고성을 확인합니다.

_도구 : JMeter, LoadUI, OpenSTA

 

2. 모니터링(Monitoring) 도구 :

소프트웨어 실행시 자원 사용량 확인, 성능 지표 확인, 부하량 파악, 장애 진단, 사용자 분석 등의 정보를 제공합니다.

성능 파악 및 안정적 운영을 도와줍니다.

_도구 : Scouter, Zabbix

 

(소프트웨어 성능 저하 원인)

- 소프트웨어 성능이 좋지 않게 분석되었을 경우, 이에 대한 적절한 조치를 취하기 전에 원인 파악을 해야합니다.

아래는 소프트웨어 성능에 악영향을 끼치는 대표적인 원인들을 정리하였습니다.

 

1. DB 연결 및 쿼리 실행

DB 의 특징은,

견고함,

상대적으로 무거움,

보조 메모리에서 데이터를 가져옴,

여러 위치에서 조회가 가능함

위와 같습니다.

 

이로인해서 DB 를 주요 파츠로 하여 움직이는 여러 응용 소프트웨어에서 성능 저하를 유의해야 하는 주요 부분으로,

DB로 인한 성능 저하의 대표적인 유형으론,

 

DB 연결 Connection 객체 관련 생성 과다(커낵션 해제를 하지 않거나 커낵션 풀 크기가 적절하지 않음),

비효율적 DB 쿼리 사용,

필요 데이터보다 많은 양의 데이터 요청,

동시 수정 방지를 위해 DB Lock 을 걸어 다른 접근을 막음,

 

위와 같습니다.

 

2. 내부 로직

성능친화적이지 못한 비합리적인 내부 로직 구현으로 인해 발생합니다.

 

3. 잘못된 환경

스레드 풀, 힙 메모리 등의 설정을 잘못하면 이로인해 성능이 저하될 수 있습니다.

외부적으로는, 라우터, L4스위치 등 네트워크 관련 장비간 데이터 전송 실패 또는 전송 지연에 따른 성능 저하 원인이 있습니다.

 

[소프트웨어 품질 평가]

(소스 코드 품질 관련 용어)

- Bad Code

다른 개발자가 이해하기 어렵게 작성된 코드를 뜻합니다.

하나의 기능을 처리하는 코드가 이리저리 어지럽게 얽혀있어서 파악하기 힘든 스파게티 코드나,

변수 및 함수의 식별자가 이해할 수 없게 되어있거나,

동일 로직이 몇번이고 중복 작성된 코드 등이 있습니다.

 

- Hard Code

프로그램 코드에 변수로 떼어낼 수 있는 부분을 그대로 입력한 코드입니다.

예를들어 가격 결정 로직의 코드에서,

val unitPrice = 1000

val price = count * unitPrice
logger.info("적용된 단위가격 : " + unitPrice)

 

위와 같이 단위 가격을 따로 떼어두면 단위 가격 정보를 이용하는 다른 코드 부분에서 코드를 수정하지 않아도 위 변수의 수치만 변경하면 간단히 수정이 가능한데,

val price = count * 1000
logger.info("적용된 단위가격 : " + 1000)

 

위와 같이 '하드코딩'을 하면,

추후 단위 가격이 바뀌었을 경우 해당 부분을 전부 찾아내기 힘들 수 있고(만약 해당 정보가 사용된 곳이 1000 개가 넘는다고 생각해봅시다.), 이로인해 소프트웨어 결함이 생겨날 수도 있습니다.

 

- Clean Code

가독성이 높고, 단순하며 의존성이 낮고 응집성이 높으며, 중복이 최소화된 깔끔한 코드입니다.

인수인계 기간 단축뿐 아니라 기술 응용 및 개발 속도에 좋은 영향을 줍니다.

 

클린 코드 작성 원칙은 가독성, 단순성, 의존의 최소화, 중복의 최소화, 추상화 등이 있습니다.

 

즉, 좋은 코드를 만들기 위해서는,

단위별 하나의 역할 및 책임을 수행할 수 있도록 응집도를 높이고,

단위 기능간 의존성을 최소화 하여 결합을 약하게 하여 코드 유연성을 높이며,

기억하기 쉬운 변수 및 함수 이름을 사용하여 명명하는 등 가독성 있는 코딩 스타일을 갖추는 것이 필요합니다.

 

(소스코드 품질 분석)

- 소스코드 품질 분석이란,

소스코드에 대한 코딩 스타일,

설정된 코딩 표준,

코드의 복잡도,

코드상 메모리 누수 현황,

스레드 결함 등을 파악하고 평가하는 것입니다.

 

- 소스코드를 실행하지 않고 코드 자체만으로 품질을 분석하는 정적 분석 도구는 아래와 같습니다.

1. pmd : 자바 및 다른 언어의 소스 코드에 대한 버그 및 데드 코드 분석

2. cppcheck : C/C++ 코드에 대한 메모리 누수, 오버플로우 등 분석

3. SonarQube : 소스 코드 통합 플랫폼, 플러그인 확장 가능

4. checkstyle : 자바 코드에 대한 코딩 표준 준수 검사 도구

 

- 소스코드를 실행하여 코드 품질을 분석하는 동적 분석 도구는 아래와 같습니다.

1. Avalanche : Valgrind 프레임워크 및 STP 기반 소프트웨어 에러 및 취약점 분석

2. Valgrind : 자동화된 메모리 및 스레드 결함 발견 및 분석

 

(소프트웨어 품질 보증(SQA : Software Quality Assurance))

- 소프트웨어 품질 보증이란,

제품 소프트웨어의 기능과 사용자의 요구사항이 일치하는지를 확인하는 체계적인 시스템과 활동을 총칭합니다.

소프트웨어 품질 확보를 위한 요구사항과 개발 절차, 평가 절차를 제공합니다.

 

- 정형 기술 검토(FTR : Formal Technical Review)

정형 기술 검토란,

소프트웨어 품질 보증을 위한 중요한 활동 중 하나로,

오류를 발견하고 예방하기 위한 "체계적이고 공식적인 리뷰 방법"입니다.

소프트웨어 개발 산출물(예: 설계서, 코드, 테스트 케이스 등)에 대해 팀원들이 모여 공식적인 절차에 따라 검토하고, 오류를 발견하거나 개선점을 도출합니다.

 

FTR 의 원칙은 아래와 같습니다.

1. 검토될 제품에 대한 체크리스트 개발

2. 자원과 시간 일정 할당

3. 문제 영역을 명확히 표현하고 의제를 제한

4. 제품 검토에만 집중

5. 검토 과정과 결과를 재검토

6. 논쟁과 반박을 제한

7. 참가자 수 제한

8. 사전 준비를 강요하고 사전에 작성한 메모를 공유

9. 모든 검토자들을 위해 의미있는 훈련 진행

10. 해결책이나 개선책에 대해 논하지 않음

 

- 소프트웨어 품질 목표 항목

소프트웨어의 품질 평가를 위한 세부 항목은 아래와 같습니다.

1. 정확성(Correctness) : 사용자의 요구사항을 충족

2. 신뢰성(Reliability) : 정확하고 일관된 결과로 요구된 기능을 오류 없이 수행하는 능력

3. 효율성(Efficiency) : 기능 수행을 위해 최소한의 자원을 소모하는 능력

4. 무결성(Integrity) : 허용되지 않는 사용이나 자료 변경을 제한

5. 유지보수 용이성(Maintainability) : 품질 개선, 오류 수정 등의 용이함

6. 사용 용이성(Usability) : 쉽게 이용 가능한 정도

7. 검사 용이성(Testability) : 쉽게 검사 가능한 정도

8. 이식성(Portability) : 다양한 환경에서도 운용 가능한 정도

9. 상호 운용성(Interoperability) : 다른 소프트웨어와 무리 없이 정보 교환

10. 유연성(Flexibility) : 수정 용이성

11. 재사용성(Reusability) : 최소한의 수정으로 다른 곳에서 그대로 응용 가능한 능력

 

- 소프트웨어 신뢰도 측정 

소프트웨어 품질 기준 중 신뢰도를 측정하기 위해서는 아래와 같은 방식이 있습니다.

1. 평균 장애 시간(MTTF, Mean Time To Failure) :

제품 고장이 발생할 때 까지의 동작시간 평균값입니다.

MTTF = 총 동작 시간 / 사용횟수

 

2. 평균 복구 시간(MTTR, Mean Time To Repair) :

고장 발생 시점부터 수리 완료까지의 수리시간 평균값입니다.

MTTR = 총 고장시간 / 사용횟수

 

3. 평균 무장애 시간(MTBF, Mean Time Between Failure) :

평균적으로 장애가 발생하는 간격(장애가 일어나지 않은 시간)을 평균 낸 것입니다.

MTBF = MTTF + MTTR

 

4. 시스템 가용성

가용성 = MTTF / MTBF