この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、菊池です。
現在開催中のAWS Summit Tokyo、当エントリでは2017年05月31日に行われたAWS Techトラック1：Amazon Aurora for PostgreSQL アーキテクチャ・特長と移行についてレポートします。
昨年末のre:Invent 2016で発表された、Aurora for PostgreSQLの最新情報が満載のセッションでした。
レポート
当セッションの登壇者及び概要は以下の通りです。
スピーカー：
Mark Porter氏
DBS Aurora - PostgreSQL General Manager, AWS RDS & DMS
Amazon Web Services, Inc.
Mark Porter氏
DBS Aurora - PostgreSQL General Manager, AWS RDS & DMS
Amazon Web Services, Inc.
セッション概要：
Amazon Aurora は MySQL 互換と PostgreSQL 互換の 2 つのエンジンをサポートしています。本セッションでは、両エンジンに共通のストレージ部分のアーキテクチャ、ならびに PostgreSQL 互換エンジンについて、開発責任者から解説を行います。また、商用データベースなどから Aurora へ移行する際のポイントについてもご説明します。
Agenda
- なぜAmazon Auroraを作ったか
- なぜAmazon Aurora with PostgreSQL compatibilityを追加するのか
- Amazon Aurora with PostgreSQL compatibilityの堅牢性
- Amazon Aurora with PostgreSQL compatibilityのパフォーマンス
- Amazon Aurora with PostgreSQL compatibilityのロードマップ
なぜAmazon Auroraを作ったか
- RDBはスケールが難しい
- 複数の昨日レイヤがモニリシックなスタック
- スケールのアプローチ
- シャード
- シェアードナッシング
- シェアードストレージ（例えばOracle RAC）
- もう一度考える
- スタックの分割
- スケールできる
- 自律的修復
- サービス指向アーキテクチャをデータベースに当てはめる
- 各レイヤを独立してスケールできる
- Auroraは進化を続けている
- 最初はMySQL compatibility
- PostgreSQL compatibilityを追加
なぜAmazon Aurora with PostgreSQL compatibilityを追加するか
- 第一にカスタマーの声・要望
- 第二にPostgreSQLのプロダクトのよさ
- OSS
- 20年の歴史
- そのままで高性能
- 標準SQLとの互換性
- 12の言語のストアドプロシージャをサポート
- Oracleとの互換性が最も高いOSS DB
- OracleからのSCTの変換ターゲットはPostgreSQLが最も多い
Aurora for PostgreSQL
- PostgreSQLと比べ2倍の性能
- 30秒のフェイルオーバ
- ９.６との100%互換性
- クラウドサービスとの連携：KMS/IAM/DMS
Aurora for PostgreSQLの可用性と堅牢性
- スケールアウト可能で分散した、ログ構造ストレージ
- Aurora Storage Engine 3つのAZ/6つの複製
- S3へのバックアップ
- ストレージエンジンの耐障害性
- なにが障害を引き起こすか
- ディスク
- マシーン
- ネットワーク
- なにが障害を引き起こすか
- レプリカ
- 可用性
- 継続的なバックアップ
- S3へ継続的なバックアップ（バックアップウィンドウなし）
- 高速で予測可能なフェイルオーバー時間（30秒未満）
- ケースによっては5秒未満も達成
Aurora for PostgreSQLのパフォーマンス
- パフォーマンス比較（vs PostgreSQL）
- PgBenchで2倍以上高速な結果
- SysBenchで2-3倍
- 120,000/sの書き込み
- データロードも3倍高速（PgBenchの初期化作業：バキュームも高速）
- レスポンスタイムが2倍以上高速、10倍以上安定・安定したスループット
- データベースサイズが大きいケースでは3倍高速な結果に
- 最大85倍高速なリカバリ（ログストラクチャード・ストレージシステムによりほぞ即座に復旧）
実際のアプリケーションでもこのような結果が出るように協力していきたい
- パフォーマンスアーキテクチャ
- 性能向上のために
- I/Oを減らす
- NWパケットを最小限にする
- 非同期で処理する
- データベースはI/Oが全て
- ネットワークストレージはパケット/secが全て
- 高スループットにはCPU/メモリの最適化が全て
- 性能向上のために
- AuroraのI/Oトラフィックは全てのステップを非同期に実行
- AuroaレプリカのI/Oトラフィック
- ストレージは共有でスレーブ側で書き込まない
- サバイバル可能なキャッシュ
- キャッシュをデータベースプロセス外に移動
- データベースプロセスが再起動してもキャッシュを維持可能=パフォーマンスが劣化しない
Performance Insightsの紹介
- データベースで起きている事をはなかなかわからない
- データベースを見てもアプリケーションの状態はわからない
- 拡張モニタリング
- OS
- プロセス・スレッド
- 最小1秒の粒度
- データベースエンジンのパフォーマンスチューニング
- DBの中身が見える
- コンピューターの状態
- 個々のSQLの内訳・ロック・待ち状態
- 全てのDBエンジンに対応（Aurora for PostgreSQLでGAし、他のDBエンジンにも対応）
- それ以外にも
- ロック検出
- 実行計画
- APIアクセス
- 35日間のデータ保持
- 2017年中に全てのRDSエンジンに対応予定
ロードマップ
- ローンチ時には
- 高性能
- 使いやすさと互換性
- Auroraの全てのフィーチャー
- パフォーマンスインサイト
- PosgreSQLの全てのフィーチャー
- DMSインバウンド
- 堅牢性・可用性
- セキュア
まとめ
現在パブリックプレビュー中のAurora for PostgreSQLですが、非常に登場が楽しみになりました。
個人的に最も注目したのは、今後全てのRDSのエンジンに対応されるというPerformance Insightsです。これまでサードパーティのツールなどを利用する必要があった、個々のSQLの分析がサポートされます。パフォーマンスチューニングもサービスで実施可能となれば、ますますRDSの利便性が向上します。
6
