インフラエンジニア必読｜Webシステムのパフォーマンス設計ガイド【ハードウェア／構成設計編】

はじめに

近年、クラウドやマネージドサービスの普及により、「ITインフラはブラックボックス化し、インフラエンジニアの需要は減少する」と言われることがあります。しかし、私は必ずしもそうとは考えていません。特にパフォーマンス分野のエンジニアは、今後も必要とされ続ける職種です。なぜなら、どれだけ基盤が抽象化されても、システムの特性に応じたパフォーマンス設計とチューニングは不可欠だからです。

ただし、パフォーマンス設計は領域が広く難易度も高いため、体系的なベストプラクティスが見つかりにくいのが現状です。そこで本記事では、システム構成およびハードウェア観点のパフォーマンス設計について、実務経験をもとに整理したベストプラクティスをご紹介します。

本記事では、LinuxベースのWeb3層オンラインシステムを対象とし、パフォーマンス設計のベストプラクティスをご紹介します。システム性能を最大化するためには、単一の構成要素だけではなく、
システム全体を俯瞰し、あらゆるレイヤに配慮することが重要です。たとえば、ミドルウェアのチューニングが完璧でも、ネットワーク帯域不足やストレージI/O性能不足が原因でボトルネックが発生し、処理遅延につながることがあります。このように、パフォーマンスエンジニアにはサーバ・ネットワーク・ストレージ・仮想化基盤など多層的な知識が求められます。本記事では、まずシステムを構成する主要要素を以下の図に基づいて整理していきます。

Webシステムには、サーバ、ストレージ、端末、ネットワーク機器、ロードバランサ、ファイアウォールなど、さまざまなハードウェアが必要です。これらはCPU・メモリといったリソースだけでなく、機器構成や冗長化方式も含めて設計する必要があります。

特にオンプレミス環境では、ハードウェア選定を誤ると後から簡単に変更できません。性能不足が判明しても、追加コストや長期停止につながるケースがあります。そのため、初期設計の段階で慎重に検討することが非常に重要です。

システム構成

ハードウェアを選定する前に、まずシステム全体の構成を検討することが重要です。ここでは、一般的なWebシステムにおける物理構成と論理構成の例を示します。

物理構成図

概略図ですが、Webシステムを構成する物理構成の例を示します。ネットワーク機器、サーバ、ストレージで構成しています。
ネットワーク機器は要件に応じて他の機器に置き換えることも可能です。たとえばUTMを例として記載していますが、UTMは高価な製品である場合が多いため、コスト重視であれば一般的なファイアウォールを導入することも選択肢の一つです。

ここでは、物理構成を検討する際に注意すべきパフォーマンス観点を整理します。

1台故障時のパフォーマンスを考慮

物理機器は故障する可能性があるため、万一の障害時でも求められる性能を維持できるシステム構成にする必要があります。ネットワーク機器やサーバ機器については、冗長構成を組むことが推奨されます。

論議構成図

続いて、Webシステムの論理構成図の例を示します。
WebサーバはUTMとファイアウォールで挟む構成にしてDMZを構築しています。その後ろにはAPレイヤとDBレイヤが続き、一般的なWeb3層システムの構成となります。
WebサーバとAPサーバは仮想サーバとして構築していますが、DBサーバは物理サーバとして独立して構築するケースが多いです。
OSやデータは仮想・物理サーバともに共有ストレージに格納し、SANブートで起動するシステムを想定しています。

論理構成の検討においてパフォーマンス観点で気を付けるポイントを記載します。

1台故障時のパフォーマンスを考慮

物理機器と同様に、仮想サーバも故障してダウンする可能性があります。そのため、障害発生時でも求められる性能を維持できるシステム構成にすることが重要です。
上記の図では、WebサーバとAPサーバは3台、DBサーバは2台で冗長構成を取る設計としていますが、要件に応じて、各レイヤのサーバ台数を適切に設計してください。1台が故障して縮退運転になった場合でも、要件定義で決められたスループットを確保できるように設計する必要があります。

重要な機器はリソース共有しない

システムの根幹であるDBサーバはパフォーマンスのボトルネックになりやすいため、単独の物理サーバで構成することが多いです。仮想化により他のサーバとリソースを共有すると、トラブル発生時や想定以上の負荷がかかった場合にDBサーバの性能に影響する可能性があります。予算に余裕があれば、個別の物理サーバで構築することが推奨されます。

ハードウェア要素のパフォーマンス設計

サーバ機器選定・サイジング

サーバの筐体選定だけでなく、CPU、メモリ、ディスクなど複数のリソース要素を検討する必要があります。リソース量を見積もる代表的な方法は、主に次の2つです。

類似システムの情報を用いた見積り

類似の要件を処理しているシステムに関する情報が入手できる場合、それを基にサイジングするのが有効です。サーバや各部品のスペックが完全に同じではないため、100％正確な見積りはできませんが、ある程度妥当な見積りが可能です。

ベンチマーク手法に基づいた見積り

CPUについては、ベンチマークを参考にした見積りが一般的です。SPECと呼ばれるベンチマークデータが公開されており、様々な値があります。SPECint2017のBase Resultを基に見積る方法が広く用いられています。下記にサンプル情報を示します。

＜SPECのサイト＞
https://www.spec.org/cpu2017/results/

基本的にCPU使用率は負荷量に比例するため、負荷量の増分と新旧機器のSPECint2017の比率を用いて、必要なコア数を算出します。ただし、この計算はあくまで想定の見積りであり、実際の値とは異なる場合があります。
そのため、プロトタイプ検証環境を構築し、算出値を精査することが推奨されます。

積み上げによる見積り

メモリの見積り
サーバにインストールするソフトウェア製品が必要とするメモリを積み上げることで、ある程度の見積りを行うことが可能です。ただし、メモリ使用量は負荷量に比例するわけではないため、精緻な見積りは難しく、余裕を持ったサイジングが推奨されます。
CPUコアの場合はライセンス費用に関わることが多いため、簡単に増やす決断が難しいことがありますが、メモリはライセンス費用に影響しないことが多く、かつ比較的安価な部品であるため、積み上げで見積もったメモリサイズの約2倍程度の余裕を持った設計が推奨されます。
ディスクの見積り
ソフトウェアのインストールに必要な容量、保存が必要な業務データの総量、ログ出力量などを考慮して、ディスクサイズを見積もる必要があります。また、VMwareなどの仮想化環境を使用する場合は、仮想サーバのバックアップ用ディスクも考慮して見積もることが推奨されます。

サーバ機器のパフォーマンス設計

ハイパースレッディングの有効化

ハイパースレッディングとは、1つのプロセッサコアを疑似的に2つに見せる技術であり、1コアで並行して2つのスレッドを実行することが可能です。CPUの待ち時間を有効活用する技術のため、単純に2コアと同等にはならず、処理性能はおおむね20～30％向上することが一般的です。
ただし、以下のような場合には性能が劣化する可能性があるため注意が必要です。

計算効率が極端に高い場合
スレッドの負荷バランスが悪い場合
並行処理によるボトルネックが発生する場合

UEFIまたはBIOS設定から有効化・無効化を変更することが可能であり、適用を検討することが推奨されます。

ストレージ機器選定

IOPSを考慮した機器選定

あらかじめ各サーバのIOPSを計測する、あるいは見積もった上で、必要なIOPSを処理できるストレージを選定することが原則です。ただし、ストレージ機器が実際に出せるIOPSは使用条件によって変動するため、カタログ記載値をそのまま鵜呑みにすることは避ける必要があります。加えて、余裕を持たせた機器選定を行うことが推奨されます。

ディスク選定

DB更新など高い性能要件を持つデータに対しては、フラッシュストレージ（SSD）の導入を検討することが推奨されます。ただし、SSDは書き換え回数に限度があるため、長期間使用する場合は交換作業も見込んでおく必要があります。一方で、バックアップなど性能を必要としないデータには、安価なHDDを採用するという選択肢もあります。
キャッシュディスクによる性能向上は重要な要素であるため、適切な容量のキャッシュディスクを選択することが推奨されます。

ストレージ機器のパフォーマンス設計

RAID設計

RAIDとはRedundant Array of Inexpensive Disks の略で、複数のディスクをまとめて1つのディスクのように扱うことができる技術です。性能の観点では、主にストライピングという技術を用いることで、書き込み速度および読み込み速度を向上させることができます。RAIDにはいくつかの種類があり、非機能要件に応じて最適な方式を選定することが必要です。以下に例を示します。

データベースの業務データなど、オンライン処理において更新・参照するデータにはRAID10を適用することで、高い性能および信頼性を確保します。
バックアップや過去のログデータなど、オンライン処理に関係のないデータにはRAID5を適用することで、性能よりもコスト削減を重視します。

1つのRAIDグループを構成するために必要なディスクの推奨本数が決まっているため、データ総量が多い場合は複数のRAIDグループを作成するのが一般的です。それぞれのRAIDグループに対する書き込み量を見積もり、各グループの負荷がなるべく均等になるように設計することが推奨されます。また、I/Oの特性としてDB書き込みではランダムアクセス、バックアップではシーケンシャルアクセスが行われるため、異なるI/O特性を持つデータは別のRAIDグループに分けて配置することが推奨されます。

まとめ

本記事では、LinuxベースのWeb3層システムを対象に、ハードウェア観点でのパフォーマンス設計のベストプラクティスを紹介しました。

ポイント

システム全体を俯瞰して設計
- ミドルウェアだけでなく、サーバ・ネットワーク・ストレージなど全レイヤを考慮。
冗長化と重要機器のリソース分離
- 1台故障でも性能を維持できる冗長構成を採用。
- DBサーバなど重要機器は単独物理構成が望ましい。
サイジングは実績情報とベンチマークで精査
- CPUはSPECベンチマーク、メモリは積み上げ方式で見積もり、余裕を持たせる。
- プロトタイプ検証で調整することが重要。
ストレージ設計とRAID
- IOPSやSSD/HDDの使い分け、キャッシュディスクを活用。
- データ特性に応じてRAID方式とRAIDグループを分ける。