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
赤神青空
PRO
August 30, 2026
Video
Programming
26
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 赤神青空
【Vitest5.0大解剖】Vitest5.0で消えた記法とAPI
akagami
PRO
0
12
【Vitest5.0大解剖】Vitest5.0で増えた書き方
akagami
PRO
0
18
【Vitest5.0大解剖】Vitest5.0で静かに変わる挙動
akagami
PRO
0
17
【Vitest5.0大解剖】Vitest5.0のTrace View
akagami
PRO
0
20
【Vitest5.0大解剖】Vitest5.0は何が速くなったのか
akagami
PRO
0
23
1MBの壁にぶつかった話
akagami
PRO
0
25
Zod4.5を10分で
akagami
PRO
0
27
S3ライフサイクル入門
akagami
PRO
0
24
Viteはサーバーとクライアントを判定していない
akagami
PRO
0
32
Other Decks in Programming
See All in Programming
T3DD26: From RAGs to Riches
martinhelmich
0
140
「AI時代、配布するPythonコードをどう守るか: 難読化の実験と判断軸」 #PyconJP2026
pkshadeck
PRO
2
130
いまどきの Codex で開発する visionOS アプリの開発スタイルについて
karad
0
180
LoopHub - ローカルで動く GitHub で、AI と共同開発
jugyo
0
380
Webエンジニアなのにブラウザの仕組みがわからないので、Pythonで自作してみた
tatsuki12
4
1.6k
Gmail/Google DriveをトリガーにAIエージェントを動かそう! / Run AI agents with Gmail/Google Drive as triggers!
har1101
3
460
ALB ログから Trace を気合で繋げる技術
fohte
7
860
書籍「プロフェッショナルAI駆動開発」紹介スライド
juntaromatsumoto
0
960
【DroidKaigi 2026】「アクセシビリティを利用するとき、 アクセシビリティもまたこちらを利用している」 〜マルウェアによる攻撃と防衛について〜
halunoyo
0
300
高専、大学編入、そして未踏へ〜プロダクト開発とキャリアの歩み - Technical College, University Transfer, and On to “Mitou” / My Journey in Product Development and Career
pkmiya
0
130
自分的「カンファレンスの楽しみ方」
syumai
0
180
kubernetes コンポーネント開発入門 / 新卒N年目の勉強会&交流会!〜〇〇への誘い〜 #n_study
mazrean
0
160
Featured
See All Featured
Chasing Engaging Ingredients in Design
codingconduct
0
300
We Analyzed 250 Million AI Search Results: Here's What I Found
joshbly
1
1.9k
RailsConf 2023
tenderlove
30
1.5k
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
810
Kristin Tynski - Automating Marketing Tasks With AI
techseoconnect
PRO
0
490
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
470
Navigating Algorithm Shifts & AI Overviews - #SMXNext
aleyda
1
1.6k
Technical Leadership for Architectural Decision Making
baasie
3
550
brightonSEO & MeasureFest 2025 - Christian Goodrich - Winning strategies for Black Friday CRO & PPC
cargoodrich
3
800
From Legacy to Launchpad: Building Startup-Ready Communities
dugsong
0
320
Why You Should Never Use an ORM
jnunemaker
PRO
61
10k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
1.3k
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