튜닝에 대한 생각

# 튜닝의 트렌드

과거에는 성능좋은 서버 하나에 모든 업무를 집어넣었다. 

필연적으로 헤비한 쿼리가 발생하게되고, 예를 들면 한달 과금 쿼리를 실행하는데 열흘 넘게 걸리는 식이다.

자연히 튜닝의 필요성이 생기게 된다. 

반면 요즘의 트렌드는 조금 변화가 생겼다. 

MSA 를 도입하면서 헤비한 쿼리가 많이 줄어들게 되었고, SQL 튜닝으로 성능을 해결하는 부분을 

서버를 스케일아웃 하는 식으로 성능을 해결이 가능해지는 부분이 생겼다. 

# 튜닝의 형태

튜닝하면 보통 SQL 튜닝을 대표적으로 생각하지만 형태는 다양하게 있다. 

1. 통계정보
2. 힌트추가
3. 쿼리 재구성
4. 인덱스추가 
5. 모델의 변경
6. 기타 (함수나 plsql 활용 등) 

1번이 제일 쉽지만 생각외로 1번으로 해결되는 케이스가 많다. 하지만 통계 변경에 대한 거부감이 있는 사람이 많다. 

주로 (통계변경으로 플랜이 바뀌는 등) 데인 경험이 있는 사람들이 거부감이 있다. 

하지만 개인적으로는 통계가 기초고 시작점이라고 생각한다. 

2번이 제일 변경이 적어 (개발자들의) 거부감이 적다. 4번은 dba 들이 싫어하고 

3번은 개발자들이 싫어하고 5번은 시간이 많이 필요해서 대안으로 제시만 할 뿐 실제적으로 적용은 거의 안한듯. 

SQL 튜닝은 결국 성능개선의 한 방식일 뿐이고 구조, 아키 관점에서 성능 개선이 가능하니 관심을 가질 필요가 있다.  

 

# 튜닝에 대한 생각 

- 튜닝은 그나마 정답이 좀 있는 편이지만 역시 트레이드 오프가 있다. 

고객이 성능 개선에 대해 절실하다면 다소 트레이드 오프가 있어도 수용 할수 있지만 그닥  튜닝의 시급하지 않은 사안에 대해서는 세련된 개선책을 제시해도 반응은 시큰둥하다. 힘을 줘야 할때 힘을 빼야 할때는 적절히 판단 해야 한다. 

튜닝은 고민의 결과이지만 지저분해진다. 고객이 원할때만 쥐어짜내줄 필요가 있다. 

개인적으로는 튜닝의 끝은 순정이라고 SQL 은 건드리지 않고 인덱스 추가, 통계, 구조 만으로 성능개선을 하는 것이 

간결하게 시스템을 유지하는 방안이라고 생각한다. 

  

# 이론이 아닌 수치로 고객 설득

이론적으로는 개선후에 성능의 차이가 있어야 하지만 적용후에 별다른 체감을 못할때가 있다. 

결국 고객을 설득 시킬 수 없으므로 그 방식은 미련을 가지지 말고 포기한다.