[AWS Black Belt Online Seminar] Amazon Aurora with PostgreSQL Compatibility 資料及び QA 公開

先日 (2019/8/28) 開催しました AWS Black Belt Online Seminar「Amazon Aurora with PostgreSQL Compatibility」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

20190828 AWS Black Belt Online Seminar Amazon Aurora with PostgreSQL Compatibility

AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます）

Q. サブネットグループで、AZを2つだけグルーピングしていた場合でも、ストレージ（データ）は、３つのAZに書込みされるのでしょうか？
A. はい。サブネットグループの設定に関わらず、Amazon Aurora は自動的に 3 つのアベイラビリティーゾーンにかけて 6 個のデータコピーを保持します。サブネットグループには、プライマリインスタンス(Writer), Aurora レプリカ(Reader)を配置するために利用します。

Q. リードレプリカについては、追加インスタンス毎に、インスタンスタイプを変えることは可能という認識であっていますか？
A. はい。ご認識の通り可能です。ただし、プライマリインスタンスとリードレプリカは同じインスタンスクラスを利用することを推奨しています。レプリカの追加方法についてはこちらのドキュメントをご確認ください。

Q. RDS for PostgreSQL を選択するメリットは、どういうものがあるでしょうか？
A. 現時点でAurora ではサポートされていない機能や拡張を利用したい場合は、RDS for PostgreSQL を選択する理由になります。例えば、PostgreSQL v11 は、2019年9月2日現在、RDS for PostgreSQL のみでサポートされています。

Q. Aurora Serverlessで、コネクション数に関する制限は出たりしないでしょうか。各リクエスト負荷は低いが大量のコネクションが要求されるような場合に、インスタンススケールアップだけで耐えられるのかが気になります。
A. まず、Aurora サーバーレス DB クラスターに割り当てられたキャパシティーは、クライアントアプリケーションで生成される負荷(CPU 使用率と接続数) に基づいてシームレスにスケールアップ/ダウンされます。Aurora Serverless(PostgreSQL)においても、provisioned Aurora クラスタ(通常の Aurora)と同様に max_connections パラメータにて、コネクション数の管理を行います。デフォルトでは、この値は次の式に設定されます。

LEAST({DBInstanceClassMemory/9531392},5000)

本パラメータの設定を確認のうえ、想定されるワークロードに基づいた検証を行い、ご確認いただければと存じます。

Q. プライマリインスタンスへの書き込み直後に落ちた場合、レプリカのデータと差異が出ることはありますか？
A. プライマリインスタンス、レプリカ共に同じストレージボリュームを利用しているため、プライマリインスタンスへの書き込みによって確定したデータが利用できなくなることはありません。

Q. S3バックアップされるとのことですがDBとS3の差異が生じることはありますか？
A. S3 へのバックアップはストレージノード側で非同期で行われます。そのため、DB インスタンスの最新の復元可能時刻は、Latest Restorable Time 値または Earliest Restorable Time 値(通常は現在時間の 5 分以内)を確認する必要があります。

Q. 削除しても最終スナップショットを取っておけば復旧可能なのですか？
A. はい。最終スナップショットを取得することにより、削除した時点のデータを復元可能です。

Q. 再起動はどういう場合にするのですか？
A. たとえば、メンテナンスのために、DB インスタンスを再起動する必要があるケースがあります。たとえば、DB インスタンス またはそのDB クラスターに関連付けられた DB パラメータグループを変更する際に、変更を反映するためにインスタンスを再起動させる必要がある場合があります。

Q. レプリカ自動増減機能で追加時にキャッシュさせるために、一回クエリを投げてからそのレプリカに次からアクセスさせるようなことはできるのですか？
A. Amazon Aurora Auto Scaling 単体では、そういった機能の実現はできません。

Q. キャッシュが足りない場合は、物理的にAuroraを増やしてテーブルを物理的に分けるのが良いですか？もしくはリードレプリカを複数立てて、リードレプリカ１にはテーブル１の参照、リードレプリカ２にはテーブル２の参照のような分散をさせるのが良いですか？
A. リードレプリカを増やすことで解決可能であれば、それが良いかと存じます。一般的に、物理的にテーブルを分ける手法(シャーディング)に比べて、シンプルな解決方法だという認識のためです。

Q. バージョンアップは簡単ですか？DB停止必要ですか？
A. アップグレードには、メジャーバージョンのアップグレードとマイナーバージョンのアップグレードの 2 種類があります。マイナーバージョンアップグレードについては、Amazon Aurora の機能で数クリックの操作で実現できます。アップグレードにはダウンタイムが必要です。こちらの資料をご参照ください。

メジャーバージョンのアップグレードでは、2019/9/2現在、Aurora の機能としてはサポートされていません。そのため、PostgreSQL ユーティリティ pg_dump や pg_restore などのダンプツールやロードツールを使用して、あるメジャーバージョンから別のメジャーバージョンに移行することができます。

Q. クローンを作ると読みこみがもともとのDBとクローン両方からされるようになるので遅くなりますか？
A. いいえ。基本的にはクローンにより、クローン元のプロダクションデータベースのパフォーマンスに影響が出ることはありません。

Q. インスタンスタイプによってvCPUが異なりますがそこは自動でvCPUを使い切るように動いてくれるのですか？
A. いいえ。CPU を使い切るかどうかは、Aurora を利用するワークロードに依存します。

—

今後の AWS Webinar | イベントスケジュール

直近で以下を予定しています。各詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております。

【AWS Innovate Online Conference】

AWS Innovate は、AWS クラウドを活用してビジネス革新を目指しているすべての IT リーダー及び IT プロフェッショナルを対象とした、最新のクラウド情報をお届けするためのオンラインカンファレンスです。この期間で、AWS初心者の方はAWSを始めるための準備を、AWS既存ユーザーの方は情報のアップデートにお役立ていただければと思います。