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

HeatWave on AWS の インバウンドレプリケーションで HeatWave エンジン有効時の レプリケーションラグを確認してみた！ HeatWavejp Meetup #13（祝 2 周年）2025/4/17 まつひさ（hmatsu47）

自己紹介 松久裕保（@hmatsu47） ● https://qiita.com/hmatsu47 ● 現在： ○ 名古屋で Web インフラのお守り係をしています ○ SRE チームに所属しつつ技術検証の支援をしています ○ HeatWave は細々と検証中です ○ 昨年 10 月（#10）以来の発表参加です 2

• https://qiita.com/hmatsu47

最近の活動 ● 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

• https://www.docswell.com/s/hmatsu47/ZP2LY6-2025-01-19-235645
• https://www.docswell.com/s/hmatsu47/Z3GL92-2025-02-07-144215

前回（#10）の発表 ● HeatWave on AWS の PrivateLink インバウンドレプリ ケーション構成 ○ ソース DB（Aurora）のフェイルオーバーに追従できるように、 フェイルオーバーイベントを捕捉し Lambda を起動・実行して PrivateLink 内部 NLB のターゲット切り替えを行う ■ フェイルオーバー開始を捕捉する場合、概ね 4 分程度のタイムラグで追従 ■ フェイルオーバー完了を捕捉する場合、概ね 5 分程度のタイムラグで追従 4

構成図（前回の発表） 5

構成図（前回の発表） ※逆向きの PrivateLink（Query 用）で クライアント（Web サーバー）から接続 6

なぜこの構成を検討？ ● Web アプリケーションから HeatWave エンジンに分析・ 集計クエリを流して高速化したい ○ ただしメインの DB は 複数 Reader を Active 状態で活用可能な Aurora をそのまま使いたい ■ HeatWave on AWS の HA 構成ではセカンダリインスタンスへアクセス不可 ■ HA 構成では HeatWave エンジンは使用不可 ■ PrivateLink 接続でのインバウンドレプリケーションも不可 ※複数のインバウンドレプリケーション構成で冗長化する想定 7

実際に使われているクエリを流してみた ● 集計クエリは 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

結果は（一部抜粋・小数点以下第三位四捨五入） a.Aurora b.HeatWave (db.r6g.4xlarge 16vCPU/Mem128GiB) (4vCPU/Mem32GiB/Cluster256GiB) クエリ① 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 倍 クエリ a/b 9

ここから本題：今回の発表のために調査したこと ● 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

ここ↓のラグを調査 a.（SECONDARY_LOAD vs SECONDARY_UNLOAD） b. 11

なぜこの調査を実施したのか ● 一般的に列指向のデータフォーマットは更新に弱いため ○ 行指向フォーマットと比べると更新処理のオーバーヘッドが大き くなりがち → HeatWave エンジンではどうなのかを知りたい 12

なお、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

調査その 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

結果（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

調査その 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

結果（rpd_tables.NROWS による遅延確認） ● いずれも 0 秒 ○ 行挿入完了・Seconds_Behind_Source が 0・NROWS が挿入済み 行数に達したタイミングが（ほぼ）同じ ■ なお NROWS の値は推計値ではなく実測値（おそらく） 17

まとめ ● HeatWave エンジン使用時のレプリケーション更新処理 のオーバーヘッドは気にするほど大きくなさそう ○ 変更バッファが溢れるほどの大容量の更新や、更新対象データの 参照を更新直後に頻繁に繰り返さない限り ● HeatWave エンジン使用の有無に関係なくレプリケー ションラグ自体の存在には気を付けたほうが良さそう ○ いまどきはストレージ分離方式の DB が多く意識外になりがち 18

今後 ● performance_schema の rpd_tables テーブルを活用し て、HeatWave エンジンのデータが追従できていないと きに HeatWave にクエリが流れないようにしたい ○ 以下の状態のときはエラーを返すか Aurora の Reader に流す ■ POOL_TYPE の値に TRANSACTIONAL を含まない行がある ■ LOAD_STATUS の値に AVAIL_RPDGSTABSTATE 以外の行がある 19