Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
大阪リージョンで RDS / Aurora を 使うときの注意点
Search
hmatsu47
PRO
March 29, 2021
Technology
2
2.9k
大阪リージョンで RDS / Aurora を 使うときの注意点
JAWS-UG 名古屋 DR 対策特集+ LT 2021/03/29
hmatsu47
PRO
March 29, 2021
Tweet
Share
More Decks by hmatsu47
See All by hmatsu47
ある日突然 DB の性能が 1/2(サイズのインスタンス相当)になった話
hmatsu47
PRO
0
21
pgvectorscale と pgai の話(ざっくり)
hmatsu47
PRO
0
17
pgvector 0.7.0 の新機能と、これから来る(かもしれない)pgvectorscale
hmatsu47
PRO
0
14
大人の社会科見学 ~ NTT 技術史料館に行ってみよう!
hmatsu47
PRO
0
360
pgvector 0.6.0 以降の進化についてざっくり取り上げてみる
hmatsu47
PRO
0
36
Cloudflare Workes からMySQL 系 DB への接続事情(2024/4 現在)
hmatsu47
PRO
0
82
BuriKaigi2024 にボランティアスタッフとして参加した話
hmatsu47
PRO
0
68
Aurora MySQL と Redshift の zero-ETL 統合のフィルター機能を試してみた
hmatsu47
PRO
0
120
Aurora MySQL 3.06 の ML 機能で Bedrock アクセスを試してみた
hmatsu47
PRO
0
86
Other Decks in Technology
See All in Technology
DuckDB雑紹介(1.1対応版)@DuckDB座談会
ktz
5
1.2k
自作Cコンパイラ 8時間の奮闘
soukouki
0
600
Javaにおける関数型プログラミンへの取り組み
skrb
7
310
自社サービスのための独自リリース版Redmine「RedMica」の取り組み
vividtone
0
1.1k
より快適なエラーログ監視を目指して
leveragestech
4
1.3k
自社開発した大規模言語モデルをどうプロダクションに乗せて運用していくか〜インフラ編〜
pfn
PRO
24
6.9k
技術ブログや登壇資料を秒で作るコツ伝授します
minorun365
PRO
23
5.5k
20240912 JJUGナイトセミナー
mii1004
0
130
プログラム検証入門
riru
2
640
PdMはどのように全てのスピードを上げられるか ~ 非連続進化のための具体的な取り組み ~
sansantech
PRO
1
160
Oracle Cloud Infrastructure IaaS 新機能アップデート 2024/6 - 2024/8
oracle4engineer
PRO
0
110
Creative UIs with Compose: DroidKaigi 2024
chrishorner
1
220
Featured
See All Featured
Principles of Awesome APIs and How to Build Them.
keavy
125
16k
Bootstrapping a Software Product
garrettdimon
PRO
304
110k
How GitHub Uses GitHub to Build GitHub
holman
472
290k
Rebuilding a faster, lazier Slack
samanthasiow
78
8.6k
How to Ace a Technical Interview
jacobian
275
23k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
88
16k
Gamification - CAS2011
davidbonilla
79
4.9k
We Have a Design System, Now What?
morganepeng
48
7.1k
Creatively Recalculating Your Daily Design Routine
revolveconf
215
12k
Debugging Ruby Performance
tmm1
72
12k
Designing for Performance
lara
604
68k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Transcript
大阪リージョンで 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 に移行予定