성능 문제 확인 방법

• 성능 요구사항이 잘 정의 되어 있다면, 문제 여부를 쉽게 판단 가능
  • 사용자가 어플리케이션 성능에 불만족
  • 시간초과/비정상부하 가 탐지
  • 응답시간의 SLA 불충족 탐지

시스템 모니터링

• 일반적인 시스템 통계에 기초하여 헬스 체크 수행
  • 비정상적인 부하 패턴, 장애 발생 감지
• 전체 인프라스트럭처 각각 모니터링 가능
  • 특정 요소 문제시 전체 영향도 파악 불가 (구성 요소간 상호작용 고려 안됨)
    • False Positive : 특정 요소 문제 발생, 사용자 성능 문제 없음 (QC CPU * 4EA / 사용률 75% / 태스크 수 많음 - 안정)
    • False Negative : 사용자 성능 문제 호소, 개별 요소 문제 없음 (QC CPU * 4EA / 사용률 08% / 태스크 1개 - 병목)

응답시간 모니터링

• 가상/실제 트랜잭션에 기초해서 헬스 체크 수행
• 트랜잭션을 수행하는 어플리케이션의 소비 시간 측정 및 임계치 초과시 통보 (SLA 준수 모니터링)
  • 단일 구성 요소 뿐 아니라, 전체 어플리케이션의 인프라스트럭처 검사

튜닝 강박증

• 한때 대부분 DBA 는 튜닝 강박증(Compulsive Tuning Disorder)을 앓음
  • 단순한 몇가지 규칙으로 DB 튜닝이 가능하다고 생각
  • 비율에 기반을 둔 여러 성능 관련 통계의 지나친 검사 하고 중요한 사용자 경험은 놓침
    • False Negative, False Positive 예외 미 고려

성능 문제 접근 방법

• 어플리케이션 성능 최적화 → 이익 극대화
  • 비용과 성능 사이에 최적의 균형점 확보
  • 성능 최적화 작업이 항상 유의미한 것은 아님

비즈니스 관점 vs. 시스템 관점

• 비즈니스상 문제와 요구사항 먼저 파악
  • 그림 1-2 (p.20)
• 결과는 비즈니스 관점에서 인식, 원인은 시스템 관점에서 확인
  • 관련 없는 문제(튜닝 강박증)나 없는 문제로 인한 헛수고 감소

문제 분류

문제 분류를 위한 작업

• 비즈니스 관점에서 문제 식별
  • 비즈니스 문제는 비즈니스 관점에서 확인
  • SLA 모니터링이 있다면 성능 문제 명백하게 확인 가능, 없다면 애플리케이션 담당자와 대화로 확인
• 문제 우선순위 정의
  • 제한된 시간과 예산, 비지니스 요건 고려
  • 문제 해결에 필요한 측정 값이 상충되는 경우 고려
• 문제 목표 정의
  • 계량화 할 수 있는 최적화 목표 설정 (예: 최대 2초내 처리)
  • SLA 의 성능 레벨 활용

문제 해결

성능 문제 해결을 위한 질문

• 시간을 소모하는 곳이 어디인가?
  • 시간을 대부분 사용하는 모듈이나 컴퍼넌트 찾기
• 시간이 어떻게 소모되는가?
  • CPU, DISK I/O, 통신 등으로 구분
• 어떻게 하면 소모되는 시간을 줄일 수 있을까?
  • 시간을 많이 소모한 부분에 집중

가장 먼저 해야 할일

• End - To - End 성능 데이터 수집
  • 오라클 환경 에서는 다중 계층 아키텍처가 사실상 표준
  • 요청을 처리하기 위해 항상 모든 구성요소를 거쳐야 하는 것은 아님

성능 문제 완벽 분석

• 요청 처리와 관련 있는 모든 구성요소 상세 정보 수집
• 분할 정복(Divide And Conquer) 방식이 유일하게 효율적인 방법
• 관련 구성 요소 파악 및 각각 소요 시간 파악
  • 시간을 가장 많이 소모한 구성요소에 대해 추가 정보 수집 (p.24)

성능 데이터 수집

• 계측 : 어플리케이션 내 계측 기능 활용 (예: SQL Trace)
  • 장점 : 새로운 코드를 배포하지 않고 동적으로 활성화 가능
  • 개발자가 직접 코드를 만들어야 하고, 포멧도 개발자 마다 다름
• 프로파일링 : 실행 중인 애플리케이션에서 수행한 오프레이션 및 소요 시간, 자원 사용량을 기록하는 성능 분석 도구
  • 장점 : 전체 어플리케이션 범위 대상으로 측정
  • 단점 : 도입 비용 높음

• 실제 상황에서 프로파일링 분석이 많이 이뤄짐
• 문제 해결을 위한 조치는 다른 문제 까지 해결 하거나 문제를 만든다. (부작용)