(レポート) AWS Online Tech Talks : PostgreSQL互換Amazon Aurora #awsblackbelt

はじめに

本記事は2017/01/16にオンラインで開催されたウェビナー(AWS Online Tech Talks)"PostgreSQL Compatibility for Amazon Aurora"のレポートです。

講師はAWSの以下の2名です

• Mark Porter(PostgreSQL互換AuroraのとRDS PostgreSQLのGeneral Manager)
• Kevin Jernigan(PostgreSQL互換AuroraのSr. Product Manager)

発表資料

Slideshare

YouTube

 

アジェンダ

• Why did we build Amazon Aurora?
• PostgreSQL Fast Facts
• Durability and Availability Architecture
• Performance Results vs. PostgreSQL
• Performance Architecture
• Announcing Performance Insights
• Feature Roadmap
• Preview Information & Questions

そもそもなんで Amazon Aurora を作ったの?

• Auroraは単にまた新しいRDBではない
• ゲームチェンジャー
• 過去5年に渡りAuroraを開発してきた
• Auroraのクラウドネイティブな特性を活かしてユーザーに価値を提供し続けている

古典的なリレーショナルデータベースはスケールしづらい

Oracle/PostgreSQL/MySQL/SQL Server のような古典的なRDBはSQL/Transactions/Caching/Logging/Storageが一体になったモノリシックスタック

• コンポーネント単位でスケールアップさせることはできない
• コンポーネント単位で独立して障害がおきることはない

NoSQLについて

• 近年NoSQLが活発なのは、データベースをスケールさせやすいから
• NoSQLの採用においてはトランザクションではなく、スケーラビリティが重要視されている

リレーショナルデータベースをスケールさせるアプローチ

過去数十年にわたりリレーショナルデータベースをスケールさせるために

• sharding(アプリケーションレイヤー)
• shared nothing(SQLレイヤー)
• shared disk(バッファーキャッシュとストレージレイヤー)

など様々なアプローチが取られてきた。

• 単純
• 安価
• スケールする

を同時に満たすようなものは存在しない

リレーショナルデータベースを再設計する

RDBを再発明するなら、どういうものがほしい?

各コンポーネントの柔軟性をもたせるためにスタックを分割させる

• スケールアウト
• セルフヒーリング
• 分散

を活かす

データベースにサービス指向アーキテクチャ(SOA)を適用

1. ロギング・ストレージレイヤーをマルチテナント、スケールアウト、DB最適化されたストレージサービスに移行
2. Auroraのストレージ・データベースサービスをAmazon EC2, Amazon VPC, Amazon DynamoDB, Amazon WRF, Amazon Route53 といったAWSサービスと連携させる
3. Auroraのストレージ・データベースサービスをマネージド・サービス化する

このようなアーキテクチャーのAmazon Auroraを2012年から開発している

Amazon Auroraをさらに良いものにする時期

• 2014年にMySQL互換なAuroraを発表
• ローンチ後の2日間で16の顧客とミーティング
• 14/16の顧客はMySQL互換だけでなくPostgreSQL互換も要望

PostgreSQL互換Amazon Aurora 速習

• OSS なデータベース
• Ingresプロジェクトから始まり20年以上アクティブに開発されている(Postgresss = Post Ingres)
• 柔軟なライセンス体系のおかげで利用しやすい
• 母体は企業ではなくNPOのファウンデーション
• デフォルト設定でも性能が良い
• Oracle/SQL Serverに近いトランザクションモデル
• オブジェクト指向。ANSI-SQL:2008 互換のためアプリの移行をしやすい
• geospatialなデータを活用できるPostGISエクステンションの存在
• 12言語のストアドプロシージャに対応。(Java, Perl, Python, Ruby, Tcl, C/C++, PL/pgSQLなど)PL/pgSQLはオラクルのそれに近い

PostgreSQL互換は具体的には?

• 最新のプロダクションバージョンであるPostgreSQL 9.6とAmazon Auroraのクラウド最適化したストレージを合体
• 耐久性：データは3 AZで6コピー作成
• 可用性：30秒未満にフェイルオーバー
• パフォーマンス：ベンチマークを取ると、スタンドアローンPostgreSQLに比べて1〜2倍
• レプリケーション：レプリカは15個まで作成可能。レプリカラグは軽微
• AWS Key Management Service (KMS) /AWS Identity and Access Management (IAM)と連携してクラウドネイティブなセキュリティ・暗号に対応
• Amazon RDSの一つとして提供
• AWS Database Migration Service/AWS Schema Conversion Toolと連携したデータ移行(in/out)に対応
• PostgreSQLとの完全互換性を維持

PostgreSQL互換Amazon Aurora:堅牢性と可用性

Auroraにより、DBAが多大な労力をはらってきた堅牢性と可用性の運用負荷が大幅に軽減される。

スケールアウト、分散、ログ構造化ストレージ

プライマリー/レプリカノードが3AZに分散した構成を例に考える

• DBノードからストレージレイヤーを分離して、共有ストレージを利用
• ただ単にストレージを分離しているわけでなく、ストレージはトランザクション処理も対応
• 各ストレージは独自に監視＆データ修復

Amazon Auroraストレージエンジン概要

AuroraのストレージレイヤーはMySQL互換とPostgreSQL互換で本質的に同じ

• 各データは3AZにまたがる6つのストレージノードに書き込まれる
• 書き込み量が多いように思えるが、実はそうではない
• Oracle RACでいうところのredo(log)レコードで効率的に書き込んでいる。

バックアップについて

• S3にバックアップ
• バックアップウィンドウの概念はない
• バックアップに伴う、パフォーマンス・インパクトもない

データ書き込みはquorumアルゴリズムを採用 書き込み成功までの時間は短い 一部のノードで書き込みに遅延が発生している場合、速やかに気づき、データベースのパフォーマンスが顕在化する前に修復する

ストレージサイズ

• ストレージは64TBまで自動拡張
• オンプレ/EC2やRDS PostgreSQLに比べて運用が楽。
• RDSのストレージは6TBの制限がある

耐障害性

• 4/6のwrite quoram
• 3/6のread quoram
• ストレージノード間は通信し、ストレージノードがオフラインになったり、データ修復が必要だったり、書き込みに失敗すると、リペアする

レプリカ

ストレージレイヤと同じくデータベースレイヤーも各ノードを個別に監視してリカバーする仕組みがある

• レプリカノードは15個まで作成可能
• ノード障害が検出されると、ノードが置き換えられる
• ノード内のプロセス障害が検出されると、プロセスはリサイクルされる
• マスターとのラグは10ms程度

継続バックアップ

• Auroraのストレージセグメントのサイズは10GB
• 各セグメントのスナップショットを継続的にS3にバックアップしている
• 新しいボリュームにリストラする場合、1スレッドでログを適用していくのではなく、何百者ストレージノードが並列してS3からログを取得し、適用する。

よりはやくて、より予測し易いフェイルオーバー

RDS PostgreSQL

• 障害検知後15-20秒でフェイルオーバー実行
• DNSプロパゲーションとリカバリを並列に実行
• 両方が終わると、アプリが復旧

Aurora PostgreSQL

• DNSプロパゲーションとリカバリを並列に実行
• リカバリはDNSプロパゲーションよりもずっと早く終る
• アプリがDNSに依存しないクラスターアウェアドライバーを利用していると、リカバリ完了後、すぐにアプリはシステム復旧する

RDS PostgreSQL と PostgreSQL互換Aurora の性能比率

どうやってこれらパフォーマンスを実現しているのか?

パフォーマンス改善の鍵

• IOを減らす
• ネットワークパケットを減らす
• データベースエンジンにオフロードする

Write IO トラフィック in Amazon RDS for PostgreSQL(マルチAZ)

各データは2AZに4コピーされる

• 可用性
• 耐障害性

に優れている。

 

• モノリシックなアーキテクチャー
• ステップ1,3,5でシーケンシャルな同期処理
• レイテンシーとジッターが増える

Auroraではジッターの幅が非常に小さい

Write IO Traffic in an Amazon Aurora 
Database Node

 

• ステップ 1:レコードを受け取って、インメモリーキューに突っ込む
• ステップ 2:レコードを永続化してacknowledgeする だけがレイテンシーに影響

残りのステップはバックグラウンドで非同期に行われる

Write IO Traffic in an Amazon Aurora 
Storage Node

• ネットワークジッターを軽減
• ストレージノード毎に効率よくS3にバックアップ
• ストレージはトランザクション対応
• 論理的には6倍の書き込み。まとめてトランザクション書き込みしているので、最大でネットワークトラフィックが1/9

 

AuroraレプリカのIOトラフィック

PostgreSQL

• redo(WAL)をマスターからレプリカーに転送
• マスターとレプリカはストレージが別のため、レプリカでもマスターと同じくWALを適用

Aurora

• redo(WAL)をマスターからレプリカーに転送
• マスターとレプリカはストレージは同じため、ディスクI/Oは発生せず
• ページキャッシュだけアップデート

サバイバルキャッシュにより、アプリケーション再起動後の立ち上がりがはやい

• 多くのデータベースではバッファーキャッシュはプロセスが再起動すると消える(コールドスタート)
• キャッシュがウォームになるまで何分もかかる
• Auroraでは再起動してもキャッシュは消えない

PostgreSQL互換Auroraで初めて搭載されるPerformance Insights 機能

第1歩: 拡張モニタリング

• 2016年にリリース
• OSメトリクスを取得 -プロセス・スレッド情報も取得

ネクストステップ: Performance Insights 機能 ← NEW

• データベースエンジンの動きをEnhanced Monitoringよりも深く知りたい
• 実際のワークロードをもとにチューニングのヒントをくれる
• DBAやDBチューニングの職人芸を代わりにやってくれる
• シングルペインでチューニングに必要なメトリクスを俯瞰できるダッシュボード
• ドリルダウンしながら、問題を解決
• データベースの運用だけでなくパフォーマンス・チューニングもマネージドで提供

Performance Insightsのワークロード測定以外について

• ロック検出
• 実行計画
• 追加料金無し
• Aurora(PostgreSQL)でまずリリース
• 2017年中に残りのDBエンジンにも展開予定

PostgreSQL 互換性のロードマップ

GA時に予定している機能一覧

参照

• https://www.youtube.com/watch?v=4jslgOGsBb4
• https://www.slideshare.net/AmazonWebServices/announcing-amazon-aurora-with-postgresql-compatibility-january-2017-aws-online-tech-talks