簡単な調査で分かる“限界”
適切な「ITキャパシティー管理」を実現する3つの手順
アプリケーションに投入するリソースを増やすだけではスケーラビリティを確保することは難しい。IT運用担当者は、リソースやパフォーマンス全体を考慮したITキャパシティー管理について慎重に検討すべきだ。
仮想化とクラウドが登場したことで「アプリケーションの柔軟性」を確保する方法が変化しつつある。企業のIT部門は、ITキャパシティー管理をすることで長年夢見ていた「コストを制御しつつ、QoE(Quality of Experience)も確保する」という望みを達成できるかもしれない。
柔軟性のあるコンポーネント(エラスティックコンポーネント)は、コンポーネントのコピーを複数稼働させておき、障害が発生してコピー元(オリジナル)のコンポーネントが停止した場合に、オリジナルの代理でコピーに処理をさせる考え方だ。だが、このようなスケーラビリティ(拡張性)があっても、利用できるリソースを十分用意できなければ意味を成さない。電気通信会社CIMIの調査によると、負荷に合わせてスケールアウト(機能拡張)するアプリケーションのコンポーネントを使う企業のうち、4分の1近くはそうしたスケーラビリティの限界を定義できていないという。つまり、必要なリソースが明確になっていないということだ。
スケーラビリティの高いアプリケーションが使われる仮想化の時代に、適切な「ITキャパシティー管理」をするための3つの手順を紹介する。
1.必要なスケールアウトの範囲を決める。
2.その範囲内でリソースのスケールアウトした場合の効果を見積もる。
3.許容できるコストで利用可能なリソースを確認する。
ソフトウェア応答時間と管理グラフ
アプリケーションのスケーラビリティを決めるためには、応答時間を追跡できるソフトウェアを使った負荷テストでQoEを評価すればいい。このテストはスケールアウトを想定するアプリケーションごとに必要だ。テストが完了したら、応答時間を図表に示して曲線を描く。その曲線はある時点で横ばいになるだろう。
コンポーネントが十分に作業できる数が稼働していれば、それ以上コピーを増やしても応答時間は改善しない。パフォーマンスは「作業できるコンポーネントの数」で頭打ちになる。こうした現象は何らかの原因でアプリケーションの処理が停滞し、QoEが低下することでも発生する。アプリケーションが何の要因で停滞しているかを把握するには、リソースの割り当て状況を確認した方がよい。ホストのリソースと、リソースへの接続許容量を調べる。クラウドベンダーとの接続部分は特に念入りに確認すべきだ。ホストリソースのネットワークが混雑していると、リソースを使い果たした場合と同じくらいQoEが低下するためだ。応答時間を記したグラフが平たんになる直前のリソース使用量を基準として、混雑が解消されるリソースのレベルを特定する。リソースが混雑状態になっているなら、アプリケーションのためにリソース増加の検討をすべきだろう。ただし、リソース増加にはコストがかかる。
アプリケーションのスケーラビリティを見極めたら、コストとQoEの関係に目を向ける。QoEはユーザーの期待に左右されるところがある。一般に、生産性の高さとアプリケーションの応答時間は関係するといわれる。応答時間の変化が問題になるのは、生産性への影響が実際にある場合のみだ。まずはソフトウェアによる負荷テストの応答時間グラフを利用するといい。このグラフにはリソースと応答時間の対比が示される。グラフの曲線が平たんになる位置から始めて、上下に移動しながらさまざまな位置でテストを実行する。
目的は生産性の範囲を定めることだ。ユーザーの作業に悪影響を及ぼす位置から、応答時間がさらに改善しても作業成果が上がらなくなる位置までの範囲を見極める。ITキャパシティー管理では、ほぼ全ての場合でアプリケーションをサポートする十分なリソースを用意し、生産性範囲の約70%以内に運用を維持することが目標になる。影響が表れるポイントの20%以下と、改善が見られなくなるポイントの10%以上に挟まれる範囲を目指すことになる。後はそのリソースにかかるコストを集計し、その範囲内で運用を管理する。クラウドベンダーが提供しているスケールや容量の割引という経済的要素も忘れずに考慮する。
単独で実行されるアプリケーションはない
アプリケーションごとのリソース調整が終わったら、企業の全てのリソース要件を決める。特定の時間に多様なアプリケーションが実行されたり、リソースを求めて争ったりすることがあればリソースの容量を増やなければならない。ITキャパシティー管理には重要な要素がもう1つ存在する。それは需要がピークに達する時間だ。アプリケーションのリソース要件は、必ずしも各アプリケーションの需要の合計とは一致しない。ユーザーがアプリケーションにアクセスする方法は1日を通して差がある。そのため、リソース要件は時間の経過とともに変わることになる。
ある期間で使用量がどう変化するかを調べるには、アプリケーションごとに活動ログ(アクティビティーログ)を確認する。アプリケーションが実行される割合と時間を特定できるだろう。使用量を追跡するには、実際の運用でのリソース使用量を評価する。実際の運用をシミュレーションするように調整した入力データに対してテストを実行してもよい。テストで得られた結果はリソース使用量と対比してグラフに曲線で示す。このグラフを使えば、ある期間にわたる全アプリケーションのリソース合計使用量が分かるだろう。もし、この時点でスケールアウトに限界があるようであれば再調整する。再調整ではリソースの混雑状態が発生しない値を設定すべきだ。データセンター間やクラウドへのネットワーク接続を対象に含めることを忘れてはならない。
このリソース使用量グラフは、リソースの節約効果をまとめることにも役立つ。全アプリケーションのリソース合計使用量が、クラウドベンダーから提供されているもっと安価なクラウド価格帯にぴったりだとすると「もう少しリソースに余裕を持たせてもコストは問題ない」といった判断も可能だ。
本稿では、アプリケーションの応答時間とリソースを関連付けたグラフと、ある期間での合計リソース使用量とコストを関連付けたグラフを利用した。これらの個々のグラフが、ITキャパシティー管理をする上で最も重要なツールになる。1つ目のグラフは各アプリケーションが実行される安全な範囲を定める。2つ目は、これらの範囲を組み合わせてリソースの需要、ひいては予測コストをもたらす方法を示す。最初はリソース要件を安全に割り当て、計画をまとめ上げ、それから同じ手法を再利用して、キャパシティーレベルを最新に保つことができるだろう。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
2
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
3
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
4
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
5
肥大化した「SFA」の沼 4カ月でBigQuery×AppSheetの新システムを構築した方法
-
6
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
7
次世代RPA「ハイパーオートメーション」が急成長か Gartnerが予測
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
昭和大学病院がeICUを導入、ICUの患者情報を遠隔地で一括管理
-
10
「何から始めればいい?」 情報漏えい対策で悲鳴を上げる中小企業のリアル
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
プログラミング不要で誰でも実現できる、ネットワーク運用管理の自動化とは
-
4
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
5
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
6
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
-
9
“あのファイル転送”で暗躍するノーウェアランサム
-
10
「オンプレミス回帰」せざるを得ない“合理的な理由”
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー