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
8
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
ゲームで体感!Aurora DSQL の OCC(楽観的同時実行制御)
hmatsu47
PRO
0
9
PostgreSQL+pgvector で GraphRAG に挑戦 & pgvectorscale 0.7.x アップデート
hmatsu47
PRO
0
17
LlamaIndex の Property Graph Index を PostgreSQL 上に構築してデータ構造を見てみる
hmatsu47
PRO
0
14
PostgreSQL+pgvector で LlamaIndex の Property Graph Index を試す(序章)
hmatsu47
PRO
0
12
HeatWave on AWS のインバウンドレプリケーションで HeatWave エンジン有効時のレプリケーションラグを確認してみた!
hmatsu47
PRO
0
17
CloudWatch Database Insights 関連アップデート
hmatsu47
PRO
0
34
さいきんの MySQL との付き合い方 〜 MySQL 8.0 より後の世界へようこそ 〜
hmatsu47
PRO
0
31
ベクトルストア入門
hmatsu47
PRO
0
25
Aurora DSQL について
hmatsu47
PRO
0
33
Other Decks in Technology
See All in Technology
無理しない AI 活用サービス / #jazug
koudaiii
0
100
Copilot coding agentにベットしたいCTOが開発組織で取り組んだこと / GitHub Copilot coding agent in Team
tnir
0
200
AIエージェントが書くのなら直接CloudFormationを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ
watany
18
7.6k
ゼロから始めるSREの事業貢献 - 生成AI時代のSRE成長戦略と実践 / Starting SRE from Day One
shinyorke
PRO
0
120
AI Ready API ─ AI時代に求められるAPI設計とは?/ AI-Ready API - Designing MCP and APIs in the AI Era
yokawasa
9
2.7k
AWS 怖い話 WAF編 @fillz_noh #AWSStartup #AWSStartup_Kansai
fillznoh
0
130
ABEMAの本番環境負荷試験への挑戦
mk2taiga
5
1.3k
20250718_ITSurf_“Bet AI”を支える文化とコストマネジメント
helosshi
0
100
推し書籍📚 / Books and a QA Engineer
ak1210
0
140
Delegating the chores of authenticating users to Keycloak
ahus1
0
190
モニタリング統一への道のり - 分散モニタリングツール統合のためのオブザーバビリティプロジェクト
niftycorp
PRO
1
520
ClaudeCodeにキレない技術
gtnao
1
870
Featured
See All Featured
Building Adaptive Systems
keathley
43
2.7k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.5k
Rails Girls Zürich Keynote
gr2m
95
14k
A designer walks into a library…
pauljervisheath
207
24k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Git: the NoSQL Database
bkeepers
PRO
430
65k
4 Signs Your Business is Dying
shpigford
184
22k
Being A Developer After 40
akosma
90
590k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
54k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
750
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