紙一重の積み重ね

35歳のエンジニアがなれる最高の自分を目指して、学んだことをこつこつ情報発信するブログです。

【全セッションまとめ】Amazon Aurora Dayに参加してきました #AWS #Aurora

はじめに

3月28日に開催されたAmazon Aurora Dayに参加してきました。

f:id:yokoyantech:20180330214734j:plain

全体的な感想

丸1日のセミナーで非常に勉強になりました。Auroraのプロダクトマネージャ2名は英語でのセッションでしたが、同時通訳もあり、支障なく聴くことができました。

セミナー会場はほぼ満席で、Auroraに対する期待や関心の高さが伺えました。Oracleのライセンス費用は年々上昇していますし、みんな商用DBライセンス費用に苦しんでいるのだろうな・・・ということがよくわかりました。

tech.nikkeibp.co.jp

AuroraがAWS史上最も急成長しているサービスであるということから、今後もAWSはAuroraに力を入れてくるでしょう。今時、システム全体をクラウドに乗せるのに、DBだけCPUライセンスが必要というのは確かに現実的ではありません。商用DBからオープンソースDB、そしてAuroraへの流れは自然な流れなのかもしれません。

【Keynote1】Amazon Aurora with MySQL compatibility最新情報~MySQL5.7対応やプレビュー機能の狙い~

スピーカー

Sirish Chandrasekaran Principal Product Manager

なぜAuroraを作ったのか?

  • Intuit社の事例

Auroraとは

  • DBをクラウド環境のために再構築

特徴

  • スケールアウト、分散、マルチテナントデザイン
  • AWSを活用した、サービス指向アーキテクチャ
  • フルマネージドサービス、自動化されたタスク
  • ハイエンドDBのような性能と可用性
  • オープンソースDBのようなシンプルさとコスト効率
  • MySQLやPostgreSQLとの互換性
  • 利用した分だけ支払うモデル
  • マネージドサービスとして提供

Auroraを入れてもらえれば他は何もしなくていい、というようにしたい

1. スケールアウト、分散、マルチテナントデザイン

  • コンピュートレイヤをストレージレイヤと分離している
    • DB専用に作られたログストレージ
    • ストレージボリュームは3つのAZにすトライピング
    • 各AZに2つずつ、計6つのデータのコピーを保持
      • AZ+1の障害にも対応可能
    • Masterとレプリカが同じストレージを参照している

2. AWSを活用した、サービス指向アーキテクチャ

  • エコシステムを利用した構成
    • Lambda
      • ストアドプロシージャ、トリガーからLambdaイベントを実行
    • S3
      • S3からデータをロードしたり、スナップショットをS3に保存
    • IAM
      • IAMロールをDBアクセス管理に利用
    • CloudWatch
      • システムメトリクスや監査ログを保存

3. フルマネージドサービス、自動化されたタスク

  • ユーザ
    • スキーマデザイン
    • クエリ作成
    • クエリの最適化
  • AWS
    • 自動化されたフェイルオーバー
    • バックアップとリカバリ
    • 分離とセキュリティ
    • 自動パッチ適用
    • 定期的なメンテナンス
  • 時間のかかるDB管理タスクを自動化することで、アプリの改善やビジネスに専念してもらう
    • AWS史上最速で成長しているサービス
    • AWSTOP100のうち、3/4が利用している
      • なぜAuroraに移行したのか?
        • オープンソースを使っていたユーザ
          • より高いパフォーマンス(最大5倍)
          • コストを最大60%削減
          • 簡単な移行。アプリの変更なし
        • コマーシャルDBを使っていたユーザ
          • 1/10のコスト。ライセンスなし
          • Cloudシステムとの統合
          • 同等のパフォーマンスと可用性
    • 今のトレンドは、NoSQLからAuroraへの移行
      • ハイパフォーマンスアプリ用のデータストア
        • Cassandra(>100nodes)Aurora(~10clusters)
        • 大規模な遺伝子情報を扱う会社が、Auroraに移行することで、10ms未満の読み取りレイテンシと大幅なコスト削減

パフォーマンス

  • MySQL5.6&5.7と比較
    • R3ベースで約5倍の性能
  • リードレプリカレイテンシ
  • I/O
    • RDSの場合
      • プライマリインスタンス>EBS>EBSミラー
      • プライマリからレプリカへ
      • レプリカインスタンス>EBS>EBSミラー
        • それぞれボリュームが独立しているため時間がかかる
        • 両方のインスタンスで同様の作業負荷が発生する
    • Auroraの場合
      • シェアードストレージに書き込むのみ
      • 物理的なIOは発生していない
      • RDSとくらべて8倍速い
  • Auroraでのパフォーマンス向上
    • DMLスループット
      • Fast B-tree insert
      • Z-order spatial indexes
      • Smart read-node selector
        • どのノードを読むのが一番早いかを判断
    • クエリ実行
      • ハッシュjoin
        • 一部のクエリでは8倍性能が向上した
    • DDL
      • パフォーマンスの高い監査機能

可用性について

  • パフォーマンスはDBが正常に稼働しているときに気にすること
  • なぜ6つのコピーが必要なのか?
    • AZ+1の障害に対応する
      • 大規模な環境だと常に何かしらの障害は起きる
      • AZ障害は運命共同
      • AZ+1障害にも対応できて、修復も可能である必要がある
  • 15台までの昇格可能なレプリカ
    • Masterが失われても10秒以内に昇格できる

Auroraは簡単

  • RDSはたくさんのことを処理してくれる
  • さらに64TBまで10GBずつ自動スケールするストレージ
  • DBのcloneも簡単にできる
    • コピーではないので早い

なぜ安価なのか?

  • RDS
    • シェアードストレージがないので、プライマリ・レプリカごとにストレージが必要
  • Aurora
    • ストレージは1つのみ
      • このため、RDSよりも30%削減できる
    • 地裁インスタンスサイズにするとさらにコスト削減できる

移行も容易

  • 各種マイグレーションツールを用意している

Auroraの新機能

1. Multi-Master

  • 1つのMASTER、15のリードレプリカが現状
  • シングルAZなら全部がMasterになる?(要確認)
  • Auroraのダウンタイムをゼロにしたい!という要望 ex.ECサイト
  • 書込みの性能(20万/秒以上の性能が必要)ex.ゲームなど
  • 継続した書込み可用性
    • M1接続中に障害発生しても、他のノードへ接続を再接続
    • シェアードストレージなので影響はゼロ

2. パラレルクエリ

  • クエリをストレージノードの数千のCPUにプッシュダウン
  • Auroraストレージには数千のCPUがある
  • ユースケース
    • OLTPワークロードの分析クエリ
    • アドホッククエリに対するETLパイプラインを作らなくてよい
    • 複数の分析クエリを同時実行

3. サーバレス

  • 可変ワークロードを持つアプリ用のオンデマンド、自動スケーリングDB
  • ユースケース
    • スケールアップ・ダウン
    • 0からスケール

4. パフォーマンスインサイト

  • DB管理をしやすくするもの
  • DBの負荷を表示するダッシュボード
  • ボトルネックの原因を表示
    • TOP SQL

5. MySQL5.7 compatibility

  • 互換性
    • JSONサポート

【Keynote2】Amazon Aurora with PostgreSQL compatibility最新情報~ついに東京リージョンでも利用可能に~

スピーカー

Kevin Jernigan Sr.Product Manager

RDSの歴史

  • 2006年 S3リリース
  • 2009年 RDSリリース
  • 2012年 Oracleサポート
  • 2013年 PostgreSQLサポート
  • 2014年 Auroraをアナウンス
  • 2015年 Aurora with MySQLがGA
  • 2017年 Aurora with PostgreSQL compatibilityがGA

これまでのDBはスケールが難しい

  • 複数の機能レイヤーが1つのアプリケーションになっている
  • 従来のアプローチ
    • アプリレイヤでシャーディング など
  • RDBをもう1度考える
    • Cloudでやるならどうするか?
    • Auroraの誕生

Auroraをよりよく

  • PostgreSQL
    • オープンソースDBである
    • 20年の歴史がある
    • コミュニティが所有している
    • 扱いやすいオープンソースライセンス
    • 高性能
    • 標準SQL
    • 12言語でのストアドプロシージャサポート(Java、Rubyなど)
    • Oracleからの移行先としても採用しやすい
    • AWS移行ツールによる自動変換率は、OracleからPostgreSQLが最も高い

PostgreSQL compatibilityが意味するもの

  • PostgreSQL9.6 + Aurora
    • パフォーマンス向上(2~3倍)
    • 可用性(30秒未満でのフェールオーバー)
    • 堅牢性(3AZ6レプリカ)
    • リードレプリカ(15台まで)
  • セキュリティと暗号化
    • KMS
    • IAM
  • RDSによる管理機能
  • データロード・アンロード
    • AWSマイグレーションツール
  • PostgreSQLとの互換性
    • 互換性のためのレイヤーがあるのではない
    • PostgreSQLの実装をそのまま利用している
    • 互換性に関してはバグはない

パフォーマンス

  • 同じサイズのインスタンスで比較
    • PostgreSQL
      • 3つのEBS
  • pgbenchでの比較結果
    • ピーク性能の1.6倍以上
    • 最多クライアント数で実行した際の2.9倍以上のスループット
  • Sysbench出の比較結果
    • ピーク性能の2倍以上
    • 最多クライアント数で実行した際の5倍以上のスループット
  • AWSの見解
    • 保守的に見ても、標準のポスグレよりも2~3倍性能がいいと言える
  • スループット比較
    • DBサイズが10GBから100GBに増えるとどうなるか?
    • 1.8倍から4.4倍違う
      • GQ版はプレビュー版よりもさらに高性能になっている
    • DBロードでは、標準の2倍以上速く完了
      • コピー
      • バキューム処理
        • 特にAuroraはバキューム処理が早い
        • 標準よりも86%削減できる
        • Writeの回数が圧倒的に減っているため
      • インデックス構築
  • レスポンスタイム比較
    • 標準に比べて2倍以上短い
    • スパイクも99%削減
      • 標準はチェックポイント時に跳ね上がる
      • Auroraはチェックポイントのスパイクはない
        • 標準よりも99%削減
        • チェックポイントを持たない
  • スループット比較
    • 標準に比べて3倍以上一貫した結果が得られた
  • リカバリ時間比較
    • ストレージシステムのリカバリが高速に実行可能
    • 標準よりも97%短く
      • 標準
        • redoログサイズとともにクラッシュリカバリの時間が増加
        • redoログ3GBで19秒
        • redoログ30GBで123秒
      • Aurora
        • redoを持たない
        • 極めて高いスループットを維持
        • 3秒以内にリカバリを完了

パフォーマンスインサイト

  • DBの可視化をするダッシュボード
  • データサンプリングを自動化する
    • Top SQLも見れる
  • まだプレビュー版
    • GA提供はまだ

DBマイグレーションサービス

  • AWS DB Migration Service
    • データ移行の開始まで10分以下
    • 移行中もアプリを実行可能
    • 同種・異種間DBにて移行可能
  • AWS Schema Conversion Tool
    • RDBのコンバート
    • DWHのコンバート
    • 利用すると評価が得られる
      • 自動コンバートできないものがあれば理由も表示される
    • 様々なターゲットを比較できる
      • 例えば、OracleからどのオープンソースDBがいいかを教えてくれる
        • MySQLか?
        • PostgreSQLか?

Aurora with PostgreSQLについて

  • 10/24ローンチ
  • セキュリティ
    • KMS
    • SSL
    • VPC default
  • 高可用性
    • 15代のリードレプリカ
    • 高速なクラッシュリカバリ
  • 高性能
    • 標準の2~3倍のスループット
  • 運用/互換性
    • 機能レベルでの標準ポスグレとの互換性
      • 10.3もサポートする
      • メジャーバージョンは3年サポートする
      • マイナーバージョンは1年サポートする

直近のアップデート

  • GAローンチ(12のリージョン。東京含む)
  • HIPAA認証
  • 暗号化されたRDSスナップショットのインポート
  • RDS for PostreSQLから、Aurora PostgreSQLリードレプリカの作成
    • ダウンタイムを減らすことができる
  • Aurora PostgreSQL 1.1リリース(標準9.6.6との互換性)

今後

  • PostgreSQL10のサポート(1か月以内)
  • クロスリージョンレプリカ
  • アウトバウンドレプリケーション
  • マルチマスタ
  • サーバレス
  • これらは来年早々にはできるようになると思う

Auroraファミリー

  • Aurora MySQLに早く追いついていく

【Session1】徹底検証!!Aurora with PostgreSQL compatibility

スピーカー

株式会社アクアシステムズ 影山さん

内容

ブログへの掲載禁止のため割愛。

【Session2】マルチリージョンのテレビ会議クラウドをAurora+DMSで実現した話

スピーカー

株式会社リコー 井上さん

関連発表

サービス全断はダメ、ゼッタイ。途切れないテレビ会議システムを目指して。 ※去年のAWSサミット発表資料

Ricoh USCとは

  • ビジネス向けテレビ会議システム
  • 専用端末+クラウド
  • グローバル
    • お客様に近い映像配信サーバから届ける
    • AWSで11のリージョンを使っている
  • 多拠点つなげる
  • 2011年からprivateクラウドで運用開始
  • 2017年に全サービスのパブリッククラウド移行完了
    • Aurora運用開始

現構成

  • 呼制御系
    • AWSの公式ページに構成図あり
    • ECSなど活用
  • 映像配信
  • サービス監視

AWS移行直後の構成

  • オンプレからほぼそのままの構成で移行
  • MySQL/RDSを1セット配置
  • 課題
    • インスタンス数が多い
      • 複数リージョンで協調動作するシステム
      • データは主に3種類
        • 主リージョンで書き込み、全リージョンで参照
        • 全リージョンで読み書き、主リージョンに集約
      • SPOFの内向性が必要
    • フェイルオーバー時間に不満
      • アプリ対応に限界
    • ストレージ不足に拡張処理が必要
    • 小サイズのRDSは効率が悪い
      • 5GBで十分なDBもある
      • GP2ストレージの性能不足、補うには33GB以上が必要!!
  • 進構成の検討
    • Auroraの利用
    • しかし
      • 数が多いため高コストで無駄が多い
    • そこで
      • DMSによる柔軟なレプリケーション構成を検討
  • DMS
    • 移行を行うマネージドサービス
      • RDBMSからS3などもできる
    • 一括コピー、継続的コピーが可能
    • テーブルを取捨選択してコピー可能
    • スキーマを変換しながらのコピー可能
  • DMSとMySQL
    • 変更検知はBinary Logを使用
      • checksumなし
    • 注意点
      • 文字セットの制限
        • 以下は使えない
          • utf8mb4
          • us_ascii
      • 開始点は秒単位の時刻で指定
  • 最終的なDMS導入決定
    • 想定外の問題はAWSと協力してつぶしていく!!

新構成と移行

  • リージョンごとに1つのAuroraクラスタをマルチAZで設置
  • 検証
    • Auroraのサイジング
    • アプリの機能テスト・性能テスト
    • ソースおよびターゲットDBのフェイルオーバー
    • DMSの機能・性能
  • 検証で分かったこと
    • 機能や性能に問題はない
    • Auroraのフェイルオーバー追従に課題
  • Auroraのフェイルオーバー
    • マルチAZでは30秒くらいで切り替わる
  • クライアントから見た課題
    • 読み書きするクライアントがレプリカにつながってしまう
  • 対策
    • JavaアプリはMariaDB Connector/Jを利用
      • 高速フェイルオーバーの恩恵を受けれる
    • クライアントを修正する
      • 泥臭い修正
  • DMSの挙動
    • ターゲットのAuroraが切り替わる:自動接続
    • ソースのAuroraが切り替わる:自動接続しない
      • DMS1.9時点
  • 対策
    • DMSタスク監視
  • 移行手順1
    • MySQLからAuroraのリードレプリカを用意してレプリケーション
    • そのほかのDBからもAuroraへレプリケーション
  • 移行手順2
    • 当日の作業は30分くらい
      • 旧DBからAuroraへのレプリケーション停止
      • DMSで処理できないDBをダンプから投入
      • DMSタスク作成&開始

9か月分かったこと

  • Auroraクラスタは毎日作るものではない
    • 開発環境は毎日構築・破棄
    • Auroraクラスタのスナップショットからの構築は遅い。時々失敗する
    • Auroraクラスタだけ残してもコストはS3の5倍程度
    • 句ら鵜s他を残し、DBインスタンスのみ毎日構築するようにした
  • Auroraアップっグレードとの付き合い方
    • 必須アップグレードは所定の期間内にメンテナンスが必要
    • 20~30秒のダウンタイムが発生
      • 本番環境以外で影響確認したい
    • 旧バージョンのAuroraを顧客が作る方法はない
      • 本番以外で常時稼働環境が必要になる!!
  • Zero Downtime Patching
    • 接続を維持したままアップグレードできる機能
    • DBの使い方によって背教が出る
      • サーバサイドのプリペアドステートメントが消える、など

まとめ

  • すこしずつ移行するのがおすすめ
  • 最終形ではない
    • 日々のキャッチアップ

【Session3】Oracle DatabaseからAurora with PostgreSQL compatibilityへの移行~orafceの活用による活用事例&メリット~

スピーカー

NTTテクノクロス株式会社 勝俣さん

orafceとは?

PostgreSQL上でOracleの機能を使えるようにする拡張モジュール 以下が使えるようになる - Data Type - SQL Queries - SQL Functions - SQL Operators - Packages

意外と多い細かな違い

  • Varchar2(n)
    • Oracle:byte数指定
    • PostgreSQL:文字数指定
  • DATE型
    • Oracle:年月日時分秒
    • PostgreSQL:年月日

メリット

  • 移植の効率化
    • ポスグレ標準+orafceがサポートする関数カバー率:34%
    • 実案件で使うだろう関数のカバー率:73%

【Session4】Oracle DatabaseからAmazon Auroraに移行するための実践ガイド

スピーカー

アマゾンウェブサービスジャパン株式会社 江川さん

お客様の声

  • クラウドにシステム全体を移すのであれば、RDBMSもクラウドネイティブにしたい
  • RDBMSもオートスケールさせたいが、CPUライセンスだとできない
  • IT予算の多くをOracleライセンスを占めている

現場の悩み

  • 業務部門・アプリ開発部門
    • アプリへの影響はどれくらい?
    • 移行の業務停止は短くしたい
  • IT・インフラ部門
    • 業務部門に何をガイドしたりいいの?
    • 従来の管理腫瘍がどう変わる?
    • 移行費用はかけたくない

決めないといけないこと(5W1H)

1. What?(対象システムは?)

2. Why?(移行理由は?)

3. How?(移行戦略は?)

AWSの考える6つの戦略

  1. Re-Host(ホスト変更)
  2. Re-Platform(プラットフォーム変更)
  3. 移行の複雑さ2位
  4. Re-Purchase(買い替え)オンプレのOracleを、ライセンス込のRDS for Oracleへ
  5. Refactor(書き換え)オンプレのOracleをAuroraに変更する、など
  6. 移行の複雑さ1位
  7. その分のメリットは大きい
  8. Retire(廃止)このタイミングで古いDBやシステムを破棄する
  9. Retain(保持)オンプレを使い続ける(Oracle9iに依存してるアプリなど)

4. Where?(移行先は?)

  • RDS
    • Aurora MySQL
    • Aurora PostgreSQL
      • 結合法方
        • ネステッドループ
        • ハッシュ
        • ソートmerge
      • インデックス
        • Bツリー
        • 関数
        • 空間
        • 全文
        • ゾーンマップ
      • 制約
        • NOT NULL
        • PK
        • UNIQUE
        • FK
        • CHECK
  • Redshift
    • データウェアハウス用途
  • on EC2

5. When?(期限は?)

  • 工数見積が必要
    • 工数=移行先との違いの量

6. Who?(担当者は?)

  • 工数見積が必要
    • 工数=移行先との違いの量

移行支援サービス

  • 計画
    • AWS CTO Calculator
  • 移行
    • AWS DMS
  • 運用

AWS DMSとは

  • 既存DBを最小限のダウンタイムでマイグレーションするサービス
  • 同種はもちろん異種プラットフォームの移行にも対応
  • 移行中もアプリケーションは稼働したまま
    • AWS上にDMS用のAurora起動
    • 移行元のDBとDMSを以下で接続
      • Internet
      • VPN
      • Direct Connect
    • DB同期が完了したら、アプリ側のDBの向き先を変える(ダウンタイムはここだけ)
  • マルチAZ構成が可能

AWS Schema Conversion Tool

  • ソースDBのビューやFunctionをターゲットDB向けに変換
  • デスクトップアプリで提供
  • できること
    • 自動変換&自動変換の補助
    • 評価レポートの作成
      • どこができるか色分けされたグラフが出る
        • 緑:自動変換
        • 青:検討が必要
        • 赤:深い検討が必要
    • アプリケーションSQLにも対応

事例

  • レコチョク
    • Oracle RACからAurora移行
      • 1000万会員のDB
    • DMS/SCTリリース前に手動で移行
    • 結果
      • Auroraによる障害はこれまでゼロ
      • DBサーバ運用に工数はほとんど咲かなくてよい

Oracleとの違い

  • Objectの主な違い
    • MySQLのシーケンス
      • AUTO_INCREMENT属性を付与
      • NULLまたは0を入れる
    • PostgreSQLのマテリアライズドビュー
      • リフレッシュは手動のフルリフレッシュのみ
      • 読み取り専用のみ対応
    • PostgreSQLのDBリンク
      • dblink
        • 関数として実装されている
        • ビューで隠ぺいするのが一般的
      • postgres_fdw
    • パーティショニング
      • MySQL
        • RANGE、HASH、LIST、KEY
      • PostgreSQL
        • RANGE、LIST
        • v10~宣言的パーティショニング
      • ストアドプロシージャ/ストアドファンクション
        • AuroraはJavaプロシージャに未対応
  • 互換性がないとどうなるのか
    • 文法ERRORになる
      • 地道に対応する
    • 文法ERRORにならず結果が異なる
      • このパターンが厄介

結果相違を起こしやすい2大ポイント

  1. NULLと空文字の扱いの違い
  2. OracleがSQL標準からずれている
    • Oracleでは区別しない
    • MySQLやPostgreSQLは区別する
  3. 対策
    • ''でgrepするとよい
    • 外部結合した後の||にも注意
  4. CHARの埋められた空白の扱いの違い
  5. Oracleは末尾の空白を保持する
  6. MySQLとPostgreSQLは、末尾の空白を無視する

トランザクション分離レベル

  • 数やデフォルトがDBで違う

バキューム

  • postgreSQL独自
  • 運用設計が必要
    • 今は自動になっている

【Session5】移行の前には移行アセスメントを~移行難易度や工数を事前に確認する~

スピーカー

アマゾンウェブサービスジャパン株式会社 北川さん

現実では・・・

簡単にDB移行できないこともある(外字が入っているとか)

移行前に実施すべき内容

  1. システムの棚卸
  2. 移行対象DBを使っているシステムの把握
  3. システム間連携の有無
  4. データの流れの把握
  5. 障害発生時の復旧プロセス
  6. そもそもDMSがサポートしているDBバージョン・エディションか?
  7. 移行対象の決定
  8. ミドルウェアのサポート終了期間の確認(緊急度)
  9. アセスメントの実施
  10. プロシージャの数
    • DDLはSCTで自動変換できる
    • プロシージャはDCTの自動変換率が比較的低い
      • SCTで評価レポートを作成する
        • 予想工数が色分けされる
          • 青:1時間未満
          • 黄:4時間未満
          • 赤:4時間以上
  11. SELECT文の数
    • 自動変換率が比較的低い
  12. テストの洗い出し、工数確認
    • SQL解釈の方言で同じSQLでも結果が違う可能性がある
    • データが正しく移行されたかの確認が必要
    • テストフレームワークがあればよいが、なければ大変
    • 工数だけで判断しない
      • 重要度と緊急度も考慮する
  13. 移行計画
    • ダンプツール
    • CSVアンロード
    • レプリケーション
    • DMS
      • 何でもかんでもDMSでやろうとしない
      • ネイティブの方法がベストな時もある
  14. 事前検証の実施
  15. 選択した移行方法で留意事項を確認
    • ¥マーク、外字など
    • 同期レプリケーションか?非同期レプリケーションか?
      • どれくらい時間差があるのか
      • 非同期の場合クラッシュしたらどうするか?
        • マルチAZ構成
        • DMSで二重障害が起きるとどこから再開するかが困難
        • 「十分な時間がとれるか?」を再度検討すべき
  16. スケジュールの策定
  17. 事前検証結果から、移行方法が妥当か確認
  18. 連携状況から他のシステムを含めた影響を確認
    • 本当に並行移行させる必要があるのか?
    • 1日止めれば難易度は下がるのでは?(安全かつ確実)
      • など
  19. トラブルを見越したスケジュールを組む
  20. 検証には可能な限り実データを使用する

まとめ

このエントリではAurora Dayの各セッションをまとめました。Auroraに興味がある方のお役に立てれば幸いです。私はPostgreSQLを使うことが多いため、Aurora with PostgreSQL compatibilityのリリースはとても嬉しいです。自分のプロダクトでAuroraに移行できないか検討してみたいと思います!!