クラウドベンダーの詳細：AWSAurora上のPostgreSQL

これでどれくらい深く行けばいいですか？この記事を書いている時点で、クラウド内のPostgreSQLに関する本はAmazonで3冊しか見つかりませんでした。また、AuroraPostgreSQLに関するPostgreSQLメーリングリストでのディスカッションは117冊しかありませんでした。それほど多くはないように見えますが、好奇心旺盛なPostgreSQLエンドユーザーである私には、公式ドキュメントが、私が実際にさらに学ぶことができる唯一の場所として残されています。私には自分自身をさらに深く冒険する能力も知識もないので、そのようなスリルを探している人のためにAWS re：Invent2018があります。クォーラムに関するWernerの記事で解決できます。

ウォームアップするために、Aurora PostgreSQLのホームページから始めました。ここで、Aurora PostgreSQLが同じハードウェアで実行されている標準のPostgreSQLよりも3倍高速であることを示すベンチマークは、PostgreSQL9.6にまでさかのぼります。後で学んだように、現在、新しいクラスターをセットアップするときのデフォルトのオプションは9.6.9です。これは、アップグレードしたくない、またはすぐにアップグレードできない人にとっては非常に良いニュースです。そして、なぜ99.99％の可用性しかないのでしょうか。 1つの説明は、ブルース・モムジャンの記事にあります。

互換性

AWSによると、Aurora PostgreSQLはPostgreSQLのドロップイン代替品であり、ドキュメントには次のように記載されています。

現在、既存のMySQLおよびPostgreSQLデータベースで使用しているコード、ツール、およびアプリケーションは、Auroraで使用できます。

これはAuroraFAQによって補強されています：

これは、PostgreSQLデータベースで現在すでに使用しているコード、アプリケーション、ドライバー、およびツールのほとんどが、ほとんどまたはまったく変更なしでAuroraで使用できることを意味します。 Amazon Auroraデータベースエンジンは、PostgreSQL 9.6および10とワイヤー互換になるように設計されており、RDS for PostgreSQL 9.6および10でサポートされているものと同じPostgreSQL拡張機能のセットをサポートしているため、2つのエンジン間でアプリケーションを簡単に移動できます。

上記のテキストの「ほとんど」は、100％の保証がないことを示しています。その場合、確実性を求める人は、AWSProfessionalServicesまたはAamazonAuroraパートナーからのテクニカルサポートの購入を検討する必要があります。ちなみに、コアコミュニティの貢献者を採用しているPostgreSQLプロフェッショナルホスティングプロバイダーはどれもそのリストに含まれていないことに気づきました。

Aurora FAQページから、Aurora PostgreSQLがRDSと同じ拡張機能をサポートしていることもわかります。これにより、コミュニティ拡張機能のほとんどといくつかの追加機能が一覧表示されます。

コンセプト

Amazon RDSの一部として、AuroraPostgreSQLには独自の用語があります：

クラスター：読み取り/書き込みモードのプライマリDBインスタンスと0個以上のAuroraレプリカ。プライマリDBは、「AWSダイアグラム」ではマスター、AWSコンソールではライターとラベル付けされることがよくあります。参照図に基づいて、興味深い観察を行うことができます。Auroraは3回書き込みます。通常、AZ間のレイテンシは同じAZ内よりも高いため、トランザクションは同じAZ内のデータコピーに書き込まれるとすぐにコミットされたと見なされます。そうでない場合、AZ間のレイテンシと潜在的な停止が発生します。
クラスターボリューム：複数のAZにまたがる仮想データベースストレージボリューム。
Aurora URL： `host：port`ペア。
クラスターエンドポイント：プライマリDBのAuroraURL。クラスターエンドポイントは1つです。
リーダーエンドポイント：レプリカセットのAuroraURL。 DNSとの類似性を示すために、それはエイリアス（CNAME）です。読み取り要求は、使用可能なレプリカ間で負荷分散されます。
カスタムエンドポイント：1つ以上のDBインスタンスで構成されるグループへのAuroraURL。
インスタンスエンドポイント：特定のDBインスタンスへのAuroraURL。
Auroraバージョン： `SELECT AURORA_VERSION（）;`によって返される製品バージョン。

AWSAuroraでのPostgreSQLのパフォーマンスとモニタリング

サイジング

Aurora PostgreSQLは、DBインスタンスのサイズとストレージ容量に基づいた最適な推測構成を適用し、DBパラメーターグループを使用してDBAにさらに調整を任せます。

DBインスタンスを選択するときは、max_connectionsの目的の値に基づいて選択してください。

スケーリング

Aurora PostgreSQLは、自動スケーリングと手動スケーリングを備えています。リードレプリカの水平スケーリングは、パフォーマンスメトリックを使用して自動化されています。垂直スケーリングはAPIを介して自動化できます。

水平スケーリングは、コンピューティングエンジンを交換し、メンテナンス操作（アップグレード、パッチ適用）を実行している間、数分間オフラインになります。したがって、AWSはメンテナンスウィンドウ中にそのような操作を実行することをお勧めします。

両方向のスケーリングは簡単です：

垂直スケーリング：インスタンスクラスの変更

水平スケーリング：リーダーレプリカの追加。

ストレージレベルでは、スペースは10G刻みで追加されます。割り当てられたストレージが再利用されることはありません。この制限に対処する方法については、以下を参照してください。

ストレージ

上記のように、Aurora PostgreSQLは、パフォーマンスの一貫性を向上させるためにクォーラムを利用するように設計されています。

基盤となるストレージは同じクラスター内のすべてのDBインスタンスで共有されるため、スタンバイノードへの追加の書き込みは必要ありません。また、DBインスタンスを追加または削除しても、基になるデータは変更されません。

それらのIOsは何だろうか単位は毎月の請求書で意味しますか？ Aurora FAQは、 IO が何であるかを説明するために、再び助けになります。つまり、監視と請求のコンテキストでです。 8KiBデータベースページの読み取りに相当する読み取りIO、およびストレージレイヤーに書き込まれる4KiBに相当する書き込みIO。

高い同時実行性

Auroraの同時実行性の高い設計を最大限に活用するには、多数の同時クエリとトランザクションを駆動するようにアプリケーションを構成することをお勧めします。

読み取りクエリと書き込みクエリをそれぞれスタンバイデータベースノードとプライマリデータベースノードに送信するように設計されたアプリケーションは、AuroraPostgreSQLリーダーレプリカエンドポイントの恩恵を受けます。

接続は、リードレプリカ間で負荷分散されます。

より多くの容量を持つカスタムエンドポイントデータベースインスタンスを使用すると、分析などの集中的なワークロードを実行するためにグループ化できます。

DBインスタンスエンドポイントは、きめ細かい負荷分散または高速フェイルオーバーに使用できます。

リーダーエンドポイントが個々のクエリの負荷を分散するには、各クエリを新しい接続として送信する必要があることに注意してください。

キャッシュ

Aurora PostgreSQLは、Survivable Cache Warming技術を使用して、バッファキャッシュ内の日付を確実に保持し、データベースの再起動後にキャッシュを再設定またはウォームアップする必要をなくします。

複製

レプリカ間のレプリケーションラグタイムは、1桁のミリ秒以内に保たれます。 PostgreSQLでは利用できませんが、クロスリージョンレプリケーションラグが数十ミリ秒以内に維持されることを知っておくとよいでしょう。

ドキュメントによると、大量の書き込み要求が発生すると、レプリカの遅延が増加します。

クエリ実行計画

さまざまなデータベースの変更によりクエリのパフォーマンスが時間の経過とともに低下するという仮定に基づいて、このAurora PostgreSQLコンポーネントの役割は、承認または拒否されたクエリ実行計画のリストを維持することです。

計画は、予防的または事後対応的な方法を使用して承認または却下されます。

実行プランが拒否済みとしてマークされると、クエリ実行プランはPostgreSQLオプティマイザの決定を上書きし、「不良」プランが実行されないようにします。

この機能には、Aurora2.1.0以降が必要です。

AWSAuroraでのPostgreSQLの高可用性とレプリケーション

ストレージレイヤーでは、Aurora PostgreSQLは、物理同期レプリケーションを使用して、3つのAZ（各リージョンは通常3つのAZで構成されます）全体で6回、各10GBのストレージボリュームをレプリケートすることで耐久性を確保します。これにより、データの2つのコピーが失われた場合でも、データベースの書き込みが機能し続けることが可能になります。読み取りの可用性は、データの3つのコピーの損失を乗り越えます。

リードレプリカは、15個の使用可能なレプリカの1つをプロモートすることにより、障害が発生したプライマリインスタンスを迅速に置き換えることができるようにします。マルチAZデプロイメントを選択すると、1つのリードレプリカが自動的に作成されます。フェイルオーバーにはユーザーの介入は不要で、データベース操作は30秒以内に再開されます。

シングルAZ展開の場合、リカバリ手順には、最後の既知の正常なバックアップからの復元が含まれます。 Aurora FAQによると、データベースを別のAZで復元する必要がある場合、プロセスは15分以内に完了します。ドキュメントはそれほど具体的ではなく、復元プロセスを完了するのに10分もかからないと主張しています。

レプリカの昇格またはインスタンスの復元中にクラスターエンドポイントが変更されないため、新しいDBインスタンスに接続するために、アプリケーション側で変更を加える必要はありません。

手順1：プライマリインスタンスを削除してフェイルオーバーを強制します：

自動フェイルオーバーステップ1：プライマリを削除する

ステップ2：自動フェイルオーバーが完了しました

自動フェイルオーバーステップ2：フェイルオーバーが完了しました。

ビジーなデータベースの場合、Aurora PostgreSQLはトランザクションログを再生する必要がないため、再起動またはクラッシュ後のリカバリ時間が大幅に短縮されます。

フルマネージドサービスの一環として、不良データブロックとディスクは自動的に置き換えられます。

レプリカが存在する場合のフェイルオーバーには最大120秒かかり、多くの場合60秒未満の時間がかかります。フェイルオーバー条件が事前に決定されている場合は、リカバリ時間を短縮できます。この場合、レプリカにフェイルオーバーの優先順位を割り当てることができます。

AuroraPostgreSQLはAmazonRDSとうまく連携します–AuroraインスタンスはプライマリRDSインスタンスのリードレプリカとして機能できます。

Aurora PostgreSQLは、コミュニティバージョンと同様に、組み込みのレプリケーション制限を克服するために使用できる論理レプリケーションをサポートしています。自動化やAWSコンソールインターフェースはありません。

AWSAuroraでのPostgreSQLのセキュリティ

ネットワークレベルでは、Aurora PostgreSQLはAWSコアコンポーネント、クラウドネットワークの分離にVPC、ネットワークアクセス制御にセキュリティグループを活用します。

スーパーユーザーアクセスはありません。クラスターを作成するとき、AuroraPostgreSQLはスーパーユーザー権限のサブセットを持つマスターアカウントを作成します。

[email protected]:5432 postgres> \du+ postgres
                               List of roles
 Role name |          Attributes               |    Member of       | Description
-----------+-------------------------------+-----------------+-------------
 postgres  | Create role, Create DB           +| {rds_superuser} |
            | Password valid until infinity  |                 |

転送中のデータを保護するために、AuroraPostgreSQLはDBインスタンスごとに構成できるネイティブSSL/TLSサポートを提供します。

保存されているすべてのデータは、パフォーマンスへの影響を最小限に抑えて暗号化できます。これは、バックアップ、スナップショット、レプリカにも当てはまります。

保存中の暗号化。

認証はIAMポリシーによって制御され、タグ付けにより、ユーザーが実行できることとリソースをさらに制御できます。

すべてのクラウドサービスで使用されるAPI呼び出しはCloudTrailに記録されます。

クライアント側の制限付きパスワード管理は、rds.restrict_password_commandsパラメーターを介して利用できます。

AWSAuroraでのPostgreSQLのバックアップとリカバリ

バックアップはデフォルトで有効になっており、無効にすることはできません。毎日の完全なスナップショットを基本バックアップとして使用して、ポイントインタイムリカバリを提供します。

自動バックアップからの復元には、いくつかの欠点があります。復元にかかる時間は数時間であり、データの損失は停止の最大5分前になる可能性があります。 Amazon RDS Multi-AZ展開は、データを失うことなく、リードレプリカをプライマリにプロモートすることでこの問題を解決します。

データベーススナップショットは高速であり、クラスターのパフォーマンスに影響を与えません。コピーしたり、他のユーザーと共有したりできます。

スナップショットの作成はほぼ瞬時に行われます：

スナップショット時間。

スナップショットの復元も高速です。 PITRと比較してください：

バックアップとスナップショットはS3に保存され、119の耐久性を提供します。

バックアップとスナップショットの他に、AuroraPostgreSQLではデータベースのクローンを作成できます。これは、大きなデータセットのコピーを作成するための効率的な方法です。たとえば、数テラバイトのデータのクローン作成には数分しかかからず、パフォーマンスへの影響はありません。

AuroraPostgreSQL-ポイントインタイムリカバリデモ

クラスターへの接続：

~ $ export PGUSER=postgres PGPASSWORD=postgres PGHOST=s9s-us-east-1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
~ $ psql
Pager usage is off.
psql (11.3, server 10.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

テーブルにデータを入力します：

[email protected]:5432 postgres> create table s9s (id serial not null, msg text, created timestamptz not null default now());
CREATE TABLE

[email protected]:5432 postgres> select * from s9s;
id | msg  |            created
----+------+-------------------------------
1 | test | 2019-06-25 07:57:40.022125+00
2 | test | 2019-06-25 07:57:57.666222+00
3 | test | 2019-06-25 07:58:05.593214+00
4 | test | 2019-06-25 07:58:08.212324+00
5 | test | 2019-06-25 07:58:10.156834+00
6 | test | 2019-06-25 07:59:58.573371+00
7 | test | 2019-06-25 07:59:59.5233+00
8 | test | 2019-06-25 08:00:00.318474+00
9 | test | 2019-06-25 08:00:11.153298+00
10 | test | 2019-06-25 08:00:12.287245+00
(10 rows)

復元を開始します：

ポイントインタイムリカバリ：復元を開始します。

復元が完了したら、ログインして確認します。

~ $ psql -h pg107-dbt3medium-restored-cluster.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
Pager usage is off.
psql (11.3, server 10.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

[email protected]:5432 postgres> select * from s9s;
id | msg  |            created
----+------+-------------------------------
1 | test | 2019-06-25 07:57:40.022125+00
2 | test | 2019-06-25 07:57:57.666222+00
3 | test | 2019-06-25 07:58:05.593214+00
4 | test | 2019-06-25 07:58:08.212324+00
5 | test | 2019-06-25 07:58:10.156834+00
6 | test | 2019-06-25 07:59:58.573371+00
(6 rows)

ベストプラクティス

監視と監査

データベースアクティビティストリームをサードパーティの監視と統合して、コンプライアンスおよび規制要件についてデータベースアクティビティを監視します。
フルマネージドデータベースサービスは、責任の欠如を意味するものではありません。CPU、RAM、ディスクスペース、ネットワーク、およびデータベース接続を監視するためのメトリックを定義します。
Aurora PostgreSQLはAWS標準モニタリングツールCloudWatchと統合され、Aurora Metrics、Aurora Enhanced Metrics、Performance Insight Counters、Aurora PostgreSQL Replication、およびRDSDimensionsでさらにグループ化できるRDSMetrics用の追加のモニターを提供します。
接続オーバーヘッドの兆候、チューニングが必要なSQLクエリ、リソース競合、またはサイズの小さいDBインスタンスクラスを待つことで、平均アクティブセッションDB負荷を監視します。
イベント通知を設定します。
エラーログパラメータを設定します。
データベースクラスターコンポーネント（インスタンス、サブネットグループ、スナップショット、セキュリティグループ）の構成変更を監視します。

複製

最大DBインスタンスクラスとストレージ容量を超えるワークロードには、ネイティブテーブルパーティショニングを使用します

暗号化

暗号化されたデータベースでは、暗号化キーが取り消された場合にデータを確実に復元できるように、バックアップを有効にする必要があります。

マスターアカウント

マスターユーザーのパスワードを変更するためにpsqlを使用しないでください。

サイジング

コストを削減するために、クラスターでさまざまなインスタンスクラスを使用することを検討してください。

パラメータグループ

$$$を節約するために、パラメータグループを使用して微調整します。

パラメータグループのデモ

現在の設定：

[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
10112136kB
(1 row)

新しいパラメータグループを作成し、新しいクラスタ全体の値を設定します：

shared_buffersクラスター全体を更新します。

カスタムパラメータグループをクラスタに関連付けます：

ライターを再起動し、値を確認します：

[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
1GB
(1 row)

ローカルタイムゾーンを設定する

デフォルトでは、タイムゾーンはUTCです：

[email protected]:5432 postgres> show timezone;
TimeZone
----------
UTC
(1 row)

新しいタイムゾーンの設定：

タイムゾーンの構成

次に確認します：

[email protected]:5432 postgres> show timezone;
TimeZone
------------
US/Pacific
(1 row)

Amazon Auroraで受け入れられるタイムゾーン値のリストは、アップストリームPostgreSQLで見つかったタイムゾーンセットではないことに注意してください。

クラスターパラメーターによってオーバーライドされるインスタンスパラメーターを確認します
パラメータグループ比較ツールを使用します。

スナップショット

スナップショットを別のアカウントと共有して、それぞれの環境に復元できるようにすることで、追加のストレージ料金を回避します。

メンテナンス

組織のスケジュールに従ってデフォルトのメンテナンスウィンドウを変更します。

フェイルオーバー

クラスターキャッシュ管理を構成することにより、回復時間を改善します。
クライアントのカーネルTCPキープアライブ値を下げ、アプリケーションのDNSキャッシュとTTL、およびPostgreSQL接続文字列を構成します。

DBA注意！

既知の制限に加えて、次のことを回避するか、注意してください。

暗号化

データベースが作成されると、暗号化状態を変更することはできません。

Auroraサーバーレス

現時点では、PostgreSQLバージョンのAuroraServerlessは限定プレビューでのみご利用いただけます。

並列クエリ

Amazon Parallel Queryは利用できませんが、PostgreSQL9.6以降は同じ名前の機能を利用できます。

エンドポイント

Amazon接続管理から：

クラスターごとに5つのカスタムエンドポイント
カスタムエンドポイント名は63文字を超えることはできません
クラスターエンドポイント名は同じリージョン内で一意です
上のスクリーンショット（aurora-custom-endpoint-details）に示されているように、READERおよびカスタムエンドポイントタイプは使用できません。CLIを使用してください
カスタムエンドポイントは、レプリカが一時的に利用できなくなることを認識していません

複製

レプリカをプライマリにプロモートする場合、リーダーエンドポイントを介した接続は、プロモートされたレプリカに短時間送信され続ける場合があります。
クロスリージョンレプリカはサポートされていません
2017年11月末にリリースされましたが、AmazonAuroraMulti-MasterプレビューはPostgreSQLではまだ利用できません
クラスターで論理レプリケーションが有効になっている場合は、パフォーマンスの低下に注意してください。
論理レプリケーションには、公開された実行中のPostgreSQLエンジン10.6以降が必要です。

ストレージ

割り当てられた最大ストレージは、データが削除されても縮小されません。また、スナップショットから復元することによってスペースが再利用されることもありません。スペースを再利用する唯一の方法は、新しいクラスターへの論理ダンプを実行することです。

バックアップとリカバリ

クラスタが停止している間、バックアップの保持は延長されません。
最大保存期間は35日です—より長い保存期間には手動スナップショットを使用してください。
ポイントインタイムリカバリは新しいDBクラスターに復元します。
レプリカへのフェイルオーバー中の読み取りの簡単な中断。
ディザスタリカバリのシナリオは、地域を超えて利用することはできません。

スナップショット

スナップショットから復元すると、新しいエンドポイントが作成されます（スナップショットは新しいクラスターにのみ復元できます）。
スナップショットの復元に続いて、カスタムエンドポイントを再作成する必要があります。
スナップショットから復元すると、ローカルタイムゾーンがUTCにリセットされます。
スナップショットから復元しても、カスタムセキュリティグループは保持されません。
スナップショットは最大20のAWSアカウントIDと共有できます。
スナップショットをリージョン間で共有することはできません。
インクリメンタルスナップショットは、リージョン間および同じリージョン内で、常に完全なスナップショットとしてコピーされます。
リージョン間でスナップショットをコピーしても、デフォルト以外のパラメータグループは保持されません。

請求

10分の請求は、容量の変更（コンピューティング、またはストレージ）に加えて、新しいインスタンスにも適用されます。

認証

IAMデータベース認証を使用すると、1秒あたりの接続数に制限が課せられます。
マスターアカウントには、取り消された特定のスーパーユーザー権限があります。

開始と停止

Aurora DBクラスターの停止と開始の概要から：

クラスターは7日後に自動的に開始されるため、無期限に停止したままにすることはできません。
個々のDBインスタンスを停止することはできません。

アップグレード

インプレースメジャーバージョンアップグレードはサポートされていません。
DBインスタンスとDBクラスターの両方のパラメーターグループの変更は、伝播するのに少なくとも5分かかります。

クローン作成

データベースごとに15個のクローン（オリジナルまたはコピー）。
ソースデータベースを削除しても、クローンは削除されません。

スケーリング

Auto-Scalingでは、すべてのレプリカが使用可能である必要があります。
クラスターごとのメトリックごとに、「自動スケーリングポリシー」は1つしか存在できません。
プライマリDBインスタンス（インスタンスクラス）の水平スケーリングは完全に自動化されていません。クラスターをスケーリングする前に、レプリカの1つへの自動フェイルオーバーがトリガーされます。スケーリングが完了したら、新しいインスタンスをリーダーからライターに手動でプロモートする必要があります。 DBインスタンスクラスの変更後、新しいインスタンスがリーダーモードのままになりました。

監視

PostgreSQLログをCloudWatchに公開するには、9.6.6および10.4の最小データベースエンジンバージョンが必要です。
RDSコンソールで使用できるAuroraメトリックは一部のみであり、他のメトリックの名前と測定単位は異なります。
デフォルトでは、EnhancedMonitoringログはCloudWatchに30日間保持されます。
CloudwatchとEnhancedMonitoringのメトリクスは、ハイパーバイザーとインスタンスで実行されているエージェントからそれぞれデータを収集するため、異なります。
Performance Insights_は、DBインスタンス内のすべてのデータベースにわたるメトリックを集約します。
AWS PerformanceInsightsCLIおよびAPIで表示する場合のSQLステートメントは500文字に制限されています。

移行

保存時に暗号化できるのは、RDSで暗号化されていないDBスナップショットのみです。
Aurora Read Replica手法を使用した移行には、TiBごとに数時間かかります。

サイジング

使用可能な最小のインスタンスクラスはdb.t3.mediumで、最大のdb.r5.24xlargeです。比較のために、MySQLエンジンはdb.t2.smallとdb.t2.mediumを提供しますが、上限範囲にはdb.r5.24xlargeはありません。
max_connectionsの上限は262,143です。

クエリプラン管理

PL/pgSQL関数内のステートメントはサポートされていません。

移行

Aurora PostgreSQLは直接移行サービスを提供しませんが、タスクは特殊なAWS製品、つまりAWSDMSにオフロードされます。

結論

アマゾンオーロラPostgreSQLは、アップストリームPostgreSQLのフルマネージドドロップイン代替として、AWSクラウドを強化するテクノロジーを利用して、自動スケーリング、クエリ負荷分散、低レベルデータなどのサービスのセットアップに必要な複雑さを取り除きます。レプリケーション、増分バックアップ、および暗号化。

PostgreSQLエンジンをアップグレードするためのアーキテクチャと保守的なアプローチにより、組織が小規模から大規模まで求めているパフォーマンスと安定性が提供されます。

固有の制限は、サービスとしての大規模なデータベースの構築が複雑なタスクであり、高度に専門化されたPostgreSQLホスティングプロバイダーに利用できるニッチ市場を残していることの単なる証拠です。