Auroraファースト

@see 賭博黙示録カイジ

最初からAuroraを使うのだ！

あるいは使わないのだ。

• 「下手にコストを考えて小出しにRDSを使うのはダメなんだ」
  →それならEC2にDBサービスを入れる戦略を取る
• コストを気にして下位のRDSを採用するぐらいだったら使わない
  →WEBサーバがクラスタ構成、DBにリードレプリカが必要になってからRDS, Auroraを採用する
  どんなサイトやシステムでもRDS, Auroraを利用するのは良くない
  →コスパの良いサーバなら、さくらの専用サーバを検討してみる
• 「嘘じゃない、かえってストレスがたまる。やる時はきっちりやった方がいい・・・！」
  RDSを利用することによる運用負荷は無視できない。
  自動バックアップ対策のMulti-AZ、メンテナンス対応、キャパシティプランニングやチューニングに時間を使うぐらいならシンプルに「Aurora」を利用する。
• 困難をお金の力で解決する
  有限な時間とリソースをビジネスに集中させ、素晴らしいユーザ体験を提供する。素敵だ。
• Auroraを使うことで、「RDSではなくて、これがAuroraだったらな」がなくなる。
  RDSでは起こりAuroraでは起こらない、一時的なクエリの詰まりといった不具合が発生する場合がある。
• Auroraを使うことでストレージ監視をしなくて済む
  Auroraはストレージが自動拡張！ディスク監視の必要がない、RDSはディスクフルになると停止するので監視が必要になる。

RDSは高いのでなんとなく下位のインスタンスで稼働していることが多く、スペック不足から障害になっているケースがよくあります。

 

 

Auroraの良いところ

• RDSと比べた場合の処理性能の向上
  MySQL処理性能5倍、PostgreSQLなら3倍
• 負荷分散が必要な場合構成がシンプル
  書き込み、読み込みエンドポイントが標準で用意されている
  RDSだとRoute53+ヘルスチェックで設定する手間がなくなりシンプルになる。
• パフォーマンスインサイト
  詳細なモニタリングが出来る
• ゼロダウンタイムパッチ
  アプリケーションのセッションが切断されない
• ストレージの自動拡張
  Auroraはストレージが自動でスケールする。
  ※RDSの場合はディスクフルになると停止し障害になります。

 

アプリのバグによるデータ不整合時の対応

1.  アプリからDBに書き込みが行われないようにメンテナンスを入れます
2.  メンテナンスでのデータ消失防止の為に、障害地点のスナップショットとログを複製してます
3. Auroraに備わっているBacktrackによって問題発生直前までにロールバックしてください
4. 問題発生直前までに戻せればクローズします
5. メンテナンスを終了しサービスを再開させてください。

 

 

Auroraでの注意点

• クラスタ用とインスタンス用で2つにパラメータグループが分かれている
  ・”クラスタ用 = ストレージ”と考える
  ・Auroraはインスタンスとストレージに分かれている
• 圧縮テーブルを非サポート
  row_formatが”Compressed”は受付ない。”Compact”などにALTER TABLEなどで変換しておく
• 移行前にtime zoneを確認
  明示的にJST(Asia/Tokyo)に指定しておく
• ゼロダウンタイムパッチとアップグレードのダウンタイム

 

Auroraのアップグレードの挙動

ゼロダウンタイムパッチ(ZDP)

• 5秒程度スループットが低下する
• アプリケーションのセッションは維持されるので安心

通常のアップグレードの場合は30秒程度ダウンする

 

ゼロダウンタイムパッチが無効になるケース

• 長期実行クエリまたはトランザクションが進行中である
• バイナリログが有効になっているか、バイナリログのレプリケーションが進行中である
  パラメータグループで「binlog_format」がoffになっているか確認して、offなら無効になっているのでOK！
• オープン SSL 接続がある
• 一時テーブルまたはテーブルロックが使用中である
• パラメータの変更が保留中である

@see AWS

 

Auroraアップグレードの動作順序

1. マスターがアップグレードされる、
   スループット5秒程度低下
2. Readerが複数台の場合は全台同時にアップデートされる
   30秒程度ダウン

Auroraアップデートの挙動 ZDPが動作しているかの違い

• ZDPが動作している
  更新系は5秒程度のスループット低下、参照系は20～30秒ダウン
• ZDPが動作しない場合
  更新系、参照どちらも20～30秒ダウン

これらの20～30秒のダウンはMulti-AZ構成でも発生するので注意したい

 

 

RDS for MySQLからAuroraへ

制限事項

• innoDBエンジンに変更しておく
  MyISAMは非対応
• ｢innodb_file_per_table｣は非対応、オプションを無効化してテーブルを戻しておく
  // MySQL5.6.6以降はデフォルトでONになっている
  @see MySQL道普請便り 第55回innodb_file_per_tableオプションについて

 

 

方法

1. mysqldumpでAuroraにリストアする

2. RDSのスナップショットからAuroraに移行する

1. アプリケーションをメンテナンスしてDBへの書き込みを止める
2. 最新のスナップショットを取得する
3. スナップショットを選択して、「スナップショットのアクション」から「スナップショットの移行」を選択する

 

スナップショットを選択して、「スナップショットのアクション」から「スナップショットの移行」を選択する

 

 

選択しよう

 

 

他の手段

リードレプリカを利用してレプリケーションからAuroraに同期をかける

 

 

RDS for PostgreSQLからAuroraへ

 

方法

• RDS for PostgreSQLのダンプデータから移行する

※MySQLのようにスナップショットからAuroraへの移行が出来ない(2019年01月18日時点)

 

考慮点

RDS for PosgreSQLからAuroraに切り替える場合

• RDSと比べるとコストが多少あがる
• インスタンス選択出来る種類がとても少ない
  // r系のみ選択可能
  // 最小インスタンスはdb.r4.larage 2CPU 7ECU メモリ15.25GB (28,000円/月)
• RDS for PostgreSQLはスナップショットからAuroraに移行出来ないので、ダンプデータからAuroraを作成する必要がある
  // MySQLのRDSであればスナップショットから移行が簡単
• 動作確認が必要