大阪リージョンで RDS / Aurora を 使うときの注意点

Transcript

1. 大阪リージョンで RDS / Aurora を 使うときの注意点 JAWS-UG 名古屋 DR 対策特集＋

   LT 2021/03/29 まつひさ（hmatsu47）

2. 自己紹介 松久裕保（@hmatsu47） https://qiita.com/hmatsu47 名古屋で Web インフラのお守り係をしています MySQL 8.0 の薄い本を作って配っていました ◦

   Qiita の記事： https://qiita.com/hmatsu47/items/ceb75caf46e3c761095d ◦ GitHub リポジトリの他、印刷版を BOOTH で配布していました ◦ 5 月発行予定の 8.0.24 対応版を最後に更新停止する予定です https://note.com/hmatsu47/n/n3ad586c31dce 2

3. 今日の内容 • 大阪ローカルリージョン時代のふりかえり • 大阪リージョンで RDS / Aurora を使う際の注意点 ◦

   提供インスタンスタイプが少ない ◦ Aurora のリザーブドインスタンスが未提供 など • ローカルリージョンから継続利用する場合の注意点 • おまけ ※2021/03/29 現在の情報です（個人で確認した情報なので無保証） 3

4. 余談ですが • 地理冗長に関する話を先月 JAWS-UG 浜松で話しました ◦ https://speakerdeck.com/hmatsu47/02-ban ◦ 2019/09 に

   JAWS-UG 名古屋で話した内容のアップデートです ◦ AWS の中の人とは違う立場で書いています 4

5. 大阪ローカルリージョン時代のふりかえり • 2019/09 に話した内容はこちら ◦ https://speakerdeck.com/hmatsu47/sisutemufalsedi-li-rong-chang-dekao-lu-subeki pointoto-da-ban-rokaruriziyonfalsehua?slide=20 ◦ 1AZ しかなかった

   ◦ 提供サービス・インスタンスタイプが少なかった ◦ ほぼすべてのサービスが「上限ゼロ」からのスタートだった ◦ EC2 の利用にはリザーブドインスタンスの購入が必要だった ▪ スポットインスタンスはあった（オンデマンドインスタンス無し） 5

6. 大阪ローカルリージョン時代の RDS • Aurora は提供されず ◦ 1AZ しかなかったので順当 ▪ 逆に

   S3 はどうしてたの…？ • 実はリザーブドインスタンス購入は必須ではなかった ◦ AWS の中の人もパートナーの人も結構勘違いしていた ▪ 最初、勘違いをもとに RI を購入したが、実はただ単に「上限ゼロ」が理由 でインスタンスを作成できなかっただけ ▪ 正確な情報は、面倒でもサポートに問い合わせて確認すべし 6

7. 大阪リージョンで RDS / Aurora を使う際の注意点 • https://qiita.com/hmatsu47/items/836b21b3415846eda107 • 提供インスタンスタイプが少ない ◦

   db.m5・r5・t3 系のみ ▪ Graviton 2 未提供 7

8. 大阪リージョンで RDS / Aurora を使う際の注意点 • https://qiita.com/hmatsu47/items/836b21b3415846eda107 • 提供インスタンスタイプが少ない ◦

   db.m5・r5・t3 系のみ ▪ Graviton 2 未提供 8

9. 大阪リージョンで RDS / Aurora を使う際の注意点 • Aurora のリザーブドインスタンス（RI）が未提供 ◦ 「提供予定なし」とのこと

   ▪ 実際に計画されているかどうかは不明 ▪ RDS については、当初大阪ローカルリージョン時代のインスタンスタイプと Oracle・SQL Server のみだったのが、先週一通り提供されるようになった 模様 9

10. 大阪リージョンで RDS / Aurora を使う際の注意点 • Aurora のリザーブドインスタンス（RI）が未提供 ◦ 「提供予定なし」とのこと

    ▪ 実際に計画されているかどうかは不明 ▪ RDS については、当初大阪ローカルリージョン時代のインスタンスタイプと Oracle・SQL Server のみだったのが、先週一通り提供されるようになった 模様 10

11. 大阪リージョンで RDS / Aurora を使う際の注意点 • クロスリージョン自動バックアップ ◦ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_Replicat eBackups.html

    ▪ 対応しているのは RDS for Oracle / PostgreSQL のみ ▪ 東京リージョンのバックアップ先は大阪リージョン固定 ▪ RPO は通常 25 分以内（リアルタイム転送ではない） ▪ 暗号化インスタンスは対象外 11

12. • クロスリージョン自動バックアップ ◦ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_Replicat eBackups.html ▪ 対応しているのは RDS for Oracle

    / PostgreSQL のみ ▪ 東京リージョンのバックアップ先は大阪リージョン固定 ▪ RPO は通常 25 分以内（リアルタイム転送ではない） ▪ 暗号化インスタンスは対象外 大阪リージョンで RDS / Aurora を使う際の注意点 12 東京リージョン（本番） 大阪リージョン（DR） データ・トランザクションログ 自動バックアップ

13. 大阪リージョンで RDS / Aurora を使う際の注意点 • クロスリージョンリードレプリカ ◦ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraM ySQL.Replication.CrossRegion.html

    ▪ 東京リージョンにあるクラスタのリードレプリカを大阪リージョンに作成 する場合、東京リージョン側のバージョンを大阪リージョン側でサポート しているバージョンまで上げておく必要がある ◦ 例：MySQL 5.6互換版なら 1.23.1 以降 13

14. ローカルリージョンから継続利用する場合の注意点 • スナップショットからインスタンスを復元する際、 ◦ DB サブネットグループが 1AZ のままでは復元できない ▪ ローカルリージョン時代は例外的に

    1AZ で構成可能だった ▪ AWS より「DB サブネットグループに複数 AZ のサブネットを追加して」と アナウンスあり。ただし VPC のアドレス設定次第では困難なことも ◦ 以前と同じインスタンスタイプで復元できない可能性がある ▪ ローカルリージョン時代に RI 購入済みの場合に困ることも 14

15. ローカルリージョンから継続利用する場合の注意点 • スナップショットからインスタンスを復元する際、 ◦ DB サブネットグループが 1AZ のままでは復元できない ▪ ローカルリージョン時代は例外的に

    1AZ で構成可能だった ▪ AWS より「DB サブネットグループに複数 AZ のサブネットを追加して」と アナウンスあり。ただし VPC のアドレス設定次第では困難なことも ◦ 以前と同じインスタンスタイプで復元できない可能性がある ▪ ローカルリージョン時代に RI 購入済みの場合に困るかも 15

16. ローカルリージョンから継続利用する場合の注意点 • RDS スナップショットから Aurora に変換できない • その他 ◦ 東京→大阪のスナップショットコピー

    ▪ 当初 CLI(API) のみ可能だった→現在はマネジメントコンソールでも可能に 16

17. まとめ • 提供されるインスタンスタイプが制限される ◦ db.m5・r5・t3 系のみ • Aurora のリザーブドインスタンスが未提供 •

    関連サービスの提供仕様・制約に注意 ◦ クロスリージョン自動バックアップ ◦ クロスリージョンリードレプリカ など 17

18. まとめ • スナップショット復元に注意 ローカルリージョン時代から利用しているインスタンスは、 ◦ DB サブネットグループの設定次第では復元できない ◦ 以前と同じインスタンスタイプで復元できない可能性がある ▪

    ローカルリージョン時代に RI 購入済みの場合に困ることも 18

19. おまけ：某社の大阪リージョン利用事例 • 本番環境をオンプレから移行した直後 19 東京リージョン（本番） AMI 取得 オンプレ（DR） ファイル差分コピー（定期実行） MySQL

    レプリケーション

20. おまけ：某社の大阪リージョン利用事例 • 大阪ローカルリージョン開設後 20 東京リージョン（本番） AMIコピー 大阪ローカルリージョン（DR） MySQL レプリケーション AMI

    取得 ファイル差分コピー（定期実行）

21. おまけ：某社の大阪リージョン利用事例 • 大阪リージョン開設後（現在） 21 東京リージョン（本番） AMIコピー ファイルレプリケーション AMI 取得 大阪リージョン（DR）

    MySQL レプリケーション

22. おまけ：某社の大阪リージョン利用事例 • 大阪リージョン開設後（現在） 22 東京リージョン（本番） AMIコピー ファイルレプリケーション AMI 取得 大阪リージョン（DR）

    MySQL レプリケーション バイナリログによる MySQL レプリケーションでは Writer の書き込み TPS が一定以上スケールしない らしいので、今後 Global Database に移行予定