レベル: 中級 Marlon Machado (mmachado@us.ibm.com), e-business Architect, IBM
2004年 9月 14日 戦略 1、2、3 の下でグリッド対応アプリケーションをチューニングする際は、作業単位と結果セットの間の均衡点を発見する必要があります。ここでは、そのための簡単な方法について学習しましょう。各戦略については、一連の developerWorks の記事の中で David Kra によって定義されています。
概要
既存のアプリケーションをグリッド化するための戦略 1、2、3 (developerWorks のシリーズ記事「アプリケーションのグリッド化に関する 6 つの戦略」に記載) は、グリッド・コンピューティングの普及に拍車をかけました。
新しいコンピューティング・パラダイムの例に漏れず、SOA ベースの世界へ全面移行する前には、このような統合 (グリッド化) 作業が数多く行われます。(SOA の詳細については、developerWorks の SOA and Web services のコンテンツ領域を参照してください。)
通常、統合作業にはチューニングが必要です。チューニングを行う場合、最も高い視点からは、統合システムをブラック・ボックスとして想定できます。そうすれば、システムへの入力 (作業単位) ストリームと出力 (結果セット) ストリームのサイズや構造のチューニングに集中できるようになります。このことは、既存のアプリケーションをバッチ指向グリッド・インフラストラクチャー製品に統合する場合に特に役立ちます。実際のアプリケーションはプラットフォーム固有であることが多く、チューニング不可能だからです。
統合システム上では、入出力以外のさまざまな領域にパフォーマンスのボトルネックが発生する可能性があります。このようなボトルネック領域の多くは製品やテクノロジーに固有のものなので、この記事では解決方法を取り上げません。一般に、統合システム内で製品やテクノロジーのボトルネックが発生するのは、役割に問題があるか、システムのその他の部分とのやり取りに問題があるからです。グリッド対応アプリケーションでは、パフォーマンスのボトルネックが発生する可能性があるのは、共有ファイル・システム、ネットワーキング、本来は非互換であるシステムとのコネクター (SAMBA など)、データベース、ライセンス管理製品、セキュリティーなどの領域です。これらのテクノロジーの一般的な問題点については、解決方法を検討しながら徐々に対処していく予定です。
今のところは、グリッド導入の最初の 3 つの戦略に基づいてグリッド化を行う場合の、高い視点から見たパフォーマンス・プロファイルに集中することにしましょう。これは、大部分の統合システムで問題となるからです。
グリッド化シナリオとパフォーマンス・プロファイル
図1は、低程度のグリッド化、高程度のグリッド化のそれぞれについて最も適するグリッドインフラストラクチャーソフトウエアを説明しています。
図1. バッチ指向アーキテクチャーとサービス指向アーキテクチャーのグリッド化戦略
図に示すように、グリッド・インフラストラクチャー・ソフトウェアとしてバッチ指向と SOA ベースのどちらを使用するかによって、各レベルのグリッド導入に適用されるグリッド化シナリオが決まります。この図には、各シナリオのパフォーマンス・プロファイルの違いも明示されています。
グリッド化シナリオとは
一般に、グリッド化レベルが下位 3 段階であるコンテキストで既存のアプリケーションをグリッド化する場合は、ほとんどが「配備シナリオ」です。一方、SOA 指向グリッド・インフラストラクチャー・ソフトウェア上で動作するようにアプリケーションをグリッド化する場合は、アプリケーションをサービス指向にするという根本的作業が伴うので、「アーキテクチャーとプログラミングのシナリオ」になります。両シナリオには、それぞれ特有のパフォーマンス・プロファイルがあります。
パフォーマンス・プロファイルとは
「パフォーマンス・プロファイル」とは、ワークロードが変化した場合にシステムが示す挙動全般のことです。パフォーマンス・プロファイルはパターンです。例えば、入ってくるワークロードの増加が CPU 利用率の上昇につながり、かつその関係が一定で予測可能な場合は、システムのパフォーマンス・プロファイルは CPU 集約型であるといえます。その場合、「システム」という用語は複数ノードを有するグリッドを意味します。
次のセクションでは、システム全体の配備シナリオのパフォーマンス・プロファイルについて検討します。
下層におけるパフォーマンス
あらゆる配備状況に共通することですが、パフォーマンス・プロファイルには、システム・パフォーマンスを最適化するためにチューニング可能な重要な設定項目がいくつかあります。このような「チューニング可能な」システムでは、スイート・スポット、つまり重要な設定項目の値を組み合わせることにより、パフォーマンスを最大化できます。
バッチ指向のグリッド・インフラストラクチャー製品に既存のアプリケーションを配備する場合、重要となる設定項目は以下のとおりです。
- 作業単位 - クライアント・ドライバーとグリッド・インフラストラクチャー・ソフトウェアを介してユーザーからアプリケーションに情報を渡す際に、使用されます。これはバッチ・ジョブ、つまりアプリケーションに供給されるパラメーターを内包するエンベロープです。作業単位は、単純なテキスト・ファイルや XML ファイルとして作成することも、データベース表にすることもできます。アプリケーション側で正しく読み取れる限り、作業単位の形式に制約はありません。
- 結果セット -- グリッド・インフラストラクチャーを介して実行依頼されたバッチ・ジョブごとに、個々のノードで生成されます。これはアプリケーションの出力、つまりアプリケーションに供給されたパラメーターに基づいて取得されます。作業単位の場合と同様に、ユーザー側で正しく情報を引き出せる限り、結果セットの形式に制約はありません。
作業単位と結果セットの関係を最も適切に把握するには、その作業をグリッドで処理する場合のコストについて、資源利用度の観点から検討するとよいでしょう。
作業単位と結果セットの関連付け
一般に、配備シナリオのパフォーマンス・プロファイルには、ジョブ送信のたびにシステム上で発生する、以下の 3 タイプの作業が示されます。
- 作業単位の処理 - 通常は、ジョブ送信ドライバー・プログラムによって実行されます。
- アプリケーションの作業 -- グリッド・ノード上に配備されたアプリケーションが実行する、実際の作業です。
- 結果集約の作業 -- 各グリッド・ノードから入ってくる個々の結果セットをより大きな結果セットに統合して、ユーザーに返します。
続いて、システムの全体的パフォーマンスが次の式で定義されます。
リスト1. システム・レベルのパフォーマンス
P は、システムのパフォーマンスをブラックボックスとして見たものです。A は、アプリケーションのパフォーマンス (定数値) です。U は、作業単位の構築に必要な作業です。R は、最終的な結果セットを生成するために必要な作業です。
アプリケーションのパフォーマンスが定数値である理由
一般に、戦略 1、2、3 に基づいてグリッド化される既存のアプリケーションは、バッチ・ジョブを入力とするプラットフォーム固有のプログラムです。そこで、条件の悪いシナリオ、例えば、「単独のマシン上で実行してもグリッド上で実行しても、アプリケーションのロー・パフォーマンスがそれほど変わらない」というシナリオを仮定してみましょう。
多くの場合、アプリケーションをグリッド化する目的はプログラム実行の高速化ではないため、この仮定は妥当です。大多数のシナリオでは、既存のアプリケーションをグリッド化する背景には、「アプリケーションを複数のノードで並行実行することで、科学計算処理や事務処理に要する時間を短縮したい」という考えがあります。この考えが A を定数値と見なす理由です。
U と R について
U の値には、入力データを必要とするノードの数が影響する可能性があります。また、グリッド・インフラストラクチャーのトランスポート・プロトコル (例えば SOAP/HTTP を介する WSDL エンベロープ) に準拠するために作業単位をパッケージ化すべきかどうか、あるいはグリッド・ノードに送る前に入力データをフラット化 (例 : オブジェクト・シリアライゼーション) すべきかどうか、といった要因も、U の値に影響する可能性があります。
一般に、任意の数 n 個のノードについて、U は次の式で定義されます。
リスト2. グリッド入力の構築に必要な作業
この式は、「n 個の作業単位の生成に必要な総作業量は、個々のサブ作業単位 u の生成に必要な総作業量にノード数 n を掛け、それに任意の作業量 w を加えたものに等しい」という意味です (w は、作業配備全体をサポートする際に必要となる可能性のあるノード数とは無関係です)。
R については、「個々の結果セット r を生成するコストは、個々のサブ作業単位 u を生成するコストに等しい」という最善のシナリオを仮定します。単一のサブ作業単位から 2 個か 3 個、あるいはそれ以上の数の結果セットを生成できるとしたらすばらしいことですが、そのような幸運なケースはありえません。したがって、任意の数 n 個のノードについて、R は次の式で定義されると言えます。
リスト3. 最終的な結果セットの生成に必要な作業
w は (上記の場合同様に) 環境をサポートするために必要となるノードとは無関係な作業であり、g は個々の結果セットをそのジョブの最終的な結果セットに集約するために必要となる作業です。
ここで注意すべきなのは、w と g の値はアプリケーションの特性、実際に使用されるグリッド・インフラストラクチャー・ソフトウェア、およびグリッド配備のベースとなるトポロジーによって決定される、ということです。つまり、w と g はどのような値にもなりえるのです。ここでこの点を掘り下げているのは、作業単位と結果セットの生成に関わる各種の作業を見積もるためにどれほどのデータ収集が必要となるかということを、読者の皆さんに認識してもらいたいからです。適切な監視ツールをあらかじめ導入していない場合は、各自で入手してください。
次に、スイート・スポットの発見に進みましょう。
スイート・スポットの発見
一般に、作業単位と結果セットの処理は、アプリケーションが実行すべき実際の作業とはまったく関係ありません。この処理は、アプリケーションのグリッド化に伴う副作用のようなものです。したがって、この追加作業がシステム全体のパフォーマンスに与える影響を最低限に抑える必要があります (式 1 参照)。要約すれば、グリッド化の要点は、可能な限りシームレスかつ透過的な状態を保つことにあります。
ここでのルールはごくシンプルです。つまり、作業単位と結果セットの生成に必要な作業の性質を考慮し、かつ式 1 の内容に基づいている場合は、P の値が大きければ大きいほどパフォーマンスが向上する、ということです。これは、U と R を可能な限りゼロに近づけたい、ということを意味します。すなわち、コストをかけずに (つまり、作業単位と結果セットの生成に資源を投資せずに) アプリケーションをグリッド化できることが望ましいのです。しかし残念ながら、現実世界はそう都合よく動いているわけではありません。
現実的な対処方法は、グリッド関連の作業をなるべく環境関連の作業から分離した状態に保ちながら、両者の間の均衡点を発見することです。この均衡点がスイート・スポットです。
グリッド関連作業と環境関連作業の識別
理想的には、作業単位と結果セットの処理に関連するすべての作業は、図 2 に示したように、グリッド・ノードの外部に置いておきたいところです。そうすれば、アプリケーションの作業をグリッド・インフラストラクチャーの作業から実質的に分離し、システムのパフォーマンス・プロファイルの全体像を明確に把握して、システムをチューニングできるからです。これ以外の方法でシステムをチューニングすることはできません。
図2. 作業単位と結果セットの役割
図 2 をよく見れば、「作業単位をサブジョブに分割する作業はユーザーが行ってもジョブ送信ドライバーが行ってもよい」ということに気付くでしょう。これは、U の作業全体をグリッドの外部で行ってもよい、と意味です。
図 2 に示したシナリオを式 2 の U の観点から表現してみると、「n(u) が対応するのは、必要な数のサブジョブを生成するためにジョブ送信ドライバーが実行しなければならない作業である」と容易に推測できます。また、元の作業単位をユーザーまたはポータルからジョブ送信ドライバーへと移動する際に必要な作業を (それだけとは限りませんが) w が表していることもわかります。
さらに、「結果サブセットを単一の結果セットに集約する作業は統合サービス・レベルで行われる (それ以外の場所では行われない) 」ということにも気付くでしょう。もう少し厳密に見れば、結果セットの生成と集約に必要な作業が実際にはグリッド自体 (r) と、環境 (w) および統合サービス (g) (いずれもグリッド外)に分割されていることがわかります。
次に、これを従来の方法論に当てはめてみましょう。まず式 1、2、3 を連結し、その結果生じた式の要素をそれぞれの作業タイプごとに並べ替えます。この操作を行った結果が式 4 に示されています。
リスト4. グリッド関連作業と環境関連作業の分離
P = [ A - n(g) ] - [ n(u+r) + 2w ]
|
 |
数学的処理の詳細について
ここでは、式 5 を導くために実際に使用した手順を紹介します。
まず次のように、式 1 に式 2、3 を代入して、グリッド関連作業と環境関連作業をそれぞれグループ化します。
P = A - U - R
P = A - [ n(u) + w ] - [ n(r+g) + w ]
P = A - n(u) - w - n(r+g) - w
P = A - n(u) - n(r) - n(g) - 2w
P = [ A - n(g) ] - [ n(u+r) + 2w ]
|
これで、システムのパフォーマンスを決定するグリッド関連要素と環境関連要素を、実質的に識別できます。
次のステップは、「グリッド関連作業と環境関連作業の間の均衡点を発見する」という基本的仮定を適用することです。ただし、A に関しては何もできないので、最低条件のシナリオ (これも基本的な仮定の一部です) の下での最善策は、「可能な作業をすべて最低限に抑えるよう努めることです (式 1 を確認してください)。
この場合に望めるのは、全体のパフォーマンスが落ちないことだけです。つまり、「P = A」が理想で、「G - E = A」が望ましい、という意味です。次の手順を見てみましょう。
G - E = A
A - n(g) - E = A
-n(g) - E = 0
n(g) = -E
n(g) = -n(u + r) - 2w
|
この等式を整理すると、最終的に式 5 が得られます。式 5 は、u とr の関係、つまりこの両者の間の均衡点をわかりやすく示します。
|
|
式 1 は、パフォーマンスを、システムへのデータ・フロー関数として示したものです。それに対して式 4 は、パフォーマンスを、システムで実行すべき作業の性質の関数として記述したものです。
式 4 には、「G = A - n(g)」として定義される、グリッド関連要素 G が含まれています。G は 2 つの要素で構成されています。1 つは定数値 (A)、もう 1 つはノード (結果サブセットを生成する必要のあるノード) の数に依存する要素です。また式 4 には、u とr の関係を「E = n(u+r) + 2w」として記述する、環境関連の要素 E が含まれています。
ここで、A が定数値である最低条件のシナリオをもう一度仮定し、グリッド関連作業と環境関連作業の間の均衡点を発見するという元の戦略に戻りましょう。個々のサブ作業単位と個々の結果セットを生成して処理する場合、必要な作業量の「スイート・スポット」は、以下の式 5 によって与えられます。
式 5. スイート・スポット
式の意味
この式の全体的意味はきわめてシンプルです。すなわち、個々の結果サブセットを生成するコストは、「対応する個々のサブ作業単位の生成と処理のコスト」、「個々の結果セットを最終的な結果セットに集約するコスト」、「作業単位と結果サブセットを容易に処理するために必要な作業量を処理が行われるノードの数で割った値」をすべて加えた値になるということです。
少し説明が複雑になりましたが、式 5 から引き出せる情報の中で最も重要なのは、アプリケーションのグリッド化に関するコストを「結果サブセットが資源面でどれほど高くつくか」という観点から見積もることです。
式 5 は、作業単位を複数の小さなサブ単位に分割した結果発生するパフォーマンス・コスト、として解釈することもできます。以下に式 6 を示します。
式 6. パフォーマンス・コストとしてのスイート・スポット
式 6 は、作業単位の選択に応じてグリッドと周辺の環境に加わるオーバーヘッドを示しています。この式により、任意数の作業単位から結果セットを生成するコストの比率 (割合) が算出されます。
まとめ
この記事ではまず、ノード非依存バッチ、独立並行バッチ、並列バッチなどの配備シナリオを使用して実行されるグリッド対応アプリケーションについて、その一般的動作を論じてきました。また、配備シナリオの典型的なパフォーマンス・プロファイルを分析し、パフォーマンス・プロファイルを特徴付ける 3 タイプの作業について明らかにしました。
次に、式 1 によって表される単純な数学モデルの観点から、パフォーマンス・プロファイルを表しました。このモデルを使用した目的は、最低条件のシナリオから引き出された仮定に基づいて作業単位と結果セットの間の均衡点を発見することでした。そして「スイート・スポット」と命名したこの均衡点を、アプリケーションのグリッド化コスト (式 5) や、システム入力を複数の小さなサブジョブに分割した結果生成されるオーバーヘッド (式 6) として表現しました。
ここで明らかになるのは、戦略 1、2、3 を使用して既存のアプリケーションをグリッド化する場合には、グリッド入力の細分度 (粒度) を決定する前に、結果生成のための必要コストを資源使用効率の観点から検討しなければならない、ということです。
式 5 は、個々の結果サブセットのコストをパフォーマンスの観点からわかりやすく示しています。ここでは、以下のそれぞれの値の平均値を見積もる必要があります。
- サブ作業単位を生成するコスト (u)
- 結果サブセットを集約するコスト (g)
- この処理をすべて行うために余分に必要となる作業量 (w)
「作業単位の作成によって生成されたオーバーヘッドを減らす」という観点から問題を把握しなければならない場合は、式 6 を使用すると、実際のグリッド化作業に適したスイート・スポットを発見できます。
値 w と値 g の見積もりに必要となるデータは、監視ツールを使用して収集できますが、必要なパフォーマンス測定基準が記述されている限り、どのような方法で表現してもかまいません。Mbps、1 秒当たりの要求数、1 分当たりのトランザクション数などの基準のほか、実際的な意味のある測定基準であれば何でも使用できます。
この簡単な方法を使用すれば、負荷のかかった状況下でもグリッド対応環境を適切に制御できるようになるでしょう。ただし、この方法を使用できるのは、戦略 1、2、3 に基づいて既存のアプリケーションをグリッド化する場合に限られます。SOA ベースのグリッド化プロジェクトについても同様の方法を提供できるように、今後もアーキテクチャーおよびプログラミングのシナリオ研究は継続されます。今後の記事に、引き続き注目してください。
参考文献
著者について | | | Marlon Machado joined IBM in 1996 as a programmer for the ISSC organization (now IBM Global Services) in Atlanta, Georgia, where he worked on various projects involving distributed architectures. In 1998 Marlon joined the San Francisco Technology Center in Austin, Texas. He later became an e-business Architect for IBM Developer Relations where he has conducted research in high-performance distributed architectures based on the J2EE programming model. Marlon is the author and lead instructor of "Performance Tuning - WebSphere Application Server Advanced Edition," an advanced hands-on workshop offered at IBM Solution Partnership Centers worldwide. Marlon lives in Austin, Texas and in the beautiful Caribbean coast of Honduras, but he spends most of his time traveling around the world assisting IBM's ISV partners. You can contact him at mmachado@us.ibm.com. |
記事の評価
| 
