HeatWave on AWS という選択肢を検討してみる
623 Views
May 09, 25
スライド概要
JAWS-UG 名古屋 5 月会①「データ利活用研究会」2025/5/9 LT
AI による要約：
本スライドでは、HeatWave on AWS の利用について検討しています。HeatWave は Oracle Cloud の MySQL マネージドサービスであり、AWS 上のリソースを利用する選択肢もあります。HeatWave の特徴や使用可能な機能、実際のパフォーマンステストの結果について詳細を述べています。分析・集計の用途による適用可能性や、注意点、課題についても触れ、代替の選択肢となる可能性を考察しています。
Qiita や Zenn でいろいろ書いてます。 https://qiita.com/hmatsu47 https://zenn.dev/hmatsu47 MySQL 8.0 の薄い本 : https://github.com/hmatsu47/mysql80_no_usui_hon Aurora MySQL v1 → v3 移行計画 : https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book https://speakerdeck.com/hmatsu47
関連スライド
各ページのテキスト
HeatWave on AWS という選択肢を検討してみる JAWS-UG 名古屋 5 月会①「データ利活用研究会」 2025/5/9 まつひさ（hmatsu47）
自己紹介 松久裕保（@hmatsu47） ● https://qiita.com/hmatsu47 ● 現在： ○ 名古屋で Web インフラのお守り係をしています ○ SRE チームに所属しつつ技術検証の支援をしています ○ 今日話す HeatWave on AWS は細々と検証中です ○ DB 分野はよくネタにしていますがデータ分野は専門外です 2
本日のテーマ ● HeatWave on AWS というマイナーな選択肢を検討する ○ Oracle Cloud が AWS 上のリソースを使って提供するサービス ■ 主に AWS 上のコンピュートリソースから接続して使うことを想定 ○ 世間一般にはほぼ認知されていない ■ 実は昨年末の「RDS/Aurora アップデート（2024 年版）」で少し触れた 3
HeatWave とは？ 4
HeatWave とは？ ● Oracle Cloud の MySQL マネージドサービス ○ いくつかの機能がひとまとめになっている（のでわかりづらい） https://www.oracle.com/jp/heatwave/features/ ■ HeatWave（HeatWave Cluster / 列指向インメモリデータ処理エンジン） ■ HeatWave GenAI（組み込み LLM・ベクトルストア・チャット） ■ HeatWave MySQL（マネージドな MySQL Database） ■ HeatWave Lakehouse（レイクハウス分析） ■ HeatWave AutoML（機械学習モデルの構築・トレーニング） 5
HeatWave とは？ ● Oracle Cloud の MySQL マネージドサービス ○ いくつかの機能がひとまとめになっている（のでわかりづらい） 今日のメインはここ https://www.oracle.com/jp/heatwave/features/ ■ HeatWave（HeatWave Cluster / 列指向インメモリデータ処理エンジン） ■ HeatWave GenAI（組み込み LLM・ベクトルストア・チャット） ■ HeatWave MySQL（マネージドな MySQL Database） ■ HeatWave Lakehouse（レイクハウス分析） ■ HeatWave AutoML（機械学習モデルの構築・トレーニング） 6
2 つの HeatWave ● HeatWave on OCI と HeatWave on AWS がある ○ Oracle Cloud Infrastructure 上にあるのが on OCI ○ AWS 上のリソースを使ってサービス提供するのが on AWS ○ on OCI のほうが安くて機能が充実 →今回は on AWS の話 https://www.oracle.com/jp/heatwave/pricing/ 7
HeatWave エンジン（HeatWave Cluster） ● メモリ上に全データを列指向フォーマットで配置 ○ MySQL Database からデータをリアルタイムで転送 ■ 非同期での転送だがほぼリアルタイム ■ zero-ETL より転送のタイムラグが小さい ■ テーブル単位で転送対象を指定可能・列フィルタも使用可能（BLOB 列など を除外できる） ○ 分析・集計が得意（超高速） ■ 列指向なのに更新系がほとんど遅くならないのが特徴 8
使い道は？ 9
何に使える？ ● アドホックな分析…△ ○ HeatWave は常時起動が前提 ■ 分析の頻度が低いとコストパフォーマンスが悪い ■ 起動の都度メモリへのデータロード時間が必要→効率が悪い ● 内部管理用の分析・集計機能…◯ ○ 普通の MySQL と同じ使い方ができる ■ アプリケーションへの実装が容易 ■ ただし使用者が限られるので、使用頻度が低いと↑と同じ結論に 10
何に使える？ ● ユーザーが使うアプリケーションの分析・集計機能…◯ ○ （基本的には）メインの DB を HeatWave に置き換えるだけ ■ 前述のとおり普通の MySQL と同じ使い方ができる ■ 但し HeatWave on AWS では現状制約が多いので置き換えは厳しいかも （置き換えが難しい場合はメインの DB のレプリカとして使う） ○ 分析・集計以外では詳細検索（結果一覧取得）などにも利用可能 ■ 検索条件が複雑化して結合対象のテーブルが増える→クエリが遅くなるので その対策として使う 11
何に使える？ 今回はこれを想定して検討することに ● ユーザーが使うアプリケーションの分析・集計機能…◯ ○ （基本的には）メインの DB を HeatWave に置き換えるだけ ■ 前述のとおり普通の MySQL と同じ使い方ができる ■ 但し HeatWave on AWS では現状制約が多いので置き換えは厳しいかも （置き換えが難しい場合はメインの DB のレプリカとして使う） ○ 分析・集計以外では詳細検索（結果一覧取得）などにも利用可能 ■ 検索条件が複雑化して結合対象のテーブルが増える→クエリが遅くなるので その対策として使う 12
データ容量は？ ● アプリケーションから使う前提でコスト比較 ○ 既存の DB の 1 インスタンス分を基準に考えると（月額）、 ■ Aurora db.r6g.2xlarge が 1 ドル 140 〜 150 円換算で約 13 〜 14 万円 ■ 同 db.r6g.4xlarge が約 26 〜 28 万円 ○ HeatWave での置き換えを考えると、 ■ 4vCPU/Mem32GiB/Cluster256GiB が円建て契約で月額約 12 〜 13 万円 ■ データ容量に比例して Cluster の容量を上げる必要があるが、MySQL の DB 容量に対して HeatWave Cluster では圧縮が効くので半分程度に削減される →元データの容量が 512GiB 〜 1TiB 程度までなら検討の価値あり？ 13
自社での検証 14
検証の実施 ● 既存の Web アプリケーションから HeatWave エンジンに 分析・集計クエリを流して高速化できるか？ ○ メインの DB は既存の Aurora をそのまま使う ■ Aurora → HeatWave でレプリケーションして使う ■ HeatWave on AWS の HA 構成の制約上、現時点での置き換えは非現実的 ※ HeatWave を複数用意し Aurora からレプリケーションして冗長化 する想定 15
検証時の構成（DB 部分のみ・片系） ※逆向きの PrivateLink（Query 用）で クライアント（Web サーバー）から接続 16
実際に使われている分析・集計クエリを流してみた ● 検証環境 ○ ソース : Aurora MySQL 3.04.1/db.r6g.4xlarge ■ 16vCPU/Mem128GiB（1 ドル 140 〜 150 円換算で月額約 26 〜 28 万円） ○ レプリカ : HeatWave MySQL 8.4.3 ■ 4vCPU/Mem32GiB/Cluster256GiB（円建て契約で月額約 12 〜 13 万円） ○ 元のデータ容量：約 160GiB ■ インデックス込み ■ HeatWave エンジンにロード後の容量：約 60GiB（圧縮による） ■ 中心となるテーブル：圧縮後約 40GiB・2 億行 17
結果（一部抜粋・小数点以下第三位四捨五入） 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 18
結果（一部抜粋・小数点以下第三位四捨五入） 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 倍 クエリ クエリ① クエリ② クエリ③ クエリ④ スキャン対象の データが大きく バッファプール （約96GiB）に 載りきらない a/b 19
結果（一部抜粋・小数点以下第三位四捨五入） 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 倍 クエリ クエリ① クエリ③ r6g.8xlargeに スケールアップ すれば載りきる が価格が倍に クエリ④ （HeatWaveの約4倍） クエリ② a/b 20
評価 ● 十分に高速化する ○ 大きなサイズの Aurora のレプリカを配置するより効果的 ● 構成は複雑化する ○ 内部 NLB を使う旧タイプの PrivateLink が双方向で必要 ○ Aurora → HeatWave のレプリケーションラグも発生する ■ DDL 実行時 MySQL Database → HeatWave エンジンデータ再ロード発生も ■ DML 実行時の考察は↓ https://www.docswell.com/s/hmatsu47/KXENLN-inbound-replication-lag 21
その他の課題 ● 冗長構成を取るには作り込みが必要 ○ Aurora フェイルオーバー対応は自前実装が必要 ○ 複数の HeatWave を使うには複数のレプリケーション接続が必要 ● API / SDK で操作ができない ○ on OCI では公開されている API が on AWS では使えない ● 並行処理（9.0 でサポート）のオーバーヘッドが大きい ○ しかも 9.0 以降では並行処理を無効化できない 22
まとめと参考記事 23
まとめ ● 用途によって向き不向きがある ○ 低頻度の分析には別の基盤（あるいは DuckDB?）を使うほうが良い ● 「Aurora のレプリカ代わりの HeatWave on AWS」は、 十分検討対象になる ○ 大きなレプリカを追加するより高速化＆コストメリットが高い ● 課題や注意点はいくつかある ○ 冗長構成の作り込みが必要、レプリケーションラグなど 24
参考記事 ● 東京リージョンにやってきた MySQL HeatWave on AWS を試す (1) 初期設定編（ほか一連の記事） ○ https://qiita.com/hmatsu47/items/8f202eef64ea57e7d948 ● HeatWave on AWS で PrivateLink 接続を使ってインバウンドレプリ ケーションを試す（ほか一連の記事） ○ https://zenn.dev/hmatsu47/articles/heatwave-on-aws-privatelink ● HeatWave MySQL が 9.0 で Auto Scheduling を実装したことでク エリの実行時間がかえって延びた件 ○ https://qiita.com/hmatsu47/items/302e6442e783c9446497 25