OCI MySQL Database高可用性＆HeatWave検証

Oracle Cloud Infrastructure MySQL Database 高可用性＆HeatWave検証 2021/05/28 株式会社データベーステクノロジ

1. はじめに 2. 検証結果 1. 高可用性 2. HeatWave 3. 総評
© 2021 Database Technology Inc. All Rights Reserved. 2 目次

この度弊社は MDS検証の第2回検証項目として、高可用性ならびにHeatWaveの運用における調査・検証、シングル構成とのパフォーマンス比較を実施しました。その結果を本資料に纏めましたので是非ご参考にしていただきサービス利用、事前調査等の一助となれば幸甚です。第1回検証結果についてはスライドシェアにて公開しております。
https://www.slideshare.net/ssuserbe6417/oracle-cloud-infrastructuremysql-database-servise2021416upd-246305196?qid=490e8f42- 6dff-46e2-b92a-8a047f828b0a&v=&b=&from_search=3 © 2021 Database Technology Inc. All Rights Reserved. 3 はじめに高可用性に関してはLimited Availabilityリリース時点のものとなります。 Oracle、MySQLは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。

１．高可用性検証１-１．構築・操作

© 2021 Database Technology Inc. All Rights Reserved. 6 MDS高可用性構成の説明
MySQLのグループレプリケーションで実装されており、プライマリと2つのセカンダリの3つのMySQLインスタンスで構成されています。 ADまたはFD

© 2021 Database Technology Inc. All Rights Reserved. 7 利用概要図
VCN SUBNET DBシステム Internet Gateway Route Table Security Lists Security Lists クライアント AD-1 AD-2 AD-3 プライマリセカンダリセカンダリユーザーはDBシステムのエンドポイントにアクセスすることで、高可用性を意識することなく稼働中のプライマリインスタンスにアクセスできますエンドポイント

© 2021 Database Technology Inc. All Rights Reserved. 8 構築
スタンドアロンのDBシステム構築手順の構成選択で、「高可用性」を選択することで構築できます。

© 2021 Database Technology Inc. All Rights Reserved. 9 プライマリの手動切り替え
DBシステムの詳細画面で手動切り替え可能です。

© 2021 Database Technology Inc. All Rights Reserved. 10 バックアップ
従来のDBシステムのバックアップ手順と一切の差異がありません。リストア従来のDBシステムのリストア手順と一切の差異がありません。構成選択では「高可用性」以外が選択不可となる制御がされています。選択不可選択不可

© 2021 Database Technology Inc. All Rights Reserved. 11 高可用性構成のDBシステム構築は、作成時はラジオボタン形式の選択で
「高可用性」を選ぶだけで作成でき、非常に簡単に構築可能です。バックアップ・リストアについては特別必要な操作や設定もありません。見解

１．高可用性検証１-２．切り替えテスト

AD-1 AD-2 AD-3 プライマリセカンダリセカンダリ © 2021 Database Technology
Inc. All Rights Reserved. 13 検証内容 DBシステムクライアント ⚫ 切り替え時のアプリの挙動 ⚫ 一時停止 or 切断 ⚫ 再接続される or されない ⚫ 切り替えに掛かる時間 ※SQLで結果が取得できない時間検証方法 ⚫ 手動切り替え ※WEBコンソールで操作 ⚫ フェイルオーバー ※mysqlslapでメモリ負荷をかけて発生させる SQL連続発行切り替え mysqlslap：MySQL公式サポートの負荷エミュレーションクライアント https://dev.mysql.com/doc/refman/ja/mysqlslap.html

© 2021 Database Technology Inc. All Rights Reserved. 14 検証環境
AD-1 AD-2 AD-3 プライマリセカンダリセカンダリ DBシステムクライアントクライアントシェイプ VM.Standard2.1 CPU 1 OCPU メモリ 15 GB ストレージ 50 GB アプリ Apache JMeter DBシステム構成高可用性シェイプ MySQL.VM.Standard.E3.1.8GB CPU 1OCPU メモリ 8GB ストレージ 50GB Apache JMeter：JDBCリクエストやJavaプログラムを実行できるテストツール https://jmeter.apache.org/

© 2021 Database Technology Inc. All Rights Reserved. 15 検証結果
切り替え方法アプリの挙動再接続再接続可能になるまでの時間手動切り替え切断されるされない 1.558秒（10回平均値）フェイルオーバー切断されるされない 2.842秒（3回平均値）切り替えが行われると、接続中アプリは切断されることが確認できました。自動再接続はされませんので、アプリ側は再接続するような仕組みが必要です。切り替えに掛かる時間は概ね1～3秒ですので、アプリ側による再接続試行は1秒毎に数回が望ましいと考えます。

⚫ アプリ側 DB接続状況 ①・・・検証開始特に何も発生せず（2分間） ②・・・3分半、SQLレスポンスなしを確認 ③・・・4分間、DB接続エラーを確認（コネクションプールはここで切断） ④・・・2分間、DB接続及びSQL応答を確認 ⑤・・・2秒間 DB接続エラーを確認
⑥・・・DB接続が可能となり、SQL応答あり ※②、③の状況はスワップ等応答に時間のかかる状況若しくはネットワークのサチレーションが発生したと推察される（オラクル社MDSプロダクトマネージャ様見解）フェイルオーバー発生切断フェイルオーバーによる影響

© 2021 Database Technology Inc. All Rights Reserved. 17 フェイルオーバーの発生と挙動
mysqlslap を使用してメモリ負荷をかけることで、フェイルオーバーの発生を確認しました。プライマリが落ちた後、hostnameの切り替わりが確認できたので、問題なくフェイルオーバーされたと考えています。フェイルオーバーして状態がアクティブになってから、旧プライマリへスイッチバックを行うと、旧プライマリのhostnameが取得できたことから自動復旧はされたと考えています。

１．高可用性検証１-３．パフォーマンステスト

© 2021 Database Technology Inc. All Rights Reserved. 19 検証内容
1分間に処理できるトランザクション数「tpmC」を計測します検証方法ベンチマークツール：tpcc-mysqlを使用テスト毎にDBをバックアップより再作成します高可用性構成については、プライマリの切り替え前後共に計測します高可用性構成はADを跨いだ構成で計測します

© 2021 Database Technology Inc. All Rights Reserved. 20 検証環境
AD-1 AD-2 AD-3 プライマリセカンダリセカンダリ DBシステム (高可用性) クライアントクライアントシェイプ VM.Standard.E3.Flex CPU 48 OCPU メモリ 768 GB ストレージ 500 GB 負荷ツール tpcc-mysql DBシステム構成シングル／高可用性シェイプ MySQL.VM.Standard.E3.16.256GB CPU 16 OCPU メモリ 256 GB ストレージ 300 GB データ量約 15 GB DBシステム (シングル) ADを跨いだ構成

17,751 28,372 40,885 49,168 74,492 94,772 14,123 26,068 28,036 28,206 28,524 28,597 0 10,000 20,000 30,000 40,000 50,000 60,000 70,000 80,000 90,000 100,000 10 20 30 50 100 500 TpmC 同時接続数シングルと高可用性の比較シングル高可用性(ADを跨いだ構成)

14,123 15,468 9,753 0 5,000 10,000 15,000 20,000 10 TpmC 同時接続数手動切り替え前後の比較切り替え前切り替え後同一AD 切り替え後クライアントとDBシステムが異なるAD

高可用性構成の方がパフォーマンスが低い結果となりました。グループレプリケーションのノード間同期による影響であると考えられます。プライマリの切り替えによるパフォーマンスの影響は殆ど無いと言える結果となりました。ただし、クライアントとプライマリが異なるADとなる場合、パフォーマンスが落ちる結果となりました。 ADが異なることで距離的優位性が下がるためと考えられます。同一AD内でFDを跨いだ構成の場合は、今回の結果ほどパフォーマンスが落ちないと思われます。

２．HeatWave検証２-１．機能概要調査

© 2021 Database Technology Inc. All Rights Reserved. 25 従来の例
⚫ OLTPとOLAPで異なるDBで構成 ⚫ データ連携はETLツールで実行 HeatWave ⚫ OLTPとOLAPで単一のDBシステムで構成 ※裏で複数のノード（HeatWaveクラスタ）が稼働 ⚫ データ連携はALTER TABLE文のクエリで実行

© 2021 Database Technology Inc. All Rights Reserved. 26 必須システム構成
⚫ 前提条件サービスリミットが最小構成を満たしていること ⚫ DBシステム構成 MySQL Database for HeatWave VM.Standard.E3 Nodes Count 1 以上 MySQL HeatWave VM.Standard.E3 Nodes Count 2 以上シェイプ MySQL.HeatWave.VM.Standard.E3 CPU 16 OCPU メモリ 512 GB ノード数 2 ～ 24 台ノード1台あたり約400GBのデータを保持可能

２．HeatWave検証２-２．構築・操作

© 2021 Database Technology Inc. All Rights Reserved. 28 利用概要図
VCN SUBNET DBシステム Internet Gateway Route Table Security Lists Security Lists クライアントユーザーはDBシステムのエンドポイントにアクセスし、通常のMDSを使用する時と同じSQL文でHeatWaveによる高速分析が可能です HeatWaveクラスタデータロード

© 2021 Database Technology Inc. All Rights Reserved. 29 HeatWave利用方法
１．DBシステム構築スタンドアロンのDBシステム構築手順の構成選択で、「HeatWave」を選択し、 HeatWave利用可能なDBシステムを構築します。

２．HeatWaveクラスタの追加 DBシステムの詳細画面で、HeatWaveクラスタを追加します

３．データロード対象テーブルのSECONDARY_ENGINEを「RAPID」に設定します。 mysql> ALTER TABLE テーブル名 SECONDARY_ENGINE=RAPID; mysql> ALTER TABLE テーブル名 SECONDARY_LOAD; データをHeatWaveにロードします。 ※HeatWaveノードの再起動時には、データロードを再度行う必要があります。以上で、HeatWaveでの高速分析が可能になります ※テーブルは作成済みの前提 ※1回のみ

© 2021 Database Technology Inc. All Rights Reserved. 32 HeatWaveクラスタの停止・起動
DBシステムの詳細画面で、ボタンクリックで起動・停止が可能です

© 2021 Database Technology Inc. All Rights Reserved. 33 HeatWaveクラスタの削除
DBシステムの詳細画面で、ボタンクリックで削除が可能です

© 2021 Database Technology Inc. All Rights Reserved. 34 バックアップ
従来のDBシステムのバックアップ手順と一切の差異がありません。リストア従来のDBシステムのリストア手順と一切の差異がありません。 HeatWaveを利用する際には、再度データロードが必要になります。

２．HeatWave検証２-３．パフォーマンステスト

⚫ SELECT文SQLの応答時間検証方法 ⚫ スタースキーマベンチマーク https://clickhouse.tech/docs/en/getting-started/example-datasets/star-schema/ ⚫ スタースキーマデータの生成 ⚫ 13種類のSELECT文によるベンチマークテスト HeatWaveクラスタ DBシステム (HeatWave) クライアント DBシステム (シングル) SQL発行

HeatWaveクラスタ © 2021 Database Technology Inc. All Rights Reserved. 37
検証環境 DBシステム (HeatWave) クライアントクライアントシェイプ VM.Standard.E3.Flex CPU 2 OCPU メモリ 16 GB ストレージ 1024 GB DBシステム構成シングル HeatWave シェイプ VM.Standard.E3.16.256GB HeatWave.VM.Standard.E3 CPU 16 OCPU メモリ 256 GB 512 GB ストレージ 1024 GB データ量約 237 GB（6 億行）索引なしありなし DBシステム (シングル)

12:10:43 3:36:04 00:00:45 00:00:00 02:00:00 04:00:00 06:00:00 08:00:00 10:00:00 12:00:00 14:00:00 SQL応答時間ベンチマーク時間の合計の比較シングル索引なしシングル索引あり HeatWave 約1000分の1 約300分の1

00:54:16 01:25:11 1.65秒 00:55:05 00:49:14 1.70秒 00:54:36 00:49:05 1.79秒 00:56:52 00:04:53 2.12秒 00:57:39 00:00:49 2.96秒 00:57:03 00:00:06 1.87秒 00:59:03 00:17:00 5.26秒 00:58:44 00:00:55 3.94秒 00:57:22 00:00:02 4.43秒 00:56:18 00:00:00 3.48秒 00:56:29 00:08:19 3.94秒 00:54:07 00:00:19 6.35秒 00:53:10 00:00:11 5.06秒 12:10:43 03:36:04 44.55秒シングル索引なしシングル索引あり HeatWave 100% ベンチマーク各種SQLの時間の割合合計 Q4.3 Q4.2 Q4.1 Q3.4 Q3.3 Q3.2 Q3.1 Q2.3 Q2.2 Q2.1 Q1.3 Q1.2 Q1.1

ベンチマーク（selectによるデータ取得時間）の合計に関しては、 HeatWaveの方が約1000分の1の時間で取得できる結果となりました。ただし、検索対象によって絞られる件数次第では、 HeatWaveよりも索引利用した方が早くなる傾向が見られました。ベンチマークの合計に対する各種SQLの割合について、シングルではあまりバラつきが見られませんが、 HeatWaveではバラつきが見られました。 ※最大でQ4.2の約500分の1、最小でQ1.1の約2000分の1 HeatWaveによる改善比率はSQLの内容によってバラつきがあることが言えます。

２．HeatWave検証２-４．別視点でのパフォーマンステスト

⚫ 多重JOINクエリ検証方法自己結合を複数回繰り返した重いSQLの応答時間を、 HeatWaveの連携状態で比較します HeatWaveクラスタ DBシステム (HeatWave) クライアント SQL発行・多重JOIN HW連携切替

00:08:39 00:24:36 00:00:00 00:05:00 00:10:00 00:15:00 00:20:00 00:25:00 00:30:00 SQL応答時間多重のJOINの比較 HeatWave無効 HeatWave有効テーブルサイズ：約237GB 行数：約6億行自己結合を行うSQLは、HeatWaveの方が遅くなる結果となりました。

⚫ 全文検索との比較検証方法 ⚫ 文字列カラムに対する部分一致検索 ⚫ HeatWave無効：LIKE検索 ⚫ HeatWave有効：LIKE検索 ⚫ HeatWave無効：全文検索（FULLTEXTインデックス） HeatWaveクラスタ DBシステム (HeatWave) クライアント SQL発行・LIKE検索・全文検索 HW連携切替

4.14 秒 3.93 秒 4.13 秒 4.15 秒 0.14 秒 0.10 秒 0.13 秒 0.41 秒 0.00 秒 1.00 秒 2.00 秒 3.00 秒 4.00 秒 5.00 秒 Q1 Q2 Q3 Q4 SQL応答時間 LIKE検索 HeatWave有効／無効の比較 HeatWave無効 HeatWave有効テーブルサイズ：約1.3GB 行数：約388万行

0.14 秒 0.10 秒 0.13 秒 0.41 秒 0.02 秒 0.01 秒 0.01 秒 0.01 秒 0.00 秒 0.10 秒 0.20 秒 0.30 秒 0.40 秒 0.50 秒 Q1 Q2 Q3 Q4 SQL応答時間 LIKE検索と全文検索の比較 HeatWave有効 LIKE検索 HeatWave無効全文検索テーブルサイズ：約1.3GB 行数：約388万行

テキストのLIKE検索では、索引利用可能な前方一致のみならず、後方一致と部分一致でもHeatWaveで約30倍早くなる結果となりました。部分一致に関しては、HeatWaveでのLIKE検索よりも、 FULLTEXTインデックスによる全文検索の方が早い結果となりました。文字列検索においては、全文検索とHeatWaveを使い分けることでより高いパフォーマンスを得ることが出来ると考えます。

⚫ HeatWaveの強制利用検証方法通常でHeatWaveが利用されないSQLを、 HeatWave強制利用して実行した場合の比較 HeatWaveクラスタ DBシステム (HeatWave) クライアント HW連携済み SQL発行・通常・HW強制利用

0.11 秒 0.75 秒 0.00 秒 0.10 秒 0.20 秒 0.30 秒 0.40 秒 0.50 秒 0.60 秒 0.70 秒 0.80 秒 0.90 秒 1.00 秒 SQL応答時間 HeatWave強制利用通常 HeatWave強制利用テーブルサイズ：約4GB 行数：2000万行 HeatWave強制実行で、極僅かにパフォーマンスが落ちる場合があります

⚫ 挿入・更新・削除検証方法 HeatWaveの連携状態で比較します 2000万行の挿入・更新・削除にかかる時間を計測します HeatWaveクラスタ DBシステム (HeatWave) クライアント SQL発行・INSERT ・UPDATE ・DELETE HW連携切替

00:04:11 00:01:44 00:01:29 00:04:12 00:01:44 00:01:33 00:00:00 00:01:00 00:02:00 00:03:00 00:04:00 00:05:00 挿入更新削除 SQL応答時間挿入・更新・削除 HeatWave無効 HeatWave有効テーブルサイズ：約4GB 行数：2000万行挿入・更新・削除は、HeatWaveの連携状態で差はない結果となりました

総評

Thank you

OCI MySQL Database高可用性＆HeatWave検証

OCI MySQL Database高可用性＆HeatWave検証

More Decks by Database Technology Inc.

Other Decks in Technology

Featured

Transcript