📑

Oracle GDSの時代がやって来た!

2022/02/18に公開約2,600字

はじめに

エンタープライズ基盤のDBでは、Oracle DBが最強!という主張にほとんど異論はないと思っていますが、パブリッククラウドのDBでは、クラウドの特性上、複数のリージョンやゾーンにDBインスタンスを分散配置してアベイラビリティとスケーラビリティを実現するDBアーキテクチャが主流になっていることや、OCI(Oracle Cloud Infrastructure)以外ではRACが構成できないことなどもあってか、残念ながらOracle DBを採用した構成をほとんど聞くことがありません。

個人的には、パブリッククラウドでOracle DBがもっと使われるようにするための解決策の一つは、パブリッククラウドと親和性の高いDBアーキテクチャを実装できるようにすること、具体的には、複数のリージョンやゾーンにDBインスタンスを分散配置してアベイラビリティとスケーラビリティを簡単に実装できるようにすることだと考えていますが、それに最適な機能がOracle DB 12c Enterprise Editionから導入されたOracle GDS(Global Data Services)です。

現時点では、Oracle GDSは国内での導入実績がおそらくないと思われるのですが(あったら教えて下さい!)、やっと時代が機能に追いついて来た感があります。

というわけで、この記事ではOracle GDSについて紹介します。

Oracle GDSの概要

Oracle DBには、DBレプリケーションを実現する機能や製品として、Active Data Guard(物理レプリケーション)やGoldenGate(論理レプリケーション)がありますが、これらの機能や製品を用いて異なるリージョンやゾーンに複数のDBレプリカを構築した場合、DBレプリカ・ファームへのクライアント接続のロード・バランシングが課題になります。
RACでは、DBインスタンス間での動的なワークロード管理機能のサービス(ローカル・サービス)がありますが、そのサービスの概念を地理的に分散配置された単一インスタンス、RAC、Active Data Guard、GoldenGateの任意の組み合わせのDBインスタンス(DBレプリカ)にまで拡張してグローバル・サービスとしてワークロード管理機能を提供できるようにしたものがGDSになります。
GDSでは、地理的な配置(リージョン)やレプリケーションの遅延(Active Data Guardのみ)などを考慮したDBインスタンスのワークロード管理のため、ローカル・サービスにはないグローバル・サービス固有の以下の3つの属性を追加しています。

  • 優先または使用可能なデータベース
  • レプリケーション・ラグ
  • リージョン・アフィニティ

これにより、リージョンやラグを考慮した複数DBインスタンスへのロード・バランシングやフェイル・オーバーがグローバル・サービスによって可能になります。

GDSのアーキテクチャ

GDSのアーキテクチャを構成するコンポーネントと概要は以下の通りです。

  • GSM(Global Service Manager)
    • GDSの主要なコンポーネントであり、グローバル・サービスのロード・バランシング、フェイル・オーバーおよび一元的な管理を提供します。クライアントのすべてのオペレーションはGSMを使用して実行されます。
  • GDSカタログ
    • GDSとGDSが提供するすべてのグローバル・サービスに関するコンフィグレーション・データを格納するためのリポジトリです。
  • GDSリージョン
    • ネットワーク的に近接しているDBとクライアントのサブセットです。一つのGDSリージョンには複数のGDSプールを含めることができます。
  • GDSプール
    • 一意のグローバル・サービスを提供するDBのサブセットです。DBは一つのGDSプールにのみ所属できます。また、GDSプールは複数のGDSリージョンに跨がることができます。

GDSでは、GDSリージョンごとに複数のGSM サーバー(3サーバ以上)を構成することが推奨されており、各リージョンにある一つのGSMがマスターになります。
また、GDSカタログのDBもData Guardによる冗長化構成が推奨されています。

GDSのユースケース

GDSのユースケースは多岐に渡ると思いますが、記事の冒頭に書いたように地理的に分散配置されたDBレプリカ・ファームへのロード・バランシングが一番のユースケースだと思います。
以下の図のように異なるリージョンに配置されたマスターDBとリードレプリカDB・ファームがあった場合、GDSでは、Read/WriteのワークロードはマスターDBへ、Read Onlyのワークロードはパフォーマンスやネットワークの状況(負荷や遅延)、優先度などに応じた適切なレプリカDBへとルーティングしてくれます。

最後に

この記事を読んで、少しでもGDSに興味を持ってもらえるとうれしいです。
私自身でがまだGDSの構築や動作検証は実施していないので、テクニカルに間違いなどあればぜひご指摘ください。
来年は時間を作ってGDSの検証したいです!

リファレンス

Discussion

ログインするとコメントできます