大阪リージョンで RDS / Aurora を 使うときの注意点 JAWS-UG 名古屋 DR 対策特集＋ LT 2021/03/29 まつひさ（hmatsu47）

自己紹介 松久裕保（@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

今日の内容 ● 大阪ローカルリージョン時代のふりかえり ● 大阪リージョンで 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-subeki pointoto-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_Replicat eBackups.html ■ 対応しているのは RDS for Oracle / PostgreSQL のみ ■ 東京リージョンのバックアップ先は大阪リージョン固定 ■ RPO は通常 25 分以内（リアルタイム転送ではない） ■ 暗号化インスタンスは対象外 11

● クロスリージョン自動バックアップ ○ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_Replicat eBackups.html ■ 対応しているのは RDS for Oracle / PostgreSQL のみ ■ 東京リージョンのバックアップ先は大阪リージョン固定 ■ RPO は通常 25 分以内（リアルタイム転送ではない） ■ 暗号化インスタンスは対象外 大阪リージョンで RDS / Aurora を使う際の注意点 12 東京リージョン（本番） 大阪リージョン（DR） データ・トランザクションログ 自動バックアップ

大阪リージョンで RDS / Aurora を使う際の注意点 ● クロスリージョンリードレプリカ ○ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraM ySQL.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 に移行予定