Ch.1 소개
성능 분석 이란 ?
- 단순히 도구 사용을 넘어 시스템의 동작 원리를 깊이 이해하고 문제의 근본 원인을 찾아내는 과정
- 목적
- 지연시간을 줄여 최종 사용자 경험을 개선
- 컴퓨팅 비용 절감
성능 엔지니어링
- H/W 선택이나 S/W 작성 전부터 시작해야 한다.
- 목표 설정과 성능 모델 작성
성능은 주관적이다.
평균 디스크 I/O 응답 시간은 1ms 이다.
- 어떤 사용자에게는 빠르고, 다른 사람에겐 느리다.
- 목표를 명확하게 설정함으로써 객관화가 가능하다.
( 목표 평균 응답 시간을 정한다, 요청의 일정 비율이 특정 지연시간 이내에 처리되어야 한다.)
가장 적합한 지표는 지연 시간이다.
지연시간은 구체적인 맥락이 필요하다 (연결 지연 시간, 요청 지연 시간, … )
Ch.2 방법론
페이지 폴트, 컨텍스트 스위치, 기타 여러 가지 시스템 지표의 정의를 안다고 해서
활용 방안이나, 각종 징조를 해결책으로 옮겨 나가야 할지는 모른다.
S/W, H/W, 성능 도구 그리고 성능 튜닝 파라미터까지 모두 변화가 있었지만, 이론과 방법론은 변하지 않았다.
용어 설명
| IOPS ( Input/Output operations per second) | - 초당 입출력 연산 수 - 데이터 전송 연산에 대한 측정값 중 하나. - 디스크 I/O의 경우 IOPS는 초당 읽기와 쓰기 횟수를 의미 |
|---|---|
| 스루풋 ( throughput ) | - 단위 시간당 처리량 - 데이터 전송 속도 ( 초당 바이트, 초당 비트 수 ) - 연산 속도 ( 초당 작업 수 또는 초당 트랜잭셕 수)를 의미하기도 함 |
| 응답 시간 ( response time ) | - 연산이 완료될 때 까지 걸리는 시간 - 대기 시간, 처리에 소요되는 시간, 결과를 전송하는 데 걸리는 시간 포함 |
| 지연 시간 ( Latency ) | - 요청에 대한 처리를 받기까지 기다려야 하는 시간 - 응답 시간과의 차이 - 지연 시간이라는 단어는 모호하다. (TCP 연결 지연시간 처럼 측정 대상을 명확하게 구분해야 한다.) |
| 사용률 ( utilization ) | - 해당 자원이 얼마나 바쁜가를 측정하는 기준 - Ex. CPU, 메모리 사용률 |
| 포화도 ( saturation ) | - 큐에 처리하지 못한 작업이 얼마나 많이 남아 있는지 정도 |
| 병목 지점 ( bottleneck ) | - 전체 시스템의 성능을 제약하는 자원 |
| 워크로드 ( workload ) | - 시스템에 가해지거나 적용되는 부하 - Ex) DB에서는 클라이언트가 보낸 쿼리 |
| 캐시 ( Cache ) | - 더 느린 저장 장치와 직접 통신하지 않고도 데이터를 빠르게 처리하기 위해 사용되는 저장 공간 |
응답 시간 VS 지연 시간
Cache 관련 예시
초당 100번의 네트워크 I/O와 50번의 디스크 I/O의 성능 비교
- 네트워크 홉 수, 네트워크 패킷 드롭 비율, I/O 크기 등 고려할 요소가 매우 많다.
- 이를 지연 시간으로 변환하면
- 네트워크 I/O 전체 : 100ms
- 디스크 I/O 전체 : 50ms
-> 차이를 명확하게 알 수 있다.
캐시 히트율
캐시 히트율 98%, 99% 차이는 10%와 11% 사이의 차이보다 성능 향상에 더 큰 영향을 미친다.
-> 히트와 미스의 속도 차이 때문.
-> 미스 시 데이터를 읽어오는 두 저장 장치 간의 속도 차이가 클 수록, 더 가파르다.
A의 캐시 히트율 : 90%
B의 캐시 히트율 : 80%
But
A의 초당 미스가 200회, B의 초당 미스가 20회라면 ?
-> B가 훨씬 빠르게 끝남.
워크로드의 전체 실행 시간 계산.
히트 지연 시간 : 1ms, 미스 지연 시간 : 10ms
A 미스율 10%, 초당 미스 200회, 초당 액세스 2000회 => 3.8초
B 미스율 20%, 초당 미스 20회, 초당 액세스 100회 => 0.28초
Trade Off
파일 시스템 레코드 크기
- Application I/O 크기와 비슷한 작은 레코드 크기 사용
- 임의 접근 I/O를 수행할 때 성능이 더 좋다, 캐시 히트율이 높아진다.
- 크게하면
- 파일 시스템 백업과 같은 연속 전송에서 성능이 향상된다.
네트워크 버퍼 크기
- 작은 버퍼는 연결당 메모리 오버헤드를 줄여 시스템이 더 많은 연결 처리
- 큰 버퍼는 네트워크의 스루풋이 증가한다.
튜닝 방법
Application 수준의 튜닝
- 불필요한 DB 쿼리를 줄여 크게 성능 향상 가능 ( 2000% )
저장 장치 수준으로 내려가서 튜닝을 진행
- I/O 속도 향상, I/O 자체를 없앨 수 있다.
- 이미 System call 같은 상위 운영 체제 스택 코드 실행 비용이 발생한 후임.
- 성능 향상은 상대적으로 낮다. ( 20% )
Application을 튜닝하는게 가장 효과적이다.
다만, 관찰자의 시작점을 Application에 두는 게 항상 효율적이지는 않다.
느린 쿼리는 CPU 사용 시간이나 파일 시스템 및 디스크 I/O 관점과 같은 하위 계층에서 이해하는 것이 더 유리할 수 있다.
Application은 지속적으로 개발되고, 매주 또는 매일 변경된다.
운영 체제 분석을 소홀히 해서는 안된다.
적합성의 수준
조직이나 환경에 따라 성능 요구사항이 달라진다.
성능 분석에 대한 투자 대비 효용이 다르다.
- ROI ( return on investment )
- 대규모 데이터 센터나 클라우드 환경을 운영하는 기업은 성능 엔지니어 팀을 두고
- 커널 내부부터 CPU 성능 카운터까지 모든 것을 측정하고 분석한다.
분석을 언제 중단할 것인가?
큰 도전 중 하나는 언제 멈춰야 할지 결정하는 일이다.
- 사용해 볼 만한 도구들도 너무 많고, 검토해야 할 사항도 너무 많다.
- 현실 세계의 문제에서는 원인이 몇 개인지 알 수 없는 경우가 많다.
성능 분석 중단을 고려할 수 있는 시나리오
1. 성능 문제의 주요 원인을 설명할 수 있을 때
2. 잠재적 ROI가 분석 비용보다 적을 때
- Ex) 연간 수천만 달러로 추산되는 성능 향상을 가져올 수 있다.
- 몇 달동안 분석에 투자하는 개인 시간을 충분히 정당화 한다.
- 여타 성능 개선 작업, 작은 마이크로 서비스 성능 개선 같은 사안들은 수백 달러의 효과가 있을 수 있으나, 한 시간의 엔지니어링 시간을 들여 분석하는 것 조차 가치가 없을 수 있다.
3. 더 큰 ROI가 기대되는 다른 문제가 있을 때
잠재적 RIO가 일상적인 업무에서 분석 우선순위를 정하는 기준으로 가져가야 한다.
성능 개선의 한시성
인터넷에서 찾은 튜닝 파라미터 값으로 성능을 빠르게 개선할 수 있지만, 이는 일부 상황에 해당한다.
다른 사람의 벽장을 뒤져서 자신에게 적합하지 않은 아무 약이나 가져와서 먹는 행위
튜닝 파라미터를 변경할 때에는 버전 관리 시스템에 변경 이력을 상세한 설명과 함께 저장해야 한다.
퍼펫, 솔트, 셰프와 같은 설정 관리 도구
규모 확장성
부하에 따른 스루풋 변화
자원에 대한 경쟁이 시작되는 지점에서 스루풋이 감소한다.
-> 무릎점 이라고 부름.
자원 경쟁이 심화되어 오버헤드 때문에 완료되는 작업이 줄어든다. ( 컨텍스트 스위칭 )
-> 이를 포화 지점이라고 한다.
빠른 성능 저하 : 메모리 부하 ( 메모리 페이지를 디스크로 옮길 때 )
느린 성능 저하 : CPU 부하
응답 시간 측면에서 선형 확장성을 유지하려면, 큐에 작업을 추가하는 것 말고
자원이 부족할 때 오류를 반환하는 식으로 설계되어야 한다.
-> 503 오류를 반환해서 응답 시간을 일정하게 유지
모른다는 것을 아는 것들
이미 알고 있는 것들
- 성능 지표를 확인해야 한다.
- 그 현재 값도 알고 있다.
- Ex. CPU 사용율을 확인해야 하고, 그 값이 평균 10%이다.
모른다는 것을 아는 것들
- 모른다는 사실을 인지하고 있는 것들
- 성능 지표나 서브시스템의 존재를 확인할 수 있다는 것을 알고 있지만, 아직 살펴보지 않았다.
- CPU를 바쁘게 만드는 원인을 찾기 위해 프로파일링을 사용할 수 있다. -> 아는데 아직 안함
모른다는 것을 모르는 것들
- 모른다는 사실 조차 모르는 것.
- 장치 인터럽트가 CPU 자원을 많이 소모할 수 있다는 사실을 모른다면, 이를 확인조차 하지 않을 것
알면 알수록 모르는 것이 더 많아진다.
방법론
분석을 어디서 시작할지 보여주고 따를 만한 효과적인 절차를 제시한다.
가로등 반방법론
- 특정 방법론이 없는 것을 의미한다.
- 그냥 시스템을 보면서 눈에 띄는 일이 벌어지고 있지 않나 살펴본다.
- 익숙하거나 이미 알려진 튜닝 파라미터들을 임의로 변경해 성능 개선이 일어나는지 확인한다.
- 성능 분석에서 특별히 top을 사용할 이유가 없는데 다른 도구의 출력을 읽는 방법을 몰라서 그냥 top 화면만 들여다 보고 있다. -> 나잖아 ?
어느날 밤 한 주정뱅이가 가로등 아래서 뭔가를 찾고 있었다.
경찰관이 물어보자 주정뱅이는 열쇠를 잃어버렸다고한다.
경찰도 함께 열쇠를 찾아봤지만 찾을 수가 없었다.
경찰은 물었다. "열쇠를 이 가로등 아래에서 잃어버린 것이 확실해요 ?"
주정뱅이는 대답했다. "아니요. 하지만 여기가 제일 밝거든요."
다른 사람 비난 반방법론
- 네트워크 문제일지도 모릅니다. 네트워크 팀에 연락해서 패킷 손실같은게 있었는지 확인해 주실래요?
- 성능 문제를 검토하기보다는 다른 사람의 문제로 만들어버린다.
- 희생자가 되지 않으려면 문제를 제기하는 쪽에 어떤 도구를 사용하여 성능 오류를 판단하였는지와 실행 화면을 요청하고 해당 정보를 어떻게 분석했는지 물어본다. ㅋㅋㅋ
체크 리스트 방법론
- iostat -x 1을 실행하고 r_await 칼럼을 살펴봐라. 부하가 걸린 상태에서 이 값이 일관되게 10ms 이상이라면, 디스크 읽기 속도가 느리거나 디스크가 과부하 상태일 수 있다.
- 팀원 모두가 공통적인 문제를 어떻게 점검해야 하는지 알도록 하는 효과적인 방법이 될 수 있다.
- 이 목록은 지속적으로 업데이트 해야 한다.
ETC
- 가장 빠른 쿼리는 전혀 실행하지 않는 쿼리
마치며
앞 내용은 너무 이론적인 소개 느낌이었다.
3장 부터 운영체제이니, 이제 시작일 듯.
