この記事は Percona Live 2019 in Texas Austin 現地レポ(Session Day 2) Side.A です。

Self-Driving Databases: It All Starts with Workload Forecasting

カーネギーメロン大学 Lin Ma氏

機械学習を使用した自律的データベースチューニング手法についての発表です。
まず、自律的データベースとは人間によるオペレーション無しにチューニング、バックアップ、リカバリ等を自動的に行うことのできるデータベースとなりますが、チューニングにフォーカスした自律的データベースのでした。

構成は以下となります。

データベースで受けたワークロードを元に、QueryBot5000というプログラムが機械学習の結果として導出したチューニングプランなどを
データベースにフィードバックして操作を行う、というものです。

QueryBot5000はGithubに公開されています。

https://github.com/malin1993ml/QueryBot5000

QueryBot5000は以下のフェーズで未来予測とチューニングを行います。

perception
– 現在のワークロードから未来のワークロードの予測を行う
action model
– perceptionからのフィードバックでどうインデックスを作成するか導出
planning
– 実際のチューニングをどのような順序で行えばよいか考える

現在でも時系列の負荷の計測と予測からindex, partitionなどのチューニングを行うデータベースはOracle Automnomos DatabaseやAzure Automatic Index Management等が存在します。

実行クエリ数の曲線から、未来における曲線を予測
また曲線のパターンから、未来における曲線のパターンを予測

QueryBot5000は以下のモジュールで構成されています。

• preprocess
• clusterer
• forecaster

preprocessor

• テンプレ化 -> クエリのノーマライズ
• パラメータの収集
• 意味的なチェック(例 select a,bとselect b,a)

これらの処理で100万パターンを1000にできる。

clusterer

• pysical feature
  タプルの読み込み・書き込みのレイテンシ
• logical feature
  クエリのタイプとJOINで参照する列
• arrival Ragte fueature
  時間とクエリ数のmax/minの変数値値を計測
  アプリごとの曲線からDBクラスタとしての平均値を導出

forcaster

• clustererやpreprocessorからのフィードバックで未来予測

テストではPKのみのテーブルから始めて動作確認を実施

ベンチマークでは以下のプログラムを使用したいうことです。

https://github.com/cmu-db/terrier

セッション中、負荷予測についてのグラフもありましたが、かなり正確でした。
近い将来DBAがインデックスを貼る必要がなくなるかもしれません。

Fast, Reliable, Secure and Affordable: MongoDB on AWS EC2

MongoDBをAWS上で構築する場合の実践的な内容についてのセッションでした。

AWSにはDocumentDBというMongoDB互換のデータベースがありますが、この場合はEC2にMongoDBを構築するケースについての説明です。

インスタンスサイズ

• 基本的にはM系、C系、R系から選択するのが良い
• 最新の世代のインスタンスは、よりパフォーマンスがよく値段も安いのでそれらを使用する

ディスク

• EBS(gp2 ssd)が最もよい
• io1/local ssd(i3, i3en)は使用しないほうが良い(コストとIOPSのバランスが理由)
• 最新世代のインスタンスは、よりEBSとの帯域は広く、オーバーヘッドは少ない
• サイズの大きなインスタンスであるほど帯域は増える
• EBS(gp2)はオペレーション/秒のコストがio1よりも低い
• gp2 IOPSの計算式

Base = 3 * volume size in GB
Max = 16000 IOPS(16TB volume size)
※バーストやスループットの最大値などもあります。

バックアップ

• 以下2つのEBSをマウントすべき
  • OS + Software
  • Data + journal(MongoDB)
• ジャーナル機能の有効化

• ジャーナルと同じディレクトリにデータを保存
• 頻繁にスナップショットを取るべき
  • スナップショットは変更分のディスクブロックのみに課金
• AWS Backupは12 .. 24時間ごとに取られる
  • https://github.com/sqlxpert/aws-tag-sched-ops を使用すると10分ごとにスナップショットの取得を自動化

フォールトトレラント

• 基本的なフォールトトレラント戦略はマルチAZにレプリカを配置すること
• MongoDBのレプリカセットは基本的に1ノードのプライマリと、2ノードのセカンダリによって構成されるので

のように配置する(リージョン間のNWレイテンシは要確認)

• アプリケーションレイヤも同じようにマルチAZにすること。
• アクセスは常にレプリカセット名で接続を行うこと。
• 障害ノードの検出をなるべくすばやく行うための施策
  • EC2 Fleetの使用
  • 構成管理ツールの使用(AWS OpsWorks, Chef,Ansible,SaltCloud,etc)
  • Pipelineを使用したAMIの自動ビルド

セキュリティ

• KMSにディスク暗号化、及びスナップショット暗号化のためのキーを格納
• TLS を使用したアプリケーショントラフィックの暗号化
• Security groupsを使用してfirewallを設定し、またインスタンスIDによる接続制御を行う(同一リージョン内)
• デフォルトのEBS service keyを使用してはいけない
• separate keyをすべてのレプリカセットに作成する
• Data volume/OS volumneを暗号化する
• KMSのキーポリシで制限する
• 暗号化ボリュームをインスタンスに接続する
• スナップショットからボリュームを作成
• スナップショットをコピー
• replicaSet メンバー間の通信はTLSを使用する
• DNSはRoute 53が推奨
• 自己署名証明書を使用しないこと
• お勧めSSL証明書発行方法
  • Lets Encrypt
  • DigiCert’s duplicate certificte feature + a wildcard certificate
• default security groupは使用しない
• security groupにおける制限にIPを使用しない。security group間で制限する。
• SGでインバウンドのみを監視する場合は全インスタンスを1つのアウトバウンドのSGにまとめ、すべての他のグループのアウトバウンドルールを削除する

例. MongoDB要のセキュリティグループの定義

• IAMロールをEC2に適用
  • AWS API認証
  • APIキーのローテートなどの管理が不要になる
• タスクごとのIAMロール
  • 特定の人のみにシェルアクセスを許可
• AWS Systems Manager – Session Manager
  • SSH鍵の管理無しにシェルアクセスが可能となる

Using Ansible to Manage MySQL at DigitalOcean

DigitalOceanにおけるAnsibleを使用したMySQLの構成事例です。
本セッションは途中から参加しました。

DigitalOceanにおけるロールの使用

Moleculeというソフトウェアを使用してAnsible Roleの開発を行っているようです。

https://molecule.readthedocs.io/en/stable/
Moleculeを使用すると、以下の事を実現できます

• Ansible開発に必要なディレクトリやファイルの初期化
• Yamlのlint
• DockerやEC2を使用したロールのテスト
• インフラテストツールの実行(Testinfraを使用しているそうです)

またMitogenを使用してデプロイの高速化を行っているとのことでした。

https://networkgenomics.com/ansible/

まとめ

現地でしか聞けない情報を得たり、普段会えないエンジニアの方々とコミニュケーションが取れたことは、非常によい経験でした。

登壇者やスポンサーの関係者では無い一般参加での日本人の方との出会いもありました(ニュージーランドのDBAだそうです)

Austinは非常に遠いですが、来年もPercona Liveは開催されますので、ワールドワイドで注目されているイベントに参加を検討してみてはいかがでしょうか。