アーキテクチャ・ジャーナル グリーンITのためのアプリケーション・パターン Dan Rogers、Ulrich Homann 2010/03/02
Page1 Page2 Page3

■スケール単位ベースのアーキテクチャ/ 設計

　この記事の前半部分では“最終状態”、つまりユーザーの予測最大数に基づいてシステムの設計を行うことの問題点について考えました。時間と共に増加するユーザーすべてにサービスを提供しようとしてアプリケーションを構築すると、必ずリソースが浪費されます。また、システムの規模を拡大しすぎると、障害点のリスクが増大します。最初の段階でコスト的に実現できない場合もあります。

　簡単な例で考えてみましょう。ロード バランサーを購入するとき、動的に拡張できるバランサーを購入することはできません。ロード バランサーが備えるポートの数は決まっているからです。このように、物理機器の処理能力の限界は、システムの規模を制限する要因となり、コストにも大きな影響を与えます。500 のポートを備えたバランサーを購入することは可能です。しかし最初の年に必要なポート数が100 であれば、容量の大きなハードウェアを購入したことで、本来節約できた資金が無駄になってしまいます。巨大なレンガ 1 つで壁を作ることと同じく、予測最大値を根拠として IT 展開を設計することはお勧めできません。

　規模を適切に調整するには、スケール単位に基づくアプローチを採用する必要があります。スケール単位によって、明確に定義された“成長要因”に基づく“管理された成長”が実現します。このアプローチを前述のインストルメンテーションや複合/ 要素分解と組み合わせ、ジャスト イン タイム方式で展開すると、アーキテクチャに負担をかけることなく、実際のユーザー要求に合わせたリソース消費が実現します。このアプローチは、大規模なインターネット プロパティでも実践されています。

　ここで有効になるのが、スケール単位の計画です。スケール単位は、IT リソースの定義済みブロックであり、拡張の 1 単位を表します。このブロックには、次のステップに進むために必要な要素がすべて含まれています。たとえば、コンピューティング性能、ネットワーク容量、配電ユニット、床面積、冷却装置などが含まれます。スケール単位は、最初期のリソース ニーズを満たすと同時に、トランザクション、ユーザー数、ポートなど、鍵となる成長要因に発生した差分を埋めるものでなければなりません。スケール単位のサイズは、すぐに必要なリソースと、時間と共に増加するリソースとのトレードオフが最適になるように選択します。

　一般にどのような製品でも、処理能力の計画マニュアルを参照することで、さまざまな成長要因を読み取ることができます。一般化できる例を挙げると、Microsoft SharePoint Server の計画ガイドには、リソース（サーバー、ストレージ、帯域幅など）計画は、SharePoint サイトの数と規模、希望する 1 秒あたりの応答数、予想されるアクティブ ユーザーの数に基づいて行うようにという指示があります。そして、これこそ SharePoint Server の成長要因なのです。“最終状態”に基づく設計モデルでは、通常、予測される処理能力を反映したアーキテクチャを前提にリソース要求量が算出され、その後展開となります。しかし、私たちの提案は、“最終状態”を前提とした展開をやめて、ジャスト イン タイムの展開によってリソースの最適利用を実現する、というものです。

　この設計プロセスは、きわめてシンプルかつ単純明快です。

1. 入手可能な処理能力の計画情報に基づいて、ソリューションの展開を設計します。

2. このソリューションの成長要因を特定します。ソフトウェア ベンダーや開発チームから情報を得られれば最善です。得られない場合は、処理能力の計画ガイダンスを精査し、拡張によって変化するソリューション アーキテクチャ内の要素（通常は、ユーザー トラフィック、要求の処理、Web サイトなどの“静的”要素、Web サイトのコンテンツなど）を特定します。

3. 特定した成長要因ごとに適切なスケール単位を決定し、設計します。スケール単位に基づく展開を実施するのが初めての場合、成長要因は 1 つか 2 つでもかまいません。

4. 定義したスケール単位に基づいて、設計を“分割”します。

5. 初期の展開とその後のスケール単位によって成長していった場合も、展開の全体が機能することを検証します。

6. 初期のスケール単位のみに基づいて、ソリューションを展開します。効果的なスケール単位展開には、効果的なモニタリングと、自動化された（少なくとも適切に管理された）展開（プロビジョニング）が必要であり、成長要因とスケール単位との間には明確な因果関係が存在しなければなりません。

●例

　SharePoint を例に考えてみましょう。読者にはお馴染みの製造メーカーContoso で SharePoint Server を展開するとします。世界各地のビジネス ユニットでこのソリューションを展開することを考え、目標とする最終状態に到達するのは 2010 年とします。ソリューションのスケール単位と成長要因は、表 1 に示されています。

表 1: SharePoint の展開例のスケール単位と成長要因

　図 6 は、表 1 の成長要因に基づいて展開が発展する場合のスケール単位と、展開の最終段階を示しています。

図 6: スケール単位に基づく成長

　ソリューションは、初期の段階では 2 つの SharePoint アプリケーション サーバー インスタンスと 1 つの SQL Server インスタンスを含むエンド ツー エンド ソリューションとして展開されます。この図では、成長のきっかけとなる要因が連続して発生しているように見えますが、成長要因は互いに独立しています。ただし、1 つのスケール単位による展開が、ソリューションの他の側面に影響を与える可能性はあります。

●すべてを考え合わせて

　このアプローチの有効性を検証するため、この記事で考察したアイデアをいくつか組み合わせ、前述のモデルを再び使用して、スケール単位と処理能力の計画について考えてみましょう。

　まず“消費されるサービス単位”というスケールに注目してください。このスケールは、図 3 のグラフの右側にある赤い線で表されます。T-0 の時点では、データ センターは構築されていますが、その処理能力はまだ活用されていません。データ センターでのリソース消費が始まると、時間の経過と共に、消費量が処理能力を上回るようになります。紫の線より下の領域は、活用されている処理能力を表します。一方、紫の線より上の領域は、未使用の処理能力を表します。未使用の処理能力を効果的に管理することで、真の意味で電力が節約されます。

■仮想化

　アプリケーション アーキテクトにとって仮想化とは、IT グリーン化のスタート地点ではなく、アプリケーションを効率化して消費リソースを最小化するための手段です。処理能力の拡張を開始する際に仮想化を活用することで、ハードウェア リソースをユーザーのニーズと厳密に一致させることができます。これにより、展開されているものの活用されていないハードウェアの処理容量を下げ、消費電力を削減することができます。将来は、仮想化によって、既に配備されているが余剰なリソースをシャットダウンできるようになるでしょう。ただし、このようなソリューションを実現するには、スイッチの切り替えが可能なコンピューター制御の電源回路、動的なネットワーク構成、必要に応じて構成/ 分解でき、部分的なスケールアップ/ダウンが可能なソフトウェアが必要です。また、ソリューションをモニタリング システムとリンクし、ソリューションがモニタリング システムによって駆動されるようにしなければなりません。このモニタリングシステムは、アプリケーションの健全性を追跡することに加え、処理能力を左右する要因と、消費されている処理能力とを“認識”できるシステムです。これらの要素を核とすることにより、サービス レベル契約（SLA）条件の到達状況に合わせて、コンピューティング リソース（ひいては電力）の使用を抑制できます。つまり、必要なパラメーター内で実行されていれば、処理能力の余剰分を停止できます。

　業界で進む仮想化への大規模なシフトは、主にこのようなシナリオに基づいています。ただしこれは、ソフトウェア システムにおいて前例がないほどのきめ細かい制御機能と正確なモデル（処理能力モデル、消費モデル、多次元でのモニタリング、安全域、電力計画など）を必要とする、驚くほど複雑なシナリオです。

　データ センターのサイズを測定単位とできない場合でも、「同じ量のタスクをより少ないリソースで完了する」という課題から逃れることはできません。そこで重要になるのが、アーキテクチャでのアプリケーション分割です。現在、問題とされているのは過剰なリソース、つまり、「未使用のリソースを検出し、オフにする」ということです。これは第一線の IT プロであれば解決できる問題です。将来、“追加する”という考えは選択肢でさえなくなるでしょう。そのとき、この問題を解決できるのは、設計者とアーキテクトのみになります。というのも、これはソフトウェアが展開あるいは構築されるより前に、解決すべき問題だからです。仮想化を利用してオフピーク時のリソースの無駄を解決する、“より多くのリソースで、より多くの仕事を行う”アプローチを使用せず、リソースが常に存在することを前提とするアプリケーションの構築はやめなければなりません。その代わりに、ビジネス アプリケーションが可能な限りすべてのリソースを効果的に消費できるよう、リソースの最適化に力を入れるのです。つまり、“多くのコンピューターの購入”を考える代わりに、むしろ問題の条件を厳しくし、現在必要だと思われるリソースの 3 分の 1 や 4 分の 1 で実行できる方法を考えるのです。20 年後には、まさにこれが現実となっているでしょう。たとえば、サーバー 5 台分の働きをするソフトウェアを、コンピューター 2 台分の処理能力で実行できるよう、仮想化してスケジュールに組み込まなければならなくなります。これを実現するには、無駄になっているリソース、つまり紫の線より上の領域をすべて活用し、利用可能なすべてのリソースを 24 時間効率的かつ効果的に使用する必要があります。

■今後の展望

●蓄積と転送、待機と再開

　アーキテクトが設計しなければならないのは、互いに独立して機能するパーツで構成されるものの、正常にデータを共有し、適切な順序で作業を実行できるアプリケーションです。ここで、毎月 2 日間しか稼動しない給与処理システムの例に戻りましょう。課題となるのは、残りの 28 日間リソースをいかに活用するか、その方法を見つけることです。そのためには、特定のハードウェアで専用のソフトウェア構成を実装することをやめ、その代わりに仮想領域に分散して格納され、必要なときに取り出して、さまざまな組み合わせで有効化できるアプリケーションを設計する必要があります。

　これを実現するには、柔軟性に富む強力な制御ソフトウェアのセットが必要です。制御ソフトウェアとアプリケーションは互いに連携して、機能コンポーネント（サーバーの役割など）やトポロジ（サイトやサーバー グループなど）の負荷を追跡、プロファイリングしなければなりません。また、“時間”をリソース管理の主要指標に設定して、静的また動的な使用状況を追跡およびプロファイリングする必要もあります。図 7 は、24 時間にわたる負荷プロファイルを単純化してグラフにしたものです。時間を軸として考えることにより、リソースが常に確保できることを前提とする原則を打ち破り、限られたリソース予算の中で達成されるサービス量を増大させることができます。

図 7: 単純化された 24 時間の負荷プロファイル

●ポートフォリオの管理

　個々のアプリケーションを管理することは、正しい方向に進むための重要な一歩です。とはいえ、目標とするサービス結果を実現するうえで最も大きな効果を発揮するのは、アプリケーションのポートフォリオ全体を対象とする静的および動的なリソース管理です。制御ソフトウェアは、リソースの使用状況を追跡できるか、スケジュールに基づいて管理が可能な（常に実行されていない）スケール単位を特定できるか、管理されている全アプリケーションの負荷プロファイルに基づいて動的に拡大/ 縮小を実行できなければなりません。適切に要素分解され、記録、計測されたアプリケーションは、この新しい管理手法の鍵となります。新しい管理手法を実現することによって、分散環境ではいまだ実現し得なかったリソースの最適化が実現できるでしょう。

■System Center に対するマイクロソフトの投資

　オペレーティング システムのコンポーネント化が始まった頃から、マイクロソフトはモニタリング、ソフトウェア配布、問題診断、仮想化の戦略を推進してきました。その中心となる投資領域、つまり管理、インフラストラクチャの制御、運用の自動化は、Microsoft System Center 製品ファミリとして結実しています。現在では、Microsoft Operations Manager、Virtual Machine Manager、およびConfiguration Manager の統合が進められており、リソースの効率的な活用に不可欠な動的かつ柔軟な制御システムが実現されようとしています。統合が進むことで、包括的なシステム管理ソリューションの登場が期待されています。このソリューションでは、最適化によって少ないリソース単位（床面積、冷却システム、計算処理能力など）で、より多くの処理を実行できるようになるでしょう。

　では、このような動きは、どのようにビルディング ブロック アプローチと調和するのでしょうか。System Center は、動的なオペレーティング環境における作業を制御します。設計やソフトウェア開発の観点からすると、監視対象（アプリケーション インストルメンテーションによって提供されるモニタリング データで、主な処理能力とリソース消費量の情報を明らかにする）を定義し、それらの測定単位が重要なシステム コンポーネントの健全性や処理能力に与える影響を特定するのは、管理パック（System Center の制御メタデータ）の役割となるでしょう。これにより System Center では、何が実行されているのか、ワークロードが問題なく適切に分散されているかを、継続的に把握できます。

　管理パックは、システムの区分化された各要素に対する重要な制御コンポーネントとなります。管理パックのアーキテクチャは、特定のスキーマ セットに従う XML ファイルというシンプルなものですが、要素分解された各コンポーネントの状態と健全性が記述されるメタデータであるゆえに強力です。大規模な同期アプリケーションに対して有効であるものは、要素分解されたアプリケーションに対しても有効です。実際、現在入手できる最も優れた管理パック設計（たとえば、Windows Server 2008、SharePoint、Dynamics アプリケーション用の管理パック）には、当初から階層化やコンポーネント化が組み込まれています。

　System Center の進化に伴い、ビジネス アプリケーション、インフラストラクチャ、またスタックの基盤要素における管理パックの重要性もさらに高くなるでしょう。System Center が既に Linux や Unix サーバーの健全性をモニタリングできることを考えると、アプリケーションの柔軟性に革新をもたらすための土台は既に据えられているといえます。この革新が実現すれば、オペレーティング システムやソフトウェア サプライヤーを自由に選択しつつ、非常に少ないコンピューティング リソースでシステムを管理することが可能になります。どのようなテクノロジを基盤としていても、アプリケーションの分割設計への移行が可能である限りは、アーキテクト本人あるいは他の誰かが、モニタリングや処理能力活用の対象領域を管理パックとして記述することが可能です。これによって、アプリケーションは経済的かつ効率的に管理できるようになり、アプリケーションの効率性を妨げているハードウェア制約から解放されます。

■まとめ

　アプリケーション アーキテクトは、より効果的にリソースを管理する分散システムを設計できます。まず、明確に定義された最適化の目標に基づいて要素分解を実行します。スケール単位を使用すると、全体的な展開アーキテクチャを損なわずに、適切に要素分解されたソリューションをグループ化し、最小限の展開と対応させることができます。インストルメンテーションとスケール単位を組み合わせることにより、System Center などの制御ソフトウェアを使用して、設定された最適化の目標とアプローチに従って、アプリケーション ポートフォリオを管理できるようになるでしょう。これらの機能が現実のものとなるのは、遠い将来のことではありません。とはいえ、消費できる電力に確実に限りがある世界では、一刻も早く実現できれば、それに勝るものはありません。

■参考資料

• Measuring National Power in the Postindustrial Age（脱工業化時代における国力の測定）、Ashley J. Tellis 他、RAND Corporation、2000 年
• Wikipedia、Theory of Constraints（制約条件の理論）

著者について Dan Rogers は、1998 年にマイクロソフトに入社し、BizTalk、Visual Studio、MSN など数多くの製品にかかわってきました。現在は、System Center 製品チームに加わり、動的な IT ソリューションを有効にするモニタリング戦略に専門的に携わっています。MSN では、一般的なストレージや電子メール サービスなどの大規模な動的プロパティのモニタリング ソリューション設計に参加し、グローバルなデータ センター イニシアチブの完全自動運用など、さまざまなプロジェクトのメンバーとして活躍してきました。 Ulrich Homann は、マイクロソフトの国際サービスの戦略プロジェクト グループでリード ソリューション アーキテクトを務めています。CTO 直属のこのグループは全世界の重要な戦略プロジェクトで管理とエンタープライズ アーキテクチャを担当しています。

INDEX
	［アーキテクチャ・ジャーナル］
	グリーンITのためのアプリケーション・パターン
	1．課題と現実
	2．どの制約を最適化するか
	3．スケール単位ベースのアーキテクチャ/ 設計

「アーキテクチャ・ジャーナル」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）