データベースとストレージのレプリケーション入門 / Intro-of-database-and-storage-replication

社内で若者向けに作ったデータベースとストレージの入門資料です

Transcript

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