[OCI Technical Deep Dive] クラウドリフト案件の合意形成の進め方とDB合意形成の実際(2025年8月5日開催)

Oracle Cloud Infrastructure(OCI) Technical Deep Dive(2025年8月5日開催)
https://go.oracle.com/LP=149126
-----
本資料では、日本オラクルが提供する Oracle Cloud Lift Services(OCLS) のナレッジをもとに、クラウドリフト案件の合意形成プロセスを解説します。
フィジビリティスタディの進め方と、その価値を最大化する方法、Oracle Database PaaS検討時の重要な判断ポイントや陥りやすい落とし穴についても具体的にご紹介。
クラウド提案を成功に導くための“土台”を、実践的な知識として持ち帰っていただけます。

[こんな方におすすめ]
・OCLSの具体的な進め方を学びたい方
・フィジビリティスタディを効果的に活用したい方
・Oracle Database PaaS提案の勘所と注意点を知りたい方

Transcript

1. クラウドリフト案件の合意形成の進め⽅と DB合意形成の実際 Oracle Cloud Lift Services (OCLS) 冨⼠原 浩介・ ⼤林 克⾄ ⽇本オラクル株式会社 クラウド事業統括 製品事業統括 OCI Platform COE 本部 クラウド・アダプション部 2025 年 8 ⽉ 5 ⽇
2. 以下の事項は、弊社の⼀般的な製品の⽅向性に関する概要を説明するものです。また、情報 提供を唯⼀の⽬的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、 マテリアルやコード、機能を提供することを確約するものではないため、購買決定を⾏う際の判断 材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリース、時期及び 価格については、弊社の裁量により決定され、変更される可能性があります。 Safe harbor statement 2 Copyright © 2025, Oracle and/or its affiliates
3. アジェンダ 3 Copyright © 2025, Oracle and/or its affiliates 1 2 クラウドリフト案件の合意形成の進め⽅ クラウドリフト案件におけるDB合意形成の実際
4. クラウドリフト案件の合意形成の進め⽅
5. OCLS フィジビリティ・スタディ⽀援の概要 5 Copyright © 2025, Oracle and/or its affiliates 対象システムがOCIへ移⾏できそうかを複数回セッションでの机上評価 概要 移⾏実現性 評価観点 • ノックアウトファクターがなく、OCIへ移⾏できること • 現⾏システムに対するお客様課題がOCIへの移⾏によって解決できること • 移⾏に向けた今後の検討事項を整理し、後続検討に繋げられること お客様が 得られること • 現⾏システム課題に対する次期アーキテクチャによる解決策 • OCIに対する⼗分な理解 • 上申資料のドラフト ⽬指す所 OCIへの移⾏提案をお客様に納得していただき、 移⾏プロジェクトを推進すること
6. OCLS フィジビリティ・スタディ⽀援の流れ 6 Copyright © 2025, Oracle and/or its affiliates 現⾏システムの ヒアリング クラウド アーキテクチャ ⽅針検討 WS#1 ヒアリング 評価 後続⽀援検討 フィジビリティ 評価 今後の進め⽅ 合意形成 検討 WS#2 WS#3 WS#4 お客様提供資料をもとに 弊社から現⾏システムや次 期要件をヒアリングを実施 ヒアリング結果をもとに次期 構成案や体制案、スケ ジュール案を提⽰し、ディス カッションを実施 ヒアリング・検討のWS、分 科会から対象システムの移 ⾏実現性(次期構成、概 算含む)を評価 FS実施してからのお客様 検討結果の確認 FS後の弊社⽀援ご紹介 や検討深掘りを実施 フィジビリティ・スタディ ヒアリングシート OCI移⾏対象現⾏基盤 サーバー⼀覧 + Oracle Database 情報 AWR レポート、 データ量情報、など お客様からのインプット情報 OCLS フィジビリティ・スタディにおけるワーク・ショップ(WS)
7. OCLS フィジビリティ・スタディ⽀援の流れ 7 Copyright © 2025, Oracle and/or its affiliates お客様からインプット情報を提供頂くことが合意形成の第⼀歩 現⾏システムの ヒアリング クラウド アーキテクチャ ⽅針検討 WS#1 ヒアリング 評価 後続⽀援検討 フィジビリティ 評価 今後の進め⽅ 合意形成 検討 WS#2 WS#3 WS#4 お客様提供資料をもとに 弊社から現⾏システムや次 期要件をヒアリングを実施 ヒアリング結果をもとに次期 構成案や体制案、スケ ジュール案を提⽰し、ディス カッションを実施 ヒアリング・検討のWS、分 科会から対象システムの移 ⾏実現性(次期構成、概 算含む)を評価 FS実施してからのお客様 検討結果の確認 FS後の弊社⽀援ご紹介 や検討深掘りを実施 フィジビリティ・スタディ ヒアリングシート OCI移⾏対象現⾏基盤 サーバー⼀覧 + Oracle Database 情報 AWR レポート、 データ量情報、など お客様からのインプット情報 OCLS フィジビリティ・スタディにおけるワーク・ショップ(WS)
8. フィジビリティ・スタディ⽀援開始前のお客様状況 8 Copyright © 2025, Oracle and/or its affiliates 本⽀援を活⽤していただくと、次期構成の⽅針や構成、予算感、NextActionがわかる 対象システム 状況 • 通常業務が忙しく、現⾏システムの状況把握や次期構成の要件整理など に時間をかけられない • クラウドはまだ経験が少なく、何から始めればよいかわからない • 検討段階のため、お⾦もかけにくい • 1〜2、3年後のシステム更改時期が迫っている （HW保守切れやSWのEOL、DC閉鎖等） • 全社的にクラウド化⽅針となっている • 来期の予算申請やRFI/RFP発出するための情報が必要 お客様組織の 状況 次期構成の検討を進めることができるフィジビリティ・スタディ⽀援がささりやすいです ただし、お客様にとって提供情報の準備がハードルです
9. お客様がインプット情報を提供しやすくする⼯夫 9 Copyright © 2025, Oracle and/or its affiliates 以下の⼯夫によってお客様からのインプット情報を⼊⼿し、次期構成の合意形成の第⼀歩を踏み出す フィジビリティ・スタディ ヒアリングシート OCI移⾏対象現⾏基盤 サーバー⼀覧 + Oracle Database 情報 AWR レポート、 データ量情報、など お客様からのインプット情報 • ヒアリングの意図や回答例をつけて極⼒回答しやすくする • 回答内容が薄くても初回Workshopで深掘り質問で補う • 最後の⼿段としてMtgにてお客様と⼀緒に回答を記⼊する • お客様所定の書式であっても⼀旦受け取り、我々のフォーマットと ⽐較して不⾜項⽬があれば追加ヒアリングする • ⼿順や取得スクリプトを提供し、迷いなく準備できるようにする （1時間に1ファイル、1〜7⽇間の期間、ピーク期間を含む） • 本番環境に影響が少ない取得⽅法 ⼯夫ポイント
10. OCLS フィジビリティ・スタディ⽀援の流れ 10 Copyright © 2025, Oracle and/or its affiliates お客様から提供頂いたインプット情報を活⽤して、次期構成の検討を実施 現⾏システムの ヒアリング クラウド アーキテクチャ ⽅針検討 WS#1 ヒアリング 評価 後続⽀援検討 フィジビリティ 評価 今後の進め⽅ 合意形成 検討 WS#2 WS#3 WS#4 お客様提供資料をもとに 弊社から現⾏システムや次 期要件をヒアリングを実施 ヒアリング結果をもとに次期 構成案や体制案、スケ ジュール案を提⽰し、ディス カッションを実施 ヒアリング・検討のWS、分 科会から対象システムの移 ⾏実現性(次期構成、概 算含む)を評価 FS実施してからのお客様 検討結果の確認 FS後の弊社⽀援ご紹介 や検討深掘りを実施 フィジビリティ・スタディ ヒアリングシート OCI移⾏対象現⾏基盤 サーバー⼀覧 + Oracle Database 情報 AWR レポート、 データ量情報、など お客様からのインプット情報 OCLS フィジビリティ・スタディにおけるワーク・ショップ(WS) クラウド・リフト後の構成案を提⽰する、 お客様との合意形成に向けた最初の 重要なフェーズ
11. クラウドリフト案件における DB合意形成の実際
12. OCLS フィジビリティ・スタディの流れ 12 Copyright © 2025, Oracle and/or its affiliates 現⾏システムの ヒアリング クラウド アーキテクチャ ⽅針検討 WS#1 ヒアリング 評価 後続⽀援検討 フィジビリティ 評価 今後の進め⽅ 合意形成 検討 WS#2 WS#3 WS#4 お客様提供資料をもとに 弊社から現⾏システムや次 期要件をヒアリングを実施 ヒアリング結果をもとに次期 構成案や体制案、スケ ジュール案を提⽰し、ディス カッションを実施 ヒアリング・検討のWS、分 科会から対象システムの移 ⾏実現性(次期構成、概 算含む)を評価 FS実施してからのお客様 検討結果の確認 FS後の弊社⽀援ご紹介 や検討深掘りを実施 フィジビリティ・スタディ ヒアリングシート OCI移⾏対象現⾏基盤 サーバー⼀覧 + Oracle Database 情報 AWR レポート、 データ量情報、など お客様からのインプット情報 OCLS フィジビリティ・スタディにおけるワーク・ショップ(WS) クラウド・リフト後の構成案を提⽰する、 お客様との合意形成に向けた最初の 重要なフェーズ
13. 「クラウド・アーキテクチャ⽅針検討」実施時における DB 構成案合意形成に向けた準備 13 Copyright © 2025, Oracle and/or its affiliates クラウドリフト後の DB 構成案と想定コストを提⽰してお客様の判断材料を⽤意する 現⾏データベース環境の理解 STEP 1 データベース・システムの 移⾏先イメージの想定と 机上サイジング STEP 2 コスト・シミュレーションと 構成案の⽐較 STEP 3 お客様提供資料をもとに、現⾏データ ベース環境を理解する 移⾏先 DB クラウド・サービスの構成 案とその机上サイジングを⾏う 構成案のそれぞれのコスト・シミュレー ションと⽐較結果をまとめる サーバー・スペック、その 上で動作する DB およ び各種パラメータ、データ 量などの紐付け AWRレポートから CPU やメモリ、I/O などの 各種利⽤量の把握 利⽤想定 DB クラウド・サービス案ごとに 移⾏先イメージの図⽰化、机上サイジング による利⽤リソース量の想定をまとめる 構成案が複数ある場合はその案の コスト・シミュレーションと⽐較結果をまとめる
14. STEP1: 現⾏データベース環境の理解 14 Copyright © 2025, Oracle and/or its affiliates
15. STEP1: 現⾏データベース環境の理解 本セクションで想定する移⾏元の構成: サーバーおよびデータベース情報 15 Copyright © 2025, Oracle and/or its affiliates サーバー情報とその上で動作するデータベース情報を把握 現⾏ 基幹 DB システム 3 ノード RAC (Real Application Clusters) ご利⽤ハードウェア HPE ProLiant DL380 Gen10 (x3) 搭載 CPU モデル Intel Xeon Gold 5122 3.60 GHz 割当 CPU コア数* 6 メモリ量* 256 GB OS Red Hat Enterprise Linux 搭載データベース DB01 (non-CDB 構成) DB02 (non-CDB 構成) DB03 (non-CDB 構成) Oracle Database 12.2.0.1 EE 12.2.0.1 EE 12.2.0.1 EE cpu_count* 明⽰的な設定なし 明⽰的な設定なし 明⽰的な設定なし sga_target* 40 GB 40 GB 40 GB pga_aggr_target* 10 GB 10 GB 10 GB Database Size 2,400 GB 2,400 GB 2,400 GB • Oracle Database のバージョンは 19c とする お客様の想定 • 1 ノード障害時でもピークに対応できるよう にリソースを構成したい (現⾏もそのような設計) • 可⽤性は必要としているが、可能であれば 3 ノードだが、2 ノードでも良い 可⽤性に ついて * がある項⽬はサーバーまたはデータベース・インスタンスあたりの数量 本資料では、紙⾯の都合上、pga_aggregate_target を pga_aggr_target と略した記載をしている場合がございます。 サービス DB バージョン • BaseDB (Base Database Service) を想定している
16. STEP1: 現⾏データベース環境の理解 本セクションで想定する移⾏元の構成: AWR レポートから机上サイジングに参考にする主な情報 16 Copyright © 2025, Oracle and/or its affiliates AWR レポートからお客様データベースの設定値や動作状況を把握 データベース CPU 観点 メモリ観点** I/O 観点 最⼤インスタンス CPU 使⽤率の合計* sga_target pga_aggr_target 合計最⼤ IOPS 合計最⼤スループット DB01 66 % 40 GB 10 GB 12,500 600 MB/sec DB02 66 % 40 GB 10 GB 12,500 600 MB/sec DB03 66 % 40 GB 10 GB 12,500 600 MB/sec 計 198 % 120 GB 30 GB 37,500 1,800 MB/sec * 3 ノード構成のため最⼤は 300% ** 値はインスタンスあたり • 上記のような最⼤値の確認だけでなく、CPU 使⽤率の推移を⾒て、CPU スケーリングをするとコスト最適化できるようなシステムであるか、 必要に応じて確認します。（本資料では想定課題をシンプルにするために省略しています。）
17. STEP2: データベース・システムの 移⾏先イメージの想定と机上サイジング 17 Copyright © 2025, Oracle and/or its affiliates 本資料で提⽰する机上サイジングは、 OCI サービスの概算算出を⽬的として、移⾏元データベースに関する 情報を基にした机上による簡易的なサイジング想定となります。従ってデータベースの性能を保証するものでは ありません。実際の厳密なサイジングは実機での検証により決定いただきますようお願い致します。
18. STEP2-1: 移⾏先イメージを想定する BaseDB: PDB (Pluggable Database) 集約案と個別構成案 18 Copyright © 2025, Oracle and/or its affiliates • BaseDB は 1 DB システムあたり 1 CDB (Container Database) 構成 • BaseDB の RAC 構成は 2 ノードのみ 基幹DBサーバ (3 ノード RAC) HPE ProLiant DL380 Gen10 (6 CPUコア 256 GB メモリ) x3 基幹DB システム BaseDB 2 ノード RAC 基幹PDB01 基幹PDB02 基幹PDB03 RAC x 2 PDB 集約案 基幹DBサーバ (3 ノード RAC) HPE ProLiant DL380 Gen10 (6 CPUコア 256 GB メモリ) x3 基幹DB02 システム BaseDB 2 ノード RAC RAC x 2 基幹DB01 システム BaseDB 2 ノード RAC RAC x 2 基幹DB03 システム BaseDB 2 ノード RAC RAC x 2 個別 構成案
19. STEP2-2: 机上サイジングをする BaseDB: PDB 集約案 19 Copyright © 2025, Oracle and/or its affiliates BaseDB はメモリ・サイズと I/O 帯域も OCPU 数に⽐例 • 現⾏ CPU コアと VM.Standard.E5.Flex の CPU コア性能を同等とした場合 6 CPU コア x 使⽤率 198% = 11.88 CPU コア → ピークに対応するには 12 CPU コア = 12 OCPU 必要 CPU 観点 メモリ 観点 • sga_target として 240 GB (= 120 GB x 2) 必要な場合 → BaseDB では 31 OCPU 必要 • 31 OCPU 構成時、デフォルト sga_target: 246.50 GB pga_aggregate_target: 61.625 GB I/O 観点 • 1,800 MB/sec スループットに対応する場合→ 少なくとも 15 OCPU 以上が必要 • 15 OCPU 構成時、 15 Gbbps:245,760 IOPS、1,920 MB/sec スループットが理論値 ストレージ・ サイズ観点 • データ容量として 7,200 GB が必要なため、BaseDB で選択可能な DATA 12 TB (RECO はデフォルト 4 TB) を選択 • 12TB の Higher Performance Block Volume の最⼤性能は 400,000 IOPS、 5,440 MB/sec スループット となる ため、現⾏の I/O 性能に対応可能 BaseDB シェイプ OCPU エディション ブロック・ボリューム・ タイプ ブロック・ボリューム・ サイズ 基幹DB システム （2 ノード RAC 構成) VM.Standard.E5.Flex 62 (31 OCPU x 2 ノード) EE-EP Higher Performance 16,784 GB DATA: 12,288 GB RECO: 4,096 GB Software: 2 x 200 GB 付録 ご参考① 付録 ご参考② 付録 ご参考③④ RAC x 2 この３つの観点から 最⼤OCPU数を選択 現⾏と同等のメモリ・サイズや I/O 帯域を確保するために、必要な CPU リソース以上に OCPU 数を増やしている構成 付録 ご参考⑤
20. STEP2-2: 机上サイジングをする BaseDB: 個別構成案 20 Copyright © 2025, Oracle and/or its affiliates BaseDB はメモリ・サイズと I/O 帯域も OCPU 数に⽐例 • 現⾏ CPU コアと VM.Standard.E5.Flex の CPU コア性能を同等とした場合 6 CPU コア x 使⽤率 66% = 3.96 CPU コア → ピークに対応するには 4 CPU コア = 4 OCPU 必要 CPU 観点 メモリ 観点 • sga_target として 80 GB (= 40 GB x 2) 必要な場合 → BaseDB の場合 11 OCPU 必要 • 11 OCPU 構成時、デフォルト sga_target: 86.50 GB pga_aggregate_target: 21.625 GB I/O 観点 • 600 MB/sec スループットに対応する場合→ 少なくとも 5 OCPU 以上が必要 • 5 OCPU 構成時、 5 Gbps:81,920 IOPS、640 MB/sec スループットが理論値 ストレージ・ サイズ観点 • データ容量として 2,400 GB が必要なため、BaseDB で選択可能な DATA 4 TB (RECO はデフォルト 1 TB) を選択 • 4 TB の Higher Performance Block Volume の最⼤性能は 307,200 IOPS、 2,400 MB/sec スループット となる ため、現⾏の I/O 性能に対応可能 BaseDB シェイプ OCPU エディション ブロック・ボリューム・ タイプ ブロック・ボリューム・ サイズ 基幹DB 01-03 システム （2 ノード RAC 構成) VM.Standard.E5.Flex 22 (11 OCPU x 2 ノード) EE-EP Higher Performance 5,520 GB DATA: 4,096 GB RECO: 1,024 GB Software: 2 x 200 GB 付録 ご参考① 付録 ご参考② 付録 ご参考③④ (以下は 1 DB システムあたりの机上サイジング) RAC x 2 RAC x 2 RAC x 2 この３つの観点から 最⼤OCPU数を選択 現⾏と同等のメモリ・サイズや I/O 帯域を確保するために、必要な CPU リソース以上に OCPU 数を増やしている構成 付録 ご参考⑤
21. STEP2-1: 移⾏先イメージを想定する ExaDB-D (Exadata Database Service on Dedicated Infrastructure) : 3 ノード構成案と 2 ノード構成案 21 Copyright © 2025, Oracle and/or its affiliates • ExaDB-D は 複数 DB ホーム、複数 CDB 構成が可能 • ExaDB-D は 2 ノード以上の構成が可能 基幹DBサーバ (3 ノード RAC) HPE ProLiant DL380 Gen10 (6 CPUコア 256 GB メモリ) x3 ExaInfra (Exadata Cloud Infrastructure) X11M 3 x DB Server 3 x Storage Server 基幹DB環境 基幹DB VM クラスタ (3 ノード RAC) 基幹 DB01 基幹 DB02 基幹 DB03 3 ノード 構成案 基幹DBサーバ (3 ノード RAC) HPE ProLiant DL380 Gen10 (6 CPUコア 256 GB メモリ) x3 ExaInfra X11M 2 x DB Server 3 x Storage Server 基幹DB環境 基幹DB VM クラスタ (2 ノード RAC) 基幹 DB01 基幹 DB02 基幹 DB03 2 ノード 構成案
22. STEP2-2: 机上サイジングをする ExaDB-D: 3 ノード構成案 22 Copyright © 2025, Oracle and/or its affiliates ExaDB-D はメモリ・サイズや I/O 帯域は、割当て CPU コア数には⽐例しない • 現⾏ CPU コアと⽐較して ExaDB-D X11M の CPU コアの性能⽐を 1.2 倍とした場合 6 CPU コア/1.2 性能⽐ x 使⽤率 198% = 9.9 CPU コア → ピークに対応するには 10 CPU コア = 40 ECPU 必要 • 3 ノード構成の場合には、VM あたり 20 ECPU として、3 ノード合計 60 ECPU を想定 CPU 観点 メモリ 観点 • VM あたりの sga_target の合計が 120 GB 必要な場合 → VM あたりの物理メモリとして 240 GB 以上が必要 I/O 観点 • DB Server と Storage Server 間は 100 Gbps Ethernet による専⽤のインターコネクトで接続 • ExaInfra X11M (3 x DB Server + 3 x Storage Server) のカタログ値としては、840万 IOPS (Max SQL Flash Read IOPS)、300 GB/sec (Max SQL Flash Bandwidth) であり、I/O 性能は⼗分対応可能と想定 ExaInfra X11M (3 x DB Server + 3 x Storage Server) ECPU (DB Server あたり 760 ECPU 利⽤可能) 物理メモリ・サイズ (DB Server あたり 1,390 GB 利⽤可能) Exadata ストレージ・サイズ (240 TB 利⽤可能) 基幹DB VM クラスタ (3 ノード RAC) 60 (20 ECPU x 3 ノード） 720 GB (240 GB x 3 ノード) 16 TB ストレージ・ サイズ観点 • データ容量として 7,200 GB が必要なため、例えば Exadata ストレージを 16 TB 構成した場合、 DATA : RECO = 80 : 20 の選択時には、12.8 TB : 3.2 TB の⽐率となる 基幹DB VM クラスタ (3 ノード RAC)
23. STEP2-2: 机上サイジングをする ExaDB-D: 2 ノード構成案 23 Copyright © 2025, Oracle and/or its affiliates ExaDB-D はメモリ・サイズや I/O 帯域は、割当て CPU コア数には⽐例しない • 現⾏ CPU コアと⽐較して ExaDB-D X11M の CPU コアの性能⽐を 1.2 倍とした場合 6 CPU コア/1.2 性能⽐ x 使⽤率 198% = 9.9 CPU コア → ピークに対応するには 10 CPU コア = 40 ECPU 必要 • 2 ノード構成の場合には、VM あたり 40 ECPU として、2 ノード合計 80 ECPU を想定 CPU 観点 メモリ 観点 • VM あたりの sga_target の合計が 240 GB (= 120 GB x 2) 必要な場合 → VM あたりの物理メモリとして 480 GB 以上が必要 I/O 観点 • DB Server と Storage Server 間は 100 Gbps Ethernet による専⽤のインターコネクトで接続 • ExaInfra X11M (2 x DB Server + 3 x Storage Server) のカタログ値としては、560万 IOPS (Max SQL Flash Read IOPS)、300 GB/sec (Max SQL Flash Bandwidth) であり、I/O 性能は⼗分対応可能と想定 ExaInfra X11M (2 x DB Server + 3 x Storage Server) ECPU (DB Server あたり 760 ECPU 利⽤可能) 物理メモリ・サイズ (DB Server あたり 1,390 GB 利⽤可能) Exadata ストレージ・サイズ (240 TB 利⽤可能) 基幹DB VM クラスタ (2 ノード RAC) 80 (40 ECPU x 2 ノード） 960 GB (480 GB x 2 ノード) 16 TB ストレージ・ サイズ観点 • データ容量として 7,200 GB が必要なため、例えば Exadata ストレージを 16 TB 構成した場合、 DATA : RECO = 80 : 20 の選択時には、12.8 TB : 3.2 TB の⽐率となる 基幹DB VM クラスタ (2 ノード RAC)
24. STEP3:コスト・シミュレーションと 構成案の⽐較 24 Copyright © 2025, Oracle and/or its affiliates
25. STEP3-1: コスト・シミュレーションして⽐較する BaseDB 案および ExaDB-D 案: ⽉額(744時間)コストの⽐較 25 Copyright © 2025, Oracle and/or its affiliates ExaDB-D 3 ノード構成が⼀番低コストとなる計算結果に ExaDB-D 3 ノード構成案 数量 単価 1ヶ⽉の時間 計 ExaInfra (Server 構成) 6 ￥449.996 744 ￥2,008,782 ECPU 60 ￥52.08 744 ￥2,324,851 合計 ￥4,333,633 ExaDB-D 2 ノード構成案 数量 単価 1ヶ⽉の時間 計 ExaInfra (Server 構成) 5 ￥449.996 744 ￥1,673,985 ECPU 80 ￥52.08 744 ￥3,099,802 合計 ￥4,773,787 BaseDB: PDB 集約案 OCPU数 EE-EP単価 1ヶ⽉の時間 Compute 計 サイズ(GB) ⽉額単価 ストレージ計 システム計 基幹DBシステム 62 ￥208.3355 744 ￥9,610,100 16,784 ￥9.2225 ￥154,790 ￥9,764,890 BaseDB: 個別構成案 OCPU数 EE-EP単価 1ヶ⽉の時間 Compute 計 サイズ(GB) ⽉額単価 ストレージ計 システム計 基幹DB01 22 ￥208.3355 744 ￥3,410,035 5,520 ￥9.2225 ￥50,908 ￥3,460,944 基幹DB02 22 ￥208.3355 744 ￥3,410,035 5,520 ￥9.2225 ￥50,908 ￥3,460,944 基幹DB03 22 ￥208.3355 744 ￥3,410,035 5,520 ￥9.2225 ￥50,908 ￥3,460,944 合計 ￥10,382,831 低 3ノード RAC 2ノード RAC 付録 ご参考⑥⑦
26. STEP3-2: 構成案を⽐較する BaseDB/ExaDB-D サービス選択の違いによる主な考慮ポイント 26 Copyright © 2025, Oracle and/or its affiliates コスト以外にも各観点での違いを⽰し、お客様の判断材料を提⽰ BaseDB RAC 構成 ExaDB-D RAC 構成 サービス概要 共有インフラ OCI Compute + Block Volume を⽤いたプラットフォーム お客様専有インフラ Oracle Database に最適化された ⾼性能・⾼可⽤性プラットフォーム 性能 BaseDB 独⾃機能は特になし Exadata 独⾃機能による性能向上 (Storage Server への⼀部処理のオフロードなど) RACノード数と ノード・スケーリング RAC 構成は 2 ノードのみ スケーリングは不可 2 ノード以上の RAC 構成が可能 オンライン・スケーリングが可能 CPU スケーリング VM 再起動(ローリング⽅式)が必要 オンライン・スケーリングが可能 メモリ・サイズ と I/O 帯域 割当て CPU コア数に⽐例 割当て CPU コア数に⾮依存 データベース構成/集約 1 CDB、複数 PDB 構成 複数 DB ホーム、複数 CDB、複数 PDB が可能 可⽤性 (単⼀ノード障害時) DB サービス停⽌時間: 数秒 (Clusterware による再構成時間) DB サービス停⽌時間: 数秒 (Clusterware による再構成時間) オラクル実施の計画メンテナンス 範囲: BaseDB のインフラ 頻度: 不定期 スケジュール: 設定不可 (通知後、期⽇までの任意のタイミングでお客様にて VM 再起動実施(その間縮退構成)) 範囲: ExaInfra 頻度: ⽉次および四半期ごと スケジュール: 設定可能 (四半期メンテナンスは VM 再起動を伴う (その間縮退構成))
27. STEP3-2: 構成案を⽐較する BaseDB: PDB 集約と個別構成との違いによる主な考慮ポイント 27 Copyright © 2025, Oracle and/or its affiliates BaseDB の場合の２つの構成案の違いを改めて⽰し、お客様の判断材料を提⽰ BaseDB: PDB 集約構成 BaseDB: 個別構成案 概要 3 つのデータベース を １つの BaseDB RAC 構成上に 3 つの PDB として動作させる 3 つのデータベース を 個別の BaseDB RAC 構成上に、それぞれ 1 つの PDB として動作させる リソース共有 ３ つの PDB が 1 つの CDB で動作するため、 リソースを共有しながら効率的に利⽤ 3 つのデータベースは、それぞれ個別の BaseDB で 動作するためリソースは完全に分離 お客様による管理 3 つの PDB が動作する 1 つの BaseDB の OS、GI、DB を⼀元的に管理 3 つの BaseDBについて、それぞれ OS、GI、DB を個別に管理 メンテナンス 3 つの PDB が動作する 1 つの BaseDB の インフラ、OS、GI、DB の⼀元的なメンテナンス 3 つの BaseDBについて、 インフラ、OS、GI、DB の個別のメンテナンス BaseDB コスト (今回の机上サイジングによる) DB 毎に BaseDB を⽤意する場合よりも低い PDB 集約よりも⾼い RAC x 2 RAC x 2 RAC x 2
28. STEP3-2: 構成案を⽐較する ExaDB-D RAC ノード数違いによる主な考慮ポイント 28 Copyright © 2025, Oracle and/or its affiliates ExaDB-D の場合の２つの構成案の違いを改めて⽰し、お客様の判断材料を提⽰ ExaDB-D 3 ノード RAC 構成 ExaDB-D 2 ノード RAC 構成 概要 ExaInfra として DB Server を 3 台構成にして 3 ノード RAC 構成とする ExaInfra として DB Server を ２ 台構成にして 2 ノード RAC 構成とする 単⼀ノード停⽌時の影響 停⽌影響は 3 台中の1台 停⽌影響は 2 台中の1台 単⼀ノード停⽌時 復旧までの DB ノードの冗⻑性 冗⻑構成あり 冗⻑構成なし 単⼀ノード停⽌時 復旧までの性能維持 残り 2 台で性能維持 この状態での CPU スケールアップも可能 (ExaDB-D はオンライン・スケーリング可能) 残り １ 台で性能維持 この状態での CPU スケールアップも可能 (ExaDB-D はオンライン・スケーリング可能) ExaDB-D コスト (今回の机上サイジングによる) 1 ノード停⽌した場合においても通常時のピークに対応 できる構成を前提とした場合 3 ノード RAC 構成の VM クラスタへの割当 CPU コア 数によるコストは、DB Server １ 台追加によるコストを 考慮しても 2 ノード RAC 構成よりも低い 1 ノード停⽌した場合においても通常時のピークに対応 できる構成を前提とした場合 ２ ノード RAC 構成の VM クラスタへの割当 CPU コア 数によるコストは、3 ノード RAC 構成よりも⾼い
29. まとめ 29 Copyright © 2025, Oracle and/or its affiliates
30. まとめ 30 Copyright © 2025, Oracle and/or its affiliates 「クラウド・アーキテクチャ⽅針検討」実施に向けた DB 構成案合意形成への準備 現⾏データベース環境の理解 STEP 1 データベース・システムの 移⾏先イメージの想定と 机上サイジング STEP 2 コスト・シミュレーションと 構成案の⽐較 STEP 3 1: お客様インプット情報やヒアリングのワークショップを通じて、現⾏データベース環境を理解して CPU、メモリ、I/O などの机上サイジングに影響を与える情報も含めて把握する 2: お客様のご希望される DB クラウド・サービスに対して、選択可能な構成案を提⽰する • 要件や机上サイジングを通じて、必要に応じて適切な別の DB クラウド・サービスの提案も検討する • BaseDB が低コストという先⼊観だけでサービスを選択しても、実際には割⾼となる可能性もある 3: お客様には、複数構成案についてコスト⽐較および柔軟性や運⽤⾯などの違いを⽐較提⽰する クラウドリフト後の構成案と想定コストを提⽰してお客様の判断材料を⽤意する
32. 付録
33. 【ご参考①】 BaseDB: OCPU 数とメモリ設定値早⾒表 (⼀部) 33 Copyright © 2025, Oracle and/or its affiliates OCPU 物理メモリ (GB) sga_target (GB) pga_aggr _target (GB) 1 16 6.50 1.625 2 32 14.50 3.625 3 48 22.50 5.625 4 64 30.50 7.625 5 80 38.50 9.625 6 96 46.50 11.625 7 112 54.50 13.625 8 128 62.50 15.625 9 144 70.50 17.625 10 160 78.50 19.625 11 176 86.50 21.625 12 192 94.50 23.625 13 208 102.50 25.625 14 224 110.50 27.625 15 240 118.50 29.625 16 256 126.50 31.625 * AMD/Intel X9 シェイプの OCPU 数と各種メモリ値 OCPU 物理メモリ (GB) sga_target (GB) pga_aggr _target (GB) 17 272 134.50 33.625 18 288 142.50 35.625 19 304 150.50 37.625 20 320 158.50 39.625 21 336 166.50 41.625 22 352 174.50 43.625 23 368 182.50 45.625 24 384 190.50 47.625 25 400 198.50 49.625 26 416 206.50 51.625 27 432 214.50 53.625 28 448 222.50 55.625 29 464 230.50 57.625 30 480 238.50 59.625 31 496 246.50 61.625 32 512 254.50 63.625
34. 【ご参考②】 BaseDB: ネットワーク帯域と理論上の最⼤ IOPS/スループット早⾒表 34 Copyright © 2025, Oracle and/or its affiliates Network Bandwidth OCPU 数 IOPS Throughput (MB/sec) 1 16,384 128 2 32,768 256 3 49,152 384 4 65,536 512 5 81,920 640 6 98,304 768 7 114,688 896 8 131,072 1,024 9 147,456 1,152 10 163,840 1,280 11 180,224 1,408 12 196,608 1,536 13 212,992 1,664 14 229,376 1,792 15 245,760 1,920 16 262,144 2,048 17 278,528 2,176 18 294,912 2,304 19 311,296 2,432 20 327,680 2,560 Network Bandwidth OCPU 数 IOPS Throughput (MB/sec) 21 344,064 2,688 22 360,448 2,816 23 376,832 2,944 24 393,216 3,072 25 409,600 3,200 26 425,984 3,328 27 442,368 3,456 28 458,752 3,584 29 475,136 3,712 30 491,520 3,840 31 507,904 3,968 32 524,288 4,096 33 540,672 4,224 34 557,056 4,352 35 573,440 4,480 36 589,824 4,608 37 606,208 4,736 38 622,592 4,864 39 638,976 4,992 40 655,360 5,120
35. 【ご参考③】 BaseDB: 初期構築時に選択可能なストレージ・サイズ組み合わせ⼀覧 35 Copyright © 2025, Oracle and/or its affiliates BaseDB: GI および LVM 選択時 に選べるストレージ・サイズ DATA (GB) RECO (GB) 256 256 512 256 1,024 512 2,048 512 4,096 1,024 8,192 2,048 BaseDB: GI 選択時に選べるストレージ・サイズ DATA (GB) RECO (GB) 12,288 4,096 16,384 4,096 24,576 8,192 32,768 8,192 40,960 10,240 49,152 12,288 57,344 14,336 65,536 16,384 73,728 18,432 81,920 20,480 • 初期構築時は DATA のサイズを選択。RECO は上記組み合わせ の通りのサイズで⾃動で決まる • 初期構築後、DATA と RECO はそれぞれ個別に選択可能なサイ ズにスケール・アップすることが可能 • LVM 選択時は最⼤ 8,192 GB までのみの選択
36. 【ご参考④】 Block Volume のサイズと理論上の最⼤ IOPS/スループット早⾒表 (⼀部) 36 Copyright © 2025, Oracle and/or its affiliates IOPS Throughput (MB/sec) Balanced Higher Performance Balanced Higher Performance サイズ (60 IOPS/GB) < 25K (75 IOPS/GB) < 50K (480KBPS/GB) < 480 MB/s (600KBPS/GB) < 680 MB/s 256 GB 15,360 19,200 120 150 512 GB 30,720 38,400 240 300 1,024 GB 61,440 76,800 480 600 2,048 GB 122,880 153,600 960 1,200 4,096 GB 200,000 307,200 1,920 2,400 8,192 GB 200,000 400,000 3,840 4,800 12,288 GB 200,000 400,000 3,840 5,440 16,384 GB 200,000 400,000 3,840 5,440 32,768 GB 200,000 400,000 3,840 5,440
37. 【ご参考⑤】 BaseDB で必要な CPU コア数以上に OCPU 数が多くなるケース 37 Copyright © 2025, Oracle and/or its affiliates (a) sga_target サイズが⼤きいシステム ご利⽤ハードウェア 搭載 CPU モデル 割当 CPU コア数* 物理メモリ量* OS データベース名 データベース・バージョン cpu_count sga_target* pga_aggr_target* データ量 * がある項⽬はサーバーまたはデータベース・インスタンスあたりの数量 例 1(a) 本番環境 (2 ノード RAC) ご利⽤ハードウェア SPARC S7-2 (x2) 搭載 CPU モデル SPARC S7 4.27 GHz 割当 CPU コア数* 6 物理メモリ量* 1,024 GB OS Solaris 11.4 データベース名 基幹DB1 データベース・バージョン 12.2.0.1 EE cpu_count 設定なし sga_target* 300 GB pga_aggr_target* 75 GB データ量 5 TB OCPU 数 物理メモリ(GB) sga_target (GB) pga_aggr_target (GB) … … … … 6 96 46.50 11.625 … … … … 38 608 302.50 75.625 … … … … 64 1,024 510.50 127.625 BaseDB: VM.Standard.E5.Flex 選択した場合の OCPU 数と各種メモリ値 • 割当 CPU コア数 (= OCPU 数) を 6 とした場合、SGA は既存の 300 GB に対して BaseDB はデフォルト 46.50 GB の割当となり、 かなり少ない • 既存と同様の SGA サイズ (300 GB) を、BaseDB でデフオルトで確保 しようとすると、OCPU 数は 38 が必要となる • 既存同様の物理メモリ・サイズ (1.024 GB) を、BaseDB で確保 する場合には、 OCPU 数は 64 が必要となり、さらなるコスト⾼に 現⾏データベース環境の理解 既存性能と⽐較して低下する懸念 お客様が想定するコスト感を上回る懸念
38. 例 1(b) 本番環境 (2 ノード RAC) ご利⽤ハードウェア IBM Power System 搭載 CPU モデル POWER9 割当 CPU コア数* 2 物理メモリ量* 48 GB OS AIX データベース名 基幹DB2 データベース・バージョン 19c EE cpu_count 設定なし sga_target* 20 GB pga_aggr_target* 4 GB データ量 2 TB AWR レポートから 【ご参考⑤】 BaseDB で必要な CPU コア数以上に OCPU 数が多くなるケース 38 Copyright © 2025, Oracle and/or its affiliates (b) I/O 量の多いシステム 現⾏データベース環境の理解 I/O 性能 現⾏最⼤値 IOPS ノード合計最⼤ 16,778.74 ノード1 最⼤ 13,855.04 ノード2 最⼤ 9,780.28 スループット ノード合計最⼤ 1,105.92 MB/sec ノード1 最⼤ 964.70 MB/sec ノード2 最⼤ 918.12 MB/sec OCPU 数 I/O 帯域 IOPS Throughput (MB/sec) … … … … 2 2 Gbps 32,768 256 … … … … 8 8 Gbps 131,072 1,024 … … … … BaseDB : VM.Standard.E5.Flex 選択した場合のネットワーク帯域と I/O 理論値 • 割当 CPU コア数 (= OCPU 数) を 2 とした場合、既存のノードあたり のスループット 964.70 MB に対して BaseDB は理論値としても 最⼤ 256 MB/sec となり、かなり少ない • 既存と同様のノードあたりの最⼤スループット(964.70 MB/sec) を超え る帯域を BaseDB で確保するためには OCPU 数は 8 以上が必要となる • DB クライアントとのネットワーク I/O 量や、Data Guard を構成する 場合は REDO 転送帯域なども別途考慮が必要 既存性能と⽐較して低下する懸念 お客様が想定するコスト感を上回る懸念
39. 【ご参考⑥】 ExaInfra と BaseDB 割当 CPU コア数(エディション別)とのコスト⽐較 39 Copyright © 2025, Oracle and/or its affiliates ⽉額 (744 時間) ⽐較 OCPU 数 EE-EP EE-HP EE 1 ¥155,002 ¥102,300 ¥49,600 2 ¥310,003 ¥204,601 ¥99,200 3 ¥465,005 ¥306,901 ¥148,800 … … … … 11 ¥1,705,018 ¥1,125,304 ¥545,599 … … … … 16 ¥2,480,026 ¥1,636,806 ¥793,598 … … … … 34 ¥5,270,055 ¥3,478,213 ¥1,686,396 … … … … ExaInfra X11M 最⼩構成 (2 x DB Server + 3 x Storage Server) ⽉額: 1,673,985 円 例えば ExaDB-D を利⽤する場合 • BaseDB EE-EP 利⽤時: 最低 11 OCPU 以上 • BaseDB EE-HP 利⽤時: 最低 16 OCPU 以上 • BaseDB EE 利⽤時: 最低 34 OCPU 以上 の差が出るサイジングとなる場合に おおよそコスト的に有利となる⽬安 BaseDB : エディション別 OCPU ⽉額費⽤ • コスト観点では、特に EE-EP を必要とする場合 (RAC 構成など) には、 BaseDB だけでなく ExaDB-D の検討の余地が⽣じる
40. 【ご参考⑦】 ExaInfra DB Server と CPU コア数とのコスト⽐較 40 Copyright © 2025, Oracle and/or its affiliates ⽉額 (744 時間) ⽐較 EE-EP CPU コア⽉額費⽤ CPU コア 数 EE-EP 1 ¥155,002 2 ¥310,003 3 ¥465,005 ExaInfra DB Server 1 台あたりの ⽉額費⽤: 334,790 円 例えば ExaDB-D を利⽤する場合、 2 CPU コア分の差が出るサイジング となる場合にはノード数を増やす⽅が コスト的に有利となる⽬安 現⾏は 1 ノード障害時でもピークに対応できるような設計でリソースを 構成している場合、残りのノードで必要とするリソース合計 CPU 24 CPU コア VM VM 24 24 VM VM 12 12 VM 12 VM VM 8 8 VM 8 VM 8 計 48 計 36 計 32 +1 DB Sever +2 DB Sever ¥7,440,077 ¥5,914,848 ¥5,294,842 + + + + + + = = = CPUコスト分⽉額 CPUコスト+ 1 DB Server 分⽉額 CPUコスト+ 2 DB Server 分⽉額 2 ノード RAC 構成 3 ノード RAC 構成 4 ノード RAC 構成 ExaDB-D ノード数および CPU 数のコスト感の例 ※円内の数字は割当 CPU コア数 低
41. Thank you Oracle Cloud Lift Services Copyright © 2025, Oracle and/or its affiliates 41