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
3.2k
大阪リージョンで RDS / Aurora を 使うときの注意点
JAWS-UG 名古屋 DR 対策特集+ LT 2021/03/29
hmatsu47
PRO
March 29, 2021
Tweet
Share
More Decks by hmatsu47
See All by hmatsu47
ゲームで体感!Aurora DSQL の OCC(楽観的同時実行制御)
hmatsu47
PRO
0
9
PostgreSQL+pgvector で GraphRAG に挑戦 & pgvectorscale 0.7.x アップデート
hmatsu47
PRO
0
20
LlamaIndex の Property Graph Index を PostgreSQL 上に構築してデータ構造を見てみる
hmatsu47
PRO
0
15
PostgreSQL+pgvector で LlamaIndex の Property Graph Index を試す(序章)
hmatsu47
PRO
0
13
HeatWave on AWS という選択肢を検討してみる
hmatsu47
PRO
0
10
HeatWave on AWS のインバウンドレプリケーションで HeatWave エンジン有効時のレプリケーションラグを確認してみた!
hmatsu47
PRO
0
19
CloudWatch Database Insights 関連アップデート
hmatsu47
PRO
0
43
さいきんの MySQL との付き合い方 〜 MySQL 8.0 より後の世界へようこそ 〜
hmatsu47
PRO
0
35
ベクトルストア入門
hmatsu47
PRO
0
26
Other Decks in Technology
See All in Technology
【新卒研修資料】数理最適化 / Mathematical Optimization
brainpadpr
25
11k
Bet "Bet AI" - Accelerating Our AI Journey #BetAIDay
layerx
PRO
4
1.5k
Amazon Qで2Dゲームを作成してみた
siromi
0
110
S3 Glacier のデータを Athena からクエリしようとしたらどうなるのか/try-to-query-s3-glacier-from-athena
emiki
0
180
LLM 機能を支える Langfuse / ClickHouse のサーバレス化
yuu26
5
390
相互運用可能な学修歴クレデンシャルに向けた標準技術と国際動向
fujie
0
200
マルチプロダクト×マルチテナントを支えるモジュラモノリスを中心としたアソビューのアーキテクチャ
disc99
1
310
VLMサービスを用いた請求書データ化検証 / SaaSxML_Session_1
sansan_randd
0
220
o11yツールを乗り換えた話
tak0x00
1
300
みんなのSRE 〜チーム全員でのSRE活動にするための4つの取り組み〜
kakehashi
PRO
2
140
Claude Codeが働くAI中心の業務システム構築の挑戦―AIエージェント中心の働き方を目指して
os1ma
9
1.5k
僕たちが「開発しやすさ」を求め 模索し続けたアーキテクチャ #アーキテクチャ勉強会_findy
bengo4com
0
2k
Featured
See All Featured
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
110
19k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Making the Leap to Tech Lead
cromwellryan
134
9.5k
For a Future-Friendly Web
brad_frost
179
9.9k
Scaling GitHub
holman
461
140k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
21
1.4k
Producing Creativity
orderedlist
PRO
346
40k
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 に移行予定