Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
はじめての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...
Amazon RDSとは
• 13のスペックから選択可能
– 最小
メモリ:0.6GB 約5,500円/月
– 最大
メモリ:244GB 約870,000円/月
• 起動後もスペックの変更可能
– 停止時間3分ほど
• 次々と新スペックの追加、...
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に...
Agenda
• Amazon RDSとは
• Multi-AZ(HA構成)
• 自動バックアップとスナップショット
• 気をつけたいポイント
そろそろDB起動したかな?
DBバックアップでのあるある
• システム構築には容量の見積もりが必要
– 見積もりが多すぎてコストの無駄
– n年後に容量オーバーで増設の手間が…
• バックアップからの復元(リストア)
– 復元手順書がない
– 復元してみたらバックアップデ...
自動バックアップとスナップショット
• 自動バックアップ
– 1日1回のフルバックアップとトランザクションログ
– 保存期間中の任意の時間に復元可能
– 保存期間:~35日
• スナップショット
– 利用者が任意のタイミングで実行
– スナップ...
自動バックアップの役割
• 運用時の信頼性の確保
– バックアップファイルはAmazonS3に保存
– AmazonS3の堅牢性は99.999999999%
– $0.095/月GB
• リストア作業の簡易化
– APIもしくは、AWS Man...
自動バックアップの注意点
• 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がイイ感じにしてくれてます
– セキュリティグループ
•...
気をつけたいポイント
• RDSはDBへのエンドポイントのみが提供されており
SSH等のアクセス方法がない
– 拡張モジュール
• AWSが用意したものだけが使用可能
• plpgsql、postgisなど
SELECT * FROM pg_a...
DBパラメーターグループ
• APIやManagement Consoleを経由して設定変更をする
– 187個の項目がある
• 参照のみ38
• 変更可能149
RDSチューニングのポイント
• DBパラメータグループの変更の必要はない
– インスタンスがスケールアップしても自動で適切
なメモリサイズに設定される
– パラメーターを変更するくらいならインスタンスを
スケールアップしたほうが良い
• 事前...
まとめ
• RDSを使ってDB運用者は幸せになろう
– バックアップ・リストア
– 障害が起きてもサービスを続行できる可用性
– スケールアップ/ダウン
• RDSは銀の弾丸ではない
– クエリーの最適化やKVSとの併用も検討すること
おまけ
• EC2とRDSは同じzoneに配置するとレスポンス高
– RDSのMulti-AZは起動させてからzoneが決まる
– バッチ処理など大量処理をするときだけ意識すればよい
– EC2は可用性のために2つ以上のゾーンで使うべき
Zon...
ご清聴ありがとうございました
宣伝
JAWS-UG三都物語 2014
2014/07/05(土)
JAWS-UG大阪、神戸、京都3支部合同開催
http://jawsugosaka.doorkeeper.jp/events/10037
Prochain SlideShare
Chargement dans…5
×

はじめてのAmazon RDS for PostgreSQL

5 021 vues

Publié le

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

Publié dans : Technologie
  • Identifiez-vous pour voir les commentaires

はじめてのAmazon RDS for PostgreSQL

  1. 1. はじめてのAmazon RDS for PostgreSQL 2014/04/16 関西PostgreSQL勉強会 with Amazon Web Services JAWS-UG大阪  中田淳平
  2. 2. 自己紹介 • 中田淳平 • Twitter:@j_nakada • 株式会社Razest 取締役CTO -モバイルゲーム作ってます • JAWS-UG大阪コアメンバー • PHP,MySQL,AWS,Unity • 好きなAWSサービス:RDS
  3. 3. JAWS-UG • Japan AWS User Group • Amazon Web Servicesの利用促進や 情報交換のためのユーザーグループ
  4. 4. Agenda • Amazon RDSとは • Multi-AZ(HA構成) • 自動バックアップとスナップショット • 気をつけたいポイント ※本資料はSlideShareで公開します
  5. 5. Amazon RDSとは • Amazon Relational Database Service – AWSのサービスの1つ – フルマネージドなクラウドRDB – 高い信頼性、可用性、拡張性が特徴 – 選択可能なDBエンジン • MySQL • Oracle • SQLServer • PostgreSQL←New!
  6. 6. Amazon RDSとは • 13のスペックから選択可能 – 最小 メモリ:0.6GB 約5,500円/月 – 最大 メモリ:244GB 約870,000円/月 • 起動後もスペックの変更可能 – 停止時間3分ほど • 次々と新スペックの追加、値下げ $1=105円 MultiAZ 東京リージョン 2014/4現在
  7. 7. Amazon RDS作成デモ • 最小スペック(Micro)インスタンス • PostgreSQL9.3.3 • Multi-AZ • Disk容量:5GB • バックアップ期間:7日間 • バックアップ開始時間:AM3時00分~3時30分 • 事前作成済み – セキュリティグループ – パラメーターグループ
  8. 8. Agenda • Amazon RDSとは • Multi-AZ(HA構成) • 自動バックアップとスナップショット • 気をつけたいポイント
  9. 9. Multi-AZ(HA構成) • アクティブ/スタンバイ方式のHA構成 – 物理的に離れたデータセンターに配置 – PostgreSQLの同期レプリケーションではない • 自動フェイルオーバー – 障害発生時は自動でスタンバイに切り替わる • スタンバイへの直接アクセスは不可 – スレーブのように参照用には使えない
  10. 10. Multi-AZのイメージ図 Zone a Zone b アクティブ スタンバイ ②スタンバイへ書き込み ③書き込み完了 ④書き込み完了 アプリケーション ①書き込み ※AWSの謎テクノロジーにより実現されているの で 内部の動作は上記の図と異なります 概念としてとらえてください スタンバイへのアクセス不可
  11. 11. Multi-AZの特徴 • 障害発生時は自動フェイルオーバーでスタンバイが昇格 – アプリケーションからは接続先の変更の必要なし – フェイルオーバーに3分ほどかかる • バックアップはスタンバイから取得される – アプリケーションへのI/Oに影響を出さない • 物理的に離れた拠点と同期してるので遅い – Single-AZと比べて数分の1の応答速度(レイテンシ) – 帯域は十分あるので、データの大きさは関係ない 本番運用ではMulti-AZ必須
  12. 12. Agenda • Amazon RDSとは • Multi-AZ(HA構成) • 自動バックアップとスナップショット • 気をつけたいポイント そろそろDB起動したかな?
  13. 13. DBバックアップでのあるある • システム構築には容量の見積もりが必要 – 見積もりが多すぎてコストの無駄 – n年後に容量オーバーで増設の手間が… • バックアップからの復元(リストア) – 復元手順書がない – 復元してみたらバックアップデータが不完全
  14. 14. 自動バックアップとスナップショット • 自動バックアップ – 1日1回のフルバックアップとトランザクションログ – 保存期間中の任意の時間に復元可能 – 保存期間:~35日 • スナップショット – 利用者が任意のタイミングで実行 – スナップショットをもとにDBインスタンス起動可能 – 保存期間:利用者が削除するまで
  15. 15. 自動バックアップの役割 • 運用時の信頼性の確保 – バックアップファイルはAmazonS3に保存 – AmazonS3の堅牢性は99.999999999% – $0.095/月GB • リストア作業の簡易化 – APIもしくは、AWS Management Consoleから バックアップ保存期間の任意のタイミングに復元 可能(リストアは別DBとして起動する)
  16. 16. 自動バックアップの注意点 • Single-AZだと1日1回のフルバックアップ中は   ストレージI/Oが数分間中断される – バックアップの時間帯は、ある程度は指定できる – Multi-AZの利用で中断を回避できる • インスタンスを削除すると自動バックアップ全削除
  17. 17. スナップショットの役割 • 好きなタイミングで取れる完全なバックアップ – 明示的に削除するまで保存可能 – インスタンスを削除しても残る • スナップショットから新規DBを起動できる – 重たい集計処理や分析のために別DBを起動し、 作業が終わったら削除することができる
  18. 18. スナップショットの注意点 • Single-AZだとスナップショット作成中は ストレージI/Oが数分間中断される – Multi-AZの利用で中断を回避できる • スナップショットから元DBへ復元することはできない – 新規DBインスタンスで起動して古いインスタンス を削除する等の対応が必要
  19. 19. バックアップまとめ • 2種類のバックアップでDB管理者が 幸せになれる • 高可用性のためにはMulti-AZが必須
  20. 20. Agenda • Amazon RDSとは • Multi-AZ(HA構成) • 自動バックアップとスナップショット • 気をつけたいポイント
  21. 21. 気をつけたいポイント • PostgreSQL9系のレプリケーションは使えない – 同期による可用性確保はMulti-AZ – 参照負荷分散はKVS(memcached等)の併用
  22. 22. 気をつけたいポイント • RDSはDBへのエンドポイントのみが提供されており SSH等のアクセス方法がない – DBパラメーターグループ • postgresql.conf相当 • AWSがイイ感じにしてくれてます – セキュリティグループ • pg_hba.conf相当 • 接続可能なサーバを指定する
  23. 23. 気をつけたいポイント • RDSはDBへのエンドポイントのみが提供されており SSH等のアクセス方法がない – 拡張モジュール • AWSが用意したものだけが使用可能 • plpgsql、postgisなど SELECT * FROM pg_available_extensions;
  24. 24. DBパラメーターグループ • APIやManagement Consoleを経由して設定変更をする – 187個の項目がある • 参照のみ38 • 変更可能149
  25. 25. RDSチューニングのポイント • DBパラメータグループの変更の必要はない – インスタンスがスケールアップしても自動で適切 なメモリサイズに設定される – パラメーターを変更するくらいならインスタンスを スケールアップしたほうが良い • 事前評価(ベンチマーク等)をする場合は、Multi-AZ 構成で評価すること – 結果が数倍違う
  26. 26. まとめ • RDSを使ってDB運用者は幸せになろう – バックアップ・リストア – 障害が起きてもサービスを続行できる可用性 – スケールアップ/ダウン • RDSは銀の弾丸ではない – クエリーの最適化やKVSとの併用も検討すること
  27. 27. おまけ • EC2とRDSは同じzoneに配置するとレスポンス高 – RDSのMulti-AZは起動させてからzoneが決まる – バッチ処理など大量処理をするときだけ意識すればよい – EC2は可用性のために2つ以上のゾーンで使うべき ZoneA ZoneB RDS EC2EC2
  28. 28. ご清聴ありがとうございました
  29. 29. 宣伝 JAWS-UG三都物語 2014 2014/07/05(土) JAWS-UG大阪、神戸、京都3支部合同開催 http://jawsugosaka.doorkeeper.jp/events/10037

×