JPOUG Tech Talk Night #7 ASAHI

クラウド上での 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 自己紹介

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

◼Agenda ⚫クラウド上でのOracle Database ⚫各クラウド上でのOracle Databaseの選択肢 ⚫クラウド上でのOracle Databaseのユースケース ⚫クラウド上でのOracle Database利用に向けて Agenda

クラウド上でのOracle Database

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

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

◼クラウド上でのソフトウェアライセンスの考え方（以下「クラウド・コンピューティング環境における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の場合) ソフトウェアライセンスの考え方の違い②

◼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環境においては個別の考え方（少しお得）が必要になりますソフトウェアライセンスの考え方の違い③

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

各クラウド上でのOracle Databaseの選択肢

各クラウド上でのOracle Databaseの選択肢：AWS

◼AWSはOracle社による承認されたクラウド環境となり、クラウド環境上でのOracle Databaseの利用が可能となります。AWS上で Oracle Databaseを利用できる構成は主として以下になります ⚫Amazon EC2上のOracle Database ⚫Amazon RDS for Oracle ⚫Amazon RDS Custom for Oracle AWS上でのOracle Database：構成

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

◼それぞれの構成の特徴は以下になります 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 オートスケール不可

各クラウド上でのOracle Databaseの選択肢：Azure

◼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：構成

◼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：構成の違い

◼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利用時)、オートスケール不可

各クラウド上でのOracle Databaseの選択肢：Google Cloud

◼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：構成

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

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

各クラウド上でのOracle Databaseの選択肢：Oracle Cloud

◼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：構成

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

◼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：構成の違い②

◼それぞれの構成の特徴は以下になります 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(サポートリクエスト可能)

各クラウド上でのOracle Databaseの選択肢：まとめ

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

クラウド上でのOracle Databaseのユースケース

◼以下それぞれの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

◼前提事項 ⚫クラウドへの移行方式や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スレッド) ◼注意事項 ⚫構成のフィジビリティ、必要ライセンスについては一部机上での確認になっているものがありますので、利用される際には確認をお願いします前提・注意事項

◼ユースケース①は標準的な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利用時との相対評価

◼実装例 ⚫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

ユースケース①：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

ユースケース①：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

ユースケース①：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

ユースケース① まとめ非機能要件 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：ライセンス面での優遇が大きいため、逆にどのような形だと既存のライセンスが活かせるか、もしくは運用費用を下げることが可能かを確認するとよい

◼ユースケース②は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利用時との相対評価

◼実装例 ⚫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は手動設定が必要

ユースケース②：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

ユースケース②：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

ユースケース②：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

ユースケース② まとめ非機能要件 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を利用することも可能

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

クラウド上でのOracle Database利用に向けて

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

◼クラウドマイグレーションを行うためには、まず移行戦略の策定が必要になります。基本的に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

JPOUG Tech Talk Night #7 ASAHI

JPOUG Tech Talk Night #7 ASAHI

More Decks by Hidehiko ASAHI

Other Decks in Technology

Featured

Transcript