AS/400展望

iSeriesパフォーマンス管理の第一歩

ポール・コンテ著

AS/400およびiSeriesに関する私のコンサルティング経験では、パフォーマンスが重要でないと考えている企業はほとんどありません。パフォーマンスが良ければレスポンスタイムやスループットが向上するのでエンドユーザーは喜びます。パフォーマンスが良ければハードウェアコストを削減でき（エンドユーザーも満足するので）、管理者も喜びます。

しかし、パフォーマンスの向上を望んでいるにもかかわらず、一貫したパフォーマンス管理プロセスを確立するのに苦労しているIT組織が多いようです。私が関わる組織のほとんどが経験と勘に頼ったプログラムの最適化や、その場しのぎのシステムチューニングを行っているというのが現実です。多くの場合、システムやアプリケーションがどの程度のパフォーマンスを挙げているのか、最大のパフォーマンス向上を得るにはどのどこをチューニングしたり最適化したりすれば良いのか、などについて全体像を正しく把握している人が組織中に誰もいないのです。

本当の意味でのパフォーマンス管理では、サービスレベルを定義し、定量的なデータを使用して、どのサービスレベルが達成されていないのかを判断できなければなりません。パフォーマンス関連の作業にIT部門スタッフや予算を効率的に割り当てられるか否かは、システムとアプリケーションのパフォーマンスを定量的に理解しているかどうかに懸かっています。スタッフと予算の効率的な割り当てには、限られたシステムリソースをどのアプリケーションが消費していて、それらのリソースをアプリケーションがどのように消費しているのかを把握している必要があります。これらの情報なくしては、スタッフを無駄に配置し、不必要なハードウェアアップグレードを購入し、それでもなお望んでいるパフォーマンスレベルを達成できないという結果になってしまいます。システムレベルのパフォーマンスを理解することはシステムキャパシティの増大を適切に計画するためにも必要不可欠です。

管理者およびスタッフはハードウェアのアップグレード、システムチューニング、アプリケーションの修正に対する予算とスタッフの作業時間の割り当てを直感だけに頼っていてはいけません。定量的なデータがないと、パフォーマンスの専門家でさえも、大規模で複雑なシステムのパフォーマンスを向上させるための最も効率的な方法を見つけるのは難しいものです。実際、総じてパフォーマンスの専門家はパフォーマンスを測定することがパフォーマンスを向上させる能力に不可欠であると認めています。

準備
本記事で説明するパフォーマンス管理プロセスと同様のプロセスを設定すると、どこにパフォーマンス上の問題があるか、どのチューニング、どの最適化作業にフォーカスすればよいかを組織は判別できるようになります。さらに具体的に言うと、効率的なパフォーマンス管理を行うことにより以下のメリットが得られます。

＊サービスレベルの予測可能性や許容性が向上し、iSeriesをより効率的に使用してビジネス（たとえばカスタマサービスの質の向上）を遂行できる。
＊リソースがどのように消費されているかを認識し、最適化作業を行うことによってハードウェア要件を低減することができるので、最大のパフォーマンス向上を得ることができる。
＊現行のハードウェア要件を低減し、購入／リースの意思決定計画を今までより効率的に行うことによりコスト効果のより高いキャパシティの増大を図れる。

パフォーマンス管理の手法は数多くあります。しかし効果的な管理をしたいのであれば、しっかりとした計画を立てる必要があります。その計画には組織が以下の課題をどう達成するのかが盛り込まれていなければなりません。

＊システムの成長とキャパシティの追跡と計画
＊それぞれのビジネスユニットに対するサービスレベル（応答時間やスループットなど）の設定と達成
＊システムおよびアプリケーションの効率向上によるサービスの向上およびハードウェア要件の低減

私が開発した方法はパフォーマンス管理プロセスのさまざまな局面を3つの層に整理したもので、それぞれがおおよそ上記の3つの課題に対応しています。

＊第1層: システムの健全性とキャパシティプランニング
＊第2層: サービスレベルとリソースの利用率
＊第3層: アプリケーションのパフォーマンス診断

ゼロから始めるのであれば第1層と第2層に対する計画を作成してまずそれを運用することをお勧めします。この2つの層では短期と中期のキャパシティプランニング用に必要不可欠な情報を提供し、最適化の作業をどこにフォーカスするかを見極めます。また初めのうちは、短期のアプリケーション最適化プロジェクトの一部として第3層のコンポーネント（後述）もいくつか調べてみるのも良いでしょう。第1層と第2層が出来上がったら第3層の細部をつめて実装します。

図1にはパフォーマンス管理計画を始めるのに必要なプロジェクトの手順を一覧にしてあります。各層の目的および各層が生成する情報の詳細について以下に説明します。各層に対して、パフォーマンスデータを収集し、レポートを生成するためのスタッフが踏む手続きを計画の中に定義しておかなければなりません。この手続きはiSeriesの組み込み機能やIBMや他社のユーティリティ、ローカルで開発したプログラムやクエリーの使い方を説明したものでなければなりません。各層に対して、この手続きを遂行する責任を持っているのは組織中の誰で、生成された情報に対処するのは誰であるのかも計画の中で明確にしていなければなりません。

第1層 ― システムの健全性とキャパシティプランニング
この層では、モニタリング対象システムのパフォーマンス全般に関する現在の情報を提供します。この層に関する典型的な質問には以下のようなものがあります。平均時およびピーク時にどれくらいのキャパシティが使用されているか。現在のシステム構成において、平均時およびピーク時の使用は「最低限」および「最大限」しきい値レベルの標準と比べてどうか。ピーク使用期間はいつ（時間、曜日、日）か。ユーザーに提供される全体的な平均サービスレベルはどれくらいか。（サービスレベルとは対話型トランザクションの応答時間、対話型およびバッチトランザクションのスループット、バッチジョブの経過時間やその他の測定値を指します。）平均時およびピーク時のサービスレベルは昨年同期と比べてどうか。図2はより広範囲な質問の一覧です。

これらの質問に答えるには、記録する具体的な測定項目、測定のサンプリング間隔、データの分類方法（ジョブタイプ別など）、のちに履歴比較やトレンド分析に使用する時系列的ポイントなどを把握しておかなければなりません。

第1層については、平均ジョブ経過時間、CPU利用率、ディスクアクティビティ、平均応答時間、ロック／占有競合などといった基本的なシステム測定項目を収集します（図3）。こうした測定項目の大部分は、サンプリング間隔を15分（一定）に設定したiSeriesに組み込みのCollection Services機能を使用して収集します。次に分析用に、データをジョブタイプ（たとえばシステム、対話型、バッチ）、接続タイプ（たとえば5250、PC-SNA）、ジョブ優先度などといった属性別に分類します。多くのパフォーマンス測定値に対して時間、曜日、日、月などの時間間隔別にデータを要約します。

図4 は生成されるレポートタイプ例の一覧です。この図にあるレポートの多くはIBMのPerformance Management eServer iSeries（PM/400e）サービスから入手可能で、お客様のシステムからCollection Servicesデータを受け取ってレポートをWeb上に提供するものです。もちろん、お客様が「これは追跡すべき」という判断に従って本記事のリストにレポートを追加したりリストからレポートを削除したりしていただいても構いません。本記事に掲載したのはパフォーマンス管理計画の1つのパターンであり、特定のお客様にとって必ずしも最適なステップとは限りません。

さまざまな要約レポートには、定義した制限に基づいて「許容範囲」、「最低限」、「過剰」などの範囲に入ったサンプルの平均、ピーク、（場合によっては）比率が示されています。選定されたレポートを毎週または毎月レビューするためのスタッフを1人ないし複数配置し、すべてのレポートはのちの傾向分析用にアーカイブしておく必要があります。

お客様の運用要件にとって最も重要な測定項目については、リアルタイムの警告を設定して指定されたパフォーマンス測定値が最大限のしきい値を超えたときにアクティブになるようにしておく必要があります。実装を推奨する警告をいくつか図5 に挙げておきます。V5R2 iSeries Navigator（またはV5R1 Operations Navigator）を使用すると、システム全体あるいはジョブレベルの測定基準に対して警告（Navigatorでは「イベント」と呼ぶ）を有効にすることができます。各警告に対してしきい値を設定しておくと、値がそのしきい値に達するとメッセージがオペレーターやメッセージキューに送られたり、その他の自動アクションが遂行されたりします。

第2層 ― サービスレベルとアプリケーションのリソース利用率
この層ではパフォーマンスデータを様々なグループに細分化します。サービスレベルを理解するには、負荷（ユーザー数）、応答時間、スループットなどのデータをビジネスユニット別、選択されたローカルあるいはリモートのアプリケーション別にまとめなければなりません。ビジネスユニットは部門、特定のユーザーグループ、リモートの顧客セット、その他のサービス享受者などです。図6、図7、図8 に第2層での典型的な質問、収集する測定項目、典型的なレポート例を一覧にしてあります。

第2層のアクションはIT部門とビジネスユニットの間でサービスレベル合意（SLA）を確立するときに非常に有効です。SLAはパフォーマンス、可用性などといったシステム、アプリケーション、IT部門がビジネスユニットに提供するその他のサービスの特性を形式化したものです。図9 はSLAが一般的に指定する測定基準の一部です。SLAを確立してそれに対応するパフォーマンスを測定すると、システムとアプリケーションのどちらが「遅すぎる」のかというあいまい性を排除できます。パフォーマンスの測定結果がSLAで合意された内容を常に満たしているかまたはそれ以上であれば問題はありません。

全体的なシステムパフォーマンス（第1層で分析）の要因を理解するには、CPUやディスクの利用率などの測定基準をアプリケーション経由やアプリケーションタスク経由でまとめるのが理想的です。残念ながらiSeriesにはこれを可能にする方法が組み込まれていませんので、独自のSQLクエリー、プログラム、その他の代替方策を開発してこれを実行しなければなりません。分析は週単位または月単位に行ってください。

上記のような分析で、どのアプリケーションやタスクが全体のシステム負荷のうちで最も高い割合を占めているのかがわかり、パフォーマンス向上が最も期待できるアプリケーションにフォーカスをあてることができます。またこの情報は収集したサービスレベルの情報と時間軸を通じて関連付けられるので、標準以下のサービスレベルの要因を見極めることもできます。たとえば、特定の期間のレスポンスが高すぎると判断できるとき、アプリケーションの分析を通じてどのアプリケーションが主要因になっているのかを突き止めることができます。

最後に、アプリケーションのリソース使用しきい値を定義して警告（図10）を実装し、定義したしきい値を頻繁に超えるアプリケーションを自動的に識別することができます。第2層の警告は単にイベント情報をファイルにログとして記録してのちに分析に使えるようにするというもので、オペレーターやシステム管理者にメッセージを送信して即座に注意を喚起するというものではありません。第3層で説明するように、警告の履歴からさらに診断を必要とするアプリケーションを識別することができます。

第3層 ― アプリケーションのパフォーマンス診断
この層ではパフォーマンス上問題がありそうなアプリケーションや最適化の候補となっているアプリケーションを臨機応変に診断するツールやテクニックを使用します。こうしたツールやテクニックは、第2層の継続的なモニタリングによって問題や高使用度のアプリケーションが識別された時だけでなく、開発中や初期の展開時にも使用できます。図11、図12、図13には第3層アクティビティでの質問、収集すべき測定項目、典型的なレポートの例を一覧にしてあります。

付随的なデータの収集に使用されるツールの候補としては、Database Monitor、Performance Tools/400（PT400）のPerformance Explorer（PEX）、ローカルで開発したトランザクション時間ログ記録ルーチンなどがあります。レポート生成用ツールの候補としては、PT/400、iSeries Navigator SQL Monitorレポート、Visual Explain、iDoctor PEX Analyzer、PTDV、サードパーティ製ツール、カスタムクエリーなどがあります。

どの診断ツールを使用するかを決める際にいくつかの方策を考慮しなければなりませんが、特に次の2つのルールは最も重要です。

＊パフォーマンス問題の原因究明と解決には直感はあてになりません。常に何らかの測定テクニックを使用して問題の原因を確認し、ソリューションがその問題に効くかどうか（さらに、副作用を引き起こさないか）を検証してください。

＊パフォーマンスの問題を解決する前にその問題が深刻なものであるかどうかを確認してください。ここでも何らかの定量的な測定テクニックを使用して最適化作業の選定と優先順位付けを行ってください。

私がお勧めするもう一つの方策は、アプリケーションに「計測用」コードを追加して、特定のアプリケーション機能に関連した実行使用やパフォーマンスデータを取得するというものです。たとえば対話型トランザクション処理アプリケーションの場合、パフォーマンスのログエントリを生成するコードを追加（たとえばレコードをファイルに書き出す）して、トランザクションタイプ、入力データ、結果、経過時間などの情報を取得するのです。このタイプの計測用コードは、プログラムのオブジェクトコードを作り直さなくても必要に応じて有効にしたり無効にしたりできるようになっていなければなりません。アプリケーション固有のパフォーマンスを動的にログに記録できる機能は、特定のパフォーマンス問題を効率的に突き止める際に大変有効です。

アプリケーションの機能によってはベンチマーク測定が相対パフォーマンスを測定する効率的な方法である場合もあります。ベンチマーク測定は計算量が多くて非対話型の機能に特に向いています。たとえば、アプリケーションが複雑な会計アプリケーションのルーチンを呼び出している場合、このルーチンをさまざまな値で繰り返し呼び出すドライバを作ることができます。このようなベンチマーク測定はいろいろな使い方ができます。

ベンチマーク測定を行うと特定の機能が時間やリソースをどの程度使用しているのかを大まかに把握できます。たとえば、複雑な会計ルーチンを実行するルーチンが、1回の呼び出し当たり平均で0.25ミリ秒かかっていて、実行時間が最もかかるバッチジョブでそのルーチンが最大200万回呼び出されているとすると、このルーチンを最適化することでおよそ8分改善できる可能性があるわけです。このような概略の見積もりを使用すると、このルーチンを最適化の対象とすべきかどうかを判断できます。

ベンチマーク測定を行うかたわらで、PEXなどのパフォーマンスツールを使用してどのリソースが使用中で、実行時間の大部分を占めているのがコードのどの部分であるかを測定することができます。またベンチマーク測定の前後で実行することによって、最適化、システムチューニング、新しいハードウェアの効果を評価することもできます。

対話型のアプリケーションやWebアプリケーションでは信頼性の高いベンチマーク測定を行うことが比較的困難となります。データベースのI/O処理が多いルーチンのスタンドアロンベンチマーク測定でも、たとえばキャッシュの影響などにより結果を見誤らないように注意が必要です。

短距離ではなくマラソン競技
総合的なパフォーマンス管理プロセスを設定することは容易な課題ではありません。自分の組織のニーズや文化に合うように時間をかけて計画を練り上げます。iSeriesのパフォーマンスに関しては本当の意味で「目の前のお金」が懸かっているということ、管理プロセスを長期間にわたって保守していくことが株価を上げるための最良の方法であることを忘れないでください。

ポール・コンテ氏はiSeries NEWSのシニアテクニカルエディタで、オレゴン州ユージーンにあるPCES社の社長を務め、Database Design and Programming for DB2/400（29th Street Press）、SQL Server 7 Developer's Guide（Osborne/McGraw-Hill）、Introduction to SQL（29th Street Press）などの著書、共著書も出版している。同氏はiSeries向けのSQLやJavaのアプリケーション開発に対する教育・コンサルティングサービスを提供している。

↑このページのトップへ