DBMS의 자동화된 운영 및 유지관리를 위한 머신러닝 애플리케이션

DBMS(데이터베이스 관리 시스템)는 모든 데이터 집약적 애플리케이션의 중요한 부분입니다. 대용량 데이터와 복잡한 작업 부하를 처리할 수 있지만, 캐싱 및 디스크 쓰기에 사용할 메모리 양과 같은 다양한 요소를 제어하는 ​​수백 또는 수천 개의 "노브"(구성 변수)가 있기 때문에 관리하기도 어렵습니다. . 빈도. 조직에서는 튜닝을 수행하기 위해 전문가를 고용해야 하는 경우가 많으며, 많은 조직에서는 전문가에게 비용이 너무 많이 듭니다. Carnegie Mellon University의 데이터베이스 연구 그룹의 학생과 연구원은 DBMS의 "노브"에 대한 올바른 설정을 자동으로 찾을 수 있는 OtterTune이라는 새로운 도구를 개발하고 있습니다. 이 도구의 목적은 데이터베이스 관리 전문 지식이 없어도 누구나 DBMS를 배포할 수 있도록 하는 것입니다.

OtterTune은 이전 DBMS 튜닝에 대한 지식을 사용하여 새 DBMS를 튜닝하므로 소비되는 시간과 리소스를 크게 줄여준다는 점에서 다른 DBMS 설정 도구와 다릅니다. OtterTune은 이전 튜닝에서 축적된 지식 기반을 유지함으로써 이를 달성합니다. 이 축적된 데이터는 기계 학습(ML) 모델을 구축하여 다양한 설정에 대한 DBMS의 반응을 포착하는 데 사용됩니다. OtterTune은 이러한 모델을 사용하여 새로운 애플리케이션에 대한 실험을 안내하고 대기 시간 감소 및 처리량 증가와 같은 최종 목표를 개선하는 구성을 제안합니다.

이 기사에서는 OtterTune의 각 기계 학습 파이프라인 구성 요소와 상호 작용하여 DBMS 설정을 조정하는 방법에 대해 설명합니다. 그런 다음 MySQL 및 Postgres에서 OtterTune의 튜닝 성능을 평가하고 최적의 구성을 DBA 및 기타 자동화된 튜닝 도구와 비교합니다.

OtterTune은 Carnegie Mellon University의 데이터베이스 연구 그룹의 학생과 연구원이 개발한 오픈 소스 도구입니다. 모든 코드는 Github에서 호스팅되며 Apache License 2.0 라이선스에 따라 릴리스됩니다.

OtterTune 작동 방식

아래 그림은 OtterTune 구성 요소와 작업 흐름을 보여줍니다

튜닝 프로세스는 사용자가 OtterTune에 튜닝할 최종 목표(예: 대기 시간 또는 처리량)를 알려주고 클라이언트 컨트롤러 프로그램이 대상 DBMS에 연결하여 Amazon EC2 인스턴스 유형 및 현재 구성을 수집할 때 시작됩니다.

그런 다음 컨트롤러는 첫 번째 관찰 기간을 시작하여 최종 목표를 관찰하고 기록합니다. 관찰 후 컨트롤러는 MySQL 디스크 페이지 읽기 및 쓰기 횟수와 같은 DBMS 내부 측정항목을 수집합니다. 컨트롤러는 이 데이터를 튜닝 관리자 프로그램에 반환합니다.

OtterTune의 튜닝 관리자는 수신된 측정 데이터를 지식 기반에 저장합니다. OtterTune은 이러한 결과를 사용하여 대상 DBMS의 다음 구성을 계산하고 이를 예상 성능 향상과 함께 컨트롤러에 반환합니다. 사용자는 튜닝 프로세스를 계속할지 아니면 종료할지 결정할 수 있습니다.

주의

OtterTune은 튜닝에 중요하지 않은 것(예: 데이터 파일 저장 경로) 또는 심각하거나 숨겨진 결과(예: 데이터 손실)를 초래할 부분을 포함하여 지원되는 각 DBMS 버전에 대해 "손잡이"의 블랙리스트를 유지 관리합니다. OtterTune은 튜닝 프로세스가 시작될 때 사용자에게 이 블랙리스트를 제공하며 사용자는 OtterTune이 피하려는 다른 "손잡이"를 추가할 수 있습니다.

OtterTune에는 일부 사용자에게 특정 제한을 초래할 수 있는 미리 결정된 가정이 있습니다. 예를 들어 컨트롤러가 DBMS 구성을 수정하려면 사용자에게 관리자 권한이 있다고 가정합니다. 그렇지 않은 경우 사용자는 튜닝 실험을 수행하기 위해 OtterTune의 다른 하드웨어에 데이터베이스 복사본을 배포해야 합니다. 이를 위해서는 사용자가 작업 부하를 재현하거나 프로덕션 DBMS에 쿼리를 전달해야 합니다. 전체 사전 설정 및 제한 사항은 당사 문서를 참조하세요.

머신러닝 파이프라인

아래 그림은 OtterTune ML 파이프라인이 데이터를 처리하는 과정을 보여주며, 모든 관찰 내용은 지식 베이스에 저장됩니다.

OtterTune은 먼저 관찰 데이터를 작업 부하 특성화 구성 요소에 제공합니다. 이 구성 요소는 다양한 작업 부하의 성능 변화와 두드러진 특성을 가장 효과적으로 포착할 수 있는 작은 DBMS 지표 집합을 식별할 수 있습니다.

다음 단계에서는 "노브 식별 구성 요소"가 DBMS 성능에 가장 큰 영향을 미치는 노브를 포함하여 노브 순위 목록을 생성합니다. 그런 다음 OtterTune은 이 모든 정보를 자동 튜너에 "공급"하여 대상 DBMS의 작업 부하를 지식 기반의 가장 가까운 작업 부하에 매핑하고 이 작업 부하 데이터를 재사용하여 더 나은 구성을 생성합니다.

아래에서 기계 학습 파이프라인의 각 구성 요소를 더 자세히 살펴보겠습니다.

워크로드 특성화: OtterTune은 DBMS의 내부 런타임 지표를 활용하여 특정 워크로드의 동작을 특성화합니다. 이러한 지표는 워크로드 동작의 여러 측면을 포착하므로 워크로드를 정확하게 나타냅니다. 그러나 많은 지표가 중복됩니다. 일부는 서로 다른 단위로 동일한 측정값을 나타내고 다른 일부는 DBMS의 일부 독립적 구성 요소를 나타내지만 해당 값은 높은 상관 관계를 갖습니다. 기계 학습 모델의 복잡성을 줄이려면 중복 측정항목을 정렬하는 것이 중요합니다. 따라서 우리는 상관 관계를 기반으로 DBMS 측정 항목을 클러스터링하고 가장 대표적인 것, 특히 중앙값에 가장 가까운 것을 선택합니다. 기계 학습의 후속 구성 요소는 이러한 측정값을 사용합니다.

노브 식별: DBMS에는 수백 개의 노브가 있을 수 있지만 그 중 일부만 성능에 영향을 미칩니다. OtterTune은 Lasso라는 널리 사용되는 기능 선택 기술을 사용하여 시스템의 전체 성능에 가장 큰 영향을 미치는 손잡이를 결정합니다. 이 기술을 사용하여 지식 베이스의 데이터를 처리함으로써 OtterTune은 DBMS 손잡이의 중요도 순서를 결정할 수 있었습니다.

다음으로 OtterTune은 구성 권장 사항을 작성할 때 사용할 노브 수를 결정해야 합니다. 노브를 너무 많이 사용하면 OtterTune의 튜닝 시간이 크게 늘어나고, 노브를 너무 적게 사용하면 최상의 구성을 찾기가 어려워집니다. OtterTune은 증분 방식을 사용하여 이 프로세스를 자동화하고 튜닝 세션 중에 사용되는 노브 수를 점차적으로 늘립니다. 이 접근 방식을 통해 OtterTune은 가장 중요한 소수의 손잡이를 먼저 사용하여 구성을 탐색하고 미세 조정한 다음 다른 손잡이를 고려하도록 확장할 수 있습니다.

자동 튜너: 자동 튜너 구성 요소는 2단계 분석 방법을 사용하여 각 관찰 단계 후에 권장할 구성을 결정합니다.

먼저 시스템은 워크로드 특성화 구성요소에서 찾은 성능 데이터를 사용하여 현재 대상 DBMS 워크로드에 가장 가까운 과거 튜닝 프로세스를 식별하고 두 측정항목을 비교하여 어떤 값이 다른 노브 설정에 유사하게 반응하는지 확인합니다.

OtterTune은 수집된 데이터와 지식 베이스에서 가장 가까운 워크로드 데이터에 통계 모델을 적용하여 또 다른 노브 구성을 시도합니다. 이 모델을 통해 OtterTune은 가능한 모든 구성에서 DBMS가 어떻게 작동할지 예측할 수 있습니다. OtterTune은 탐색(모델 개선을 위한 정보 수집)과 활용(탐욕스럽게 목표 지표에 접근)을 번갈아 가며 다음 구성을 조정합니다.

달성

OtterTune은 Python으로 작성되었습니다.

워크로드 특성화 및 손잡이 식별 구성 요소의 경우 런타임 성능은 주요 고려 사항이 아니므로 scikit-learn을 사용하여 해당 기계 학습 알고리즘을 구현합니다. 이러한 알고리즘은 백그라운드 프로세스에서 실행되며 새로 생성된 데이터를 지식 기반으로 흡수합니다.

구성 요소를 자동으로 조정하려면 기계 학습 알고리즘이 매우 중요합니다. 각 관찰 단계는 완료 후 실행되어 OtterTune이 테스트할 다음 단계를 선택할 수 있도록 새로운 데이터를 흡수해야 합니다. 성능을 고려해야 하기 때문에 TensorFlow를 사용하여 구현합니다.

DBMS 하드웨어, 손잡이 구성 및 런타임 성능 지표를 수집하기 위해 OLTP-Bench 벤치마크 프레임워크를 OtterTune의 컨트롤러에 통합했습니다.

실험적 디자인

우리는 평가를 위해 다음 구성 옵션을 사용하여 MySQL 및 Postgres에 대한 최고의 OtterTune 구성을 비교했습니다.

기본값: DBMS 초기 구성
튜닝 스크립트: 오픈 소스 튜닝 제안 도구로 만든 구성
DBA: 인간 DBA가 선택한 구성
RDS: Amazon 개발자 관리형 DBMS의 사용자 지정 구성을 동일한 EC2 인스턴스 유형에 적용합니다.
Amazon EC2 스팟 인스턴스에 대한 모든 실험을 수행했습니다. 각 실험은 m4.large 및 m3.xlarge 유형의 두 인스턴스에서 실행됩니다. 하나는 OtterTune 컨트롤러용이고 다른 하나는 대상 DBMS 배포용입니다. OtterTune 튜닝 관리자와 지식 기반은 20코어 128G 메모리 서버에 로컬로 배포됩니다.

워크로드는 온라인 거래 시스템의 성능을 평가하기 위한 업계 표준인 TPC-C를 사용합니다.

평가

실험에 사용된 각 데이터베이스(MySQL 및 Postgres)에 대해 지연 시간과 처리량을 측정했으며 아래 차트에 결과가 나와 있습니다. 첫 번째 차트는 트랜잭션을 완료하는 데 걸리는 '최악의 경우' 시간을 나타내는 '99번째 백분위수 대기 시간' 수치를 보여줍니다. 두 번째 차트는 초당 수행된 평균 트랜잭션 수로 측정된 처리량 결과를 보여줍니다.

MySQL 실험 결과

튜닝 스크립트 및 RDS의 구성과 비교하여 OtterTune에서 생성된 최적의 구성은 OtterTune이 MySQL 대기 시간을 약 60% 줄이고 처리량을 22%~35% 늘렸습니다. OtterTune은 또한 거의 DBA만큼 좋은 구성을 생성합니다.

TPC-C 로드 중에는 몇 개의 MySQL 노브만 성능에 큰 영향을 미칩니다. OtterTune 및 DBA의 구성은 이러한 노브를 좋은 값으로 설정합니다. 하나의 손잡이에 최적이 아닌 값이 할당되었기 때문에 RDS 성능이 약간 나빴습니다. 손잡이 하나만 수정되었기 때문에 튜닝 스크립트가 최악의 성능을 발휘했습니다.

Postgres 실험 결과

지연 시간 측면에서 Postgres 기본 구성과 비교하여 OtterTune, 튜닝 도구, DBA 및 RDS 구성이 비슷한 개선을 달성했습니다. 이는 아마도 OLTP-Bench 클라이언트와 DBMS 간의 네트워크 오버헤드 때문이라고 할 수 있습니다. 처리량 측면에서 Postgres는 OtterTune으로 구성된 경우 DBA 및 튜닝 스크립트보다 12% 더 높고 RDS보다 32% 더 높습니다.

결론

OtterTune은 DBMS 구성 노브에 대한 최적의 값을 찾는 프로세스를 자동화합니다. 이전 튜닝 프로세스에서 수집된 학습 데이터를 재사용하여 새로 배포된 DBMS를 튜닝합니다. OtterTune은 기계 학습 모델을 훈련하기 위해 초기화 데이터 세트를 생성할 필요가 없기 때문에 튜닝 시간이 크게 단축됩니다.

다음은 무엇인가요? DBaaS(DBMS 호스트에 대한 원격 로그인이 불가능한 경우)의 인기가 높아짐에 따라 OtterTune은 곧 원격 로그인 없이 대상 DBMS의 하드웨어 기능을 자동으로 조사할 수 있게 될 것입니다.

OtterTune에 대해 자세히 알아보려면 GitHub에서 논문과 코드를 확인하세요. 곧 OtterTune을 온라인 튜닝 서비스로 만들 예정이므로 이 사이트를 계속 지켜봐 주시기 바랍니다.

위 내용은 DBMS의 자동화된 운영 및 유지관리를 위한 머신러닝 애플리케이션의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!