単一障害点（SPOF）の排除は、エンタープライズシステムにおける基本要件です。データベース層における高可用性（HA）戦略は、単にサーバーを冗長化するだけでなく、データの一貫性（Consistency）、復旧時間目標（RTO）、および運用コストの複雑なバランスの上に成り立ちます。本稿では、アクティブ-アクティブ（Active-Active）およびアクティブ-スタンバイ（Active-Standby）構成の内部動作と、エンジニアリング観点でのトレードオフを分析します。
1. アクティブ-スタンバイ：確実性とレイテンシ
アクティブ-スタンバイ（Active-Standby / Active-Passive）構成は、プライマリノードのみが書き込み（Write）と読み取り（Read）を処理し、セカンダリノードはデータの同期を受け取りながら待機するモデルです。このアーキテクチャの核心は、VIP（Virtual IP）の切り替えメカニズムとレプリケーション方式にあります。
非同期レプリケーションを採用した場合、プライマリ障害時に未転送のトランザクションログが消失し、データ損失（RPO > 0）が発生するリスクがあります。一方、準同期（Semi-Sync）または完全同期（Sync）レプリケーションはデータの安全性を高めますが、書き込みレイテンシ（Write Latency）にネットワークラウンドトリップ時間が加算されます。
ネットワーク分断により、スタンバイ機が誤って「プライマリがダウンした」と判断し昇格してしまうと、システム内に2つのマスターが存在することになります。これによりデータ不整合が発生します。これを防ぐには、STONITH（Shoot The Other Node In The Head）のようなフェンシングメカニズムが必須です。
フェイルオーバーのロジック
KeepalivedやPacemakerなどのツールを使用し、ハートビート監視を行います。以下は、Keepalived設定におけるVIP移行ロジックの概念的な構成です。
# /etc/keepalived/keepalived.conf snippet
vrrp_instance DB_HA {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
# 認証設定
authentication {
auth_type PASS
auth_pass <SECRET_PASSWORD>
}
# 仮想IPアドレス（アプリケーションはこのIPに接続する）
virtual_ipaddress {
192.168.10.100
}
# ヘルスチェック・スクリプトによる監視
track_script {
chk_mysql_status
}
}
2. アクティブ-アクティブ：スループットと競合解決
アクティブ-アクティブ（Multi-Master）構成では、複数のノードが同時に書き込みを受け付けます。理論上は書き込みスループットが向上するように見えますが、実際には書き込み競合（Write Conflict）の解決とデータ同期のオーバーヘッドがボトルネックとなります。
すべてのノード間でデータを双方向に同期する必要があるため、ノード数が増えるにつれて通信量は指数関数的に増加します（Mesh Topology）。また、同一レコードに対する同時更新が発生した場合、競合解決ロジック（Last Write Wins、あるいはアプリケーション側でのマージ）が必要です。
グローバル規模でActive-Activeを構成する場合、光の速度による物理的なレイテンシは避けられません。CAP定理における「分断耐性（P）」を確保しつつ「可用性（A）」を取るため、結果整合性（Eventual Consistency）を許容する設計が一般的です。
HAProxyによるロードバランシング
アプリケーションとDBの間にロードバランサーを配置し、接続を分散させます。Active-Active構成であっても、デッドロックを避けるために「特定ユーザーの書き込みは特定ノードに固定する（Sticky Session）」戦略が有効な場合があります。
# haproxy.cfg snippet showing connection logic
listen mysql-cluster
bind 0.0.0.0:3306
mode tcp
option mysql-check user haproxy_check
balance roundrobin
# 書き込みノードの定義
server db01 192.168.10.101:3306 check weight 1
server db02 192.168.10.102:3306 check weight 1
# 接続数過多の場合のバックアップ（Sorry Server）
# server db-backup 192.168.10.103:3306 check backup
3. 技術的比較と意思決定マトリクス
アーキテクチャ選定において、単純な「優劣」ではなく、ワークロードの特性に合わせた選択が必要です。以下の比較テーブルを参照してください。
| 評価項目 | アクティブ-スタンバイ | アクティブ-アクティブ |
|---|---|---|
| 複雑性 | 低 (標準的な構成) | 極めて高 (競合解決が必要) |
| データ整合性 | 強整合性 (Strong Consistency) を維持しやすい | 結果整合性になりがち、競合リスクあり |
| リソース効率 | 低 (スタンバイ機がアイドル状態) | 高 (全ノードを活用可能) |
| 障害復旧 (RTO) | 数十秒〜数分 (昇格プロセスが必要) | ほぼゼロ (他ノードが即時応答) |
| 書き込み性能 | 単一ノードの限界に依存 | 分散可能だが同期コストで相殺される可能性あり |
トラフィックが単一のプライマリDBで処理可能なレベルであるにもかかわらず、可用性のみを理由にActive-Active構成を導入することは避けてください。運用の複雑さとデバッグの難易度が飛躍的に向上し、逆にシステム全体の安定性を損なう原因となります。
結論と推奨事項
大半のユースケース、特に厳密なデータ整合性が求められる金融トランザクションや在庫管理システムにおいては、アクティブ-スタンバイ構成が最も堅牢な選択肢です。読み取り負荷が高い場合は、スタンバイ機をリードレプリカとして活用する「Read-Replica」パターンを併用することで、整合性を犠牲にせずにスケーラビリティを確保できます。アクティブ-アクティブ構成は、地理的に分散したデータセンター間での極めて高い可用性が必須である場合や、書き込み競合が発生しにくい特定のワークロードに限定して検討すべきです。
Post a Comment