논문제목 : Automatic Database Management System Tuning Through Large-scale Machine Learning
거참.. 블로그가 많이 밀렸다 ㅎ
하고 있던 강화학습도 다 못썼다 ㅎㅎ ㅎㅎ ㅎㅎ 게으름의 극치
하지만 바쁘기도 했삼 ㅡㅅㅡ 아마도..
오늘은 OtterTune 논문 리뷰 세미나 때 했던 내용을 간략하게 정리하려한다... (매우 간략함)
아직 초짜 석사 3개월차 찌랭이여서 아주 미숙하다...
도움이 될지는 모르겠다... (안될듯)
그냥 내 개인 정리용으로 올린다!
<Introduction>
데이터베이스 튜닝에 있어서 튜닝을 할 수 있는 옵션들이 점점 늘어나고 있고 그에 따라서 완벽하게 DBMS를 튜닝하는건 힘들다. 또한 데이터베이스의 복잡성과 사이즈가 점점 커지면서 사람이 knob 하나씩 튜닝을 하기에는 그 능력치를 벗어나고 있다. (힘들다는 뜻) 그래서 자동으로 configuration을 추천해주는 모델이 등장하였고 Ottertune에서는 configuration 추천에 있어 ML 모델을 사용한다.
OtterTune의 특징은 어떤 target workload에 대해서 튜닝을 진행할 때 이전에 튜닝을 했었던 workload에 대한 data를 재사용하여서 좀 더 빠르게 target workload의 튜닝이 가능하다는 점이다.
저자들은 본래 튜닝 시스템에 대해서 네가지 문제점을 지적한다.
1. Dependencies
DBMS 튜닝을 진행할 때 하나의 knob값을 변경했음에도 그와 연관성이 있는 다른 knob의 값에게도 영향을 미칠 수 있다.
2. Continuous Settings
그림 b를 통해 knob 값을 설정했을 때 계속해서 latency가 낮은게 아니라 한 지점에서만 낮은 latency를 보이고 그 이후에는 다시 latency가 높아지는 것을 볼 수 있다.
3. Non-Reusable Configuration
그림 c를 보게되면 각 config 파일이 각각의 workload에 최적화 되어있는 파일인데 workload1에서 config 1의 latency는 낮지만 workload3에서의 latency는 매우 높은 것을 확인할 수 있다. 반대로 config 3을 workload1에서 사용했을 땐 latency가 매우 높지만 workload3에서는 현저히 낮은 것을 확인할 수 있다.
4. Tuning Complexity
DBMS의 버전이 계속해서 업데이트 되고 있고 그에 따라 knob의 갯수도 점점 늘어가기 때문에 튜닝 복잡도가 높아지고 있다..
<SYSTEM's OVERVIEW>
Ottertune의 아키텍처는 크게 Tuning manager와 Controller로 나눌 수 있다.
여기서 Controller는 DBMS와 Tuning manager를 이어주는 매개체 정도로 생각하면 된다.
Controller는 튜닝 요청이 들어오게되면 그 DBMS에 대한 metrics 정보를 JDBC같은 API를 통해 얻는다. 이후 그 정보를 Tuning manager에게 전송한다. Tuning manager는 그 정보와 이전 tuning session에 대한 data를 함께 data repository에 저장한다. 이제 이 data repository에 저장된 workload와 target workload의 유사도를 비교해서 가장 유사한 workload를 매핑시키는 과정이 ML model에서 이루어진다.
<OtterTune Machine Learning Pipeline>
자..! 이게 OtterTune의 파이프라인이다.
그림과 같이 크게 Workload Characterization, Knob Identification, Automatic Tuner 세 단계로 나뉘게 된다.
그럼 첫번째 단계부터 알아보자..!!!!!
1. Workload Characterization
먼저 Data repo에 저장되어있는 metrics와 sample을 각 행렬의 row와 column으로 생성한다. 이 값들을 우리는 2차원 평면의 그래프에서 나타내고 싶기 때문에 (clustering 과정에서) Factor-Analysis를 통해 차원을 줄여주게 된다.
이후 K-means Clustering을 통해 그룹핑을 진행한다. 이를 하는 이유는 metric의 값이 너무 많기 때문에 불필요한 (성능에 크게 영향을 미치지 않는) metric을 줄여주기 위해서다. 그래서 clustering에서 비슷한 특징을 가진 metric끼리 그룹핑해주고 그 안에서의 중심점을 대푯값으로 지정한다. 그 대푯값으로 Knob Identification을 진행한다.
2. Knob Identification
선별한 knob들 중에서도 중요도를 매겨서 실험을 진행할 때 상위 몇 개만 사용할 예정이기때문에 (불확실 ㅠ) Lasso-path-algorithm을 통해 knob의 중요도를 매긴다.
여기서 Lasso-path-algorithm이란 Lasso의 특징을 가지고 있는 알고리즘인데 개념부터 천천히 말해보자..
일단 Linear-Regression은 실제값과 예측값과의 MSE를 최소화하도록 하는 w와 b의 값을 찾는게 목적이다.
그리고 Lasso는 Linear-Regression에서 overfitting을 막기 위해 w에 대한 penalty항을 추가한 것이다. 그리고 다음과 같은 식을 최소화 시키는 것이 목적이다.
여기서 x가 knob이라고 하고 이 knob이 데이터베이스의 성능에 영향을 많이 끼칠수록 w의 값을 크게 준다. 그럼 실질적으로 y-hat과의 연관성이 높은 파라미터는 w겠다. 그러므로 Lasso-path-algorithm에서는 알파의 값을 먼저 무한대로 주게된다. 그럼 Lasso의 목적은 위에서 말했듯이 식을 최소화하는 것이 목적이기 때문에 w의 값이 0에 가까워질것이다. 여기서 알파의 값을 조금씩 줄여주면 w의 값이 클수록 제일 먼저 변화가 생기게 될 것이고 w의 값이 크다는건 데이터베이스의 성능에 영향을 많이 끼친다는 뜻! (살짝 복잡하다ㅠㅠ)
그래서 위 그림에서보면 innodb_buffer_pool_size가 제일 먼저 변화가 일어났기 때문에 가장 영향이 큰 (=중요도가 높은) knob이 된다.
이렇게 중요도를 매긴 후에는 그 중에서 몇개의 knob을 recommendation에 사용할지 정해준다. 너무 많은 knob을 사용할 경우 recommendation하는데 시간이 너무 오래 걸리고 너무 적은 knob을 사용하게되면 신뢰도가 떨어지기 때문에 Ottertune에서는 knob의 갯수를 점점 증가시키겠다고 한다..
마지막
3. Automatic Tuner
별 거 없다. 이제 target workload랑 data repo에 저장되어있었던 workload들 간에 유사도를 측정한다. Euclidean distance를 통해서 계산하고 가장 가까운 workload를 매핑해준다.
이후에는 Gaussian Process Regression을 통해서 다음 configuraion을 추천해준다.
끝.
더 자세히 쓰고싶은데 그건 다음 기회에...
진짜 별내용없어보이는데 그런 논문은 아님.. 나의 이해력 문제...
그리고 귀찮음의 문제....