AWS Black Belt Online Seminar Amazon Aurora with PostgreSQL … · 2018-03-23 · AWS Black Belt...

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Daichi Egawa, Solutions Architect

Amazon Web Services Japan K.K.

2017.12.20

【AWS Black Belt Online Seminar】Amazon Aurora with

PostgreSQL Compatibility


内容についての注意点

• 本資料では2017年12月20日時点のサービス内容および価格についてご説明しています。最新の情報はAWS公式ウェブサイト(http://aws.amazon.com)にてご確認ください。

• 資料作成には十分注意しておりますが、資料内の価格とAWS公式ウェブサイト記載の価格に相違があった場合、AWS公式ウェブサイトの価格を優先とさせていただきます。

• 価格は税抜表記となっています。日本居住者のお客様が東京リージョンを使用する場合、別途消費税をご請求させていただきます。

• AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change in accordance with the AWS Customer Agreement available at http://aws.amazon.com/agreement/. Any pricing information included in this document is provided only as an estimate of usage charges for AWS services based on certain information that you have provided. Monthly charges will be based on your actual use of AWS services, and may vary from the estimates provided.


AWS Black Belt Online Seminar とはAWSJ の Tech メンバが AWS に関する様々な事を紹介するオンラインセミナーです

【火曜 12:00~13:00】主に AWS のソリューションや業界カットでの使いどころなどを紹介(例：IoT、金融業界向け etc.)

【水曜 18:00~19:00】主に AWS サービスの紹介やアップデートの解説(例：EC2、RDS、Lambda etc.)

※開催曜日と時間帯は変更となる場合がございます。最新の情報は下記をご確認下さい。

オンラインセミナーのスケジュール & 申し込みサイト• https://aws.amazon.com/jp/about-aws/events/webinars/

https://aws.amazon.com/jp/about-aws/events/webinars/


AWS Black Belt Online Seminar へようこそ！

質問を投げることができます！Adobe Connect の Q&A ウィンドウから、質問を書き込んでください（書き込んだ質問は、主催者にしか見えません）

今後のロードマップに関するご質問はお答えできませんのでご了承ください

Twitter へツイートする際はハッシュタグ #awsblackbelt をご利用ください

①Q&Aウィンドウ右下のフォームに質問を書き込んで

ください

②吹き出しマークで送信してください


Agenda

• はじめに

• アーキテクチャ

• パフォーマンス

• 管理・運用

Performance Insight による監視

• 移行

• まとめ


リレーショナルデータベースをもう一度考える

• 今、データベースを再度実装するならどうするか？

スタックの分割

以下のようなことを実装: スケールアウト

セルフヒーリング

分散サービスの活用


Amazon Aurora

特徴 (http://aws.amazon.com/jp/rds/aurora/)

• MySQL5.6との互換性(MySQL 5.7互換はプレビュー中)

• 3AZに6本のディスクに書き込み2本のディスク障害ではRead/Write可能。3本のディスク障害でもRead可能

• キャシュとログをAuroraプロセスから分離することでAuroraプロセスのリスタートでもキャッシュが残る

• レプリケーション遅延は10-20ms程

• 64TBまでディスクがシームレスにスケールする

価格体系 (http://aws.amazon.com/jp/rds/aurora/pricing/)

• 選択したインスタンスタイプ

• 実際に利用したディスク容量 (プロビジョニング不要)

• バックアップストレージ容量

Amazonがクラウド時代に再設計したデータベース

http://aws.amazon.com/jp/rds/aurora/

Po s t g r e S Q L Fo r A u r o ra2017/10/24 GA リリース！(Virginia, Ohio, Oregon, Ireland)

2017/11/22 Region Expansion(Canada , Frankfurt, Sydney,Mumbai)

低コストPostgreSQL 9.6互換ハイパフォーマンススケーラブル、堅牢かつセキュア

スナップショット経由でRDS for PostgreSQL から移行可能

Amazon Aurora with PostgreSQL Compatibl ity



• PostgreSQL-compatible edition を選択可能に



• PostgreSQL 9.6 との互換性 SQL

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

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

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

※ その他のモジュールについては以下のドキュメントを参照くださいhttp://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions.96x

※ wal2json についてはサポートされていません参考)http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.AuroraPostgreSQL.html#Aurora.AuroraPostgreSQL.Compare

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

http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions.96x

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.AuroraPostgreSQL.html#Aurora.AuroraPostgreSQL.Compare


アーキテクチャ


Service Oriented Architecture

• ログとストレージレイヤをシームレスにスケールするストレージサービスに移動

• EC2, VPC, DynamoDB, SWF,Route 53 などのAWSサービスを管理コンポーネントに採用

• Amazon S3 を利用して99.999999999% の耐久性でストリーミングバックアップ

Amazon DynamoDB

Amazon SWF

Amazon Route 53

Logging + Storage

SQL

Transactions

Caching

Amazon S3

Amazon RDS

Data Plane Control Plane


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

詳細：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 を構成するコンポーネント

• DB クラスター

Amazon Aurora の管理単位

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

• プライマリインスタンス(Writer)

読み込み、書き込みを行うマスターインスタンス

• Aurora レプリカ(Reader)

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

• クラスターボリューム (Amazon Aurora ストレージ) (詳細は後述)

3つの AZ 間でレプリケートされる仮想ボリューム

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

• Aurora エンドポイント(詳細は後述)

Aurora の接続先を示す URL


DB クラスター

• プライマリインスタンス、レプリカ、クラスターボリュームを包括する Aurora 固有の概念

パラメーターグループ、メンテナンスウィンドウも DB クラスターと各インスタンスそれぞれに設定


Aurora エンドポイント• 以下の 3種類のエンドポイントが利用可能

クラスターエンドポイント：常にプライマリインスタンスを指すエンドポイント

リーダーエンドポイント(読み込みエンドポイント)：レプリカに接続する単一のエンドポイント

インスタンスエンドポイント：各インスタンスごとのエンドポイント


クラスタエンドポイント

Availability Zone A Availability Zone B

VPC subnet VPC subnet


Aurora Writer Aurora Reader


• 各Auroraノードは個別にエンドポイント(インスタンスエンドポイント)を持っている

• クラスターエンドポイントは、その時アクティブなAurora Writer

ノードのCNAME

Write


• フェイルオーバが発生すると、Auroraノードの昇格が行われ、クラスタエンドポイントの指し先が変わる




Aurora Writer Aurora Writer


Write



リーダーエンドポイント(読み取りエンドポイント)• Amazon Aurora cluster内のReaderに単一のエンドポイントを提供

• ReaderがFailoverした場合は、再接続を行うことで新しいReaderに接続が可能• Round Robinで接続

• メリット• Load Balancing – クラスタエンドポイントに接続することでDBクラスタ内のリードレプ

リカ間でコネクションのロードバランシングが可能

• Higher Availability – 複数のAuroraレプリカをAvailability Zone毎に配置し、リードエンドポイント経由で接続することが可能

• 負荷分散用のソフトウェアを利用していた場合は、置き換えることでシンプルに実装可能

• 注意点• DNSベースなのでアプリケーションやドライバ側でIPアドレスのキャッシュ周りの設定の

確認やfailoverのテストを推薦• Readerが1インスタンスもいなくなった場合はWriterへ接続


リーダーエンドポイント

• クラスタ内のReaderにラウンドロビンで接続

• 常にReaderに接続されるが、Readerが1インスタンスもいなくなった場合はWriterに接続

• Readerの追加・削除は自動で行われる



VPC subnet VPC subnetAurora Reader Aurora Reader

リーダエンドポイント

Read

Aurora Writer


Aurora ストレージ：スケールアウト可能な分散ストレージ

Master Replica Replica Replica

Availability Zone 1

Aurora ストレージ(共有ストレージボリューム)

プライマリインスタンス

リードレプリカリード

レプリカリード

レプリカ

Availability Zone 2 Availability Zone 3

リージョン

ストレージ監視

データベース・インスタンス

監視


Aurora ストレージ

• SSDを利用したシームレスにスケールするストレージ

• 10GBから64TBまでシームレスに自動でスケールアップ

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

• 標準で高可用性を実現• 3AZに6つのデータのコピーを作成

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

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

• Log Structured Storage

SQL

Transactions

AZ 1 AZ 2 AZ 3

Caching

Amazon S3


ディスク障害検知と修復

• 2つのコピーに障害が起こっても、読み書きに影響は無い• 3つのコピーに障害が発生しても読み込みは可能• 自動検知、修復

SQL

Transaction

AZ 1 AZ 2 AZ 3

Caching

SQL

Transaction

AZ 1 AZ 2 AZ 3

Caching

読み書き可能読み込み可能

詳細： https://aws.amazon.com/jp/blogs/news/amazon-aurora-under-the-hood-quorum-and-correlated-failure/

https://aws.amazon.com/jp/blogs/news/amazon-aurora-under-the-hood-quorum-and-correlated-failure/


ストレージノードクラスタ

• Protection Group毎に6つのストレージノードを使用

• 各ログレコードはLog Sequence Number(LSN)を持っており不足・重複しているレコードを判別可能

不足している場合はストレージノード間でゴシッププロトコルを利用し補完

詳細： http://aws.typepad.com/sajp/2017/02/introducing-the-aurora-storage-engine.html

http://aws.typepad.com/sajp/2017/02/introducing-the-aurora-storage-engine.html


セキュリティ

• データの暗号化• AES-256 (ハードウエア支援)• ディスクとAmazon S3に置かれている全ブロックを暗号化• AWS KMSを利用したキー管理

• SSLを利用したデータ通信の保護

• 標準でAmazon VPCを使ったネットワークの分離

• ノードへ直接アクセスは不可能

• 業界標準のセキュリティとデータ保護の認証をサポートStorage

SQL

Transactions

Caching

Amazon S3

Application

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

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


レプリケーション

可用性データベースノードに不具合が発生すると、自動的に検知され置換

不具合が発生したプロセスは自動的に検知され、再起動

フェイルオーバーの必要がある場合、レプリカは自動的にプライマリへ昇格

フェイルオーバー順を指定可能

AZ 1 AZ 3AZ 2

PrimaryNodePrimaryNode

PrimaryDatabase

Node

PrimaryNodePrimaryNodeRead

Replica

PrimaryNodePrimaryNodeRead

Replica

Database and

Instance Monitoring

パフォーマンスリードレプリカを利用して、参照のスケールアウトが可能

リーダーエンドポイントを利用して自動的にバランシング可能


Amazon Aurora Continuous Backup

セグメントスナップショットログレコード

リカバリポイント

Segment 1

Segment 2

Segment 3

Time

• 各セグメントごとに Amazon S3 へ継続的なスナップショットを並列に取得

• Amazon Auroraが使用しているディスクの仕組みによりパフォーマンスへ影響を与えない

• リストア時、並列非同期に適切なセグメントのスナップショットとログを取得し、

ストレージへ適用


高速なデータ修復

既存のデータベース

最後のチェックポイントからログを適用していく

PostgreSQL ではシングルスレッドなため適用完了までの時間が増加

Amazon Aurora

Disk readの一環として、オンデマンドでredo logの適用を行う

並列、分散、非同期で行われる

Checkpointed Data WAL

T0 でクラッシュが発生すると最後のチェックポイントからのログを適用する必要がある

T0 T0

T0 でクラッシュが発生するとredoを並列で分散して非同期でログの適用を行う


高速でより予測可能なフェイルオーバー時間

ApprunningFailure detection DNS propagation

Recovery Recovery

DBfailure

Amazon RDS for PostgreSQL is good: failover times of ~60 seconds

Failure detection DNS propagation

Recovery

DB

failure

Amazon Aurora is better:failover times < 30 seconds

1 5 - 2 0 s e c

3 - 1 0 s e c

Replica-Aware App Running

AppRunning


パフォーマンス


Amazon Aurora with PostgreSQL Compatibility

Performance vs. PostgreSQL

Report from the Field on the Aurora PostgreSQL- Performance Result from SRA OSS

https://www.youtube.com/watch?v=6kDP-95YJKU



このセッションで何をお話しているか

• Aurora/RDS for PostgerSQLに対して pgbench を実行

• データロードについて(pgbench -i)

ロード、Vacuum, Indexing の観点でそれぞれAurora がより短時間で完了

特に Vacuum については大きな差

• SELECT/UPDATE/INSERT(TPC-B を想定したワークロード)

• 同時接続数が多くなるほど、Aurora がより高いスループットを発揮

• 加えて、高速かつ一貫したスループットを発揮


Amazon Aurora with PostgreSQL Compatibility

Performance vs. PostgreSQL

Deep Dive on the Amazon Aurora PostgreSQL-compatible Edition (DAT402)https://www.youtube.com/watch?v=6kDP-95YJKU



ベンチマーク環境PostgreSQL – Single AZ, no backup Amazon Aurora

EBS EBS EBS

60,000 total IOPS

AZ 1 AZ 2 AZ 3

Amazon S3

r4.16xlarge databaseinstance

Storage Node

Storage Node

Storage Node

Storage Node

Storage Node

Storage Node

r4.8xlarge client driver

r4.16xlarge databaseinstance



Amazon S3Amazon RDS

r4.16xlarge30,000 iops

Amazon Aurora PostgreSQL Performance Benchmarking Guide：https://d1.awsstatic.com/product-marketing/Aurora/RDS_Aurora_PostgreSQL_Performance_Assessment_Benchmarking_V1-0.pdf

https://d1.awsstatic.com/product-marketing/Aurora/RDS_Aurora_PostgreSQL_Performance_Assessment_Benchmarking_V1-0.pdf


より高速なレスポンスタイム

書き込みで重たいワークロード下のレスポンスタイム

- PostgreSQL の2倍以上短く、スパイクが99%削減

0.00

100.00

200.00

300.00

400.00

500.00

600.00

700.00

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Response t

ime,

ms

Minutes

SYSBENCH RESPONSE TIME (p95), 30 GiB, 1024 CLIENTS

PostgreSQL (Single AZ, No Backup) Amazon Aurora (Three AZs, Continuous Backup)


Amazon Aurora Reduced Recovery Time Up to 97%

ストレージシステムのリカバリが高速に実行可能

3 GiB redorecovered in 19 seconds



Amazon Aurora has no redo.Recovered in 3 seconds while maintaining signficantly greater throughput.

0

20

40

60

80

100

120

140

160

0 20000 40000 60000 80000 100000 120000 140000

Reco

ve

ry t

ime

in

se

co

nd

s (

less is b

ett

er)

writes / second (more is better)

Recovery t ime f rom crash under load

Bubble size represents redo log which must be recovered

As PostgreSQL throughput

goes up, so does log size

and crash recovery time.


ベンチマークから見る Aurora の特徴と使い所

• 高いクエリ並列度、データサイズが大きい環境で性能を発揮

コネクション数、データ量が多いワークロードで高スループット、安定した性能を発揮

• 並列度が活かせる場面でより性能的な優位性を発揮

リカバリ、Vacuum などの処理がより高速に

• 高い可用性・堅牢性を兼ね備えつつ、高スループットを実現

Aurora ストレージは 3AZで、6つのコピーを保持


I/Oを減らす

ネットワークパケットを最小限にする

結果をキャッシュしておく

データベースエンジンをオフロードする

DO LESS WORK

非同期で処理する

レイテンシーの通り道を減らす

ロックフリーなデータ構造を使う

バッチ操作を同時に行う

BE MORE EFFICIENT

データベースは I/O が全て

ネットワーク接続したストレージは PACKETS/SECOND が全て

高スループットの処理にコンテキストスイッチは許されない

性能向上のために行っていること


IO traffic in Amazon RDS for PostgreSQL

EBSに書き込み – EBSがミラーへ複製し、両方終了後ack

スタンバイインスタンス側のEBSに書き込み

IO FLOW

ステップ1, 3, 5はシーケンシャルかつ同期

それによりレイテンシーもパフォーマンスのゆらぎも増加

各ユーザー操作には様々な書き込みタイプがある

書き込み破損を避けるためにデータブロックを2回書く必要性

OBSERVATIONS

RDS FOR POSTGRESQL WITH MULTI-AZ

EBS mirrorEBS mirror

AZ 1 AZ 2

Amazon S3

EBS

Amazon Elastic Block Store

(EBS)

Primary Database

Node

Standby Database

Node

1

2

3

4

5

WAL DATA COMMIT LOG & FILES

TYPE OF W RITE


IO traffic in Aurora (データベース)

AZ 1 AZ 3

Primary

instance

Amazon S3

AZ 2

Replica

instance

AMAZON AURORA

ASYNC

4/6 QUORUM

DISTRIBUTED

WRITES

IO FLOW

REDOログレコードのみ書き込む; 全てのステップは非同期

データブロックは書かない(チェックポイント, キャッシュ置換時)

6倍のログ書き込みだが, 1/9のネットワークトラフィック

ネットワークとストレージのレイテンシー異常時の耐性

OBSERVATIONS

PERFORMANCE

REDOログレコードをまとめる – 完全にLSN順に並ぶ

適切なセグメントに分割する – 部分ごとに並ぶ

ストレージノードへまとめて書き込む

DATAAMAZON AURORA + WAL LOG COMMIT LOG & FILESWAL

TYPE OF W RITE

write-only もしくは、read/write が混在するワークロードにて、PostgreSQL のコミュニティエディションに比べて、2倍以上の性能を発揮


非同期グループコミット

Read

Write

Commit

Read

Read

T1

Commit (T1)

Commit (T2)

Commit (T3)

LSN 10

LSN 12

LSN 22

LSN 50

LSN 30

LSN 34

LSN 41

LSN 47

LSN 20

LSN 49

Commit (T4)

Commit (T5)

Commit (T6)

Commit (T7)

Commit (T8)

LSN GROWTHDurable LSN at head-node

COMMIT QUEUEPending commits in LSN order

TIME

GROUP

COMMIT

TRANSACTIONS

Read

Write

Commit

Read

Read

T1

Read

Write

Commit

Read

Read

Tn

TRADITIONAL APPROACHAMAZON AURORA

ディスクへ書き込むためののログバッファを管理バッファが一杯になるか書き込み待ち時間を超過すると書き込みを実行書き込み頻度が少ない場合は最初の書き込みが遅くなる

最初の書き込みと同時にI/Oリクエストを実行。書き込みが実行されるまでバッファを埋める

6つの内4つのストレージノードからACKが返ってきた時点で堅牢性のある書き込みが完了


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を検証


IO traffic in Aurora Replicas

PAGE CACHEUPDATE

Aurora Master

30% Read

70% Write

Aurora Replica

100% New Reads

Shared Multi-AZ Storage

PostgreSQL Master

30% Read

70% Write

PostgreSQL Replica

30% New Reads

70% Write

シングルプロセスでWAL を適用

Data Volume Data Volume

Physical: WAL をレプリカに送信

• 書き込みは各インスタンス同様に実施

• ストレージはそれぞれ独立(Shared Nothing)

Physical: ページキャッシュをレプリカに送信

• ストレージは共有。レプリカ側でストレージへの書き込みは起こらない

• ページキャッシュが適用

PostgreSQL READ SCALING Amazon Aurora READ SCALING


キャッシュレイヤの分離• キャッシュレイヤは通常、データベース

プロセス内にある – データベースがダウンした場合、消去される

• キャッシュをデータベースプロセス外に移動

• データベースプロセスのリスタートが発生してもキャッシュが残った状態を維持可能

• サービスにすぐデータベースを戻すことが出来る

• 高速なクラッシュリカバリ + 保持可能なキャッシュ = DB障害から高速に復帰可能

SQL

Transactions

Caching

SQL

Transactions

Caching

SQL

Transactions

Caching

キャッシュプロセスをDBプロセス外におくことでDBプロセスの再起動でもキャッシュが残る


管理・運用


スケーリング

• スケールアップ

• スケールアウト

リードレプリカ：最大15台まで

インスタンスクラス vCPU メモリ (GiB)

db.r4.large 2 15.25

db.r4.xlarge 4 30.5

db.r4.2xlarge 8 61

db.r4.4xlarge 16 122




Aurora のモニタリング

• CloudWatch 詳細：

http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Aurora.Monitoring.html#Aurora.AuroraPostgreSQL.Monitoring.Metrics

• 拡張モニタリング詳細：

http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html

• Performance Insight(プレビュー)

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

http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Aurora.Monitoring.html#Aurora.AuroraPostgreSQL.Monitoring.Metrics

http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html

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


拡張モニタリング

• OS レベルの監視情報を提供


Performance Insights

Intuitive tuning

for managed cloud databases


Performance Insight へのアクセス

以下の赤枠のいずれかをクリック


Performance Insights dashboardAverage Active Sessions グラフ Top Load Items テーブル


Average Active Sessions グラフ

• データベースへのワークロードとキャパシティを表示

• データベースへの負荷を以下の観点でリアルタイムに表示

Waits(待機状態)

SQL

アクセス元ホスト

データベースユーザー

• 各観点のドリルダウン

• 時間軸の調整

• 最大CPUラインとの比較


毎秒ごとのサンプリング

標準的なクエリ(しばしばグラフに表示)

高速なクエリ(グラフには滅多に現れない)

スロークエリ(確実にグラフで確認可能)

User 1

User 2

User 3

Time


Active Session State

CPU IO Wait

idleidle idle idleQuery 1 Query 2 Query 3

Time


分析の観点の一例

• 最大 CPU ラインとの比較最大 CPU ラインをよく超えており、待機状態がCPUの場合

Max_connections の調整

該当クエリのチューニング

インスタンスタイプのスケールアップ

• 最大 CPU ラインを超えていないにも関わらず、システムにボトルネックが発生している場合は？

単一の重たいクエリが発生している可能性単一のセッションで重たいクエリをドリルダウンで探索

テーブルなどへのアクセス競合が発生している可能性

データベース以外の部分で問題が発生している可能性


移行


RDS for PostgreSQL からのマイグレーション

• RDSスナップショットから Aurora を作成可能

マネジメントコンソールで数クリックの操作で移行

スナップショットは PostgreSQL 9.6.1以降のものが必要


マイグレーション時の注意

• 以下の前提条件を満たしていることスナップショットは、PostgreSQL 9.6.1以降の

インスタンスから作成されていること RDS の機能で暗号化されていないこと

• RDS for PostgreSQL の監視メトリクスが一部異なる• RDS for PostgreSQL の Parameter Group で設定できる

項目やデフォルト値が一部異なる checkpoint_timeout, effective_cache_size など移行時には Parameter Group の指定ができないので、必要に応じて

Aurora インスタンス作成後に変更


レプリケーション

• 以下のような場合は、AWS Database Migration Service（DMS）を利用した移行も検討

よりダウンタイムを短くしたい

RDS for PostgreSQL 以外のデータベースからの移行

特徴(https://aws.amazon.com/jp/dms/)

• マネージド型データベース移行サービス

• 異機種RDB間のデータ移行をサポート

• 継続的なレプリケーション（CDC）機能

https://aws.amazon.com/jp/dms/


まとめ

• クラウド時代に Amazon が再設計したRDBMS

スケーラブル、高い堅牢性、可用性をもつ設計

PostgreSQL 9.6 と互換性があり既存資産を流用しやすい

• 高いクエリ並列度、データサイズが大きい環境で性能を発揮

コネクション数、データ量が多いワークロードでより優位性を発揮

• 高可用性・実環境での性能向上を実現するための多くのチャレンジを継続して実行中


参考資料Amazon Aurora SIGMOD論文(英語)

• http://www.allthingsdistributed.com/files/p1041-verbitski.pdf

Amazon Auroraストレージエンジン• http://aws.typepad.com/sajp/2017/02/introducing-the-aurora-storage-engine.html

Amazon Auroraストレージのquorumに関する実装について• https://aws.amazon.com/jp/blogs/news/amazon-aurora-under-the-hood-quorum-and-correlated-failure/• https://aws.amazon.com/jp/blogs/news/amazon-aurora-under-the-hood-quorum-reads-and-mutating-state/• https://aws.amazon.com/jp/blogs/news/amazon-aurora-under-the-hood-reducing-costs-using-quorum-sets/• https://aws.amazon.com/jp/blogs/news/amazon-aurora-under-the-hood-quorum-membership/

re:invent 2017 Aurora with PostgreSQL Compatibility 関連セッション• Deep Dive on the Amazon Aurora PostgreSQL-compatible Edition：

https://www.youtube.com/watch?v=nd_BT_H-vsM• Report from the Field on Amazon Aurora Performance：

https://www.youtube.com/watch?v=6kDP-95YJKU• How Verizon is Adopting the Amazon Aurora PostgreSQL-compatible：

https://www.youtube.com/watch?v=tb6s_sSrXPY

AWS Database Blog (Amazon Aurora)• https://aws.amazon.com/blogs/database/category/aurora/

http://www.allthingsdistributed.com/files/p1041-verbitski.pdf

http://aws.typepad.com/sajp/2017/02/introducing-the-aurora-storage-engine.html

https://aws.amazon.com/jp/blogs/news/amazon-aurora-under-the-hood-quorum-and-correlated-failure/

https://aws.amazon.com/jp/blogs/news/amazon-aurora-under-the-hood-quorum-reads-and-mutating-state/

https://aws.amazon.com/jp/blogs/news/amazon-aurora-under-the-hood-reducing-costs-using-quorum-sets/

https://aws.amazon.com/jp/blogs/news/amazon-aurora-under-the-hood-quorum-membership/

https://www.youtube.com/watch?v=nd_BT_H-vsM


https://www.youtube.com/watch?v=tb6s_sSrXPY

https://aws.amazon.com/blogs/database/category/aurora/


オンラインセミナー資料の配置場所

AWS クラウドサービス活用資料集• http://aws.amazon.com/jp/aws-jp-introduction/

AWS Solutions Architect ブログ• 最新の情報、セミナー中の Q&A 等が掲載されています

• http://aws.typepad.com/sajp/

http://aws.amazon.com/jp/aws-jp-introduction/

http://aws.typepad.com/sajp/

AWS Black Belt Online Seminar Amazon Aurora with PostgreSQL … · 2018-03-23 · AWS Black Belt...

Documents

Transcript of AWS Black Belt Online Seminar Amazon Aurora with PostgreSQL … · 2018-03-23 · AWS Black Belt...