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
【AWS RDS解説】待機系は読めるのか
Search
赤神青空
August 30, 2026
Programming
24
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
【AWS RDS解説】待機系は読めるのか
赤神青空
August 30, 2026
More Decks by 赤神青空
See All by 赤神青空
Vitest5.0は何が速くなったのか
akagami
0
10
1MBの壁にぶつかった話
akagami
0
20
Zod4.5を10分で
akagami
0
18
S3ライフサイクル入門
akagami
0
17
Viteはサーバーとクライアントを判定していない
akagami
0
24
OpenAI と Cursor、決裂までの3年
akagami
0
43
「まずはAI」の前に、分けて考える
akagami
0
28
【AWS Dogwood入門】使い分けと、採用するときの注意
akagami
0
17
【AWS Dogwood入門】認可はどこに置かれているか
akagami
0
31
Other Decks in Programming
See All in Programming
Deep dive into the select statement (GopherCon UK)
jespino
0
160
Oxlintはいいぞ(続)
yug1224
1
510
freee が目指す データ マネジメント戦略 AI-Ready 時代を支える 攻めのガバナンスとは
freee
PRO
0
560
S3 を使うアプリケーションをローカル完結で動かすことに全力を注いでみた / Running S3 Apps Offline
contour_gara
0
720
【DroidKaigi 2026】「アクセシビリティを利用するとき、 アクセシビリティもまたこちらを利用している」 〜マルウェアによる攻撃と防衛について〜
halunoyo
0
130
Detecting Compromised CI with eBPF and Cilium Tetragon
lizrice
0
280
in-process GraphQL のすすめ #ginzajs
izumin5210
4
1.5k
リアルな遅延を測る仕様
kota_yata
1
130
FastAPI の並行処理モデルを完全に理解する
hoto17296
9
3.4k
{ Android | Kotlin } Gradle Plugin in 2026
ryunen344
1
170
【QA Test Talk Vol.8】AI-DLC による Whole Team Approach の加速
pkshadeck
PRO
0
270
ALB ログから Trace を気合で繋げる技術
fohte
7
840
Featured
See All Featured
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
260
WENDY [Excerpt]
tessaabrams
12
39k
Evolving SEO for Evolving Search Engines
ryanjones
0
270
Designing Experiences People Love
moore
143
24k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
3k
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
3
1.2k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
How People are Using Generative and Agentic AI to Supercharge Their Products, Projects, Services and Value Streams Today
helenjbeal
1
300
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
570
The Curious Case for Waylosing
cassininazir
1
490
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
It's Worth the Effort
3n
188
29k
Transcript
2026年08月 待機系は読めるのか Multi-AZ とリードレプリカは、別の目的の道具 赤神青空
▪読みが速くならなかった話 Multi-AZにしたのに 「Multi-AZにしたので、2台で捌けるようになったはず」 残念ながら、そうはなっていません。 何が起きるか 待機系は動いているが、1クエリも 受け取らない。 今ココ はじめに なぜ気づきにくいか
費用は2倍なので、使われている 気がしてしまう。 今回やること 冗長化と負荷分散を、別の話として 分ける。 2/10
▪前提として、ここだけ揃えておきます RDSが引き受ける範囲 RDSは既存のDBエンジンをそのまま動かすサービスで、預けているのは運用のほうです。 AWSが持つのは、OSとエンジンのパッチ、バックアップ、冗長化 自分が持つのは、スキーマ設計とクエリと、構成の選択 今日の話は、この「構成の選択」のところ 冗長化の設定は、コンソールのチェックボックス1つで変わる だからこそ、目的を取り違えたまま有効にできてしまう 今ココ はじめに
3/10
▪名前が似ていて、中身がかなり違う Multi-AZ の2つの形 Multi-AZ インスタンス 待機系は1台、同期レプリケーション 待機系から読めない 切り替わりは 60〜120秒 全エンジンで使える
Multi-AZ DBクラスター 待機系が2台、どちらも読める 準同期で書き込みを確定させる 切り替わりは 35秒未満 MySQLとPostgreSQLのみ クラスター型は3台ぶんの費用。読めるぶん高い、という関係です。 今ココ 冗長化 4/10
▪図にすると差が一目で分かる 待機系が読めるかどうか Multi-AZ インスタンス Multi-AZ DBクラスター 待機系は1台。読み取りには使えない プライマリ AZ-a 読み書き
アプリからの読み取り 同期 待機系は2台。どちらからも読める スタンバイ AZ-b 待つだけ ✕ 読めない ‧⽬的は可⽤性だけ。読み負荷は1ミリも減らない ‧フェイルオーバーは概ね 1〜2分 ‧待機系のぶんの費⽤は払っている ‧読みを分けたいなら、別にリードレプリカが要る ライター 読める待機系 AZ-a AZ-b 読める待機系 AZ-c ◯ 3台とも読み取りに使える ‧可⽤性と読み性能を同時に取れる ‧準同期で書き込みを確定させる ‧フェイルオーバーがより短い ‧そのぶんインスタンスは3台ぶん動いている 左は可用性だけ、右は可用性と読み性能の両取り 今ココ 冗長化 5/10
▪こちらは負荷を分けるための仕組み リードレプリカ Multi-AZ が壊れたときのためなのに対し、リードレプリカは混んだときのためです。 非同期レプリケーション。少し古い値が返ることがある 台数を増やせる(上限はエンジンにより5〜15台) 別リージョンにも置ける(クロスリージョンは最大5台) 昇格させて独立したDBにできる(ただし手動) 遅延を許容できない読み取りには使えない 今ココ
負荷分散 6/10
▪同じ「複製」でも、狙っているものが違う 縦に守るか、横に捌くか Multi-AZ = 縦に守る リードレプリカ = 横に捌く 同じデータを、別のAZにもう1つ持つ コピーを増やして、読みを分散させる
⾮同期 プライマリ AZ-a 読み書き 同期レプリケーション スタンバイ AZ-b 待つだけ ✕ ここから読むことはできない ⽬的 = 壊れたときのため ‧切り替わりは 60〜120秒(クラスター型なら35秒未満) ‧読み負荷は1ミリも減らない プライマリ レプリカ 1 レプリカ 2 書き込み レプリカ 3 ◯ 全部から読める ⽬的 = 混んだときのため ‧⾮同期なので、少し古い値が返ることがある ‧障害時に⾃動で昇格しない。可⽤性の役には⽴たない 冗長化は壊れたとき、レプリカは混んだとき。足しても互いの代わりにならない 今ココ 負荷分散 7/10
▪ここが一番の誤解だと思っています レプリカは昇格しない 障害が起きたとき、リードレプリカは自動でプライマリになりません。 昇格は手動の操作です。 よくある勘違い レプリカを3台置いたので、 可用性も上がったはず。 今ココ 負荷分散 実際
フェイルオーバー先になるのは 待機系だけ。 併用したとき 新しめのバージョンなら、 再起動なしで追従します。 8/10
▪目的から道具を引く 何を守りたいかで変わる 可用性・拡張性・災害対策は別々の目的なので、まとめて語らないほうがよいです。 AZ障害に耐えたい → Multi-AZ 読み負荷を捌きたい → リードレプリカ 両方いっぺんに
→ Multi-AZ DBクラスター リージョン障害に耐えたい → クロスリージョンのレプリカ 誤操作から戻したい → スナップショットとPITR どこまで失ってよいか、何分で戻すか。先に決めるのはそちら 今ココ まとめ 9/10
▪チェックボックスを入れる前に思い出すこと まとめ 01 待機系は、原則として読めない 読めるのはMulti-AZ DBクラスターだけ。費用は3台ぶんになる。 02 リードレプリカは可用性を上げない 障害時に自動で昇格しない。フェイルオーバー先は待機系だけ。 03
冗長化と負荷分散は別の買い物 片方を足しても、もう片方の代わりにはならない。 今ココ まとめ 10/10