Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
【AWS RDS解説】待機系は読めるのか
Search
赤神青空
PRO
August 30, 2026
Video
Programming
38
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 赤神青空
【AWS資格のニュース】SAP が SAP-C03 に変わります
akagami
PRO
0
2
【力学 #5】単振り子と小角近似
akagami
PRO
0
5
【AIニュース】Genie 4 とは何か
akagami
PRO
0
15
【基本情報対策】IPアドレスとサブネットマスク
akagami
PRO
0
15
GPT-6 Cyber とは何か
akagami
PRO
0
15
【AWSの新サービス】Amazon ECS Gateway とは何か
akagami
PRO
0
20
【力学 #4】単振動:ばねの運動方程式を解く
akagami
PRO
0
9
【力学 #4】単振動:ばねの運動方程式を解く
akagami
PRO
0
10
Cloudflare の AI で他人の会話が混ざった?
akagami
PRO
0
27
Other Decks in Programming
See All in Programming
AIで開発が速くなった先で、開発チームは何を目指すか
shihochan
1
2k
Claude Code ハーネスDeep Dive – 君はどこまで制御する? -
takateeen_knj
6
5.2k
AI時代のTerminal環境を UNIX哲学で設計・運用する
yasunori0418
1
350
當我們開始不讀 Code - AI Agent 時代,Code Review 與 Clean Code 還剩下什麼?
jame2408
1
370
Kawaiicon: Kubernetes, it's no longer cool, but let's secure it anyway!
barnbarn
0
130
AWS CDKを理解するために公式の定義を深掘って解説してみる / Understanding AWS CDK by Digging into Its Official Definition
akihisaikeda
3
290
Herb in Rails 8.2: Your ERB views, now HTML-aware @ Kaigi on Rails 2026, Tokyo, Japan
marcoroth
2
420
AI Augmentation Techniques with Liberty
ivargrimstad
1
440
小さなアプリを作って公開するまで
onozaty
0
160
Next.js: The final boss of Web Performance
guaca
0
400
[JA] Domain Modeling with Vanilla Rails: 「操作」から再考するRailsの設計論
yasaichi
4
1.9k
[DroidKnights 2026] Workflow AX: From Auto-Documented Policies to E2E Testing
raeminkang
0
560
Featured
See All Featured
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
360
31k
[SF Ruby Conf 2025] Rails X
palkan
3
1.5k
How GitHub (no longer) Works
holman
316
150k
[RailsConf 2023] Rails as a piece of cake
palkan
59
7.1k
The Illustrated Guide to Node.js - THAT Conference 2024
reverentgeek
1
600
Discover your Explorer Soul
emna__ayadi
2
1.3k
SEO for Brand Visibility & Recognition
aleyda
0
4.9k
The Cost Of JavaScript in 2023
addyosmani
56
10k
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
3
1.4k
The SEO identity crisis: Don't let AI make you average
varn
0
630
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
70
68k
What the history of the web can teach us about the future of AI
inesmontani
PRO
3
800
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