機械学習でデータベースを自動調整

この記事は、カーネギーメロン大学の Dana Van Aken、Andy Pavlo、Geoff Gordon によって執筆されました。このプロジェクトは、学術研究者が AWS クラウドクレジット研究プログラムを使用して科学的ブレークスルーを推進する方法を示しています。

データベース管理システム (DBMS) は、データ集約型アプリケーションにとって重要な部分です。大量のデータや複雑なワークロードを処理できますが、キャッシュに使用するメモリの量やディスクへの書き込み頻度などの要素を制御する「ノブ」（または構成変数）が数百または数千あるため、管理が困難になることもあります。多くの場合、組織はチューニングを行うために専門家を雇わなければなりませんが、多くの組織にとって専門家を雇うのは費用がかかりすぎます。カーネギーメロン大学のデータベース研究グループの学生と研究者は、DBMS の「ノブ」の適切な設定を自動的に見つける OtterTune という新しいツールを開発しています。このツールは、データベース管理の専門知識がなくても誰でも DBMS を導入できるように設計されています。

OtterTune は、以前の DBMS チューニングの知識を活用して新しい DBMS をチューニングする点で他の DBMS セットアップ ツールとは異なり、必要な時間とリソースを大幅に削減します。 OtterTune は、以前のチューニングの知識ベースを維持することでこれを実現します。この知識ベースは、DBMS がさまざまな設定にどのように応答するかをキャプチャするための機械学習 (ML) モデルの構築に使用されます。 OtterTune はこれらのモデルを使用して新しいアプリケーションの実験をガイドし、レイテンシの低減やスループットの向上などの最終目標を改善する構成を推奨します。

この記事では、OtterTune の機械学習パイプラインの各コンポーネントと、それらがどのように相互作用して DBMS 設定を調整するかについて説明します。次に、MySQL と Postgres での OtterTune のチューニング パフォーマンスを評価し、その最適な構成を DBA や他の自動チューニング ツールの構成と比較します。

OtterTune は、カーネギーメロン大学のデータベース研究グループの学生と研究者によって開発されたオープンソースツールです。すべてのコードは 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 ワークロードに最も近い履歴チューニング プロセスを識別し、2 つのメトリックを比較して、異なるノブ設定に対してどの値が同様に応答するかを識別します。

次に、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 の 2 つのインスタンスで実行されました。1 つは OtterTune コントローラー用、もう 1 つはターゲット DBMS デプロイメント用です。 OtterTune チューニング マネージャーとナレッジ ベースは、20 個のコアと 128G のメモリを備えたローカル サーバーに展開されます。

使用されるワークロードは、オンライン トランザクション システムのパフォーマンスを評価するための業界標準である TPC-C です。

評価する

実験では、MySQL と Postgres の各データベースのレイテンシとスループットを測定しました。次のグラフに結果を示します。最初のグラフは、「99 パーセンタイル レイテンシ」の数を示しています。これは、トランザクションを完了するのにかかる「最悪の場合」の時間を表します。 2 番目のグラフは、1 秒あたりに実行されるトランザクションの平均数として測定されたスループットの結果を示しています。

MySQL 実験結果

チューニング スクリプトと RDS 構成と比較すると、OtterTune によって生成された最適な構成では、MySQL のレイテンシが約 60% 削減され、スループットが 22% ～ 35% 向上しました。 OtterTune は、DBA とほぼ同等の構成も生成します。

TPC-C ワークロードでは、MySQL のノブのほんの一部だけがパフォーマンスに大きな影響を与えました。 OtterTune および DBA 構成では、これらのノブに適切な値が設定されます。ノブに最適でない値が割り当てられたため、RDS のパフォーマンスはわずかに低下しました。チューニング スクリプトは 1 つのノブのみを変更するため、パフォーマンスは最悪です。

Postgres 実験結果

レイテンシに関しては、OtterTune、チューニング ツール、DBA、および RDS 構成は、Postgres のデフォルト構成と比較して同様の改善を達成しました。これはおそらく、OLTP-Bench クライアントと DBMS 間のネットワーク オーバーヘッドによるものと考えられます。スループットに関しては、OtterTune 構成の Postgres は DBA およびチューニング スクリプトよりも 12% 高く、RDS よりも 32% 高くなります。

結論

OtterTune は、DBMS 構成ノブの最適な値を見つけるプロセスを自動化します。以前のチューニング プロセスで収集されたトレーニング データを再利用して、新しく導入された DBMS をチューニングします。 OtterTune は機械学習モデルをトレーニングするために初期化データセットを生成する必要がないため、チューニング時間が大幅に短縮されます。

次は何でしょう? DBaaS (DBMS ホストへのリモート ログインが不可能) の人気の高まりに対応するため、OtterTune はまもなく、リモート ログインを必要とせずに対象 DBMS のハードウェア機能を自動的に検出できるようになります。