【OpsJAWS】DB系アップデートとAuroraサービスの紹介【re:Invent 2024 振り返り】

OpsJAWS Meetup32 re:Invent 2024 Ops系アップデート振り返り
「DB系アップデートとAuroraサービスの紹介」

Transcript

1. DB 系アップデートとAurora サービスの紹介 re:Invent 2024 Ops 系アップデート振り返り 1
2. 自己紹介 moko_poi SRE SRE Kaigi 2025 / OpsJAWS 2
3. 話すこと Provisioned Aurora Aurora Serverless v2 ACU 0 対応 Amazon Aurora PostgreSQL Limitless Database Amazon Aurora DSQL ※ 時間の都合上要点に絞ってお話しさせていただきます 3
4. 1. はじめに 4
5. Aurora とは？ コンピュートとストレージが分離 ストレージはマルチAZ 対応 各AZ に2 つずつストレージのコピーが配置される MySQL, PostgreSQL 互換 手動でインスタンスタイプの変更 再起動が伴うため、ダウンタイムを伴う キャパシティプランニングが難しい... ※ リーダーインスタンスの自動スケールアウトは対応 https://pages.awscloud.com/rs/112-TZM-766/images/2022_0608-DAT_Slide-Deck.pdf 5
6. Aurora Serverless v2 最小0.5ACU から最大128ACU まで、スケールアップ/ ダウンが可能 CPU, Memory, Network の使用量に応じてスケールアップ/ スケールダウンが自動で行われる 手動スケールやダウンタイムが不要 クエリやコネクションを維持 スケーリング中でもアクティブなクエリやコネクションが切断されないため、可用性が高い ※ 1 ACU = 2 GiB 6
7. 最新情報 最大256ACU に対応 https://aws.amazon.com/jp/about-aws/whats-new/2024/10/amazon-aurora-serverless-v2-256-acus/ 東京/ 大阪リージョン価格が25%OFF https://x.com/con_mame/status/1861558345217515620 ACU 0 対応 https://aws.amazon.com/jp/blogs/database/introducing-scaling-to-0-capacity-with-amazon-aurora-serverless- v2/ ※ LTS バージョンに対応していなかったりするので、そこは注意が必要 7
8. 2. Aurora Serverless v2 ACU 0 に対応 8
9. ACU 0 特徴 一時停止機能 コンピューティング料金が発生しない ストレージ料金のみ発生 再開には最大15 秒 有効化の方法 最小キャパシティを0 ACU に設定 Pause after inactivity を指定 一時停止までの非アクティブ時間を5 分～24 時間で設定 9
10. 一時停止される条件 非アクティブ期間が指定時間を超えると一時停止がトリガーされる 5 分 ~ 24 時間 で指定可能 一時停止するとステータスは「Available 」として表示 一時停止されないケース コネクションプールが維持されている場合 アプリケーションからの接続が断続的に発生する。 RDS Proxy や論理レプリケーションを使用している場合 常にバックグラウンドで接続が存在し、非アクティブ状態とみなされない Aurora グローバルデータベースの一部構成 プライマリクラスター, セカンダリクラスター https://aws.amazon.com/jp/blogs/database/introducing-scaling-to-0-capacity-with-amazon-aurora-serverless-v2/ 10
11. 再開される条件 一時停止中のインスタンスに接続した場合 新しい接続リクエストが発生すると自動的に再開 フェイルオーバー発生時 プライマリインスタンスで障害が発生すると再開プロセスが実行 メンテナンスイベントやスケジュールされたリクエスト AWS によるメンテナンスやアプリケーションのジョブが再開をトリガー 再開時の注意事項 再開には15 秒の遅延が発生する場合がある クライアント側のタイムアウト設定を15 秒以上に設定 リトライロジックを実装 11
12. 3. Amazon Aurora PostgreSQL Limitless Database 12
13. シャーディングを活用した水平スケーリング データベースの書き込みスループットとストレージ容量の拡張を実現 単一データベースとして操作可能 2 層アーキテクチャ i. Distributed Transaction Routers （分散トランザクションルーター） ii. Data Access Shards （データアクセスシャード） 13
14. https://aws.amazon.com/jp/blogs/news/amazon-aurora-postgresql-limitless-database-is-now-generally-available/ 14
15. Distributed Transaction Routers クライアントの SQL 接続を管理 SQL コマンドを適切なシャードにルーティング 結果をクライアントに返す役割を担う トランザクションの一貫性を維持 分散環境でも整合性を確保 Data Access Shards データの保存とクエリの実行を担当 テーブルの分割やシャーディングキーによる分散処理 シャード間でデータの完全性を維持 -> 各シャードは、分割されたデータの特定の部分を担当し、独自のインスタンスとして動作します。 15
16. テーブルタイプ シャードテーブル データがシャード間で分散 大規模テーブルや高負荷クエリに最適 参照テーブル すべてのシャードに完全コピー データ移動不要で結合クエリを高速化 標準テーブル 単一シャード内で動作 小規模なデータや固定的なテーブルに最適 16
17. 書き込みフロー: i. Distributed Transaction Router (DTR): クライアントからの書き込みリクエストを受信。 トランザクションを解析し、適切なシャードにルーティング。 必要に応じて、分散トランザクションを管理。 ii. Data Access Shards: 各シャードがデータを受け取り、内部ストレージに書き込み。 シャード間の整合性を維持するため、2 フェーズコミットなどのプロトコルを使用。 iii. Storage Layer: 各シャードのデータは、Aurora の分散ストレージに保存され、マルチAZ 間で同期的にレプリケー ト。 17
18. 読み取りフロー: i. Distributed Transaction Router (DTR): クライアントからのクエリを受信し、解析。 クエリに関連するシャードを特定し、リクエストをルーティング。 ii. Data Access Shards: 該当シャードがデータを取得。 必要に応じて、複数シャードからデータを集約。 iii. DTR: 集約したデータをクライアントに返送。 18
19. 制約と注意点 シャードキーの偏りによる負荷集中 偏りのあるキー選択で特定シャードに負荷が集中（ホットシャード問題） 複数シャードをまたぐ分散クエリは性能低下を招くため、適切なテーブル設計が必要 DB シャードグループの容量制限 最大容量: 16 ～6,144 ACU 初期設定時の最大容量に基づきルーターとシャード数が決定。 負荷に応じてリソースが自動スケール 19
20. 4. Amazon Aurora DSQL 20
21. サーバレス分散SQL データベース 事実上無制限のスケール PostgreSQL 互換 特徴 OCC （楽観的同時実行制御）を採用 コミット時にのみ競合を確認し、非ブロッキングで処理 可用性 シングルリージョン構成：99.99% の可用性 マルチリージョン構成：99.999% の可用性 21
22. アーキテクチャ 1. Compute Layer トランザクション処理を担当（Firecracker MicroVM 上で動作） アジュディケーターがOCC を使用し、トランザクションの競合を検出・解決 動的スケールアウトで効率的なクエリ処理を実現 2. Transaction Log Layer ジャーナルでトランザクションを記録し、AZ 間でリアルタイムに複製 一貫性と耐久性を保証 3. Storage Layer MVCC で複数バージョンのデータを保持 データ集計やフィルタリングをストレージ側で処理し、遅延を最小化 ※ MVCC: マルチバージョン同時実行制御 22
23. https://aws.amazon.com/jp/blogs/database/introducing-amazon-aurora-dsql/ 23
24. マルチリージョン構成 1. エンドポイント 複数リージョンで同時に読み書き可能 単一の論理データベースとして動作 2. 同期レプリケーション トランザクションの変更をリアルタイムで複製 強い一貫性と低レイテンシを実現 3. ウィットネスリージョン トランザクションログを一時保存 障害時の復旧プロセスを補助 24
25. なぜマルチリージョン構成では三つのリージョンが必要なのか？ クォーラムで整合性維持: 1 リージョンがダウンしても残り2 つで整合性確保 スプリットブレイン防止: ウィットネスが仲裁役を担う 障害復旧補助: ログを利用して復旧を迅速化 25
26. レイテンシ削減の仕組み 正確な時刻同期 EC2 の高精度な時刻同期（マイクロ秒単位）を活用 ノード間通信を最小限化し、一貫性を維持しつつ低レイテンシを実現 トランザクション処理の最適化 楽観的同時実行制御（OCC ）を採用 読み取り・書き込み時に競合を最小化し、コミット時に調整 スナップショット分離レベルで効率的な処理を実現 従来のProvisioned Aurora との違い Aurora DSQL: OCC （楽観ロック）でスケーラブル Provisioned Aurora: 悲観ロックで競合制御 26
27. まとめ Aurora Serverless v2 ACU 0 対応でコスト効率を最大化 最大256ACU に対応し、さらなるスケーラビリティを実現 Aurora PostgreSQL Limitless Database 高負荷なライティングワークロードにも対応可能なシャーディングレス設計 Aurora DSQL サーバレス分散SQL で高可用性（99.999% ）と強いデータ整合性を提供 運用負荷を軽減し、グローバルアプリケーションに最適 27
28. 参考資料 Aurora Serverless v2 https://pages.awscloud.com/rs/112-TZM-766/images/2022_0608-DAT_Slide-Deck.pdf https://aws.amazon.com/jp/blogs/aws/amazon-aurora-serverless-v2-is-generally-available-instant-scaling-for- demanding-workloads/ https://www.youtube.com/live/b2Tl6SsWC-M?si=hdFAeJEJ06AiCRmy https://aws.amazon.com/jp/blogs/database/introducing-scaling-to-0-capacity-with-amazon-aurora-serverless- v2/ Amazon Aurora PostgreSQL Limitless Database https://aws.amazon.com/jp/blogs/news/amazon-aurora-postgresql-limitless-database-is-now-generally- available/ https://www.youtube.com/watch?v=a9FfjuVJ9d8 https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/limitless.html 28
29. Amazon Aurora DSQL https://aws.amazon.com/jp/about-aws/whats-new/2024/12/amazon-aurora-dsql-preview/ https://aws.amazon.com/jp/blogs/database/introducing-amazon-aurora-dsql/ https://www.publickey1.jp/blog/24/amazon_aurora_dsqlpostgresql.html https://aws.amazon.com/jp/blogs/database/concurrency-control-in-amazon-aurora-dsql/ https://brooker.co.za/blog/ 29