DBのアーキテクチャ
Daily Blogging43日目
なんだかんだもうすぐ50回目を迎えそう
引き続きおうちで学べるデータベースのきほん読んでる
今日はDBのアーキテクチャについてアウトプットしていくぅ
アーキテクチャって何?
そもそもアーキテクチャって色々な意味を含んでいるけど、この本ではこういう意味
システムを作り上げるための物理的レベルの組み合わせ
ハードウェアとソフトウェアの組み合わせを指す。
目的あってこそのアーキテクチャ
アーキテクチャは、システムが達成すべき目的をきちんと達成できるようにするために設計するもの。
目的なしにアーキテクチャを考えることはできないので、まずはシステムの目的が何かをちゃんと考える必要があるよ
きちんと目的を持って設計されたアーキテクチャは、みるだけでシステムの目的と機能がわかるらしく、プロジェクトに途中参加するエンジニアはまず「アーキテクチャ設計書を見せてください」っていうらしい。
※そんなこと言ったことない
DBのアーキテクチャは3種類
- スタンドアロン
- クラスタリング
- レプリケーション
ざっくりいうと、
スタンドアロンは非冗長な構成、クラスタリングとレプリケーションは冗長な構成
スタンドアロン
単一のDBサーバで稼働する
障害があった時にはもうおしまい
いわゆるSPOFになる
→単一障害点
冗長化
DBサーバの冗長化は他のサーバと比べて冗長化がちょっと難しい
その理由は、永続的なデータを管理しているため
→冗長的なデータの整合性を取るのが大変
データ部分、ストレージを冗長的にするかどうかで構成が変わる
ちなみに、クラスタリング、レプリケーションは併用可能
クラスタリング
DBサーバのみの冗長化構成
DBサーバ自体は複数構成にしているけど、ストレージ部分は共有
レプリケーション
DBサーバに加えて、ストレージも冗長化した構成
ストレージも冗長化することで、データそのものが障害や災害で破損したときにもサービスを継続ができる高い可用性を発揮することができる。
また、負荷分散のために読み取り専用で作られるセットのことを、リードレプリカという
シェアするかしないか
クラスタリングでもレプリケーションでも、冗長化したコンポーネントを起動しっぱなしにするかしないかでまた話が変わってくる。
- Active-Active
- 冗長化したコンポーネントがいずれもActiveな状態である
- Active-Standby
- コンポーネントを全て同時に稼働させずに、障害時などにStandbyからActiveに切り替える
Active-Activeの時に、ストレージで問題が起こる。
全部稼働中ということは、データの書き込みが同時多発的に発生する可能性があり、整合性取るのがめちゃくちゃ大変だということ。
この問題を解決するための方法が、シェアードナッシング
シェアードナッシング
文字通り、何も共有しないこと。
ストレージなど、ネットワーク以外のリソースは全部共有しないスタイル
ストレージの共有がないので、特定のwebサーバからは特定のストレージにしかアクセスできない。
シェアードエブリシング
逆に全部共有するスタイル。
ストレージもみんなで一つ
みんなで書き込みとかできるので整合性保つの大変
Auroraはハイブリッドタイプ
AWS Auroraはそれぞれのアーキテクチャのいいとこどりをしてるサービスだった
クラスタリング
DBサーバのクラスタリングじゃないけど
- 複数のDBインスタンスで構成されるクラスタを持つ
- プライマリインスタンス (Writer) とリードレプリカ (Reader) を持つ構造になっており、フェイルオーバー時にリーダーがプライマリに昇格する仕組み
- Aurora マルチマスター構成(MySQL 互換のみ)では、複数のノードが書き込みできるクラスタリングの特徴を持つ
レプリケーション
- マルチAZで、6つのコピーを自動で管理(3つのAZにまたがるストレージレイヤーで合計6つのデータコピー)
- リードレプリカを複数作成でき、読み取り負荷を分散できる
シェアしてるしシェアしてない
シェアードナッシングとシェアードエブリシングのハイブリッドでもある
- シェアードナッシング
- WriterとReaderで分かれているので、ナッシング的な要素を持つ
- シェアードエブリシング
- マルチAZでストレージを共有しているので、エブリシング的な要素ももつ
Discussion