JPOUG Tech Talk Night #7 ASAHI

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

View Slide

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
自己紹介

View Slide

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

View Slide

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

View Slide

5
Copyright
クラウド上でのOracle Database

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

19
Copyright
◼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 パーティ製クラスタツール
RAC、Data Guardの利用
運用(DBパッチ適用) ユーザユーザ(AutonomousはOracle)
Oracle性能監視オンプレと同様 Performance HUB等の利用が可能
バックアップ手動マネージド、手動で実施可能
ストレージ複数DISKが利用可能 1,225.8TB、2,760,000IOPS(ExaDB利
用時)、オートスケール不可

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

42
Copyright
ユースケース②：Azureでの実装例
◼実装例
⚫Oracle Database Service for Azure(ODSA)
⚫Base-DB RAC構成(16OCPUずつ)
⚫DRはData Guardを利用
⚫メンテナンスは片ノードずつ実施
⚫メトリクス監視・リソース監視はOCIの機能
(Performance HUB)で実装、ログ監視は個別実装
スト
現行のライセンスの持ち込みが可能
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

View Slide

43
Copyright
ユースケース②：Google Cloudでの実装例
◼実装例
⚫Oracle Database EE on Bare Metal
⚫16コア RAC構成（※）
⚫DRはData Guardで実装
スト
現行のライセンスの持ち込みが可能（現行と同様の計算式と想定）
Bare Metal Solutionのコストが非公開のため、コストは不明
？
2．性能要件現行と同等のコア数で対応が可能 ◎
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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

View Slide

JPOUG Tech Talk Night #7 ASAHI

JPOUG Tech Talk Night #7 ASAHI

Hidehiko ASAHI

More Decks by Hidehiko ASAHI

Other Decks in Technology

Featured

Transcript