기계 학습으로 인해 데이터베이스 관리 시스템 운영자가 실직하게 될까요?

소개	데이터베이스 관리 시스템(DBMS)은 데이터 집약적인 애플리케이션 시스템에서 가장 중요한 부분입니다. 대용량 데이터와 복잡한 워크로드를 처리할 수 있습니다. 그러나 캐싱에 사용되는 메모리 양, 데이터가 저장 장치에 기록되는 빈도 등의 요소를 제어하는 ​​수백 또는 수천 개의 구성 "손잡이"가 있기 때문에 관리하기가 어렵습니다. 조직에서는 캠페인을 세부적으로 조정하기 위해 전문가를 고용하는 경우가 많지만 많은 기업에서는 전문가에게 비용이 엄청나게 많이 듭니다.

이 기사는 Carnegie Mellon University의 게스트 세 명(Dana Van Aken, Andy Pavlo 및 Geoff Gordon 기사)이 공동 집필했습니다. 이 프로젝트는 학술 연구자들이 연구 프로그램용 AWS 클라우드 크레딧(https://aws.amazon.com/research-credits/)을 사용하여 과학적 혁신을 지원할 수 있는 방법을 보여줍니다.

OtterTune은 적절한 설정을 찾기 위해 DBMS 버튼 구성을 자동화하는 Carnegie Mellon University Database Group(http://db.cs.cmu.edu/projects/autotune/)의 학생 및 연구원이 개발한 새로운 도구입니다. 목표는 데이터베이스 관리에 대한 전문 지식이 없는 사람이라도 누구나 쉽게 DBMS를 배포할 수 있도록 하는 것입니다.

OtterTune은 이전에 배포한 DBMS를 튜닝하여 얻은 지식을 완전히 활용하여 새로 배포된 DBMS를 튜닝한다는 점에서 다른 DBMS 구성 도구와 다릅니다. 이는 새로 배포된 DBMS를 조정하는 데 필요한 시간과 리소스를 크게 줄여줍니다. 이를 위해 OtterTune은 이전 튜닝 세션에서 수집된 튜닝 데이터가 포함된 데이터베이스를 유지 관리합니다. 이 데이터를 사용하여 DBMS가 다양한 구성에 반응하는 방식에 대한 정보를 캡처하는 기계 학습 모델을 구축합니다. OtterTune은 이러한 모델을 사용하여 사용자가 새로운 애플리케이션을 시험해 볼 때 지연 시간 감소 또는 처리량 증가와 같은 특정 목표를 개선하는 설정을 제안하도록 안내합니다.

이 기사에서는 OtterTune 기계 학습 파이프라인의 각 구성 요소를 살펴보고 이 구성 요소가 서로 어떻게 연관되어 DBMS 구성을 조정하는지 보여줍니다. 그런 다음 최적 구성의 성능을 데이터베이스 관리자(DBA) 및 기타 자동화된 튜닝 도구가 선택한 구성과 비교하여 MySQL 및 Postgres에서 OtterTune의 성능을 평가했습니다.

OtterTune은 Carnegie Mellon University 데이터베이스 그룹의 학생과 연구원이 개발한 오픈 소스 도구입니다. 모든 코드는 GitHub(https://github.com/cmu-db/ottertune)에 있으며 Apache License 2.0에 따라 릴리스됩니다.

작동 방식

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

새 튜닝 세션이 시작될 때 사용자는 최적화할 특정 목표(예: 대기 시간 또는 처리량)를 OtterTune에 알려줍니다. 클라이언트 컨트롤러는 대상 DBMS에 연결하고 Amazon EC2 인스턴스 유형과 현재 대상을 수집합니다.

그런 다음 컨트롤러는 첫 번째 관찰 기간을 시작합니다. 이 기간 동안 DBMS를 관찰하고 특정 대상을 기록합니다. 관찰 기간이 끝나면 컨트롤러는 디스크에서 읽은 페이지 수 및 디스크에 쓴 페이지의 MySQL 수와 같은 내부 측정항목을 DBMS에서 수집합니다. 컨트롤러는 특정 목표와 내부 측정항목을 모두 튜닝 관리자에게 반환합니다.

OtterTune의 튜닝 관리자는 메트릭을 수신한 후 이를 저장소에 저장합니다. OtterTune은 결과를 사용하여 컨트롤러가 대상 DBMS에 설치해야 하는 다음 구성을 계산합니다. 튜닝 관리자는 이 구성을 컨트롤러에 반환하고 실제 실행을 통해 예상되는 개선 사항을 추정합니다. 사용자는 튜닝 세션을 계속할지 또는 종료할지 결정할 수 있습니다.

지침

OtterTune은 지원하는 각 DBMS 버전에 대한 버튼 블랙리스트를 유지 관리합니다. 블랙리스트에는 조정할 필요가 없는 버튼(예: DBMS 저장 파일의 경로 이름) 또는 심각하거나 숨겨진 결과를 초래할 수 있는 버튼(예: DBMS의 데이터 손실을 유발할 수 있음)이 포함됩니다. 각 튜닝 세션이 시작될 때 OtterTune은 사용자에게 블랙리스트를 제공하므로 OtterTune이 튜닝을 피하기를 원하는 다른 버튼을 추가할 수 있습니다.

OtterTune은 일부 사용자에게 유용성을 제한할 수 있는 특정 가정을 합니다. 예를 들어, 사용자에게 관리자 권한이 있어 컨트롤러가 DBMS 구성을 수정할 수 있다고 가정합니다. 사용자에게 관리자 권한이 없는 경우 OtterTune 튜닝 실험을 위해 데이터베이스의 두 번째 복사본을 다른 하드웨어에 배포할 수 있습니다. 이를 위해서는 사용자가 작업 부하 추적을 재생하거나 프로덕션 등급 DBMS에서 쿼리를 전달해야 합니다. 가정 및 제한 사항에 대한 자세한 내용은 논문(http://db.cs.cmu.edu/papers/2017/tuning-sigmod2017.pdf)을 참조하세요.

머신러닝 파이프라인

아래 이미지는 OtterTune의 기계 학습 파이프라인을 통과하는 데이터가 어떻게 처리되는지 보여줍니다. 모든 관찰 내용은 OtterTune의 데이터베이스에 저장됩니다.

OtterTune은 먼저 관찰 결과를 작업 부하 특성화 구성 요소로 전송합니다. 이 구성 요소는 성능 변화와 다양한 워크로드의 고유한 특성을 가장 정확하게 캡처하는 작은 DBMS 지표 집합을 식별합니다.

다음으로 Knob Identification 구성 요소는 DBMS 성능에 가장 큰 영향을 미치는 버튼을 나열하는 버튼 정렬 목록을 생성합니다. 그런 다음 OtterTune은 이 모든 정보를 자동 튜너에 제공합니다. 이 구성요소는 대상 DBMS의 작업 부하를 데이터 저장소의 가장 유사한 작업 부하에 매핑하고 작업 부하 데이터를 재사용하여 보다 적절한 구성을 생성합니다.

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

워크로드 특성화: OtterTune은 DBMS의 내부 런타임 지표를 사용하여 워크로드의 동작 특성을 설명합니다. 이러한 지표는 런타임 동작의 다양한 측면을 포착하므로 워크로드를 정확하게 나타냅니다. 그러나 많은 지표는 중복됩니다. 일부는 서로 다른 단위로 기록된 동일한 지표 값이고 다른 일부는 값이 높은 상관 관계가 있는 DBMS의 독립적인 부분을 나타냅니다. 중복 측정항목을 간소화하는 것은 이를 사용하는 기계 학습 모델의 복잡성을 줄여주기 때문에 중요합니다. 이를 위해 DBMS 메트릭을 상관 패턴을 기반으로 클러스터로 나눕니다. 그런 다음 각 클러스터에서 대표 측정항목, 특히 클러스터 중심에 가장 가까운 측정항목을 선택합니다. 기계 학습 파이프라인의 후속 구성 요소는 이러한 측정항목을 사용합니다.

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

OtterTune은 제안된 구성에 사용할 버튼 수를 결정해야 합니다. 버튼을 너무 많이 사용하면 OtterTune의 최적화 시간이 크게 늘어납니다. 버튼을 너무 적게 사용하면 OtterTune이 최적의 구성을 찾지 못합니다. 이 프로세스를 자동화하기 위해 OtterTune은 증분 방식을 사용합니다. 튜닝 세션에 사용되는 버튼 수가 점차 늘어납니다. 이 접근 방식을 통해 OtterTune은 가장 중요한 버튼의 작은 집합에 대한 구성을 탐색 및 최적화한 다음 추가 버튼을 고려하도록 범위를 확장할 수 있습니다.

자동 조정기: 자동 조정 구성 요소는 각 관찰 기간 후에 2단계 분석을 수행하여 OtterTune이 권장해야 하는 구성을 결정합니다.

먼저 시스템은 작업 부하 특성화 구성 요소에서 식별된 지표에 대한 성능 데이터를 사용하여 대상 DBMS 작업 부하를 가장 잘 나타내는 이전 튜닝 세션의 작업 부하를 식별합니다. 세션의 지표를 이전 워크로드의 지표와 비교하여 어느 것이 다른 버튼 설정에 유사하게 반응하는지 확인합니다.

그런 다음 OtterTune은 다른 버튼 구성을 선택하여 시도해 봅니다. 이는 수집된 데이터뿐만 아니라 저장소에서 가장 유사한 워크로드의 데이터에 통계 모델을 적용합니다. 이 모델을 통해 OtterTune은 가능한 모든 구성을 사용하여 DBMS가 어떻게 작동할지 예측할 수 있습니다. OtterTune은 탐색(모델 개선을 위한 정보 수집)과 활용(특정 지표에서 가능한 한 성능을 발휘) 간의 균형을 유지하기 위해 다음 구성을 최적화합니다.

달성

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

워크로드 특성화 및 Knob 식별에 관한 한 런타임 성능은 걱정할 주요 문제가 아니므로 scikit-learn을 사용하여 해당 기계 학습 알고리즘을 구현했습니다. 이러한 알고리즘은 백그라운드 프로세스에서 실행되며 OtterTune의 데이터베이스에서 새로운 데이터를 사용할 수 있게 되는 즉시 통합됩니다.

자동 튜너의 경우 기계 학습 알고리즘이 중요한 경로에 있습니다. 각 관찰 기간 후에 실행되어 OtterTune이 다음에 시도할 버튼 구성을 선택할 수 있도록 새 데이터를 통합합니다. 성능이 고려 사항이므로 TensorFlow를 사용하여 이러한 알고리즘을 구현했습니다.

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

평가

평가를 위해 OtterTune이 선택한 최상의 구성을 MySQL 및 Postgres 성능에 대한 다음 구성과 비교했습니다.

• 기본값: DBMS에서 제공하는 구성
• 튜닝 스크립트: 오픈 소스 튜닝 자문 도구로 생성된 구성
• DBA: 데이터베이스 관리자가 생성한 구성
• RDS: Amazon RD에서 관리하고 동일한 유형의 EC2 인스턴스에 배포된 DBMS용으로 사용자 정의된 구성입니다.

Amazon EC2 스팟 인스턴스에서 모든 실험을 수행했습니다. 우리는 두 개의 인스턴스(OtterTune의 컨트롤러용 인스턴스와 배포된 대상 DBMS 시스템용 인스턴스)에서 각 평가판을 수행했습니다. 우리는 각각 m4.large 및 m3.xlarge 인스턴스 유형을 사용했습니다. 우리는 20개의 코어와 128GB의 메모리를 갖춘 로컬 서버에 OtterTune의 튜닝 관리자와 데이터 데이터베이스를 배포했습니다.

온라인 트랜잭션 처리(OLTP) 시스템의 성능을 평가하기 위한 업계 표준인 TPC-C 워크로드를 사용했습니다.

실험에 사용한 각 데이터베이스인 MySQL과 Postgres에 대해 대기 시간과 처리량을 측정했습니다. 다음 그림은 결과를 보여줍니다. 첫 번째 그래프는 99번째 백분위수 대기 시간을 보여줍니다. 이는 트랜잭션이 완료되는 데 걸리는 "최악의 경우" 시간을 나타냅니다. 두 번째 그래프는 초당 완료된 평균 트랜잭션 수로 측정된 처리량 결과를 보여줍니다.

MySQL 결과:

OtterTune에서 생성된 최적의 구성과 튜닝 스크립트 및 RDS에서 생성된 구성을 비교하면 OtterTune 구성을 사용하면 MySQL의 지연 시간이 약 60% 감소하고 처리량이 35% 증가하는 것을 확인할 수 있습니다. OtterTune은 또한 데이터베이스 관리자가 선택한 결과만큼 좋은 구성을 생성합니다.

몇 가지 MySQL 버튼은 TPC-C 워크로드 성능에 상당한 영향을 미칩니다. OtterTune과 데이터베이스 관리자가 생성한 구성은 이러한 각 버튼에 대한 좋은 설정을 제공합니다. RDS는 하나의 버튼에 대해 최적이 아닌 설정을 제공하기 때문에 성능이 약간 떨어졌습니다. 튜닝 스크립트의 구성은 버튼 하나만 수정했기 때문에 최악의 성능을 보였습니다.

Postgres에 대한 결과:

대기 시간 측면에서 OtterTune, 튜닝 도구, 데이터베이스 관리 및 RDS 생성 구성은 모두 Postgres의 기본 설정에 비해 유사한 개선 사항을 보여줍니다. 이는 아마도 네트워크를 통한 OLTP-Bench 클라이언트와 DBMS 간의 왕복에 필요한 오버헤드 때문이라고 할 수 있습니다. 처리량의 경우 OtterTune에서 권장하는 구성을 사용하면 Postgres 성능은 데이터베이스 관리자 및 튜닝 스크립트가 선택한 구성보다 약 12%, RDS보다 약 32% 더 높습니다.

MySQL과 유사하게 Postgres 성능에 중요한 영향을 미치는 버튼은 몇 개뿐입니다. OtterTune, 데이터베이스 관리자, 튜닝 스크립트 및 RDS 생성 구성은 모두 이러한 버튼을 수정하며 대부분은 꽤 좋은 설정을 제공합니다.

결론

OtterTune은 DBMS 구성 버튼에 대한 올바른 설정을 찾는 프로세스를 자동화합니다. 새로 배포된 DBMS를 튜닝하기 위해 이전 튜닝 세션에서 수집된 교육 데이터를 재사용합니다. OtterTune에서는 기계 학습 모델 교육을 위한 초기 데이터 세트 생성이 필요하지 않으므로 튜닝 시간이 크게 단축됩니다.

다음은 무엇인가요? DBMS 호스트 시스템에 대한 원격 액세스가 없는 DBaaS 배포의 인기가 높아지는 것을 수용하기 위해 OtterTune은 곧 원격 액세스 없이 대상 DMBS의 하드웨어 기능을 자동으로 감지할 수 있게 될 것입니다.

OtterTune에 대한 자세한 내용은 당사의 논문이나 GitHub의 코드를 참조하세요. 이 웹사이트(http://ottertune.cs.cmu.edu/)를 계속 지켜봐 주시기 바랍니다. 곧 온라인 튜닝 서비스인 OtterTune을 출시할 예정입니다.
저자 소개:

Dana Van Aken은 Andrew Pavlo 박사의 지도를 받는 Carnegie Mellon University의 컴퓨터 과학 박사 과정 학생입니다.

Andy Pavlo는 카네기 멜론 대학교 컴퓨터 과학과의 데이터베이스 과학 조교수입니다.

Geoff Gordon은 카네기멜론대학교 기계학습학과의 부교수이자 교육부 부책임자입니다.

위 내용은 기계 학습으로 인해 데이터베이스 관리 시스템 운영자가 실직하게 될까요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!