Amazon Web Services ブログ
Oracle パフォーマンスメトリクスに基づいた Amazon RDS インスタンスを大規模で適正なサイズにする
オンプレミスのミッションクリティカルなアプリケーションを商用データベースで稼働中のエンタープライズ企業で、コスト効率の高い、マネージド型データベースサービスをお探しのお客様がいらっしゃいます。リレーショナルデータベースのワークロードを移行するプラットフォームの 1 つ、Amazon RDS をおすすめします。RDS はサイズ変更が可能な容量を提供し、時間のかかる重い非個別型管理タスクに対応します。大規模なデータベースの移行では、適切なサイズのターゲット RDS DB インスタンスを多くのデータベースに作成できる、スケーラブルかつ効果的なソリューションが必要です。
この記事では、オンプレミスの Oracle パフォーマンスメトリクスに基づいた DB インスタンス を大規模で適切なサイズにするプロセスについて説明します。Python と SQL スクリプトを使用してオンプレミスデータベースから Oracle パフォーマンスメトリクスを収集する方法、および AWS Glue と Amazon Athena を使った DB インスタンスサイズのデータ分析と推奨事項を得る方法を解説します。このソリューションは、1 つのデータベースから多数のデータベースまでの DB インスタンスのサイズ調整に有効です。
概要
オンプレミスの Oracle ワークロードの検出を目的として、1 時間ごとの I/O、CPU、メモリ使用量の統計について Oracle 自動ワークロードリポジトリ (AWR) をクエリする SQL スクリプトが開発されました。Python スクリプトを検出するデータベースのリストを含む入力ファイルから読み込んで、各データベースをループ処理して SQL スクリプトを実行します。データベースごとに .csv 出力ファイルが生成されます。
目標は、少なくとも 1 か月のパフォーマンスメトリクスを収集し、DB インスタンスのサイズをより正確に推定することです。AWR の保存期間が 1 か月未満に設定されている場合、複数回スクリプトを実行できます。スクリプトはすべて Amazon EC2 Linux インスタンスにインストールされ、ここを中心としてここから実行されます。Python スクリプトが SQL*Plus セッションを開始し、EC2 インスタンスからリモートで Oracle データベースに接続します。
データベースワークロード出力ファイルの各行は、1 つの Oracle AWR スナップショットからのパフォーマンスメトリクスを表しています。出力で収集する主なパフォーマンスメトリクスは、次のとおりです。
- 1 時間あたりの最大 HOST CPU 使用率
- 1 時間あたりの Oracle SGA および PGA の使用率
- 1 時間あたりの平均物理読み込み量および書き込み量 (メガビット/秒)
ワークロード出力ファイルは Amazon S3 バケットにアップロードされます。使いやすいサーバーレスの対話型クエリサービスである Athena を使用して、S3 バケット内のワークロードデータを分析します。スキーマを定義した後、標準 SQL を使用して S3 の大規模データセットを Athena ですばやく分析します。
Athena はデフォルトで AWS Glue と統合している、完全マネージド型の抽出、変換、ロード (ETL) を行うサービスで、S3 のワークロードデータをクロールし、スキーマを検出するために使用します。クローラが AWS Glueで作成され、S3 バケットのデータにアクセスし、メタデータを抽出して、AWS Glue データカタログでテーブル定義を作成します。オンプレミスデータベースのワークロードを DB インスタンス容量と比較するには、ルックアップ用に .csv ファイルを同じ S3 バケットにアップロードします。.csv ファイルにはターゲット DB インスタンスタイプ、vCPU、メモリ、最大帯域幅設定が含まれています。詳細については、Amazon RDS ハードウェアの仕様をご参照ください。
Oracle パフォーマンスメトリクスに基づいて DB インスタンスを適切なサイズにするのに使用するロジックは、Athena のビューでコード化されています。
- CPU 使用率 – 90 パーセンタイルでの 1 時間ごとの最大 HOST CPU 使用率を CPU ワークロードの代表として使用します。この値にオンプレミスで構成している CPU の数を掛けて、推定 CPU 使用率を決定します。追加の 20% がヘッドルームとしてこの数に追加されます。同じホストで複数のデータベースインスタンスが実行されている場合は、CPU 使用率がデータベースインスタンス間で均等に分散されていると想定します。Oracle RAC の場合は、すべての RAC ノードの推定 CPU 使用率の合計を使用します。ヘッドルームの割合は、CPU クロック速度の違いを考慮して調整します。詳細については、EC2 インスタンス CPU の仕様をご参照ください。
- メモリ使用率 – Oracle SGA と PGA の使用率の最大合計を、Oracle 用推定メモリ使用率として使用します。OS に 20% を追加して、目標メモリサイズの要件を決定します。Oracle RAC の場合は、すべての RAC ノードの推定メモリ使用率の合計を使用します。
- 帯域幅使用率 – 90 パーセンタイルでの 1 時間あたりの平均物理読み込みおよび書き込み量の合計 (メガビット/秒) を代表の帯域幅使用率として使用します。追加の 20% がヘッドルームとしてこの数に追加されます。Oracle RAC の場合は、すべての RAC ノードの推定帯域幅使用率の合計を使用します。
- 最も近い一致 – 前出の 3 つの推定値 (CPU 使用率、メモリ使用率、帯域幅使用率) を DB インスタンスの CPU、メモリ、帯域幅の容量と比較します。CPU、メモリ、帯域幅の順に最も近いものを見つけます。
- 代表データポイント – 代表 CPU のデータポイントを選択するロジックとスループットワークロードは、ビュー定義を変更することで簡単に調整できます。ご自身のワークロード分布に基づいて、上位 N 位以上のパーセンタイルを使用してください。
Athena のビューをクエリして、インスタンスサイジングレポートを作成します。レポートは .csv ファイルとして保存でき、推奨される DB インスタンスタイプを各データベースに表示します。レポートにはデータベースサイズ、オンプレミスの CPU、メモリ、帯域幅の使用率、ターゲット DB インスタンスの CPU、メモリ、帯域幅の容量も含まれます。
次の図は、このブログで取り上げるソリューションのプロセスを示しています。
こちらがプロセスのしくみです。
- EC2 インスタンスで実行している Python と SQL スクリプトを使用して、多数のオンプレミス Oracle データベースからデータベースパフォーマンスワークロードを収集します。
- ワークロードの出力 .csv ファイルと Amazon RDS インスタンス設定のルックアップ .csv ファイルを EC2 インスタンスから S3 バケットにアップロードします。
- S3 でワークロードパフォーマンスデータと Amazon RDS インスタンスルックアップデータをクロールして分析し、AWS Glue を使用してテーブルメタデータを作成します。
- Athena でビューを作成し、適切なターゲット DB インスタンスサイズを決定します。そのビューを実行してインスタンスサイジングレポートを作成します。
- レポートをダウンロードします。
ソリューション
このソリューションを実装するためのコードと AWS CloudFormation テンプレートは、amazon-rds-sizing-sample GitHub リポジトリにあります。
AWS CloudFormation テンプレートは以下のリソースをプロビジョニングします。
- instancesizing_CFN1.yaml
- Python 2.7 と AWS CLI を搭載した Amazon Linux AMI を使用する EC2 Linux インスタンス。Oracle データベースのパフォーマンスメトリクス収集スクリプトを実行するためにプレインストール済み
- Oracle データベースワークロードの出力ファイルを格納するための S3 バケット
- 作成した S3 バケットへのフルアクセス権を持つインスタンスに添付してある IAM ロール。テンプレートはプロビジョニングしたインスタンスに自動的に次のタスクをデプロイします。
- Python 拡張モジュール cx_Oracle をインストールします。
- Oracle Instant Client 18.3 Basis と SQL*Plus をインストールします。
- /home/ec2-user/.bash_profile の Oracle 環境変数を構成します。
- サンプルデータベースの TNS エントリを使用して、tnsnames.ora を作成します。
- instancesizing_CFN2.yaml
- AWS Glue 用 IAM ロール
- S3 バケットにアップロードしたパフォーマンスメトリクスデータをクロールする AWS Glue クローラ
- Amazon RDS インスタンスタイプのルックアップ .csv ファイルをクロールする AWS Glue クローラ
- instancesizing_CFN3.yaml
- インスタンスサイジングレポートを作成するためのビュー定義用 Athena の名前付きクエリ
前提条件
このソリューションを参照しながら実行するには、以下のリソースが必要です。
- Amazon EC2、Athena、AWS Glue、Amazon S3 のリソースにアクセスするためのアクセス許可を持つ AWS アカウント。
- 仮想プライベートクラウド (VPC) の EC2 Linux インスタンス。このインスタンスはオンプレミスの Oracle データベースに接続できます。
- Oracle Diagnostics Pack のライセンス。この記事で提供している Oracle データベースのパフォーマンスメトリクス収集スクリプトは、Oracle カタログ内の dba_hist* テーブルをクエリしますが、それにはカタログへのアクセス許可が必要です。
- Oracle データベースのデータ収集スクリプトを操作するための、Oracle 11g Enterprise Edition または 12c Enterprise Edition (Oracle Database のマルチテナントを除く)。
- 以下の AWS CloudFormation テンプレートと Oracle パフォーマンスメトリクス収集スクリプトは、amazon-rds-sizing-sample からダウンロードできます。
- instancesizing_CFN1.yaml
- instancesizing_CFN2.yaml
- instancesizing_CFN3.yaml
- instancesizingtools.zip
ステップ 1: EC2 インスタンスと S3 バケットをプロビジョニングするための AWS CloudFormation スタックを作成する
最初の AWS CloudFormation テンプレートは EC2 インスタンスと S3 バケットを作成します。
AWS CloudFormation コンソールで、[Create stack] をクリックします。Select Template セクション (Specify template 下にある) で、[Upload a template file] をクリックします。[Choose File] を選択して、instancesizing_CFN1.yaml ファイルをアップロードし、[Next] をクリックします。詳細については、ステップ 3: スタックの作成 をご参照ください。
[Specify Details] 画面で、以下のフィールドに値を入力します。
- Stack name – スタックの名前を入力します。
- InstanceType – インスタンスタイプを入力します。デフォルトは m4.large です。
- KeyName – キーペアを選択します。
- LinuxAMIidName – Amazon Linux AMI (HVM) の AMI ID、SSD ボリュームタイプを入力します。デフォルトのイメージには 必要とする Python SDK と AWS CLI が含まれています。
- Name – EC2 インスタンス名タグの値を入力します。デフォルトは WL です。
- S3Bucketname – データベースワークロードデータを保持するための S3 バケット名を入力します。
- SecurityGroups – 作成済みのセキュリティグループを選択します。
- Subnet – EC2 インスタンスを作成するサブネット ID を入力します。
- VPC – EC2 インスタンスを作成する VPC を選択します。
[Create] ページで、IAM リソースの作成を確認してから、[Create] をクリックします。スタック作成の進行状況をモニタリングするには、CloudFormation スタックの [Events] タブを確認してください。CloudFormation スタックが完了したら、リソースが作成されたことを確認します。
ステップ 2: オンプレミスの Oracle パフォーマンスメトリクスを収集する
スタックの [Resources] タブで「AWS:EC2:Instance」と入力し、物理 ID を選択します。
EC2 コンソールで [Connect] をクリックします。手順に従って、ec2-user としてこの EC2 インスタンスに SSH で接続します。
amazon-rds-sizing-sample GitHub リポジトリからダウンロードした zip ファイル instancesizingtools.zip を検索し、EC2 インスタンスの /home/ec2-user ディレクトリにアップロードします。ファイルを解凍するには、次のコマンドを実行します。
unzip instancesizingtools.zip
/instancesizingtools ディレクトリは、パフォーマンスメトリクス収集スクリプトを含む EC2 インスタンスに作成されます。このディレクトリの構造は次のとおりです。
- instancesizingtools: ルートディレクトリ
- output: スクリプト出力を含むディレクトリ。
- scripts: パフォーマンスメトリクス収集スクリプトを含むディレクトリ。
- logfile: スクリプトログファイルを含むディレクトリ。
- dblist.txt: 検出する Oracle データベースを含むファイル。
- run_aws_tool_awr.py: dblist.txt にリストされているデータベース内の awrsqllist.txt で定義されている SQL を実行するための Python スクリプト。
- oracle_performance.sql: データベースパフォーマンスメトリクスを収集するための SQL スクリプト
- awrsqllist.txt: Python スクリプトが実行する SQL ファイルのリストを含むファイル。このファイルのコンテンツは oracle_performance.sql です。
- instancelookup:
- Rds_instance_type_csv: ターゲット DB インスタンスタイプ、vCPU、メモリ、最大帯域幅設定を含むファイル。このサンプルファイルには M4 と R4 インスタンスファミリーが含まれています。必要があれば、もっと多くのファミリータイプを追加できます。
EC2 インスタンスで次のコマンドを使用して、以下を確認します。
- AWS CLI と Python 2.7 のインストール
- Oracle 環境変数の設定
- ディレクトリ instancesizingtools の構造
オンプレミスの Oracle データベースに、「セッションの作成」および「select_catalog_role」の権限を持つ Oracle ユーザーアカウントを作成します。
EC2 インスタンスでオンプレミスの Oracle データベースの接続情報を使用し、$ORACLE_HOME/network/admin/tnsnames.ora にエントリを作成します。参考のために、サンプルの TNS エントリを tnsnames.ora に追加しておきます。
次の形式を使用して、分析対象のすべてのデータベースのファイル /home/ec2-user/instancesizingtools/scripts/dblist.txt を Oracle データベースのユーザー名、パスワード、tnsnames エントリで更新します。各行が 1 つのデータベースを表します。AWS CloudFormation テンプレートを使って Oracle Instant Client 18.3 をインストールします。Oracle Database 10g に接続するには、Oracle Instant Client 12.1.0.2 を手動でインストールします。
#username, password, tns_entry
awsread,read123,orcl11
データベースパフォーマンスメトリクスを収集するには、EC2 インスタンスで 次の Python スクリプトを実行します。
cd /home/ec2-user/instancesizingtools/scripts
python run_aws_tool_awr.py dblist.txt > logfile/run_aws_tool_awr.log 2>&1
ディレクトリ logfile に作成したログファイルとディレクトリ output に作成した出力を確認します。必要に応じてエラーを訂正し、スクリプトを再実行します。
ステップ 3: パフォーマンスメトリクスの出力と Amazon RDS インスタンスタイプの設定 .csv ファイルを S3 バケットにアップロードする
新規および更新したパフォーマンスメトリクスの出力ファイルを EC2 インスタンスの出力ディレクトリから S3 バケットに再帰的にコピーするには、EC2 インスタンスで次の s3 sync コマンドを実行します。「S3bucketname」をステップ 1 でプロビジョニングしたバケット名に置き換えます。
cd /home/ec2-user/instancesizingtools/output
aws s3 sync . s3://<S3bucketname>/performancedata/ --exclude="*" --include="*.csv" --sse
S3 cp コマンドは、ローカルファイル rds_instance_type.csv を S3 バケットにコピーするために使用します。「S3bucketname」をステップ 1 でプロビジョニングしたバケット名に置き換えます。
cd /home/ec2-user/instancesizingtools/instancelookup
aws s3 cp rds_instance_type.csv s3://<S3bucketname>/instancelookup/ --sse
上記のコマンドは S3 バケットにそれぞれ 2 つのフォルダを作成します。
- instancelookup
- performancedata
次のスクリーンショットは、データベースワークロード出力ファイルが作成された後にアップロードされた S3 バケットフォルダ s3://<S3bucketname>/performancedata
と s3://<S3bucketname>/instancelookup/
のコンテンツのサンプルです。AWS Glue クローラがこれら 2 つのフォルダのデータをクロールします。
ステップ 4: AWS CloudFormation Stack を作成し、2 つの AWS Glue クローラをプロビジョニングしてからクローラを実行する
2 つ目の AWS CloudFormation テンプレートは、2 つの AWS Glue クローラを作成するものです。
nstancesizing_CFN2.yaml ファイルに対して、ステップ 1 で説明したスタック作成のプロセスを繰り返します。[Specify Details] のページで、以下の値を入力します。
- スタック名
- S3Targetbucketname (ステップ 1 でプロビジョニングした S3 バケット名を入力します)
データベース「dbinstancesize」が AWS Glue データカタログに作成されます。2 つの AWS Glue クローラ「dbinstancesizecrawler1」と「dbinstancesizecrawler2」が作成されます。クローラはオンデマンドで実行するようになっています。必要に応じて、時間を基準にしたスケジュールをクローラに定義できます。
AWS Glue コンソールで、[Crawlers] をクリックし、クローラ dbinstancesizecrawler1 を選択し、[Run crawler] をクリックします。同じことを繰り返して、クローラ dbinstancesizecrawler2 を開始します。
これら 2 つのクローラは、Amazon S3 フォルダ /performancedata および /instancelookup のデータをそれぞれクロールします。各クローラが AWS Glue データベース dbinstancesize に、1 つの AWS Glue メタデータテーブルを作成します。テーブル名は Amazon S3 フォルダ名と同じものです。
クローラの実行が完了したら、Athena コンソールでテーブル定義を確認します。次のスクリーンショットは、テーブルスキーマ定義を示しています。
ステップ 5: AWS CloudFormation Stack を作成し、query という名前の Amazon Athena をプロビジョニングしてから Athena のビューを作成する
3 つ目の AWS CloudFormation テンプレートは、query という名前の Amazon Athena を作成します。
cstancesizing_CFN3.yaml ファイルに対して、ステップ 1 で説明したスタック作成のプロセスを繰り返します。
Athena コンソールの [Saved Queries] タブで、[v_instance_sizing] をクリックします。
名前付きクエリはクエリエディタウィンドウにポートされます。ビュー v_instance_sizing を作成するには、[Run query] をクリックします。
ステップ 6: インスタンスサイジングレポートを作成し、ダウンロードする
Athena コンソールの [Query Editor] タブで、新しいクエリタブを開き、次のコマンドを使ってビュー v_intance_sizing をクエリします。
select * from v_instance_sizing
各ソース Oracle データベースで、結果は次のようになります。
- 推奨ターゲットインスタンスタイプ
- 現在のデータベースサイズ
- ソースオンプレミスの CPU、メモリ、帯域幅の使用率
- ターゲット DB インスタンスの CPU、メモリ、帯域幅容量の設定
[Download] をクリックします。次のスクリーンショットに示すように、結果は CSV 形式です。
まとめ
この記事では、Oracle のパフォーマンスメトリクスに基づいて RDS DB インスタンスを適切なサイズにするためのソリューションをご紹介しました。このソリューションは、データベース移行のワークロードに合わせて、多数のデータベースを分析し、AWS のインフラストラクチャのベースラインを確立するために利用できます。
著者について
Michelle Deng は、アマゾン ウェブ サービスのシニアクラウドデータベースアーキテクトです。AWSのお客様と協力して、データベースの移行とビッグデータプロジェクトに関するガイダンスや技術支援を行っています。
Udayasimha Theepireddy (Uday) は 2017 年 11 月よりアマゾン ウェブ サービスのシニアクラウドデータベースアーキテクトとして活躍しています。Amazon の社内顧客と協力して、いくつかのサービスをオンプレミスの Oracle から Aurora や RDS PostgreSQL、RDS MySQL、Redshift データベースに移行する作業を担当しています。