そのデータベース壊せますか？ そして直せますか？：データベースエンジニアへの道（6）（1/4 ページ）

はじめに

　本連載の最終回となる今回は、データベースの論理障害をテーマとして取り上げます。データベースエンジニアの仕事としては、これまでの連載で紹介してきたデータベース設計について取り上げられることが多いのですが、論理障害を含むデータベース運用設計は、システムの設計開発より圧倒的に長い保守運用期間を乗り切るために非常に重要な工程です。

　今回のタイトルからも連想されるとおり、当初は「さまざまな方法で本当にデータベースを壊して障害状態を観察し、そこからの復旧作業を疑似体験する」というデータベースの物理障害からの復旧、いわゆるバックアップとデータベースリカバリを予定していました。

　しかし、近々のハードウェア事情を見ると、高性能化、低価格化が進み、安価に冗長性を持った環境を用意できるようになり、ハードウェア障害が直接データベース障害の原因になるケースが少なくなりました。また、OSやDBMSなどのソフトウェアの安定性向上によって、OS、DBMSのクラッシュによる障害も減少しています。また、データベースの物理障害からの復旧方法やバックアップ／リカバリについては、各所でさまざまな情報が多く公開されています。

　反対に、データベースの扱うデータの種類やデータ量は増加している割にデータ障害についての十分な対策が取られていないため、データ障害が増えているように感じられます。以前、筆者が保守していたデータベースシステムで最も多く発生した障害はハードディスク故障でしたが、RAID構成のためディスク交換さえすればそれがデータベース障害につながることはありませんでした。これに対し最も対応に手間取ったのが、ユーザーからの問い合わせにより発覚したデータ障害でした。「登録したはずの日報が見つからない」「伝票の金額が合わない」など、テーブル、データを特定し、個別にデータを修正するという手間のかかる作業が多く発生しました。

　このような理由により、今回はデータベース障害（物理障害）ではなく、データ障害（論理障害）を中心に取り上げることにしました。

今回のスコープ

　本稿ではデータベース運用設計の障害対策・障害回復設計で対策を検討するデータベース障害から、特に論理障害を取り上げます（図1）。前半は、データベースエンジニアにとっての論理障害の位置付けを説明し、後半は、論理障害の予防と対応について障害の具体例を交えながら紹介していきます。

図1　今回のスコープと論理障害の位置付け

論理障害の位置付け

データベース設計とデータベース運用設計の違い

　データベースエンジニアのタスクには、第1回「真のデータベースエンジニアを目指そう！」で紹介したデータベースの「設計・構築」「運用設計」「保守・運用」の3つがあります（表1）。

　これまでの連載で紹介してきたデータベース設計と、今回初めて取り上げるデータベース運用設計は、どちらも何かを設計するという点では共通していますが、この2つは大きく異なる点があります。ここでデータベースを業務システムの構成要素の1つと位置付け、データベース設計と運用設計の両者を業務システム構築の面から比較してみると、前者が「業務システムがユーザーに提供するサービス（業務機能）の設計」であるのに対し、後者は「そのサービスを維持するための設計」である点が異なります。

障害の予防と対応

　データベース運用設計では、データベースが障害状態（＝機能が維持できない状態）に陥らないように、障害対策や障害回復の方法を設計します。そのアプローチには、障害の発生前に行う障害予防と障害の発生後に行う障害対応の2つがあります（図2）。

図2　障害の予防と対応

1．障害予防（障害発生前）

• 障害が発生しない仕組みをシステムに実装する
• 障害の発生を事前に監視・検知する仕組みを保守運用作業に実装する

2．障害対応（障害発生後）

• 障害が発生したときの回復手段を保守運用作業に実装する
• 障害が発生したデータベース、データを回復させる

　障害の予防や対応を検討するには「どうすればデータベースは壊れるのか？」という視点から、データベース、データの設計や仕様を見直し、データベースの壊し方、直し方を熟知しておく必要があります。

　また、データベース運用設計に含まれる監視設計は障害の予防に、バックアップ・リカバリは障害回復に関連しています（図1）。