【レポート】Amazon Aurora with PostgreSQL Compatibility における運用設計のファーストステップ #AWSSummit

2019.06.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、崔です。
AWS Summit Tokyo 2019 3日目のB3-05のセッションである「Amazon Aurora with PostgreSQL Compatibility における運用設計のファーストステップ」のレポートをお届けします。

Amazon Aurora はクラウドに適したデータベースとは何かを1から考え実装された新しいデータベースエンジンであり、Amazon Relational Database Service (RDS) を使ったマネージド型サービスです。そのため、パッチ適用、バックアップといった時間のかかる管理タスクを自動化し、ユーザが必要な運用タスクにフォーカスすることができます。本講演では、皆様に意識していただきたい運用上のポイントについてご紹介したいと思います。

スピーカー

アマゾン ウェブ サービス ジャパン株式会社
技術統括本部
ソリューションアーキテクト 江川 大地 様

Amazon Aurora

  • 優れた性能と拡張性
  • 高可用性と耐久性
  • 高い安全性
  • フルマネージド

Amazon Auroraのアーキテクチャ

  • クラスターボリューム
    • 3つのAZにまたがって6つのコピーを持つ
  • プライマリインスタンス(Writer)と、Aurora レプリカ(Reader)

Auroraストレージ

  • SSDを使用したシームレスにスケールするストレージ
    • 10GBから64TBまでシームレスに自動でスケールアップ
    • 実際に使った分だけ課金
  • 標準で高可用性を実現
    • クォーラムシステムの採用(4/6クォーラムを採用)
    • 継続的にS3へ増分バックアップ

PostgreSQL Compatibility

  • PostgreSQL 9.6, 10 との強い互換性
  • RDS for PostgreSQLで利用可能な拡張モジュールを利用可能
    • PL/pgSQL, pgcypto, PostGIS, pg_hint_plan, orafceなど
  • RDS for PostgreSQLのスナップショットから移行可能

運用上おさえておきたいポイント

高可用性設計

  • Aurora レプリカをマルチAZに配置可能
    • 複数のAZにレプリカを配置して冗長化(最大15台)
    • プライマリインスタンスに障害が発生した場合、自動的にレプリカへフェイルオーバー
    • どのレプリカを昇格させるかの優先度を設定可能
      • プライマリと同じAZのレプリカを昇格させたい
      • 集計処理を行っているレプリカは昇格させたくない
  • ストレージは標準で高可用性を実現

バックアップとPITR

  • 自動バックアップが常に有効
    • S3へ継続的かつ自動的に増分バックアップ
    • パフォーマンスへの影響はない
    • バックアップの保持期間のみ指定
  • データの復元とPITR
    • 5分前からバックアップ保持期間までの任意の位置に秒単位で復元可能
    • 最新の復元可能時刻はマネジメントコンソールで確認可能

監視(CloudWatch)

  • 各種メトリクスを60秒間隔で取得・確認可能
    • ホスト層のメトリクス
      • CPU使用率
      • メモリ使用量、等
    • ストレージのメトリクス
      • IOPS
      • Queue Depth、等
    • データベース関連のメトリクス
      • DB接続数
      • デッドロックの回数、等

拡張モニタリングによるOSレベルの詳細監視

  • OSレベルの監視情報を提供
    • OSメトリクスを1〜60秒間隔で取得
    • プロセスリスト

Performance Insightsによるワークロード監視

  • データベースへのワークロード、キャパシティ、統計情報を表示
  • データベースへの負荷をリアルタイムに表示
  • 主要な機能
    • データベースロード
    • カウンターメトリクス
    • Top N ディメンション
    • 待機、SQL、ホスト、ユーザ

イベント通知(Event Subscriptions)

  • RDSで発生した40種類以上のイベントをAmazon SNS経由でPush通知
    • シャットダウン、再起動、フェイルオーバー、設定変更、メンテナンス開始/終了等
  • アプリケーションと組み合わた自動化やログ保存が容易に

ログ設定

  • 障害時の切り分けなどのためにログ記録が重要
  • 以下のパラメータについて事前に確認
    • log_statement:どのSQL文をログに記録するか設定
    • log_min_duration_statement:設定したミリ秒以上の時間がかかった場合に、そのSQLと所要時間を記録
    • log_min_messages:どのメッセージ階層をサーバログに書き込むか設定
    • rds.log_retention_period:システムログの保持期間を設定
    • スロークエリの分析などのために、拡張モジュール:auto_explainの利用も検討

監査ログ

  • 以下のパラメータを有効にすることでログ出力が可能
    • log_statement
    • rds.force_admin_logging_level:rdsadminによるアクションの記録
  • pgaudit(拡張モジュール)の利用
    • ファイングレイン監査の実施が可能:特定のテーブル、列、操作のみログ出力することにより、ログ出力にかかる負荷を制御可能
    • メタデータの出力により、ログをより見やすい出力形式へ

Vacuum

  • 通常のPostgreSQLと同様に検討
    • autovacuumの利用
    • パラメータ設計
      • maintenance_work_mem/autovacuum_work_mem
      • autovacuum_vacuum_scale_factor/autovacuum_vacuum_threshold
      • 遅延 Vacuum関連パラメータ
    • テーブルレベルのパラメータの利用
  • autovacuumのログ
    • rds.force_autovacuum_logging_level:autovacuumワーカーによるオペレーションを記録
    • log_autovacuum_min_duration:指定した値以上の時間がかかった場合にrds.force.autovacuum_logging_levelで指定されたログを出力(5000を指定すると5秒以上のアクティビティをログへ出力)

ソフトウェアメンテナス

  • メンテナスウィンドウで指定した曜日・時間帯に自動実施
  • 安定性・堅牢性に関わるソフトウェアパッチを自動
  • メンテナスは数ヶ月に一度の頻度で発生(毎週必ずではない)
  • 指定した時間帯の数分間で実施(メンテナンス内容に依存)
  • Tips
    • トラフィックが少ない曜日・時間帯をメンテナンスウィンドウに指定しておく
    • イベント通知を運用監視に組み込んでおく
    • describe-db-instancesコマンドなどでメンテナンスの有無を定期的に確認

マイナーバージョンアップグレード

  • 簡単な操作でアップグレードが可能
    • 手動か自動で実施可能
    • いずれの場合もダウンタイムが発生するため、本番環境では実施タイミングを考慮の上、手動での実施を推奨
  • 注意事項
    • アップグレードされたインスタンスを前のバージョンに戻すことはできない。切り戻す必要がある場合は、スナップショットから復元
    • 拡張モジュールのアップグレードは、ユーザ自身で行う必要がある

最新機能を活用した運用効率化とTips

Aurora PostgreSQL Compatibility

  • 新しいメジャーバージョン 10系をリリース
  • 主な機能
    • ネイティブパーティション(宣言的パーティション)
    • パラレルクエリ強化(パラレルクエリに対応するScan方式、Join方式の追加)
    • postgres_fdw強化(リモートサーバでの集約に対応)

PostgreSQL ロジカルレプリケーションをサポート

  • PostgreSQLのロジカルレプリケーションでデータの同期が可能
    • 移行元のPostgreSQLからRDS/Auroraへ同期することで移行のダウンタイムを短縮可能
    • Aurora PostgreSQLから外部のPostgreSQLへデータを複製可能
    • 基本的な手順/注意点はマニュアルを参照
      • DDLやシーケンスなどのレプリケーションは出来ないなど

Amazon Aurora クラスターの停止および起動をサポート

  • Auroraクラスターを停止/起動可能に
  • クラスターを停止すると、プライマリインスタンスと全てのレプリカインスタンスが停止
  • 停止するとインスタンス料金は課金されなくなるが、ストレージ料金は課金される
  • 1日に最大7日間まで停止可能。7日後に自動起動。

カスタムエンドポイント

  • Auroraクラスター内のどのインスタンスを含めるかをユーザが指定可能なエンドポイントが作成可能に
  • オンラインクエリー用のリードレプリカと分析クエリー用のリードレプリカを分離することが可能に

Database clonig

  • ストレージコストを増やすことなくデータベースのコピーを作成
    • データをコピーするわけではないため、クローンの作成はほぼ即座に完了
    • データのコピーはオリジナルボリュームとコピー先のボリュームのデータが異なる場合の書き込み時のみ発生
  • ユースケース
    • 本番データを使用しテスト
    • データベースの再構成
    • 本番システムに影響を及ばさずに分析目的で特定時点のスナップショットを保存

厳密なパスワード管理によるユーザ制御

  • ロールに対するパスワードを誰が変更可能かを制御可能に
    • 利用の仕方
      • rds.restrict_password_commands = 1 に設定(パラメータグループ)
      • rds_passwordロールの付与(本ロールを持つメンバのみパスワード変更可能)
    • 注意点
      • Aurora PostgreSQL 10.6以降で利用可能
      • rds_superuserはrds_passwordロールを常に持つ

Query Plan Managementによる実行計画管理

  • 主な機能
    • 手動/自動でのプランキャプチャー
    • プランの測定/比較
    • プランの承認/拒否
    • ベースラインの確立
    • プランの修正
  • サポートバージョン
    • Aurora PostgreSQL 2.1.0以上
    • PL/pgSQLは未サポート

Query Plan Managementのユースケース

  • 性能低下を防止する事前予防
    • 手動/自動のキャプチャでプランを取得
    • エクスポート/インポート可能
    • ベースラインのプランを強制
    • 新しいプランの効率性を分析
  • 性能低下を検出し修復する事後対応
    • ベースラインで固定
    • パフォーマンス低下を監視
    • ベースラインを拒否し、別の承認済みプランを使用することも可能
    • pg_hint_plan拡張でプランを修正することも可能

Database Activity Streamによるリアルタイム監視

  • データベースアクティビティをニアリアルタイムでAmazon Kinesis Data Streamへプッシュして監視可能に
    • SQLコマンド、接続情報などを送信
    • DBアクティビティ情報は暗号化

Cluster Cache Managementによる高速リカバリ

  • フェイルオーバー後のコールドキャッシュを回避
  • データベースをフェイルオーバーしてキャッシュをウォームアップするにはしばらく時間がかかる
  • フェイルオーバーの優先度を0に設定する
  • レプリカがプライマリインスタンスのキャッシュを同期する

まとめ

  • マネージドサービスの特性を活かして、運用を省力化可能
  • Auroraの最新機能を活用して、運用効率を向上

感想

Amazon Aurora PostgreSQLの話がテンコ盛りでした。商用データベースからの移行先として積極的に検討していきたいですね!