システム障害の最大の原因は……

多くのユーザーが報道などで知ることになるシステム障害は氷山の一角で、実際には数えきれないほどの障害があちこちで発生している。多くのシステム障害は、「ギリギリのITリソースにしてサービス提供したい」という企業の投資効率への思いと、「障害を避けるために十分なITリソースを投入すべき」というITベンダーの思い……両者のせめぎ合いの結果から生まれるのだ。

システム障害が起きる理由

米EMC社によれば、日本企業の50%が、過去1年間にデータ損失またはシステム・ダウン(もしくは両方)を経験したと答え、データ損失とシステム・ダウンの主原因のひとつとしてハードウェア障害が55%にも達するとの調査結果を発表している。さらにこの調査では、システムの復旧やダウンタイムからのデータ復旧について完全な自信はないと回答した企業は全体の89%に上ったという。

大和田尚孝氏は著書「システムはなぜダウンするのか」の中で、システム・ダウンの原因は以下の4点に分けられるとしている。

・ソフトウェアの不具合

・性能・容量不足

・設定・操作ミス

・不慮の事故

本稿で述べるシステム障害範囲としては、ソフトウェアの不具合による障害は対象としていないので、システム障害が起きる具体的な理由としては、(1)人為的ミス、(2)システムの構成設計ミス、(3)システムのサイジングのミス、の3つに分けて考えたい。

(1)人為的ミス

最適なシステム設計、最適なシステムサイズであっても人為的な操作ミスや設定ミスなどでシステム障害は発生してしまう。人為的ミスを防止するには、2人で確認しながらオペレーションすることが望ましい。しかし、多くの現場では緊急時や人的リソースの問題から難しいのが実情だろうし、人がオペレーションする以上、ミスはつきものなのでシステム的な防止策というのは難しい。

(2)システムの構成設計ミス

システムの構成設計ミスはエンジニアとしては対処することが困難である。

機器構成における根本的なミスはコンピュータ自身が異常であることを知らせてくれるので大丈夫だが、各種サーバやネットワーク機器、負荷分散方法、バックアップ方法、障害時の対応方法はエンジニアの経験やノウハウに依存してしまう。

(3)システムのサイジングミス

システムのサイジングは、サイジングをするエンジニアの経験やノウハウに依存している。

適切なサイジングを行うには、同時接続数やCPUの使用率、ネットワークのスループット、データベース・アクセスなど、システムにかかる負荷の平均値や最大値を適切に見積もることである。

この場合、負荷の最大値(ピーク)がシステムの適切なサイズになるが、障害リスクを勘案してリスクヘッジするため、必要以上に大きなサイジングをしてしまう傾向がある。

大きすぎるサーバ、多すぎるサーバ数が提案され、提案価格が顧客の予算と合わない場合、営業担当者がエンジニアに「もっと少ないサーバ数でサイジングできないか」と相談しても、エンジニアの「安定稼働の保証できませんよ」という言葉に、何も言い返せなくなってしまう。

もちろん、ベンダー努力によって顧客予算に見合った(安定稼働できる)サイジングの機器提案ができればいいだろう。だが、多くの場合は顧客の予算に合わせるため、顧客と交渉してギリギリのサイジングをすることになる。結果的にこのような顧客とベンダーの取引がシステム・サイジングのミスを誘発する。

上記3つの障害発生理由のうち、(1)と(2)は、防止する仕組みはない。仕組みとして防止できるのは、(3)のサイジングミスである。

サイジングミスが発生する本質的理由

潤沢な予算がある企業や、予算について無頓着な企業では、システム障害はほとんど発生しない。障害発生の可能性があるのは、IT投資を最小限にして効率的な投資をする企業だ。

企業がITシステムを開発・構築する際に気にかけるポイントは、なるべく低予算でシステム構築を行い、ビジネスの目的を達成することである。これは企業としては当たり前のことだが、実はITシステム投資では、投資効率の最大化は簡単ではないのだ。

障害を避けたければ、潤沢な予算でシステム構築をするしかない。しかし、潤沢な予算でシステム構築をすると無駄な投資が増えてしまう。このトレードオフを解消しない限り、システム障害を根本的に防止することは難しい。

トレードオフを解決するのは最適バランス

このトレードオフを解決して、最適な投資規模でビジネスの目的を達成するために、米国で注目されているのが、パフォーマンス・マネジメントとキャパシティ・マネジメントである。

パフォーマンス・マネジメントとは、ビジネスの性能(ビジネス目標の達成具合や達成能力)とITシステム全体の性能を統合してマネジメントすること。キャパシティ・マネジメントとは、パフォーマンス・マネジメントを支えるITリソース(CPU、メモリ、ディスク容量など)のキャパシティ(容量)をマネジメントすることだ。つまり、ビジネス・パフォーマンスとITキャパシティをバランスよく両立させるマネジメントツールを使えば、システム障害を防止することができるというわけだ。

キャパシティ・マネジメントの方法

キャパシティ・マネジメントは、仮説構築、検証、データ分析の3フェーズで考える。

仮説構築フェーズでは、「性能要件の確定とシステムのワークロード(実行する処理の質や量の総計)の収集」と「性能要件からシステム・リソースの見積」を行う。検証フェーズでは「システム・リソースのパフォーマンスを評価」を行う。データ分析フェーズでは「システム監視による分析」を行う。

(1)性能要件の確定とシステムのワークロードの収集

性能要件はビジネス・パフォーマンスから算出されるもので、「毎分500件の処理件数を行う」とか「Webページの応答時間を2秒以内にする」という性能要件になる。このような性能要件はIT部門と合意することが多いが、本来はビジネス・パフォーマンスの責任部門である利用部門と合意すべき事項だ。

性能要件を確定した後にワークロードを想定する必要があるが、ワークロードとは、システムが実行する処理の種類や量の総計で、CPU負荷率やハードディスクへのアクセス、ネットワーク機器とのスループットなどである。これらをメトリクス(測定指標)として特定することが重要になってくる。

(2)性能要件からシステム・リソースを見積もる

各ベンダーが提示しているカタログ性能値を利用して最適なリソースの理論値を求める。次に経験値を利用する。経験値とは、過去に経験した同じようなシステムモデル、システム構成、システム規模において現在稼働中の性能結果から逆算して想定する。理論値に経験値を加えて性能要件を満たすシステム・リソースを見積もる。

(3)システム・リソースのパフォーマンスを評価

見積もったシステム・リソースを評価する必要がある。いくつかの評価手法があるが、シミュレーションは使い勝手がよい。シミュレーションとは、想定するトラフィック・モデルを作り出すプログラムで性能を予測することである。ここでは、(2)で算出した机上の数値を実際に測定することで、様々なトラフィック量を想定して実測することができる。

(4)システム監視による分析

最終的には、本番稼働しているシステムを監視して、実測データをログとして採取することである。実測データを使って分析することで、サイジングが正しかったのか否か、正しくなければどれほどのITリソースの追加が必要なのかを見極める必要がある。

KKDからKKDへ

システム・サイジングは「KKD: 経験、勘、度胸」では限界があり、「KKD: 仮説構築、検証、データ分析」という科学的なアプローチでサイジングできなれければシステム障害を防ぐことができない。

ビジネス・パフォーマンスのマネジメントと、ITリソースのキャパシティ・マネジメントを実施して、投資効率とシステム障害がトレードオフとならないよう、バランスの取れたマネジメントが必要となってくるのだ。

では実際、数多くの企業で行われているシステムのサイジングとはどのようなものなのか、次回でその実態と改善点を詳しく解説する。

執筆者紹介

寺澤 慎祐 (てらざわ しんすけ)

日本サイトラインシステムズ株式会社　シニアコンサルタント　兼　株式会社アイトップ　代表取締役

分析指向マーケティングとITマネジメントのスペシャリスト。サン・マイクロシステムズを退職後、企業向けにマーケティングマネジメントとITマネジメントのコンサルティングを行っている。光産業創成大学院大学においてB2Bマーケティングの講師も務める。