社内で若者向けに作ったデータベースとストレージの入門資料です
データベースとストレージのレプリケーション入門年 月 日
View Slide
公開に向けたこの資料は新卒 年目、 年目の若手に向け作られた初心者向けのものです作者自身も とストレージは得意ではない領域のため、間違っている箇所があったらこっそり優しく教えていただけると幸いです
アジェンダステートレスとステートフルステートフルの管理はなぜ大変？アプリケーションとデータベース特性と 定理データベースとストレージストレージの種類と読み書きの特性のスケーリング・可用性への基本的な考慮
ステートレスとステートフルステートレス状態 が 無いステートフル状態 が 有る
ステートレスとステートフルステートレス状態 が 無いステートフル状態 が 有るたとえば・・・静的コンテンツ だけを返す サイト→ 何回アクセスしても結果が同じ ステートレス日々アクセスするサイトに応じて内容が変わるような システム 広告とか→ 各ユーザーの傾向に応じてレスポンスが違うステートフルデータベース→ 入力 データの追加・変更・削除 によっては出力も変化する ステートフル
ステートフルの管理はなぜ大変？ステートがあるとその時点でのデータが壊れたときにそれを保証するのが大変ステートがあるとスケールも大変ステートがあると読み出しと書き込みのタイミングによって結果が変わるので大変→ 株価の変動や銀行口座など、ミッションクリティカル性の高いワークロードもある
ステートフルの管理はなぜ大変？ステートフルなアプリ複数ユーザーからのリクエストダウンタイムなしにスケールアップしたい🤔🤔
ステートフルの管理はなぜ大変？ 垂直スケールにするとステートフルなアプリ複数ユーザーからのリクエストダウンタイムなしにスケールアップしたい🤔🤔単にマシンスペックを上げるとダウンタイムが発生
ステートフルの管理はなぜ大変？ 水平にスケールするとステートフルなアプリ複数ユーザーからのリクエスト各ユーザーの入力に対する同期をアプリケーション間でどうやってとる？ステートフルなアプリ ステートフルなアプリ
アプリケーションとデータベースを分離してみる層構造にしたがって、アプリケーションとデータベースを分離してみましょう
ステートフルの管理はなぜ大変？ を分離してみるとアプリ複数ユーザーからのリクエストアプリ アプリデータベース
ステートフルの管理はなぜ大変？ を分離してみるとアプリ複数ユーザーからのリクエストアプリ アプリデータベースこっちはなんとかスケールできそう横に並べればダウンタイムも発生しにくくなるこっちは結局どうすんの？🤔🤔
結局データベースが大変なことにデータベースのスケーリングを理解するにはデータベースの特性を理解する必要があります
データベースの重要な性質データはアプリケーションよりも寿命が長いデータベースはアプリケーションよりも止めるのが難しいデータベースはアプリケーションよりも構造を変えるのが難しい
データベースの重要な性質データはアプリケーションよりも寿命が長いデータベースはアプリケーションよりも止めるのが難しいデータベースはアプリケーションよりも構造を変えるのが難しいデータベースはサービスが終了しても活用される場合があるアプリケーションは壊れても一時的なダウンで済むが、データは壊れたらサービスが死ぬデータベースは色んな所から参照されている場合がある データ分析や機械学習のバッチ処理など
大事なことなのでもう一度データベースのスケーリングを理解するにはデータベースの特性を理解する必要があります
データベースに関する便利な資料データベースのスケーリングを理解するにはデータベースの構造を理解する必要があります
特性と 定理は以下 つの言葉の頭文字原子性一貫性独立性永続性データベースのトランザクション処理に関する つの重要な性質
特性と 定理は以下 つの言葉の頭文字原子性一貫性独立性永続性データベースのトランザクション処理に関する つの重要な性質💡トランザクションとは？💡データの処理における一連のやり取りのこと書き込みや読み込みを完了するまでの一連の流れ
特性と 定理は以下 つの言葉の頭文字原子性一貫性独立性永続性データベースのトランザクション処理に関する つの重要な性質トランザクションは完全に実行が完了するか全く実行されないかのどちらかでないといけない→ 処理の一部だけが行われている状態は銀行の処理とか考えるとわかりやすい
特性と 定理は以下 つの言葉の頭文字原子性一貫性独立性永続性データベースのトランザクション処理に関する つの重要な性質トランザクションの状態に関わらずデータベースの整合性は維持しないといけない→ 実行結果が矛盾してはいけない
特性と 定理は以下 つの言葉の頭文字原子性一貫性独立性永続性データベースのトランザクション処理に関する つの重要な性質トランザクションを同時に行った場合でも各トランザクションは他の処理結果の影響を受けてはならない→ 実行結果が矛盾してはいけない
特性と 定理は以下 つの言葉の頭文字原子性一貫性独立性永続性データベースのトランザクション処理に関する つの重要な性質トランザクションの結果は障害の有無に関わらず失われてはいけない→ ハードウェア障害後もデータの永続性を保証
特性と 定理は以下 つの言葉の頭文字原子性一貫性独立性永続性データベースのトランザクション処理に関する つの重要な性質トランザクションの結果は障害の有無に関わらず失われてはいけない→ ハードウェア障害後もデータの永続性を保証ちなみにこれはデータベーススペシャリストなどの試験でも登場する非常に基本的なの特性です
特性と 定理は以下 つの言葉の頭文字一貫性可用性分断耐性分散システムにおけるノード間のやり取りに関する定理
特性と 定理は以下 つの言葉の頭文字一貫性可用性分断耐性分散システムにおけるノード間のやり取りに関する定理誰かがデータを更新したら必ず更新後のデータが参照できる→ データの同一性を保証
特性と 定理は以下 つの言葉の頭文字一貫性可用性分断耐性分散システムにおけるノード間のやり取りに関する定理クライアントが常にデータにアクセスできること→ 読み込みも書き込みもできる
特性と 定理は以下 つの言葉の頭文字一貫性可用性分断耐性分散システムにおけるノード間のやり取りに関する定理ノードがネットワーク的に分断されても結果が正しく保たれること→ 分散システムの が発生しないこと
特性と 定理は以下 つの言葉の頭文字一貫性可用性分断耐性分散システムにおけるノード間のやり取りに関する定理定理はこれら つを同時に保証することはできないという理論
特性と 定理は以下 つの言葉の頭文字一貫性可用性分断耐性分散システムにおけるノード間のやり取りに関する定理定理はこれら つを同時に保証することはできないという理論ただし、最近は の台頭によりこれを限りなく解決できるような仕組みができてきた
重視型の一貫性と可用性を重視した構成一貫性可用性分断耐性一般的な 、 、 等とにかく単体の性能を上げて殴るやつ
重視型の可用性と分断耐性を重視した構成一貫性可用性分断耐性や などとにかく分散させて書き込み性能を上げる一時的一貫性を犠牲に結果整合性で帳尻合せ
重視型の一貫性と分断耐性を重視した構成一貫性可用性分断耐性や などサーバが増えるとロック待ちにより可用性が損なわれるが、一貫性を持つ分散
重視型の一貫性と分断耐性を重視した構成一貫性可用性分断耐性や などサーバが増えるとロック待ちにより可用性が損なわれるが、一貫性を持つ分散他にも 特性があるが分散 まで踏み込むと内容が難しいので割愛・・・
データベースとストレージデータベースはデータを管理するミドルウェアデータはストレージに保存するもの→ ストレージの種類と特性を知るのは大事！
ストレージの種類 ブロックストレージ• やベアメタルにボリュームとしてマウント• 単一ホストからしか見られない• 、 など 経由のものや のようなネイティブデバイスもある• マウントしたボリュームには が対応した好きなファイルシステム 、 、 、 等 を使える• 性能が高く や のデータ保管に適している
ストレージの種類 ファイルストレージ• やベアメタルにファイルシステムとしてマウント• 複数ホストからの読み書きを受け付ける• や のようなネットワークドライブ• ファイルシステムをマウントするので 側では選択不可• 性能はそこそこ、ファイル単位のロック機構があり、触るファイルが別であれば 書き込みを複数ホストから同時にできる
ストレージの種類 オブジェクトストレージ• フォルダやデバイスとしてマウントしない、でアクセスするタイプのストレージ• プログラマブルで大量のファイルを書き込める• 構造化されたメタデータやファイル オブジェクト 単位での世代管理の仕組みがあり、アプリケーションとの親和性が高い• 性能は つの中では一番低い• 画像や動画などの保存に使う
のスケーリングにおける基本的な方針定理でも示されている通り、 の特性によって取るべき構成は違うここでは一般的な以下 つの を考える分散複数台で構成する場合・性能面での可用性・耐障害性としての可用性を分けて考えるとわかりやすい
のスケーリングで大事な用語レプリケーションデータの複製耐障害性を上げるための仕組みシャーディングデータを複数台に分散して書き込む仕組み書き込み分散するので性能向上が見込める
のスケーリングは分断耐性が低い書き込みのエンドポイントを複数作るのは難しいシャーディングもやれなくはないが今回は難しい＋複雑になるので割愛でも 台だけで本番構えると可用性が・・・
のスケーリングは分断耐性が低い書き込みのエンドポイントを複数作るのは難しいシャーディングもやれなくはないが今回は難しい＋複雑になるので割愛でも 台だけで本番構えると可用性が・・・→ レプリケーションを置いてアクティブスタンバイ構成にし、障害発生時に切り替える構成なんかはつおいのでこういうことがいい感じにできるらしい よくわかってない
のレプリケーションレプリカプライマリデータベースデータを同期プロキシ障害発生時にはフェイルオーバー状態監視※ただし、 や 単体でクラスタリングとフェイルオーバーまでは面倒を見ないのでソリューションを別途自前で入れる必要がある
のレプリケーションレプリカプライマリデータベースデータを同期プロキシ障害発生時にはフェイルオーバー状態監視最もシンプルな冗長構成障害発生時若干のダウンタイムはあるサイトを分ければ 構成にも応用可※ただし、 や 単体でクラスタリングとフェイルオーバーまでは面倒を見ないのでソリューションを別途自前で入れる必要がある
のレプリケーションレプリカプライマリデータベースデータを同期プロキシ障害発生時にはフェイルオーバー状態監視データベースのストレージのスナップショットを取得するアプローチもある愚直な反面即時性には欠ける定常時にこちらを読み取り専用で使って負荷を下げるというやり方もあるいわゆる リードレプリカ
のスケーリングは可用性が弱点書き込みしすぎるとロックの原因になるシンプルで書き込みが特定箇所に集中しないデータを保管するのに向いているオンメモリなので高速裏を返すとメモリなのでコストは高い→ で取得するまでもないデータや、一時的なキャッシュを保存するのに使いやすい
のレプリケーション レプリケーションマスタースレーブスレーブスレーブデータの同期
のレプリケーション レプリケーションマスタースレーブスレーブスレーブ読み込みはスレーブからできるマスターで障害発生マスターが書き込みの単一障害点データの同期
のレプリケーション 構成マスタースレーブスレーブスレーブデータの同期
のレプリケーション 構成マスタースレーブスレーブスレーブマスターに昇格データの同期マスターで障害発生フェイルオーバー
のレプリケーション クラスターマスタースレーブスレーブスレーブマスターマスター
のレプリケーション クラスターマスタースレーブスレーブスレーブマスターマスターレプリケーションによる耐障害性シャードによる書き込み性能の向上マスターのフェイルオーバーなど全部盛り盛り
の構成比較構成 シンプルさ フェイルオーバー 書き込み分散レプリケーション ◯ ✕ ✕△ ◯ ✕クラスター ✕ ◯ ◯
まとめストレージも も、特性を理解すると活用法が見えてくるデータベースの仕組みだけでも知っておくと、インフラ屋さんとして役立つかも！！ストレージは製品もあるので勉強しましょう可用性には性能維持と耐障害性の観点があるレプリケーションとシャードは抑えると の特性に合わせ構成を考えると◎
inductor
yoshikieguchi
doradora09
nihonbuson
soracom
eiki
oracle4engineer
sakaguchi
bun913
honma12345
tenforward
goyoki
scottboms
denniskardys
bryan
tammielis
paulrobertlloyd
hannesfritz
phodgson
chrislema
geoffreycrofte
panda_program
matthewcrist
searls