Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AWS re:Invent 2024 ふりかえり

AWS re:Invent 2024 ふりかえり

クラスメソッド re:Growth 2024 福岡 の登壇資料です。

https://connpass.com/event/335824/

Takaaki Tanaka

December 12, 2024
Tweet

More Decks by Takaaki Tanaka

Other Decks in Technology

Transcript

  1. 2 • クラスメソッド福岡 
 • 製造ビジネステクノロジー部 
 • チームマネージャー 


    • サウナ・スパ プロフェッショナル 
 田中 孝明 (Takaaki TANAKA) こーめい 

  2. re:Invent 2024 サマリー ⽣成AI and グローバル分散データベース - Amazon SageMaker のリブランディング

    - k8s の管理を⾃動化する Amazon EKS Auto Mode - 新たなグローバル分散データベース Amazon Aurora DSQL 追加 - Amazon DynamoDB global tables のマルチリージョンでの強い整合性モード を追加 - Amazon Q Developer に Unit tests / documents ⽣成機能サポート - Amazon S3 の機能強化(Metadata / S3 tables) - Keynote で Andy Jassy (現 Amazon CEO / 元 AWS CEO) が Amazon Nova を発 表
  3. Aurora であって Aurora ではない Amazon Aurora DSQL - 事実上無制限にスケールするサーバーレスな分散データベース -

    リージョンにまたがることで 99.999 % の可⽤性を実現 - マルチリージョンで Active / Active の書き込みが可能 - 強い⼀貫性 - サーバーレス(サーバーの管理不要) - PostgreSQL との互換 - ⼤規模から⼩規模までのシステムでの利⽤を想定 - 現在はプレビュー
  4. 10 - Amazon Aurora ではストレージ 層、レプリケーション層、データ整 合性層の分離をおこなってきた - PostgreSQL の操作は全て

    Query processor 層で⾏っている - トランザクション間のコンフリクト チェックは Adjudicator が担当し、 問題なければトランザクションログ を Journal に書き込む - その後書き込みログを別のリージョ ンへレプリケートする 極限までデータベースの機能を分離
  5. 11 - 楽観的ロック (Optimistic Concurrency Control) を採⽤ - Amazon Time

    Sync Service などで も利⽤されてる原⼦時計を使ってタ イムスタンプを取得 - 厳密なタイムスタンプを利⽤するこ とでコンフリクトが発⽣するのが稀 という思想 - 競合発⽣時のリトライ処理を考慮す る必要はある(楽観的ロックのデメ リットの⼀つで競合が多発する場合 はリトライが頻発する) 楽観的ロック
  6. 隣の芝⽣について 動画で⽐較対象にされたサービス - 原⼦時計(TrueTime)を使っている点は⼀緒で地球規模の分散環境における トランザクションの順番や⼀貫性の保証を実現している - ロックには Two-phase commit と

    Paxos を採⽤、準備フェーズで Coordinator と呼ばれるノードとそれ他のノードにトランザクションを伝え、 その他のノードがトランザクションに成功するようであれば成功を通知し、全 てノードが成功する時にロックを獲得してトランザクション書き込みを実施す る - 個⼈的には現時点の⽐較については静観する(リトライ処理などアプリケー ションの性質によって変わるため)
  7. 18 - 従来だと別のリージョンへのレプリ ケートまでの間、最新データに反映 されていないということが起こりう る - 書き込みログを Journal に書き込

    み、シリアライズで各ストレージに レプリケーションしていく - ただし、未取り込みの書き込みログ を適⽤していくため、レイテンシー は犠牲になる 全てのリージョンで確実に最新のデータを取得する