s u m m i t · 2020-06-06 · amazon aurora のアーキテクチャ availability zone a...

S U M M I TTokyo

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T

Amazon Aurora with PostgreSQL Compatibility における運用設計のファーストステップ

Daichi EgawaAWS Solutions ArchitectAmazon Web Services Japan K.K.

B 3 - 0 5


Agenda

• Aurora Overview

• 運用上おさえておきたいポイント

• 最新機能を活用した運用効率化とTips

• まとめ


Amazon Aurora

クラウド向けに再設計された MySQL, PostgreSQL と互換性のあるRDBMS

コマーシャルデータベースの性能と可用性を1/10のコストで

フルマネージド

RDSを使ったマネージドサービスハードウェアのプロビジョニング、ソフトウェアのパッチ適用、セットアップ、構成、バックアップと

いった管理タスクからの解放

高い安全性

ネットワーク分離、保管時/通信の暗号化

優れた性能と拡張性

標準的な MySQL と比べて 5 倍、標準的な PostgreSQL と比べて

3 倍のスループットを実現; リードレプリカを最大 15 個追

加してスケールアウト可能

耐障害性、自己修復機能を兼ね備えたストレージ; 3 つのAZにわたり、6 個のコピーを保持; Amazon S3への継続的

なバックアップ

高可用性と耐久性


Amazon Aurora のアーキテクチャ

Availability Zone a Availability Zone b Availability Zone c

クラスターボリューム (Amazon Aurora ストレージ)

データコピーデータコピーデータコピー

Writes(書き込み)

Reads(読み込み)


Aurora を構成するコンポーネント

• Amazon Aurora DB クラスター➢ Amazon Aurora の管理単位

➢ プライマリインスタンス、レプリカ、クラスターボリュームの総称

• プライマリ DB インスタンス(Writer)➢ 読み込み、書き込みを行うマスターインスタンス

• Aurora レプリカ(Reader)➢ 読み込みをスケールアウトさせるレプリカ(15台まで作成可能)

• クラスターボリューム(Aurora ストレージ)➢ 3つの AZ 間でレプリケートされる仮想ボリューム

➢ プライマリインスタンスもレプリカも同じクラスターボリュームを利用

• Aurora エンドポイント➢ Aurora の接続先を示す URL

詳細：http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Aurora.Overview.html


http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Aurora.Overview.html


Aurora ストレージ

• SSDを利用したシームレスに

スケールするストレージ

• 10GBから64TBまでシームレスに自動

でスケールアップ

• 実際に使った分だけ課金

• 標準で高可用性を実現

• 3AZに6つのデータのコピーを作成

• クォーラムシステムの採用

• 継続的に S3 へ増分バックアップ

SQL

Transactions

AZ 1 AZ 2 AZ 3

Caching

Amazon S3

詳細：https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.StorageReliability.html

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.StorageReliability.html


PostgreSQL Compatibility

• PostgreSQL 9.6, 10 との強い互換性➢ SQL

➢ クライアントアプリケーション(psql, pg_dump など)

➢ プロシージャ(PL/pgSQL など)

• RDS for PostgreSQL で利用可能な拡張モジュールを利用可能➢ 例)PL/pgSQL, pgcypto, PostGIS, pg_hint_plan, orafce など

• RDS for PostgreSQL のスナップショットから移行可能


RDSなどEC2オンプレミス

データベース管理のフルマネージド化による運用負荷の軽減


運用・監視

• 高可用設計

• バックアップ

• 監視

• ログ

• Vacuum

• メンテナンス

• バージョンアップグレード


高可用性設計

• Aurora レプリカ(Reader)をマルチAZ配置可能• 複数のAZにレプリカを配置して冗長化(最大15台まで)

• プライマリインスタンスに障害が発生した場合、自動的にレプリカへフェイルオーバー

• どのレプリカが昇格するかの優先度を設定可能

• 優先度：Tier0 > Tier1 > … > Tier15

• 利用例1)プライマリと同じAZのレプリカを優先的に昇格させたい

• 利用例2)集計処理を行っているレプリカは極力昇格させたくない

• ストレージは標準で高可用性を実現• Aurora3AZに6つのデータのコピーを作成

詳細：https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Reference.html

SQLTransactions

AZ 1 AZ 2 AZ 3

Caching

Amazon S3

SQLTransactions

Caching

SQLTransactions

Caching

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Reference.html


バックアップとPITR

• 自動バックアップが常に有効• Amazon S3 へ継続かつ自動的に増分バック

アップ(バックアップウィンドウも指定不要)• Aurora ストレージの仕組みにより

パフォーマンスへ影響は出ない• バックアップの保持期間のみ指定

• データの復元とPITR• 5分前からバックアップの保持期間までの

任意の位置に秒単位で復元可能• 最新の復元可能時刻はマネジメントコン

ソールで確認可能(Latest Restorable Time 値または Earliest Restorable Time 値)

SQLTransactions

AZ 1 AZ 2 AZ 3

Caching

Amazon S3

SQLTransactions

Caching

SQLTransactions

Caching


(参考)IO traffic in Aurora (ストレージノード)

LOG RECORDS

Primary

instance

INCOMING QUEUE

STORAGE NODE

S3 BACKUP

1

2

3

4

5

6

7

8

UPDATE

QUEUE

ACK

HOT

LOG

DATA

BLOCKS

POINT IN TIME

SNAPSHOT

GC

SCRUB

COALESCE

SORT

GROUP

PEER-TO-PEER GOSSIPPeer

storage

nodes

全てのステップは非同期

ステップ1と 2だけがフォアグラウンドのレイテンシーに影響

インプットキューはPostgreSQLに比べて極めて小さい

レイテンシーにセンシティブな操作に向く

ディスク領域をバッファーに使ってスパイクに対処

OBSERVATIONS

IO FLOW

① レコードを受信しインメモリのキューに追加

② レコードをSSDに永続化してACK

③ レコードを整理してギャップを把握

④ ピアと通信して穴埋め

⑤ ログレコードを新しいバージョンのデータブロックに合体

⑥ 定期的にログと新しいバージョンのブロックをS3に転送

⑦ 定期的に古いバージョンのガベージコレクションを実施

⑧ 定期的にブロックのCRCを検証

パフォーマンスに影響しない


監視

• Amazon CloudWatch

• 拡張モニタリング

• Performance Insights

• RDS イベント通知

• ログ


監視（CloudWatch対応）

各種メトリクスを60秒間隔で取得・確認可能

• ホスト層のメトリクス• CPU使用率

• メモリ使用量 etc..

• ストレージのメトリクス• IOPS

• Queue Depth etc..

• データベース関連のメトリクス• DB 接続数

• デッドロックの回数 etc..

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.htmlhttp://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/DeveloperGuide/rds-metricscollected.html

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html

http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/DeveloperGuide/rds-metricscollected.html


Aurora PostgreSQL 固有の監視メトリクスメトリクス説明単位

MaximumUsedTransactionIDs 最も古い未バキュームトランザクション ID の古さ(詳細は次のページを参照)

カウント

AuroraReplicaLag ソース DB インスタンスからリードレプリカ DB インスタンスまでのラグ。

ミリ秒

AuroraReplicaLagMaximum DB クラスター内のプライマリインスタンスと各 Aurora DB インスタンス間の最大遅延時間

ミリ秒

AuroraReplicaLagMinimum DB クラスター内のプライマリインスタンスと各 Aurora DB インスタンス間の最小遅延時間

ミリ秒

TransactionLogsDiskUsage トランザクションログ(WAL)で使用されているディスク容量。ディスク容量監視の一貫で確認

メガバイト

VolumeBytesUsed Aurora DB インスタンスで使用されたストレージ容量。ストレージ容量に対する費用を確認するために使用

バイト

FreeLocalStorage 一時テーブルおよびログで使用可能なローカルストレージ容量(Aurora ストレージではなく、Writer, Readerインスタンス自身のローカルストレージ)

バイト


トランザクションID周回の早期検知のための運用• CloudWatch による監視とアラーム通知を設定可能

• メトリクス：MaximumUsedTransactionIDs

• 以下のSQL の値を返却

• 更新頻度などに応じた適切な閾値を元にアラーム設定

• アラームが発行された場合の対処• トランザクションIDが大きいデータベース、テーブルの特定

• autovacuum が正常に動いているかの確認

※ 確認方法などの詳細は以下のブログを参考に

詳細： https://aws.typepad.com/sajp/2017/01/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql.html

=>SELECT max(age(datfrozenxid)) FROM pg_database;

https://aws.typepad.com/sajp/2017/01/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql.html


拡張モニタリングによるOSレベルの詳細監視• OS レベルの監視情報を提供

• OS メトリクスを1秒〜60秒間隔で取得

• プロセスリスト


Performance Insights によるワークロード監視• データベースへのワークロード、

キャパシティ、統計情報を表示

• データベースへの負荷をリアルタイムに表示

• 主要な機能➢ “データベースロード” チャート

➢ “カウンターメトリクス” チャート

➢ “Top N ディメンション” テーブル

• ディメンション: 待機、SQL、ホスト、ユーザー


イベント通知（Event Subscriptions）

RDSで発生した40種類以上のイベントをAmazon SNS経由でPush通知

• シャットダウン、再起動、フェイルオーバー、設定変更、メンテナンス開始/終了 etc..

アプリケーションと組み合わせた自動化やログ保存が容易に

Event

Alarm

Queue

Message

Amazon SNS

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html

Email notification

HTTP notification

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html


ログ設定

• 障害時の切り分けなどのためにログ記録が重要

• 以下のパラメータについて事前に確認• log_statement:どのSQL文をログに記録するか設定

• log_min_duration_statement: 設定したミリ秒以上の時間がかかった場合に、そのSQL と所要時間を記録

• log_min_messages:どのメッセージ階層をサーバログに書き込むか設定

• rds.log_retention_period:システムログの保持期間を設定

※ スロークエリの分析などのために

拡張モジュール auto_explain の利用も検討

詳細：https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.PostgreSQL.html

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.PostgreSQL.html


監査ログ

• 以下のパラメータを有効にすることでログ出力が可能• log_statement：実行されたSQLを出力

• rds.force_admin_logging_level： rdsadmin によるアクションの記録

• pgaudit(拡張モジュール) の利用• ファイングレイン監査の実施が可能：特定のテーブル、列、操作のみログ

出力することにより、ログ出力にかかる負荷を制御可能

• メタデータの出力により、ログをより見やすい出力形式へ

参考：https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html#Appendix.PostgreSQL.CommonDBATasks.Auditing

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html#Appendix.PostgreSQL.CommonDBATasks.Auditing


Vacuum• 通常の PostgreSQL と同様に検討

• autovacuum の利用

• パラメータ設計• mainenance_wrok_mem/autovacuum_work_mem

• autovacuum_vacuum_scale_factor/autovacuum_vacuum_threshold

• 遅延 Vacuum関連パラメータ

• テーブルレベルパラメータの利用

• autovacuum のログ• rds.force_autovacuum_logging_level： autovacuum ワーカーによる

オペレーションを記録

• log_autovacuum_min_duration：設定した値以上の時間がかかった場合に rds.force_autovacuum_logging_level で指定されたログを出力(5000を設定すると5秒以上のアクティビティをログへ出力)

参考：https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum


ソフトウェアメンテナンス

• メンテナンスウィンドウで指定した曜日・時間帯に自動実施

• 安全性・堅牢性に関わるソフトウェアパッチを自動適用（リブートを伴うケースあり）

• メンテナンスは数ヶ月に一度の頻度で発生（毎週必ずではない）

• 指定した時間帯の数分間で実施（メンテナンス内容に依存）

http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Maintenance.html

TIPS– トラフィックが少ない曜日・時間帯をメンテナンスウィンドウに指定しておく

– イベント通知を運用監視に組み込んでおく

– describe-db-instances コマンドなどでメンテナンスの有無を定期的に確認

http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Maintenance.html


マイナーバージョンアップグレード

• 簡単な操作でアップグレードが可能• 手動(数クリックの操作) or 自動で実施可能

※ いずれの場合もダウンタイムが発生するためプロダクション環境では実施タイミングを考慮の上、手動での実施を推奨

• 注意事項/推奨事項• アップグレードされたインスタンスを前のバージョンに戻すことは出来ない。切り戻す必

要がある場合は、アップグレード前のスナップショットから以前のバージョンを復元

• 事前にテスト/リハーサルを実施し、問題ないことを確認

• 拡張モジュールのアップグレードは、ユーザー自身で行う必要がある

詳細： https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Upgrading.html

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Upgrading.html


Aurora with PostgreSQL Compatibility：新しいメジャーバージョン 10系をリリース

• PostgreSQL 10.x に対応(Aurora PostgreSQL としては v2.x)

–主な新機能：

• ネイティブ・パーティショニング(宣言的パーティショニング)

• パラレルクエリ強化(パラレルクエリに対応するScan方式、Join方式の追加)

• postgres_fdw強化(リモートサーバでの集約に対応)

→その他： https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Updates.20180305.html

詳細： https://aws.amazon.com/jp/about-aws/whats-new/2018/09/amazon-aurora-postgresql-compatibility-supports-postgresql104/

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Updates.20180305.html

https://aws.amazon.com/jp/about-aws/whats-new/2018/09/amazon-aurora-postgresql-compatibility-supports-postgresql104/


PostgreSQL ロジカルレプリケーションをサポート• PostgreSQL のロジカルレプリケーションでデータの同期が可能

• 移行元の PostgreSQL から RDS/Aurora へ同期することで移行のダウンタイムを短縮可能

• Aurora PostgreSQL から外部のPostgreSQL へデータを複製可能

• 基本的な手順/注意点(制限)は PostgreSQL マニュアルを参照• 例)DDLやシーケンスなどのレプリケーションは出来ないなど

詳細：https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication

Corporate data center

Table A

Table Bデータベース

Publication

Table A

Table BAmazon Aurora

AWS Cloud

Subscription

レプリケーション

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication


Amazon Aurora: クラスターの停止および起動をサポート• Auroraクラスターを停止/起動可能に

• クラスターを停止すると、プライマリインスタンスとすべてのレプリカインスタンスが停止

• 停止するとインスタンス料金は課金されなくなるが、ストレージ料金は課金される

• 1回に最大7日間まで停止可能。7日後に自動起動

AZ a AZ b

起動中起動中

AZ a AZ b

停止中停止中


Amazon Aurora: カスタムエンドポイント• Auroraクラスター内のどのインスタンスを含めるかを

ユーザーが指定可能なエンドポイントが作成可能に

• オンラインクエリー用のリードレプリカと分析クエリー用のリードレプリカを分離することが可能に


Database cloningストレージコストを増やすことなくデータベースのコピーを作成• データをコピーするわけではないため、

クローンの作成はほぼ即座に完了

• データのコピーはオリジナルボリュームとコピー先のボリュームのデータが異なる場合の書き込み時のみ発生

ユースケース• プロダクションデータを使用したテスト

• データベースの再構成

• プロダクションシステムに影響を及ばさずに分析目的で特定の時点でのスナップショットを保存

Production database

Clone Clone

CloneDev/test

applications

Benchmarks

Production applications

Production applications


厳密なパスワード管理によるユーザ制御

ロールに対するパスワードを誰が変更可能かを制御可能に

• 利用の仕方• rds.restrict_password_commands = 1 に設定(パラメータグループ)

• rds_password ロールの付与(本ロールを持つメンバのみパスワード変更可能)

• 注意点• Aurora PostgreSQL 10.6以降で利用可能

• rds_superuser は rds_passwordロールを常に持つ

詳細：https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Security.html#RestrictPasswordMgmt

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Security.html#RestrictPasswordMgmt


Query Plan Management による実行計画管理

apg_plan_mgmt.use_plan_baselines = true dba_plansビュー

サポートバージョン/制限

統計情報の変化環境(パラメータ)の変化バインド変数の変化

プランの安定化

ベースライン(承認済み)

詳細：https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.html

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.html


Query Plan Managementのユースケース

手動/自動のキャプチャーでプラン

エクスポートインポート

ベースラインのプランを強制

分析

ベースラインで固定

パフォーマンス低下を監視(ex. Performance Insights)

拒否

• pg_hint_plan拡張修正

SQL

承認済みプラン

SQL


SQL


問題のプランの拒否

新規のプランの承認

既存のプランの修正


Database Activity Stream によるリアルタイム監視

• データベースアクティビティをニアリアルタイムでAmazon Kinesis Data Stream へプッシュして監視可能に

• SQL コマンド、接続情報などを送信

• DBアクティビティ情報は暗号化

• 以下のパートナー製品が本機能を利用した監査に対応• SecureSphere Database Audit and Protection(Imperva)

• Data Center Security Suite(McAfee)

• Infosphere Guardium(IBM)

詳細： https://aws.amazon.com/jp/about-aws/whats-new/2019/05/amazon-aurora-with-postgresql-compatibility-supports-database-activity-streams/

Amazon KinesisData Streams

Amazon Aurora

Activity Event Record

https://aws.amazon.com/jp/about-aws/whats-new/2019/05/amazon-aurora-with-postgresql-compatibility-supports-database-activity-streams/


Cluster Cache Management による高速リカバリフェイルオーバー後のコールドキャッシュを回避

0

50,000

100,000

150,000

200,000

250,000

300,000

350,000

400,000

0 60 120 180 240 300 360 420 480 540 600 660 720 780 840 900 960 1020 1080 1140 1200

Tra

nsa

ctions

per

Second (

TPS)

Seconds

PGBench 20X RO / 1X RW 160GB Cached - Failover at 600 Seconds

Baseline

通常、データベースをバックアップしてキャッシュをウォームアップするにはしばら

く時間がかかります。このフェールオーバーの例では、CCMがないと、DBの起動に

32秒かかりましたが、パフォーマンスの90％を回復するには340秒でした

340秒

32秒


Cluster Cache Management(CCM) の動作


クラスターボリューム (Amazon Aurora ストレージ)

データコピーデータコピーデータコピー

Writes(書き込み)

Reads(読み込み)


0

50,000

100,000

150,000

200,000

250,000

300,000

350,000

400,000

0 60 120 180 240 300 360 420 480 540 600 660 720 780 840 900 960 1020 1080 1140 1200

Tra

nsa

ctions

per

Second (

TPS)

Seconds

PGBench 20X RO / 1X RW 160GB Cached - Failover at 600 Seconds

BaselineCCM Enabled

Cluster Cache Managementによる高速リカバリWriterとほぼ同期されたウォームキャッシュを持つレプリカへフェイルオーバー

CCMが有効になっていると、データベースはウォームアップされたキャッシュにフェ

イルオーバ。フェイルオーバーから32秒後には、90%のパフォーマンスを回復

340秒

32秒


まとめ

• マネージドサービスの特性を活かして、運用を省力化可能

• Aurora の最新機能を活用して、運用効率をさらに向上

Amazon Aurora remains the fastest-growing service in the history of AWS

Tens of thousands of customers, 2X customer growth for last 3 years


セッション内容• 『ビジネスの方向け：データベースマイグレーションにお

ける検討要素とAWSにおけるデータベース構築の選択肢』• Amazon Relational Database Sservice の概要• Amazon RDS for Oracle 概要• Amazon RDS for SQL Server 概要• Amazon RDS for MySQL(/MariaDB) 概要• Amazon RDS for PostgreSQL 概要• Amazon Aurora 概要• [技術者向け]データベース移行手法選択の勘所

データベースマイグレーションの進め方、RDS各エンジンの特徴をオンデマンドで学習できます

https://pages.awscloud.com/event_JAPAN_DB-migration_ondemand.html

https://pages.awscloud.com/event_JAPAN_DB-migration_ondemand.html

s u m m i t · 2020-06-06 · amazon aurora のアーキテクチャ availability zone a...

Documents