＃＃＃導入＃＃＃
| データベース管理システム (DBMS) は、データ集約型のアプリケーション システムの最も重要な部分です。大量のデータと複雑なワークロードを処理できます。しかし、キャッシュに使用されるメモリの量やストレージ デバイスにデータが書き込まれる頻度などの要素を制御する構成「ノブ」が数百または数千あるため、管理が困難です。組織はキャンペーンの微調整を支援するために専門家を雇うことがよくありますが、専門家は多くの企業にとって法外な費用がかかります。
|
この記事は、カーネギー メロン大学の 3 人のゲスト、ダナ ヴァン アーケン、アンディ パブロ、ジェフ ゴードンによって書かれました。共著記事です。このプロジェクトでは、学術研究者が AWS クラウドクレジット研究プログラム (https://aws.amazon.com/research-credits/) を使用して科学的進歩をサポートする方法を示します。
OtterTune は、カーネギーメロン大学データベース グループ (http://db.cs.cmu.edu/projects/autotune/) の学生と研究者によって開発された新しいツールで、適切な設定を見つけるために [構成] ボタンを自動的に見つけます。目標は、データベース管理の専門知識がない人でも、誰でも簡単に DBMS を導入できるようにすることです。
OtterTune は、以前にデプロイされた DBMS のチューニングから得られた知識を最大限に活用して、新しくデプロイされた DBMS をチューニングするため、他の DBMS 構成ツールとは異なります。これにより、新しくデプロイされた DBMS の調整に必要な時間とリソースが大幅に削減されます。この目的のために、OtterTune は、以前のチューニング セッションから収集されたチューニング データを含むデータベースを維持します。このデータを使用して、DBMS がさまざまな構成にどのように反応するかに関する情報を取得する機械学習モデルを構築します。 OtterTune はこれらのモデルを使用して、新しいアプリケーションを試すときにユーザーをガイドし、レイテンシーの削減やスループットの向上など、特定の目標を向上させる設定を提案します。
この記事では、OtterTune の機械学習パイプラインの各コンポーネントを調査し、DBMS の構成を調整するためにそれらがどのように相互に関係しているかを示します。次に、OtterTune の最適な構成のパフォーマンスを、データベース管理者 (DBA) やその他の自動チューニング ツールによって選択された構成と比較することにより、MySQL および Postgres での OtterTune のパフォーマンスを評価しました。
OtterTune は、カーネギー メロン大学のデータベース グループの学生と研究者によって開発されたオープン ソース ツールです。すべてのコードは 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 チューニング実験のためにデータベースの 2 番目のコピーを他のハードウェアにデプロイできます。これには、ユーザーがワークロード トレースを再生するか、本番グレードの DBMS からクエリを転送する必要があります。仮定と制限の詳細については、論文 (http://db.cs.cmu.edu/papers/2017/tuning-sigmod2017.pdf) を参照してください。
機械学習パイプライン
下の図は、データが OtterTune の機械学習パイプラインを通過する際にどのように処理されるかを示しています。すべての観測結果は OtterTune のデータベースに保存されます。
OtterTune は、まず観察結果をワークロード特性評価コンポーネントに送信します。このコンポーネントは、さまざまなワークロードのパフォーマンスの変化と固有の特性を最も正確に捕捉する、少数の DBMS メトリクスを識別します。
次に、ノブ識別コンポーネントは、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 で書かれています。
ワークロードの特性評価とノブの識別の 2 つのコンポーネントに関する限り、実行時のパフォーマンスは心配する主な問題ではないため、scikit-learn を使用して対応する機械学習アルゴリズムを実装しました。これらのアルゴリズムはバックグラウンド プロセスで実行され、新しいデータが OtterTune のデータベースで利用可能になるとすぐに統合されます。
自動チューナーに関しては、機械学習アルゴリズムがクリティカル パス上にあります。これらは各観察期間の後に実行され、OtterTune が次に試行するボタン構成を選択できるように新しいデータを統合します。パフォーマンスが考慮されるため、これらのアルゴリズムは TensorFlow を使用して実装されました。
DBMS ハードウェア、ボタン構成、実行時のパフォーマンス メトリックに関するデータを収集するために、OtterTune のコントローラーを OLTP-Bench ベンチマーク フレームワークと統合しました。
＃＃＃評価する＃＃＃
評価のために、MySQL および Postgres のパフォーマンスについて、OtterTune によって選択された最適な構成と次の構成を比較しました。
デフォルト: DBMS によって提供される構成
チューニング スクリプト: オープンソースのチューニング アドバイザリ ツールによって生成された構成
DBA: データベース管理者が生成した構成-
#RDS: DBMS 用にカスタマイズされた構成。Amazon RD によって管理され、同じタイプの EC2 インスタンスにデプロイされます。 -
- すべての実験は Amazon EC2 スポット インスタンスで実行されました。各トライアルは 2 つのインスタンスで実行されました。1 つは OtterTune のコントローラー用で、もう 1 つはデプロイされたターゲット DBMS システム用です。それぞれ m4.large インスタンス タイプと m3.xlarge インスタンス タイプを使用しました。 OtterTune のチューニング マネージャーとデータ データベースを、20 コアと 128 GB のメモリを備えたローカル サーバーにデプロイしました。
- オンライン トランザクション処理 (OLTP) システムのパフォーマンスを評価するための業界標準である TPC-C ワークロードを使用しました。
実験で使用した各データベース (MySQL と Postgres) に対してレイテンシーとスループットを測定しました。次の図は結果を示しています。最初のグラフは、トランザクションが完了するまでにかかる「最悪の場合」の時間を表す 99 パーセンタイル レイテンシの量を示しています。 2 番目のグラフは、1 秒あたりに完了したトランザクションの平均数として測定されたスループットの結果を示しています。
MySQL の結果:
OtterTune によって生成された最適な構成と、チューニング スクリプトおよび RDS によって生成された構成を比較すると、OtterTune 構成を使用すると、MySQL のレイテンシーが約 60% 削減され、スループットが 35% 増加することがわかります。 OtterTune は、データベース管理者が選択したものと同等の結果をもたらす構成も生成します。
いくつかの MySQL ボタンは、TPC-C ワークロードのパフォーマンスに大きな影響を与えます。 OtterTune とデータベース管理者によって生成された構成は、これらの各ボタンに適切な設定を提供します。 RDS は、1 つのボタンに次善の設定を提供したため、パフォーマンスが若干低下しました。ボタンが 1 つだけ変更されたため、調整スクリプトの構成のパフォーマンスは最悪でした。
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 のコードを参照してください。この Web サイト (http://ottertune.cs.cmu.edu/) を今後もご覧ください。オンライン チューニング サービスである OtterTune を間もなく開始します。
著者について：＃＃＃
Dana Van Aken は、カーネギー メロン大学のコンピューター サイエンスの博士課程の学生で、アンドリュー パブロ博士の指導を受けています。
Andy Pavlo は、カーネギー メロン大学コンピューター サイエンス学部のデータベース サイエンスの助教授です。
Geoff Gordon は、カーネギー メロン大学の機械学習部門の准教授兼教育副ディレクターです。
