LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

キャパシティプランニングと性能設計とは何か

キャパシティプランニングと性能設計の外注とは、システムが将来の利用量・データ量の増加に耐えられるよう、処理能力の余裕度と応答性能を事前に見積もり、設計段階で仕組み化する作業を、専門知見を持つ外部パートナーに委ねる取り組みを指します。IPA（情報処理推進機構）の非機能要求グレードでは、この領域は6つの大項目のうち「性能・拡張性」に該当し、レスポンスタイムなどの性能目標値と、将来の業務量増加に備えるリソース拡張性の両方を扱う項目として整理されています^*1。

非機能要求グレードは、性能・拡張性のほかに可用性・運用保守性・移行性・セキュリティ・システム環境／エコロジーを含む6大項目で非機能要件を体系化しています^*1。本記事が扱うキャパシティプランニングと性能設計は、このうち性能・拡張性の中でも「性能目標値（レスポンスタイム・スループット）」と「リソース拡張性（CPU・メモリ・ディスクの拡張余地）」の2領域を、要件定義〜設計段階でどう詰めるかという工程に焦点を当てます。

AWS（Amazon Web Services）が提示するWell-Architected Frameworkでも、性能に関する柱は「Performance Efficiency（性能効率）」として独立して定義されています^*2。この柱は「クラウドリソースを効率的に使い、需要の変化や技術の進化に応じてその効率を維持する能力」と説明され、アーキテクチャ選定・コンピューティングとハードウェア・データ管理・ネットワーキング・プロセスと文化という5つのベストプラクティス領域で構成されています^*2。設計段階でのキャパシティプランニングは、この中でもアーキテクチャ選定とコンピューティング領域に直結する工程です。

レスポンスタイム・スループット・同時接続数——性能目標値の決め方

性能設計の第一歩は、非機能要求として何を「性能目標値」に置くかを数値で定義することです。非機能要求グレードの性能目標値には、オンラインレスポンスとオンラインスループットという2つの中項目があります^*1。オンラインレスポンスは通常時・ピーク時・縮退時（一部機能停止時）それぞれのレスポンス順守率を段階的に定義する項目で、オンラインスループットは同様に3つの状況下での処理余裕率を定義する項目です^*1。

ここで実務上重要になるのが、目標値の書き方です。「レスポンス2秒以下」という表現だけでは、性能設計の判断基準として不十分です。非機能要求グレードの考え方に沿えば、パーセンタイル（%ile）を添えて「レスポンス2秒以下（90%ile）」のように、全体のうち何割がその基準を満たせばよいかまで明示する必要があります^*1。この基準がないと、外注先が想定する「達成すべき性能」の水準が発注側と一致しないまま設計が進むリスクがあります。

同時接続数（同時アクセス数）についても同様に、平均的な利用状況ではなく、業務特性ごとの分布を踏まえて設定する必要があります。参照系（検索・一覧表示）・更新系（登録・変更）・バッチ系など、処理特性が異なる機能をひとまとめにして目標値を決めると、実際のピーク帯で想定外の遅延が生じる原因になります。データ増加についても、現在のデータ量だけでなく、将来のレコード数増加によってインデックス構造や検索性能がどう変化するかを、設計段階で見込んでおくことが求められます。

ピーク見積り・余裕率・成長予測——容量計画の3要素

性能目標値を定めたあとの容量計画（キャパシティプランニング）では、ピーク見積り・余裕率・成長予測という3つの要素を組み合わせて必要なリソース量を導きます。非機能要求グレードのオンラインスループットの項目では、通常時・ピーク時・縮退時それぞれに対して「処理余裕率」を段階的に設定する仕組みが用意されています^*1。余裕率とは、想定されるピーク時の処理量に対してどれだけの予備能力を確保するかを表す指標です。

ピーク見積りで見落としやすいのが、単位時間の取り方です。1時間平均のアクセス数と1分平均のアクセス数では、実際にシステムへかかる負荷の大きさが異なります。アクセスが時間内で均等に発生するとは限らず、特定の数分間に集中する場合、その集中区間を基準に容量を見積もる必要があります。年末年始のセール、月初の一括処理、キャンペーン開始直後のアクセス集中など、業務特有のピーク要因を洗い出すことが、容量計画の精度を左右します。

成長予測についても、事業計画上の利用者数・データ量の伸びをそのまま容量計画に反映する工程が欠かせません。非機能要求グレードのリソース拡張性の項目でも「将来の業務量の増加に備えてどれだけ余裕を持たせるか」という観点が、CPU・メモリ・ディスクそれぞれの拡張性の段階として定義されています^*1。事業側の成長シナリオが変わった場合、性能目標値と容量計画も見直しの対象になる前提で設計しておくことが実務上の要点です。

スケールアップ・スケールアウト・オートスケール——増強手段の選び方

容量計画で見積もった必要リソース量を、実際にどう確保するかを決めるのが増強手段の設計です。非機能要求グレードのリソース拡張性の項目には、CPU拡張性・メモリ拡張性・ディスク拡張性に加えて、サーバ処理能力を増強する手段としてスケールアップ対応とスケールアウト対応が定義されています^*1。スケールアップは1台のサーバの性能（CPU・メモリ）を高める方式、スケールアウトはサーバの台数を増やして処理を分散する方式です。

クラウド環境では、需要に応じてリソースを自動的に増減させるオートスケールという手段も選択肢に入ります。AWS Well-Architected Frameworkの性能効率の柱は、需要の変化に応じて効率を維持する能力を重視しており、負荷の変動が大きいワークロードでは、固定的なリソース確保よりも需要追従型の構成が性能効率の観点で有利になりやすいと位置づけられています^*2。ただし、どの増強手段を選ぶかは、システムの特性（状態を保持するか、データベースのように垂直分割が難しい構成か等）によって最適解が変わるため、一律にスケールアウトやオートスケールが正しいとは言えません。

増強手段の選択を誤ると、想定した性能が得られないだけでなく、余分なコストや構成変更の手戻りが発生する可能性があります。特に、スケールアウトを前提に設計していたシステムが、実装段階で状態管理の都合上スケールアップしか選べないと判明するケースは、要件定義段階でアプリケーション構成の前提を詰め切れていないと起こりやすい失敗です。設計段階でアプリケーション側の制約とインフラ側の増強手段を突き合わせておく作業が欠かせません。

ボトルネック特定と性能試験の関係——設計と検証の分業

キャパシティプランニングと性能設計は「設計段階でどう見積もり、どう構成するか」を扱う工程であり、実際に性能が目標値を満たすかを確認する性能試験（負荷テスト）とは別の工程です。設計段階の見積りには前提の誤差が伴うため、性能試験によって実測値との差を検証し、ボトルネックとなっている箇所（データベースの特定クエリ、ネットワーク帯域、アプリケーションの排他制御など）を特定する工程が後続で必要になります。

この2つの工程を混同すると、設計段階の見積りが実態と合っているかを確認せずにリリースしてしまうリスクがあります。反対に、性能試験だけを実施して設計段階の余裕率設定を見直さないと、次回の負荷増大時に同じ問題が再発する可能性があります。AWS Well-Architected Frameworkの性能効率の柱でも、選択した構成を定期的に見直すレビューと、期待した性能からの逸脱を把握するモニタリングの両方を、性能効率を維持するための要素として位置づけています^*2。設計・見積り・試験・モニタリングを一連の工程として回す前提を、外注の要件定義段階で共有しておくことが望まれます。

内製でこの工程を完結させる場合、非機能要求グレードの項目定義を読み解いて自社の業務特性に翻訳するスキル、クラウド各社のスケーリング機能の特性理解、負荷モデルを組み立てる分析スキルの3つが同時に必要になります。これらを兼ね備えた人材を確保できない場合、性能目標値の設定が曖昧なまま設計が進み、リリース後に想定外の遅延やタイムアウトが発生してから対応に追われる状況に陥りやすくなります。

外注する場合の委託範囲——どこまでを依頼できるか

キャパシティプランニングと性能設計を外注する場合、委託範囲は大きく3段階に分けて整理できます。第一に、非機能要求のヒアリングと数値化（レスポンスタイム・スループット・同時接続数を業務特性ごとに定義する工程）です。第二に、ピーク見積り・余裕率・成長予測を反映した容量計画と、スケールアップ／アウト・オートスケールを含む構成設計です。第三に、設計内容をインフラ構成やアプリケーション設計書に落とし込み、後続の性能試験フェーズに引き渡すための仕様化です。

これらのうち、どこまでを外注に委ねるかは、発注側の体制によって変わります。非機能要件のヒアリングだけを外部の専門家に依頼し、構成設計は内製で行う切り方もあれば、要件定義から構成設計・仕様化までを一括して委託する切り方もあります。委託範囲を曖昧にしたまま契約すると、「性能目標値は決めたが、それを満たす構成の妥当性検証は誰が担うのか」といった責任分担の空白が生じやすいため、契約前に工程単位で担当を明確にしておく必要があります。

発注側の準備——外注を機能させるために必要な情報

外注先が精度の高いキャパシティプランニングと性能設計を行うには、発注側が事前に用意すべき情報があります。まず、現状のアクセス実績データ（時間帯別・曜日別のアクセス数、既存システムがあればその処理時間分布）です。新規システムで実績データがない場合は、類似業務の想定値や事業計画上の利用者数見込みを整理しておく必要があります。

次に、業務特性ごとの重要度です。参照系と更新系のどちらの性能を優先するか、縮退時（一部機能が停止した状態）にどこまでの性能を維持すべきかは、業務を理解している発注側でなければ判断できません。外注先に丸ごと委ねるのではなく、性能目標値の「達成すべき水準」を最終的に承認する役割は発注側に残ります。

さらに、将来の成長シナリオに関する情報も欠かせません。利用者数やデータ量が今後どの程度のペースで増加する見込みかは、事業側の計画に基づく情報であり、外注先が独自に推測できるものではありません。この情報が共有されないまま容量計画が進むと、余裕率の設定が過大または過小になり、後になって構成の見直しが必要になる可能性があります。事業計画の変更が生じた際は、性能目標値と容量計画を再確認する機会を契約時にあらかじめ組み込んでおくと、見直しの機会を逃しにくくなります。

まとめ：キャパシティプランニング外注で押さえる3つの判断軸

本稿では、キャパシティプランニングと性能設計を外注する際に押さえるべき考え方を整理しました。要点を3つに集約すると次の通りです。第一に、性能目標値はパーセンタイルを添えて業務特性ごとに数値化することが前提になります。第二に、容量計画はピーク見積り・余裕率・成長予測の3要素を組み合わせ、スケールアップ／アウト・オートスケールのどれが自社システムの構成に適合するかを見極める必要があります。第三に、外注の委託範囲を工程単位で明確にし、事業計画データの提供や性能目標値の承認など発注側に残る役割を契約前に確認することが、外注を機能させる条件になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：独立行政法人情報処理推進機構（IPA）「非機能要求グレード」性能・拡張性（性能目標値・リソース拡張性の項目定義）（https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html）
2. *2　出典：Amazon Web Services「AWS Well-Architected Framework – Performance Efficiency Pillar」（https://docs.aws.amazon.com/wellarchitected/latest/framework/performance-efficiency.html）

Tweet