【レポート】 Amazon Aurora for PostgreSQL アーキテクチャ・特長と移行 #AWSSummit

こんにちは、菊池です。

現在開催中のAWS Summit Tokyo、当エントリでは2017年05月31日に行われたAWS Techトラック1：Amazon Aurora for PostgreSQL アーキテクチャ・特長と移行についてレポートします。

昨年末のre:Invent 2016で発表された、Aurora for PostgreSQLの最新情報が満載のセッションでした。

• 関連：【速報】Amazon Aurora with PostgreSQL compatibility が発表されました！ #reinvent

レポート

当セッションの登壇者及び概要は以下の通りです。

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の利便性が向上します。