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

■どの制約を最適化するか

　電力消費の制約によって、リソースの無制限な提供は非常に困難になりました。このため、アプリケーションやシステムを低コストで実行しつつ必要なサービスを提供するにはどのような最適化を実行すればよいのかを検討する必要があります。図 3 に示されているように、構成要素は、エネルギー消費量、利用できるサービス単位、そして消費されるサービス単位です。

図 3: オン/ オフいずれの状態でもサーバーは必要最低限のリソースを消費します。

　この図を解釈するには、まずこれが 4 次元のグラフであることを理解する必要があります（この図では、コスト単位 = データ センターです。もう少し小さい単位をベースとしたい場合は、適宜調整してください）。小さなブロックはスケール単位を表しており、一定の資金支出によって獲得される一定の処理能力を表します。1 より小さい単位を追加することはできませんが、単位そのもののサイズを変更することは可能です。ここでわかることは、処理能力は需要と重なって滑らかに上昇するのではなく、目盛りから目盛りへと増加するため、消費されるサービス単位とエネルギー消費量の間にギャップが生じるということです。最適化の鍵となる要因は、全体的な消費状況です。ここでは、IT 部門が常に方針とする“スイッチを切る”から進んで、“最大限に活用”という選択肢に到達することが重要です。エネルギー効率を最大にするには、単に単位を追加するのではなく、達成される処理量を増やす必要があります。

■電力コスト モデルの注意点

　電力の支払方法は、電力の利用量によって異なります。規模の小さい企業では、実際に使用した量に応じて支払を行います。こうした企業は、提供するサービスに対する消費電力の割合を下げようとします。不要なサービスを停止する場合もあります。一方、大量の電力を消費する企業は、ある程度の電力を一定の期間にわたって定額で使用できる契約を結びます。こうした企業の場合には、契約電力量を削減したり、購入した電力量を使って提供できるサービスの数を増やそうという力が働くことになります。リソース消費の停止が真っ先に検討されることはありません。停止しても、即座に得られるメリットはないからです。

■戦略

　最適化の促進要因、また最適化の妨げとなるアプリケーションのアーキテクチャや設計の課題について考察したところで、エネルギー効率の良い設計を実現するために実際に何が行えるかを考えてみましょう。

●あらゆるものを測定する

　システムやコンポーネントの動作に関するデータを収集し分析できなければ、最適化はただの当て推量になります。以下のガイドラインは、莫大なインターネット プロパティから得られた知識をまとめた、James Hamilton 氏によるマイクロソフトの社内論文からの引用です。

• すべてのものを計測します。システムを介して行われる顧客とのやり取りやトランザクションをすべて測定し、異常を報告します。Runner（ユーザーシミュレーション）は便利ですが、それだけで十分とはいえません。

• 開発時には、運用と同時にコード インストルメンテーション（アラート、警告、ステータス）を実行する必要があります。アラート機能は、運用中もリアルタイムで動的に調整できなければなりません。

• 必要に応じてオン/ オフを切り替えられる構成可能なログ機能をサポートして、デバッグに活用します。新しいビルドを展開して障害時のモニタリングを有効化するのは非常に危険です。

• 実運用環境におけるコンポーネントの健全性を簡単にモニタリングできる方法を実装します。

• 重要なアクションはすべて記録します。システムが重要な動作を実行するとき（特に、ネットワーク要求時やデータ変更時）は必ず、実行された内容をログに記録します。これには、ユーザー コマンドやシステムの応答も含まれます。デバッグの際、この記録が非常に役立ちます。さらに重要なことは、重要情報を特定するマイニング ツールを構築できるという点です。重要情報には、たとえばユーザーが実行しているクエリーの内容（検索用語、その単語数など）などがあります。

　最初に測定対象の結果を決め、次に測定を実行するという、シンプルなアプローチが最も適切です。概算値や統計サンプルだけに頼るべきではありません。測定を成功させるには、特定時点でのサンプルではなく、スループット計測を使用する必要があります。

　この作業をサポートしてくれる便利なツールが、マイクロソフトの Patterns & Practices チームからリリースされています。それは、Enterprise Library の Logging Application Block です。このビルディング ブロックは特に、アプリケーション コードのインストルメンテーションをサポートします。

●複合モデル

　「複合」という概念は、アプリケーション アーキテクチャの分野に広く浸透しています。しかしここでは、特定のモデルの優位性を議論することではなく、コンポーネント、サービス、システム設計に関する既成概念をアーキテクトや設計者に再検討してもらうことを目的とします。

　たとえば、既に紹介した“何が、いつ必要か”を見極めることも、再検討のアプローチの 1 つです。ハードウェアの領域でもコードの領域でも、この問題を検討することには大きな意味があります。たとえば、わずかな時間しか必要とされない（あるいは、まったく使用されない）アプリケーション コード、コンポーネント、モジュールが展開され、リソースを消費している場合があります。また、パーティショニングすべきシステムが、モノリシックな状態のまま実行されていることも珍しくありません。可用性の観点からすると、これは最もリスクの小さい方法かもしれませんが、リソースが無制限であるという誤った既成概念を生むことになります。よく知られている複合や要素分解のアプローチ/ 手法を活用することによって、ユーザーのニーズを満たしつつも、リソースを浪費しない設計を実現できるようになります。

●粒度

　要素分解と複合は、リソースの使用を最小限に抑えるための強力な手段です。その目標は、スタンドアロンの単位として既定で実行されるアプリケーションサーフェスを最小化することです。ただし、特定の目標のみに的を絞った最適化を過度に実施することは、避けなければなりません。機能を選択的に展開できるようにするには、アプリケーション コードを機能グループに分ける必要があります。このアプローチによって、全体の機能が損うことなく、コンポーネントを任意の時点で実行することができます。その結果、適切に定義された、リソース状況に適した単位で、作業をスケジューリングできます。

　Windows Server 2008 は、このようなモデルをベースとしています。図 4 は、Windows Server 開発チームが使用した分類を示しています。この分類は、顧客がそれぞれの抱える制約に応じて最適化を実施できるようにするという目標に基づき作成されています。

図 4: 単一のサーバーまたはワークロードの構成と依存関係

　Windows Server Manager では、役割に基づいて機能を展開し管理します。つまり、展開の選択肢も機能/ 役割レベルで提供されます。ワークロード、ソリューション、製品などの不必要に大きな単位に縛られることはありません（Windows Server の世界では、コンポーネントを実質上意識する必要がありません）。Windows Server 2008 と一緒にリリースされたすべての Windows アプリケーションは、この分類方法に従っています。Exchange 2007 などのその他のマイクロソフト製品でも、同様の役割ベースの要素分解アプローチが採用されています。

　この分類方法はマイクロソフトや Windows に固有のものと見なされているかもしれませんが、その他のオペレーティング システムやアプリケーションに対しても有効です。実際のところ、アプリケーション、オペレーティング システム、データベース、ERP や CRM システムなどの基業務ソリューションのソフトウェア開発では、これが一般的な複合フレームワークとなっています。

●依存関係

　このモデルは、一部のアプリケーションには複雑すぎるかもしれませんが、基本となる役割の概念はほとんどの開発者にとって馴染み深いものです。1 つの役割をベースとするアプリケーションであっても、通常は他の役割（データベースなど）に依存したり、他の役割やアプリケーションと連携したり（ERP システムとやり取りする Web サイトなど）します。しかし、従来のクライアント/サーバー アプリケーションでは、このような依存関係はコンパイルされたバインディングに隠されています。予見性が高く自動化されたリソース管理を実現するには、これらの依存関係を、アプリケーション ビットに含まれるモデル要素として露出させる必要があります。

　図 4 の分類は、単一のサーバーまたはワークロードの構成と依存関係を表しています。現在のデータ センターのほとんどのソリューションは、分散され、複数の階層にまたがっています。図 5 では、モデルにいくつかの局面を追加して、サーバーや階層間の依存関係を示しています。サーバー/ ワークロードとサーバー役割は図 4 の Windows Server の分類と同じなので、モデルの結合はスムーズに行えます。

図 5: 分散アプリケーション モデルの各局面

• アプリケーション: 表面に表れるアプリケーションまたは機能を論理的に表したものです。物理的には、アプリケーションでは、ある種のエンドポイント（HTTP/HTTPS、TCP/IP など）を露出します。また、他のアプリケーションへの依存関係も明示できます。たとえば、SharePoint は SQL Server と Active Directory に依存します。

• サイト: データ センターやデータ センター室への機能の展開を表します。アプリケーションには、複数のサイトを関連付けることができます。

• サーバー グループ: 高可用性（ネットワーク負荷分散やフェールオーバー クラスター）など、共通の属性を持つサーバーのグループを表します。アプリケーションは任意の数のサーバー グループを持つことができます。これはサイト内の階層として表現されます。

　このような情報があれば、運用チームは重要なリソースの依存関係と使用状況を把握することができます。また、機能要件や非機能要件、また任意の時点におけるユーザーやトランザクション負荷などの運用パターンを踏まえて、リソースを自動プロビジョニングすることも可能になります。

　アプリケーション アーキテクトの仕事とは、単一のサーバー内か複数のサーバー間かにかかわらず、機能要素をオンデマンドかつ適切なタイミングで展開できるようアプリケーションを構築することです。アプリケーションがこのように構築されていれば、どのようなエネルギー購入モデルが使用されている場合でも、運用担当者は柔軟に全体的な消費を最適化できます。また、運用担当者は、各アプリケーションおよびアプリケーション間で必要とされる機能や依存関係を明確に把握し、見分けられるようになります。このようにして、消費されるリソースを最小化しながらユーザーのニーズを満たす展開が実現されるのです。

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

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

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