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
Auroraは速いRDSではない
Search
赤神青空
PRO
August 19, 2026
Video
Programming
130
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Auroraは速いRDSではない
赤神青空
PRO
August 19, 2026
Video
More Decks by 赤神青空
See All by 赤神青空
【AWS AIF対策】AIシステムを守る
akagami
PRO
0
13
【AIニュース】ChatGPT Space とは何か
akagami
PRO
0
20
【AWS AIF対策】透明性と説明可能性
akagami
PRO
0
16
【AIニュース】OpenAI の「dots」とは何か
akagami
PRO
0
22
【AWS AIF対策】責任あるAI
akagami
PRO
0
24
【AWS AIF対策】基盤モデルの評価
akagami
PRO
0
27
【AWS AIF対策】モデルの学習とファインチューニング
akagami
PRO
0
17
【AWS AIF対策】プロンプトエンジニアリング
akagami
PRO
0
17
【AWS AIF対策】RAGとベクトルデータベース
akagami
PRO
0
17
Other Decks in Programming
See All in Programming
GemmaをJevのように使ってみる / Use Gemma like Jev
kishida
5
660
WebRTC映像をAirPlayに対応させる挑戦.pdf
monolithic_adam
0
340
Turning Architecture into Unit Tests in the AI Era (NSSpain XIV)
steliosf
PRO
1
130
FreeBSDでZabbixを動かす
kenkino
0
350
設計次第でAIコードの読む量は減らせる / designing-for-code-reading
minodriven
34
15k
Unity6 URPによる海底をテーマにしたVJシステムの解説 | Unity Shader 完全に理解した 勉強会
gam0022
0
320
Streamlitで実現する自然言語データアプリ開発
ayumu_yamaguchi
1
340
スマートフォンでモールス信号を送受信する 〜スマートフォンのLEDとカメラで作る光通信の設計と実装〜
atsuki_seo
0
230
wkhtmltopdfの次どうするか問題2026
willnet
2
1.8k
パーソナライズPodcastを作った話
repunit11
0
120
[2026-09-26]空論ジェネリックプロセス~テスト資産とAIで紡ぐ、再現可能なパフォーマンスチューニングの話~
tosite
0
250
AWSに止められる覚悟してますか?
morizo_1984
2
510
Featured
See All Featured
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.6k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
123
22k
Code Reviewing Like a Champion
maltzj
528
40k
Jamie Indigo - Trashchat’s Guide to Black Boxes: Technical SEO Tactics for LLMs
techseoconnect
PRO
0
690
Evolving SEO for Evolving Search Engines
ryanjones
0
310
Jess Joyce - The Pitfalls of Following Frameworks
techseoconnect
PRO
1
430
The AI Search Optimization Roadmap by Aleyda Solis
aleyda
2
6.3k
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
760
Google's AI Overviews - The New Search
badams
0
1.6k
Scaling GitHub
holman
464
140k
Practical Orchestrator
shlominoach
192
12k
WENDY [Excerpt]
tessaabrams
14
40k
Transcript
2026年08月 Auroraは速いRDSではない ストレージ層を作り直した、別のデータベース 赤神青空
▪料金表で並んでいると、そう見える 上位プランだと思っていた 「AuroraはRDSの高い版で、そのぶん速い」 私はずっとそう理解していました。 何が困るか 速い理由が分からないので、 選ぶ理由も言えない。 今ココ はじめに 実際に困ること
移行したら請求が想定と違った、を 説明できない。 今回やること 中で何が違うのかを、1枚の図で 押さえる。 2/12
▪誤解には、ちゃんと理由がある 上位版に見える理由 外から見ているぶんには、本当にRDSの延長に見えるように作られています。 MySQLとPostgreSQLの互換なので、SQLはそのまま 接続方法もドライバも変えなくてよい コンソール上でもRDSの中に並んでいる 同じエンジンならスナップショットから載せ替えられる だから「速いRDS」で説明がついてしまう 今ココ はじめに
3/12
▪どこが「速い」のか Auroraの正体 AuroraはMySQL・PostgreSQL互換のまま、 ストレージ層だけを別物に置き換えたDBである。 従来のRDB 1台のインスタンスがディスクを 抱え、複製も自分でする。 今ココ 正体 Aurora
計算とストレージを分離し、 共有ストレージを全員で見る。 効いてくる場所 レプリカ追加・フェイルオーバー・ 復旧が速くなる。 4/12
▪レプリカがデータのコピーを持たない 計算とストレージの分離 計算層(インスタンス) ライター 書き込みはここだけ リーダー 1 リーダー 2 最⼤15台まで追加できる
データのコピーは持たない 1つのボリュームに⾒えるが、実体は散っている アベイラビリティゾーン a ✓ ✓ アベイラビリティゾーン b ✓ アベイラビリティゾーン c ✓ GBごとに2コピー GBごとに2コピー GBごとに2コピー 壊れたら、その10GBだけ 他から作り直される 単⼀の装置があるのでは なく、断⽚の集まり ここが丸ごと落ちても 書き込みは⽌まらない 書き込み 4つ必要 2つ失っても⽌まらない 読み取り 3つ必要 3つ失っても続けられる 守れない範囲 リージョン障害と操作ミス 6コピーは同⼀リージョン内の話。DELETE は6コピーすべてに忠実に反映される。 1つのボリュームに見えるが、実体は10GB単位で6コピーに散っている 今ココ 正体 5/12
▪壊れることを前提にした数え方 6コピーとクォーラム データは3つのAZに2コピーずつ、計6コピー。全部揃うのを待たずに合意を取ります。 書き込みは6つのうち4つ揃った時点で確定 AZが1つ落ちても書き込みは止まらない 読み取りは、通常はクォーラムを取らない どのコピーが最新かを追跡し、1つから読む 3つ揃える読み取りは障害復旧のときだけ 10GB刻みで自動修復・自動拡張(最大128TiB) 今ココ
正体 6/12
▪同じ「リードレプリカ」でも中身が別物 レプリカの作られ方が違う RDSのリードレプリカ 各レプリカがデータを丸ごと持つ 追加のたびにコピーが走る 遅延はレプリケーション由来 ストレージ費がレプリカ数ぶん Auroraのリードレプリカ 同じストレージを全員で参照する 追加が速く、台数を増やしやすい
遅延は概ねミリ秒台 ストレージ費は1つぶんで済む 最大15台。3台に増やしてもストレージ代は変わりません。 今ココ 速さの理由 7/12
▪切り替わりを隠しているのは、この仕組み 接続先は4つある クラスター リーダー カスタム インスタンス 今ココ 速さの理由 常にライターを指す。書き込みはここ リーダー群に自動で振り分ける
指定したインスタンス群だけに向ける 個別の1台を名指しする。運用・調査用 8/12
▪Auroraで一番事故が起きる分岐 Standard と I/O-Optimized Aurora Standard ストレージ $0.10/GB-月 I/O が別課金
$0.20/百万 小さなトランザクション多発で膨らむ 事前に読みにくい Aurora I/O-Optimized ストレージ $0.225/GB-月 I/O は追加課金なし 金額が予測しやすくなる インスタンス単価も上がる 目安はI/Oが総額の25%を超えたらI/O-Optimizedへ。 今ココ 代償 9/12
▪移行して初めて気づく種類の費用 数字で押さえる $0.20 100万 I/O Standardのみ。月10億で$200 今ココ 代償 25% 切り替えの目安
I/Oが総額に占める割合 +30% インスタンス単価 I/O-Optimized側の上げ幅 10/12
▪RDSには無い、あるいは形が違うもの 分離だからできること 独自機能に見えるものは、だいたい共有ストレージがあるから成立しています。 Backtrack … 復元せずに時間を巻き戻す(MySQL互換) 高速クローン … 実データを複製せず別クラスターを作る Global
Database … 別リージョンへサブ秒で複製 高速復旧 … ログの適用をストレージ側が引き受ける Global Databaseの複製I/Oだけは例外 I/O-Optimizedにしても、そこは課金され続ける 今ココ 恩恵 11/12
▪速い理由が言えると、選ぶ理由も言える まとめ 01 Auroraは「速いRDS」ではない ストレージ層を別物に作り直した結果として速くなっている。 02 レプリカと切り替えの速さは分離の帰結 レプリカがデータを持たないので、追加も切り替えも軽い。 03 代償はI/O課金という形で来る
25%を目安に構成を選ぶ。移行後は必ず請求の内訳を見る。 今ココ まとめ 12/12