Oracle RAC"ハイパフォーマンス"対談《池田高志氏&小野孝太郎氏》 
後編 エキスパートが明かす、性能改善の実践的テクニック

「Oracle Real Application Clusters(RAC)を用いたシステムのパフォーマンスをいかに高めるか」――日頃RACと深く関わる富士通北陸システムズの池田高志氏と米国オラ クル 小野孝太郎氏の対談を通じて、RACのスケーラビリティ向上の軌跡、性能向上のポイントを紹介する本企画。後編では、両氏が駆使しているパフォーマンス改 善のテクニックなどを紹介しよう(編集部)。

■スループット VS. レスポンス・カーブでボトルネックをチェック

池田氏
株式会社富士通北陸システムズ
データベースソリューション事業本部
ソリューション企画部
池田高志氏

1998年に富士通北陸システムズ入社。以来、一貫してOracle Databaseに関わり、ユーザー・サポートやシステム・インテグレーションなどを担当。2008年からはOracle Databaseのアップグレード・サービスの立ち上げを主導。Oracle Master Platinum保持者で、2010年には「Platinum of the Year」を受賞している。
Club Platinum 2010 開催! ~第二部:懇親会編~
――後編では、RACを使ったシステムのパフォーマンス改善のポイントを伺っていきましょう。まず、チューニングを実施するうえで注意すべき点を教えていただけますか?

小野:私自身が、日頃パフォーマンス・チューニングと問題解決にあたる中で心掛けているのは、まず「パフォーマンス 要件を正しく理解する」ということです。レスポンスに関する要件を把握していないということは、ゴールを知らないのと同じです。これでは問題解決の枠組み 自体を設定できないので、まずは要件を正しく理解するよう努めます。

 実際にパフォーマンスを検証する際には、1件の処理にかかるレスポンスタイムと、それをどれだけ同時に実行して処理できるかとい うスループットを調査します。このときに必ず見るのが、スループットとレスポンス・カーブの関係です。これは横軸がスループット、縦軸がレスポンスタイム を示すグラフで確認するのですが、この中で縦軸のレスポンスタイムが上昇したところがボトルネックになります。パフォーマンスを改善する際には、この山を できるだけ右下に持っていくように、つまりスループットが高い状態でもレスポンスタイムが悪化しないように調整していきます。

池田:そのようなアプローチは初めてお聞きしましたね。

小野:この関係を見ながらパフォーマンスをチューニングしていくのが一番いいんですよ。

 単にレスポンスタイムが悪いということであれば、問題となっているSQLをチューニングするしかありません。しかし、スループッ トの問題ならば、どこかでスループットが頭打ちとなり、レスポンスタイムが上昇するというグラフになります。このとき、レスポンスタイムが上昇したところ に必ずボトルネックが発生しています。重要なのは、このボトルネックが何かを見つけることなのです。

110501-02.png
スループットとレスポンスの関係――レスポンスタイムが上昇したところにボトルネックがある

 では、ボトルネックとは何かというと、100%使い切られているリソースです。ボトルネックとなるリソースとしては、CPUやメ モリ、ストレージ、ネットワーク、あるいはOSやOracle Databaseの内部リソースなどが考えられます。この何らかのリソースの使用率が100%になっているため、それ以上スループットが上がらないわけで す。

 100%使われているリソースが見つかったら、次はそれをどう改善できるのかを考えます。例えば、ストレージがネックになってい る場合は、もしかしたらバッファ・キャッシュを大きくすれば改善するかもしれません。こうした「ボトルネックを見つけ、可能ならチューニングして、その内 容をベスト・プラクティスとしてドキュメント化し、提供する」ということも、私の仕事になります。RACの性能問題は大抵、これで解決してしまうのです。 実は私の業務の中で"嬉しい瞬間"は、そのボトルネックがチューニングできないことを発見したときです(笑)。その場合には製品を修正することになります が、言いかえれば、これは「製品の性能改善点を1つ見つけられた」ということになります。

――池田さんは実際のプロジェクトにおいて、パフォーマンス・チューニングをどのように実施されているのでしょうか?

池田:まず、システム・テストや性能テストのフェーズでは、「AWR(Automatic Workload Repository)レポート」などを使ってキャッシュ・ヒット率といった指標値をチェックします。さらに、1回当たりのアクセス・ブロック数などの数 値を見て、この数値が異常に大きい場合には効率が低いのではないかと疑います。大体、この辺りから深掘りしていく感じです。

 また以前に、「昨日の日中に性能が低下したけど、今日になったら収まっていた」というケースで、「過去のデータを調査してほし い」という依頼を受けたことがありました。このときは、Oracle Database 10gで「ASH(Active Session History)」が入っていたので、それを使って過去の状況を調べたりしました。

小野氏
Oracle Corporation,
Cluster and Parallel Storage Technology,
Consulting Member of Technical Staff
小野孝太郎氏

1994年に日本オラクル入社。前身となるParallel Server Optionの時代からRACと関わり続け、1996年に米国本社に移籍。データベース開発部門でRACの性能改善を担うチームに所属。世界中のRAC ユーザーから寄せられる性能問題の解決を支援している。
US開発部門でRACの性能向上を支える日本のエンジニア(前編) ユーザーの厳しい要求が改善の糧
US開発部門でRACの性能向上を支える日本のエンジニア(後編) 終わりなき改善に向け、RAC一筋
小野:ASHはまさにそうしたケースのために実装された機能です。以前なら「今度パフォーマンスが低下したら、情報を取得しておいてください」とお願いしなければなりませんでしたが、ASHが入っていれば、過去の状態をすぐに調べることができるのです。

 ただ、本来はASHで継続してOracle Databaseの稼働情報を取得しているように、CPUやOSの統計情報などに関しても、必要な情報をすべて取得し続けるべきでしょうね。ボトルネック を探し出す際、AWRレポートでOSやハードウェアの状況をすべて調べられるわけではないため、十分に原因を追及できないことがあります。その問題に対処 するために、オラクルは「OS Watcher」というツールも提供しています。

池田:OSやCPUの情報を取得するために、プロジェクトによっては、そのための仕掛けを組み込むべきかなと考えたこともあったのですが、すでにツールが用意されているんですね。

小野:そうなんです。「My Oracle Support」からOS Watcherというツールがダウンロードできるようになっています。これはOSやネットワークの情報を収集し、アーカイブするシェル・スクリプト群で、 vmstatやnetstat、iostatといったユーティリティを使ってOSのデータを収集してくれます。

池田:富士通のサーバにも、OSから情報を取得してグラフで表示するといった運用ツールが用意されていますが、Oracle Databaseの観点から必要な情報を定期的に取得してくれるツールがあるのは便利ですね。

――小野さんが前編でお話しされたように、「ボトルネックはキャッシュ・フュージョンではなく、別の部分にあるケースが大半」だとしても、AWRレポートを使いこなしてその根本原因まで突き止めるのは難しいという声もあります。そうした方へのアドバイスはありますか?

小野:AWRレポートには、開発部門のエンジニアでもパフォーマンスを分析する際に必要とする多岐にわたる情報が記 録されています。実は、この情報に基づいてチューニング方法をユーザーに提案する仕組みがあり、それが「ADDM(Automatic Database Diagnostic Monitor)」です。ユーザーは、基本的にはADDMのアドバイザ機能を使ってチューニングするのがベストでしょう。ADDMには、私のような開発部 門のパフォーマンス・エンジニアがAWRレポートを解析した結果を、アドバイスとして出力するように実装しています。バージョンが上がるごとにアドバイス 内容は豊富になってきているので、ぜひ活用してください。

■ハードウェアやOSも含めてパフォーマンスを最適化したOracle Exadata

――最後に、RACの今後の進化の方向性や、RACに期待することなどをお聞かせください。

小野:我々の今後のゴールは、「RACを意識せずに使えるようにする」ことです。すでにそのための手を打っています。

 実は今回は、近い将来問題になりそうなことを見極めるために日本に来ました。実際にお客様の環境でのパフォーマンス・データを見 て、今は問題になっていないけれど、今後負荷が上昇した際に問題になるかもしれない部分を調べています。これは、いわば短期的な改善に向けた取り組みです ね。一方、長期的な観点では、今は詳しくお話しできませんがキャッシュ・フュージョンの根底的な部分を劇的に改善するアプローチを進めています。

 加えて、ハードウェアやOSも含めたアプローチとして「Oracle Exadata」の提供を始めました。オラクルは、OSとしてSolarisを持っており、Linuxにも積極的に関与していますが、こうしたハードウェ アとOSも含めてパフォーマンスを最適化しています。例えば現状、ディスクI/Oがボトルネックになるケースが非常に多いと思いますが、Exadataで は、その問題を根底から解消するようなアーキテクチャを搭載しています。ぜひ活用していただきたいですね。

池田:先ほど小野さんもお話しされていましたが、やはり今後は、RACやキャッシュ・フュージョンを意識せずに使え るようになればという期待があります。それを今のものをベースに改善して実現するのか、それともまったく異なるアーキテクチャで実現するのかはわかりませ んが、RACなら何ノードでもそのまま使えるということになれば、非常に強力なソリューションになるでしょう。特に期待しているのはそうした部分です。

 Exadataについても、我々はその良さをお客様にお伝えするという立場から、すでにいくつかのプロジェクトで利用しています。今後は、さらに改良すべきポイントをリクエストし、オラクルと共同で改善していければと考えています。

――RACの進化の行先については、oracletech.jpでも引き続き追いかけていきたいと思います。池田さん、小野さん、本日はありがとうございました。

前の記事 <<  最初の記事へ  >> 次の記事

《Oracle RAC"ハイパフォーマンス"対談《池田高志氏&小野孝太郎氏》》シリーズをお見逃しなく!