レベル: 中級 Matt Haynos (mph@us.ibm.com), Program Director, Grid Technology and Strategy, IBM
2005年 12月 06日 記事「グリッドの展望 : 全体は、部分の合計よりも大きい」で、IBM Grid Marketing and Strategy の Program Director である Matt Haynos は、自動化がグリッド環境内で (特にプロビジョニングとオーケストレーションにおいて) 果たす重要な役割について述べました。要点は、グリッド環境への自動化の導入は段階的に行えるということです。この記事では、グリッド環境内でインフラストラクチャーの自動化を効果的に実現する、論理的かつ革新的なアプローチについて、Haynos が概説します。このアプローチは、多くのお客様とのエンゲージメントにおいて得られた経験に基づくものです。
グリッド上に構築された動的なインフラストラクチャーへの道のり
多くの組織では、Platform LSF や Altair PBS Professional などのジョブ・スケジューラーを使用してワークロードを仮想化することにより、グリッドへの道のりを歩み始めています。実際、IBM は最近、Grid and Grow というオファリングの提供を開始しましたが、これはまさにこうしたお客様を対象としています。この道のりは、ワークロードのコンテキストを解析することから始まります。そしてワークロードを仮想化した時点で、焦点は資源管理に移ります。つまり、サーバー、ストレージ、ライセンス、ネットワーク帯域などの資源を、インフラストラクチャーがワークロード要求に応じてインテリジェントに供給できるようにする、しかもそれを自動化された形で行えるようにする必要があるということです。その結果、組織の関心は、ジョブ・スケジューリング・テクノロジーとプロビジョニングおよびオーケストレーション・テクノロジーの融合に向けられることになります。
グリッド・コンピューティングに基づいて構築された動的なインフラストラクチャーに向けてこの道のりを歩み始めた組織は、プロビジョニングやオーケストレーションなどのテクノロジーを完全に統合するに当たってあらかじめ考慮しなければならないことがあることに気付きます。技術的な問題も確かにあります。しかし、それよりもまず、自動化全般の概念に対する安心を得ることが大切なのです。
自動化の哲学
インフラストラクチャーの自動化は、シンプルで魅力的な概念です。エンタープライズ内の複数のアプリケーションやインフラストラクチャーにわたり、適切な場所に適切なタイミングで自動的に資源を割り振ることができるということは確かに魅力的です。しかし、結局のところ、この考えに対して、さらには自動化全般に対して、ユーザーと組織が安心感を得なければならないことがわかります。人間は本質的に、自動化されたプロセスやタスクが自分自身と同じレベルのインテリジェンスをもって実行されることを確認するまでは、自動化に対して不信感を抱くものです。また、自分の仕事や任務が自動化に取って代わられるのではないかという不安もある程度あります。
ここで、わかりやすい例を二つ紹介しましょう。最初の例は、インフラストラクチャーの自動化を請け負っているある会社の創立者に伺った話です。まず、新しい車を購入しようとしている場面を想像してみてください。展示場に入ると、見るからにベテランのセールスマンがあなたの方に近づいてきて、素晴らしい車があると告げます。その性能は信じがたいもので、あなたは「この車についてもっと知りたい」と思います。そのセールスマンによれば、この革新的な車は自動で走行することができ、あなたは後部座席に座っているだけでよいというのです。そこであなたは自問します。この車の後部座席に乗り込むべきかどうか。しかし、この車に胸を躍らせることはあったとしても、おそらく答えは「ノー」でしょう。実際に自動で動いているところを自分自身の目で確かめて安心を得るまでは、とても後部座席に乗り込む気にはならないはずです。自動化についても、これと同じことが言えます。
もう一つの例は、私がプログラマーとして UNIX® シェル・スクリプトに多くの時間を費やしていた頃にさかのぼります。私は数週間をかけて、いくつかの開発活動や管理活動を自動化するスクリプトを完成させました。それは、自分の仕事、ひいては会社の仕事がもっと楽になることを約束するものでした。私は、そのスクリプトを実行するたびに、結果が期待どおりかどうかをチェックしました。そうして、間違いなく正常に動作するという確信が得られるまで、数週間続けてスクリプトの「お守り」をしました。私は元々、疑い深い方でしたので、スクリプトが私の意図どおりに動作することを自分自身で確かめずにはいられなかったのです。その甲斐あって、そこからは順風満帆でした。
これらの例から得られる教訓は、自動化に対して安心を得るには時間と経験が必要だということです。洞察力のある組織は、自動化に至るまでには論理的な発展があること、そして人的要素が重要な考慮事項であることを認識しています。
プロビジョニングからオーケストレーションへ
図 1 は、グリッド配備の初期段階に始まり、自動化された資源割り振りの段階的実現に至るまでのアプローチを示しています。ここでは、資源が配備される可能性のあるアプリケーション・インフラストラクチャーが複数あることを前提としています。たとえば、金融会社の場合、顧客対面用の口座管理アプリケーションとそれに対応するインフラストラクチャーのほかに、リスク管理アプリケーションとそれに関連するグリッド・インフラストラクチャーもあるでしょう。資源は有限であるわけですから、要するに適切なアプリケーションに適切なタイミングで資源を割り振ることが、サービス・レベルの変動を最小限に抑える、すなわちビジネス価値を最大化するための秘訣なのです。この例については後でもう一度触れます。
図 1. 完全自動化に至るまでの段階的道のり
では、完全自動化に向けてのステップについて見ていきましょう。最初の 1 ～ 3 ステップでは、リスク管理アプリケーションと新しいグリッド・インフラストラクチャーを運用できる状態にします。これは非常に単純明快です。まずグリッド・インフラストラクチャーを構築します。その後、グリッド・ミドルウェアとグリッド資源を構成し、一連のグリッド資源全体をスケジューリングしてリスク管理アプリケーションの運用を開始します。もちろん、アプリケーションがすでに並列化または通常は Scatter/Gather アプローチの実装によってグリッド対応になっており、分散した資源にわたって動作することが前提となります。
次のステップは重要です。というのは、このステップで、グリッド・アプリケーションの資源使用状況と消費パターンのダイナミクスが分かり始めるからです。それには、ある種のオフラインの分析を使用するか、あるいはアプリケーションを実際に監視して、その振る舞いと資源割り振りの効果に関する情報を得ます。これを行う方法については、いくつかの「技」がありますが、全体のパターンは個々のアプリケーションの性質に大きく依存します。一般的なゴールは、割り振られた資源に応じたアプリケーションの振る舞いについて、何らかの洞察を得られるようにすることです。資源の割り当てられ方とアプリケーションのパフォーマンスに対する全般的な効果に対して、安心感が得られ始めることが非常に重要なのです。
次にIBM Tivoli® Intelligent Orchestrator などの製品 (これらは Objective Analyzer と呼ばれ、次のセクションでもう少し詳しく触れます) で、資源割り振りの決定に関連するアルゴリズムを作成したと仮定します。このステップは、資源割り振りソフトウェアがシステム管理者に対して、あるインフラストラクチャーから別のインフラストラクチャーに資源を割り振る必要が生じたことを知らせるアラートを提供できるようにすることです。ここでは何も自動化されません。システム管理者は、資源割り振りソフトウェアから提供される推奨情報（アラート）を理解し始め、再プロビジョニング・タスクを手動で開始することによって対応するアクションを実行することができるようになります。このステップは、手間のかかるものとなる可能性があります。なぜなら、多くの集約的な管理活動があり得るからです。しかし、資源割り振りソフトウェアの決定に対して安心感を得るには極めて重要なステップです。
ステップ 6 では、アラートが提供されます。それだけでなく、資源割り振りソフトウェアが実際に処理し、資源割り振り (または割り振り解除) を実行することを管理者が許可する手段にもなります。資源割り振りソフトウェアは、その推奨情報（アラート）を管理者に提供し、対応するアクションを行うかどうかの確認を求めます。これは、ステップ 5 と非常によく似ています。違いは、資源割り振りを実際に実行するオプションが提供される点だけです。これも重要なステップです。なぜかと言えば、管理者は本質的に「信頼していますので、どうぞ先に進んでください」と言うだけだからです。これらの段階を経て、自動化ソフトウェアは管理者からの安心感を得ていくのです。
最後のステップでは、基本的に、資源割り振りソフトウェアに制御を完全に渡します。開発した資源割り振りアルゴリズムおよびポリシーが適切なものであれば、その結果として、何もせずにただ見守っているだけで、有限の資源が適切なアプリケーションに適切なタイミングで配備されて、サービス・レベルの変動が最小限に抑えられ、ひいては会社のビジネス価値が高まります。
グリッド環境内での資源割り振り
資源割り振りソフトウェアにおける最も重要な問題は、特定のアプリケーションとそれらに関連するインフラストラクチャーにいつ、どのような方法で資源を割り振るかということです。資源割り振りの自動化を実現する革新的なプロセスについて説明しましたが、これは基本的にグリッド・インフラストラクチャーにも、非グリッド・インフラストラクチャーにも適用できます。つまり、これは哲学なのです。しかし、グリッド・インフラストラクチャーが関係する場合、資源割り振りの決定に関する問題には特別の配慮が必要です。
Tivoli Intelligent Orchestrator では、複数のアプリケーション・インフラストラクチャーにわたる資源割り振りの決定は、Objective Analyzer と呼ばれるプラグイン型のモジュールを用いたフレームワークを介して行われます。アプリケーション・インフラストラクチャーごとに、その環境用の Objective Analyzer が少なくとも一つ存在します。Objective Analyzer は、1 ～ N 個の資源に対する (サービス・レベルの) 違反の可能性を返すソフトウェアです。
基本的に、Objective Analyzer は、一つまたは一連のアプリケーションが割り振られた数 (少なくとも一つ) の資源ではサービス・レベル・アグリーメントを果たせない可能性を Tivoli Intelligent Orchestrator に知らせます。Tivoli Intelligent Orchestrator の仕事は、この情報をすべて収集し、複数のアプリケーション・インフラストラクチャーにわたってポリシー・ベースの資源割り振りを決定することです。グリッド環境の場合、インテリジェントな Objective Analyzer をいかに構築するかが秘訣となります。
グリッド環境には多種多様な特性があります。通常、サービス・レベルの違反が生じる可能性を示す指標として役立つのは資源使用率です。これは、前出の金融口座管理アプリケーションのような Web 環境に特に当てはまります。ところが、ここでのリスク管理アプリケーションのようなグリッド環境では役に立ちません。実際のところ、使用効率の高いグリッド・インフラストラクチャーこそがゴールであり、多くのグリッド・ユーザーにとってまさに主目的だからです。
グリッド環境においてさらに重要なことは、コンピューティングの速度です。アプリケーションの処理完了に向けての進捗状況はどうか。速度は低下したか。資源を追加すればスピードアップするか (これはアプリケーション次第ですが)。という具合に、グリッド環境では速度の方がはるかに役に立つ指標となります。しかも、これは長期のワークロードにも、短期間のワークロードにも当てはまります。短期間のワークロードの場合、速度は、基本的にグリッド・インフラストラクチャー全体に分散したトランザクションのスループット (タスク) です。
グリッド環境の場合、総合して考慮しなければならない事項が数多くあるため、資源割り振りの決定も、Objective Analyzer の構築も複雑なものとなる可能性があります。ただし、取り掛かりとして非常に簡単なポリシーはあります。それは、時刻ベースのポリシーです。この例では、口座管理アプリケーションは、たとえば通常の営業時間後はあまり使用されないことが予想されます。ですから、その時点で、それらの資源をリスク管理アプリケーションや、一日中絶えず実行されるその他のグリッド・アプリケーションに再プロビジョニングすることは理にかなっていると言えるでしょう。この資源割り振りポリシーなら、グリッド・インフラストラクチャーが関係していてもシンプルになります。
プロビジョニングからオーケストレーションへ
この記事では、複数のアプリケーション・インフラストラクチャーにわたる資源割り振りを含む自動化の仕組みに関するいくつかの課題について説明しました。特にグリッド・インフラストラクチャーが関係する場合、テクノロジーも確かに重要かもしれませんが、考慮すべき最も重要な側面は自動化に対する人的要素です。また、グリッド環境内での資源割り振りの決定に際しては、一般的な 3 層構造のアプリケーション・インフラストラクチャーと比べて特別の配慮が必要です。
最後に興味深い話を付け加えておきましょう。WebSphere® Extended Deployment (XD) のように、管理者がアプリケーションの優先順位付けポリシーを設定する手間を省く統合型グリッド・パッケージがあるのです。資源割り振りソフトウェアを構築する必要はありません。管理者が各アプリケーションの相対的重要性とサービス・レベル目標を指定すれば、後は WebSphere XD がリソース割り振りを自動的に管理してくれます。
参考文献 学ぶために
製品や技術を入手するために
- Visit Platform Computing to find out more about the Platform LSF family of products.
- Visit Altair to find out more about PBS Professional.
議論するために
著者について  | 
| | Matt Haynos is a program director on the IBM Grid Technology and Strategy team, based in Somers, N.Y. He has various responsibilities on the team covering a broad range of initiatives related to building the IBM grid computing business. He has held a variety of technical and managerial positions within IBM in the application development, program direction, and business development areas. He holds a bachelor's degree in computer science/applied mathematics and cognitive science from the University of Rochester, and a master's degree in computer science from the University of Vermont. He lives with his wife and two sons in Connecticut. |
記事の評価
| 
