Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
HeatWave on AWS という選択肢を検討してみる
Search
hmatsu47
PRO
May 09, 2025
Technology
0
6
HeatWave on AWS という選択肢を検討してみる
JAWS-UG 名古屋 5 月会①「データ利活用研究会」2025/5/9 LT
hmatsu47
PRO
May 09, 2025
Tweet
Share
More Decks by hmatsu47
See All by hmatsu47
PostgreSQL+pgvector で GraphRAG に挑戦 & pgvectorscale 0.7.x アップデート
hmatsu47
PRO
0
5
LlamaIndex の Property Graph Index を PostgreSQL 上に構築してデータ構造を見てみる
hmatsu47
PRO
0
7
PostgreSQL+pgvector で LlamaIndex の Property Graph Index を試す(序章)
hmatsu47
PRO
0
11
HeatWave on AWS のインバウンドレプリケーションで HeatWave エンジン有効時のレプリケーションラグを確認してみた!
hmatsu47
PRO
0
15
CloudWatch Database Insights 関連アップデート
hmatsu47
PRO
0
26
さいきんの MySQL との付き合い方 〜 MySQL 8.0 より後の世界へようこそ 〜
hmatsu47
PRO
0
29
ベクトルストア入門
hmatsu47
PRO
0
25
Aurora DSQL について
hmatsu47
PRO
0
27
DynamoDB Global Tables MRSC・pgvector 0.8.0・caching_sha2_password 関連アップデート
hmatsu47
PRO
0
27
Other Decks in Technology
See All in Technology
2年でここまで成長!AWSで育てたAI Slack botの軌跡
iwamot
PRO
2
360
登壇ネタの見つけ方 / How to find talk topics
pinkumohikan
3
300
PostgreSQL 18 cancel request key長の変更とRailsへの関連
yahonda
0
110
原則から考える保守しやすいComposable関数設計
moriatsushi
3
500
IIWレポートからみるID業界で話題のMCP
fujie
0
740
PHPでWebブラウザのレンダリングエンジンを実装する
dip_tech
PRO
0
170
Definition of Done
kawaguti
PRO
6
460
Prox Industries株式会社 会社紹介資料
proxindustries
0
210
ひとり情シスなCTOがLLMと始めるオペレーション最適化 / CTO's LLM-Powered Ops
yamitzky
0
380
変化する開発、進化する体系時代に適応するソフトウェアエンジニアの知識と考え方(JaSST'25 Kansai)
mizunori
0
140
25分で解説する「最小権限の原則」を実現するための AWS「ポリシー」大全
opelab
9
2.2k
監視のこれまでとこれから/sakura monitoring seminar 2025
fujiwara3
10
2.9k
Featured
See All Featured
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
The Straight Up "How To Draw Better" Workshop
denniskardys
233
140k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Designing for humans not robots
tammielis
253
25k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
How STYLIGHT went responsive
nonsquared
100
5.6k
How to Think Like a Performance Engineer
csswizardry
24
1.7k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Rails Girls Zürich Keynote
gr2m
94
14k
The Pragmatic Product Professional
lauravandoore
35
6.7k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Transcript
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 部分のみ・片系) 16 ※逆向きの PrivateLink(Query 用)で クライアント(Web サーバー)から接続
実際に使われている分析・集計クエリを流してみた • 検証環境 ◦ ソース : 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 クエリ 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 クエリ 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 クエリ 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倍)
評価 • 十分に高速化する ◦ 大きなサイズの 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