RDS Data API と Aurora zero-ETL 統合と BuriKaigi2024 の話

JAWS-UG 浜松 AWS 勉強会 202401 2024/1/26

Transcript

1. RDS Data API と Aurora zero-ETL 統合と BuriKaigi2024 の話 JAWS-UG 浜松 AWS 勉強会 202401　2024/1/26 まつひさ（hmatsu47）
2. 前半のネタは（JAWS-UG 名古屋での 2023/12/18 発表資料より） • re:Invent 2023 期間の RDS / Aurora 関連アップデート ◦ ① RDS for Db2（GA） ◦ ② Aurora Limitless Database（申請制プレビュー） ◦ ③ Data API（Aurora Serverless v1）と AppSync の連携強化（GA?） ◦ ④ RDS / Aurora で Redshift との zero-ETL 統合（プレビュー） ▪ Aurora PostgreSQL（15.4） ▪ RDS for MySQL（8.0.28 〜） 2 これのその後（1.） これのデータ転送処理（2.） （ロジカルレプリケーション）
3. 1. RDS Data API と AppSync の連携強化 • https://aws.amazon.com/jp/about-aws/whats-new/2023/11/aws-appsync-aurora-clusters -rds-data-api/ ◦ RDS Data API : Aurora Serverless v1 に HTTPS アクセス ◦ AppSync : サーバーレス GraphQL & Pub / Sub API ◦ Amplify CLI（GraphQL Transformer）なしで GraphQL スキーマ作成 ▪ https://qiita.com/inada_riku/items/5f058e34bf8c0737f588 ◦ JavaScript リゾルバーで SQL を作成することが容易に ▪ https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-rds-js.html 3 発表時点（re:Invent 期間）では
4. JAWS-UG 名古屋（2023/12/18）の 3 日後に • Aurora PostgreSQL（Serverless v2・プロビジョンド）が RDS Data API に対応（2023/12/21 発表） ◦ https://aws.amazon.com/jp/about-aws/whats-new/2023/12/amazon-aurora-postgre sql-rds-data-api/ ◦ 同時にクエリエディタと Knowledge Base for Amazon Bedrock （ベクターストアとして）にも対応 ▪ https://dev.classmethod.jp/articles/aurora-serverless-v2-query-editor-connection/ ▪ https://qiita.com/hayao_k/items/45e59c1c2a183c27b20d 4
5. 2. RDS / Aurora で Redshift との zero-ETL 統合 • 複雑な ETL の設定なしにニアリアルタイムデータ連携 • Aurora PostgreSQL と RDS for MySQL が新たに追加 ◦ Aurora PostgreSQL 15.4（オハイオリージョンでのプレビュー版を使用） ◦ RDS for MySQL 8.0.28 以降（各リージョンで DB は GA 版、Redshift は プレビュー版（preview_2023 トラック）を使用 ◦ Aurora MySQL（3.05.0 〜）は 2023/11 に GA ▪ プレビュー時とは対応バージョンが異なる点に注意 5
6. Aurora MySQL の zero-ETL 統合では • enhanced binary log 設定が必須 ◦ https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/zero-etl.settin g-up.html ▪ Aurora zero-ETL integrations with Amazon Redshift require specific values for the DB cluster parameters that control replication. Specifically, Aurora MySQL requires enhanced binlog (aurora_enhanced_binlog), and Aurora PostgreSQL requires enhanced logical replication (aurora.enhanced_logical_replication). • ストレージ層で Redshift にデータを転送するために enhanced binary log を使用 6
7. Aurora MySQL enhanced binary log とは • Aurora での binlog 処理の遅さを改善する機能 ◦ https://aws.amazon.com/jp/blogs/database/introducing-amazon-aurora-mysql-enh anced-binary-log-binlog/ ▪ 2023/5/22 に発表 ◦ Aurora MySQL ではストレージ構造の制約で binlog 処理が遅い ▪ コンピュート層とストレージ層の分離・ストレージ層の 3AZ 冗長化が影響 ▪ 特にクラッシュリカバリ時の binlog 復旧が劇遅になることがあった ◦ 別のストレージ領域にデータと並行して binlog を記録 ▪ binlog バックアップはできない（制限事項） 7
8. Aurora PostgreSQL の zero-ETL 統合では • enhanced logical replication 設定が必須 ◦ 前掲リンク ▪ Enabling enhanced logical replication (aurora.enhanced_logical_replication) automatically sets the REPLICA IDENTITY parameter to FULL, which means that all column values are written to the write ahead log (WAL). This will increase the IOPS for your source DB cluster. ◦ Logical Replication : Pub / Sub 形式の論理レプリケーション ◦ WAL からの変換＆転送処理をストレージ層にオフロード ▪ Publisher（送信側）のストレージ層で WAL 変換→ Subscriber（受信側）に転送 ▪ 初期データ（テーブルのスナップショット）もストレージ層で転送 8
9. PostgreSQL のロジカルレプリケーション • 初期データはテーブルの スナップショットを転送 • 更新系トランザクション で WAL を書き出す • WAL を Publisher で変換 → Subscriber へ送信 9 出典 : https://www.fujitsu.com/jp/products/software/resources/feature-stories/postgres/article-index/logical-replication-tutorial/ （一部改変） • enhanced logical replication ではこの部分をストレージ層へ オフロード • zero-ETL 統合では Redshift が Subscriber に
10. Aurora PostgreSQL enhanced logical replication • zero-ETL 統合ではストレージ層で Redshift にデータを 転送するために使用 • 現時点で詳細不明だが設定項目から見て Aurora MySQL の enhanced binary log と類似の制限がありそう ◦ aurora.logical_replication_backup=0 ◦ aurora.logical_replication_globaldb=0 • 前半の話はここまで 10
11. 後半のネタは • 1/20 に開催された BuriKaigi2024 に参加してきた話 ◦ https://toyama-eng.connpass.com/event/303732/ ◦ 会場は富山県立大（射水市） ◦ 2 年連続のボランティアスタッフ参加 ◦ Togetter まとめはこちら ▪ https://togetter.com/li/2300223 ▪ 1/24 の編集部イチオシに選んでいただきました 11
12. 富山といえば • 1/1 の令和 6 年能登半島地震により一部地域で被害が ◦ 氷見市・高岡市などを中心に • BuriKaigi2024 も開催が危ぶまれた ◦ 被災して参加できなくなった人も ◦ 最終的に運営コアスタッフの判断で開催を決定 ▪ 会場施設・コアスタッフの無事が確認できた ▪ 氷見・能登の寒ブリの水揚げは（例年より少ないものの）再開された 12
13. その結果 • 地元や全国から 100 名を超える参加者が集結 ◦ 最終的に 120 名は超えていたはず • IT カンファレンスとは思えない光景が展開された ◦ X（旧 Twitter）でも一時話題に ▪ 参加者以外の人も盛り上がる 13
14. 会場でセッションを聞きながらブリしゃぶ体験！ 14 写真は当日の X（旧 Twitter）#burikaigi ポストより拝借しました
15. 大いに盛り上がりました • 毎年恒例のライブコーディング対決 ◦ 並行セッションではなくスペシャルイベント化 15 写真は当日の X（旧 Twitter）#burikaigi ポストより拝借しました
16. 感じたこと • 地方イベントは人集めが難しい、とはいうけれど ◦ 地域の特色を生かしたことを思い切りやると強いコンテンツに • スタッフをする自信がなくても何かできることはある ◦ 受付の外の誘導だったり ◦ 終わった後のゴミ集めや片付けだったり 16
17. そして • 観光客少なすぎ！ ◦ 富山も金沢も人が少ない！ ▪ 天気の問題はあったけれど ◦ 会社でお土産を配ったとき「え？大丈夫だったの？」と言われた ▪ みんな加賀と能登（石川）と越中（富山）の位置関係知らなさすぎ問題 • 被害が少なかった地域に美味しいものを食べに行こう！ ◦ 個人的には BuriKaigi を除き粗食で済ませたので次こそは… 17
18. 来年は記念すべき第 10 回！ • また参加するつもり ◦ （たぶん）3 回連続 3 回目のボランティアスタッフとして • 今回のブリしゃぶ体験が非常に盛り上がったので ◦ 企画のハードルが上がった感も 18