ハードウェアが「うそ」をつく?
完璧なDBでも壊れる――「コミット成功」なのにデータが消えかねない3つの問題
業務システムにおいて、データベースへの保存処理の完了は「データが安全に守られた」ことを意味するとは限らない。データの破損を招きかねない、インフラ層が抱える3つの構造的な問題とは。
システムのクラウド化が進み、インフラがブラックボックス化する現代において、ストレージ層の物理的な制約を意識する機会は減少している。業務システムにおいて、データベースへのデータ保存は「できて当たり前」だと認識され、コミット(確定処理)が成功すればデータは永続化されたと安心するのが一般的だ。しかし、データベースエンジン、OS、物理的なストレージデバイス間で仕様の認識に食い違いがあれば、最悪の場合、致命的なデータ消失につながる。
DBaaS(Database as a Service)ベンダーPlanetScaleのインフラエンジニアであるクリス・シンジャクリ氏は、システムの下層に潜むデータ消失のリスクと、データベースがデータを守るための仕組みについて、「データベースをレプリケーション(複製)していれば安全だというのは誤りだ」と警鐘を鳴らす。個々のノード(サーバ)において、システム異常終了時にもデータ破損を防ぐクラッシュセーフティを確保できていなければ、「破損したデータ」を複製してしまう恐れがあるという。
データベースエンジン、OS、ハードウェア間の認識の食い違いが招く、3つの構造的な問題とは。
MySQLを悩ませる「半書き」と二重書き込みのジレンマ
併せて読みたいお薦め記事
データベース運用のヒント
以下では、システム管理者向けのイベント「SREcon25 Europe/Middle East/Africa」において、シンジャクリ氏がセッション「The Computer Wants to Lose Your Data」で語った3つの構造的課題から、データの永続性を確実なものにするための条件を読み解く。
1つ目の課題は、リレーショナルデータベース管理システム(RDBMS)「MySQL」のデータ書き込み方式に起因する。データベースはデータを効率的に管理するため、一定のブロック単位(MySQLのデフォルトは16KB)でストレージに書き込む。
一方で、一般的なHDDやコンシューマー向けSSDが「完全に実行されるか、全く実行されないか」の不可分(アトミック)な状態で一度に書き込める単位は、512Bから4KB程度にとどまる。もし16KBのデータを書き込んでいる間に電源喪失やシステムクラッシュが発生すると、データの一部だけが上書きされ、残りは古いデータのままになる「Torn Write」(半書き)という状態に陥る。この状態ではデータの構造が破壊され、変更履歴を記録した復旧用のファイル(トランザクションログ)さえ適用が不可能になる。
この致命的な破損を防ぐための仕組みとして、MySQLに備わっているのが、データ保護のために一時的に書き込む専用領域「Doublewrite Buffer」(ダブルライトバッファー)だ。データをテーブルに書き込む前に、まず専用領域に記録することで、もしテーブルへの書き込み中にクラッシュが発生しても、バッファーから正常なデータを復旧できる仕組みを構築している。
しかし、同じデータを2回ディスクに書き込むため、パフォーマンスの低下は避けられない。シンジャクリ氏によれば、これを安全に回避する手段として2つのアプローチが存在する。1つ目は高度なデータ保護機能を備えたファイルシステム「ZFS」(Zettabyte File System)を採用し、16KB単位での書き込みをソフトウェアレベルで保証することだ。2つ目は、16KB以上のデータを一括で書き込める仕様を持つ、エンタープライズグレードのNVMe(Non-Volatile Memory Express)接続SSDを利用することだ。こうした特性を持つストレージを用意できれば、インフラ担当者は二重書き込みを無効化し、安全性とパフォーマンスを両立させることが可能になる。
PostgreSQLの「fsyncgate」が示す低レイヤーの残酷さ
2つ目の課題は、2018年にRDBMS「PostgreSQL」のコミュニティーで見つかった、「fsyncgate」と呼ばれるバグだ。
データをディスクに確実に書き込んだことを保証するため、データベースシステムは「Linux」のカーネル(OSの中核機能)である「fsync」を実行する。fsyncは、メモリ上のデータを物理ディスクに確実に保存するよう指示する機能だ。
通常、fsyncが「成功」を返せばデータは永続化されたと見なされる。しかし当時のLinuxカーネルでは、書き込み時のI/O(入出力)エラーが発生し、fsyncがエラーを返した後、もう一度fsyncを呼び出すと「エラー状態がクリアされて成功を返してしまう」という挙動が存在していた。エラー発生時に再試行する設計だったデータベースは、実際には書き込まれていないデータを「保存完了」と誤認し、深刻なデータ破損を引き起こす恐れがあったのだ。
「上位のソフトウェア層は、下位層のバグや仕様を修正できない」とシンジャクリ氏は指摘する。PostgreSQL開発チームは、fsyncがエラーを返した場合は再試行せず、直ちにデータベースプロセスを強制終了させる決断を下した。一見すると乱暴な手法に見えるが、これ以上書き込みを続けて不整合を広げるよりも、即座にシステムを停止させて既知の安全な状態から復旧するか、正常なノードに切り替える方が、データの完全性を守るためには理にかなっているためだ。
ハードウェアがつく「うそ」と揮発性キャッシュの死角
3つ目の課題は、ストレージデバイス自身が持つ「揮発性ライトキャッシュ」(電源が切れると消えてしまう一時的な高速データ保存領域)の問題だ。HDDやSSDには、書き込み速度の向上や突発的な負荷への対応のために、RAMを用いたキャッシュ領域が搭載されている。
OSからフラッシュ(書き込みの確定)の要求があった場合、ストレージデバイスはキャッシュ内のデータを不揮発性の領域に移す必要がある。しかし、コンシューマー向けの安価なストレージデバイスの一部には、読み書き速度を高く見せるために、データがまだ揮発性のキャッシュにとどまっているにもかかわらず「書き込み完了」とOSに“うその応答”を返すものがある。この状態で電源が失われれば、データは確実に消え去る。
パフォーマンスと安全性を両立させるためのインフラ担当者の選択は、物理的な電源バックアップの導入だ。具体的には、停電時に内蔵電池でデータを保護する「バッテリーバックアップ機能」(BBU)を備えた、複数の記憶装置を制御する専用機器「ハードウェアRAIDコントローラー」を使用するか、大容量のキャパシター(コンデンサー)を搭載したエンタープライズ向けSSDを採用することだ。これによって、想定外の電源喪失時にも内蔵電力を使ってキャッシュ内容を安全に退避させることが可能になる。
「システムは時として、データを守ろうとする努力を裏切り、データを消し去ることがある。データベースを安定稼働させるためには、ソフトウェアの堅牢(けんろう)性だけではなく、ハードウェアを含めたインフラ全体における特性を理解し、適切に投資する必要がある」とシンジャクリ氏は総括した。インフラのクラウド化が進む現代においても、物理層の仕様や制約に対する深い洞察は、システムの信頼性を確保するエンジニアにとって不可欠だ。
本稿は、USENIXが2025年11月12日に公開した動画「SREcon25 Europe/Middle East/Africa - The Computer Wants to Lose Your Data」を基に作成しました。
Copyright © ITmedia, Inc. All Rights Reserved.
本記事は制作段階でChatGPT等の生成系AIサービスを利用していますが、文責は編集部に帰属します。
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社うるる] 「入札市場」攻略ガイド:効率的に落札するためのポイントを徹底解説 -
製品資料
[株式会社うるる] 入札情報に特化した「販路拡大」「効率化」のためのサポートツールとは? -
市場調査・トレンド
[株式会社うるる] 公共入札に成功する企業と失敗する企業の「5つの違い」 -
製品資料
[日本ビジネスシステムズ株式会社] 専門家が教える、Microsoft 365の「テナント統合/分離」を成功に導く秘訣 -
製品資料
[rakumo株式会社] Microsoft 365での情報埋没を防ぐ、社内ナレッジを資産化する情報ポータル活用
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
「Microsoft 365」が乗っ取られる MFAを破る“本物の画面”の恐怖
-
2
PHP脆弱性「PHP2Shell」で2260万件に影響 情シスの緊急チェックリスト
-
3
半数がブルーカラー転向を視野に? ベテランエンジニアを追い込む“54歳の壁”
-
4
「Windows」の不要なファイルを安全に消して容量を空ける方法
-
5
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
6
「有線LAN環境」に関するアンケート
-
7
データセンター事業者が「脱VMware」をした“例のライセンス問題”じゃない理由
-
8
積水化学工業が「SAP S/4HANA Cloud」の“全グループ導入”に踏み切った訳
-
9
生成AIが普及しても「技術書」を手放せないエンジニアの本音
-
10
「テザリング依存」に潜む落とし穴 “遅いVPN”を解消するネット構築術
ホワイトペーパーランキング PR
-
1
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
2
2026年のサイバーセキュリティには何が必要か? 最新データに学ぶ傾向と対策
-
3
経験豊富な即戦力人材に直接アプローチできる、「攻めの採用」への転換術
-
4
「IT史に名を残すシステム障害」8選
-
5
最速72分でデータが流出? 最新の脅威トレンドや侵入手法から分かった防衛策
-
6
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
7
Microsoft 365のメールセキュリティ、3つの“死角”と追加で検討すべき対策とは
-
8
AI駆動開発のスピードと安全性を両立 「品質・セキュリティ管理」の実践ガイド
-
9
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
-
10
「標的型攻撃メール」事例・サンプル集
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー