> [!abstract] 概要（abstract 和訳） > データベース管理システム（DBMS）の設定チューニングは、データ集約的なアプリケーションのあらゆる取り組みにおいて不可欠な側面である。しかしこれは歴史的に困難なタスクであった。なぜなら DBMS にはキャッシュに使用するメモリ量やデータをストレージに書き込む頻度など、システムのあらゆる側面を制御する数百の設定「ノブ」があるからである。これらのノブの問題は、標準化されていない（すなわち、2 つの DBMS が同じノブに異なる名前を使う）、独立していない（すなわち、1 つのノブを変更すると他のノブに影響する可能性がある）、普遍的でない（すなわち、あるアプリケーションで有効なものが別のアプリケーションでは最適でない場合がある）ことである。さらに悪いことに、ノブの効果に関する情報は（高価な）経験からしか得られない。 > これらの課題を克服するために、我々は過去の経験を活用し新しい情報を収集して DBMS 設定をチューニングする自動化アプローチを提案する。我々は教師あり学習と教師なし学習を組み合わせた機械学習手法を使って（1）最も影響の大きいノブを選択し、（2）未知のデータベースワークロードを過去のワークロードにマッピングすることで経験を転用し、（3）ノブ設定を推薦する。我々はこれらの技術を OtterTune という新しいツールで実装し、3 つの DBMS でテストした。我々の評価は、OtterTune が既存ツールや人間の専門家が生成したものと同等かそれ以上の設定を推薦することを示す。 ## 論文情報 - **タイトル**: Automatic Database Management System Tuning Through Large-scale Machine Learning - **著者**: Dana Van Aken（Carnegie Mellon University）、Andrew Pavlo（Carnegie Mellon University）、Geoffrey J. Gordon（Carnegie Mellon University）、Bohan Zhang（Peking University） - **媒体**: ACM SIGMOD International Conference on Management of Data 2017（SIGMOD '17） - **発表年**: 2017 年 5 月 14–19 日、シカゴ、イリノイ州 - **ページ**: 1009–1024 - **DOI**: http://dx.doi.org/10.1145/3035918.3064029 - **実装**: [OtterTune GitHub](https://github.com/cmu-db/ottertune) ## 概要 OtterTune は、過去のチューニングセッションから収集した訓練データを再利用することで新しい DBMS デプロイメントをチューニングする自動サービスである。教師あり学習（Lasso、ガウシアンプロセス回帰）と教師なし学習（因子分析、k-means クラスタリング）を組み合わせた3段階の機械学習パイプラインを持ち、ワークロードの特性化、重要ノブの特定、設定の推薦を行う。MySQL、Postgres、Actian Vector の3つの DBMS での実験で、デフォルト設定比58〜94%のレイテンシ低下と、人間の DBA が作成した設定と同等かそれ以上の性能を60分以内に達成することを示した。 ## 問題設定 DBMS 設定チューニングが困難な理由として、論文は4つの課題を挙げる。 1. **依存関係（Dependencies）**: ノブは相互に依存するため、1 つのノブを変えると他のノブの効果が変わる。最適設定の探索は NP 困難であることが知られる。図1a（YCSB / MySQL）でバッファプールとログファイルサイズの組み合わせによりレイテンシが非線形に変化する様子を示す。 2. **連続設定（Continuous Settings）**: あるノブの最適値は 0 から RAM 容量まで任意の値をとりうる。図1b では、バッファプールサイズを 10 MB から 3 GB に増加させた際、1.5 GB で最良性能となりその後急速に性能が劣化する様子を示す。 3. **設定の再利用不可（Non-Reusable Configurations）**: あるワークロードに最適な設定が別のワークロードで最悪になる。図1c では Config #1 が Workload #3 のレイテンシを 3500% 悪化させることを示す。 4. **チューニング複雑性の増大（Tuning Complexity）**: ノブ数は MySQL が15年で6倍、Postgres が3倍に増加した（図1d）。DBA がすべてを把握することは不可能になっている。 **Figure 1: Motivating Examples** – YCSB ワークロードで MySQL の設定を変えた際の性能変化と、MySQL/Postgres のノブ数増加トレンド。 ![[_attachments/van-aken-etal-parameters/fig01-motivating-examples.png]] (Figure 1. 4 つのサブ図が示す DBMS チューニングの本質的困難さ：ノブ依存関係、連続設定の非線形性、設定の非再利用性、バージョンに伴うノブ数増加。Source: Van Aken et al., SIGMOD 2017.) ## 提案手法 ### アーキテクチャ OtterTune は2つの主要コンポーネントで構成される。 - **コントローラ（Controller）**: クライアント側。標準 API（JDBC）経由で対象 DBMS に接続し、ランタイム情報を収集し、新しい設定をインストールし、性能測定を行う。 - **チューニングマネージャ（Tuning Manager）**: サーバー側。コントローラから受け取った情報と過去のチューニングセッションのデータをリポジトリに蓄積し、ML モデルを構築して最適な設定を選択する。 リポジトリには DBMS の設定と性能データのみ格納される（データベースの内容や機密情報は含まない）。DBMS のメジャーバージョン別に管理する。 **Figure 2: OtterTune Architecture** – チューニングマネージャ（分析・計画）、ML モデル、データリポジトリ、コントローラ、DBMS の連携。 ![[_attachments/van-aken-etal-parameters/fig02-architecture.png]] (Figure 2. OtterTune の2層構成。コントローラが DBMS からメトリクスを収集し、チューニングマネージャが ML モデルを使って次の設定を推薦するフィードバックループ。Source: Van Aken et al., SIGMOD 2017.) ### 機械学習パイプライン 3段階のパイプラインで構成される（図3）。 **Figure 3: OtterTune ML Pipeline** – ワークロード特性化、ノブ特定、自動チューナーの3段階データ処理パス。 ![[_attachments/van-aken-etal-parameters/fig03-ml-pipeline.png]] (Figure 3. データリポジトリから始まり、因子分析＋k-means でメトリクスを削減し、Lasso でノブを選択し、GP 回帰で次の設定を推薦するパイプライン全体像。Source: Van Aken et al., SIGMOD 2017.) #### ステップ1: ワークロード特性化（Workload Characterization） DBMS の内部ランタイムメトリクスを使ってワークロードの特性を捉える（論理的なワークロード分析ではなく）。内部メトリクスはノブ設定の変化を直接反映するためより正確だ。 - **冗長メトリクスの除去**: MySQL の 131 メトリクスを 93%、Postgres の 57 メトリクスを 82% 削減する 1. **因子分析（Factor Analysis）**: 高次元メトリクスデータを低次元の因子に変換。相互相関パターンを捉える 2. **k-means クラスタリング**: 因子座標を使ってメトリクスをクラスタリング。各クラスタからクラスタ中心に最も近い1つのメトリクスを代表として保持 3. k の選択は自動ヒューリスティック（Pham et al. 2005）で決定。人手のクラスタ数指定を不要にする - **ワークロードマッピング**: 目標ワークロードと過去のワークロードの類似度をユークリッド距離（十分位数ビニング後）で計算し、最類似ワークロードを特定。動的マッピング（観測期間ごとに更新）が静的マッピングより精度が高い。 #### ステップ2: ノブ特定（Knob Identification） **Lasso**（L1 正則化最小二乗法）で性能に最も影響するノブを特定する。OLS に対する Lasso の利点は、解釈可能性・安定性・計算効率であり、理論的にも実証的にも一貫した特徴選択アルゴリズムとして機能する。 - **特徴量**: ノブとその2次多項式特徴量（相互積）。2次特徴量によってノブ間の依存関係を検出できる（例: バッファプールサイズとログバッファサイズの積がモデルに選択されれば、両者の依存関係が判明する） - **前処理**: カテゴリ特徴のダミー変数化 + 標準化（平均を引いて標準偏差で割る） - **Lasso パス**: L1 ペナルティを高から低へ減らしながら回帰を繰り返す。各ノブがモデルに加わる順序が重要度ランキングになる - **段階的ノブ選択（Incremental Knob Selection）**: チューニング開始時は4ノブから始め、60分ごとに2ノブずつ追加。固定ノブ数よりも常に優れた設定を生成する（§7.3） #### ステップ3: 設定推薦（Configuration Recommendation） 2フェーズで設定を推薦する。 **フェーズ1: ワークロードマッピング**（§6.1） ステップ1で得た類似ワークロードのリポジトリデータを使って、目標ワークロードに最も近いワークロードを特定する。 **フェーズ2: ガウシアンプロセス（GP）回帰**（§6.2） GP は探索（exploitation）と活用（exploration）を理論的に妥当な方法でトレードオフできる点でベイズ最適化における標準的な手法。GP は既定でも信頼区間を提供する。 - 選択済みワークロードのデータで GP モデルを訓練し、目標ワークロードのデータで更新 - マッピングされたワークロードとの不完全な一致は、未実験設定の分散に ridge 項を加えることで対処 - **探索（Exploration）**: GP の未知領域（大きな分散）を調べる。過去に試みた min/max を超えた値の探索が可能 - **活用（Exploitation）**: 既知の良い設定の近傍を調べて最適化を深める - 次の設定は「期待改善量（Expected Improvement）」が最大のものを選択 - **勾配降下法**: 初期化セット（上位設定:ランダム = 1:10）から勾配降下で局所最適を探索。1回の勾配降下は10〜20秒 ## 新規性 | 既存手法の限界 | OtterTune の解決 | |---|---| | ベンダー固有（DB2 Performance Wizard, Oracle など）| 複数 DBMS 対応（MySQL・Postgres・Vector）| | 手動ステップが必要（DBA の介入、2番目のDB展開など）| 完全自動、管理者権限のみ必要 | | 各デプロイメントを独立して扱う（経験の再利用なし）| 過去のチューニングセッションを再利用 | | iTuned: 初期サンプリング（Latin Hypercube）が必要で収束が遅い | 既存データから開始し30〜45分で収束 | | heuristic・ルールベース（MySQLTuner, PGTune）| データ駆動のML手法 | ## 実験設定 - **環境**: Amazon EC2（コントローラ: m4.large/4vCPU/16GB、DBMS: m3.xlarge/4vCPU/15GB、チューニングマネージャ: ローカルサーバー/20コア/128GB RAM） - **DBMS**: MySQL v5.6、Postgres v9.3、Actian Vector v4.2 - **ワークロード**: YCSB、TPC-C（OLTP標準）、Wikipedia（OLTP複合）、TPC-H（OLAP） - **訓練データ**: DBMS あたり 30k 以上のトライアル（YCSB 15 バリアント × ランダムノブスイープ） - **比較対象**: iTuned（GPベース、初期サンプリングあり）、MySQLTuner、PGTune、人間 DBA（MySQL 15年超専門家, Postgres 6年超専門家）、Amazon RDS 設定 - **観測期間**: OLTP は5分固定、OLAP は全クエリ実行時間 ## 実験結果 ### ノブ数の影響（§7.3） - 段階的ノブ選択（Incremental）は常にすべての固定ノブ数設定より優れる - MySQL/Postgres: 4ノブ固定が次善（バッファプールサイズ、ログファイルサイズ、フラッシュ方式が支配的） - Vector: 8ノブ以上が必要（並列度ノブが4ノブ設定に含まれない） **Figure 5/6: Tuning Evaluation** – OtterTune と iTuned の比較（TPC-C / Wikipedia）。 ![[_attachments/van-aken-etal-parameters/fig06-tuning-evaluation-oltp.png]] (Figure 6/7. TPC-C と Wikipedia ワークロードでの OtterTune（青線）対 iTuned（赤線）の99パーセンタイルレイテンシ推移。OtterTune は30〜45分以内で iTuned の最終性能を上回る。Source: Van Aken et al., SIGMOD 2017.) ### チューニング性能比較（§7.4） - TPC-C / MySQL: OtterTune は iTuned より **85% 低いレイテンシ** - TPC-C / Postgres: OtterTune は iTuned より **75% 低いレイテンシ** - iTuned は初期サンプリング（10試行）のために最初の60〜120分で有意な改善が得られない ### 有効性比較（§7.6） **MySQL（TPC-C）**: - vs チューニングスクリプト（MySQLTuner）: スループット **35% 向上**、レイテンシ **60% 低下** - vs Amazon RDS: スループット **22% 向上**、レイテンシ **57% 低下** - vs 人間 DBA: ほぼ同等（DBA は OtterTune が禁止する耐久性設定まで変更していた） **Postgres（TPC-C）**: - vs DBA: スループット **〜12% 向上** - vs Amazon RDS: スループット **〜32% 向上** - vs チューニングスクリプト（PGTune）: OtterTune の checkpoint_segments を 540 に設定（DBAの32や RDS の16と比べ高すぎる値。レイテンシ最小化のために有効だがクラッシュ後の回復時間が長くなる問題点） **Figure 10/11: Efficacy Comparison** – デフォルト/OtterTune/チューニングスクリプト/DBA/RDS のスループットとレイテンシ比較。 ![[_attachments/van-aken-etal-parameters/fig10-efficacy-comparison.png]] (Figure 10/11. MySQL と Postgres における TPC-C ワークロードのスループット（左）と99パーセンタイルレイテンシ（右）の比較。OtterTune はデフォルト比で大幅に改善し、人間 DBA に匹敵する。Source: Van Aken et al., SIGMOD 2017.) ### 実行時間内訳（§7.5） - MySQL/Postgres: ワークロード実行が大部分（5分間の観測期間が支配） - ワークロードマッピング: 30〜40秒 - 設定生成（GP + 勾配降下）: 5〜15秒 ## 考察 - **強み**: 既存データの再利用による高速収束（<60分）。複数 DBMS 対応。人間専門家に匹敵する品質。探索と活用のバランスが良い。 - **限界**: 一部のノブはデフォルト設定の意味上危険（例: checkpoint_segments を過度に大きくすると回復時間が長くなる）。レイテンシ最適化が目標の場合、回復コストのような副作用を考慮しない。DBMS を再起動するコストを推薦に含めない。 - **前提条件**: コントローラが管理者権限を持つこと。物理設計（インデックス等）は既に適切に設定されている前提。ハードウェアプロファイルは事前定義済みリストから選択（自動検出は未対応）。 ## 強み / 弱点・課題 **強み**: - 過去のチューニングセッションからの知識転用という新規アイデア - 完全自動パイプライン（3段階ML、ヒューリスティックなし） - 複数 DBMS をまたいで動作（イノービ固有ではない） - 段階的ノブ選択による安定した収束 **弱点・課題（論文が示す限界と懸念）**: - グローバルノブのみ対象（テーブル・コンポーネント固有ノブは将来課題） - ハードウェア自動検出が未実装（DBaaS では問題になる） - チェックポイント設定など「安全でないノブ」の自動判定が未対応 - 物理設計の自動化（インデックス選択等）は対象外（付録 C で将来研究と述べる） - 一部のノブは DBMS 再起動が必要で、再起動コストを現在は無視している ## 関連概念 - [[データベースノブチューニング]] — 本論文が定義した手法の直接の親概念 - [[ベイズ最適化]] — GP 回帰によるノブ推薦はベイズ最適化の一例 - [[データベース O&M]] — 上位ドメイン概念 - [[データベース自律診断]] — 診断とチューニングは隣接する概念 - [[Carnegie Mellon University]] / [[Andrew Pavlo]] / [[Dana Van Aken]] - [[OtterTune]] — 本論文が発表した OSS システム ## 出典 - `.raw/papers/van-aken-etal-parameters.pdf`（CMU 教員ページ掲載版） - DOI: http://dx.doi.org/10.1145/3035918.3064029