AWS Black Belt Online Seminar 2017 Amazon Aurora with PostgreSQL Compatibility

© 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/

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がクラウド時代に再設計したデータベース

P o s t g r e S Q L F o r A u r o r a
2017/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 Compatiblity

• 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_PostgreS
QL.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 のスナップショットから移行可能

アーキテクチャ

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

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の追加・削除
は自動で行われる
Aurora 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/

ストレージノードクラスタ
• Protection Group毎に6つのストレージノードを使用
• 各ログレコードはLog Sequence Number(LSN)を持っており不足・重複
しているレコードを判別可能
 不足している場合はストレージノード間でゴシッププロトコルを利用し補完
詳細： 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

レプリケーション
可用性
データベースノードに不具合が発生すると、
自動的に検知され置換
不具合が発生したプロセスは自動的に検知
され、再起動
フェイルオーバーの必要がある場合、レプ
リカは自動的にプライマリへ昇格
フェイルオーバー順を指定可能
AZ 1 AZ 3AZ 2
Primary
Node
Primary
Node
Primary
Database
Node
Primary
Node
Primary
Node
Read
Replica
Primary
Node
Primary
Node
Read
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
を並列で分散して非同期でログの適用を行う

高速でより予測可能なフェイルオーバー時間
App
runningFailure detection DNS propagation
Recovery Recovery
DB
failure
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
App
Running

パフォーマンス

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)

ベンチマーク環境
PostgreSQL – Single AZ, no backup Amazon Aurora
EBS EBS EBS
60,000 total IOPS
AZ 1 AZ 2 AZ 3
Amazon S3
r4.16xlarg
e database
instance
Storage
Node
Storage
Node
Storage
Node
Storage
Node
Storage
Node
Storage
Node
r4.8xlarge
client
driver
r4.16xlarg
e database
instance
r4.8xlarge
client
driver
r4.8xlarge
client
driver
Amazon S3
Amazon RDS
r4.16xlarge
30,000 iops
Amazon Aurora PostgreSQL Performance Benchmarking Guide：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
Responsetime,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 redo
recovered in 19 seconds
10 GiB redo
30 GiB redo
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
Recoverytimeinseconds(lessisbetter)
writes / second (more is better)
Recovery time from 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
T Y P E O F W RIT E

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
T Y P E O F W RIT E
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 GROWTH
Durable LSN at head-node
COMMIT QUEUE
Pending commits in LSN order
TIME
GROUP
COMMIT
TRANSACTIONS
Read
Write
Commit
Read
Read
T1
Read
Write
Commit
Read
Read
Tn
TRADITIONAL APPROACH
AMAZON 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 CACHE
UPDATE
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/Auror
a.Monitoring.html#Aurora.AuroraPostgreSQL.Monitoring.Metrics
• 拡張モニタリング
 詳細：
http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGui
de/USER_Monitoring.OS.html
• Performance Insight(プレビュー)
 http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/U
serGuide/USER_PerfInsights.html

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

Performance
Insights
Intuitive tuning
for managed cloud databases

Performance Insight へのアクセス
以下の赤枠のいずれかをクリック

Performance Insights dashboard
Average 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）機能

まとめ
• クラウド時代に 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：
• 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/

オンラインセミナー資料の配置場所
AWS クラウドサービス活用資料集
• http://aws.amazon.com/jp/aws-jp-introduction/
AWS Solutions Architect ブログ
• 最新の情報、セミナー中の Q&A 等が掲載されています
• http://aws.typepad.com/sajp/

AWS Black Belt Online Seminar 2017 Amazon Aurora with PostgreSQL Compatibility

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to AWS Black Belt Online Seminar 2017 Amazon Aurora with PostgreSQL Compatibility

Similar to AWS Black Belt Online Seminar 2017 Amazon Aurora with PostgreSQL Compatibility (20)

More from Amazon Web Services Japan

More from Amazon Web Services Japan (20)

Recently uploaded

Recently uploaded (9)

AWS Black Belt Online Seminar 2017 Amazon Aurora with PostgreSQL Compatibility