この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
CX事業本部@大阪の岩田です。 re:invent2019一発目のセッションはDAT328 Deep dive on Amazon Aurora with PostgreSQL compatibilityでした。 早速レポートです！
セッション概要
Amazon Aurora with PostgreSQL compatibility is a relational database service that combines the speed and availability of high-end commercial databases with the simplicity and cost-effectiveness of open-source databases. In this session, we review the functionality in order to understand the architectural differences that contribute to improved scalability, availability, and durability. You'll also get a deep dive into the capabilities of the service and a review of the latest available features. Finally, we walk you through the techniques that you can use to migrate to Amazon Aurora.
レポート
RDS PostgreSQLとAurora PostgreSQLについて
- 主にストレージレイヤーに違いがある
- RDSではPostgreSQL12がPreview状態
- AuroraではPostgreSQL11.4互換までサポートされている
Base architecture
- 3つのAZにまたがって各AZ毎に2箇所に分散して書き込みを行う
- 合計6箇所に分散して書き込みを行うアーキテクチャ
- クォーラム方式を採用
- 書き込みは4/6、読み込みは3/6のストレージで成功したらクライアントに処理成功を返す
- 15個までのリードレプリカを持つことが可能
- Writer NodeのAZに障害があった場合はRead Only NodeがWriter Nodeに昇格する
Log based storage
- RDSではLog Bufferが埋まったらストレージにフラッシュする
- ボトルネックになりがち
- AuroraはLog bufferを持たずキューに流れてきた書き込み要求を都度都度ストレージにフラッシュしていく
Writing less
- RDSではチェックポイント時にデータファイルにlog_bufferの中身を書き込む
- Auroraにはチェックポイントという概念が存在しない
- AuroraStorageに更新ログ(WAL)を継続的に適用していくだけ
- RDSや通常のPostgreSQLではチェックポイント直後に対象ページの変更点をWALに書き出す際にfull_page_writeが発生する。
- PostgreSQLのブロックサイズは8Kで、OSの4Kの２倍になっている。そのためチェックポイントでブロックに書き込みを行う際に1/2ブロックしか書き込みが完了せずにクラッシュする可能性がある
- そのような状態になっても復旧可能にするためにWALに全ページを書き込むような動作になっている
- Auroraではチェックポイントという概念が存在しないため、full_page_writeが不要。そのためWALの書き込みが高速
- (参考) full_page_writes
Conventional database backup
- 一般的なバックアップ方式としてベースバックアップ+差分バックアップの方式が知られている
- 差分をバックアップする際、更新箇所が1つのブロックだけの場合は効率的だが、複数のブロックにまたがって変更が発生している場合は、更新されてブロック全てがバックアップ対象となり処理が遅くなる。
- ベースバックアップ取得からの経過時間が長くなるとリカバリに必要な時間も長くなる
RDS backup(EBS)
- ページごとにEBSのスナップショットを取得してバックアップ
- リストア時はスナップショットから各ページを復旧してWALを適用することで復旧する
Aurora backup
- ブロックごとに継続的にログ適用していくアーキテクチャ
- 最後のブロックログを都度S3にバックアップ
Insert test
- テスト用のテーブルに大量の更新を行った際のベンチマーク比較
- 通常のPostgreSQLでは更新が増えると1秒あたりのINSERT件数が落ちていく
- DBが肥大化することでランダムアクセスのコストが上がり、WALの書き込みが遅くなるため
- WALのサイズを上げることでPostgreSQLでもパフォーマンスチューニングは可能だが、時間経過と共に遅くなっていく
- Auroraは安定して高パフォーマンスを維持
Auroraのクラッシュリカバリは97%高速
- RDSではWALのサイズを上げると、クラッシュからの復旧時に適用すべきWALのサイズが大きくなるため、リカバリ遅い
- Auroraははチェックポイント&WALでリカバリというアーキテクチャではないので高速
同期レプリケーション
- RDSではコミット時にEBSヘの同期書き込み(2ミラー)が発生する
- マルチAZ構成の場合はさらに別AZへの同期書き込みが発生し、遅い
- 3Nodeへのコピーに123ms程度の時間が必要
- Auroraではストレージノードへの書き込みのみ
- 6箇所に非同期書き込みを行い、4/6からのAckで処理完了とするためレイテンシーの影響を受けづらい
- AuroraはRDSの1AZ、バックアップ無しの構成よりも高速
- RDSはチェックポイント発生時に遅くなる。
- Auroraにはチェックポイントが無いので早い
Replica & Clone
- RDSは更新ログを非同期でリードレプリカに適用し続けるようなアーキテクチャ
- Auroraはストレージレイヤを非同期でレプリケーションしながら、メモリを更新するようなアーキテクチャ
- Auroraのリードレプリカはmsレベルの遅延で読み取りが可能
Fast clone
- AuroraのCloneはClone元へストレージのポインタを作成するだけ
- Clone後に書き込みが行われたタイミングでClone元のデータをコピー&更新してポインタから置き換えるCopy on Writeのようなアーキテクチャになっている
- Clone取得による遅延がほぼ発生しない
Replication
- logical replicationがサポートされている
- WALをSQL文に変換して適用
- DMSでWALを別のDBに適用など
Global database
- Global databaseの機能で別リージョンに複製を作成できる
- Auroraストレージをコピーする
- Replication ServerとReplication Agentが連携してレプリケーションを実現する
Caching
- PostgreSQLではshared_buffersとOSのファイルシステムキャッシュ2つのキャッシュ機構を利用する
- 一般的な設定ではマシンメモリの25%をshared_buffersに、50%をOSキャッシュに利用する
- AuroraはOSのファイルシステムを利用しないのでOSのファイルシステムキャッシュも存在しない
- キャッシュを2重持ちする事によるオーバーヘッドが削減される
- 通常のPostgreSQLではshared_buffersに多くのメモリを割り当てると、プロセスクラッシュ時にshared_buffers上のキャッシュが消えるため、復旧直後はパフォーマンスが出づらくなる。
- TPSが元の水準に戻るまで340秒程度が必要
CCM
- AuroraはCCM(Cluster Cache Management)の機構が存在するため、プロセスがクラッシュしてもshared_buffers上にキャッシュされたデータが消えない。
- そのため復旧直後から高いTPSを維持することが可能
- リカバリの所要時間(32秒)は変わらない
Performance
- パフォーマンスについて
- Performance Insightを使うことでボトルネックを特定することが可能
クエリの実行計画について
- クエリの実行計画は様々な要因によって変わり得る
- 統計情報
- 設定
- インデックス
- 不適切な結合方式が採用されることでクエリのパフォーマンスが大きく低下したりする
QPM(Query Plan Management)
- QPMを使うことで実行計画を制御することができる
- キャプチャーしてベースラインを決める
- より良い実行計画の場合は手動で承認する といったことが可能
- 参考 Aurora PostgreSQLのクエリ実行計画管理機能を試してみた
Prefetch
- 通常のPostgreSQLはファイルシステムキャッシュでPrefetchを実行している
- AuroraはPostgreSQLのPrefetch機能を進化させ、Index Range ScanにおいてもPrefetchを利用できる
- indexブロックを読み込んだ段階でheap blockから対象行のデータを読み込む
Vacuum prefetch
- Vacuum処理でもPrefetchの機能を活用している
- トランザクションIDを凍結するためにvisiblity mapとfrozen mapをVacuumする際、通常のPostgreSQLではトランザクションID凍結済みのブロックまでディスクIOが発生する
- トランザクションIDの凍結についてはこちらが参考になります。PostgreSQL: XID周回問題に潜む別の問題
- AuroraではトランザクションID未凍結のblockのみIOを行うためVacuum処理が高速になる
Serverless
- オンデマンドでインスタンスがスケールUP&downする動作方式
- アプリケーションへのインパクト無しにスケール可能
- スケールUPは高速にスケールdownは緩やかに
- 完全従量課金
- Data APIが利用可能
Migration
- 様々なマイグレーション方式が利用可能
- pg_dump/pg_restore
- DMS
- RDSからスナップショットをインポート
- RDSのリードレプリカからAuroraへレプリケーションし、Promoteする方法
Training
- 様々なトレーニングを提供中
- AWS Certified Database — Specialtyのベータ版提供中
まとめ
Auroraの内部アーキテクチャが説明されており、PostgreSQL好きの自分にはとても興味深いセッションでした。 Auroraはすごいですね！
2
