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
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
赤神青空
PRO
August 30, 2026
Video
Programming
29
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
【AWS RDS解説】待機系は読めるのか
赤神青空
PRO
August 30, 2026
Video
More Decks by 赤神青空
See All by 赤神青空
【ORM不要論の歴史】2026年の不要論は何を言っているのか
akagami
PRO
0
13
【ORM不要論の歴史】運用の問題は、いまの責務論に直結する
akagami
PRO
0
11
【ORM不要論の歴史】なぜ生まれ、20年前に何を言われたか
akagami
PRO
0
19
【高い買い物LT会】初任給で話題の国産フィジカルAIを買った話
akagami
PRO
0
95
【ORM不要論の歴史】「ORM」と呼ばれているものが3つある
akagami
PRO
0
53
【Vitest5.0大解剖】Vitest5.0で消えた記法とAPI
akagami
PRO
0
24
【Vitest5.0大解剖】Vitest5.0で増えた書き方
akagami
PRO
0
32
【Vitest5.0大解剖】Vitest5.0で静かに変わる挙動
akagami
PRO
0
27
【Vitest5.0大解剖】Vitest5.0のTrace View
akagami
PRO
0
28
Other Decks in Programming
See All in Programming
Intent as Code
shoppingjaws
2
410
フロントエンドUIフレームワークのこれまでとこれから
ssssota
1
800
WebMCP Challenge に星空観察アプリで参加した話
okajun35
0
100
go-spidermonkeyでAIエージェントのCode Modeを実装する
syumai
3
1.5k
AIを上手に使っていこうとしたら越境せざるを得なくなった話 〜実践1年で見えた境界を越えなければならない理由と進め方〜 / Crossing borders with AI
tomoyakitaura
4
1.1k
LLMは4年分のCompose移行を再現できるのか?実プロダクト279件のXMLで探る自動化の境界線
makun
0
440
Laravelのアプリケーションをどこにデプロイするか #ツナギメオフライン.9
akase244
0
120
Vibes Containers 〜AIで変わるコンテナ設計と運用〜
tkikuc
3
510
コンパウンドプロダクト開発のためのローカルプロセスマネージャー再発明 #layerxgo
izumin5210
0
660
AIに既存システムを理解させる技術 ~レガシーを見捨てないハーネスエンジニアリング入門~
ochtum
0
210
不幸な GC
chencmd
0
890
ハーネス設計入門 〜プロンプト、コンテキストの次〜
kinopeee
55
36k
Featured
See All Featured
Dominate Local Search Results - an insider guide to GBP, reviews, and Local SEO
greggifford
PRO
0
320
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
4.7k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
3k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
3k
What Being in a Rock Band Can Teach Us About Real World SEO
427marketing
0
1.1k
Discover your Explorer Soul
emna__ayadi
2
1.3k
The agentic SEO stack - context over prompts
schlessera
0
910
jQuery: Nuts, Bolts and Bling
dougneiner
66
8.6k
What does AI have to do with Human Rights?
axbom
PRO
1
2.4k
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
290
The Limits of Empathy - UXLibs8
cassininazir
1
640
Claude Code のすすめ
schroneko
67
230k
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