HeatWave on AWS の PrivateLink インバウンドレプリケーションで Aurora フェイルオーバーに追従する HeatWavejp Meetup #10 2024/10/17 まつひさ（hmatsu47）

自己紹介 松久裕保（@hmatsu47） ● https://qiita.com/hmatsu47 ● 現在： ○ 名古屋で Web インフラのお守り係をしています ○ SRE チームに所属しつつ技術検証の支援をしています ○ HeatWave は諸事情で検証を一旦中止→最近復活しました ○ 昨年 10 月（#04）以来の発表参加です 2

余談ですが ● Oracle Cloud ホーム画面 3

余談ですが ● サービスに移動後 🤔 4

本日お話しする内容 ● HeatWave on AWS のインバウンドレプリケーション ○ ソース DB が Aurora → binlog を流せるのは Writer のみ ■ Writer フェイルオーバーで新 Writer に接続し直す必要あり ○ PrivateLink 経由→ NLB ターゲットが IP アドレスベース ■ DNS でのフェイルオーバー追従ができない ○ Aurora クラスターのイベントを捕捉してフェイルオーバー追従 →実際に試してみた ● https://zenn.dev/hmatsu47/articles/heatwave-on-aws-privatelink 5

図にすると 6

設定の流れ…の前に ● ここでフェイルオーバーのデモ①：仕込み ○ Aurora 側のデータを確認 ○ HeatWave 側のデータを確認 ○ Aurora クラスターをフェイルオーバー ○ インバウンドレプリケーションの異常が検知されたことを確認 ○ Aurora 側でデータを追加 7

設定の流れ ● ターゲットグループの属性を微調整 ○ 旧ターゲット登録解除→新ターゲット登録が正常動作するように ● Aurora クラスターに Reader を追加 ● ターゲット入れ替え用の Lambda 関数を作成 ● SNS トピックとサブスクリプションを作成 ● Aurora（RDS）のイベントサブスクリプションを作成 ○ クラスター failover イベント 8

ターゲットグループの属性を微調整 ● ターゲットが入れ替わってもフェイルオープンは維持 ○ ターゲットが 1 つの場合はデフォルト動作だが念のため設定 ● ターゲットが入れ替わったときにできるだけ速く再接続 ○ ターゲット登録解除で即接続終了（Draining なし） ● クロスゾーン負荷分散を有効化 ○ Aurora クラスターのインスタンスを複数 AZ で冗長化している ケースではこの設定が必要 9

Aurora クラスターに Reader を追加 ● Writer 1 インスタンスのみの場合 ○ フェイルオーバー先の Reader インスタンスを追加しておく ○ 通常は 1 インスタンス目の Writer とは別 AZ に（AZ 冗長化） 10

ターゲット入れ替え用の Lambda 関数を作成 ● SNS のメッセージ内容を見てターゲットを入れ替える ○ メッセージから切り替え後のインスタンス名を抽出 ○ 現ターゲットと異なる場合、現ターゲットを外して切り替え後の インスタンスを新たに登録する Python コードを実装 https://zenn.dev/hmatsu47/articles/heatwave-on-aws-privatelink-failover#%E3%82 %BF%E3%83%BC%E3%82%B2%E3%83%83%E3%83%88%E5%85%A5%E3% 82%8C%E6%9B%BF%E3%81%88%E7%94%A8%E3%81%AE-lambda-%E9%96 %A2%E6%95%B0%E3%82%92%E4%BD%9C%E6%88%90 11

SNS トピックとサブスクリプションを作成 ● Aurora のイベントを Lambda に受け渡すためのもの ○ SNS トピックとサブスクリプションを作成 ○ サブスクリプションフィルターで failover 開始イベントのみを通 知 12

Aurora のイベントサブスクリプションを作成 ● Aurora で発生したイベントを捕捉するためのもの ○ ターゲット：先ほどの SNS トピックを指定 ○ ソース：Aurora クラスターの failover イベントを指定 13

ところで ● NLB ターゲットグループのヘルスチェックは？ ○ MySQL プロトコルを喋れない ○ ヘルスチェックが「異常なリクエスト」と見なされないように TCP:40000 など MySQL に無関係なポート番号で上書き ■ あえてヘルスチェックが効かないように設定（フェイルオープン狙い） ○ 複数のターゲットを同時に登録すると誤動作リスクあり 14

ひととおり説明が終わったところで ● フェイルオーバーのデモ②：結果確認 ○ Aurora クラスターの Writer インスタンスを確認 ○ インバウンドレプリケーションが復旧したことを確認 ○ HeatWave 側のデータを確認 15

まとめ ● on AWS の PrivateLink インバウンドレプリケーション ○ そのままではソース DB のフェイルオーバーに追従できない ○ Aurora の場合はフェイルオーバーイベントを捕捉して Lambda を実行して PrivateLink 内部 NLB のターゲット切り替えが可能 ● 切り替え後の再接続タイムラグに注意が必要 ○ フェイルオーバー開始を捕捉する場合、概ね 4 分程度 ■ 同・完了を捕捉する場合、概ね 5 分程度 16

おまけ：PrivateLink 料金 ● HeatWave on AWS 東京の PrivateLink 料金は割安？ ○ AWS のインターフェイスエンドポイント料金： USD 0.014/h + USD 0.01/GB（～ 1 PB） ○ 同・NLB： USD 0.0243/h + USD 0.006/h（/NLCU） 17 3.317 円 1.643 円 出典：https://www.oracle.com/jp/mysql/pricing/#heatwave-on-aws