HeatWave on AWS のインバウンドレプリケーションで HeatWave エンジン有効時のレプリケーションラグを確認してみた！

祝 2 周年 HeatWave の 〇〇 やってみた！LT 大会！！ HeatWavejp Meetup #13 2025/4/17

Transcript

1. HeatWave on AWS の インバウンドレプリケーションで HeatWave エンジン有効時の レプリケーションラグを確認してみた！ HeatWavejp Meetup #13（祝 2 周年）2025/4/17 まつひさ（hmatsu47）
2. 自己紹介 松久裕保（@hmatsu47） • https://qiita.com/hmatsu47 • 現在： ◦ 名古屋で Web インフラのお守り係をしています ◦ SRE チームに所属しつつ技術検証の支援をしています ◦ HeatWave は細々と検証中です ◦ 昨年 10 月（#10）以来の発表参加です 2
3. 最近の活動 • BuriKaigi2025（2/1・富山県立大） ◦ 「ベクトルストア入門」 https://www.docswell.com/s/hmatsu47/ZP2LY6-2025-01-19-235645 • PHP カンファレンス名古屋 2025（2/22・ウインクあいち） ◦ 「さいきんの MySQL との付き合い方 〜 MySQL 8.0 より後の世界へようこそ 〜」 https://www.docswell.com/s/hmatsu47/Z3GL92-2025-02-07-144215 3
4. 前回（#10）の発表 • HeatWave on AWS の PrivateLink インバウンドレプリ ケーション構成 ◦ ソース DB（Aurora）のフェイルオーバーに追従できるように、 フェイルオーバーイベントを捕捉し Lambda を起動・実行して PrivateLink 内部 NLB のターゲット切り替えを行う ▪ フェイルオーバー開始を捕捉する場合、概ね 4 分程度のタイムラグで追従 ▪ フェイルオーバー完了を捕捉する場合、概ね 5 分程度のタイムラグで追従 4
5. 構成図（前回の発表） 5
6. 構成図（前回の発表） 6 ※逆向きの PrivateLink（Query 用）で クライアント（Web サーバー）から接続
7. なぜこの構成を検討？ • Web アプリケーションから HeatWave エンジンに分析・ 集計クエリを流して高速化したい ◦ ただしメインの DB は 複数 Reader を Active 状態で活用可能な Aurora をそのまま使いたい ▪ HeatWave on AWS の HA 構成ではセカンダリインスタンスへアクセス不可 ▪ HA 構成では HeatWave エンジンは使用不可 ▪ PrivateLink 接続でのインバウンドレプリケーションも不可 ※複数のインバウンドレプリケーション構成で冗長化する想定 7
8. 実際に使われているクエリを流してみた • 集計クエリは HeatWave エンジンで高速化を実現 ◦ 実験環境 ▪ ソース : Aurora MySQL 3.04.1/db.r6g.4xlarge（16vCPU/Mem128GiB） ▪ レプリカ : HeatWave MySQL 8.4.3/4vCPU/Mem32GiB/Cluster256GiB ▪ データ容量：約 160GiB（インデックス込み） ▪ HeatWave エンジンにロードされた容量：圧縮後約 60GiB ▪ Aurora は（ある程度）バッファプールにデータが載った状態で比較 【注】use_secondary_engine=FORCED で実行しないと遅くなるケースあり 8
9. 結果は（一部抜粋・小数点以下第三位四捨五入） 9 クエリ a.Aurora (db.r6g.4xlarge 16vCPU/Mem128GiB) b.HeatWave (4vCPU/Mem32GiB/Cluster256GiB) a/b クエリ① 160.92 秒 1.50 秒 107.42 倍 クエリ② 1.65 秒 0.51 秒 3.25 倍 クエリ③ 2.63 秒 0.23 秒 11.43 倍 クエリ④ 169.61 秒 3.70 秒 45.79 倍 クエリ⑤ 1.99 秒 0.14 秒 13.79 倍 クエリ⑥ 1.11 秒 0.30 秒 3.73 倍 クエリ⑦ 2.75 秒 0.15 秒 18.79 倍
10. ここから本題：今回の発表のために調査したこと • HeatWave on AWS のインバウンドレプリケーション時の HeatWave エンジン更新ラグ a. レプリカ MySQL DB の InnoDB 更新ラグ比較 ▪ SHOW REPLICA STATUS の Seconds_Behind_Source ▪ SECONDARY_LOAD 時の更新ラグを SECONDARY_UNLOAD 時と比較 → SECONDARY_LOAD 時の HeatWave エンジン更新オーバーヘッドは？ b. InnoDB → HeatWave エンジンの伝搬ラグ ▪ performance_schema の rpd_tables.NROWS（テーブル内行数）追従 10
11. ここ↓のラグを調査 11 a.（SECONDARY_LOAD vs SECONDARY_UNLOAD） b.
12. なぜこの調査を実施したのか • 一般的に列指向のデータフォーマットは更新に弱いため ◦ 行指向フォーマットと比べると更新処理のオーバーヘッドが大き くなりがち → HeatWave エンジンではどうなのかを知りたい 12
13. なお、HeatWave エンジン（Cluster）の仕様は • HeatWave User Guide / 2.2.7 Change Propagation DML operations, INSERT, UPDATE, and DELETE, on the MySQL DB System do not wait for changes to be propagated to the HeatWave Cluster; （略） Data changes on the MySQL DB System node are propagated to HeatWave in batch transactions. Change propagation is initiated as follows: • Every 200ms. • When the change propagation buffer reaches its 64MB capacity. • When data updated by DML operations on the MySQL DB System are read by a subsequent HeatWave query. 13
14. 調査その 1 • レプリカ MySQL DB の InnoDB 更新ラグ比較 ◦ 約 2 億行・約 40GiB（HeatWave エンジンの容量）のテーブルに対し 1. オートコミットで個別に計 25,000 行を挿入 2. 2,500 行毎のトランザクション処理で計 25,000 行挿入 3. 1,000 行単位で計 25,000 行更新 ◦ ソース（Aurora）で更新処理を流しながらレプリカ（HeatWave）で 約 1 秒間隔で SHOW REPLICA STATUS を実行 ▪ Seconds_Behind_Source の推移を確認 ▪ SECONDARY_UNLOAD 時と SECONDARY_LOAD 時を比較 14
15. 結果（SECONDARY_UNLOAD 時 vs SECONDARY_LOAD 時） • 目立った差は無し ◦ それぞれ 1. SECONDARY_UNLOAD 時・SECONDARY_LOAD 時いずれも最大 63 秒前後 2. 同・いずれも最大 1 秒程度 3. 同・いずれも最大 1 秒程度 ◦ Multi Thread Applier を（実質）無効化しても大きな違いは無し ▪ replica_parallel_workers = 1（0 にはできない） →ちなみにデフォルト値はやたらと大きい（MySQL 4.32GB で 48） 15
16. 調査その 2 • InnoDB → HeatWave エンジンの伝搬ラグ ◦ 先ほどと同じテーブルに対し 1. オートコミットで個別に計 25,000 行を挿入 2. 2,500 行毎のトランザクション処理で計 25,000 行挿入 ◦ ソース（Aurora）で更新処理を流しながらレプリカ（HeatWave）で 約 1 秒間隔で確認クエリを実行 → SHOW REPLICA STATUS & p_s の rpd_tables.NROWS を SELECT ▪ ソースからの行挿入完了後、レプリカで Seconds_Behind_Source が 0 に なったタイミングから NROWS がどの程度遅れて挿入済み行数に達するか？ 16
17. 結果（rpd_tables.NROWS による遅延確認） • いずれも 0 秒 ◦ 行挿入完了・Seconds_Behind_Source が 0・NROWS が挿入済み 行数に達したタイミングが（ほぼ）同じ ▪ なお NROWS の値は推計値ではなく実測値（おそらく） 17
18. まとめ • HeatWave エンジン使用時のレプリケーション更新処理 のオーバーヘッドは気にするほど大きくなさそう ◦ 変更バッファが溢れるほどの大容量の更新や、更新対象データの 参照を更新直後に頻繁に繰り返さない限り • HeatWave エンジン使用の有無に関係なくレプリケー ションラグ自体の存在には気を付けたほうが良さそう ◦ いまどきはストレージ分離方式の DB が多く意識外になりがち 18
19. 今後 • performance_schema の rpd_tables テーブルを活用し て、HeatWave エンジンのデータが追従できていないと きに HeatWave にクエリが流れないようにしたい ◦ 以下の状態のときはエラーを返すか Aurora の Reader に流す ▪ POOL_TYPE の値に TRANSACTIONAL を含まない行がある ▪ LOAD_STATUS の値に AVAIL_RPDGSTABSTATE 以外の行がある 19