【AWS BlackBelt】Amazon Aurora with PostgreSQL Compatibilityを聞きました

2017/12/20 に実施された【AWS BlackBelt】Amazon Aurora with PostgreSQL Compatibilityのまとめです。

はじめに

• RDBMSをもう一度考える
  • RDBMSは1970年代から売れている。
  • もし、今、クラウドに載せるならどうするか？
    • スタックの分割
    • スケールアウト
    • セルフヒーリング
• クラウド時代に再設計したDBがAurora

Aurora with PostgreSQL

• PostgreSQL9.6互換
  • SQL
  • クライアントアプリ（psql,pg_dumpなど）
  • プロシージャ（PL/pgSQLなど）
  • RDS for PostgreSQLで利用可能な拡張モジュールを利用可能
    • PostGISなど
• ハイパフォーマンス
• スケーラブル、堅牢かつセキュア
• スナップショット経由で、RDS for PostgreSQLから移行可能
• 低コスト
  • 商用DBよりもリーズナブル

アーキテクチャ

• ログとストレージレイヤをシームレスにスケールする
• Data Plane
  • SQL
  • Transactions
  • Cashing
• Logging+Storage

コンポーネント

• AZは3つから構成される
  • AZ aにmaster（プライマリインスタンス。書き込みをする。）
  • AZ bとcはリード専用のレプリカ
  • クラスターボリューム
    • 3つのAZ間で共有されるか総ボリューム
    • プライマリもレプリカも、同じストレージを見に行く

DBクラスタ

• パラメータグループ、メンテナンスウインドウは、DBクラスタと個別にインスタンスに設定するものがある

Auroraエンドポイント

• クラスタエンドポイント（プライマリインスタンスを指す）
  • アプリからは、クラスタエンドポイントを指定すればよい
  • フェイルオーバーが発生すると、裏側でクラスタエンドポイントの指し先が変わる
• リーダーエンドポイント（読み込みエンドポイント）レプリカに接続する単一のエンドポイント
  • リードレプリカ間でコネクションのロードバランシングができる
  • 実際のフェイルオーバーのテストを推奨
  • Readerが1インスタンスもいなくなると、Writerに接続する
• インスタンスエンドポイント（各インスタンス毎のエンドポイント）

Auroraストレージ

• スケールアウト可能な分散ストレージ
  • AZは3つにまたがっている
  • 6つのコピーを持つ
  • ストレージに対して監視を実施している
• SSDを利用したシームレスにスケールするストレージ
  • 10GBから64TBまでシームレスに自動でスケールアップ
  • 実際に使った分だけ課金
    • Cloud Watchで確認可能
• 標準で高可用性
  • ３AZに6つのコピーを生成
  • クォーラムシステムの採用
    • レイテンシの軽減を行っている
    • 4/6書き込みが終わると、アプリに返却するとのこと
  • 継続的にS3へ増分バックアップ
• Log Structured Storage

ディスク障害検知と修復

• 2つのコピーに障害が起こっても、読み書きに影響はない
  • AZ障害にも耐えられる
• 3つのコピーに障害が発生しても、読み込みは可能
• 自動検知、自己修復を行う

ストレージノードクラスタ

• Protection Group音に6つのストレージノードを利用
  • 10GB単位のボリューム（3つのAZ毎に2つのストレージノードがある）

セキュリティ

• データの暗号化
  • AES-256
• ノードへの直接アクセスは不可

レプリケーション

• DBノードに不具合が発生すると、自動的に検知され置換する
• 不具合が発生したプロセスは、自動的に検知され再起動する
• フェイルオーバーの必要がある場合、レプリカは自動的にプライマリへ昇格
• フェイルオーバー順も指定可能

高速なデータ修復

• 並列、分散、非同期で行われる

高速でより予測可能なフェイルオーバー時間

• RDS for PostgreSQLは1分~数分
• Auroraは30秒以内

パフォーマンス

vs.PostgreSQL

• プレビュー版のAuroraと比較
  • pgbenchを実行
    • 特にVacuumについては大きな差
  • SELECT/UPDATE/INSERT
    • PostgreSQLの2倍以上短く、スパイクが99％削減
• どちらもAuroraがより短時間で終了
• リカバリ時間
  • PostgreSQLは、redoログが3GB,10GB,30GBと大きくなるとリカバリ時間が長くなる（19秒、50秒、123秒）
  • Auroraは、どんな状況でも3秒程度

Auroraの特徴と使いどころ

• 高いクエリ並列度、データサイズが大きい環境で性能を発揮
• 並列度が活かせる場面でより性能的な優位性を発揮
  • リカバリ、バキュームなどの処理がより高速に
• 高い可用性・堅牢性

書き込みの違い

RDS for PostgreSQL

• プライマリでEBSに書き込み、EBSのミラーに書き込み
• スタンバイのEBSに書き込み、EBSのミラーに書き込み

Aurora

• Auroraストレージへまとめて書き込む
  • 6倍のログ書き込みだが、1/9のネットワークトラフィック
• レコードを受信してインメモリのキューに追加し、レコードをSSDに永続化するとACKを返す
  • 以降の処理は非同期で実施

キャッシュレイヤの分離

• DBプロセスを再起動しても、キャッシュが残る
  • キャッシュレイヤとDBプロセスのレイヤが分離されている

管理・運用面

スケーリング

• リードレプリカは15台まで

モニタリング

• CloudWatch
• 拡張モニタリング
  • OSレベルの監視情報を表示
• Performance Insight（プレビュー）
  • Average Active Sessionsグラフ
    • Waits（待機状態）
    • SQL
      • ボトルネックを確認できる
    • アクセス元ホスト
    • DBユーザ
    • 各観点のドリルダウン、時間軸の調整、最大CPUラインとの比較もできる
      • 最大CPUラインをよく超えており、待機状態がCPUの場合
        • max_connectionsの調整
        • 該当クエリのチューニング
  • Top Load Itemsテーブル
    • CPU、IOなど

移行

• RDS for PostgreSQLのスナップショットから移行可能
• 以下2つの条件を満たしていること
  • 9.6.1移行のインスタンスから作成されていること
  • RDSの機能で暗号化されていないこと
• パラメータグループの設定項目やデフォルト値が一部異なる
• RDS for PostgreSQL以外のDBからの移行サービスがある

まとめ

• クラウド時代にAmazonが再設計したRDBMS
• 高いクエリ並列度、データサイズが大きい環境で性能を発揮
• 高可用性

質問

• 東京リージョンのオーロラポスグレは、いつごろリリース予定ですか？
  • 投稿してみたけど、回答されず。
• ポスグレのバキュームは、もうオートバキュームに任せておけばよいのか、昔みたいにバッチ組まないといけないのか知りたいです
  • 投稿してみたけど、回答されず。
• ストレージのコストについて
  • 使用した分だけ課金になる
• マンスリーカルキュレーターにないけど？
  • RDSタグからAuroraが選択できる

おわりに

非常に面白いウェビナーでした。 来年には東京リージョンでも提供されると思いますので、楽しみにしています！