SE関のノーツ/ドミノ徒然草: 第37回 キャパシティ見積りは社会科学?

前回とりあげたような大規模なノーツ/ドミノシステムのリリース移行は多くの場合、新しいハードウェアへの入れ替えや増強を伴うこともよく見られます。またこれを機にTCOの削減などを目的としてサーバーを一気に集中化するといったアプローチも見られます。いずれの場合でもそこで問題となるのが、『サーバーやネットワークのキャパシティはどう見積もればよいか?』という疑問です。今回はノーツ/ドミノのキャパシティ見積りについて移行の場合に限らずどんな考え方ができるか探ってみましょう。

Lotus クライアント テクニカル プロフェッショナルズ, ソフトウェア事業, 日本アイ・ビー・エム株式会社

Lotus クライアント テクニカル プロフェッショナルズ, ソフトウェア事業, 日本アイ・ビー・エム株式会社



2003年 9月 10日

まずノーツ/ドミノの場合を考える前に、通常のトランザクションシステムではどうでしょう。もちろんいろいろなアプローチはあるようですが、典型的にはまず"想定ユーザー利用"とでも言える情報、具体的には端末数から始まりピーク時の同時ユーザー数、ユーザーの操作シナリオといったものを出します。そして基本的なトランザクションの負荷などの"基礎負荷データ"を実験や事例などから抽出し、最終的に想定ユーザー利用と組み合せて算術的にサーバーやネットワークの負荷を出していっているようです。確かに理にかなった正攻法と言えるでしょう。

ではノーツ/ドミノではどうでしょう。確かにノーツ/ドミノでも基本的にはユーザーが利用するクライアント/サーバーシステムですから、同じアプローチをとれることでしょう。実際の例をみても通常のトランザクションシステムと同様に、まずは"想定ユーザー利用"をユーザー側から出してもらい、そして各ハードウェアベンダーが計測しているノーツ/ドミノの"基礎負荷データ"などを利用して見積りを行っているところがほとんどです。

ところが現場では、『1年たったらサーバー容量が足りなくなった』、『利用当初から応答が極めて悪い』、『早朝はまったくつかえない』といった苦情が時々聞こえてきます。キャパシティ見積りは正しくなかったのでしょうか。見積りを行ったエンジニアに聞けば、『ユーザーが想定より予想以上に成長してしまったんです』、『朝一番のアクセス集中がものすごいんです』、『重いアプリケーションがあってそれが足を引っ張ってしまって』とか様々です。

ではこれらの共通した課題はなんでしょうか。"基礎負荷データ"自身はベンダーが計測しているものですからこれはいじりようがありませんし、実測ベースですから恐らく妥当な数字だと言えるでしょう。そうするとやはり"想定ユーザー利用"があやしくなります。確かにユーザーの成長性、アクセス集中時の同時ユーザー数などのユーザー想定は、なかなか正しく想定するのは困難そうです。実際これらの出し方を見ているとかなり大雑把な推定であることが少なくありません。

トランザクションシステムなどでは、利用するユーザー、利用するアプリケーション、利用の仕方が比較的確定していて、業務の実施の仕方から、例えばピークの月末にこの程度の利用があるだろうということは推定できるでしょう。ところがノーツ/ドミノの場合はユーザーは社員のほぼ全員、PCは一人一台、アプリケーションはメールからワークフローなどの重いものまで多数となってしまい、いったい何時どんなピークがあるかはなかなか単純には推定できそうにありません。この全社員を対象とした汎用アプリケーション環境とも言えるノーツ/ドミノシステムの性格が、この"想定ユーザー利用"を困難にしていると言えるでしょう。

業務の特性からは推定が困難で、そしてユーザーもほぼ全員、アプリケーションは多様、という状況では業務に注目したユーザー利用の想定はかなり困難です。その先にあるやり方はもうオフィスにいる人間の観察くらいでしょうか。あるお客様の事業部のサーバー統合で、同時ユーザーを推定するのにお客様の感覚を尋ねてみました。すると『朝は皆PCに向かってほとんどメールとかを処理しています。たぶん100%でしょう。』という答えが返ってきました。経験的には10%からせいぜい50%程度の同時ユーザー数が100%というのは極めて異例ではありましたが、半信半疑に朝一番でオフィスを観察してみるとほとんどの人がPCの前に向かい、そしてかなりの人が実際にノーツを使っていました。当然のことながらサーバーでユーザーピークを見ると登録ユーザーの数とほぼ同じ数が記録に残っていました。実に現場の感覚や観察は正確なものだと感心したものでした。

その後ユーザーのピークユーザー数を知る上で、『フレックスは採用していますか』、『営業マンの直行直帰はありますか』、『朝礼はオフィスによって時間が違いますか』などオフィスの様子を想像できるような質問をキャパシティ見積りのためにしたりしています。このように一見技術的でない要素がキャパシティ見積りに役立つということは奇妙なものです。さらに全社系の掲示板などのサーバー見積りのために、『人事異動はどのように通知されていますか』、『営業マンが興味をもって見るものは何ですか』、『申請書の〆切はいつですか』、と特に利用が集中しそうなアプリケーションに関していろいろな質問が考えられます。実際これらの質問はユーザー自身が"想定ユーザー利用"を出すために頭の中で漠然と考えていることでもあるようです。

このような想定ユーザー利用のための一見あいまいな人の動きに関する観察と質問。しかしたくさんのアプリケーションをたくさんの人が使うノーツ/ドミノでは、想定ユーザー利用はまさにオフィスでの人の動きそのものの想定という意味で納得性があるかもしれません。しかもこの想定ユーザー利用の同時ユーザーだけとっても経験的には10%程度から100%までありえるということは、極端にはキャパシティ見積りが10倍違ってくることになり、その重要性は見逃せません。

想定ユーザー利用のための人の動きの観察は、キャパシティ見積りという極めて科学技術的に見えるものの中にある社会科学的な要素と言えるでしょう。そしてノーツ/ドミノでのキャパシティ見積りはそのシステムの特徴から社会科学的要素がかなり大きな位置を占めると言えるのではないでしょうか。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=339099
ArticleTitle=SE関のノーツ/ドミノ徒然草: 第37回 キャパシティ見積りは社会科学?
publish-date=09102003