HeatWavejp_Meetup_07_【LT4】_DWHとしてのHeatwave利用にあたっての考慮事項（機能、非機能）

DWHとしてのHeatwave利用にあ たっての考慮事項（機能、非機能） HeatWavejp Meetup #07 @gho4d76g

自己紹介 本名: 山田 脩 所属: 株式会社アイル (https://www.ill.co.jp/) 主業務: 当社クラウド事業（CROSSシリ ーズ）のインフラ基盤の企画・構 築・運用管理を通貫して担当。オ ンプレミス・AWSのハイブリッド 出典: https://www.ill.co.jp/business/ より抜粋

今日お話しすること・しないこと ● AWS上に構築された既存のワークロードからMySQL Heatwave Serviceを利用する上での検討事項 ○ Heatwave on OCI vs Heatwave on AWS ● MySQL Heatwave Serviceの運用にあたっての考慮事項 ○ 高可用性構成を考える ● 商用環境データのマイグレーション方式 ● HeatWave AutoML、HeatWave Lakehouse

Chapter.1 AWS上に構築したワークロード Should we choose "MySQL Heatwave Service on AWS" or “MySQL AWS上に構築済みのワークロ ードから、MySQL Heatwave Serviceを利用するための検討 事項 からMySQL Heatwave Service HeatWave Service”? を利用するための検討事項

構成の選択肢 サービス アクセス経路 実装方法 備考 MySQL HeatWave Service (on OCI) Public Access (OCI) Network Load Balancer (+ NSG + SL) 引用[1] Virtual Private Network Access Site-to-Site VPN (+ NSG + SL) 引用[2] Private Access (AWS)TransitGatewayMegaport-(OCI) FastConnect 引用[3] Public Access(Inner AWS Global Network) MySQL Enterprise Firewall Private Access AWS PrivateLink HeatWave on AWS ※ 2024年3月末時点で、Heatwave On AWSではAWS PrivateLinkは非サポート -

構成の選択肢 サービス機能 MySQL HeatWave Service MySQL HeatWave Service on AWS ベース MySQL Enterprise Edition MySQL Enterprise Edition MDSノードシェイプ ECPU(8タイプ), OCPU（3タイ プ） AWSに最適化4タイプのシェイプ HeatWaveノードシェイプ（RAM） ECPU/OCPU(32GB, 512GB) 16GB, 256GB PITR(Point-In-Time Recovery)の サポート あり - 高可用性構成のサポート あり - 読み取りレプリカのサポート あり - クエリエディタコンソール - あり Heatwave AutoMLコンソール - あり 備考 ※注2 ※ 注: 読み取りレプリカはECPUの場合MySQL.8以上、OCUPの場合MySQL.VM.Standard.E3.4.64GB以上を選択する必要があります。

考慮事項 ● クラウド間通信におけるデータ・グラビティ（AWS⇒OCI） ○ 通信のレイテンシ（RTT, BandWidth） ■ OCIの可用性ゾーン内通信の水準が必要か否かを検討 ○ 通信のコスト ■ 主に、AWSからのアウトバウンド通信に対するコスト ● 特にOCIへのデータ・ロードに係る通信（方式・コスト）を検討 ○ （自サービスの）セキュリティ・ポリシー ■ セキュリティホワイトペーパー等で情報資産（DB）の所在に関して謳 っている場合は改訂のための働きかけも必要

通信のレイテンシ: ● 一般論として ○ MySQL Client-Server間はTCPで通信 ○ 距離が遠い = Round Trip Time（RTT）に反映 表: RTT測定値（単位ms） RTT(min) RTT(avg) RTT(max) OCIの同一FD上のコンピュー トインスタンス ⇒ MDSノー ド 0.133 0.191 8.884 ping -c 1000 Site-to-Site VPNで接続した AWS EC2インスタンス ⇒ OCI上のMDSノード 4.284 4.65 47.625 ping -c 1000 例 ※ AWS VPC、OCI VCNはいずれも東京リージョン Note

(1)Network間の距離 出典: https://www.oracle.com/jp/news/announcement/mysql-heatwave-on-aws-2022-09-12/

通信コスト: ● AWS から OCIへのクラウド間通信コスト ○ OCI NLB経由でpublicアクセス ■ EC2がEIPを持っている場合はアウトバウンドトラフィックに対しては 課金されないが、ワークロードをNAT Gateway下に収容している場合 は注意が必要 ○ VPN/Transit Gateway経由のPrivateアクセスの場合 ■ 通信量に応じて従量課金が発生 ○ データ・ロードをオブジェクトストレージ経由にするなどの工 夫が必要 ■ 分析対象のデータ鮮度とのトレードオフで判断

まとめ MySQL HeatWave Service on AWS を選択する判断基準 ❏ リアルタイム性の要求される大容量のデータロードまたは、更新量 の多いデータソース(Amazon Aurora等)からのレプリケーションが 必要か？ ❏ YESの場合: ❏ データ転送コストとDBシステムのコストを加味したTCOを 精査し、コストメリットがあれば「MySQL HeatWave Service on AWS」を選択 ❏ 当社のワークロードでは「No」と判断

Chapter.2 MySQL Heatwave Service の運用に関する考慮事項 1. “High Availability” and AWS上に構築したワークロード “Scalability” 2. “Controllability” からMySQL Heatwave Service 3. Just Idea... を利用するための検討事項

(1) MySQL Heatwave Serviceの運用管理機能 ● High-Availability ○ 高可用性構成 ■ MySQL InooDB Cluster (Group Replication) を基盤としたマネ ージドクラスタ管理機能を提供 ● Scalability ○ 読み取り用レプリカ ■ 非同期レプリケーションを基盤としたスケーラブルなリードレプリ カノード管理機能を提供

High-Availability MySQL HeatWave Serviceの高可用性構成 ● MDSノードは3台構成 ○ ランニングコストはスタンド アローンの2.5倍 ● R/Wエンドポイント以外は隠ぺい ● マルチマスター構成は制限 ○ group_replication_single_pri mary_mode=ON ● Heatwaveクラスターは共有

Scalability MySQL HeatWave Serviceの高可用性構成 ● MDSノード+ストレージ分のコスト ● 最大18ノードまで作成可 ● 読み取りエンドポイントとして、LB の代表エンドポイントとノード毎の エンドポイントの両方が利用可 ● 別リージョンへの配置は不可 ● レプリカノードの昇格は不可

(2) メンテナンス・コントローラビリティ ● メンテナンスのないシステムは存在しない ○ マネージドなOSレイヤのセキュリティパッチ ■ システムアップグレードのコントロール ○ データベースエンジンのライフサイクル追従 ■ マイナー/メジャーバージョンアップのコントール ○ HeatWaveを利用する場合、構成要素が増える ■ HeatWaveノードのメンテナンスについても考慮が必要？ まだメンテナンス予定を受けたこ とがないので、知見のある方にご 教示いただきたく

メンテナンス時の振る舞い スタンドアローン 接続を閉じてメンテナンス実行（この間サ ービスダウンタイム） 高可用性構成 1. 2. 3. 読み取りリードレ プリカなし 4. 読み取りリードレ プリカあり レプリケーションソースのMDSノードと 同時にすべてのリードレプリカのメンテナ ンスを実行（この間サービスダウンタイ ム） 1. 2. セカンダリDBの1台をGroup Replixation(GR)から除去しメンテナ ンス実行しGRに戻す セカンダリDBの2台目も同様 プライマリノードの接続を閉じてて から、セカンダリノードを昇格（こ の間サービス断） 旧プライマリDBをメンテナンスして からGRに戻す / 引用[4]。 読み取りレプリカを1つずつアップグ レード（2ノード以上でダウンタイム なし） 以降、上の手順でMDSノードのメン テナンスを順次実行 /引用[5]

Self Serviceでメンテナンスに備える ● OCIではレプリケーションチャネル管理をマネージドサービスとし て提供しており、セルフサービスでActive-Standby構成を組む・と いう選択肢もありうる。 ○ データベースエンジンのメジャーバージョンアップのようなリスクの高いマ イグレーションでの一時的利用 ○ ある程度のダウンタイムが許容できるシステムであれば常時稼働も検討 ■ ただし、MDSノード障害時手動オペレーション（F/O, HeatWaveクラ スターの有効化）の計画が必要。

Self Serviceでメンテナンスに備える ● あらかじめMDSノード前段にネット ワークロードバランサを配置する必 要 ○ エンドポイント固定 ● スタンバイDBシステムを配置しレプ リケーションを構成 ● スタンバイDBシステム側で HeatWaveクラスタを常時稼働させ るかはコストとRTOの観点で判断。 ● 必要時に、サービス閉塞の上、スタ ンバイDBシステムを昇格 →LoadBalancer側で経路を切り替え

DWHの特性を踏まえた構成のアイデア（失敗） ● 次のような特性を備えたDWHとして運用する場合を考える ○ Write: ■ 書き込みタイミングをシステムによってコントロールが可能 ■ 限られた書き込みクライアント ○ Read: ■ （サービスのユーザ―によって）アドホックに問い合わせ ● コントロールは難しい ■ クライアント数はサービストラフィック量に依存 ■ DWHにかかるワークロードはReadが支配的

DWHの特性を踏まえた構成のアイデア （失敗） MySQL HeatWave Serviceの高可用性構成 ● 読み取りワークロードの負荷が支配 的である場合、MDSノードの垂直ス ケーリングを行うよりも、Replica ノードの水平スケーリングを行う方 がコスト効率に優れるシナリオもあ り得る？ ● MDSノードの読み取りレプリカから、 Heatwave Clusterを参照できるの か要検証。

DWHの特性を踏まえた構成のアイデア （失敗） MySQL HeatWave Serviceの高可用性構成 ● 読み取り専用ノードのシステム状態を 確認すると、RAPIDデータベースエン ジンに関する項目がないことが判明！ ● 読み取りレプリカノードへのクエリも 自動的にHeatWaveにオフロードされ るものと勘違いしていたが、実際は異 なることが分かった。

引用 1. Connecting to a MySQL HeatWave Database Instance Using an OCI Network Load Balancer 2. VPN Connection to AWS 3. Enable multicloud high availability and data protection across OCI and AWS with Megaport 4. Read replicas on MySQL Database Service 5. Maintenance of a High Availability DB System

• https://blogs.oracle.com/mysql/post/connecting-to-a-mysql-heatwave-database-instance-using-an-oci-network-load-balancer
• https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/vpn_to_aws.htm
• https://docs.oracle.com/en/solutions/multicloud-failover-oci-aws/index.html#GUID-A7E1BFB0-4489-4DD5-8D6F-B4DE38F88BE2
• https://blogs.oracle.com/mysql/post/read-replicas-mysql-database-service
• https://docs.oracle.com/en-us/iaas/mysql-database/doc/maintenance-high-availability-db-system.html#GUID-1BFF565C-B041-4F32-99C8-03C05F2ED93B