HeatWave on AWS という選択肢を検討してみる

JAWS-UG 名古屋 5 月会①「データ利活用研究会」2025/5/9 LT

Transcript

1. HeatWave on AWS という選択肢を検討してみる JAWS-UG 名古屋 5 月会①「データ利活用研究会」 2025/5/9 まつひさ（hmatsu47）
2. 自己紹介 松久裕保（@hmatsu47） • https://qiita.com/hmatsu47 • 現在： ◦ 名古屋で Web インフラのお守り係をしています ◦ SRE チームに所属しつつ技術検証の支援をしています ◦ 今日話す HeatWave on AWS は細々と検証中です ◦ DB 分野はよくネタにしていますがデータ分野は専門外です 2
3. 本日のテーマ • HeatWave on AWS というマイナーな選択肢を検討する ◦ Oracle Cloud が AWS 上のリソースを使って提供するサービス ▪ 主に AWS 上のコンピュートリソースから接続して使うことを想定 ◦ 世間一般にはほぼ認知されていない ▪ 実は昨年末の「RDS/Aurora アップデート（2024 年版）」で少し触れた 3
4. HeatWave とは？ 4
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（機械学習モデルの構築・トレーニング） 5
6. 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 今日のメインはここ
7. 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
8. HeatWave エンジン（HeatWave Cluster） • メモリ上に全データを列指向フォーマットで配置 ◦ MySQL Database からデータをリアルタイムで転送 ▪ 非同期での転送だがほぼリアルタイム ▪ zero-ETL より転送のタイムラグが小さい ▪ テーブル単位で転送対象を指定可能・列フィルタも使用可能（BLOB 列など を除外できる） ◦ 分析・集計が得意（超高速） ▪ 列指向なのに更新系がほとんど遅くならないのが特徴 8
9. 使い道は？ 9
10. 何に使える？ • アドホックな分析…△ ◦ HeatWave は常時起動が前提 ▪ 分析の頻度が低いとコストパフォーマンスが悪い ▪ 起動の都度メモリへのデータロード時間が必要→効率が悪い • 内部管理用の分析・集計機能…◯ ◦ 普通の MySQL と同じ使い方ができる ▪ アプリケーションへの実装が容易 ▪ ただし使用者が限られるので、使用頻度が低いと↑と同じ結論に 10
11. 何に使える？ • ユーザーが使うアプリケーションの分析・集計機能…◯ ◦ （基本的には）メインの DB を HeatWave に置き換えるだけ ▪ 前述のとおり普通の MySQL と同じ使い方ができる ▪ 但し HeatWave on AWS では現状制約が多いので置き換えは厳しいかも （置き換えが難しい場合はメインの DB のレプリカとして使う） ◦ 分析・集計以外では詳細検索（結果一覧取得）などにも利用可能 ▪ 検索条件が複雑化して結合対象のテーブルが増える→クエリが遅くなるので その対策として使う 11
12. 何に使える？ • ユーザーが使うアプリケーションの分析・集計機能…◯ ◦ （基本的には）メインの DB を HeatWave に置き換えるだけ ▪ 前述のとおり普通の MySQL と同じ使い方ができる ▪ 但し HeatWave on AWS では現状制約が多いので置き換えは厳しいかも （置き換えが難しい場合はメインの DB のレプリカとして使う） ◦ 分析・集計以外では詳細検索（結果一覧取得）などにも利用可能 ▪ 検索条件が複雑化して結合対象のテーブルが増える→クエリが遅くなるので その対策として使う 12 今回はこれを想定して検討することに
13. データ容量は？ • アプリケーションから使う前提でコスト比較 ◦ 既存の 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. 自社での検証 14
15. 検証の実施 • 既存の Web アプリケーションから HeatWave エンジンに 分析・集計クエリを流して高速化できるか？ ◦ メインの DB は既存の Aurora をそのまま使う ▪ Aurora → HeatWave でレプリケーションして使う ▪ HeatWave on AWS の HA 構成の制約上、現時点での置き換えは非現実的 ※ HeatWave を複数用意し Aurora からレプリケーションして冗長化 する想定 15
16. 検証時の構成（DB 部分のみ・片系） 16 ※逆向きの PrivateLink（Query 用）で クライアント（Web サーバー）から接続
17. 実際に使われている分析・集計クエリを流してみた • 検証環境 ◦ ソース : 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
18. 結果（一部抜粋・小数点以下第三位四捨五入） 18 クエリ 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 倍
19. 結果（一部抜粋・小数点以下第三位四捨五入） 19 クエリ 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 倍 スキャン対象の データが大きく バッファプール （約96GiB）に 載りきらない
20. 結果（一部抜粋・小数点以下第三位四捨五入） 20 クエリ 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 倍 r6g.8xlargeに スケールアップ すれば載りきる が価格が倍に （HeatWaveの約4倍）
21. 評価 • 十分に高速化する ◦ 大きなサイズの Aurora のレプリカを配置するより効果的 • 構成は複雑化する ◦ 内部 NLB を使う旧タイプの PrivateLink が双方向で必要 ◦ Aurora → HeatWave のレプリケーションラグも発生する ▪ DDL 実行時 MySQL Database → HeatWave エンジンデータ再ロード発生も ▪ DML 実行時の考察は↓ https://www.docswell.com/s/hmatsu47/KXENLN-inbound-replication-lag 21
22. その他の課題 • 冗長構成を取るには作り込みが必要 ◦ Aurora フェイルオーバー対応は自前実装が必要 ◦ 複数の HeatWave を使うには複数のレプリケーション接続が必要 • API / SDK で操作ができない ◦ on OCI では公開されている API が on AWS では使えない • 並行処理（9.0 でサポート）のオーバーヘッドが大きい ◦ しかも 9.0 以降では並行処理を無効化できない 22
23. まとめと参考記事 23
24. まとめ • 用途によって向き不向きがある ◦ 低頻度の分析には別の基盤（あるいは DuckDB?）を使うほうが良い • 「Aurora のレプリカ代わりの HeatWave on AWS」は、 十分検討対象になる ◦ 大きなレプリカを追加するより高速化＆コストメリットが高い • 課題や注意点はいくつかある ◦ 冗長構成の作り込みが必要、レプリケーションラグなど 24
25. 参考記事 • 東京リージョンにやってきた 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