Amazon Aurora with PostgreSQL Compatibility

tech black belt aws Database Amazon RDS

# Amazon Aurora with PostgreSQL Compatibility

https://d1.awsstatic.com/webinars/jp/pdf/services/20190828_AWSBlackBelt2019_Aurora_PostgreSQL2.pdf

## PostgreSQL 互換モード

  • 9.6系との互換性 : 1.y.z
  • 10系との互換性 : 2.y.z

 

## 可用性と耐久性

  • Aurora ストレージ
  • ディスクの障害検知と修復
    • 2つのコピーに障害が起こっても、読み書きに影響はない
    • 3つのコピーに障害が起こっても読み込み可能
    • Gossip protocol によるノード修復
  • ストレージノードクラスタ
    • Protection Group(10GB) ごとに6つのストレージノード
    • ログとデータは別々に保存されている
    • 各ログレコードはLog Sequence number(LSN)を持っており、不足・重複しているレコードを判別可能（不足の場合は他のノードから保管）
    • Protection Group により並列に処理することができるし、パフォーマンスに影響を与えない.　リストアを非同期かつ並列に行える
    • 最大10GB なので高速で予測可能なフェイルオーバが可能
    • 10GB - 64TBまで自動でスケールアップ

 

## 性能と拡張性

  • 複数のAZに最大15のリードレプリカ
  • 低遅延
  • フェイルオーバーの順序を設定可能
  • カスタムリーダーエンドポイントによるレプリカの使い分け（アプリ用、Batch 用など）

 

## PostgreSQL と Aurora PostgreSQLの比較

  • Aurora は共有ストレージ
  • Auroraはページキャッシュが適用される
  • PostgreSQL は新規に全てがインスタンスのストレージに書き込みされる

 

## RDS for Postgres と Aurora PostgreSQL compatibility の違い

  • RDS for PostgreSQL はインスタンスごとにEBSストレージとそのミラーを持つ。書き込みがあるとシーケンシャルかつ同期的に他のノードに書き込みが走る。なのでレイテンシーは増加傾向にある。
  • Aurora PostgreSQL compatibility は共有ストレージ。キャッシュを利用しながら非同期で書き込むので6つにコピーされるがレイテンシーはそれほど増加しない。4/6の書き込みでcommit.
  • ストレージ側から見たときに、レコードを受信してキューに保存。その後SSDに書き込み。この時点でACK.
  • その後バックグラウンドでバックアップや他の処理を行う。スパイクにも対応できる。

 

## 運用管理

  • 停止可能（7日後に自動で起動する）
  • データベースのプロセスのリスタートが発生してもキャッシュが残った状態を維持可能
  • プライマリインスタンスを再起動するとレプリカもすべて再起動
  • スケールに関してcooldown Period や最小・最大数を指定可能
  • そこまで早くスケールはできないので、予測可能な場合は事前にレプリカを追加しておくのが良い
  • 定期的かつ自動的にS3にバックアップ
  • バックアップ保存期間は1-35日
  • スナップショットからの復元（5分前から任意の秒単位で復元可能）

 

  • パラメータグループ
    • デフォルトパラメータはチューニング済み
    • 静的パラメータ（適用には再起動が必要）と動的パラメータ
    • DBクラスタパラメータ
    • DBパラメータ
  • Performance Insights による監視
    • データベースロードチャート
      • SQL文、状態（CPU処理中、待機中）、接続元ホスト、接続ユーザー
    • カウンターメトリクスチャート
  • メンテナンス
    • メンテナンスウィンドウによる定期的なメンテナンス
    • 自動的なパッチ適用（数ヶ月に一回の頻度で発生。再起動を伴う可能性もある）

 

## 新機能

  • PostgreSQL 論理レプリケーション
  • Cluster Cache Management による高速リカバリ
    • フェイルオーバー後のコールドキャッシュを回避
    • 暖気されたキャッシュを持つレプリカへフェイルオーバ
  • Query Plan Management
    • クエリ計画管理を行う
    • 計画安定性。システムに上記の変更が発生した場合、QPM は計画の回帰が生じないようにして、計画安定性を向上させます。
    • 計画適応性。QPM は、新しい最小費用計画を自動的に検出し、新しい計画が使用されるときに制御し、その変更に適応します。
    • ユースケース
      • パフォーマンス低下を防止する事前予防
        • 開発環境で調査し、本番環境に適用
      • パフォーマンス低下を検出し修復
    • Database cloning
      • ストレージコストを増やすことなくデータベースのコピーを作成
      • 作成時のデータのポインタを保持し、新規に書き込みがあった場合に書き込みを行う
      • アカウント間のクローン共有も可能
    • Aurora Serverless
      • ユースケース
        • 不定期利用のアプリケーション
        • 開発・テスト用途
        • リクエスト予測が難しい場合（予測可能な場合は通常のAuroraがよし）
    • IAMの権限に基づいて、認証トークンパスワードがわりに利用（有効期限は15分）
    • 厳密なパスワード管理
      • ロール・ユーザに対するパスワードを誰が変更可能かを制御する機能
      • 10.6以降で利用可能
    • Database Activity Stream によるリアルタイム監視
      • アクティビティをKinesis Data Stream にプッシュ
    • 削除保護
    • CloudWatch Logs の特定文字列検出フィルター
    • S3からのデータをインポートする

 

## 雑感

MySQL compatibility と同様にRDS for xxx を利用するよりAurora を優先するのが良いとする内容だった。

Aurora の方が機能が豊富だし、並列処理によりパフォーマンスも出るのでこちらで問題ないと思う。仕組みの考え方について理解できたが、それを実装するAWSはすごい。

クローン作成のしくみは特にすごい。https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Clone.html