クラウド上での Oracle Database利用に向けて 【JPOUG】 2023年9月13日 野村総合研究所 朝日英彦

2 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼朝日 英彦(ASAHI Hidehiko) ◼略歴 ⚫野村総合研究所にて金融業界のお客様向けのミッションクリティカルなシステム基盤 設計・構築、特にデータベース周りのチューニング等を長年にわたり実施。現在は保険 業界向けのシステムモダナイズやクラウドシフトに従事。 ◼データベース関連の資格等 ⚫Oracle ACE Associate（Database） ⚫Oracle Master Platinum（Oracle Database 9i, 10g） ⚫Oracle Database Cloud Administrator 2023 Certified Professional ⚫Oracle Autonomous Database Cloud 2023 Certified Professional ⚫情報処理技術者（データベース） ⚫2022, 2023 Japan AWS Top Engineer（Database） ⚫AWS Certified Database – Specialty (2022, 2023 Japan AWS All Certifications Engineer) ⚫Azure Database Administrator Associate ⚫Google Cloud Certified Professional Cloud Database Engineer 自己紹介

3 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼背景 ⚫クラウドの利用が一般的になった昨今、金融機関等でコアワークロードを担っている Oracle Databaseのクラウド移行も始まっています。一方で、どのクラウドだとどのよう にOracle Databaseワークロードを動かせるのか、各クラウドベンダが出している資料 はありますが、横串で比較するようなものは見当たりません。本日は、なるべくフラット に各クラウドでOracle Databaseをどのように稼働させることができるか、についてお話 しします。 ※本資料上では単に「クラウド」とした場合には以下の四つのパブリッククラウド、 AWS、Azure、Google CloudそしてOracle Cloud(OCI)を指します ◼以下については本日触れません。。 ⚫Oracle Databaseや各クラウドの機能等についての説明 ◼注意 ⚫必要なライセンス等については、利用される場合には各自改めて確認ください ⚫比較表の中身等、省略している部分も多いため、詳細は各ベンダに確認ください ⚫2023年8月末日の情報を元に作成しています 背景とか

4 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼Agenda ⚫クラウド上でのOracle Database ⚫各クラウド上でのOracle Databaseの選択肢 ⚫クラウド上でのOracle Databaseのユースケース ⚫クラウド上でのOracle Database利用に向けて Agenda

5 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. クラウド上でのOracle Database

6 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼オンプレ（プライベートクラウド含む）と何が違うの？ ⚫違う点 •ソフトウェアライセンスカウントの考え方 •クラウドによってはPaaS等の利用形態が選択可能 ⚫違わない点 •Oracle Databaseのソフトウェアとしての動作（バイナリ） クラウド上でのOracle Database

7 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼クラウド上でのソフトウェアライセンスの考え方（以下「クラウド・コンピュー ティング環境におけるOracleソフトウェアのライセンス（日本語参考 訳）」より引用） ⚫本資料は、以下のベンダーが提供するクラウド・コンピューティング環境に適用されま す: Amazon Web Services – Amazon Elastic Compute Cloud (EC2), Amazon Relational Database Service (RDS)、Microsoft Azure Platform (以 下、これらを「承認されたクラウド環境」と表記します） ◼つまり、AWS、Azureのみが「承認されたクラウド環境」となり、Google Cloudは承認されたクラウド環境には入りません ⚫当然ながらOracle Cloud上ではOracleソフトウェアを利用可能です ソフトウェアライセンスの考え方の違い①

8 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼クラウド上でのソフトウェアライセンスの考え方（以下「クラウド・コンピュー ティング環境におけるOracleソフトウェアのライセンス（日本語参考訳）」 より引用） ⚫承認されたクラウド環境におけるOracleプログラムのライセンス許諾の際には、インスタ ンス タイプの最大使用可能な vCPUをカウントする必要があり、計算方法は以下と なります • Amazon EC2 and RDS – マルチスレッディングが有効の場合 2 vCPU = 1 Processor、マルチスレッディングが無効の場合 1 vCPU = 1 Processor • Microsoft Azure – マルチスレッディングが有効の場合 2 vCPU = 1 Processor、 マルチスレッディングが無効の場合 1 vCPU = 1 Processor ⚫承認されたクラウド環境においてOracle Processorライセンスをカウントする場合、 Oracle Processor Core Factor Tableは適用されません ◼「承認されたクラウド環境」においても従来環境（オンプレ）とはライセン スカウントの方法が違います(上記例はEEの場合) ソフトウェアライセンスの考え方の違い②

9 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼Oracle Cloud上でのOracle Databaseライセンスの考え方は、Oracle 社の「Oracle Processor Core Factor Table 補足資料」に基づいて決 定されます（以下、当該資料より引用） ⚫EE：Processor ライセンスは以下の比率でOracle Cloudに持ち込む ことが可能です。 - 1 Processor ライセンスあたり 2 OCPU 上で当該 プログラム使用可能 (1 Processor：2 OCPU) ⚫SE2：Processorライセンスはソケットとしてカウントしているとみなし、1 Processor ライセンスあたり 4 OCPU 上で当該プログラム使用可能 (1 Processor： 4 OCPU) ◼Oracle Cloud環境においては個別の考え方（少しお得）が必要にな ります ソフトウェアライセンスの考え方の違い③

10 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼PaaS等の利用形態が選択可能 ⚫PaaSを選択すると、クラウドベンダ側に管理を任せることが可能となり ます（以下はAWSのPaaS利用例） PaaS等の利用形態が選択可能 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/rds-custom.html

11 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 各クラウド上でのOracle Databaseの選択肢

12 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 各クラウド上でのOracle Databaseの選択肢：AWS

13 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼AWSはOracle社による承認されたクラウド環境となり、クラウド環境 上でのOracle Databaseの利用が可能となります。AWS上で Oracle Databaseを利用できる構成は主として以下になります ⚫Amazon EC2上のOracle Database ⚫Amazon RDS for Oracle ⚫Amazon RDS Custom for Oracle AWS上でのOracle Database：構成

14 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼構成によってユーザ(カスタマー)側とAWSとの責任分界点が以下のよ うに分かれます AWS上でのOracle Database：構成の違い https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/rds-custom.html#custom-intro.solution

15 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼それぞれの構成の特徴は以下になります AWS上でのOracle Database：各構成のひとこと特徴 Amazon EC2構成 Amazon RDS構成 RDS Custom構成 ライセンス利用形態 BYOLのみ、認定クラウド環境 としての利用が可能 SE2は一部ライセンス込みも 可、BYOLを認定クラウド環境 としての利用が可能 BYOLのみ、認定クラウド環境 としての利用が可能 データベースバージョン 全てのバージョンが利用可能 19c、21c 19c 最大インスタンスクラス （利用可能なサイズ） 128vCPU、3,904GiBメモリ 128vCPU、4TiBメモリ 機能 基本制限なし(RACは不可) RDS固有制限あり RDS Custom固有制限あり スケーリング 可能（要再起動） 可能（要再起動） 可能（要再起動） 可用性（HA）、DR AutoRecovery機能、クラス タ構成、もしくはData Guard Multi-AZ、Data Guard AutoRecovery機能 もしくはData Guard 運用(DBパッチ適用) ユーザ AWS(タイミングは選択可能) ユーザ(適用はAWS) Oracle性能監視 オンプレと同様 Performance Insightを利用 可能 オンプレと同様(Performance Insight 利用不可) バックアップ 手動 マネージド マネージド、手動 ストレージ 複数DISKやRAID構成をとる ことで、実質無制限 64TiB、256,000IOPS オートスケール可能 64TiB、256,000IOPS オートスケール不可

16 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 各クラウド上でのOracle Databaseの選択肢：Azure

17 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼AzureはOracle社による承認されたクラウド環境となり、クラウド環 境上でのOracle Databaseの利用が可能となります。また、 Microsoft社とOracle社のパートナシップにより、Azure上からOracle Cloud上のOracle Databaseを利用できる仕組みが提供されていま す(Oracle Database Service for Azure: ODSA)。 Azure上で Oracle Databaseを利用できる構成は主として以下になります ⚫Azure VM上のOracle Database ⚫Oracle Database Service for Azure: ODSA Azure上でのOracle Database：構成

18 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼Azure VM上のOracle Databaseは基本的には仮想サーバ上で Oracle Databaseを利用する形となりますので、自身でインストール （もしくはマーケットプレイス・ギャラリー等）する必要があります ◼ODSAはAzureとOracle Cloudとの間の低レイテンシ接続を利用し てOracle Cloud上のOracle DatabaseをあたかもAzure上のサービ スとして利用できる、というサービスになります。基本的にはAzure側 の作業のみで作成ができますが、細かいメンテナンス等が必要な場 合にはOracle Cloud側から作業が必要になる一方、 Autonomous DBやExadata DB等、Oracle Databaseの高度な サービスを利用することが可能となります Azure上でのOracle Database：構成の違い

19 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼Azure上の構成の特徴は以下になります Azure上でのOracle Database：各構成のひとこと特徴 Azure VM構成 ODSA構成 ライセンス利用形態 BYOLのみ、認定クラウド環境としての 利用が可能 BYOL、ライセンス込みの構成が可能 (Base-DB, ExaDB, Autonomous DB) データベースバージョン 全てのバージョンが利用可能 19c、21c 最大インスタンスクラス （利用可能なサイズ） 512コア、16,384GBメモリ （ExaDB利用時） 機能 基本制限なし(RACは不可) 制限なし(ExaDB利用時) スケーリング 可能（要再起動） 可能、ExaDBは一部オンライン拡張も 可能 可用性（HA）、DR Service Healing機能 3rd パーティ製クラスタツール もしくはData Guard RAC、Data Guardの利用 運用(DBパッチ適用) ユーザ ユーザ(AutonomousはOracle) Oracle性能監視 オンプレと同様 Performance HUB等の利用が可能 バックアップ 手動 マネージド、手動で実施可能 ストレージ 複数DISKが利用可能 1,225.8TB、2,760,000IOPS(ExaDB利 用時)、オートスケール不可

20 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 各クラウド上でのOracle Databaseの選択肢：Google Cloud

21 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼Google CloudはOracle社の認定クラウド環境に指定されていませ ん。そのため、Google CloudのいわゆるVM上でOracle Database を稼働させることはできませんが、唯一、Google Cloud上のBare Metal Solution上で利用することが可能となります ◼Bare Metal サーバにはハイパーバイザであるOracle VM、もしくは Linux OSをインストールすることが可能となります ⚫Bare Metal Solution：Hypervisor（Oracle VM） ⚫Bare Metal Solution：Linux OS Google Cloud上でのOracle Database：構成

22 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼Oracle VMもしくはOracle Linux Virtualization Manager （OLVM）を利用してハードパーティショニングを行うことが可能です。 また、直接Linux OSを利用し、大きな一つのサーバとして利用するこ とが可能です。例えば、２ソケットモデルのサーバを利用することで SE2ライセンスを活用することも可能となります。また、Google Cloud社の説明ではRAC構成も可能となってます Google Cloud上でのOracle Database：構成の違い

23 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼Google Cloud構成の特徴は以下になります Google Cloud上でのOracle Database：構成のひとこと特徴 Bear Metal Solution ライセンス利用形態 BYOLのみ データベースバージョン 全てのバージョンが利用可能 最大インスタンスクラス 896vCPU、24TBメモリ 機能 基本制限なし スケーリング 可能（要再起動） 可用性（HA）、DR クラスタ構成、RAC構成 DRはData Guardの利用 運用(DBパッチ適用) ユーザ(OSレイヤもユーザ) Oracle性能監視 オンプレと同様 バックアップ 手動 ストレージ 複数DISKが利用可能

24 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 各クラウド上でのOracle Databaseの選択肢：Oracle Cloud

25 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼Oracle CloudはOracle社のクラウド環境となるため、Oracle Databaseの利用に最適化されています。他のクラウドでは利用でき ないEnterprise Editionのライセンス込みのモデルや、Exadataのクラ ウドサービス、さらにFull-Managed のAutonomous Databaseを利 用することが可能です ⚫仮想サーバ上のOracle Database(DB on IaaS) ⚫Base Database(BaseDB)/Exadata Database(ExaDB) ⚫Autonomous Database(ADB) Oracle Cloud上でのOracle Database：構成

26 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼構成によってユーザ(カスタマー)側とAWSとの責任分界点が以下の ように分かれます Oracle Cloud上でのOracle Database：構成の違い① 出典：https://speakerdeck.com/oracle4engineer/oracle-autonomous-database?slide=25

27 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼VM上のOracle Databaseは基本的には仮想サーバ上でOracle Databaseを利用する形となりますので、自身でインストール（もしく はマーケットプレイス・ギャラリー等）する必要があります。前述のとお り、利用するOCPU数によってライセンスが制限されます ◼Base Databaseはライセンス的にSE, EE, EE-HP, EE-EPという四つ のモデルがあり、EE-EPではRAC構成も選択可能となります。 Exadata Databaseも含め、BYOLも可能ですが、ライセンス込みの モデルもあり、コアの拡張等も柔軟に行うことが可能です ◼Autonomous DatabaseはFull-ManagedのOracle Database サービスとなります。完全な自動運用となり、ユーザ側はパッチ適用や チューニング等のDB運用を気にする必要はありません Oracle Cloud上でのOracle Database：構成の違い②

28 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼それぞれの構成の特徴は以下になります Oracle Cloud上でのOracle Database：各構成のひとこと特徴 DB on IaaS構成 Base-DB/Exa-DB構成 ADB構成 ライセンス利用形態 BYOLのみ BYOL、ライセンス込みの構成 が可能 BYOL、ライセンス込みの構成 が可能 データベースバージョン 全てのバージョンが利用可能 19c、21c 19c、21c 最大インスタンスクラス （利用可能なサイズ） 512コア、16,384GBメモリ （ExaDB利用時） 496コア、11,120GBメモリ (構成による) 機能 基本制限なし(RACは不可) 制限なし(ExaDB利用時) Autonomousの制限あり スケーリング 可能（要再起動） 可能、ExaDBは一部オンライ ン拡張も可能 可能 可用性（HA）、DR Service Healing機能 もしくはData Guard RAC、Data Guardの利用 マネージド Autonomous Data Guard を利用する場合、EEはActive Data Guardライセンスが必要 運用(DBパッチ適用) ユーザ ユーザ マネージド Oracle性能監視 オンプレと同様 Performance HUB等の利用 が可能 Performance HUB等の利用 が可能 バックアップ 手動 マネージド、手動で実施可能 マネージド ストレージ 複数DISKが利用可能 1,225.8TB、 2,760,000IOPS(ExaDB利用 時)、オートスケール不可 128TB(サポートリクエスト可 能)

29 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 各クラウド上でのOracle Databaseの選択肢：まとめ

30 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. クラウド上でのOracle Database ◼基本的にはクラウド上のOracle Databaseはコンセプトとして以下の 三つに分けることができます 1. IaaS 上の Oracle Database 2. PaaS 上の Oracle Database(半マネージド:OSへのroot権限あり) 3. PaaS 上の Oracle Database(フルマネージド) ⚫１→３で自由度は下がりますが運用の管理負荷も下がる形となりま す。Oracle Databaseはもともとミッションクリティカルな場面で利用さ れることも多く、自由度がさがると課題に対して必要な対応ができない 場合もありますので、システムの適性にあわせて選択しましょう。個人 的な判断ポイントとしては、現在運用しているシステムで個別パッチを 適用している場合には、フルマネージドの選択は避けた方が無難です （十分に考慮したうえで選択するのはアリです）。

31 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. クラウド上でのOracle Databaseのユースケース

32 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼以下それぞれのOracle Databaseユースケースについて、AWS、Azure、Google Cloud、Oracle Cloudにそれぞれマイグレを行った場合にどのような構成をとるのが適 切か、私なりの実装例を示してみます（正解ではありません！） ⚫ユースケース① • Oracle SE2(4ソケット分プロセッサライセンス) • アクティブスタンバイ構成 • 2ソケット 8コアサーバ • DRはバックアップの遠隔コピー • 夜間メンテナンスOK • DB・ノード稼働監視 • 1TBディスク、遠隔転送100GB/日 ⚫ユースケース② • Oracle EE(合計16プロセッサライセンス) • RACによるアクティブアクティブ構成 • 2ソケット 16コアサーバ • DRはData Guard による準リアル同期 • 24h365d運用、個別パッチ適用 • DB・ノード稼働・リソース監視 • 1TBディスク、遠隔転送100GB/日 クラウド上のOracle Databaseのユースケース SE2 8コア Active SE2 8コア Standby EE 16コア Active(RAC) EE 16コア Active(RAC) EE 16コア Active(RAC) EE 16コア Active(RAC) Data Guard 遠隔コピー BKUP

33 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼前提事項 ⚫クラウドへの移行方式やOracle Databaseからのエンジン変更等については今回の検討の 対象外となります ⚫コア・OCPUは物理コア、VCPUは論理コア（スレッド）を指します ⚫Oracle Databaseのライセンスの考え方は以下になります(今回はNUPは対象外) • オンプレ・その他環境 • SE2： 1プロセッサライセンス 1CPUソケット • EE： 1プロセッサライセンス 2物理コア(Intel Xeon想定) • 認定クラウド環境(AWS, Azure) • SE2： 1プロセッサライセンス 4vCPU • EE： 1プロセッサライセンス 1vCPU(1スレッド)、2vCPU(2スレッド) • Oracle Cloud環境 • SE2： 1プロセッサライセンス 4OCPU(8スレッド) • EE： 1プロセッサライセンス 2OCPU(4スレッド) ◼注意事項 ⚫構成のフィジビリティ、必要ライセンスについては一部机上での確認になっているものがあります ので、利用される際には確認をお願いします 前提・注意事項

34 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼ユースケース①は標準的なOracle SE2を利用したアクティブ・スタンバイ構成で、各ノード 2ソケット 8コアとなっています。(非機能要求グレード 社会的影響が限定されるシステム) ⚫構成 • Oracle SE2(両ノードで4ソケット分プロセッサライセンス) • アクティブスタンバイ構成 • 2ソケット 8コア CPU/ノード • DRはバックアップの遠隔コピー • 夜間メンテナンスOK • DB・ノード稼働監視 ◼求められている非機能要件 ユースケース①の非機能要件 SE2 8コア Active SE2 8コア Standby 遠隔コピー BKUP 非機能要件 対応 評価 1． ライセンス, コスト Oracle SE2 ４ソケット分プロセッサライセンス利用 8コア64GBメモリ×2、1TBストレージで概算、リモート転送 100GB/月 2． 性能要件 8コア分の処理ができること、拡張性は不要 3． 可用性要件 障害発生時のダウンタイム15分程度であること 4． DR要件 バックアップデータから復旧できること 5． メンテ要件 夜間帯にメンテナンス時間を設定できること 6． 監視要件 ノード・DBサービスの稼働が監視できること ◎:要件充足＋α 〇:要件充足 △:代替可能/個別 ✕:充足できず 非機能要求グレード： https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html 標準的なOCI利用時 との相対評価

35 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼実装例 ⚫RDS for Oracle (SE2 BYOL) ⚫8vCPUモデル、Multi-AZ構成 ⚫DRはスナップショットをクロスリージョンコピー ⚫メンテナンスウィンドウを夜間に設定 ⚫メトリクス監視・ログ監視を実装 ユースケース①：AWSでの実装例 Multi-AZ 非機能要件 本実装での対応 評価 1． ライセンス, コスト Oracle SE2 1ソケット分プロセッサライセンスは、Amazon RDSではSE2 4vCPU分プロ セッサライセンスとなるため、サーバ毎8vCPUまで利用可能 〇 2． 性能要件 SE2の場合にはHT無の8vCPUまでが各ノードに割り当て可能となるため、オンプレと同 様の性能確保が可能 〇 3． 可用性要件 障害発生時のダウンタイムはMulti-AZ切り替えのため5～15分程度となる マネージドで実装が可能 ◎ 4． DR要件 バックアップの取得、復旧は容易に実施が可能 ◎ 5． メンテ要件 メンテウィンドウの設定が可能 夜間利用しない場合には停止することでコスト削減も可能(AWSとしてはRDSの停止・ 起動を運用に組み込むのは非推奨) ◎ 6． 監視要件 容易にメトリクス監視の実装が可能 CloudWatchLogsによるアラートログ等の監視も比較的容易 ◎ 遠隔スナップショット SE2 8vCPU Active SE2 8vCPU Standby

36 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ユースケース①：Azureでの実装例 ◼実装例 ⚫Oracle Database SE2 on Azure VM ⚫8vCPUモデル、3rd パーティツールでHA構成 ⚫DRはRMANもしくはスナップショットバックアップを クロスリージョンコピー ⚫メンテナンスウィンドウを夜間に設定 ⚫メトリクス監視・ログ監視を個別実装 3rd Party 非機能要件 本実装での対応 評価 1． ライセンス, コスト Oracle SE2 1ソケット分プロセッサライセンスは、Azure VM上ではSE2 4vCPU分 となるため、サーバ毎8vCPUまで利用可能 Azure上は基本的にはHTを無効にできないため、vCPUベースのカウントとなる △ 2． 性能要件 SE2の場合にはHT無の8vCPUまでが各ノードに割り当て可能となるため、オンプレ と同様の性能確保が可能（ただしHT無ノードは古いモデルのみ） 〇 3． 可用性要件 障害発生時のダウンタイムは 3rd パーティ製品による切り替えのため５～１５分 程度となる（3rd パーティツールでは共有ディスク構成も可能） 〇 4． DR要件 バックアップの取得、復旧は個別実装が必要 〇 5． メンテ要件 VMメンテ通知が行われた場合には夜間帯でメンテ実施が可能 夜間利用しない場合には停止することでコスト削減も可能 ◎ 6． 監視要件 個別に作りこみが必要となるが、実装は可能 〇 遠隔スナップショット SE2 8vCPU Active SE2 8vCPU Standby

37 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ユースケース①：Google Cloudでの実装例 ◼実装例 ⚫Oracle Database SE2 on Bare Metal(2ソケット×2) ⚫2ソケットモデル、3rd パーティツールでHA構成（？） ⚫DRはRMANもしくはスナップショットバックアップをクロ スリージョンコピー ⚫メンテナンス時間枠を夜間に設定 ⚫メトリクス監視・ログ監視を個別実装 非機能要件 本実装での対応 評価 1． ライセンス, コス ト Oracle SE2 2プロセッサライセンスをBYOLにて利用 Bare Metal製品のコストが非公開 ？ 2． 性能要件 SE2は16スレッドまで利用できるため、要件に対しては十分となる 〇 3． 可用性要件 障害発生時のダウンタイムは 3rd パーティ製品による切り替えのため５～１５ 分程度となる（Bare Metalのサポートが確認できず。。） （3rd パーティツールでは共有ディスク構成も可能と想定） ？ 4． DR要件 バックアップの取得、復旧は個別実装が必要 〇 5． メンテ要件 メンテナンスの時間枠の設定が可能 〇 6． 監視要件 個別に作りこみが必要となるが、オンプレと同等の実装可能 〇 遠隔バックアップ SE2 2ソケット Active 3rd Party SE2 2ソケット Standby

38 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ユースケース①：Oracle Cloudでの実装例 ◼実装例 ⚫BYOL to AutonomousでSE2ライセンスをAutonomous DB へもちこみ ⚫8OCPU分の利用 ⚫DRはAutonomous Data Guardを利用 ⚫メンテナンス時間枠を夜間に設定 ⚫メトリクス監視を実装（ログ監視は不要） 非機能要件 本実装での対応 評価 1． ライセンス、コス ト Oracle SE2 2プロセッサライセンスをBYOL to Autonomousにて1プロセッサライセンス を4OCPU分として利用可能。ピークに合わせたCPUのスケール等で柔軟にコスト削減 が可能となるため、〇→◎ 〇→◎ 2． 性能要件 8OCPU分の利用が可能となるため、要件を充足 1OCPUは2スレッドとなるため、さらなる性能向上が期待できる ◎ 3． 可用性要件 Autonomous DBのバックグラウンドではRACが稼働しているため、障害時の停止時 間は極小 ◎ 4． DR要件 Autonomous DBは自動バックアップが取得されているため、運用は不要 (必要な場合に手動で対応は可能) ◎ 5． メンテ要件 メンテナンスの時間枠の設定が可能 夜間停止することでコスト削減が可能 ◎ 6． 監視要件 メトリクス監視はPerformance HUBの利用等で可能 ログ監視はAutonomous DBは不要（という建付け） ◎ Data Guard Autonomous DB 8OCPU

39 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ユースケース① まとめ 非機能要件 AWS Azure Google Cloud Oracle Cloud 1． ライセンス,コスト 〇 △ ？ ◎ 2． 性能要件 〇 〇 〇 ◎ 3． 可用性要件 ◎ 〇 ？ ◎ 4． DR要件 ◎ 〇 〇 ◎ 5． メンテ要件 ◎ ◎ 〇 ◎ 6． 監視要件 ◎ 〇 〇 ◎ ◼ユースケース①ではOracle Cloudが一番適してはいますが、AWSやAzureも要件を満 たす実装がインプリ可能であることが確認できました ⚫AWS：RDSはフルマネージドであり、デプロイや運用が非常に簡便となり、利用しやすい ⚫Azure：Azure（単体）ではマネージドなOracle Databaseは利用できないため、オンプ レと似たような形での利用となる ⚫Google Cloud：ライセンスの関係でOracle Databaseを利用するには制約が大きくなる ため、利用したい場合にはフィジビリティを確認する必要がある ⚫Oracle Cloud：ライセンス面での優遇が大きいため、逆にどのような形だと既存のライセン スが活かせるか、もしくは運用費用を下げることが可能かを確認するとよい

40 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼ユースケース②はRACを利用したActive-Active構成となり、可用性やDRについて高い 要件が求められます。(非機能要求グレード 社会的影響が極めて大きいシステム) ⚫構成 • Oracle EE(合計32プロセッサライセンス) • RACによるアクティブアクティブ構成 • 16コアサーバ×4 • DRはData Guard による準リアル同期 • 24h365d運用、個別パッチ適用 • DB・ノード稼働・リソース監視 ◼求められている非機能要件 ユースケース②の非機能要件 非機能要件 対応 評価 1． ライセンス、コスト 各ノードでOracle EE 8プロセッサライセンス＋RACオプション、Diagnostic Pack 16コア128GB×4、ディスク1TB、リモート転送 100GB/月 2． 性能要件 16コア＋16コア分の処理ができること、必要な場合には拡張可能であること 3． 可用性要件 ハード障害等の単独障害でダウンタイムが発生しないこと 4． DR要件 大規模災害時にも数時間程度で業務継続が可能であること 5． メンテ要件 サービスはオンラインでメンテナンスが可能であること 6． 監視要件 ノード・DBサービスの稼働、システムリソースや高負荷SQL等が監視できること EE 16コア Active(RAC) EE 16コア Active(RAC) EE 16コア Active(RAC) EE 16コア Active(RAC) Data Guard 非機能要求グレード： https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html ◎:要件充足＋α 〇:要件充足 △:代替可能/個別 ✕:充足できず 標準的なOCI利用時 との相対評価

41 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼実装例 ⚫RDS Custom for Oracle ⚫32vCPUモデル、Data Guard同期でHA確保 ⚫DRは非同期でクロスリージョンのデータ確保 ⚫Data Guardの切り替えでメンテナンス時間確保 ⚫メトリクス監視・ログ監視を実装、リソース監視はオ ンプレ相当(Performance Insight利用不可) ユースケース②：AWSでの実装例 Data Guard 非機能要件 本実装での対応 評価 1． ライセンス、コ スト 各ノードOracle EE 16プロセッサライセンスが必要となるため、合計48 EEプロ セッサライセンスが必要となる（持ち込み32ライセンスのため、追加が必要） △ 3． 性能要件 RACで16コア＋16コアの処理をシングルで担うため、32vCPU構成としているが、 HT有の構成となるため要件を満たせない可能性がある △ 4． 可用性要件 障害発生時のダウンタイムはData Guard切り替えのため5～15分程度となる △ 5． DR要件 Data Guardの切り替えにより、業務継続が可能 〇 6． メンテ要件 Data Guardの切り替えにより、ノード毎のメンテナンスが可能 個別パッチ適用が可能 〇 7． 監視要件 容易にメトリクス監視の実装が可能、CloudWatchLogsによるアラートログ等 の監視も比較的容易、性能監視はオンプレ相当 〇 Data Guard EE 32vCPU Active EE 32vCPU DG 同期 EE 32vCPU DG 非同期 同期DGやクロスリージョン DGは手動設定が必要

42 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ユースケース②：Azureでの実装例 ◼実装例 ⚫Oracle Database Service for Azure(ODSA) ⚫Base-DB RAC構成(16OCPUずつ) ⚫DRはData Guardを利用 ⚫メンテナンスは片ノードずつ実施 ⚫メトリクス監視・リソース監視はOCIの機能 (Performance HUB)で実装、ログ監視は個別実装 非機能要件 本実装での対応 評価 1． ライセンス、コ スト 現行のライセンスの持ち込みが可能 ODSAを利用する場合、基本的にはコストはOCI利用と同等 〇 2． 性能要件 現行と同等のコア数で対応が可能 必要な場合には拡張も可能（ライセンスは準備が必要） ◎ 3． 可用性要件 RAC構成のため、障害時の停止時間は極小 〇 4． DR要件 自動バックアップの実装が可能 DR側のリージョンでODSAが利用できない場合があるため、DRを組む場合に はDR側のサービス構成を確認する必要がある(現在大阪は利用不可) △ 5． メンテ要件 RACのため片ノードずつのメンテナンスが可能 個別パッチ適用は可能 〇 6． 監視要件 メトリクス監視・リソース監視はPerformance HUBの利用等で可能 ログ監視は個別実装 ◎ Data Guard EE 16OCPU RAC EE 16 OCPU RAC EE 16OCPU RAC EE 16 OCPU RAC

43 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ユースケース②：Google Cloudでの実装例 ◼実装例 ⚫Oracle Database EE on Bare Metal ⚫16コア RAC構成（※） ⚫DRはData Guardで実装 ⚫メンテナンス時間枠を夜間に設定 ⚫メトリクス監視・ログ監視を個別実装 非機能要件 本実装での対応 評価 1． ライセンス、コ スト 現行のライセンスの持ち込みが可能（現行と同様の計算式と想定） Bare Metal Solutionのコストが非公開のため、コストは不明 ？ 2． 性能要件 現行と同等のコア数で対応が可能 ◎ 3． 可用性要件 RAC構成のため、障害時の停止時間は極小 〇 4． DR要件 バックアップの取得、復旧は個別実装が必要 Bare Metal Solutionの利用できるリージョンは限られており、日本だとTokyo のみとなる（Osakaは利用できない）ため、確認が必要 △ 5． メンテ要件 メンテナンスの時間枠の設定が可能 個別パッチの適用は可能 〇 6． 監視要件 個別に作りこみが必要となるが、オンプレと同等の実装可能 〇 Data Guard EE 16コア RAC ※Google Cloud社の説明ではRACがBare Metal 上で実現可能となっています（出典：https://cloud.google.com/bare-metal?hl=ja） EE 16コア RAC EE 16コア RAC EE 16コア RAC

44 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ユースケース②：Oracle Cloudでの実装例 ◼実装例 ⚫Base-DB RAC構成(16OCPUずつ) ⚫DRはData Guardを利用 ⚫メンテナンスは片ノードずつ実施 ⚫メトリクス監視・リソース監視はOCIの機能 (Performance HUB)で実装、ログ監視は個別実装 非機能要件 本実装での対応 評価 1． ライセンス、コ スト 現行のライセンスの持ち込みが可能 〇 2． 性能要件 現行と同等のコア数で対応が可能 必要な場合には拡張も可能（ライセンスは準備が必要） ◎ 3． 可用性要件 RAC構成のため、障害時の停止時間は極小 〇 4． DR要件 自動バックアップの実装が可能 ◎ 5． メンテ要件 RACのため片ノードずつのメンテナンスが可能 個別パッチ適用は可能 〇 6． 監視要件 メトリクス監視・リソース監視はPerformance HUBの利用等で可能 ログ監視は個別実装 ◎ Data Guard EE 16OCPU RAC EE 16 OCPU RAC EE 16OCPU RAC EE 16 OCPU RAC

45 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ユースケース② まとめ 非機能要件 AWS Azure Google Cloud Oracle Cloud 1． ライセンス,コスト △ 〇 ？ 〇 2． 性能要件 △ ◎ ◎ ◎ 3． 可用性要件 △ 〇 〇 〇 4． DR要件 〇 △ △ ◎ 5． メンテ要件 〇 〇 〇 〇 6． 監視要件 〇 ◎ 〇 ◎ ◼ユースケース②においては、机上ではOracle Cloudをはじめ、Azure、Google Cloud の環境においては、メインサイトではRAC構成を構成できますが、DR等を含めて総合 的に利用する場合には、Oracle Cloudが適しているといえます。 ⚫AWS：AWS上ではRAC構成を利用できないため、要件を精査する必要がある ⚫Azure：RAC構成を利用する場合には、ODSA構成が利用可能となるが、現在大阪では ODSA構成がサポートされないため、構成には注意する必要がある ⚫Google Cloud：実績は不明だが、RAC構成も利用可能となっている。現在大阪では Bare Metal Solutionがサポートされないため、構成には注意する必要がある ⚫Oracle Cloud：DR構成含めて安心して利用することが可能。またさらに高い要件の場合に は、Exadataを利用することも可能

46 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼ユースケース①のようなライトな形の要求においてはどのクラウドでもある 程度マネージドな実装が可能となります ◼ユースケース②のような高い要求になってくるとOracle Cloudの利用が必 要となってくると考えられます。また、Oracle Cloudの場合にはさらに高い 要求でもExadata サービス等を利用することが可能となります ユースケースのまとめ

47 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. クラウド上でのOracle Database利用に向けて

48 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼今回はOracle Databaseにフォーカスしてクラウド移行の場合分け、を行ってみました。 既に会社のシステムとしてはクラウドを利用している場合も多いと思われ、新たにクラウド 移行を行う場合には利用しているクラウドをまずは検討されることも多いと思います ◼一方、Oracle Databaseを利用するシステムはコアな部分での利用が多く、大きくコス トがかかってくると想定されます ◼今回紹介したとおり、非機能要求グレードで言及されているような社会的影響が大き なシステムの場合にオンプレと同様の要件を満たすためには、Oracle Cloudが最適な 選択肢となってくると考えています ◼比較的負荷の低いシステムにおいてもOracle Cloudでのメリットは大きいですが、他の クラウドでも要件は満たすことが可能となります。特にAmazon RDSは運用負荷も低く 抑えられるため、多く利用されていると考えています まとめ

49 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ◼クラウドマイグレーションを行うためには、まず移行戦略の策定が必要になります。基本 的にOracle Databaseをそのままクラウドに移行する手法は、②のリホストになります。 ここは、Oracle Cloudが一番使い勝手が良いといえます ◼AWSやAzure, Google Cloudはリプラットフォーム、すなわちDBエンジンの変更サポー トにも力を入れています。現時点でも数は少ないですがリプラットフォームは行われていま す。今まで以上にコストや技術的な背景が整えば、採用しやすくなるかもしれません。 (もしかしたらその時にはさらにAutonomous DBがコスト効果高く利用できるようになっ ているかもしれませんが) 今後の展望 出典：https://aws.amazon.com/jp/builders-flash/202011/migration-to-cloud-2/?awsf.filter-name=*all

No content