【Oracle Cloud ウェビナー】クラウド時代を乗り切るOracleデータベースのテスト効率化手法～定期的なアップグレード/パッチ適用の課題も運用自動化で解決～

Oracle Cloud ウェビナーシリーズ情報: https://oracle.com/goto/ocws-jp
セッション動画: https://go.oracle.com/ocws-jp-ondemand

Transcript

1. クラウド時代を乗り切るOracleデータベースの テスト効率化手法 ～定期的なアップグレード/パッチ適用の課題も運用自動化で解決～ 日本オラクル株式会社 2023年12月20日 Oracle Cloud ウェビナー
2. Copyright © 2023, Oracle and/or its affiliates 2 Safe Harbor Statement 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供 を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、 マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購 買決定を行う際の判断材料になさらないで下さい。 オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量 により決定されます。 Oracleは、米国オラクル・コーポレーション及びその子会社、関連会社の米国及びその他の国における登録商標 または商標です。他社名又は製品名は、それぞれ各社の商標である場合があります。
3. Copyright © 2023, Oracle and/or its affiliates 3 Agenda 1 2 3 アップグレード/パッチ適用の必要性 RAT機能全体像 DBテスト計画／DBテストの流れ RAT各機能の使い方 テスト自動化ソリューション概要/自動化ツール仕様 お客様事例 4 5 6
4. Copyright © 2023, Oracle and/or its affiliates 4 Databaseにおけるアップグレード/パッチ適用の必要性 更改時にバージョンアップする 新機能・性能アップ パッチを当て続ける メリット Old New 更改などの機器入れ換え時は、並行して リソースが確保できます。 本番環境へのバージョンアップ・テスト には最もコストが良いタイミングです。 新しいHWには、古いDBはNG 6～8カ月 9～11カ月 12か月 以上 新規 既知 いつまでに修正されていた？ セキュリティインシデント・バグの9割は 既知の不具合が原因であり、最新のバー ジョン・定期的にパッチを当てていること で予防できる。 パッチは最新DB向けに作成されます。 既知・新規？ 2倍 OFF ON 一例) XRMEM Cache on/off ExaX8M DB 19c～ Exadata X8M以降、Database 19c以降 からの最新バージョンから性能アップす る様々な機能がサポートされています。 XRMEMはIndexを使うOLTP系処理に大 幅改善が見込めます。 *Oracle Databaseの各リリースのパッチ提供期間に関 してはMy Oracle SupportよりDoc ID: 742060.1 を ご参照ください。 ・新機能の活用/機能拡張等による、 性能向上・運用管理性向上・セキュリ ティ強化 ・既知不具合の解消・新規パッチの提供 (*)最新バージョンを活用し、新機能を 活用し、データを活用する ・セキュリティ事故発生 ・既知不具合による障害発生 ・アップグレード難易度上昇 ・将来的なコスト増の潜在 ・多額の損害が起きる可能性 最新を使わないリスク 最新バージョンを使うメリット ・アプリケーションのUpgradeも合わ せて検討、対応しないといけない ・計画、テスト、調整が大変 ・作業工数、費用がかさむ 最新バージョンを使うデメリット
5. Copyright © 2023, Oracle and/or its affiliates 5 Oracle Database Upgradeのハードル • アプリケーション(SQL)がエラーにならないか？ • アプリケーション(SQL)性能が悪化しないか？ 既存APのUpgradeによる影響 • データベースサイズが大きく停止時間が長い • 停止時間を取れるタイミングは限られている Upgrade時のデータベース停止時間 Upgradeの必要性と効果はわかっても、Upgrade実施は難しい Oracle Real Application Testingが有効 Oracle GoldenGateが有効
6. Copyright © 2023, Oracle and/or its affiliates 6 Agenda 1 2 3 アップグレード/パッチ適用の必要性 RAT機能全体像 DBテスト計画／DBテストの流れ RAT各機能の使い方 テスト自動化ソリューション概要/自動化ツール仕様 お客様事例 4 5 6
7. Copyright © 2023, Oracle and/or its affiliates 7 Real Application Testing(RAT)とは？ Oracle Real Application Testing（以下RAT） は、主にUpgrade時に 使用できる、高品質かつ低作業コストでテストするためのオプションです。 Real Application Testing Performance Analyzer (SPA) ⚫ SQL単体テスト（性能／非互換検出） ⚫ システム変更前後でのSQLの実行計画やパ フォーマンスの比較レポートを生成 Database Replay ⚫ システムテスト ⚫ 本番環境のトランザクションを記録(キャプチャ)し、 テスト環境で再現(リプレイ)、比較レポートを生成 ？ 【RATメリット】：テスト大幅効率化（テスト工数削減）、テスト期間短縮
8. Copyright © 2023, Oracle and/or its affiliates 8 Real Application Testing(RAT)とは？ Oracle Real Application Testing（以下RAT） は、主にUpgrade時に 使用できる、高品質かつ低作業コストでテストするためのオプションです。 Real Application Testing Performance Analyzer (SPA) ⚫ SQL単体テスト（性能／非互換検出） ⚫ システム変更前後でのSQLの実行計画やパ フォーマンスの比較レポートを生成 Database Replay ⚫ システムテスト ⚫ 本番環境のトランザクションを記録(キャプチャ)し、 テスト環境で再現(リプレイ)、比較レポートを生成 ？ 【RATメリット】：テスト大幅効率化（テスト工数削減）、テスト期間短縮 実行計画や単体性能、SQL 互換性(エラー有無)のチェックに スループットのチェック、 リソース使用量のチェックに
9. Copyright © 2023, Oracle and/or its affiliates 9 データベース変更時のテスト RATは性能テストを自動化 主な担当 チーム DBに関するテスト テスト内容 一般的なテスト方法 業務 (開発) 業務機能テスト ・機能要件を満たしているか ・単体試験 ・結合試験 性能テスト ・SQL性能(レスポンス)を満たしているか ・負荷ツールの利用 基盤 ・DB負荷テスト(スループット) 運用テスト・ DB起動/停止 ・バックアップ/リカバリ ・FailOver確認 ・DB起動/停止やバックアップ/リカバリ、 フェイルオーバー等が準備したスクリプト、 手順書で想定通り動作するか ・基盤試験 RATカバー範囲 SPAカバー範囲 Database Replayカバー範囲
10. Copyright © 2023, Oracle and/or its affiliates 10 Agenda 1 2 3 アップグレード/パッチ適用の必要性 RAT機能全体像 DBテスト計画／DBテストの流れ RAT各機能の使い方 テスト自動化ソリューション概要/自動化ツール仕様 お客様事例 4 5 6
11. Copyright © 2023, Oracle and/or its affiliates 11 アップグレード時に見受けられる問題 アップグレード オプティマイザの挙動の変化 非互換の発生 新機能の自動起動 オプティマイザの挙動が変わり、アップグレードすること で性能が変わる可能性がある。 SQL構文確認の厳格化など、バージョンが変わった影響を 受けて実行できなくなるSQLが発生する可能性がある。 Oracle Databaseは各バージョン毎に新しい機能を追加し ており、場合によっては新機能がデフォルトでONとなり、 データベースの挙動が変わることがある。 アップグレード時に問題を引き起こす可能性がある事象 統計 情報 統計 情報 CBO 12c CBO 19c ------------------------------------------------ | Id | Operation | Name | ------------------------------------------------ | 0 | SELECT STATEMENT | | |* 1 | HASH JOIN | | |* 2 | HASH JOIN | | |* 3 | TABLE ACCESS FULL | TABLE_A | | 4 | MERGE JOIN CARTESIAN| | |* 5 | TABLE ACCESS FULL | TABLE_B | | 6 | BUFFER SORT | | |* 7 | TABLE ACCESS FULL | TABLE_C | | 8 | INDEX FULL SCAN | TABLE_D_PK | ------------------------------------------------ ------------------------------------------------ | Id | Operation | Name | ------------------------------------------------ | 0 | SELECT STATEMENT | | |* 1 | HASH JOIN | | |* 2 | HASH JOIN | | |* 3 | TABLE ACCESS FULL | TABLE_A | | 4 | MERGE JOIN CARTESIAN| | |* 5 | TABLE ACCESS FULL | TABLE_B | | 6 | BUFFER SORT | | |* 7 | TABLE ACCESS FULL | TABLE_C | | 8 | INDEX FULL SCAN | TABLE_D_PK | ------------------------------------------------ ※これらの変化は恩恵も非常の高く、適切な使い方をすることで 問題になることはありません。 アップグレード前にこれらの変化 が発生する可能性を把握し、適切に使うことが重要となります。 異なる実行計画による 性能劣化が発生
12. Copyright © 2023, Oracle and/or its affiliates 12 アップグレード後に発生する問題の原因分析 非機能テストの重要性を 認識していない プロジェクトの遅れにより テスト期間が短縮 テスト実施コンディション が不適切 テストの実施方法が 不適切 テスト結果への 対応が遅い テストの範囲が 不適切 テストへの意識の問題 アプリケーションが動作する かどうかを主眼としてテスト し、非機能テスト(主に性能) に対する意識が低いまま、 C/Oを迎えるプロジェクトが 多数見受けられる。 場合によってはプロジェクト の遅れを吸収するためにテス トそのものが割愛される。 テストコンディションの問題 テスト実施方法の問題 結果への対応の問題 テストは実施されているが、 そのコンディションやテスト 範囲が不適切で、C/O後に発 生しうる問題をテストフェー ズで洗い出せないプロジェク トが見受けられる。 結合・総合テストのみを実施 するプロジェクトが多く、 C/O後にSQLの問題が発生す ることが見受けられる。 また、場合によっては手動で テストを実施しており、テス ト網羅性が非常に低いテスト も多く見受けられる。 テストで明らかになった問題 に対しては迅速かつ正確に対 応する必要がある。 Oracle Databaseでは取りう る策を各バージョンで増やし てきておりますので、そのよ うな新しい技術を含めた準備 を事前にすることが重要とな る。
13. Copyright © 2023, Oracle and/or its affiliates 13 アップグレードに於ける問題への対応 非機能テストの重要性を 認識していない プロジェクトの遅れにより テスト期間が短縮 テスト実施コンディションが 不適切 テストの実施方法が 不適切 テスト結果への 対応が遅い テストの範囲が 不適切 非機能テストのゴールを明確化 し、関係者で合意する 非機能テスト実施内容を合意し、 テスト不足のままリリース されることを防ぐ テスト前提を十分に吟味し 適切なコンディションで テストを実行する 本番C/O時に発生する 問題を極小化する 網羅度が高く、繰返し実行可能 なSQL単体テスト方式を準備す る テスト品質とコスト両面での プロジェクト貢献 効果的／スピーディーな 解決策を準備する テスト期間の延伸防止 問題の原因 対応案 期待する効果 抜け漏れのない対応がテスト成功の鍵となる ① ② ③ ④
14. Copyright © 2023, Oracle and/or its affiliates 14 1. 非機能テストのゴールの明確化 Level1： エラーが発生 しないこと オブジェクト定義が必要 本番相当の統計情報が必要 本番相当のデータが必要 テ ス ト 環 境 に 必 要 な 要 素 Level3： 処理時間が 遅くならないこと Level2： 実行計画が 変わらないこと 実行計画を比較 同じ？ 実行して比較 向上？ チューニングを実施 1. 実行計画の比較 アップグレード前後で実行計画が 変わっていない場合は、性能劣化 をしないとみなす。 2. 実行統計の比較 実行時間とバッファキャッシュ使 用量がどちらも向上している場合 は性能が向上するとみなす。 3. チューニングのクライテリア チューニングは現行と比べX秒以 内の差は許容する。 <テストのGoal> • 性能担保の基準が決定したら計画段階で全ステークホルダーと合意することが重要 例：SQL単体テストの性能担保基準
15. Copyright © 2023, Oracle and/or its affiliates 15 • 性能テストを実施する際は、下記にあげるようなテスト環境やコンディションをテストの 目的に合わせて適切に設定することがテスト成功の前提となる • テストコンディションやテスト範囲を計画段階で適切に設定することが重要 2. 適切なコンディションでテストを実施 フェーズ 単体テスト 総合テスト 受入テスト 目的 SQL単体での性能 実行計画/実行結果の確認 アプリケーション/バッチ観点での 性能確認 受入基準を満たす性能かを 実行計画で確認 環境 検証環境 総合テスト環境 受入テスト環境 データ量 データ量は本番と同等 データ量は本番と同等 - データ精度 本番データ 本番データ - 統計情報 運用方針に従い、検証環境で 統計情報を取得 本番と同等 本番環境/開発環境と同等 担当者 各開発ベンダー アプリケーション担当 アプリケーション担当
16. Copyright © 2023, Oracle and/or its affiliates 16 • 全てのSQLの洗い出し＝テスト品質の向上につながりますが、業務上優先順位が高いSQL をテスト対象とすることで、システム利用ユーザの満足度は向上します。 3. 網羅率担保の基準の明確化（1/2） テスト網羅率 品質 ユーザ 満足度 コスト コスト 過剰な品質領域 品質 ユーザ満足 度 【テスト網羅率と品質・コスト・ユーザ満足度の関係（イメージ）】 テスト網羅率を上げると品質は向上しますが、 ある点を境にユーザ満足度は上がりにくくな ります（例えば、ほとんど使われない機能の テストは満足度向上につながりにくい） 過剰な品質によるコスト増を避け、 低コストでテストを実現するには、 網羅率に対して割り切ることは重要
17. Copyright © 2023, Oracle and/or its affiliates 17 • テスト対象とするSQLの洗い出し方法を決定したら、計画段階で全ステークホルダーと合 意することが重要 3. 網羅率担保の基準の明確化（2/2） アプリのソースを調査してSQLを取得する方法 本番機で実行されたSQLをキャプチャーする方法（STSを使用） 網羅性 中～高い • 全ソースに対して調査を行えば網羅性は高まるが、実際には 重要な機能などに絞って実施することが多く、その場合の網 羅性は中程度になる。 • 入力値のバリエーションを調べるのは困難。 中～高い • キャプチャー期間中に行われたアプリ操作の網羅性に依存する。キャプチャー 期間中に全ての機能が実行された場合は網羅性は高くなる。 • 入力値のバリエーションを調べるのは容易。 コスト 高い • アプリ調査に多くの工数が掛かる。 • アプリの数に比例して増大する。 低い • アプリ調査は不要。 • SQL数が多くても工数はあまり増えない。 期間 長い • アプリ調査に多くの期間が掛かる。 短い • 本番機でキャプチャーする期間のみ。 本番環境へ の負荷 無し • アプリのソース調査のため、本番への負荷はかからない 取得方法に依存 • カーソル・キャッシュから取得する場合は、本番環境上のカーソル・キャッシュからの収集となり、 網羅性は高い、かつほとんど負荷を与えず取得できる。 • AWRから取得する場合は、AWRに保存されるSQLのみが対象となる。デフォルトではAWR に保存されるSQLは少ないため、網羅性は極めて低くなる。 • SQLトレースから取得する場合は、DBサーバーにかかる負荷が増えるため、 本番環境へのパフォーマンスへの影響及びディスクサイズに注意が必要。
18. Copyright © 2023, Oracle and/or its affiliates 18 3. 網羅度が高く、繰返し実行可能なSQL単体テスト方式を準備する 施策の影響確認や各処理の確認で行うSQL 単体テスト方式は同じとなる。 その為、自動で実行でき、繰り返し実行可 能なテスト方式を準備することが重要 処理A 処理B 処理C SQL SQL SQL SQL SQL 表A 表B 表C 索引を追加 統計情報を 再取得 施策 月次 処理A 日次 処理A 月次 処理B 日次 処理B 各処理毎のテスト 何度も実行される SQL単体テストの自動化と テスト対象SQL単体の網羅度が向上 アップグレードを成功させるために 重要となる。 データベースへの処理は SQLで実行されるため SQLで性能を担保するこ とが非常に重要となる SQLの単体性能試験 結合試験 総合試験 施策の影響を 確認するために SQL単体試験 を実施 施策の影響確認 検証対象とするSQLの網羅度を上げること が処理の網羅度を上げることとなる。 SQLの網羅度 繰返し実行可能なテスト方式
19. Copyright © 2023, Oracle and/or its affiliates 19 3. (参考)繰返し実行できるテスト 検証環境 性能 情報 STS 実行/測定 比較レポート 本番環境/テスト環境 準備フェーズ 変更 テストフェーズ STS ベースライン情報となるSTSの取得 *検証環境でSTSを取得する場合は検 証環境で処理を一度流す必要があり ます。 索引を追加 統計情報を 再取得 検証環境 施策となるチューニング案を実装 ・比較1:実行計画 実行計画レベルで比較します。 検証環境に統計情報を設定する ことで簡易に比較可能となりま す。 ・比較2:実行統計 SQLを実行して比較します。 データを準備する必要があるた め、実行計画比較よりコストは かかりますが、より精度の高い 比較が可能となります。 STSは取得もと環境で実行されてい るSQL実行情報をSQL_IDや実行計 画とともに保存する情報となります。 同じベースラインを使用して 繰り返しテストを実行すること が可能です。
20. Copyright © 2023, Oracle and/or its affiliates 20 4. 効果的／スピーディーな解決方法を用意する <テスト実施> テスト テスト結果 性 能 劣 化 に 対 す る 効 果 SQL 改修 ヒント 句 SPM パラメータ変更 オブジェクト 追加・変更 パッチ適用 <結果の分析> アドバイザ 結果 DBA DBA アドバイザ <対策の施行> ロジック修正 データ補正 SQL改修 ヒント句 SPM 挙動問題 性能問題 パッチ適用 DBパラメータ変更 オブジェクト変更 パッチ適用 テスト結果の分析・対策方法を事前に 準備することで時間短縮だけでなく 属人化解除による品質の強化も 期待できます アドバイザ使用による 一次フィルタの活用 対応チームの確立に よる対応品質の向上
21. Copyright © 2023, Oracle and/or its affiliates 21 Agenda 1 2 3 アップグレード/パッチ適用の必要性 RAT機能全体像 DBテスト計画／DBテストの流れ RAT各機能の使い方 テスト自動化ソリューション概要/自動化ツール仕様 お客様事例 4 5 6
22. Copyright © 2023, Oracle and/or its affiliates 22 SPAの使用イメージ AP 本番環境 (またはSQL取得が可能な同等の環境) 3. STSをステージング 環境にインポート 2. データをステージング 環境にセット ステージング環境 変更前/ 変更後 環境 リモートDB 4. 変更前/変更後の環境に 対してSQL実行、性能等測定 (SPA試行) DB Link / ADG 1. SQLチューニングセッ ト(STS)を使用し、SQL 情報を取得 データベースのみでテストが可能 STS SPA STS 5. レポート生成
23. Copyright © 2023, Oracle and/or its affiliates 23 SPAのレポート（性能比較） テスト概要 •50本のSQLの性能測定 •変更前後で比較レポート •比較軸はバッファ読み取りを選択 結果の概要 •変更後、バッファ読み 取りが110％増加 内訳の概要 •一部のSQLの実行計画が変化 •改善するものも低下するものもある 改善すべきSQLへのアクション •チューニングアドバイザの実行 •SQL計画ベースラインの作成
24. Copyright © 2023, Oracle and/or its affiliates 24 • 新環境でエラーとなると下記のようにレポートとして表示されます。そのエ ラーを調査することで該当しうる非互換を調査することが可能 SPAのレポート（非互換調査） 「副問い合わせ内で GROUP BY 句使用時の SELECT リストの制限事項の変更について (KROWN:141697) (Doc ID 1749380.1)」に 該当した例 • RATを使用した非互換調査結果例
25. Copyright © 2023, Oracle and/or its affiliates 25 SPAのレポート / HTML,テキスト形式 Enterprise Managerからの操作のほか、 API(DBMS_SQLPAなど)からの操作、HTMLや テキスト形式でのレポート出力も可能
26. Copyright © 2023, Oracle and/or its affiliates 26 DB Replayの使用イメージ 本番環境 テスト環境 リプレイ ・クライアント AP キャプチャファイル 1. キャプチャ ・各セッションでキャプ チャを実施 ・ディレクトリオブジェク ト上にファイル群として出 力 2. データ移行 ・キャプチャ時と極力近い データをテスト環境へ移行 3. リプレイ前処理 ・キャプチャを前処理後、 リプレイ・クライアントへ配置 4. リプレイ ・リプレイ・クライアントよ り再生
27. Copyright © 2023, Oracle and/or its affiliates 27 DB Replay実行結果 DB統合基盤の既存ワークロード をDB Replayを使用して再生 新たに統合基盤に乗せる アプリケーションのワークロードを テストツールから生成 進捗確認やリプレイ停止は 管理画面からいつでも可能 開始時間と終了時間や、取得時と Replay 時の処理時間を比較し、 全体性能の劣化がないかを確認 非互換の有無も確認可能
28. Copyright © 2023, Oracle and/or its affiliates 28 • アップグレード時のSQL互換性チェック – SPAを使用し、数万本のSQLからエラーの発生するSQLを発見 • アップグレード時/RU適用時の性能試験 – SPAを使用し、数万本のSQLから実行計画や性能が変化するSQLを発見 • 定期パッチ適用による安定運用 – SPAにより定期パッチ(セキュリティ、修正)の適用に必要なテストをルー ティン化 • H/W移行にともなう性能影響の調査 – DB Replayにより、新しいH/Wでのリソース使用量等を正確に調査 RATのユースケース
29. Copyright © 2023, Oracle and/or its affiliates 29 他のワークロードシミュレーションツールとの比較 他のワークロードシミュレーションツール Real Application Testing 性能チェック 通常、スループット観点の評価のみ 個別SQLレベル(実行計画やエラー)と、ワークロード全体の スループットの両観点でチェック可能 性能面以外のチェック アプリケーションに返されたエラーのチェッ ク(DBレベルのエラーは追加分析が必要) SQLエラーの有無、取得行数の差異などをチェック可能 テストの網羅性 シナリオの検討と、それを実現するためのス クリプト作成作業が必要。現実的な工数で実 施するには、通常SQL数やシナリオの絞り込 みが必要 SPAではSTS作成、DB Replayではキャプチャにより、少な い工数でSQLやシナリオの網羅度を高められる テストの正確性、再現 性 擬似的なワークロードによるテスト 実SQL、実ワークロードを使用したリアルなテストが可能 テストの柔軟性 スクリプト作成により、様々なワークロード の作成が可能 思考時間やセッション数の調整、複数のキャプチャの統合リ プレイなどが可能。新規ワークロードの作成は不可 (スコー プ外。Application Testing Suiteで対応可能) 環境構築の工数 アプリケーション層も本番同様に構築する必 要がある アプリケーション層の構築は不要 (Database Replayにおけるリプレイクライアントのみ必要) テスト→性能改善の サイクルの効率性 Oracle Databaseの性能分析は別途行う必要 がある SPAとチューニング・アドバイザ、DB ReplayとAWR期間比 較レポートが密接に連携。テスト後の性能改善を強力サポー ト
30. Copyright © 2023, Oracle and/or its affiliates 30 Oracle Database Cloud Service: エディション Extreme Performance High Performance Enterprise Edition Adds… Adds… Adds… Multitenant Partitioning Advanced Compression Advanced Security, Label Security, Database Vault Real Application Clusters DB In-Memory Active Data Guard • 完全なデータベース・ インスタンス • 表領域暗号化 Standard Edition • 全てのEE 標準機能 - Data Guard - Hybrid Columnar Compression(HCC) - パラレル処理 etc Real Application Testing Advanced Analytics, Spatial and Graph, OLAP Management Packs (Data Masking and Subsetting Pack, Diagnostics and Tuning Packs) 全てのデータベース・オプション機能 が利用可能 Oracle Database Cloud では、 全てのエディションで表領域暗 号化機能を提供 Management Packs (Database Lifecycle Management Pack, Cloud Management Pack for Oracle Database) EEでRATの使用 可能
31. Copyright © 2023, Oracle and/or its affiliates 31 Agenda 1 2 3 アップグレード/パッチ適用の必要性 RAT機能全体像 DBテスト計画／DBテストの流れ RAT各機能の使い方 テスト自動化ソリューション概要/自動化ツール仕様 お客様事例 4 5 6
32. 32 テスト自動化ソリューション概要/自動化ツール仕様 運用自動化が求められる背景 Copyright © 2023, Oracle and/or its affiliates ➢ オンプレミスより、クラウド環境を選択するお客様の増加 ① サブスクリプションモデル ✓ 専有環境をサブスクリプションで利用可能 ✓ 環境の構成を最適化することで、大半のケースでコストダウンが可能 トレンド クラウド環境のメリッ ト/特徴 クラウド環境の課題 ➢ Exadataのインフラストラクチャー・レイヤーに関しては、四半期メンテナンスが実施されるため、業務継 続性に関する対策・運用が必要（ExaDB-D/ExaDB-C@Cのみ） ➢ クラウド環境の運用でも業務影響を考慮する必要があるのはDBのRU適用 ➢ 少ない工数および短期間でテストを実施するため、“Oracle Real Application Testing（RAT）”の重要性は高い ➢ 弊社コンサルティングサービスでは、OCI環境におけるRAT運用時のタスクを整理し、RAT運用自体を自動化することで、更なる工数 削減（テスト期間、OCI環境利用コスト、DBAの作業コスト）を検討および検証 ③ 環境構築/運用の容易性 ✓ DBインスタンスの作成、DB複製およびリストアなどの操作がGUIから可能 ② フレキシビリティ ✓ CPU数を流動的に変更可能 ✓ スケールアウト（DBサーバー、ストレージサーバーの追加）もGUIから可能 ➢ OS/GI/DBのパッチ適用はGUIから可能だが、引き続きお客様による対応が必要
33. 33 テスト自動化ソリューション概要/自動化ツール仕様 インフラ運用自動化成熟度 ⚫ インフラ運用自動化成熟度 ▸ Oracle Consultingが定義しているインフラ運用自動化の成熟度は下記の通り ▸ Oracle Consultingは、RAT運用自動化に関して”Level 5”までの内容を提言 • 環境構築の自動化：OCI環境にパッチ適用前後の2つのバージョンのデータベースを作成 • RAT自動実行：データベースに対するRATを利用したテストを実行 Copyright © 2023, Oracle and/or its affiliates Level 1 Level 2 Level 3 Level 4 Level 5 DBトラブル迅速解決 TFA導入 パッチ適用前試験効 率化 TFA導入 RAT ログ監視/視覚化 TFA導入 RAT O&M IaC導入 TFA導入 RAT O&M IaC導入 TFA導入 RAT O&M 環境構築の自動化 環境構築の自動化 SQL性能自動分析 インフラ運用自動化 成熟度
34. 34 テスト自動化ソリューション概要/自動化ツール仕様 RAT運用自動化の概要 Copyright © 2023, Oracle and/or its affiliates ⚫ RAT運用自動化の概要 ▸ RAT運用自動化に必要な事前準備は下記の通り ①実行サーバ環境セットアップ ②パッチ適用前後の各ソフトウェアイメージ作成 ③STS取得 (スクリプトで半自動化) ▸ テスト自動化の範囲は下記の通り ①環境構築の自動化 • 商用DB（BaseDBインスタンス前提）の オンデマンド・バックアップを取得 • VCN/Subnetなどのテスト用NW環境作成 • バックアップからパッチ適用前バージョンの BaseDBインスタンス作成 • バックアップからパッチ適用後バージョンの BaseDBインスタンス作成 ②RAT実行 • パッチ適用前バージョンのDBに対してSPA実行 • パッチ適用後バージョンのDBに対してSPA実行 • 実行結果比較、レポート出力 システム構成例 OCI Region VCN（本番環境） Subnet Database System （商用DB） Subnet 実行サーバ Object Storage VCN（テスト環境） Subnet Database System Database System バックアップ取得 SPA実行 プロビジョニング プロビジョニング SPA実行 (DBLINK) パッチ適用前 パッチ適用後 Ansible & Terraform
35. 35 テスト自動化ソリューション概要/自動化ツール仕様 自動化ツールの説明（1/5） ⚫ 自動化ツールの構成と実行形式 ▸ Ansible、Terraform、シェルスクリプトを利用 ▸ Ansible Playbookより「OCIリソースの作成用シェル」、「RAT（SPA）実行シェル」を呼び出し実行 • 「OCIリソースの作成用シェル」は、Terraformコマンドを実行 • 「RAT（SPA）実行シェル」は、SQLスクリプトを実行 Copyright © 2023, Oracle and/or its affiliates Ansible Playbook OCIリソースの作成用シェルスクリプトの実行 （Terraform実行） RAT（SPA）実行シェルスクリプトの実行 Terraformテンプレート SQLスクリプト Terraformテンプレートを参照 SQLスクリプトをコール
36. 36 テスト自動化ソリューション概要/自動化ツール仕様 自動化ツールの説明（2/5） ⚫ Ansible Playbookの例（1/2） ▸ yamlファイル（tasksセクションのみ抜粋）は下記の通り Copyright © 2023, Oracle and/or its affiliates tasks: - name: setup oci network ansible.builtin.command: sh oci_create.sh oci_core_subnet.ocssn1 &（# OCI NWリソース作成シェルを実行） - name: pause pause: seconds: 120（# 120秒待機） - name: setup dbsystem 1 ansible.builtin.command: sh oci_create.sh oci_database_db_system.new_dbsystem1 &（# BaseDB#1作成シェルを実行） - name: pause pause: seconds: 300（# 300秒待機） - name: setup dbsystem 2 ansible.builtin.command: sh oci_create.sh oci_database_db_system.new_dbsystem2 &（# BaseDB #2作成シェルを実行） - name: pause pause: seconds: 120（# 5秒待機） OCIリソースの作成用シェル実行時、 Terraformテンプレートを読み込み、 TerraformコマンドにてOCIリソース、 BaseDBを作成
37. 37 テスト自動化ソリューション概要/自動化ツール仕様 自動化ツールの説明（3/5） ⚫ Ansible Playbookの内容（2/2） ▸ yamlファイル（tasksセクションのみ抜粋）は下記の通り Copyright © 2023, Oracle and/or its affiliates - name: setup network 1 ansible.builtin.command: sh setnetwork1.sh &（BaseDB接続用IPアドレス抽出シェルを実行） - name: pause pause: seconds: 120（# 120秒待機） - name: setup network 2 ansible.builtin.command: sh setnetwork2.sh &（ BaseDB接続用IPアドレス抽出シェルを実行） - name: pause pause: seconds: 120（# 120秒待機） - name: exec rat ansible.builtin.command: sh exec_spa_all.sh &（# RAT実行シェルを実行） RAT実行には、実行サーバからのOracle Net接続が必要であ るため、BaseDBのIPアドレスを取得し、実行サーバのhosts に設定 ※RACのBaseDB複製前にIPアドレスを取得できないため、複 製後にIPアドレスを取得 SQLスクリプトをコールし、RAT（SPA）を実行
38. 38 テスト自動化ソリューション概要/自動化ツール仕様 自動化ツールの説明（4/5） ⚫ OCIリソースの作成用シェルスクリプトの処理の流れ ▸ OCIリソース作成の流れは下記の通り Copyright © 2023, Oracle and/or its affiliates # 大項目 中項目 小項目 1 OCIリ ソース作 成 OCIリソースの作成 VCNの作成 2 サブネットの作成 3 ゲートウェイの作成 4 ルート表の作成 5 セキュリティ・リストの作成 6 LPGの作成、ピアリング設定 7 BaseDB複製用バック アップの取得 BaseDB複製用バックアップをソースDBCSから取 得 8 BaseDB#1を構成 （パッチ適用前バー ジョン） バックアップからBaseDBを作成 9 BaseDB#2を構成 （パッチ適用後バー ジョン） バックアップからBaseDBを作成 10 BaseDBへの接続設 定 BaseDBのIPアドレス情報を取得し、実行サーバ のhostsに設定 VCN（本番） Subnet BaseDB（ソース） Subnet 実行サーバ Object Storage VCN（テスト自動化） Subnet BaseDB(パッチ適用前) Local Peering Gateway #7 BaseDB複製用バックアップの取得 BaseDB(パッチ適用後) #8 BaseDBを構成 #9 BaseDBを構成 #1～#6 OCIリソースの作成 #10 BaseDBへの接続設定
39. VCN（テスト自動化） 39 テスト自動化ソリューション概要/自動化ツール仕様 自動化ツールの説明（5/5） ⚫ RAT（SPA）実行シェルスクリプトの処理の流れ ▸ RAT（SPA）実行の流れは下記の通り Copyright © 2023, Oracle and/or its affiliates # 大項目 中項目 小項目 1 RAT(SP A)実行 RAT(SPA)実行 初期化パラメータ変更(パッチ適用前)(*) 2 初期化パラメータ変更(パッチ適用後)(*) 3 パブリックDBLINK作成 4 SPA実行（実行計画比較） 5 STSフィルタ 6 SPA実行（性能比較） 7 SPAレポートの作成 VCN（本番） Subnet BaseDB(ソース) Subnet 実行サーバ Object Storage Subnet BaseDB(パッチ適用前) Local Peering Gateway BaseDB(パッチ適用後) RAT(SPA)実行 SPA実行 (DBLINK) (*) 複製後のBaseDBには、“open_links”、”global_names”の変更値が反映されな いため、本ステップで変更する必要がある。
40. Copyright © 2023, Oracle and/or its affiliates 40 Agenda 1 2 3 アップグレード/パッチ適用の必要性 RAT機能全体像 DBテスト計画／DBテストの流れ RAT各機能の使い方 RAT事例紹介 お客様事例 4 5 6
41. 41 お客様事例 検証実施の経緯 Copyright © 2023, Oracle and/or its affiliates • RAT運用自動化の取り組 みを相談 • ExaDB-D/ExaDB-C@C を対象とした運用自動化 をターゲットに決定 • Cloud Universal Credits の余剰分を利用 • ExaDB-C@Cを中心とし たクラウド移行支援中の お客様 • Cloud Universal Credits の余剰あり ▸ プロジェクトの状況 • 本番環境とは異なるVCN/ コンパートメントを利用 • 自動化対象は、テスト環 境構築→テスト検証→テ スト環境削除 • 結果や利用ツールを、お 客様にフィードバック ▸ ディスカッション ▸ 合意
42. 42 お客様事例 自動化検証の概要 Copyright © 2023, Oracle and/or its affiliates ⚫ お客様環境にて、自動化検証を実施（ExaDB-D/ExaDB-C@C） ▸ 自動化検証の事前準備は下記の通り • ExaDB-C@CからZFS上にRMANバックアップを取得 • ExaDB-Dインスタンスを新規に作成 • パッチ適用前バージョンはExaDB-C@Cと同じバージョン • バックアップからパッチ適用前/後バージョンのDBを複製 ▸ テスト自動化の範囲は下記の通り • パッチ適用前バージョンのDBに対してSPA実行 • パッチ適用後バージョンのDBに対してSPA実行 • 実行結果比較、レポート出力 Xシステム構成 OCI Region お客様DC VCN（RAT検証用） Subnet ExaDB-C@C RMAN DBバックアップ Subnet Subnet ExaDB-D パッチ適用前 パッチ適用後 実行サーバ Ansible & Terraform
43. 43 お客様事例 本プロジェクトの活動報告（1/3） ⚫ 本PJでは、RAT（SPA）実行のみを自動化 Copyright © 2023, Oracle and/or its affiliates OCI Region VCN （本番環境（稼働中）） お客様DC VCN （RAT検証用） Subnet ExaDB-C@C Subnet Subnet ExaDB-D パッチ適用前 パッチ適用後 実行サーバ Subnet Subnet Subnet ExaDB-D 踏み台サーバ システム構成（手動） ✓ RAT検証用にVCN/コンパートメ ントを分けて作成 システム構成（手動） ✓ RAT検証用にExaDB-Dインスタ ンスは新規に作成 テスト自動化スコープ • SPA実行→レポート出力の工程の自動化 • SPAレポートでのSQL実行計画変動の確認 • SPAレポートでのSQLパフォーマンス統計変動 の確認 システム構成（手動） ✓ ExaDB-C@CからZFS上に RMANバックアップを取得し、 パッチ適用前後のDBを作成 システム構成（手動） ✓ 検証用DBを利用し、SPA の比較対象とするスキー マ作成し、サンプルSQL 実行 Ansible & Terraform
44. 44 お客様事例 本プロジェクトの活動報告（2/3） ⚫ 検証手順（メイン作業（1/2）） Copyright © 2023, Oracle and/or its affiliates # 作業方法 項目 作業概要 詳細 1 手動 事前準備 OCIネットワークリソースの作成 • VCN, サブネット, ゲートウェイ, セキュリティリスト等 の作成 2 ExaDB-Dの作成 • Exadataインフラストラクチャ（X8M）の作成 • VMクラスタの作成 3 DBの作成 • 現行/新の2つのデータベースを作成 4 ツール実行兼踏み台サーバの作成 • AnsibleやTerraformを実行するサーバを作成 5 ツール実行兼踏み台サーバ 実行 ツールのインストール、スクリプ ト配置 • AnsibleやTerraform、RATを実行するスクリプトなどを 配置 6 STS実行 / 実行データ コピー STS出力 (テスト用比較対象SQL 実行) • 対象となるExaDB-C@C上のDBで実行 7 DBバックアップ出力 • 対象となるExaDB-C@C上のDBで実行 8 DBバックアップ転送 • 対象となるExaDB-C@CからRAT実行用ExaDB-Dへの転 送 9 RAT検証用DBインスタ ンス複製 パッチ適用前バージョンDBの複 製 • DBバックアップより、ソースで取得したSTSとデータ含 めて複製 10 パッチ適用後バージョンDBの複 製 • DBバックアップより、ソースで取得したSTSとデータ含 めて複製
45. 45 お客様事例 本プロジェクトの活動報告（3/3） ⚫ 検証手順（メイン作業（2/2）） Copyright © 2023, Oracle and/or its affiliates # 作業方法 項目 作業概要 詳細 11 自動 SPA実行 スクリプト変数設定 • スクリプト内の変数をユーザ環境に合わせて設定 12 SQL比較スクリプト実行 • パッチ適用前/適用後のDBに対して、SPAの実行、実行結 果の比較、レポートの出力 • 日本オラクル社内検証で作成したスクリプトを流用 13 手動 RAT検証用実行環境削除 DBの削除 • RAT実行用に複製したデータベースを削除 14 ExaDB-Dの削除 • Exadataインフラストラクチャ（X8M）の削除 • VMクラスタの削除 15 ツール実行兼踏み台サーバの削除 • AnsibleやTerraformを実行するサーバを削除 16 OCIネットワークリソースの削除 • VCN, サブネット, ゲートウェイ, セキュリティリスト等 の削除
46. 46 お客様事例 （参考）テスト検証対応日数とOCI利用コスト Copyright © 2023, Oracle and/or its affiliates ⚫ テスト検証対応日数 項番 作業概要 実施日数（営業日） 1 検証環境作成 1 2 検証向けバックアップ取得/STS取得手順準備 5 3 自動化スクリプト準備 5 4 ExaDB-C@C側バックアップ取得 2 5 バージョンアップ前後のDB作成 5 6 SPA自動化実行 5 8 検証環境削除 1 合計 24 ⚫ OCI利用コスト ▸ 検証環境利用期間 ：45日間（非営業日含む） ▸ コスト合計（ExaDB-D X8M（8OCPU）+ コンピュート） ：約300万円
47. 47 Copyright © 2023, Oracle and/or its affiliates 本ウェビナーのまとめ DBにおけるアップグ レード/パッチ適用の 必要性 ◼ メリットは、下記の通り ➢ Exadata X8M以降、Database 19c以降の最新バージョンから性能アップする様々な機能 をサポート ➢ セキュリティインシデント、不具合の9割は既知の不具合が原因であり、最新のバージョン の利用、および定期的なパッチ適用により予防が可能 RATの紹介 ◼ 主にアップグレード、パッチ適用時に使用できる、高品質かつ低作業コストでテストするため のオプション（OCIでは、Enterprise Editionにてオプション無しで使用可能） ➢ SPAは、SQL単体テスト時に有用であり、システム変更前後でのSQLの実行計画やパフォー マンスの比較レポートを生成 ➢ DB Replayは、システムテスト時に有用であり、本番環境のトランザクションを記録(キャ プチャ)し、テスト環境で再現(リプレイ)、比較レポートを生成 RAT運用自動化の検 証 ◼ 弊社コンサルティングサービスでは、OCI環境におけるRAT運用時のタスクを整理し、RAT運 用自体を自動化することで、更なる工数削減（テスト期間、OCI環境利用コスト、DBAの作業 コスト）を検討および検証 お客様事例のご紹介 および弊社社内検証 の近況 ◼ Base DBだけではなく、ExaDB-C@C/ExaDB-D環境でも、下記タスクの自動化を実現 ➢ OCI環境の構築 ➢ RAT実行 ➢ SQL性能の自動分析