Oracleアカウント

シンジ＆アヤノの実践データベース性能テストの極意： Oracle Real Application Testingを使ってみよう

～オラクルコンサルタントが語る～

第1回　Real Application Testingの概要とポイント

1.はじめに

Real Application Testingの紹介に入る前にまず、「なぜシステムパフォーマンステストは重要なのか。」そして「なぜ、（Real Application Testingのような）テストソリューションが必要なのか。」をお伝えしたいと思います。

少しビジネス視点のお話になりますが、実際の多くのビジネス現場では、高パフォーマンス、かつ高品質でSLAの高い要件に対応できるシステムが求められています。それがミッションクリティカルなシステムであれば尚更です。その状況下において、システムパフォーマンスの劣化が発生した場合には、それがユーザーからの苦情・クレームや、ユーザーのシステム利用忌避につながり、会社のブランドイメージの低下やユーザー数の減少など、経営にも影響を及ぼす問題まで発展する可能性を秘めています。

また、本番カットオーバー前であっても、システム開発・移行案件における性能問題のインパクトは、問題発覚が後行程なればなるほど、要件定義（非機能要件）の見直し等につながり、大きな修正コストをともなうことになります。

そのため、システムパフォーマンステストはミッションクリティカルなシステムでは必須のテストと言えます。しかし実際のプロジェクトにおいては、昨今では特に企業間の競争激化により、システムの開発期間がますます短くなってきており、それにともないテストに使用できる期間も短くなってきています。

その上、実プロジェクトでは当初の開発スケジュールどおり進捗せず要件定義や設計のフェーズで遅れが生じることも多く、かといってシステムカットオーバーの日付を後ろ倒しにすることもできず、結果としてやむなくテストフェーズが短縮される状況をよく見かけます。

そんな中でテストフェーズでは、テストツールなどを用いてテストの自動化・効率化が図られることが多いと思います。しかし実際は、自動化できる項目の見極めを行う必要があったり、適切なテスト計画・テスト項目策定を行うスキルや、テストツールを扱うスキルが重要だったりと、高い品質のテストを行うためには、単純に「ツールで自動化」すればよいというものではありません。

そこで、短期間でかつ高品質なテストを実現するためにはどうすればよいのでしょうか。以降でOracleのテストソリューションを紹介しながら、説明していきたいと思います。

Oracleのテストソリューションを、おおまかに分けると以下の図のようになります。目的によって使い分けることができ、それぞれが補完しあう機能です。

アプリケーションそのものをユーザーが実際に操作をする代わりに、自動的にアプリケーションを動作させ、機能（回帰）テストや性能テストを実施するためのテストツールがApplication Testing Suite(ATS) です。アプリケーションからAPサーバ・DBサーバを通して一続きにテストを行うもので、アプリケーションの作成・変更部分に応じて新しいテストシナリオを柔軟に作れるのが特徴です。Oracleの製品以外では、JMeterやHP LoadRunnerが同じ系統のツールに分類されるかと思います。

次に、アプリケーションを直接動作させるのではなく、事前にユーザーリクエスト(HTTP)をキャプチャーしておいたものAPサーバ上でリプレイすることで、APサーバに対して、キャプチャー時の負荷を再現できるのが、Application Replayです。本番環境の実ワークロードをキャプチャーしてリプレイすることで、APサーバの負荷テストを高品質で実現するために使えるツールです。

最後に、本連載で取り上げる、Real Application Testing(RAT)ですが、これは、Oracle Database 11gからのデータベースの新機能として実装されているもので、データベースを中心としたシステムの変更リスクを削減するための高品質テストオプションです。Real Application Testingは、Enterprise Edition でオプションのライセンスを購入することで使用できるようになります。

Real Application Testingは、SQL Performance Analyzer(SPA)とDatabase Replay(DB Replay)という２つの機能で構成されています。

SQL Performance Analyzer(SPA)は、システム変更前と変更後でのSQL単位での比較を実施しレポートを生成します。多数のSQLを効率よくテストし、実行計画や性能の変化を確認することができます。

Database Replayは、本番環境などの実際のワークロードを記録し、テスト環境などで再現し比較レポートを生成します。こちらはSQL単位ではなく、データベースの全体性能に与える影響を包括的に評価することが可能となります。

SQL Performance Analyzer(SPA)とDatabase Replay(DB Replay)は、それぞれ補完しあう機能です。

2.SQL Performance Analyzer

まずはじめに、コンサルタントとして考えるSQL Performance Analyzerの必要性と、その機能概要について、説明したいと思います。

システムパフォーマンステストの重要性については、先ほどお話しましたが、アプリケーションのパフォーマンス劣化につながる主な要因のひとつが、SQLのパフォーマンス劣化です。データ件数の増加により純粋にSQLの処理件数が増えたことが原因であるケースもあれば、データバリエーションの変動や、パッチ適用や初期化パラメータ変更によって、SQLの実行計画が変化したことが原因であるケースもあります。そのため、パフォーマンス劣化が予測されるSQLに対して、事前に検証やチューニングが実施できれば、システムパフォーマンス問題を引き起こす主な要因のひとつをつぶすことができます。

しかし、だからといって、アプリケーションが使用するSQLの全種類について網羅的に性能テストを実施することは、コスト面で困難です。それがシステムの新規開発案件ではなく、基本的にアプリの修正が入らないサーバのEOL(End of Life)のためのサーバリプレースおよびDatabaseアップグレード案件となれば尚更、コストとして十分なテスト工数が確保されることはまれでしょう。そんなときに活躍するのが、このSQL Performance Analyzer です。

＜アヤノのここがワンポイント＞

本番環境のSQLワークロードをテスト環境で再現し、SQL単位のパフォーマンスが比較可能

SPAを利用することでDatabaseのレイヤで本番環境から取得したSQLのワークロードをテスト環境で再現し、システム変更の前後などで実行計画を比較することができます。あらかじめ実行計画が変動するものを特定できるため、性能劣化が予測されるSQLに関しては事前に対策を打つことができ、運用後のトラブルを軽減させることが可能です。

劣化が予測されるSQLのチューニングが容易に実施可能

さらに、パフォーマンスを比較するだけではなく、SQLチューニングアドバイザやSQL計画管理を併用することで劣化してしまったSQLのチューニングも実施することができます。Enterprise Managerを利用することで自動的にグラフィカルなレポーティングが出力できるため、チューニング後の確認も画面上から実施することが可能です。

以下にSQL Performance Analyzerの基本概念の図を掲載します。

1. まず、本番環境でSQLワークロードを取得しSQL Tuning Set (STS)に格納します。SQLワークロード情報は、一定時間（指定可能）ごとにカーソルキャッシュから情報を収集して格納することや、AWRスナップショット（過去情報）から取得することもできます。STSに格納するSQLは一定条件でフィルタすることも可能です。STSに含まれるデータは、「SQLテキスト」「バインド変数」「実行計画」「統計情報」などです。（ただし、STSは10gR2から使用できる機能です。9i /10R1では、SQLトレースで代替する方法があります。）

2. 次にそのSTSを本番環境からテスト環境にExport/Importで移動させます。その後、システム変更の前にSQLを実行し、変更前のベースラインを取得します。

3. 次に、システム変更を実施し、その後、同様にSQLを実行します。 ※ここで想定している「システム変更」はたとえば以下のようなものです。

DBアップグレード
パッチ適用
オプティマイザ統計情報の更新
スキーマの変更（インデックスの追加・変更など）
初期化パラメータの変更
CPU・メモリの増設やディスク装置の変更

4. SQL Performance Analyzerでシステム変更後のSQL実行まで完了すると、そのまま比較レポートが生成され、STS全体とSQL単位について、それぞれのパフォーマンス情報が簡単に比較できます

3.Database Replay

次に、今度はDatabase Replayの必要性と機能概要について説明したいと思います。

SQL Performance AnalyzerもDatabase Replayも、システムのパフォーマンス問題が企業に甚大な影響を与えることを防止するための性能テスト機能であることに変わりはありませんが、SQL Performance Analyzerが、個別のSQLに対してパフォーマンス検証を行う機能であるのに対して、Database Replayは、データベースシステム全体の影響を検証する機能です。

個々のSQLレスポンスで見ると問題のないように思えても、実際に本番環境のあらゆる処理の入り混じるワークロードの中で実行されたときに、システム全体に悪影響を及ぼす問題が発生する場合があります。たとえば、ラッチの競合やCPUの高騰、バッファ・キャッシュからのエージアウトによるI/Oの多発、さらにRACであれば、過度なキャッシュ・フュージョンなどです。

一般的に、性能テスト／負荷テストを実施する際には、中小のシステム規模であれば、複数のPC端末を並べて、複数人で「いっせーのーで」で同時にアプリケーションの操作をすることで、負荷をかけて検証する場合もありますが、ある程度の大規模システムであれば、たいていの場合は、負荷かけツールを使用して自動化してテストします。前にも記述しましたが、Oracle製品では、Application Testing Suite(ATS)がそれに該当します。

では、それらの負荷かけツールと比べて、Database Replayだと何が優れているのか。大きく分けて２つあると考えています。１つ目は、「本番の実際のワークロードを取得して、それを再現することができる」こと、２つ目は、「AP担当者がいなくても、DB担当者だけで簡単にテストが繰り返し実施できる」ことです。

＜シンジのここが勘所＞

本番環境の負荷を取得し、そのままテスト環境で再現が可能

負荷かけツールを使用する場合、本番相当のワークロードを擬似的に作成することになります。その際には広範囲に及ぶテストシナリオの作成が必要になり、時間とコストがかかります。また「テストシナリオが不十分＝テスト品質が不十分」となり、テストシナリオ作成者のスキルに依存してしまいます。さらに、担当者がそのツールに精通している必要もあります。

Database Replayを使用する場合、本番のワークロードをそのままキャプチャーして使用できるため、テストシナリオ作成などは不要で、リプレイするだけで本番の負荷が再現できます。

DB担当者(DBA)だけで、簡単に繰り返しのテストが可能

負荷かけツールを使用する場合、そのツールに精通している必要があるのと同時に、テスト対象のアプリケーションにも精通している必要があります。そのため通常、実施する対象者は必然的にアプリケーション担当者になります。しかしアプリケーションがデータベース全体に与える影響を検証するためには、DB担当者のデータベース性能結果分析スキルが必要となり、アプリケーション担当者だけでは、負荷テストの実施～検証までを完結することができません。

Database Replayを使用する場合、データベース・レイヤーに限定した負荷かけとなるため、DB担当者により、一度本番のワークロードをキャプチャーしてしまうことで、あとは同じくDB担当者により繰り返しリプレイすることができるため、アプリケーション担当者が不在でも（ＡＰサーバが使用できない状況でも）、負荷テストを進めることが可能です。

以下にDatabase Replayの基本概念の図を掲載します。

1. まず、本番環境でワークロードをキャプチャーします。キャプチャーした情報は、キャプチャーファイルとしてファイルに格納されます。

2. 次に、取得したキャプチャーファイルをテスト環境にコピーします。テスト環境では、データの状態を本番環境でのキャプチャー開始時点の内容に合わせておく必要があります。コピーしたキャプチャーファイルを、テスト環境側でリプレイ可能なフォーマットに変換します。（ここでは変換されたファイルを便宜的にリプレイ・ファイルと呼びます。）リプレイ・ファイルは何度でも実行可能です。RAC環境でキャプチャーした場合は、全インスタンスで生成されたキャプチャーファイルを一箇所に集め、リプレイ・ファイルに変換します。

3. リプレイ・クライアントがリプレイ・ファイルを読み込んで、リクエストをDBサーバに送信することで、ワークロードがリプレイされます。クライアントはスレッドで実行されるため、１プロセスで複数並列度を再現可能ですが、負荷が大きい場合には必要に応じてクライアントを複数起動します。（１プロセス最大５０セッション）

4. リプレイが完了すると、各種レポートが生成され、さまざまな観点でデータベース全体としてのパフォーマンス情報や負荷情報が比較して分析することができます。

4.まとめ

今回はまずReal Application Testingの概要とポイントについて説明しました。

SQL Performance Analyzer は、個々のSQL単体レベルで分析・レポートし、Database Replayは、データベースシステム全体レベルで分析・レポートします。そのためオラクルでは、まずSQL Performance Analyzerで、個々の性能の悪いSQLを分析・チューニングしてSQL単体レベルの問題を解決させた後に、Database Replay で、データベースシステム全体の分析・チューニングを実施する、というフローをベスト・プラクティスとしています。