re-Cap_LT_登壇資料_初心者LT会札幌_.pdf

Transcript

1. 1 「Aurora DSQLについて解説」 ◆ NECソリューションイノベータ株式会社 工藤 僚馬 AWS 初心者LT会札幌
2. 2 Profile AWSTemplateFormatVersion: '2010-09-09' Description: Self-Introduction Resources: Me: Type: AWS::IAM::User Properties: UserName: 工藤 僚馬 Policies: - PolicyName: Skills PolicyDocument: Version: ‘2023-11-13' Statement: - Effect: Allow Action: - ‘EC2:*’ - ‘Lambda:*’ - ‘Amplify:*’ - ‘ECS:*’ - ‘TransitGateway:*’ - ‘RDS:*’ Resource: '*' Tags: - Key: Role Value: クラウドアーキテクト/エンジニア - Key: 好きなAWSサービス Value: AWS DeepRacer 最近サーフィンデビューしました。
3. 3 海外は怖いなぁ…という方へ 身に降りかかった困難一覧 ・羽田空港の保安検査場通過後にビールをぶっかけられる →ユニクロが国際線の中にあるというライフハックを発見 ・ライトニングケーブルの先端金属部分（断線ではなく）が折れる ・保安検査場のパスポート認証機械がエラーを引き起こし使えなくなる →認証機２台の内１台が使用不可になり、後列に多大なる影響（冗長性大事） ・ホテルの自動チェックイン機がフリーズする ・re:Inventの会場でぶら下げる顔写真生成でエラーが発生し 事前に設定した写真ではなく現場で撮影する羽目になる ・名前の似た別の会場に上司をUberで送迎してしまう（50分くらいロス） ・ホテルのチェックインをAM12:00に設定した結果、深夜0:00の判定 のようで、15:00に着いたのに６時間くらい待った ・カジノの収支-650$（還元率0%） ・帰国後にサブの財布を無くしていたことに気づく（保険証in） これでもre:Invent （6泊10日） 乗り切れました！！
4. Aurora DSQLとは 今年のre:Inventで発表された 新DBサービス コンセプトは ”DynamoDB for SQL Applications” ※クラメソさんブログより引用
5. Aurora DSQLとは バージニアリージョンでプレビュー開始 Aurora DSQLの特徴 登場背景 ・既存のリレーショナル データベース製品は、 急速に変化するサーバーレスとコンテナの スケーラブルな世界にはあまり適して いなかった。 （※RDS Proxyが解消するが、完全ではない。） ・グローバルにサービスを展開する際に 複数リージョンでアクティブかつ強力な 一貫性を持つデータを取得できる機能が求め られていた。 ・完全にサーバレスな分散型DB ・事実上無限のスケーラビリティ ・99.999%のマルチリージョン可用性※1 ・インフラ管理必要なし ・強い整合性 ・PostgreSQL互換※2 （Marc`s blog より引用： https://brooker.co.za/blog/2024/12/03/aurora-dsql.html）
6. インフラ管理必要なし 設定はリージョン選択だけ アクティブ-アクティブの リージョンを選択 障害発生時用のサブリージョンを選択 ※トランザクションログのみ保管 ※シングルリージョンであれば上記設定も不要
7. インフラ管理必要なし VPCへの配置が不要 接続は払い出された リージョン単位の エンドポイントから SDK, CLIなどから トークンを発行して アクセス可能
8. 強い整合性 ・結果整合性 ・強い整合性 (Aurora DSQL) 時間 データAを取得 データA データA’ データA データA’ 同期中 更新 データA’を取得 データA`を取得 Site1 Site2 時間 データA データA’ データA データA’ 同期中 更新 データA’を取得 データA`を取得 Site1 Site2 データA’を取得 Aurora DSQLは、リージョンを跨いでも強い整合性を維持
9. 99.999%のマルチリージョン可用性 ・シングルリージョン ・マルチリージョン 3AZの分散で99.99%の可用性 3リージョンの分散で99.999%の可用性 （うち一つはトランザクションログのみ保管）
10. 強い整合性 遅延はどのくらい？ ・読み取りは通常1.2ミリ秒程度※1 ・トランザクションが複雑になることでは、レイテンシは大きく増えない ・ただし楽観的同時実行制御（コミット時にのみクロスリージョンの 同期のデータ通信）のため リージョン間で競合が多発するとパフォーマンスが悪化する ・Google Cloud の Spannerの４倍の速度※2 ※1 Marc`s blog より引用： https://brooker.co.za/blog/2024/12/03/aurora-dsql.html） ※2 SpannerとDSQLは同時実行制御の方式が違うので注意
11. （補足）どうやって強い整合性を担保しているのか リージョンを跨いだナノ秒単位での時刻同期 ・トランザクションスタートとコミットの時刻が ナノ秒単位で保存される ・これにより、どのトランザクションが最新の履歴かを ナノ秒単位で判断できる ・グローバルを跨いで共有された一時ストレージ（Journal）に 順序づけられたトランザクションログとして保存され、参照される
12. PostgreSQL互換 対応していない機能 ・オブジェクト - 複数データベース - ビュー - 一時テーブル - シーケンス 等 ・制約 - 外部キー - 除外制約 ・操作 - ALTER SYSTEM - TRUNCATE 等 ・拡張機能 - pgAudit - PL/pgSQL 等 ・その他 -１時間を超える接続 - 2つ以上のDDL/トランザクション 等 対応していない機能が、現状多数存在しているので注意
13. （補足）競合の検出方法 ・Google Spanner ・Aurora DSQL こんな感じでレイテンシを抑えている ・セル単位のロック（≠行単位） ・ロックしない ・ナノ秒単位でのコミット履歴の管理 ・トランザクションスタート/コミット 完了の時刻を確認して競合を検出
14. （補足）楽観的同時制御とは？ トランザクションにロックをかけない ・ロック（悲観的同時制御） ・楽観的同時制御（OCC） 楽観的同時制御は同時にトランザクションが発生した場合リトライ処理が必要 時間 データA データA’ 更新（読み取り&書き込み） エラー 更新（読み取り &書き込み） 時間 データA データA’’ 更新（読み取り&書き込み） 更新（読み取り&書き込み） ロック ・・・ 待ち ロック
15. 似たサービスとの比較 ※1 VPCエンドポイント利用でプライベートでの接続が可能 ※2 DynamoDB Transactionで利用可能 Aurora Limitless Database (PostgreSQL) Aurora Global Table (PostgreSQL) DynamoDB Global Table Aurora DSQL アクティブ/アクティ ブ構成 ◦ × ◦ ◦ エンドポイント パブリック/プライベー ト パブリック/プライベー ト パブリック※1 パブリックのみ 同時実行制御 悲観的（ロック） 悲観的（ロック） 楽観的 楽観的 SQL ◦ ◦ × ◦ 分離レベル Repeatable read/ Read Commited Repeatable read/ Read Commited Serializable(直列可能）※2 スナップショット (= Repeatable read) リージョンを跨いだ 整合性 - 結果整合性/ セッション内整合性/ グローバル整合性 (=強い整合性) 結果整合性 / 強い整合性 （NEW!) 強い整合性
16. 16 まとめ ◆ 結局どういうユースケースで使用できるのか ・リレーショナルデータベースを使用したフルサーバレス構成を 実装したい場合 →LambdaなどのVPC外のリソースからのゼロスケールRDBとして丁度良い ・インフラの管理を限りなく少なくしたい場合 →フェールオーバ・バックアップ・パッチ適用が不要 ・急激な処理の増加・減少が発生するワークロード →既存DBのPostgreSQL 互換で最高のスケーラビリティ性を確保できる