はじめてのAmazon RDS for PostgreSQL

2014/04/16関西PostgreSQL勉強会 with

Amazon Web Services

JAWS-UG大阪　 中田淳平

自己紹介

• 中田淳平

• Twitter:@j_nakada

• 株式会社Razest 取締役CTO-モバイルゲーム作ってます

• JAWS-UG大阪コアメンバー

• PHP,MySQL,AWS,Unity

• 好きなAWSサービス:RDS

JAWS-UG

• Japan AWS User Group• Amazon Web Servicesの利用促進や

情報交換のためのユーザーグループ

Agenda

• Amazon RDSとは

• Multi-AZ（HA構成）

• 自動バックアップとスナップショット

• 気をつけたいポイント

※本資料はSlideShareで公開します

Amazon RDSとは

• Amazon Relational Database Service– AWSのサービスの1つ– フルマネージドなクラウドRDB– 高い信頼性、可用性、拡張性が特徴

– 選択可能なDBエンジン

• MySQL• Oracle• SQLServer• PostgreSQL←New!

Amazon RDSとは

• 13のスペックから選択可能– 最小

メモリ:0.6GB　約5,500円/月

– 最大メモリ:244GB 約870,000円/月

• 起動後もスペックの変更可能– 停止時間3分ほど

• 次々と新スペックの追加、値下げ

$1=105円MultiAZ

東京リージョン2014/4現在

Amazon RDS作成デモ

• 最小スペック（Micro）インスタンス• PostgreSQL9.3.3• Multi-AZ• Disk容量：5GB• バックアップ期間：7日間• バックアップ開始時間：AM3時00分～3時30分

• 事前作成済み– セキュリティグループ– パラメーターグループ

Agenda

• Amazon RDSとは

• Multi-AZ（HA構成）

• 自動バックアップとスナップショット

• 気をつけたいポイント

Multi-AZ（HA構成）

• アクティブ／スタンバイ方式のHA構成

– 物理的に離れたデータセンターに配置

– PostgreSQLの同期レプリケーションではない

• 自動フェイルオーバー

– 障害発生時は自動でスタンバイに切り替わる

• スタンバイへの直接アクセスは不可

– スレーブのように参照用には使えない

Multi-AZのイメージ図

Zone　a Zone　b

アクティブ スタンバイ

②スタンバイへ書き込み

③書き込み完了

④書き込み完了

アプリケーション

①書き込み

※AWSの謎テクノロジーにより実現されているので内部の動作は上記の図と異なります概念としてとらえてください

スタンバイへのアクセス不可

Multi-AZの特徴

• 障害発生時は自動フェイルオーバーでスタンバイが昇格

– アプリケーションからは接続先の変更の必要なし

– フェイルオーバーに3分ほどかかる

• バックアップはスタンバイから取得される

– アプリケーションへのI/Oに影響を出さない

• 物理的に離れた拠点と同期してるので遅い

– Single-AZと比べて数分の1の応答速度（レイテンシ）

– 帯域は十分あるので、データの大きさは関係ない

本番運用ではMulti-AZ必須

Agenda

• Amazon RDSとは

• Multi-AZ（HA構成）

• 自動バックアップとスナップショット

• 気をつけたいポイント

そろそろDB起動したかな？

DBバックアップでのあるある

• システム構築には容量の見積もりが必要

– 見積もりが多すぎてコストの無駄

– n年後に容量オーバーで増設の手間が…

• バックアップからの復元（リストア）

– 復元手順書がない

– 復元してみたらバックアップデータが不完全

自動バックアップとスナップショット

• 自動バックアップ

– 1日1回のフルバックアップとトランザクションログ

– 保存期間中の任意の時間に復元可能

– 保存期間：～35日

• スナップショット

– 利用者が任意のタイミングで実行

– スナップショットをもとにDBインスタンス起動可能

– 保存期間：利用者が削除するまで

自動バックアップの役割

• 運用時の信頼性の確保

– バックアップファイルはAmazonS3に保存

– AmazonS3の堅牢性は99.999999999%– $0.095/月GB

• リストア作業の簡易化

– APIもしくは、AWS Management Consoleからバックアップ保存期間の任意のタイミングに復元可能（リストアは別DBとして起動する）

自動バックアップの注意点

• Single-AZだと1日1回のフルバックアップ中は　 ストレージI/Oが数分間中断される

– バックアップの時間帯は、ある程度は指定できる

– Multi-AZの利用で中断を回避できる

• インスタンスを削除すると自動バックアップ全削除

スナップショットの役割

• 好きなタイミングで取れる完全なバックアップ

– 明示的に削除するまで保存可能

– インスタンスを削除しても残る

• スナップショットから新規DBを起動できる

– 重たい集計処理や分析のために別DBを起動し、作業が終わったら削除することができる

スナップショットの注意点

• Single-AZだとスナップショット作成中は

ストレージI/Oが数分間中断される

– Multi-AZの利用で中断を回避できる

• スナップショットから元DBへ復元することはできない

– 新規DBインスタンスで起動して古いインスタンスを削除する等の対応が必要

バックアップまとめ

• 2種類のバックアップでDB管理者が幸せになれる

• 高可用性のためにはMulti-AZが必須

Agenda

• Amazon RDSとは

• Multi-AZ（HA構成）

• 自動バックアップとスナップショット

• 気をつけたいポイント

気をつけたいポイント

• PostgreSQL9系のレプリケーションは使えない

– 同期による可用性確保はMulti-AZ

– 参照負荷分散はKVS（memcached等）の併用

気をつけたいポイント

• RDSはDBへのエンドポイントのみが提供されておりSSH等のアクセス方法がない

– DBパラメーターグループ

• postgresql.conf相当

• AWSがイイ感じにしてくれてます

– セキュリティグループ

• pg_hba.conf相当

• 接続可能なサーバを指定する

気をつけたいポイント

• RDSはDBへのエンドポイントのみが提供されておりSSH等のアクセス方法がない

– 拡張モジュール

• AWSが用意したものだけが使用可能

• plpgsql、postgisなど

SELECT * FROM pg_available_extensions;

DBパラメーターグループ

• APIやManagement Consoleを経由して設定変更をする

– 187個の項目がある

• 参照のみ38• 変更可能149

RDSチューニングのポイント

• DBパラメータグループの変更の必要はない

– インスタンスがスケールアップしても自動で適切なメモリサイズに設定される

– パラメーターを変更するくらいならインスタンスをスケールアップしたほうが良い

• 事前評価（ベンチマーク等）をする場合は、Multi-AZ構成で評価すること

– 結果が数倍違う

まとめ

• RDSを使ってDB運用者は幸せになろう– バックアップ・リストア

– 障害が起きてもサービスを続行できる可用性

– スケールアップ／ダウン

• RDSは銀の弾丸ではない

– クエリーの最適化やKVSとの併用も検討すること

おまけ

• EC2とRDSは同じzoneに配置するとレスポンス高

– RDSのMulti-AZは起動させてからzoneが決まる

– バッチ処理など大量処理をするときだけ意識すればよい

– EC2は可用性のために2つ以上のゾーンで使うべき

ZoneA ZoneB

RDS EC2EC2

ご清聴ありがとうございました

宣伝

JAWS-UG三都物語 20142014/07/05（土）

JAWS-UG大阪、神戸、京都3支部合同開催

http://jawsugosaka.doorkeeper.jp/events/10037