失敗事例に学ぶ運用性能品質向上策：攻めの性能マネジメント（4）（2/2 ページ）

[岡安一将，NTTデータ]

過去の教訓から学ぶ性能マネジメントのポイント

　今回ご紹介した事例から得られる教訓を整理してみると、運用時に実施すべき性能マネジメントのポイントが分かります。

事例番号	教訓	マネージメントのポイント
事例1	どうしても実現できない事もある	（1）リスク管理をしよう
事例2	問題発生前のプロアクティブ対応が理想的	（2）性能監視と診断
事例3	現状を把握していれば素早い対応ができる	（2）性能監視と診断
事例4	診断ツールの有無で解析効率が大きく異なる	（3）分析の仕組みを準備

【ポイント（1）】 リスク管理をしよう

• 対象：リスクの見える化
• 観点：迅速な対応
• 工程：すべて

　PMBOKによると、リスク管理とは、リスクの識別、分析、対応計画であると定義されています。今回の事例に当てはめると、以下のように整理できます。

• リスク識別：本番環境と試験環境のCPU数の違いから本番と同じ負荷が掛けられない
• リスク分析：本番環境ではCPU数分の性能が出ない可能性がある
• 対応計画の立案：試験環境のサーバを本番に移設する

　こうして管理しておけば、問題が発生した場合も早期復旧、最悪でも、お客さまに事前情報としてお伝えすることが可能になるのです。

【ポイント（2）】 性能監視と診断

• 対象：実性能の見える化（リスク回避策）
• 観点：かなり迅速な対応（戦わずして勝つ）
• 工程：運用

　システム担当の方でさえ、自社システムがピーク負荷になる契機と、主要サーバのCPU使用率を把握されている方は少ないのではないでしょうか？ 性能の現状を見える化すれば性能問題の防止が可能となり、運用品質の大きな向上が期待できます。

　見える化の対象は、以下の2つに分類することができます。

1. 業務性能

• オンラインレスポンスとスループット
• バッチ処理時間
• 同時ログイン数、売上高、取引回数、新規加入会員数など（業務特性に合わせて選択）

　業務性能は性能目標値をクリアしているかどうか監視します。それにより、限界までの余裕度も把握することができるため、問題発生前にサーバ増強やチューニングという、プロアクティブな対策を実施することが可能です。

2. システム統計情報

• サーバリソース使用率（CPU使用率、メモリ使用率など）
• ミドルウェア統計情報（DBMSやAPサーバの内部情報）

　システム統計情報は、プラットフォーム側の性能目標値、または監視閾値と比較し、それをクリアしていることを確認します。例えばCPU使用率70％以内での運用を想定している場合、現状が55％と分かれば、システムの増強が近いうちに必要になることが分かります。

【ポイント（3）】 分析の仕組みを準備しておく

• 対象：システムの見える化（リスク軽減策）
• 観点：迅速な対応
• 工程：運用（開発時も有効）

　分析ツールの有無により、解析作業の効率は数十倍という単位で変わるため、問題発生時の対応時間に大きな違いがでます。分析ツールは、以下の3つに分類することができます。

1. データ取得

　sarやvmstat、システムモニタといったOSのコマンドや、ミドルウェア標準の統計情報取得ツールのことです。標準のコマンドやツールは簡単に使えますが、それらを使いこなすスキルを持つ専門家が必要になります。

2. データ解析／表示

　シェルスクリプトによるデータ整形、Excelによるグラフ化などが一般的です。可視化により、データ解析のスピードは大きく向上します。スクリプトやマクロを作り込むことで、ある程度自動化することも可能です。

3. チューニングアドバイス

　有償の解析ツールには、解析効率を上げるための便利機能だけでなく、問題点を改善するためのチューニングアドバイスを提示してくれるものもあり、専門家不在でもある程度の対応が可能になります。必ず正解が提示されるとは限りませんが、人間では避けられないチェック漏れ、確認ミス等は確実に防止できます。また【ポイント2 】でご紹介した診断も、ツールのレポート機能を利用することで工数削減が可能です。

　お気付きの方もいらっしゃると思いますが、今回ご紹介した運用時の性能マネジメントには特別な技やスキルは必要ありませんが、導入コストを気にして、実施していないシステムが少なからず存在します。ツール導入の有無にかかわらず、問題発生時の損失を適切なコストで効果的に低減させるのが、性能管理のゴールの1つであるといえます。

　自動車の世界では、大量生産による普及から豪華装備による差別化の時代を経て、安全を売りにする時代がありました。エアバッグが全車標準装備になり始めたころです（若者は分かるかな？）。オープンシステムもそろそろ安全を売る時代ではないでしょうか。そのためには、大量生産されたエアバッグのように、コストダウンが必要です。そのために必要なのは何か？ 私たちは、ツールを活用した仕組みをもっと取り入れていくこと、つまりIT業界のIT化がTCO削減への大きなキーワードであると考えています。

---

　今回の事例でも少しご紹介しましたが、企画段階での業務量予測が外れることは珍しいことではなく、むしろ一般的です。ならば、攻めの性能マネジメントがそこを攻めないわけにはいきません！ 次回は、実業務量に対応するためのキャパシティプランニングについてご紹介します。

筆者プロフィール

岡安 一将

NTTデータ 基盤システム事業本部所属。Webシステムのインフラ開発に関する技術支援業務を経て、現在は社内外への性能コンサルティングと、性能問題予防のためのサービス展開を担当している。

「攻めの性能マネジメント」バックナンバー

• 保存版 性能品質の作り方
• システムは変化し続ける――キャパシティプランニング
• 失敗事例に学ぶ運用性能品質向上策
• ハード性能以上の性能は出ないんです
• 性能問題の失敗事例集
• 出そうで出ないシステム性能