Db2 pureScale vs Oracle RAC：次世代ミッションクリティカル基盤の技術選定
エンタープライズ・データベースにおいて「24時間365日、止まらないこと」は絶対条件です。その解として君臨するシェアード・ディスク型クラスターの双璧、Db2 pureScale と Oracle RAC。本記事では、Db2 DBAの視点から、これら2製品のアーキテクチャの本質、RDMA通信の優位性、そして IBM Spectrum Scale (GPFS) を用いた運用管理のリアルを徹底解剖します。
- 集中管理（pureScale）と分散管理（RAC）が生むスケーラビリティの決定的な差
- RDMA通信が実現する「CPU負荷ゼロ」のノード間同期メカニズム
- IBM Spectrum Scale (GPFS) vs ASM：DBAの作業効率を左右するストレージ層の違い
- クラウド（AWS/GCP）移行時に直面する「最高速度」と「コスト」のジレンマ
目次
1. アーキテクチャの根本的相違：集中か、分散か
両製品とも「複数のサーバーから1つの共有ストレージを参照する」という構成は共通していますが、ノード間の整合性を保つための「司令塔」の在り方が全く異なります。
1.1 Db2 pureScale：CF（Cluster Caching Facility）方式
pureScaleのルーツは、IBMのメインフレーム技術「Parallel Sysplex」にあります。その心臓部は、CF (Cluster Caching Facility) という専用ノードによる集中管理です。
各メンバーノードは、ロック情報や共有キャッシュをCFに問い合わせます。ノードが10台、20台と増えても、通信相手は常にCFであるため、ノード間での直接的な競合（インターコネクトの輻輳）が発生せず、「線形のスケーラビリティ」を維持できるのが最大の強みです。
1.2 Oracle RAC：Cache Fusion 方式
Oracle RACには特定の司令塔は存在しません。代わりに Cache Fusion という技術を用い、各ノードが対等にデータを持ち合います。
あるノードが必要なデータが別のノードにある場合、インターコネクト経由でデータを直接転送します。小規模構成では柔軟に動作しますが、大規模構成（4ノード以上など）になると、「誰が最新データを持っているか」のメタデータ交換が指数関数的に増大し、オーバーヘッドが生じやすくなります。
2. 徹底比較データ：スペックとインフラ要件
DBAが選定時に参照すべき、主要なコンポーネントを詳細な表にまとめました。
| 比較項目 | Db2 pureScale (v11.5+) | Oracle RAC (19c/21c) |
|---|---|---|
| アーキテクチャ | CFによる集中管理。拡張性が極めて高い。 | Cache Fusionによる分散管理。汎用性に優れる。 |
| 推奨ネットワーク | RDMA (RoCE / InfiniBand) | 汎用 Ethernet (UDP/TCP) |
| ノード間レイテンシ | 1〜10マイクロ秒（物理限界に近い） | 数百マイクロ秒〜ミリ秒（通信負荷に依存） |
| ストレージ管理 | IBM Spectrum Scale (GPFS) | Oracle ASM |
| ライセンス形態 | Advanced Edition等に機能を包含。 | EEに加えてRAC Optionが必要。 |
3. RDMAの圧倒的な優位性：なぜ最高速度が安定するのか
pureScaleが「最高速度のネットワーク」を使い倒せる理由は、プロトコルにあります。一般的なTCP/IP通信はOSのカーネルやCPUを介しますが、RDMA (Remote Direct Memory Access) はこれらを完全にバイパスします。
- ゼロ・コピー： OS内の冗長なデータコピーを排除し、メモリ間を直接同期。
- CPU負荷からの独立： DBが100%の負荷でクエリを処理していても、クラスター維持のための通信はネットワークカード（HCA）が直接行うため、遅延が発生しません。
- フェイルオーバーの抑制： 通信遅延による誤ったノードダウン判定を防ぎ、不要なシステム停止を回避。
実際に運用されている方はご存じかと思いますが、RDMA関連のトラブルが多いのもまた事実です。RDMAを使用しているため、Db2側から問題判別が行われますが、実際にはハード側の問題であることが多く、またハード側では十分な問題判別ができないという悪循環が生まれています。
4. ストレージと運用のリアリティ：Spectrum Scale (GPFS) の真価
DBAとして自動化スクリプトを書く際、ストレージ層の透明性は非常に重要です。
4.1 Spectrum Scale (GPFS) の利便性
IBM Spectrum Scaleは、OSからは「普通のディレクトリ」としてマウントされます。これにより、DBAは特別なツールを使わずに、標準のUNIXコマンドでファイル操作や監視が可能です。
/usr/lpp/mmfs/bin/mmgetstate -a
# ストレージプールの詳細確認
/usr/lpp/mmfs/bin/mmlsdisk db2fs1 -L
4.2 Oracle ASM との比較
Oracle ASMは非常に高性能ですが、OSからは物理デバイスとしてしか見えず、中身を確認するには `asmcmd` などの専用インターフェースが必要です。運用のシンプルさという点では、GPFSを採用している pureScale に軍配が上がります。
5. クラウド（AWS/GCP）におけるコストと性能
AWSやGCPを使うと「構築費用」は下がりますが、IOPS最高速度のストレージ（io2 Block Express等）をフル活用すると、ランニングコストが指数関数的に増大します。
「とりあえずクラウドへ」ではなく、純粋なスループットを求めるワークロードか、あるいは変動する負荷への対応（オートスケーリング）を求めるのかで、pureScale か RAC か、あるいは別の選択肢かが決まります。特にRDMAが使えない環境での pureScale 構成には高度な設計が不可欠です。
Db2、Oracleを問わず、並列処理が多くなるクラスタシステムではIOPSが非常に重要になり、かつ速度も求められます。構築時の初期費用や最低コストの見積もりだけを見ると、クラウドの方がコストがかからないという印象を持ちがちですが、パフォーマンスを追求すればクラウドの方がかえってコストがかかることもあるということを、お客様にご理解いただくことが最も重要です。特に営業さんに強く言いたい！！
6. 結論：選定基準
最終的な判断は、システムの「未来の規模」に集約されます。
- Db2 pureScale を選ぶべき： ノード数を増やしても確実に性能を伸ばしたい、かつメインフレーム級の極低レイテンシを追求する場合。
- Oracle RAC を選ぶべき： 汎用インフラを活用し、市場に溢れる豊富なナレッジを武器に運用したい場合。
最高スペックのSSDやネットワークをどう料理するか、この記事が皆様の次世代基盤設計のヒントになれば幸いです。