こんにちは、4年目エンジニアの nakaSay です。普段は在庫管理システムのフロントエンド・バックエンドの開発を行っています。
ただいま「データベースのきほん」という書籍の内容をかい摘み、いくつかのパートに分けて記事を投稿しています。
本書籍は入門書であり、記事では以下のような内容を取り上げる予定です。気になった方は是非気軽にお立ち寄りください。
- データベースの全体像
- リレーショナルデータベースとは
- データベースに関わるお金の話
- データベースとアーキテクチャ構成
- DBMS を操作するときの基本知識
- SQL文の基本
- トランザクションと同時実行制御
- テーブル設計の基礎
- バックアップとリカバリ
アーキテクチャとは
アーキテクチャとは、「どのような機能を持ったサーバを用意し、どのようなストレージやネットワーク機器と組み合わせてシステム全体を作り上げるか」というハードウェアとミドルウェアの構成を指します。
この構成を、システムが果たすべき目的と照らし合わせながら決めていくこと、それが「アーキテクチャ設計」です。
ここを極めようとするとデータベースはもちろん、サーバから OS、他のミドルウェア、ストレージ、ロードバランサにファイアウォールといったネットワーク機器に至るまでの幅広い知識を必要とします。
アーキテクチャという領域は、第3章で取り上げた「お金」の領域と密接な関係を持っています。
システムが予算制約の中で作られ、運用されていくため、想定以上に費用がかかれば頓挫する可能性もあります。反対に、財布の紐を締めすぎて非力なアーキテクチャを選択して失敗することもあり得ます。
「システムに求められる要件を満たすために、どのようなアーキテクチャが適切であるか」ということを考えることなしに、システム構築にかかる費用を算出できません。
また、アーキテクチャは開発終盤で変更することは難しいため、アーキテクチャ設計はシステム開発の序盤で行われる仕事の中でも重要なものになります。
データベースのアーキテクチャの歴史
まずはアーキテクチャの歴史を見ていきましょう。
スタンドアロン
LAN やネットワーク機器に接続されておらず、孤立していることが特徴です。
強み
- ちょっとした作業や試験を手早く行える
- セキュリティリスクが非常に低い
弱み
- 物理的に離れた場所からはアクセスできない
- 複数人での同時作用ができない
- マシンが1台のため、可用性が低い
- 部品交換でしか性能改善できないため、拡張性が乏しい
いくつか強みもありますが、弱みの部分が致命的です。
この弱みを少しずつ改善するため、次世代のアーキテクチャが考案されます。
クライアント/サーバ
エンドユーザが直接操作して処理の命令を発するマシンである「クライアント」、その命令を受けて処理を実行する「サーバ」に分離していることが特徴です。
このアーキテクチャが普及した背景には、Windows シリーズがビジネスシーンでクライアントマシンとして地位を確立したこと、大規模なデータを通信できるネットワーク回線の進化があります。
強み
- 物理的に離れた場所からアクセスできる
- 複数人での同時操作ができる
弱み
- DB へ直接アクセスするリスク
- クライアントへ配布するネイティブアプリの管理（バージョン、バグ修正など）
ここで、スタンドアロン時代にあった致命的な問題がいくつか改善されました。
しかしながら、セキュリティリスクのや管理コストの問題が浮上し、新たなるアーキテクチャが生み出されることになります。
Web3層
クライアントから命令を受けるサーバ部分を、Webサーバ、アプリケーションサーバ、DBサーバの3層に分離していることが特徴です。
クライアントとDBの間にWebサーバ層、アプリケーション層が追加されており、Apache や IIS などのWebサーバ製品、Java や Go などのアプリケーション開発の言語など、皆さんも聞き馴染みのあるものが多いかと思います。
強み
- ユーザからの直接のアクセスをWebサーバ層が受け止めるためセキュア
- ブラウザからアクセス可能なためアプリケーションの管理コストなどがない
- アプリケーション層にビジネスロジックを集約できる
クラサバ構成にあった欠点を見事に解決できる、なかなかよく考えられた構成です。
この構成は現在の Web システムではほぼ標準と言って良い地位を確立しています。
データベースのアーキテクチャを考えよう
Web3層となったことで、データベースはかなり実用的となりました。
ここでは、スタンドアロン時代から問題となっていた「可用性」や「拡張性」はどのように改善されてきたのか説明してきます。
「可用性」とはシステムがどの程度停止しないかを示す指標です。
可用性を上げる 2 つの戦略
- 心臓戦略：高品質 ー 少数戦略
各構成要素（コンポーネント）の信頼性を上げ、障害の発生率を下げる。 - 腎臓戦略：低品質 ＝ 多数路線
「物はいつか壊れるこのだ」という諦念を前提に、予備を用意しておく。
現在は「腎臓戦略」に軍配が上がっていて、この予備を用意しておくことを「冗長化」とも言います。
では、DB サーバにおける冗長化はどのようなものなのかを見ていきましょう
クラスタリング
同じ機能を持つコンポーネントを並列させることが特徴です。
つまり、複数の DB サーバを用意しておき、問題が起きれば予備のサーバを利用する仕組みとなっています。
最も基本的な冗長化の仕組みであり、構成は2つに分かれます。
- Active - Active: クラスタ構成のコンポーネントが同時稼働
- Active - Standby: クラスタ構成のコンポーネントの内、稼働・待機と分かれる
この構成では DB サーバは複数用意されますが、ストレージは1つのため、「シェアードディスク」と呼ばれています。
ストレージは1つのため、DB サーバが増えてもスループット（単位時間あたりの処理性能）の向上には限界があるのですが、それを克服するために「シェアードナッシング」という Google が考案した構成があります。
これはストレージも複数用意するのですが、その名の通りリソースはストレージ間で共有せず、サーバとストレージのセットを並列にする構図となっています。リソースを明確に分離することで負荷分散が実現され、スループットも線形的な向上を見せました。
ただ、全てのデータを揃えるためには各ストレージのデータをまとめた「まとめサーバ」を用意する必要があったり、各ストレージに予備があるわけではないためいずれかのストレージに問題が発生した場合は復旧が困難という課題はありました。
このストレージの予冗長化はデータの同期などいくつか難しい点があるのですが、それを実現する方法が「レプリケーション（複製）」になります。
レプリケーション
DB サーバとストレージをセットで冗長化する。「シェアードナッシング」とは異なり、各ストレージは全リソースを保持しています。
これは単に冗長化としても有用だが、負荷分散という観点でも効果を発揮する方法になっていることが利点です。
参照元であるオリジナルを「マスタ」、参照先の複製を「スレーブ」と言い、「マスタスレーブ」と一般的に表現されますが、お互いにデータを参照し合う「マルチマスタ」も存在します。
まとめ
- データベースにおいて可用性を上げる技術は、「クラスタリング」と「レプリケーション」に大別できる
- クラスタリングには「Active-Active」と「Active-Standby」がある
- Active-Active は DB サーバの負荷分散も行えるが、シングルストレージがボトルネックポイントになる
- ストレージは永続層であり単に冗長化することが難しいため、性能問題を引き起こしやすい
- 「シェアードナッシング」型はストレージの問題が解消できるが、利用できるケースは限られる
- レプリケーションはデータを物理的に遠隔補完することで可用性を高めるための技術だが、負荷分散として利用することもできる
- しかし、クラスタリングもレプリケーションも、作るにはそれなりにコストと工数が必要となり、トレードオフが発生する
参考