社内のインフラ設計で発注者が押さえておくべき重要ポイント【2024年最新版】

インフラを設計するときに一番大事なのは、インフラ上に展開されるサービスに対して「必要十分なキャパシティ」はどれくらいかを見積もることです。

例えば、鉄道会社が朝のラッシュアワーを解消しようとして連結車両を２倍に増設したり、東京大阪間の移動時間を短縮するために新幹線の平均時速を300キロに上げたりといった計画を実施したらどのようなことが起きるでしょうか？
２倍になった車両は駅のホームに収まりきらないので大混乱を引き起こしますし、レールの整備なしにいきなり時速300キロで新幹線を走らせたら、脱線事故にいたることは必至です。

逆に「大は小を兼ねる」という発想で、使いもしない巨大なインフラを構築してしまえばリソースの無駄遣いが生じます。
人口が衰退している地方公共団体で巨大なホールを作ったものの、実際にそれに見合った利用者がいないという状況がしばしば問題になっていますが、これと同じです。

この記事では、インフラシステム構築の当事者である発注者が知っておくべき、適切なインフラ設計を行うための基本的な技術や用語、ノウハウなどを整理したあとに、「必要十分なキャパシティ」を備えたインフラを構築する方法である「キャパシティ・プランニング」について解説します。

インフラ設計とは、業務で使う社内システムや顧客向けのwebサービスなどのアプリケーションを動かすための基盤部分の設計を指します。

具体的にはアプリケーションを問題なく動作させるために必要となるCPUのスペック・数、メモリー容量、データ入出力のスピードと安定性の確保などを行います。
また、実際にアプリケーションに直結した部分だけでなく、データを格納するストレージ領域の確保や増設の検討、ストレージ領域の拡張とデータ維持にあたっての堅牢性の維持や、アプリケーションが稼働したあとネットワークにボトルネックが生じないかのシミュレーションなども行います。

さらに、万が一メインサーバーがダウンしたケースに備え、どうやってサービスを最短時間で復旧させるかの計画などを立案することもインフラ設計の重要な仕事です。
もちろん個人情報保護や不正侵入、ウイルス対策などのセキュリティ対策も欠かせません。

このように整理すると、発注企業の担当者は新規に開発する業務システムやwebサービスの「アプリケーション部分」に専念し、インフラ整備などの裏方部分はシステム構築会社に丸投げしてしまえばよいのではないか…？という考えが出てきそうです。

しかし残念ながらそうした考え方では、インフラ設計は成功しません。
最初にその理由を確認しておきましょう。

インフラの設計を業者任せにできない最初の理由ですが、これはシステム構築会社のなかには、インフラを軽視している会社も存在するからです。
意外に思うかもしれませんが、アプリケーションを開発することがメインのシステム構築会社の場合、「重視すべきはアプリケーションのスペックであって、インフラは足りなければ追加すればよい」という考え方をしがちなのです。

インターネット関連のハードウェア機器が非常に高価だった時代は、限られたリソースの性能を最大限引き出すインフラ設計の重要性が認識されていました。
しかし、ハード機器の進歩は日進月歩で価格性能比は急速に向上しています。
したがって、足りなければ物理的なハードウェアを追加すれば問題ないだろう…と考えてしまうシステム構築会社はかなりあるということを肝に銘じておきましょう。

あとで触れますが「仮想化」や「クラウド化」といった、最新のシステム構築のトレンドに乗り遅れてしまっているシステム構築会社ほどこうした考え方を持っていますので、発注先を絞り込むときには注意が必要です。

２番目の理由として、オープン化が進展しITエンジニアの職域が拡大したことで役割の細分化が進み、アプリケーションの設計をしながら、インフラでどの程度までのスペックを想定すべきかを総合的に俯瞰できるエンジニアが減ってしまったという現状があります。

Windowsに強い○○さん、UNIXなら○○さん、というように製品やソリューションごとに専門意識が生まれ、「アプリケーション屋は、インフラのことまで分からない、知る必要もない」と考えるエンジニアも増えています。

本来は「このアプリケーションなら、既存のインフラのこの辺りにボトルネックが生じそうだから対策を立てなければならない」と考えるべきエンジニア自身がこうした狭い専門意識を持ってしまっているので、注意が必要です。

また、アプリケーション開発者にとって、システム基盤の動作が見えにくくなっていることも挙げられます。
システム基盤はサーバーやネットワーク、ストレージなどの「ハードウェア基盤」と、オペレーティングシステム、webサーバー、データベースサーバーなどのミドルウェアといった「ソフト基盤」で構成されています。
最近のシステム基盤は、このミドルウェア部分の領域が拡大しているため、ソフトウェア的なシステム基盤の部分の働きが見えにくくなってきているという現状があります。

ここまでは最近のシステム構築会社やエンジニアがインフラの知識が不足していたり、経験が追いついていなかったりというややネガティブな理由でしたが、インフラに関する知識があると見積もりが正確に判断できる、というメリットを最後に挙げたいと思います。

アプリケーションに関しては、詳細な機能やインタフェース部分にまで細かくタッチする発注担当者の方も多いのですが、インフラ部分に関しては業者の言いなりの金額でそのまま社内の稟議を通してしまうことが少なくありません。
アプリケーションの部分で詳細を詰めて当初予定していた予算より15%もコストダウンできたのに、インフラに関してはノーチェック状態で、世間の相場よりも15％高かったということでは、せっかくのコストダウンの努力も元も子もありません。

以上、システム構築会社にインフラ設計を丸投げしてはいけない理由を３つ整理しました。
では、システム構築会社にインフラ設計を丸投げできないとしたら、発注者はどうすべきでしょうか。

それは、発注者自身がアプリケーションの性能から必要十分なインフラを割り出すためのフレームワークである「キャパシティ・プランニング」の考え方を押さえ、キャパシティ・プランニングを実施してくれる信頼できるインフラ構築業者とシステム設計を行っていくことで解決できます。

キャパシティ・プランニングは、新規のシステム開発や既存システムの改修などの際に「必要十分」なインフラはどのような水準なのかを計測して、最適なインフラ計画づくりを支援するものです。

対象となる事業計画や業務要件、サービスレベル要求などからどれくらいのインフラを用意する必要があるのかを算定することが目的で、基本的な作業手順は次の３段階のステップに分かれます。

このようにキャパシティ・プランニングとは、最初に既存のインフラ環境の情報を把握し、アプリケーションを載せるために必要なインフラのスペックを客観的に決定していくプロセスです。

では、具体的にどのような作業が実施されるのか、詳しく見てみましょう。

ワークロードの収集は最初に、IT担当者や実際インフラを利用している部門のヒアリングから始まります。
いきなりツールなどを使ってネットワーク状況を測定したりはせず、現在行っている業務の種類や処理量・頻度、さらに現状の課題、理想として実現すべき処理時間などをヒアリングから想定します。

その後実際に調査に入り、処理ピーク時のトラフィック状況や通常時の毎秒当たりの処理件数、１件当たりのデータサイズ、それぞれの処理における許容時間を満たしているかどうかなどの情報を収集します。

例えば受発注システムでのトランザクション処理ならば「トランザクション1件当たりの処理時間を１秒以内に収められているか」、ビッグデータ分析であれば、「毎秒1,000件のトランザクション処理をこなせているか」などになります。
実態を把握したあとで、インフラに必要な性能要件を割り出します。
必要な調査項目としては下記のようになります。

性能要件をベースとして、システムの具体的な構成を決定するのが「サイジング」です。
サイジングは個々のスペックを詳細に検討することで客観的に必要な性能を明らかにします。

必要なスペックが決定できたら、今度はそのスペックが本当に必要十分であるかを検証します。
検証手法には大きく分けて「静的積算」「シミュレーション」「プロトタイピング」があります。

■ 静的積算
「静的積算」とはハードウェアの性能を元に処理時間を計算する方法です。
静的積算はハードウェアの性能という分かりやすい指標を元にするので、目安として必要スペックを評価するには有効ですが、精度はそれほど高くありません。

■ シミュレーション
「シミュレーション」では、ハードウェアの性能だけで評価することなく、実際に発生する処理の種類と量を考慮した処理プログラムを作って性能を検証します。
処理プログラムを作る時間と手間がかかりますが、一度作ってしまえばパラメーターを変更するだけで多種多様な検証が可能です。

■ プロトタイピング
「静的積算」や「シミュレーション」は、ハードウェア機器やシミュレーション用のソフトウェアを使って性能を検証する手法ですが、「プロトタイピング」ではシミュレーションで作ったソフトウェアを本番環境で動作させて実測値を計測します。
手間とコストがかかるものの本番環境での正確な検証データが得られるというメリットがあります。

以上、必要なインフラを客観的に割り出していく「キャパシティ・プランニング」の基本について整理しました。
このキャパシティ・プランニングの流れを知って、システム構築会社に必要十分なインフラ設計を依頼すれば、コストパフォーマンスに優れた問題のないインフラを設計してもらうことができます。

ただし、すべてのシステム構築会社がこうしたキャパシティ・プランニングを実施できる経験やノウハウを持っているわけではないことに注意しましょう。

特に最近のインフラ構築では欠かせないトレンドである「仮想化」と「クラウド化」においてキャパシティ・プランニングをきちんと実施できるシステム構築会社はそれほど多くありません。
そうした優良業者を見つけるためにも、次に「仮想化」と「クラウド化」においてキャパシティ・プランニングはどのように実施されるのかの基礎を押さえておきましょう。

仮想化とは、CPU、メモリー、HDDなどのサーバーマシンのハードウェアリソースや、点在するストレージ、ネットワーク機器のMACアドレスやIPアドレスを、物理的な構成にとらわれずにソフトウェア的統合したり再分割したりすることができる技術です。

仮想化技術を使えばハードウェア機器の使っていない部分を有効活用することができるので、限られたリソースのコストパフォーマンスを最大化することを目的とするインフラ構築に大きなメリットを及ぼします。

実際に仮想化を利用してコストパフォーマンスの良いインフラ構築をしたいと考えた際に、「既存インフラは仮想化環境でも問題なく動作するのか」「１台のサーバーにどのぐらい仮想サーバーを立てることができるのか」、などのキャパシティ・プランニングが重要になってきます。

まず対象となるサーバーを把握することが、仮想化によるサーバー統合計画を遂行する上で重要です。
ただし、全社規模でサーバー統合を実施する場合、各部門に導入されているサーバーの情報を収集するのは非常に大変です。

仮想化技術とは、もともと物理的に制約のあるハードウェア機器を拡張して使う技術なので、仮想サーバーを設計したり、現在のインフラを仮想化環境に移行したりする場合には、物理的なハード機器のキャパシティ・プランニングを実施するときよりも、調査の規模が拡大し内容も複雑になります。

また、情報を収集したあと「１台の物理サーバーにいったいどのぐらいの仮想サーバーを作っていいのか」「仮想サーバーの組み合わせは適切なのかどうか」などの「性能要件」を決定したり、性能要件を元に「サイジング」「評価・チューニング」を進めたりしていく際にも物理的なハードウェアのキャパシティ・プランニングよりも高度な判断が求められます。

仮想化におけるキャパシティ・プランニングにおいてもCPUの種類、スペック、搭載数、そしてメモリー量やディスク容量などといったインベントリ情報に加えて、CPU使用率、メモリー使用量、ページング数、ディスクやネットワークのI/Oパフォーマンスといった、稼働しているサーバーの性能を丁寧に採取していくことになります。

ただし、先程指摘したように仮想化技術で物理的なハードウェアの限界を超えてシステムを拡張させているので、上記のような調査を仮想サービスの数だけ想定して実施しなければなりません。

また、性能情報は一度だけ集めればよいというわけではなく、ある一定期間続けて閑散期や繁忙期など業務のピークの上下に合わせて採取するのが理想です。
このような作業を、仮想サービスの数だけ100サービス、1,000サービスといった規模で実施するのは、困難であると言えるでしょう。

そうしたときに便利なのが、ツールの導入です。
著名なキャパシティ・プランニング用のツールとしては下記のようなものがあります。

■ VMware「Capacity Planner」
公式サイト

■ Novell「PlateSpin Recon」
公式サイト

■ Microsoft「Assessment and Planning Toolkit（MAP）」
公式サイト

これらのツールは仮想化技術を採用した際のキャパシティ・プランニング実施を想定しており、基本的には既存サーバーに手を加えることなくソフトウェア的に情報を収集できます。
こうしたツールで実際にキャパシティ・プランニングの情報収集を行ってみるのもよいですし、こうしたツールを使って効率よく安価に仮想化技術でのキャパシティ・プランニングを実施してくれる業者を探してみるのもよいでしょう。

ここまでキャパシティ・プランニングの重要性を指摘してきましたが、クラウドサービスを使えば、キャパシティ・プランニングを意識することなく、必要に応じてインフラをスケールすることが可能です。

クラウドサービスでは、ネットワーク経由でインフラなどのサービスを提供しますが、サービスを利用中にもっとインフラをスケールアップしたい、想定していたよりもトラフィックが少ないのでインフラをスケールダウンしたいということが、管理画面から簡単にできます。

クラウドサービスは大きくパブリッククラウドとプライベートクラウドに分けられます。

パブリッククラウドはAmazon Web Service（AWS）などのように、あらかじめ必要なインフラ機能を使いやすい管理画面から集中管理できるように構成しています。
主にサーバーやストレージ、ネットワークなどの基盤部分のインフラを提供するIaaS のほか、webサーバーやデータベースサーバーなどのミドルウェアを含めて提供するPaaSなどがあります。
もうひとつのSaaSについては、ソフトウェアの提供まで行いますので、インフラ構築の選択肢としては除外してよいでしょう。

プライベートクラウドとは、企業がクラウド環境を自分たちで構築し、社内の各部署やグループ会社に提供するサービス形態です。
クラウドと言うと、AWSのようなパブリッククラウドのみを想像する方もいると思いますが、クラウドの便利なスケール機能などを自社で実装して所有することで、より柔軟性の高いサービスを構築することが可能です。

パブリッククラウドについては、あらかじめインフラ設計が完了された状態で提供されているので、導入速度の速さにメリットがあります。
一方でセキュリティポリシーの遵守など、クラウドサービス提供者の規約に従う必要があります。

ここではプライベートクラウドについて、解説を加えます。
パブリッククラウドについては、アイミツまとめのこちらの記事なども参照してください。

自社で柔軟にインフラ設計のできるプライベートクラウドは、ホスティングタイプとオンプレミスタイプに分かれます。
以下、特徴を見ていきましょう。

「ホスティング型プライベートクラウド」は、インフラの設計や構築などはすべて自社で行うものの、データセンターなどのホスティング事業者のスペースにクラウドシステムを設置します。

ホスティング型プライベートクラウドは、パブリッククラウドとオンプレミス型プライベートクラウドの中間に位置します。
自社でまったくタッチすることのないインフラ部分に関しては設計や運用を提供事業者に完全に任せられるとともに、自社独自の要件をインフラに反映できる点で、パブリッククラウドより使い勝手が良いという特徴があります。
パブリッククラウドに比べると費用的には高くなるものの、完全なオンプレミス型プライベートクラウドと比較すると導入速度の速さや運用コストの低減といった点がメリットとなります。

「オンプレミス型プライベートクラウド」はインフラの設計や構築などを自社で行うことはもちろん、設置場所も自社内になります。

オンプレミス型プライベートクラウドでは自社内にシステムを設置するため、外部からのアクセスを完全になくすことができます。
インターネットにつなげなければ、高価なファイヤーウォールを設置することもなく、特別なセキュリティ対策も必要ありません。
社内で完結することが決まっているならば、最もセキュリティレベルが高く、セキュリティ対策のランニングコストは安い手法と言えます。
また、自社独自の機能要件を自由に設定できるため、設計の柔軟性が高い点がメリットです。

また、サービスによってこれらを混在させる場合もあります。
企業機密を取り扱うデータベースサーバーは、オンプレミス型プライベートクラウドで構築し、webサービスなどはホスティング型クラウドで展開するといった、用途や目的によってクラウドの形態を組み合わせる場合は「ハイブリッド型プライベートクラウド」と呼ばれます。

実際の導入件数が最も多いのはこのハイブリッド型プライベートクラウドです。
年間を通じてサービスを途切れなく提供する部分はオンプレミス型で構築して、繁忙期や特定のキャンペーン時のみパブリッククラウドを利用するという方法も便利です。

以上見てきたように、自社の運用形態に最適なクラウドサービスを選択してインフラ管理をすることで、柔軟なスケール（アップ/ダウン）をはじめとした、クラウドならではのインフラ設計メリットを享受することが可能です。

キャパシティ・プランニングを実施することで、必要十分な機能要件を客観的に割り出せることが分かりました。
ここまでで機能的な部分の設計は十分と言えますが、最後に「非機能要件」にきちんと目を配って、インフラ設計を完成させましょう。

システム基盤を設計・構築する際の仕上げとして忘れてはならないのが、システムが実現すべき機能やサービス以外のシステムが確保すべき品質を指す「非機能要件」です。
インフラ構築における非機能要件のポイントは、次の５つとなります。

「機能要件」については、キャパシティ・プランニングを使いながら詳細を明らかにし、「非機能要件」については上記５ポイントをチェックすることで、質の高いインフラ設計が可能になりますので、ぜひ参考にしてください。

最後に、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

以上、社内のインフラ設計で発注者が押さえておくべき重要ポイントについてまとめました。
インフラ設計は主役であるアプリケーションの開発の陰に隠れて、ついつい後回しになりがちな部分ですが、インフラ設計のパフォーマンスを上げればコストダウンや業務効率化などに直結します。

また、最近のインフラ構築のトレンドである「仮想化」や「クラウド化」を導入するにしても、基本となる重要な部分に関しては発注側企業がきちんとその本質を押さえていないと、こうした技術に対応できるシステム構築会社を見つけることは難しいでしょう。

とはいえ、インターネット回線を引いて、最低限のサーバーセッテイングだけを行ういわゆるインフラ屋ではなく、自社のインフラのコストパフォーマンスを最大化してくれるような戦略的なインフラ設計を行ってくれる会社を見つけ出すことは時間と手間もかかります。

そんなときはぜひ「アイミツ」にお声をかけてください。
貴社のインフラ設計の課題解決に最適な会社を複数ピックアップいたします。