Rds徹底入門

Amazon RDS徹底入門

2011/11/05
第4回JAWS‐UG大阪
@j_nakada

自己紹介
• 中田淳平
• Twitter:@j_nakada
• 株式会社Razest 取締役CTO
• 携帯ゲームサイト「ゲムトモ」を運営
• PHP,MySQL,Flash Lite,AWS
• 好きなAWSサービス:RDS

Agenda
• Amazon RDSとは
• 自動バックアップとスナップショット
• リードレプリカとMulti‐AZ
• パフォーマンスチューニング

質問

Amazon RDSを使ったことがある人？

データベースを使ったことがある人？

Amazon RDSとは
• Amazon Relational Database Service
– AWSのサービスの1つ
– クラウド上でRDBの作成ができるサービス
– 高い信頼性、可用性、拡張性が特徴
– 選択可能なDBエンジンはMySQLとOracle

利用可能なデータベースエンジン
• MySQL 5.1
本日のターゲット
• MySQL 5.5
• Oracle 11g

こっちは
この人にお任せ！
@kaz_goto

利用可能なストレージエンジン（MySQL）

• InnoDB（InnoDB Plugin）
• MyISAM
• Tritonn
• SPIDER
• Q4M

Agenda
• Amazon RDSとは
• 自動バックアップとスナップショット
• リードレプリカとMulti‐AZ
• パフォーマンスチューニング
• まとめ

DBバックアップでのあるある
• システム構築には容量の見積もりが必要
– 見積もりが多すぎてコストの無駄
– n年後に容量オーバーで増設の手間が…

• バックアップからの復元（リストア）
– 復元手順書がない
– 復元してみたらバックアップデータが不完全

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

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

自動バックアップの注意点
• 1日1回のフルバックアップ中はストレージI/O
が数分間中断される
– バックアップの時間帯は、ある程度は指定できる
– Multi‐AZの利用で中断を回避できる

• 自動バックアップの内容を使って別のインス
タンスを起動することは出来ない
– スナップショットの利用で解決

スナップショットの役割
• 好きなタイミングで取れる完全なバックアップ
– 明示的に削除するまで保存可能
– $0.15/月GB

• スナップショットから新規のDBインスタンスを
起動できる
– 重たい集計処理や分析などのためだけにインス
タンスを起動して、終わったら終了する等の使い
方ができる

スナップショットの注意点
• スナップショット中ストレージI/Oが数分間中断
される
– Multi‐AZの利用で中断を回避できる

• スナップショットから元のDBインスタンスへ復
元することはできない
– 新規DBインスタンスで起動して、古いインスタン
スを削除する等の対応が必要

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

• 可用性を高くするためにはMulti‐AZとの併用
が必須

リードレプリカとMulti‐AZ
• リードレプリカ
– 非同期レプリケーション（マスター／スレーブ）
– スレーブへの読み込みアクセスが可能

• Multi‐AZ
– 同期レプリケーション（アクティブ／スタンバイ）
– 自動フェイルオーバー
– スタンバイへの直接アクセスは不可

リードレプリカ（非同期レプリケーション）

アプリケーション
スレーブへ読込のみアクセス可能

①書き込み ②書き込み完了

マスタースレーブ
③スレーブへ書き込み

Zone a Zone b

※MySQLの標準的なレプリケーション機能

リードレプリカの特徴

• スレーブに参照系アクセスが可能なので負荷分
散システムとして利用できる
– アクセス先はアプリケーション側でマスター／スレー
ブを意識して実装する必要がある

• マスターと同期をしているわけではないので、ス
レーブに最新の情報があることは保証されてい
ない
– ミッションクリティカルな処理ではマスターから参照す
ること
– インスタンスタイプはマスターと揃えるべき

同期レプリケーションのイメージ図

アプリケーション
スタンバイへのアクセス不可

①書き込み ④書き込み完了

③書き込み完了
アクティブスタンバイ
②スタンバイへ書き込み
Zone a Zone b

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

Multi‐AZの特徴

• スタンバイはアクティブに障害が発生した時に自動でフェ
イルオーバーしてアクティブに昇格する
– アプリケーションからは接続先の変更の必要なし
– フェイルオーバーに3分ほどかかる

• バックアップ／スナップショットはスタンバイから取得できる
– アクティブのI/Oに影響を出さないのでアプリケーションから快
適に利用できる

• 物理的に離れた拠点と同期してるので遅い
– Non‐MultiAZと比べて数分の1の応答速度（レイテンシ）
– 帯域は十分あるので、データの大きさは関係ない

パフォーマンスチューニング
• RDSはDBへのエンドポイントのみが提供され
ており、SSH等のアクセス方法がない
– my.cnfどうするの？
– メモリの割り当てどうなってるの？

DBパラメーターグループ
• APIを経由して設定変更をする
– MySQL5.1と5.5でパラメータの種類が異なる
– 標準のMySQL相当の項目が存在する
– AWS Management Consoleからは参照のみ

変更可能なパラメータ（一部）
innodb_buffer_pool_size {DBInstanceClassMemory*3/4}
key_buffer_size 16777216
log_slow_queries / slow_query_log OFF
max_connections {DBInstanceClassMemory/12582880}
performance_schema（5.5のみ） OFF
character_set～ latin1

InnoDBの利用なら文字コードあたりしか変えなくていい
ただし、反映にはインスタンスのrebootが必要

変更不可能なパラメータ（一部）
ignore_builtin_innodb 1（5.1のみ）
log_output TABLE
default_time_zone UTC
binlog_format MIXED
innodb_flush_method O_DIRECT
各種dir

デフォルトタイムゾーンが変えられない！

RDSチューニングのポイント
• InnoDBを使う限りは変更の必要はない
– インスタンスがスケールアップしても自動的に適
切なメモリサイズに設定される

• MyISAMを使う場合は調整が必要
– key_buffer_sizeをメモリの30%など
– 通常のMySQLと同じ感覚でOK

RDSチューニングのポイント（２）
• 事前評価（ベンチマーク等）をする場合は、
MultiAZ構成で評価すること
– 結果が数倍違う

• チューニングより上位インスタンス
– innodb_io_capacityを1000に設定して10%～20%
の向上がある程度（largeインスタンス）
– 上位インスタンスに切り替えれば、それ以上の性
能向上が可能

まとめ
• DB運用者が楽をするために使いましょう
– バックアップ・リストア
– 障害が起きてもサービスを続行できる可用性
– スケールアウト、スケールアップ／ダウン

• RDSは銀の弾丸ではない
– 標準のストレージエンジンのみ利用できる
– クエリーの最適化やKVSとの併用も検討すること

おまけ
• EC2とRDSは同一zoneに配置した方がレスポ
ンスが速いです
– RDSのMultiAZは起動させてからzoneが決まる
– 任意のzoneに指定することは現時点では無理

EC2 RDS EC2

Zone a Zone b

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

Rds徹底入門

More Related Content

What's hot

Similar to Rds徹底入門

More from Junpei Nakada

Rds徹底入門