Upgrade to Pro — share decks privately, control downloads, hide ads and more …

【AWS RDS解説】待機系は読めるのか

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on.

【AWS RDS解説】待機系は読めるのか

Avatar for 赤神青空

赤神青空 PRO

August 30, 2026

Video

More Decks by 赤神青空

Other Decks in Programming

Transcript

  1. ▪名前が似ていて、中身がかなり違う Multi-AZ の2つの形 Multi-AZ インスタンス 待機系は1台、同期レプリケーション 待機系から読めない 切り替わりは 60〜120秒 全エンジンで使える

    Multi-AZ DBクラスター 待機系が2台、どちらも読める 準同期で書き込みを確定させる 切り替わりは 35秒未満 MySQLとPostgreSQLのみ クラスター型は3台ぶんの費用。読めるぶん高い、という関係です。 今ココ 冗長化 4/10
  2. ▪図にすると差が一目で分かる 待機系が読めるかどうか Multi-AZ インスタンス Multi-AZ DBクラスター 待機系は1台。読み取りには使えない プライマリ AZ-a 読み書き

    アプリからの読み取り 同期 待機系は2台。どちらからも読める スタンバイ AZ-b 待つだけ ✕ 読めない ‧⽬的は可⽤性だけ。読み負荷は1ミリも減らない ‧フェイルオーバーは概ね 1〜2分 ‧待機系のぶんの費⽤は払っている ‧読みを分けたいなら、別にリードレプリカが要る ライター 読める待機系 AZ-a AZ-b 読める待機系 AZ-c ◯ 3台とも読み取りに使える ‧可⽤性と読み性能を同時に取れる ‧準同期で書き込みを確定させる ‧フェイルオーバーがより短い ‧そのぶんインスタンスは3台ぶん動いている 左は可用性だけ、右は可用性と読み性能の両取り 今ココ 冗長化 5/10
  3. ▪同じ「複製」でも、狙っているものが違う 縦に守るか、横に捌くか Multi-AZ = 縦に守る リードレプリカ = 横に捌く 同じデータを、別のAZにもう1つ持つ コピーを増やして、読みを分散させる

    ⾮同期 プライマリ AZ-a 読み書き 同期レプリケーション スタンバイ AZ-b 待つだけ ✕ ここから読むことはできない ⽬的 = 壊れたときのため ‧切り替わりは 60〜120秒(クラスター型なら35秒未満) ‧読み負荷は1ミリも減らない プライマリ レプリカ 1 レプリカ 2 書き込み レプリカ 3 ◯ 全部から読める ⽬的 = 混んだときのため ‧⾮同期なので、少し古い値が返ることがある ‧障害時に⾃動で昇格しない。可⽤性の役には⽴たない 冗長化は壊れたとき、レプリカは混んだとき。足しても互いの代わりにならない 今ココ 負荷分散 7/10
  4. ▪目的から道具を引く 何を守りたいかで変わる 可用性・拡張性・災害対策は別々の目的なので、まとめて語らないほうがよいです。 AZ障害に耐えたい → Multi-AZ 読み負荷を捌きたい → リードレプリカ 両方いっぺんに

    → Multi-AZ DBクラスター リージョン障害に耐えたい → クロスリージョンのレプリカ 誤操作から戻したい → スナップショットとPITR どこまで失ってよいか、何分で戻すか。先に決めるのはそちら 今ココ まとめ 9/10