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

AWS Summit Tokyo 2019

#Amazon RDS

#Amazon Aurora

#PostgreSQL

#AWS

Yoichi Sai

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コマンドなどでメンテナンスの有無を定期的に確認

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

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