JAWS-UG 名古屋 DR 対策特集+ LT 2021/03/29
大阪リージョンで RDS / Aurora を使うときの注意点JAWS-UG 名古屋 DR 対策特集+ LT 2021/03/29まつひさ(hmatsu47)
View Slide
自己紹介松久裕保(@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/n3ad586c31dce2
今日の内容● 大阪ローカルリージョン時代のふりかえり● 大阪リージョンで RDS / Aurora を使う際の注意点○ 提供インスタンスタイプが少ない○ Aurora のリザーブドインスタンスが未提供 など● ローカルリージョンから継続利用する場合の注意点● おまけ※2021/03/29 現在の情報です(個人で確認した情報なので無保証)3
余談ですが● 地理冗長に関する話を先月 JAWS-UG 浜松で話しました○ https://speakerdeck.com/hmatsu47/02-ban○ 2019/09 に JAWS-UG 名古屋で話した内容のアップデートです○ AWS の中の人とは違う立場で書いています4
大阪ローカルリージョン時代のふりかえり● 2019/09 に話した内容はこちら○ https://speakerdeck.com/hmatsu47/sisutemufalsedi-li-rong-chang-dekao-lu-subekipointoto-da-ban-rokaruriziyonfalsehua?slide=20○ 1AZ しかなかった○ 提供サービス・インスタンスタイプが少なかった○ ほぼすべてのサービスが「上限ゼロ」からのスタートだった○ EC2 の利用にはリザーブドインスタンスの購入が必要だった■ スポットインスタンスはあった(オンデマンドインスタンス無し)5
大阪ローカルリージョン時代の RDS● Aurora は提供されず○ 1AZ しかなかったので順当■ 逆に S3 はどうしてたの…?● 実はリザーブドインスタンス購入は必須ではなかった○ AWS の中の人もパートナーの人も結構勘違いしていた■ 最初、勘違いをもとに RI を購入したが、実はただ単に「上限ゼロ」が理由でインスタンスを作成できなかっただけ■ 正確な情報は、面倒でもサポートに問い合わせて確認すべし6
大阪リージョンで RDS / Aurora を使う際の注意点● https://qiita.com/hmatsu47/items/836b21b3415846eda107● 提供インスタンスタイプが少ない○ db.m5・r5・t3 系のみ■ Graviton 2 未提供7
大阪リージョンで RDS / Aurora を使う際の注意点● https://qiita.com/hmatsu47/items/836b21b3415846eda107● 提供インスタンスタイプが少ない○ db.m5・r5・t3 系のみ■ Graviton 2 未提供8
大阪リージョンで RDS / Aurora を使う際の注意点● Aurora のリザーブドインスタンス(RI)が未提供○ 「提供予定なし」とのこと■ 実際に計画されているかどうかは不明■ RDS については、当初大阪ローカルリージョン時代のインスタンスタイプとOracle・SQL Server のみだったのが、先週一通り提供されるようになった模様9
大阪リージョンで RDS / Aurora を使う際の注意点● Aurora のリザーブドインスタンス(RI)が未提供○ 「提供予定なし」とのこと■ 実際に計画されているかどうかは不明■ RDS については、当初大阪ローカルリージョン時代のインスタンスタイプとOracle・SQL Server のみだったのが、先週一通り提供されるようになった模様10
大阪リージョンで RDS / Aurora を使う際の注意点● クロスリージョン自動バックアップ○ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_ReplicateBackups.html■ 対応しているのは RDS for Oracle / PostgreSQL のみ■ 東京リージョンのバックアップ先は大阪リージョン固定■ RPO は通常 25 分以内(リアルタイム転送ではない)■ 暗号化インスタンスは対象外11
● クロスリージョン自動バックアップ○ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_ReplicateBackups.html■ 対応しているのは RDS for Oracle / PostgreSQL のみ■ 東京リージョンのバックアップ先は大阪リージョン固定■ RPO は通常 25 分以内(リアルタイム転送ではない)■ 暗号化インスタンスは対象外大阪リージョンで RDS / Aurora を使う際の注意点12東京リージョン(本番) 大阪リージョン(DR)データ・トランザクションログ 自動バックアップ
大阪リージョンで RDS / Aurora を使う際の注意点● クロスリージョンリードレプリカ○ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.html■ 東京リージョンにあるクラスタのリードレプリカを大阪リージョンに作成する場合、東京リージョン側のバージョンを大阪リージョン側でサポートしているバージョンまで上げておく必要がある○ 例:MySQL 5.6互換版なら 1.23.1 以降13
ローカルリージョンから継続利用する場合の注意点● スナップショットからインスタンスを復元する際、○ DB サブネットグループが 1AZ のままでは復元できない■ ローカルリージョン時代は例外的に 1AZ で構成可能だった■ AWS より「DB サブネットグループに複数 AZ のサブネットを追加して」とアナウンスあり。ただし VPC のアドレス設定次第では困難なことも○ 以前と同じインスタンスタイプで復元できない可能性がある■ ローカルリージョン時代に RI 購入済みの場合に困ることも14
ローカルリージョンから継続利用する場合の注意点● スナップショットからインスタンスを復元する際、○ DB サブネットグループが 1AZ のままでは復元できない■ ローカルリージョン時代は例外的に 1AZ で構成可能だった■ AWS より「DB サブネットグループに複数 AZ のサブネットを追加して」とアナウンスあり。ただし VPC のアドレス設定次第では困難なことも○ 以前と同じインスタンスタイプで復元できない可能性がある■ ローカルリージョン時代に RI 購入済みの場合に困るかも15
ローカルリージョンから継続利用する場合の注意点● RDS スナップショットから Aurora に変換できない● その他○ 東京→大阪のスナップショットコピー■ 当初 CLI(API) のみ可能だった→現在はマネジメントコンソールでも可能に16
まとめ● 提供されるインスタンスタイプが制限される○ db.m5・r5・t3 系のみ● Aurora のリザーブドインスタンスが未提供● 関連サービスの提供仕様・制約に注意○ クロスリージョン自動バックアップ○ クロスリージョンリードレプリカなど17
まとめ● スナップショット復元に注意ローカルリージョン時代から利用しているインスタンスは、○ DB サブネットグループの設定次第では復元できない○ 以前と同じインスタンスタイプで復元できない可能性がある■ ローカルリージョン時代に RI 購入済みの場合に困ることも18
おまけ:某社の大阪リージョン利用事例● 本番環境をオンプレから移行した直後19東京リージョン(本番)AMI 取得オンプレ(DR)ファイル差分コピー(定期実行)MySQL レプリケーション
おまけ:某社の大阪リージョン利用事例● 大阪ローカルリージョン開設後20東京リージョン(本番)AMIコピー大阪ローカルリージョン(DR)MySQL レプリケーションAMI 取得ファイル差分コピー(定期実行)
おまけ:某社の大阪リージョン利用事例● 大阪リージョン開設後(現在)21東京リージョン(本番)AMIコピーファイルレプリケーションAMI 取得大阪リージョン(DR)MySQL レプリケーション
おまけ:某社の大阪リージョン利用事例● 大阪リージョン開設後(現在)22東京リージョン(本番)AMIコピーファイルレプリケーションAMI 取得大阪リージョン(DR)MySQL レプリケーションバイナリログによる MySQL レプリケーションではWriter の書き込み TPS が一定以上スケールしないらしいので、今後 Global Database に移行予定