はじめてのAmazon RDS for PostgreSQL
Upcoming SlideShare
Loading in...5
×
 

はじめてのAmazon RDS for PostgreSQL

on

  • 1,247 views

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

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

Statistics

Views

Total Views
1,247
Views on SlideShare
1,236
Embed Views
11

Actions

Likes
2
Downloads
8
Comments
0

2 Embeds 11

http://s.deeeki.com 7
https://twitter.com 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

はじめてのAmazon RDS for PostgreSQL はじめてのAmazon RDS for PostgreSQL Presentation Transcript

  • はじめての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三都物語 2014 2014/07/05(土) JAWS-UG大阪、神戸、京都3支部合同開催 http://jawsugosaka.doorkeeper.jp/events/10037