Tweet

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

Page1 Page2 Page3

■概要

　エネルギー不足の進行に伴い、エネルギー資源の価格が上昇しています。この状況は今後、IT ソリューションの設計、展開、使用に大きな影響を与えると考えられています。その影響が最も顕著に現れるのは、データ センター レベルでしょう。この問題を解決するうえで、仮想化その他の省電力テクノロジがある程度の成果を収めるとしても、アプリケーションの仮想化は本質的に効率性が低いため、限界は明らかです。

　この記事では、電力効率の高いアプリケーションを設計するためのアイデアを紹介します。作業完了に必要なリソースを減らすことでデータ センター構築の必要性も低くなり、結果として企業の資金節約につながります。こうした取り組みは、近い将来、企業の継続的な成長にとって必須の作業となるでしょう。

■問題点

　現在、全世界の企業が、賄える電力量の限界、または消費できる電力量の制限に既に直面しているか、あるいは直面しようとしています。図 1 を見ると、データ センターの成長を阻むのは、データ センター コストのうち最も大きな割合を占めるサーバーの運用/ 管理コストのように思えます。ところが、消費電力を抑制すると、そのことが制限要因となって成長曲線が阻害されます。この点は、右側の図の調査データにも現れています。

図 1: データ センターのコスト

　各国の政府がエネルギーに注目し、米国議会が国内の総電力消費量の一環としてデータ センター電力消費を制限することを検討している現在、企業の将来の成長は、利用できる電力と冷却性能にかかっているということが言えそうです。これらの制限に対応するため、企業はエネルギー消費を制限または削減しようと努力しています。しかし、現在最も広く使用されているさまざまなアプローチの多くは、インフラストラクチャ最適化に主眼を置くものです。これでは、将来の電力課題を考えると視野が狭すぎるかもしれません。インフラストラクチャの最適利用を実現するためには、アプリケーションのアーキテクチャと設計、データ センターの管理、IT 運用といったさまざまな分野に対応する、複数の手法によってエコシステム全体を運用する必要があります。

■制約条件の理論

　まず、たたき台として最適なのは、多くの読者にも馴染み深い Goldratt 博士の制約条件の理論（TOC: Theory of Constraints）です。TOC の基本的な考えは、サブシステムを個別に最適化するより、システム レベルの制約（または相互依存関係）を特定し管理する方が最適化への近道となるという考えです。TOC は元々工場の生産管理のための理論でしたが、一般的なアプリケーションに対して適用されるようになりました。また、グリーン IT の導入作業にも適切に当てはめることができます。この記事の内容と最も関連性の高い TOC の原則は、スループットの最適化です。この原則は、システムのボトルネックを管理することにより、最大のスループットが得られるというものです。つまり、システム内のボトルネックを調整して、利用可能なリソースのスループットを最大化することができます。IT の場合、制約となるのはサーバー、イメージ、仮想マシン、メモリ、帯域幅などのインフラストラクチャ コンポーネントです。これらのコンポーネントが、価値あるビジネス成果が生まれるスピードを左右しているということになります。

■課題と現実

　これまでに高い評価と実績を築いてきたアプリケーションやソリューションの設計パターン/ 動作にも、現在の制約と対立してしまったり、将来的な対立の悪化が予想されるものがあります。

　使い放題は過去のもの。現在のアプリケーション開発者やアーキテクトは、いつでも必要なときにリソースを使える時代で育ってきました。私たちがメインフレームを卒業して以来、ニーズに見合ったリソースを得られて当然という状態が続いたわけです。しかし、電力容量がますます不足しつつある今、各国政府はデータ センターが消費するエネルギー量に厳しい制限を課そうと議論を始めています。これはつまり、これからの開発者は、アプリケーションの電力消費を最適化することに多くの時間を費やさなければならなくなるということです。そこには、消費制限をオーバーすればそれ以上のコストがかかるという、単純な理由があります。

　最終状態を想定して設計されるアプリケーション。現在のほとんどのソリューションは、需要に応じて成長する有機的なシステムとしてではなく、予測される“最終状態”を基に設計されています。たとえば、15 万人のユーザーを抱える企業が SharePoint ソリューションを展開する場合に、各ユーザーに 50 GB のディスク容量が割り当てられるとします。このソリューションの設計、処理能力、展開の計画では、15 万人のユーザーがコラボレーションを行えばすぐに 50 GB のディスク容量が必要になるという“最終状態”が想定されています。

　図 2 は、ある架空のアプリケーションまたはソリューションを展開/ 使用した場合の標準的な負荷プロファイルを示しています。負荷は 2 年間にわたって増加するものとします。処理能力に余裕があれば安心感は得られるかもしれませんが、一般的には無駄になります。電力やストレージなどのリソースは、展開の初日から使用プロファイルの最高値を基準に割り当てられています。これらを“ジャスト イン タイム”方式で割り当てれば、貴重なリソースを節約してコストを削減することができます。

図 2: 展開されているソリューションの負荷プロファイル

　何が、いつ必要かを見極める。90 年代の半ば、Microsoft IT 部門は HR アプリケーションとは別に、多くのサーバーを必要とする給与処理ソリューションを実行していました。各サーバーは月に 2 日間だけ実行され、残りの時間はアイドル状態を維持していました。倹約家のマネージャーたちが何度かこの点を指摘しましたが、IT スタッフは給与処理システムで他のタスクを実行することに難色を示しました。給料が支払われなくなっては大変ということで、この議論は毎回 IT 部門が制していたのですが、現在は状況が異なります。「コンピューターかデータ センターを追加する」という意見を最初に述べられる時代ではないのです。「リソースの消費を抑えるように設計する」が、採用するべきアプローチです。そのためには、処理能力の需要の変動をよく把握する必要があります。つまり、「何が、いつ必要なのか」を見極めることが必要です。

　勘と経験（SOYP: Seat Of Your Pants）による設計。SOYP に従って計画を行えば、必ずシステムに非効率性が入り込みます。しかし、大規模なインストールであっても、過去の経験と不確かな処理能力データに基づく推量によって設計されている場合が多いというのが現状です。入力要素を組み合わせていくと、通常はピーク時の負荷に n%（20% < n < 50%）がプラスされた状態を想定したソリューションが設計されます。処理能力を低く見積もってプロジェクトを台無しにしたと言われることを避けようとして、プロジェクト スケジュールを計画する場合に使われるアルゴリズムが、処理能力計画にも適用されているのです。

　“二重対策”ソリューション設計アプローチ。初期のクライアント/ サーバー教本の教えは、“用心深すぎるということはない”というものでした。当時のシステムソリューションは十分な堅牢性を備えていなかったため、アーキテクトはリスク、問題、障害を回避するためにさまざまな策を講じました。1 つの策が破られても、別の策が機能するというわけです。アプリケーション設計の領域では、アプリケーション/ インフラストラクチャのパートナー制度を考案して、起こり得る可能性のある、あらゆる障害に対して複数の回復ソリューションを用意しました。また、“単一障害点”という言葉は、途方もない散財を後押しすることになりました。2 台の Web サーバーで足りるところに 3 台目を置き、ロード バランサー 1 台では故障したときに困るということで 2 台目を買い、クラスター化された冗長構成のストレージ エリア ネットワーク（SAN）上に 2 つのデータベースを構築したのです。

　回復/ 堅牢性強化ソリューションが必要なくなったわけではありませんが、そのニーズは企業の環境目標と両立させなければなりません。電力の使い方が重要になる中、アプリケーション アーキテクトはバランスのとれた設計を強く意識する必要があります。仮想化やハードウェアの機能向上への依存によって、取り組みの焦点がずれることは避けるべきです。エネルギー効率に優れた IT を実現するには、あらゆる要素を考慮する必要があります。

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

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

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