[실기] 소프트웨어 구축- 애플리케이션 성능 개선

최초 작성일: 2024-09-03

최종 작성일: 2024-09-03

목표 : 정처기 합격 및 CS 지식 쌓기

 

 

 

 

 

 

애플리케이션 성능 개선

1.    애플리케이션 성능 저하 원인

(1)   데이터베이스 관련 성능 저하

1)    데이터베이스 락(DB Lock)

대량의 데이터 조회나 과도한 업데이트 시 발생

Lock이 해제될 때까지 다른 트랜잭션들이 대기하게 되며, 이로 인해 타임아웃이 발생할 수 있다

*DB Connection Pool: 데이터 베이스에 접근할 수 있는 졸병을 만들어 놓고,

2)    불필요한 패치(가져오는 것)

결과 세트에서 커서를 자주 옮기는 경우 발생

   네트워크와 리소스에 불필요한 부담을 주며, 전체 시스템의 성능 저하를 초래할 수 있다

3)    연결 누수(Connection Leak)

데이터베이스 연결 후, 이를 제대로 반환하지 않을 때 발생

사용 가능한 데이터베이스 연결이 부족해져 시스템 성능 저하가 발생

*DB connection 사용 후 해제 필요

(2) 내부 로직으로 인한 성능 저하 원인

1) 파일 관련 오류

대량의 파일을 업로드하거나 다운로드 하는 과정에서 발생

시스템의 응답 시간이 증가하고 시스템의 부하가 커질 수 있다

2) 코드 오류

잘못된 코드 로직, 예를 들어 무한 반복 등의 문제로 발생

시스템의 리소스가 과도하게 사용되거나 전체적인 성능이 저하 될 수 있따.

(3)외부호출로 인한 성능 저하

외부 서버와의 인터페이스가 장시간 수행되거나 타임아웃이 발생

시스템의 응답시간이 늘어나고 전체 성능에 영향을 줄 수 있다

2.    애플리케이션 성능 분석

(1)   애플리케이션 성능 분석 지표

종류	설명
처리량(throughput)	애플리케이션이 일정 시간 내에 처리 하는 작업의 양 높은 처리량은 시스템의 효율성을 나타낸다
응답시간(response time)	사용자가 요청을 전송한 시점부터 애플리케이션이 첫 응답을 보내기 까지의 시간 빠른 응답 시간은 사용자 경험에 긍정적인 영향을 미친다
경과 시간(turn around time)	요청이 전달됨 시점부터 처리가 완료되기 까지의 총 시간
자원 사용률(resource usage)	애플리케이션이 작업을 처리하는 동안 cpu,메모리, 네트워크 등의 자원 사용량 효율적인 자원 사용은 시스템 성능에 중요하다

(2)   성능 분석 도구

종류	설명
JMeter	다양한 프로토콜(HTTP, FTP등)을 지원하는 부하 테스트 도구 애플리케이션의 성능과 스트레스 테스트에 적합
LoadUI	웹 서비스의 로드 테스트에 사용되며, 테스트 형태에 따라 분산된 UI를 제공 동시 및 별도의 결과보고가 가능
OpenSTA	HTTP, HTTPS 프로토콜에 대한 부하 테스트 및 성능 모니터링 도구 웹 애플리케이션의 스트레스 테스트에 유용하다

(3)   모니터링 도구

SCOUTER : 단일 뷰를 통합 통합 및 실시간 모니터링 기능 제공

NMON : 리눅스 서버 자원에 대한 모니터링 도구

Zabbix:  웹기반의 서버, 서비스 모니터링 도구

Jennifer : 애플리케이션에서 서버로 유입되는 트랜잭션의 양, 처리 시간, 응답 시간, 자원 활용률 등을 모니터링 한다

3.    정형기술검토회의 (FTR, Formal Technical Review)

(1)   개념

소프트웨어 엔지니어링의 일부로 소프트웨어 품질 보증 활동이다

소프트웨어 개발과정에서 생성되는 문서나 프로그램의 문제점을 찾아내고 해결을 촉구하는 공식적인 검토 과정이다

소프트웨어 개발 산출물, 오류 발견을 목적으로 한다

(2)   목적

산출물이 요구사항에 부합하는 지 검토한다

소프트웨어가 설정된 기준에 따라 적절하게 표현되었는지 확인한다

소프트웨어의 기능적, 논리적 오류를 식별한다

프로젝트 관리가 보다 쉬워지도록 돕는다

(3)   검토 지침

제작자가 아닌 제품의 검토에만 집중한다

제기된 모든 문제를 바로 해결하고자 하지 않는다

검토자들은 사전에 작성된 메모들을 공유한다

논쟁이나 반박을 제한한다

의제를 정하고 그 범위를 유지 한다

참가자의 수를 제한하고 사전준비를 철저히 하도록 강요한다

자원과 시간 일정을 할당한다

4.    소스코드 품질 분석

(1)   동료 검토(peer review)

2~3명의 개발자가 참여하는 리뷰 프로세스

코드 작성자가 코드를 설명하고 이해 관계자들이 그 설명을 들으며 겸함을 발견한다

코드의 품질을 개선하고 팀 내 지식 공유를 촉진한다

(2)   워크 스루 (walk through)

계획된 개발자 검토 회의 – 팀 회의

검토 자료를 회의 전에 배포하여 사전 검토한 후, 짧은 시간 동안 리뷰 회의를 진행한다

오류 검출과 문서화를 통해 코드 품질을 향상시키고, 개발 프로세스를 검토한다

(3)   인스펙션

작업자가 아닌 다른 전문가나 팀이 검사하여 오류를 찾아내고 소스코드의 품질을 높이는 기법

계획 -> 사전 교육 -> 준비 -> 인스펙션 회의 -> 수정 -> 후속조치

5.    소스코드 품질 분석 도구

(1)   소스코드 품질 분석 도구의 개념

코딩 중 발생할 수 있는 다양한 문제를 해결하기 위해서 사용하는 도구

코딩 스타일, 코딩 표준 준수 여부, 코드의 복잡도, 메모리 누수, 스레드 결함 등 소스코드로 인해 발생하는 문제들을 찾는 데 사용

(2)   소스코드 품질 분석 도구 분류

1)    정적 분석 도구

프로그램 실행 없이 소프트웨어 코드를 분석

코드의 결함, 버그, 보안 취약점 등을 확인

소스코드의 오류와 잠재적인 문제점들을 분석하는 데 사용

2)    동적 분석 도구-avalanche, valgrind

프로그램을 실행하여 코드의 메모리 누수(out of memory, jvm이 돌아갈 수 있는 메모리(ram)를 초과하는 경우, 자원을 해제 하지 않은 경우에 발생 함)나 스레드(작은 프로세스) 결함 등을 발견

실행 중인 프로그램의 문제를 실시간으로 분석

6.    애플리케이션 성능 개선하기 -clean code

(1)   코드 최적화의 개념

알고리즘 개선, 병목 현상 제거, 실행 시간 단축, 메모리 사용 최소화

소스 코드의 가독성 향상, 계산 횟수 감소, 실행시간과 기억용량 최적화

소스코드 리팩토링을 통해 코드 스멜을 제거하고 품질을 개선

(2)   코드 스멜

소스 코드에서 발견할 수 있는 잠재적인 문제점들을 지칭

종류 : 중복된 코드, 긴 메서드, 큰 클래스, 클래스 동시 수정

코드 스멜 관련 용어 : 스파게티 코드(복잡하게 얽힌 소스 코드 구조)/ 외계인 코드 (오래되어 유지보수가 어려운 코드)

(3)   리팩토링

외부 동작 변경 없이 내부 구조를 개선하는 방법

기능 변경 없이 소스 코드의 가독성과 유지보수성을 높이기 위해 내부 구조를 변경한다

(4)   클린코드 – 읽기 쉬운 코드

1)    클린코드의 개념

의존성 최소화, 명확한 가독성과 목적성을 가진 코드

특징: 의존성 최소화, 단일 책임 원칙 준수, 버그 최소화, 가독성 향상, 중복 최소화, 변경 용이성, 간결함

2)    구현 방법

클래스명, 메서드명, 변수명에 의미 있는 명사 사용

불필요한 주석 제거, 의도를 명확히 기술한 주석 작성

리팩토링을 통해 복잡도 낮춤

코드는 기능별로 간단하게 작성

중복 코드 제거

쉽게 읽을 수 있는 코드 작성

다른 모듈에 미치는 영향 최소화

런타임 오류 대신 예외 처리를 통한 안정적 종료 유도

3)    클린코드 작성 원칙

가독성 : 쉽게 읽히는 코드/ 이해하기 쉬운 용어 사용/적절한 들여쓰기

단순성: 간단한 코드 작성/ 최소단위로 분리/ 한가지 기능만 처리

의존성 배제 : 코드 변경 시 다른 부분에 영향이 없도록 작성

중복성 최소화 : 중복코드 삭제 및 공동 코드 사용

추상화 : 상위 객체에서 간략하게 기능적 특성 표현, 상세내용은 하위 객체에서 구현