紙一重の積み重ね

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

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

f:id:yokoyantech:20171220191141p:plain

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で確認可能
  • 標準で高可用性
    • 3AZに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が選択できる

おわりに

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