関西PostgreSQL勉強会での発表資料です

1. はじめてのAmazon RDS
for PostgreSQL
2014/04/16
関西PostgreSQL勉強会 with
Amazon Web Services
JAWS-UG大阪 中田淳平

2. 自己紹介
• 中田淳平
• Twitter:@j_nakada
• 株式会社Razest 取締役CTO
-モバイルゲーム作ってます
• JAWS-UG大阪コアメンバー
• PHP,MySQL,AWS,Unity
• 好きなAWSサービス:RDS

3. JAWS-UG
• Japan AWS User Group
• Amazon Web Servicesの利用促進や
情報交換のためのユーザーグループ

4. Agenda
• Amazon RDSとは
• Multi-AZ（HA構成）
• 自動バックアップとスナップショット
• 気をつけたいポイント
※本資料はSlideShareで公開します

5. Amazon RDSとは
• Amazon Relational Database Service
– AWSのサービスの1つ
– フルマネージドなクラウドRDB
– 高い信頼性、可用性、拡張性が特徴
– 選択可能なDBエンジン
• MySQL
• Oracle
• SQLServer
• PostgreSQL←New!

6. Amazon RDSとは
• 13のスペックから選択可能
– 最小
メモリ:0.6GB 約5,500円/月
– 最大
メモリ:244GB 約870,000円/月
• 起動後もスペックの変更可能
– 停止時間3分ほど
• 次々と新スペックの追加、値下げ
$1=105円
MultiAZ
東京リージョン
2014/4現在

7. Amazon RDS作成デモ
• 最小スペック（Micro）インスタンス
• PostgreSQL9.3.3
• Multi-AZ
• Disk容量：5GB
• バックアップ期間：7日間
• バックアップ開始時間：AM3時00分～3時30分
• 事前作成済み
– セキュリティグループ
– パラメーターグループ

8. Agenda
• Amazon RDSとは
• Multi-AZ（HA構成）
• 自動バックアップとスナップショット
• 気をつけたいポイント

9. Multi-AZ（HA構成）
• アクティブ／スタンバイ方式のHA構成
– 物理的に離れたデータセンターに配置
– PostgreSQLの同期レプリケーションではない
• 自動フェイルオーバー
– 障害発生時は自動でスタンバイに切り替わる
• スタンバイへの直接アクセスは不可
– スレーブのように参照用には使えない

10. Multi-AZのイメージ図
Zone a Zone b
アクティブ スタンバイ
②スタンバイへ書き込み
③書き込み完了
④書き込み完了
アプリケーション
①書き込み
※AWSの謎テクノロジーにより実現されているの
で
内部の動作は上記の図と異なります
概念としてとらえてください
スタンバイへのアクセス不可

11. Multi-AZの特徴
• 障害発生時は自動フェイルオーバーでスタンバイが昇格
– アプリケーションからは接続先の変更の必要なし
– フェイルオーバーに3分ほどかかる
• バックアップはスタンバイから取得される
– アプリケーションへのI/Oに影響を出さない
• 物理的に離れた拠点と同期してるので遅い
– Single-AZと比べて数分の1の応答速度（レイテンシ）
– 帯域は十分あるので、データの大きさは関係ない
本番運用ではMulti-AZ必須

12. Agenda
• Amazon RDSとは
• Multi-AZ（HA構成）
• 自動バックアップとスナップショット
• 気をつけたいポイント
そろそろDB起動したかな？

13. DBバックアップでのあるある
• システム構築には容量の見積もりが必要
– 見積もりが多すぎてコストの無駄
– n年後に容量オーバーで増設の手間が…
• バックアップからの復元（リストア）
– 復元手順書がない
– 復元してみたらバックアップデータが不完全

14. 自動バックアップとスナップショット
• 自動バックアップ
– 1日1回のフルバックアップとトランザクションログ
– 保存期間中の任意の時間に復元可能
– 保存期間：～35日
• スナップショット
– 利用者が任意のタイミングで実行
– スナップショットをもとにDBインスタンス起動可能
– 保存期間：利用者が削除するまで

15. 自動バックアップの役割
• 運用時の信頼性の確保
– バックアップファイルはAmazonS3に保存
– AmazonS3の堅牢性は99.999999999%
– $0.095/月GB
• リストア作業の簡易化
– APIもしくは、AWS Management Consoleから
バックアップ保存期間の任意のタイミングに復元
可能（リストアは別DBとして起動する）

16. 自動バックアップの注意点
• Single-AZだと1日1回のフルバックアップ中は
ストレージI/Oが数分間中断される
– バックアップの時間帯は、ある程度は指定できる
– Multi-AZの利用で中断を回避できる
• インスタンスを削除すると自動バックアップ全削除

17. スナップショットの役割
• 好きなタイミングで取れる完全なバックアップ
– 明示的に削除するまで保存可能
– インスタンスを削除しても残る
• スナップショットから新規DBを起動できる
– 重たい集計処理や分析のために別DBを起動し、
作業が終わったら削除することができる

18. スナップショットの注意点
• Single-AZだとスナップショット作成中は
ストレージI/Oが数分間中断される
– Multi-AZの利用で中断を回避できる
• スナップショットから元DBへ復元することはできない
– 新規DBインスタンスで起動して古いインスタンス
を削除する等の対応が必要

19. バックアップまとめ
• 2種類のバックアップでDB管理者が
幸せになれる
• 高可用性のためにはMulti-AZが必須

20. Agenda
• Amazon RDSとは
• Multi-AZ（HA構成）
• 自動バックアップとスナップショット
• 気をつけたいポイント

21. 気をつけたいポイント
• PostgreSQL9系のレプリケーションは使えない
– 同期による可用性確保はMulti-AZ
– 参照負荷分散はKVS（memcached等）の併用

22. 気をつけたいポイント
• RDSはDBへのエンドポイントのみが提供されており
SSH等のアクセス方法がない
– DBパラメーターグループ
• postgresql.conf相当
• AWSがイイ感じにしてくれてます
– セキュリティグループ
• pg_hba.conf相当
• 接続可能なサーバを指定する

23. 気をつけたいポイント
• RDSはDBへのエンドポイントのみが提供されており
SSH等のアクセス方法がない
– 拡張モジュール
• AWSが用意したものだけが使用可能
• plpgsql、postgisなど
SELECT * FROM pg_available_extensions;

24. DBパラメーターグループ
• APIやManagement Consoleを経由して設定変更をする
– 187個の項目がある
• 参照のみ38
• 変更可能149

25. RDSチューニングのポイント
• DBパラメータグループの変更の必要はない
– インスタンスがスケールアップしても自動で適切
なメモリサイズに設定される
– パラメーターを変更するくらいならインスタンスを
スケールアップしたほうが良い
• 事前評価（ベンチマーク等）をする場合は、Multi-AZ
構成で評価すること
– 結果が数倍違う

26. まとめ
• RDSを使ってDB運用者は幸せになろう
– バックアップ・リストア
– 障害が起きてもサービスを続行できる可用性
– スケールアップ／ダウン
• RDSは銀の弾丸ではない
– クエリーの最適化やKVSとの併用も検討すること

27. おまけ
• EC2とRDSは同じzoneに配置するとレスポンス高
– RDSのMulti-AZは起動させてからzoneが決まる
– バッチ処理など大量処理をするときだけ意識すればよい
– EC2は可用性のために2つ以上のゾーンで使うべき
ZoneA ZoneB
RDS EC2EC2

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

29. 宣伝
JAWS-UG三都物語 2014
2014/07/05（土）
JAWS-UG大阪、神戸、京都3支部合同開催
http://jawsugosaka.doorkeeper.jp/events/10037