Web3.0への移行を前にして、クラウドやマイクロサービスアーキテクチャなど、分散システム(distributed systems)の構築が各所で試みられています。分散システムは、高いスケーラビリティやコストパフォーマンス、障害耐性・可用性の高さなどのメリットが期待できる一方、運用やデータ管理において複雑性が増すため、注意しなければならないポイントも少なくありません。
その中でも必ず押さえるべき考えの一つが本記事で取り上げる「データ整合性」です。
この記事では、「データ整合性」の正確な概念や「CAP定理」など分散システムの導入・運用担当者が知っておくべき基本をご紹介します。さらに「コンフリクト(競合)の解決」「データバックアップ」などデータ整合性にまつわる具体的な手法についても解説します。
「データ整合性」とは、‟システム内のデータが正確かつ一貫性を保った状態”を指す用語で、データベースの信頼度にかかわる要素です。
例えば、あなたがEコマース事業の在庫管理を担当していると考えてみてください。
在庫管理システムのデータが、商品が売れた直後に正確に更新されなければ二重販売や顧客への誤った情報提供につながり、企業の信頼性にかかわります。このようにデータ整合性は、データベースを保有・利用する企業やサービス提供者にとって事業の安定性や顧客からの信頼性に直接影響をおよぼす事項です。
金融や医療などの業界ではより厳密なシステムの信頼性が求められることもあり、データの整合性に向けられる意識は一段と高まります。
分散システムにおいて特にデータの整合性が問題にされるのは、その特性に由来するトレードオフに起因します。このトレードオフを明確に説明する理論が「CAP定理」です。CAP定理とは、分散システムが以下の三つの性質のうち同時に二つまでしか満たせないという考え方です。
定義:すべてのノード(計算リソース)が最新の同じデータを保持している
例:銀行の残高照会で、どのATMから確認しても常に正確な残高が表示される
定義:システムが常にリクエストに応答できる。特定のノードがダウンしていても、ほかのノードが代替して応答を返す
例:オンラインショップがどんなにアクセスが集中しても注文を受け付けられる
定義:システムがネットワーク分断(ノード間の通信が一時的に途絶える状態)によってストップせず、個別に機能できる
例:地理的に離れた複数のデータセンターが、一時的に通信できなくなってもそれぞれ独立して機能する
分散システムの運用では、CAP定理の理解を深め、用途に応じた適切なアプローチを採用することが、データ整合性を維持する鍵となります。CAP定理はあくまで分散システムを理解するための明快な考え方であり、現実にはそれぞれの特性の中で度合いやバランスを調整してさまざまな選択肢が取られます。例えば、「結果整合性」と「強整合性」はその際に用いられる指標として最もポピュラーな分類です。
定義:短期的にデータの一貫性を犠牲にし、全ノード間でデータの同期が完了するまで一時的な不整合を許容するモデル
有効なケース:ソーシャルメディアやEコマースのカート管理など短期間のデータ不一致がUXや信頼性に大きな影響を与えない場合
定義:インシデント発生時の可用性を犠牲にし、データの更新が行われた際に、その変更が即座にすべてのノードに反映されることを保証するモデル
有効なケース:金融取引システムや医療情報システム、在庫管理システムなどデータの整合性を最優先すべき場合
分散システムにおいて、複数のノードやクライアントが同時に同じデータに対して操作を行い、矛盾した結果が発生するコンフリクト(競合)は代表的な課題です。以下に代表的なコンフリクト解決手法を解説します。
トランザクション管理は、分散システムにおいてデータの整合性を維持するための基本的な手法です。トランザクションとは、一連の操作を一つのまとまりとして処理する仕組みであり、すべての操作が完了するか、あるいはすべてがキャンセルされる(ロールバック)ことを保証します。トランザクション管理における排他制御は、同時に複数のクライアントが同じデータを更新しようとする場合に競合を防ぐ役割を果たします。また排他制御においては、以下の二つの代表的な考え方が存在します。
・楽観的ロック(Optimistic Locking)
バージョン番号を比較するなどして、データ更新時に競合が発生した場合のみエラーを検出し、競合を解決します
適用シーン: データ競合の頻度が低い場合
・悲観的ロック(Pessimistic Locking)
データ更新中はほかの操作をブロックすることで競合を防ぎます
適用シーン: 競合が頻発する場合
バージョン管理は、データにバージョン番号やタイムスタンプを付与し、どの更新が最新のものであるかを識別することでコンフリクトを解決する手法です。各更新時にバージョンを比較し、競合が発生した場合には最も新しいデータを採用する、または手動でのマージを行います。分散型バージョン管理システムとして代表的なものに、Gitが挙げられます。
クォーラム(Quorum)は、分散システムでデータを操作する際に、ノードの多数派で合意を形成して整合性を確保する方法です。クォーラムは読み取り・書き込みに必要なノードの数を定義し、これを満たすことでデータの正確性を保証します。その際、単純な過半数の意見を集めるだけでなく、読み取り(Read)と書き込み(Write)の操作において、システム全体の整合性を保証するための基準が設けられます。その際、ReadとWriteのバランスを調整することで、一貫性と可用性のバランスを取りながら柔軟な分散システムの設計が行える点が、クォーラムを用いた整合性確保のメリットです。
特定のアプリケーション要件に基づいて独自のロジックを設計する方法です。競合の性質やデータの重要性に応じて、カスタマイズされた解決策を実装します。例えば、以下のようなケースが例として挙げられます。
・Eコマース:
在庫管理で、最初に確定した注文を優先し、それ以外をキャンセル
・ソーシャルメディア:
投稿の統合時に、すべての更新内容を結合する
この際、個別にロジックを設定することでシステム要件に応じて設計が複雑化しやすくなり、保守が難しくなる可能性があることには注意が必要です。
ブロックチェーンは、データを「ブロック」という単位で記録し、これをチェーン状に繋げた構造を持つ分散台帳システムです。ブロックチェーンでは、新しいデータ(トランザクション)が正しいかどうかを全ノードで合意(コンセンサス)することにより、ネットワーク全体で一貫性のあるデータ状態を保ちます。これにより高い信頼性と不変性が保証されるとともに、コンセンサスアルゴリズムにより、中央集権的な調整が不要となります。ただし、高い信頼性を確保するため、トランザクションの処理速度が犠牲になることがあったり、実装の複雑性が高かったりするなどの課題も存在します。
分散システムにおけるコンフリクト解決には、データの特性やシステムの要件に応じた多様なアプローチがあります。競合の頻度や影響、性能要件を考慮し、適切な解決手段を選択することが重要です。
分散システムの利用においても、システム障害やヒューマンエラー、サイバー攻撃などによってデータを復旧する必要が生じる可能性は常に意識しておかなければなりません。その際、適切なバックアップ戦略を取ることがデータ整合性を早急に取り戻し、システムの安定稼働を実現するためには不可欠です。
バックアップの方法にはいくつかの選択肢があります。フルバックアップは、データベース全体を完全な形で保存する方法で、システム全体の整合性を保証する復旧手段として活用されます。一方、トランザクションログを利用する差分バックアップやスナップショットを利用する増分バックアップでは、より小さい単位で、ストレージ容量を節約しながら、復旧の効率性を高めることができます。
トランザクションログ:データベース内の変更履歴を時系列順に記録したログデータ。トランザクション単位で整合性を確保可能
スナップショット:データベース全体または特定時点の状態をキャプチャしたデータ。作成時点のデータ状態しか保存されない一方、高速な復旧が可能
実際の運用では、定期的なフルバックアップをベースに、差分バックアップや増分バックアップを組み合わせることとなります。また、復旧が成功するかどうかは実際に試すまで分からないため、リストアテストを定期的に実施することも重要です。これにより、バックアップデータが正常に機能し、整合性が保たれているかを確認できます。
さらに、これらのバックアップ手法は、データベースのトランザクション管理と組み合わせることで、より高い整合性を実現します。例えば、トランザクションが完全にコミットされた後にバックアップを取得することで、未完了の操作による不整合を防ぐことができます。
分散システムを構築、運用するにあたって押さえておくべきデータ整合性の保ち方について、基礎から解説しました。近年、企業が利用するデータの量・種類は拡大を続けており、分散システムの普及も手伝ってデータの整合性に関する知識がより求められるようになっています。この記事を、トレンドや業界に合わせて、あるべき「整合性」の保ち方を探るヒントとしてご活用ください。