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
データベースとストレージのレプリケーション入門 / Intro-of-database-and...
Search
Kohei Ota
January 27, 2022
Technology
28
6.4k
データベースとストレージのレプリケーション入門 / Intro-of-database-and-storage-replication
社内で若者向けに作ったデータベースとストレージの入門資料です
Kohei Ota
January 27, 2022
Tweet
Share
More Decks by Kohei Ota
See All by Kohei Ota
CloudNative Meets WebAssembly: Exploring Wasm's Potential to Replace Containers
inductor
4
2.9k
The Cloud Native Chronicles: 10 Years of Community Growth Inside and Outside Japan
inductor
0
130
Cracking the KubeCon CfP
inductor
2
620
KubeCon Recap -Platform migration at Scale-
inductor
1
1k
コンテナビルド最新事情 2022年度版 / Container Build 2022
inductor
3
530
KubeConのケーススタディから振り返る、Platform for Platforms のあり方と その実践 / Lessons from KubeCon case studies: Platform for Platforms and its practice
inductor
3
850
オンラインの技術カンファレンスを安定稼働させるための取り組み / SRE activity for online conference platform
inductor
1
1.3k
Kubernetesネットワーキング初級者脱出ガイド / Kubernetes networking beginner's guide
inductor
22
6.4k
コンテナネイティブロードバランシングの話 / A story about container native load balancing
inductor
2
2.2k
Other Decks in Technology
See All in Technology
2025/07/22_家族アルバム みてねのCRE における生成AI活用事例
masartz
2
110
(HackFes)米国国防総省のDevSecOpsライフサイクルをAWSのセキュリティサービスとOSSで実現
syoshie
5
660
なぜAI時代に 「イベント」を中心に考えるのか? / Why focus on "events" in the age of AI?
ytake
2
540
少人数でも回る! DevinとPlaybookで支える運用改善
ishikawa_pro
1
240
生成AIによる情報システムへのインパクト
taka_aki
1
130
Wasmで社内ツールを作って配布しよう
askua
0
120
CSPヘッダー導入で実現するWebサイトの多層防御:今すぐ試せる設定例と運用知見
llamakko
1
200
「手を動かした者だけが世界を変える」ソフトウェア開発だけではない開発者人生
onishi
11
4.2k
TypeScript 上達の道
ysknsid25
8
750
増え続ける脆弱性に立ち向かう: 事前対策と優先度づけによる 持続可能な脆弱性管理 / Confronting the Rise of Vulnerabilities: Sustainable Management Through Proactive Measures and Prioritization
nttcom
1
160
低レイヤソフトウェア技術者が YouTuberとして食っていこうとした話
sat
PRO
7
5.8k
機械学習を「社会実装」するということ 2025年夏版 / Social Implementation of Machine Learning July 2025 Version
moepy_stats
1
590
Featured
See All Featured
Making Projects Easy
brettharned
116
6.3k
4 Signs Your Business is Dying
shpigford
184
22k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
It's Worth the Effort
3n
185
28k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Building Applications with DynamoDB
mza
95
6.5k
Optimizing for Happiness
mojombo
379
70k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
990
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
760
How to Ace a Technical Interview
jacobian
278
23k
Transcript
データベースとストレージの レプリケーション入門 年 月 日
公開に向けた この資料は新卒 年目、 年目の若手に向け作られた 初心者向けのものです 作者自身も とストレージは得意ではない領域の ため、間違っている箇所があったらこっそり優しく 教えていただけると幸いです
アジェンダ ステートレスとステートフル ステートフルの管理はなぜ大変? アプリケーションとデータベース 特性と 定理 データベースとストレージ ストレージの種類と読み書きの特性 のスケーリング・可用性への基本的な考慮
ステートレスとステートフル ステートレス 状態 が 無い ステートフル 状態 が 有る
ステートレスとステートフル ステートレス 状態 が 無い ステートフル 状態 が 有る たとえば・・・
静的コンテンツ だけを返す サイト → 何回アクセスしても結果が同じ ステートレス 日々アクセスするサイトに応じて内容が変わる ような システム 広告とか → 各ユーザーの傾向に応じてレスポンスが違う ステートフル データベース → 入力 データの追加・変更・削除 によっては 出力も変化する ステートフル
ステートフルの管理はなぜ大変? ステートがあるとその時点でのデータが壊れたときに それを保証するのが大変 ステートがあるとスケールも大変 ステートがあると読み出しと書き込みのタイミングに よって結果が変わるので大変 → 株価の変動や銀行口座など、ミッションクリティカル性 の高いワークロードもある
ステートフルの管理はなぜ大変? ステートフルなアプリ 複数ユーザーからの リクエスト ダウンタイムなしに スケールアップしたい 🤔🤔
ステートフルの管理はなぜ大変? 垂直スケールにすると ステートフルなアプリ 複数ユーザーからの リクエスト ダウンタイムなしに スケールアップしたい 🤔🤔 単にマシンスペックを上げると ダウンタイムが発生
ステートフルの管理はなぜ大変? 水平にスケールすると ステートフルなアプリ 複数ユーザーからの リクエスト 各ユーザーの入力に対する 同期をアプリケーション間 でどうやってとる? ステートフルなアプリ ステートフルなアプリ
アプリケーションとデータベースを分離してみる 層構造にしたがって、アプリケーションと データベースを分離してみましょう
ステートフルの管理はなぜ大変? を分離してみると アプリ 複数ユーザーからの リクエスト アプリ アプリ データベース
ステートフルの管理はなぜ大変? を分離してみると アプリ 複数ユーザーからの リクエスト アプリ アプリ データベース こっちはなんとか スケールできそう
横に並べればダウンタイム も発生しにくくなる こっちは結局 どうすんの? 🤔🤔
結局データベースが大変なことに データベースのスケーリングを理解するには データベースの特性を理解する必要があります
データベースの重要な性質 データはアプリケーションよりも寿命が長い データベースはアプリケーションよりも止めるのが 難しい データベースはアプリケーションよりも構造を変える のが難しい
データベースの重要な性質 データはアプリケーションよりも寿命が長い データベースはアプリケーションよりも止めるのが 難しい データベースはアプリケーションよりも構造を変える のが難しい データベースはサービスが終了しても 活用される場合がある アプリケーションは壊れても一時的な ダウンで済むが、データは壊れたら
サービスが死ぬ データベースは色んな所から参照され ている場合がある データ分析や機械 学習のバッチ処理など
大事なことなのでもう一度 データベースのスケーリングを理解するには データベースの特性を理解する必要があります
データベースに関する便利な資料 データベースのスケーリングを理解するには データベースの構造を理解する必要があります
データベースに関する便利な資料 データベースのスケーリングを理解するには データベースの構造を理解する必要があります
特性と 定理 は以下 つの言葉の頭文字 原子性 一貫性 独立性 永続性 データベースのトランザクション処理に 関する
つの重要な性質
特性と 定理 は以下 つの言葉の頭文字 原子性 一貫性 独立性 永続性 データベースのトランザクション処理に 関する
つの重要な性質 💡トランザクションとは?💡 データの処理における一連のやり取りのこと 書き込みや読み込みを完了するまでの一連の流れ
特性と 定理 は以下 つの言葉の頭文字 原子性 一貫性 独立性 永続性 データベースのトランザクション処理に 関する
つの重要な性質 トランザクションは完全に実行が完了するか 全く実行されないかのどちらかでないといけない → 処理の一部だけが行われている状態は 銀行の処理とか考えるとわかりやすい
特性と 定理 は以下 つの言葉の頭文字 原子性 一貫性 独立性 永続性 データベースのトランザクション処理に 関する
つの重要な性質 トランザクションの状態に関わらず データベースの整合性は維持しないといけない → 実行結果が矛盾してはいけない
特性と 定理 は以下 つの言葉の頭文字 原子性 一貫性 独立性 永続性 データベースのトランザクション処理に 関する
つの重要な性質 トランザクションを同時に行った場合でも 各トランザクションは他の処理結果の影響を 受けてはならない → 実行結果が矛盾してはいけない
特性と 定理 は以下 つの言葉の頭文字 原子性 一貫性 独立性 永続性 データベースのトランザクション処理に 関する
つの重要な性質 トランザクションの結果は障害の有無に関わらず 失われてはいけない → ハードウェア障害後もデータの永続性を保証
特性と 定理 は以下 つの言葉の頭文字 原子性 一貫性 独立性 永続性 データベースのトランザクション処理に 関する
つの重要な性質 トランザクションの結果は障害の有無に関わらず 失われてはいけない → ハードウェア障害後もデータの永続性を保証 ちなみにこれはデータベース スペシャリストなどの試験でも 登場する非常に基本的な の特性です
特性と 定理 は以下 つの言葉の頭文字 一貫性 可用性 分断耐性 分散システムにおけるノード間のやり取り に関する定理
特性と 定理 は以下 つの言葉の頭文字 一貫性 可用性 分断耐性 分散システムにおけるノード間のやり取り に関する定理 誰かがデータを更新したら
必ず更新後のデータが参照できる → データの同一性を保証
特性と 定理 は以下 つの言葉の頭文字 一貫性 可用性 分断耐性 分散システムにおけるノード間のやり取り に関する定理 クライアントが常にデータにアクセスできること
→ 読み込みも書き込みもできる
特性と 定理 は以下 つの言葉の頭文字 一貫性 可用性 分断耐性 分散システムにおけるノード間のやり取り に関する定理 ノードがネットワーク的に分断されても
結果が正しく保たれること → 分散システムの が発生しないこと
特性と 定理 は以下 つの言葉の頭文字 一貫性 可用性 分断耐性 分散システムにおけるノード間のやり取り に関する定理 定理はこれら
つを同時に保証 することはできないという理論
特性と 定理 は以下 つの言葉の頭文字 一貫性 可用性 分断耐性 分散システムにおけるノード間のやり取り に関する定理 定理はこれら
つを同時に保証 することはできないという理論 ただし、最近は の台頭により これを限りなく解決できるような仕組みが できてきた
重視型の 一貫性と可用性を重視した構成 一貫性 可用性 分断耐性 一般的な 、 、 等 とにかく単体の性能を上げて殴るやつ
重視型の 可用性と分断耐性を重視した構成 一貫性 可用性 分断耐性 や など とにかく分散させて書き込み性能を上げる 一時的一貫性を犠牲に結果整合性で帳尻合せ
重視型の 一貫性と分断耐性を重視した構成 一貫性 可用性 分断耐性 や など サーバが増えるとロック待ちにより 可用性が損なわれるが、一貫性を持つ分散
重視型の 一貫性と分断耐性を重視した構成 一貫性 可用性 分断耐性 や など サーバが増えるとロック待ちにより 可用性が損なわれるが、一貫性を持つ分散 他にも
特性があるが 分散 まで踏み込むと内容が 難しいので割愛・・・
データベースとストレージ データベースはデータを管理するミドルウェア データはストレージに保存するもの → ストレージの種類と特性を知るのは大事!
ストレージの種類 ブロックストレージ • やベアメタルにボリュームとしてマウント • 単一ホストからしか見られない • 、 など 経由のものや
のようなネイティブ デバイスもある • マウントしたボリュームには が対応した好きなファイ ルシステム 、 、 、 等 を使える • 性能が高く や のデータ保管に適している
ストレージの種類 ファイルストレージ • やベアメタルにファイルシステムとしてマウント • 複数ホストからの読み書きを受け付ける • や のようなネットワークドライブ •
ファイルシステムをマウントするので 側では選択不可 • 性能はそこそこ、ファイル単位のロック機構があり、 触るファイルが別であれば 書き込みを複数ホストから 同時にできる
ストレージの種類 オブジェクトストレージ • フォルダやデバイスとしてマウントしない、 でアクセスするタイプのストレージ • プログラマブルで大量のファイルを書き込める • 構造化されたメタデータやファイル オブジェクト
単位 での世代管理の仕組みがあり、アプリケーションとの親 和性が高い • 性能は つの中では一番低い • 画像や動画などの保存に使う
ストレージの種類 オブジェクトストレージ • フォルダやデバイスとしてマウントしない、 でアクセスするタイプのストレージ • プログラマブルで大量のファイルを書き込める • 構造化されたメタデータやファイル オブジェクト
単位 での世代管理の仕組みがあり、アプリケーションとの親 和性が高い • 性能は つの中では一番低い • 画像や動画などの保存に使う
のスケーリングにおける基本的な方針 定理でも示されている通り、 の特性に よって取るべき構成は違う ここでは一般的な以下 つの を考える 分散 複数台で構成する場合 ・性能面での可用性
・耐障害性としての可用性 を分けて考えるとわかりやすい
のスケーリングで大事な用語 レプリケーション データの複製 耐障害性を上げるための仕組み シャーディング データを複数台に分散して書き込む仕組み 書き込み分散するので性能向上が見込める
のスケーリングで大事な用語 レプリケーション データの複製 耐障害性を上げるための仕組み シャーディング データを複数台に分散して書き込む仕組み 書き込み分散するので性能向上が見込める
のスケーリング は分断耐性が低い 書き込みのエンドポイントを複数作るのは 難しい シャーディングもやれなくはないが今回は 難しい+複雑になるので割愛 でも 台だけで本番構えると可用性が・・・
のスケーリング は分断耐性が低い 書き込みのエンドポイントを複数作るのは 難しい シャーディングもやれなくはないが今回は 難しい+複雑になるので割愛 でも 台だけで本番構えると可用性が・・・ → レプリケーションを置いてアクティブスタンバイ
構成にし、障害発生時に切り替える構成 なんかはつおいので こういうことがいい感じにできる らしい よくわかってない
のレプリケーション レプリカ プライマリ データベース データを同期 プロキシ 障害発生時には フェイルオーバー 状態監視 ※ただし、
や 単体で クラスタリングとフェイルオーバーまでは 面倒を見ないので ソリューションを別途自前で入れる必要がある
のレプリケーション レプリカ プライマリ データベース データを同期 プロキシ 障害発生時には フェイルオーバー 状態監視 最もシンプルな冗長構成
障害発生時若干のダウンタイムはある サイトを分ければ 構成にも応用可 ※ただし、 や 単体で クラスタリングとフェイルオーバーまでは 面倒を見ないので ソリューションを別途自前で入れる必要がある
のレプリケーション レプリカ プライマリ データベース データを同期 プロキシ 障害発生時には フェイルオーバー 状態監視 データベースのストレージのスナップ
ショットを取得するアプローチもある 愚直な反面即時性には欠ける 定常時にこちらを読み取り専用で 使って負荷を下げるというやり方もある いわゆる リードレプリカ
のスケーリング は可用性が弱点 書き込みしすぎるとロックの原因になる シンプルで書き込みが特定箇所に集中 しないデータを保管するのに向いている オンメモリなので高速 裏を返すとメモリなのでコストは高い → で取得するまでもないデータや、 一時的なキャッシュを保存するのに使いやすい
のレプリケーション レプリケーション マスター スレーブ スレーブ スレーブ データの同期
のレプリケーション レプリケーション マスター スレーブ スレーブ スレーブ 読み込みはスレーブ からできる マスターで 障害発生
マスターが書き込みの 単一障害点 データの同期
のレプリケーション 構成 マスター スレーブ スレーブ スレーブ データの同期
のレプリケーション 構成 マスター スレーブ スレーブ スレーブ マスターに昇格 データの同期 マスターで 障害発生
フェイルオーバー
のレプリケーション クラスター マスター スレーブ スレーブ スレーブ マスター マスター
のレプリケーション クラスター マスター スレーブ スレーブ スレーブ マスター マスター レプリケーションによる耐障害性 シャードによる書き込み性能の向上
マスターのフェイルオーバーなど全部盛り盛り
の構成比較 構成 シンプルさ フェイルオーバー 書き込み分散 レプリケーション ◯ ✕ ✕ △
◯ ✕ クラスター ✕ ◯ ◯
まとめ ストレージも も、特性を理解すると活用法が 見えてくる データベースの仕組みだけでも知っておくと、 インフラ屋さんとして役立つかも!! ストレージは製品もあるので勉強しましょう 可用性には性能維持と耐障害性の観点がある レプリケーションとシャードは抑える と
の特性に合わせ構成を考えると◎
None