OCI MySQL Database高可用性＆HeatWave検証

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Slide 3

Slide 3 text

この度弊社は 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 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。

Slide 4

Slide 4 text

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© 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システムのエンドポイントにアクセスすることで、高可用性を意識することなく稼働中のプライマリインスタンスにアクセスできますエンドポイント

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

© 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/

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© 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を跨いだ構成

Slide 21

Slide 21 text

© 2021 Database Technology Inc. All Rights Reserved. 21 検証結果 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を跨いだ構成)

Slide 22

Slide 22 text

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© 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のデータを保持可能

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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システム (シングル)

Slide 38

Slide 38 text

© 2021 Database Technology Inc. All Rights Reserved. 38 検証結果 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

Slide 39

Slide 39 text

© 2021 Database Technology Inc. All Rights Reserved. 39 検証結果 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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Slide 43

Slide 43 text

© 2021 Database Technology Inc. All Rights Reserved. 43 検証結果 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の方が遅くなる結果となりました。

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

© 2021 Database Technology Inc. All Rights Reserved. 45 検証結果 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万行

Slide 46

Slide 46 text

© 2021 Database Technology Inc. All Rights Reserved. 46 検証結果 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万行

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

Slide 49

Slide 49 text

© 2021 Database Technology Inc. All Rights Reserved. 49 検証結果 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強制実行で、極僅かにパフォーマンスが落ちる場合があります

Slide 50

Slide 50 text

Slide 51

Slide 51 text

© 2021 Database Technology Inc. All Rights Reserved. 51 検証結果 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の連携状態で差はない結果となりました