Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

B1dca90d4b3ffd2ccd918774e1ba170d?s=47 hmatsu47
March 29, 2021

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

JAWS-UG 名古屋 DR 対策特集+ LT 2021/03/29

B1dca90d4b3ffd2ccd918774e1ba170d?s=128

hmatsu47

March 29, 2021
Tweet

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 に移行予定