Oracle Globally Distributed Database

解決する課題

• 1台の DB に収まらない巨大なデータ量・スループットを、サーバー増設で直線的にスケールアウトしたい
• 単一 DB を単一障害点（SPOF）にしたくない。一部の障害が全体停止につながらない構成が欲しい
• 各国のデータを指定したリージョンに置き続けたい（データ所在地・レジデンシ要件への対応）
• ユーザーに近い場所へデータを置き、地理的に分散したアクセスのレイテンシを下げたい

主要概念と用語

• シャーディング（Sharding）: 1つの論理テーブルを行単位で複数の物理 DB に分割し、各 DB が互いに独立して動く水平分割方式。各 DB はデータの一部だけを持つ
• シャード（Shard）: 分割されたデータの一部を保持する独立した Oracle Database 1台。スケールアウトは「シャードを足す」ことで行う
• シャードキー（Sharding Key）: 行をどのシャードへ置くかを決める列。設計の最重要要素で、DynamoDB のパーティションキーに相当
• シャーディング方式: キーをハッシュして均等分散するシステム管理シャーディング（一貫性ハッシュ）、値の範囲やリストで割り当てるユーザー定義シャーディング、両者を組み合わせるコンポジットがある
• シャードカタログ（Shard Catalog）: シャード構成やルーティング情報、横断クエリの調整を担う管理用 DB
• シャードディレクター（Shard Director / GSM）: 接続要求のシャードキーを見て適切なシャードへ振り分けるルーター
• チャンク（Chunk）: シャード内の再配置単位。リシャーディング時はチャンク単位でデータが移動する
• レプリケーション: 各シャードを Data Guard や **Raft（RAFT レプリケーション）**で複製し、シャード単位の高可用性を確保する
• 重複テーブル（Duplicated Table）: 全シャードに複製して持つ参照系の小さな表。シャード表との結合をローカルで完結させる

仕様・制限・クォータ

• データモデルはリレーショナル。シャード表にはシャードキーを含む設計が前提で、シャードキーは原則として更新しない（更新するとシャード間移動が必要になる）
• クエリには 2 種類ある。シャードキーを指定して1シャードに直接ルーティングされる単一シャードクエリと、複数シャードへまたがるクロスシャードクエリ。後者はカタログ経由で集約され、コストが高い
• 一意キー / 外部キーはシャードキーを含む形でないと全シャードでの保証が難しく、設計上の制約となる
• 各シャードは独立した Oracle Database なので、シャード単体の容量・性能上限は通常の Oracle DB に準じる。全体容量はシャード数に比例して伸びる
• リシャーディング（シャード追加・分割）はチャンク移動として行われ、オンラインで実行できるが移動中は I/O 負荷がかかる
• OCI 上の構成数・シェイプ・リージョン展開には**サービス上限（クォータ）**があり、引き上げ申請ができる

内部の仕組み

Oracle Globally Distributed Database は、アプリから見て1つの論理 DB に見える集合を、内部的には複数の独立した Oracle Database（シャード）へ水平分割して構成します。行をどのシャードへ置くかはシャードキーで決まります。システム管理シャーディングではシャードキーを一貫性ハッシュで分散させ、データを均等に配置します。ユーザー定義シャーディングでは「日本のデータは東京リージョンのシャードへ」のように、値の範囲やリストで明示的に配置先を指定でき、データ所在地要件に応える設計ができます。

接続はシャードディレクター（GSM）が受け、リクエストに含まれるシャードキーから該当シャードへ直接ルーティングします。これにより単一シャードクエリはカタログを経由せず、1台の DB に対する通常クエリと同等の効率で処理されます。複数シャードにまたがるクエリはシャードカタログが各シャードへ配り、結果を集約します。

各シャードは独立して動くため、1シャードの障害は他シャードに波及しません。さらに各シャードを Data Guard または Raft レプリケーションで複製しておくことで、シャード単位のフェイルオーバーが可能になり、全体の可用性を高めます。スケールアウトは**シャードを追加し、チャンクを再配置（リシャーディング）**することで行い、容量とスループットを足し算で増やせます。

設計パターン / ベストプラクティス

• アクセスパターンからシャードキーを決める: 最も頻繁な検索条件をシャードキーに選び、単一シャードクエリで完結させる。横断クエリを最小化するのが性能の要
• データを均等に分散する: 偏りやすい値（特定テナント・特定地域への集中）はホットシャードを生む。ハッシュ分散や複合キーで散らす
• データ所在地要件にはユーザー定義シャーディング: リージョンごとにシャードを割り当て、国・地域単位でデータを物理的に固定する
• 参照系の小表は重複テーブルに: マスタやコードテーブルは全シャードに複製しておくと、シャード表との結合がローカルで済みクロスシャードを避けられる
• シャードキーは不変に保つ: シャードキーの値を更新するとシャード間でデータ移動が発生する。キーは生成時に確定し以後変えない設計にする
• シャードごとに HA を組む: 各シャードを Data Guard / Raft で複製し、シャード単位の障害でも縮退運転を続けられるようにする

運用・監視

• OCI Monitoring と Oracle 標準の管理ツールで、各シャードの CPU・I/O・接続数・レプリケーション遅延・チャンク分布を監視する
• **シャード間のデータ偏り（スキュー）**を定期的に確認し、偏りが出たらリシャーディングでチャンクを再配置する
• リシャーディング（シャード追加・分割）はオンラインで実行可能だが I/O 負荷がかかるため、低負荷の時間帯に計画する
• バックアップ・パッチはシャードごとに行う。各シャードは独立 DB なので、ローリングで順次適用すれば全体停止を避けられる
• フェイルオーバーはシャード単位。レプリカ構成（Data Guard / Raft）の健全性と遅延を継続監視し、切り替え可能な状態を保つ

コスト

課金は基本的に各シャード（独立した DB インスタンス）の計算・ストレージの合計に、シャードカタログやシャードディレクターといった管理コンポーネントの分が加わります。シャードを足すほど容量と費用が比例して増える構造です。

セキュリティ

• 保存データは既定で暗号化。鍵は Oracle 管理鍵、または **OCI Vault（KMS）**の顧客管理鍵（CMK）を選択できる
• 各シャード・カタログはプライベートサブネットに配置し、**セキュリティリスト / NSG（ネットワークセキュリティグループ）**で接続元を最小化する
• 操作権限は OCI IAM ポリシーでコンパートメント単位に最小化し、DB 内ユーザー権限と組み合わせて管理する
• 通信は TLS で暗号化する。アプリの DB 資格情報はコードに直書きせず OCI Vault のシークレットに保管する
• ユーザー定義シャーディングを使えば、データを特定リージョンに固定してレジデンシ要件を満たせる

Well-Architected の観点

• 信頼性（Reliability）: シャードが独立しているため単一障害点を排除できる。各シャードを Data Guard / Raft で複製すればシャード単位でフェイルオーバーでき、一部障害でも縮退して稼働を続けられる
• パフォーマンス効率（Performance）: シャードを足すだけで直線的にスケールアウトでき、書き込みも分散できる。単一シャードクエリは 1 台の DB と同等の効率で応答する。ホットシャードを避けるキー設計が性能を左右する

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 分散データベース（シャード構成）を作成する例
# システム管理シャーディング + 指定シャード数でスケールアウト構成を組む
oci distributed-db sharded-database create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name app-gdd \
  --db-deployment-type DEDICATED \
  --sharding-method SYSTEM \
  --shard-count 3 \
  --replication-method RAFT \
  --wait-for-state ACTIVE

# 作成した分散データベースの一覧を確認
oci distributed-db sharded-database list \
  --compartment-id "$COMPARTMENT_OCID" \
  --output table

# 個別の分散データベースの構成（シャード配置・状態）を取得
oci distributed-db sharded-database get \
  --sharded-database-id "$SHARDED_DB_OCID"