はじめに
オンプレミス環境やAWSなどのクラウド上でWebアプリケーションを導入する場合、どちらにおいても、どの程度のスペックのサーバー(サービス)を用意すればよいか、スペックの見積もりを求められます。
また、お客様によっては、このスペックで問題ないと言う根拠を示すよう求められる場合もあります。
とは言え、根拠と言われると中々説明に苦しむ事も多く、場合によっては、JMeterなどを利用して負荷テストを行い、問題ない事を証明するよう求められる場合もあります(JMeterによる負荷テストで問題ない事を示すのも難しかったりしますが)。
サーバースペックの見積もりを、その根拠についても合わせて求められた場合に、どのように見積もりをしたらよいか、その考え方についてまとめてみたいと思います。
前提
サーバーサイジングを行う対象のシステムは、Webサーバー(Apache)、APサーバー(Tomcat)、DBサーバー(Oracle)で構成される、シンプルなWebアプリケーション(Java)を想定しています。
一番大切な事
はじめに、サーバースペック見積もりにおいて、一番重要なポイントを記載すると、サーバー上で動作するWebアプリケーションのパフォーマンス特性を把握する事です。
パフォーマンス特性を把握するには、社内にパフォーマンス検証用の環境(データ量が十分にある必要あり)を用意し、CPUコア数、メモリ、JVMのヒープサイズ、Web/APサーバー台数など変更した場合にどうなるかを検証する。
それと並行して、Webアプリケーションの利用に特徴(利用ユーザー数、利用年数、利用している機能、製品、データサイズが大きいなど)がある、お客様本番環境のシステム構成とパフォーマンスログ(OSのパフォーマンスログ、Apacheのアクセスログ、GCログ、OracleのStatspackレポートなど)をいくつか収集して分析を行い、実際の実力値を見極めます。
パッケージ製品の導入し始めやSaaS提供を開始したばかりの段階では、社内でのパフォーマンス検証や、社内本番環境でのパフォーマンス状況を根拠にするしかありませんが、ある程度Webアプリケーションの導入が進んできたら、お客様本番環境での実力値を知る事で、より正確にスペック見積もりができるようになります。
社内でのパフォーマンス(負荷)検証
社内でのパフォーマンス検証は、Webアプリケーションのパフォーマンス特性を把握するための検証と、製品(Webアプリケーション)のバージョンの違いや、OS、ミドルウェアのバージョンの違いによる差異を確認するための検証を行います。
どちらの検証も、データ量が十分にある検証用の環境を用意し、パフォーマンス計測は、計測毎に同じデータ量での測定になるよう(計測前にデータを共通の検証用データの状態に戻す)にする必要があります。
また、パフォーマンス計測を行うシナリオも同じものを使うようにします。
パフォーマンス計測は、JMeterなどを利用して行い、スレッド数の変動により、スループットやレスポンスタイムがどのように変動するかや、計測中のCPU使用率、メモリ、ロードアベレージなどのOSパフォーマンスログやミドルウェアのログ(Apacheのアクセスログ、GCログ、OracleのStatspackレポートなど)を取得して、パフォーマンスの差異とパフォーマンス悪化のボトルネックが何かを確認します。
負荷検証環境のサーバースペックは、あまり高すぎないものにします(スペックが高すぎると負荷が中々かからず、ボトルネックが何か把握しにくい場合があるため)。
また、CPUコア数やメモリを変動させて検証する事があるので、AWS、Azure、OCIなどのクラウド環境や社内の仮想環境で検証するのがよいと思います。
サーバースペックは、お客様本番環境で利用する最小スペック想定のものとするのがお勧めです(Web/APサーバーは、CPUコア数4、メモリ8GB、ディスク容量300GB、DBサーバーは、CPUコア数4、メモリ8GB、ディスク容量300GBなど)。
物理サーバーとAWSなどのクラウド環境とでは、動作するWebアプリケーションにもよりますが、同じサーバースペックでは、物理サーバーの方が速い(場合によっては、1～3割)傾向があります。
JMeterなどで、実際に大勢の人が操作しているのに近い負荷状況を再現するのは、非常に難しいものです。スレッド数、ランプアップ期間、ループ回数、タイマー設定などを調整しつつ、テストシナリオも含め、最適なものを見極める必要がありますが、詳細はこの記事では書ききれないため、割愛します。
本記事では、スレッド数の増減により、最適な負荷状況が確認できる前提で、これ以降の記事を記載します。
Webアプリケーションのパフォーマンス特性を把握するための検証
パフォーマンス特性を把握する検証にも、以下のような目的があり、それぞれ検証内容も変わります。
なお、パフォーマンス計測に利用するデータとWebアプリケーションのバージョンは固定して検証を行います。
【目的1】最小構成での処理限界値を確認する
検証環境のサーバー構成およびスペックを最小想定のもの(Web/APサーバー1台、DBサーバー1台、各サーバーのスペックは、CPUコア数4、メモリ8GB、ディスク容量300GBなど)で固定し、徐々に負荷を上げていった場合の処理限界値を確認します。
- 検証方法
- 同じスレッド数で3～5回程度測定を行う
- スレッド数を10、20、30・・・のように増やしていき(必要に応じてランプアップ期間も調整)、各スレッド毎のスループット上限値とレスポンスタイム(平均または90%Line)を確認する
- スレッド数を増やしていき、エラーが発生(HTTPステータス503など)したり、平均または90%Lineのレスポンスタイムが閾値(3秒など)を超える、もしくはスレッド毎のスループットグラフが限界を超えたスレッド数とスループット=限界スループットを確認する
限界スループットの確認方法については、以下の記事が参考になると思います。
この検証の結果得られた限界スループット(Transaction Per Second)が、最小構成、スペックの環境で捌ける、秒間リクエスト数の上限とみなす事ができます。
また、この検証結果が、その後の検証およびスペック(CPUコア数、Web/APサーバー台数)見積もりの際のベースラインになります。
営業さんなどから、新規のお客様向けに、「何名利用想定の場合、どの程度のスペックのサーバーを何台用意すればよいか。」といった漠然としたスペック見積もり依頼をされる事があると思います。
その場合、Web/APサーバーの台数については、利用ユーザー数の何%が1秒の間に同時に操作するかを想定して標準スペックおよび構成を用意しておくとよいと思います。
例えば、1000名利用想定で、利用ユーザー数の最大5%が秒間同時アクセスする想定の場合、秒間50リクエストを捌く事ができる処理性能が必要になります。
この場合、負荷テストにより得られた、最小サーバー構成、スペックでの限界スループット(≒限界秒間リクエスト数)が30であった場合は、Web/APサーバーの台数は2台必要になるでしょうし、限界スループットが70であった場合は、1台で問題ないといった判断ができるようになります。
ここまでは社内負荷検証結果に基づくものになりますが、後述する、スペック変動に伴うパフォーマンス特性の変化や、お客様本番環境のサーバー構成、スペックでの最大秒間リクエスト数を多く収集して、実環境での実力値が分かるようになると、上記のような判断がより正確にできるようになります。
限界スループットとは別に、可能であれば取得しておきたいのが、Oracleのデータベースバッファキャッシュに、実データの何%程度がキャッシュされているかです。
OLTPシステムでは、データベースバッファキャッシュには、よく参照される直近のデータがキャッシュされるものと思います(履歴を参照するような処理やバッチ処理などは除く)。
この比率がどの位になっていると、パフォーマンスが良好な状態を保てるかが把握できると、DBのメモリ見積もりがしやすくなります(計測が難しいため、見積もり時に推測で設定する事が多いですが)。
【参考】データベースバッファキャッシュに何のオブジェクトがどの位キャッシュされているか確認するSQL
set line 300 pages 50000
col object_name for a30
col OWNER for a15
col OBJNAME for a50
col OBJTYPE for a10
SET NUMWIDTH 13
set colsep ';'
spool buffer_cache.txt
SELECT
s.owner owner,
object_name objname,
substr(object_type, 1, 10) objtype,
buffer.status status,
s.blocks * ts.block_size TOTAL_BYTES,
buffer.blocks * ts.block_size CACHE_BYTES,
(buffer.blocks / decode(s.blocks, 0,.001, s.blocks)) * 100 CACHE_PERCENT,
trunc((s.blocks * ts.block_size / 1024 / 1024)) "TOTAL_MB(TRUNC)",
trunc(buffer.blocks * ts.block_size / 1024 / 1024) "CACHE_MB(TRUNC)",
trunc((buffer.blocks / decode(s.blocks, 0,.001, s.blocks)) * 100) "CACHE_PERCENT(TRUNC)"
FROM
(
SELECT
o.owner,
o.object_name,
o.subobject_name,
o.object_type object_type,
bh.status,
count(*) blocks
FROM
dba_objects o,
v$bh bh
WHERE
o.object_id = bh.objd
AND o.owner NOT IN('SYS', 'SYSTEM')
GROUP BY
o.owner,
o.object_name,
o.subobject_name,
o.object_type,
bh.status
) buffer,
dba_segments s,
dba_tablespaces ts
WHERE
s.tablespace_name = ts.tablespace_name
AND s.owner = buffer.owner
AND s.segment_name = buffer.object_name
AND s.SEGMENT_TYPE = buffer.object_type
AND (
s.PARTITION_NAME = buffer.subobject_name
OR buffer.subobject_name IS NULL
)
order by
s.owner,
object_name
;
spool off
【目的2】サーバースペックを変動させた場合のパフォーマンス挙動の変化を確認する
ベースラインとなるパフォーマンス特性について確認できたら、サーバースペックや構成の変化により、パフォーマンスがどのように変化するのかを確認します。
検証内容は【目的1】で行ったものと同じですが、例えば以下のようにスペックや構成を変動させた時に、限界スループットがどのように変動するかを確認します。
- Web/APサーバーのCPUコア数を2倍に増やした場合の処理限界値を確認する
- Web/APサーバーのCPUコア数を元に戻し、メモリとヒープサイズを増やしていった場合の処理限界値の推移を確認する(ヒープサイズを増やす事で、パフォーマンスにどう影響するかを確認する)
- Web/APサーバーのCPUコア数、メモリを元に戻し、DBサーバーのメモリとSGAサイズを増やした場合の処理限界値の推移を確認する(SGAのサイズを増やす事で、パフォーマンスにどう影響するかを確認する)
- Web/APサーバーからDBへのコネクションプールのサイズを増やした場合の処理限界値の推移を確認する
- Web/APサーバー、DBサーバーのCPUコア数、メモリを元に戻し、ロードバランサーを用意し、Web/APサーバーの台数を2台にした場合の処理限界値を確認する
など
上記のような検証を行う事で、どのサーバーのスペック(メモリ割り当て)を変動させる事で、限界スループットがどのように変動するかを確認する事ができます。
一般的には、DBサーバーの処理がボトルネックになっていない場合、Web/APサーバーの台数を増やす事で、スループットも2倍程度になります。また、台数は変動させず、CPUコア数を増やす事で、台数を増やすほどの効果は無いかもしれませんが、スループットが改善する可能性があります。
しかし、DBサーバーでの処理がボトルネックになりやすいシステムでは、Web/APサーバーの台数を増やしても、かえってDBサーバーの負荷が高くなり、システム全体のパフォーマンスが落ちてしまいます。
このような場合は、Web/APサーバーの台数を増やすより、DBサーバーのメモリとSGAを増やした方が、パフォーマンスがよくなる可能性があるのですが、このような検証を行い、Webアプリケーションのパフォーマンス特性を理解する事で、サーバーサイジングをする際の重要な判断材料にできるようになります。
Webアプリケーションのバージョンの違いによる差異を確認するための検証
あるバージョンでのWebアプリケーションのパフォーマンス特性が把握できたら、新しいバージョンがリリースされる前に、「Webアプリケーションのパフォーマンス特性を把握するための検証」のセクションで行った検証(最小構成での処理限界値を確認するの検証のみなど、一部で可)を再度行い、前バージョンに比べてパフォーマンス特性に変化が無いか確認します(大幅に悪化しているようであれば、リリースしないか、少なくともデリバリーしない方がよい)。
このような検証をしておく事で、サーバースペックや構成だけでなく、Webアプリケーションのバージョンによる特性も加味してサイジングを行えるようになりますし、リリースしてからお客様環境で大幅なパフォーマンス悪化というような事態を避ける事ができる可能性が高くなります。
本題からはそれますが、以前関わっていた環境では、デイリービルドをデプロイした負荷テスト環境で、簡易スモークテストのシナリオでパフォーマンス測定を行い、その日に行われたコードの変更により、パフォーマンスが悪化していないか、毎日確認していました。
その結果、問題が見つかっても、かなり早いタイミングで対処ができていたように思います。
OS、ミドルウェアのバージョンアップによる差異を確認するための検証
OS(WindowsやLinux)、ミドルウェア(Apache、Tomcat、Java、Oracleなど)のバージョンアップによるパフォーマンス変化についても、Webアプリケーションのバージョン差異と同様にパフォーマンス測定して、差異を確認します。
ミドルウェアのバージョンアップにより、パラメータ設定などが大きく変わり、パフォーマンスにも影響が出る場合があるため、必ず実施した方がよい検証です。
ただし、上述したような検証は、手動でやる事は物理的にほぼ不可能なので、ほぼ自動で検証・測定ができるような環境整備をする事が大前提となります。
お客様本番環境での調査
社内でのパフォーマンス(負荷)検証をどれだけ実施しても、完全にお客様本番環境での状況を再現する事は非常に難しいです。
よって、お客様本番環境の実際のパフォーマンス状況をなるべく多くのパターンの環境で確認し、Webアプリケーションの(本当の)パフォーマンス特性を把握する事が非常に大切です。
また、パフォーマンス状況の調査の他にも、サーバーのスペック見積もりをする際には、ディスク容量(データ量がどの位になるか)、ネットワークの帯域幅についての考慮も必要です。
そのため、お客様本番環境で、以下のような情報を収集し、調査・解析を行います。
なお、以下は1社あたりで収集する情報です。
繰り返しになりますが、利用ユーザー数や利用製品、期間の違いなど、なるべく多くのパターンの環境の情報を取得するようにします。
| 収集項目 | 確認方法 | 備考 |
|---|---|---|
| お客様名 | 導入製品のお客様情報を確認 | |
| 利用ユーザー数 | 導入製品のお客様情報を確認 | |
| 利用製品 | 導入製品のお客様情報を確認 | |
| 製品のバージョン | 導入製品のお客様情報を確認 | |
| 製品の利用期間 | 導入製品のお客様情報を確認 | |
| 監査要件 | 導入時のヒアリング資料、RFPなど | 監査に必要となるログの種類と保管期間などを確認 |
| Web/APサーバーの台数 | 導入製品のお客様環境情報を確認 | シングル構成、水平クラスタなど |
| Web/APサーバーのスペック | 導入製品のお客様環境情報を確認 | CPU(製品名、コア数)、メモリ、ディスク容量、ディスク空き容量 |
| Web/APサーバーのOS情報 | 導入製品のお客様環境情報を確認 | OSの種類とバージョン |
| Web/APサーバーのOSのパフォーマンスログ | お客様本番環境から取得 | sarなどを可能であればアクセスが多い時期の1週間分取得 |
| Apache、Tomcatのバージョン | 導入製品のお客様環境情報を確認 | |
| Apacheのアクセスログ | お客様本番環境から取得 | 可能であればアクセスが多い時期の1週間分取得 |
| Apacheのエラーログ | お客様本番環境から取得 | 可能であればアクセスが多い時期の1週間分取得 |
| TomcatのHeapサイズ、Metaspaceサイズ | お客様本番環境から取得 | |
| GCログ | お客様本番環境から取得 | 可能であればアクセスが多い時期の1週間分取得 |
| Tomcatの標準出力ログ、エラーログ | お客様本番環境から取得 | 可能であればアクセスが多い時期の1週間分取得 |
| Webアプリケーションの各種ログ | お客様本番環境から取得 | 可能であればアクセスが多い時期の1週間分取得 |
| DBサーバーの台数 | 導入製品のお客様環境情報を確認 | シングル構成、HA構成、RAC、Exadataなど |
| DBサーバーのスペック | 導入製品のお客様環境情報を確認 | CPU(製品名、コア数)、メモリ、ディスク容量、ディスク空き容量 |
| DBサーバーのOS情報 | 導入製品のお客様環境情報を確認 | OSの種類とバージョン |
| DBサーバーのOSのパフォーマンスログ | お客様本番環境から取得 | sarなどを可能であればアクセスが多い時期の1週間分取得 |
| DBのデータサイズ | お客様本番環境から取得 | データファイルのサイズの合計、expdpのestimate_onlyオプションなど |
| Oracleのバージョン | 導入製品のお客様環境情報を確認 | |
| Oracleのアラートログ、リスナーログ | お客様本番環境から取得 | エラーなど無いかを確認 |
| OracleのStatspackレポート | お客様本番環境から取得 | 可能であればアクセスが多い時期の1時間毎のレポートを1週間分取得 |
お客様本番環境のパフォーマンス調査の流れについては、以下の記事も参考にしてください。
■Web/APサーバーの台数、各Web/APサーバーのCPUコア数を見積もるための情報収集
情報が収集できたら、Apacheのアクセスログを確認し、実際のパフォーマンス状況を確認します。
具体的には、以下のような内容を確認し、お客様環境毎にまとめていきます。
- ログ収集期間
- Web/APサーバー1台の1日の最大リクエスト数
- 秒間最大リクエスト数
- 秒間最大リクエスト数となった時刻
- サーバー処理時間が3秒以上のリクエスト数
- サーバー処理時間が3秒以上のリクエストの平均処理時間
- 最大サーバー処理時間
- サーバー処理時間が3秒以上のリクエストの割合(%)
- レスポンスが遅い機能(処理)
Apacheのアクセスログの解析方法の例については、以下の記事も参考にしてください。
Web/APサーバーの台数、各Web/APサーバーのCPUコア数を見積もるには、Web/APサーバーの台数、各Web/APサーバーのスペック(CPUの種類、コア数、メモリ)、利用ユーザー数と秒間最大リクエスト数に着目します。
様々なお客様本番環境において、以下のような点を確認し、Web/APサーバーの台数、各Web/APサーバーのCPUコア数を見積もるための参考情報とします。
-
お客様本番環境の、Web/APサーバー1台あたりの秒間最大リクエスト数と、最小構成、スペックで負荷検証した際の限界スループット(≒限界秒間リクエスト数)とに大きな乖離がないか
- 秒間最大リクエスト数が負荷検証結果より低く、サーバー処理時間が3秒以上のリクエストの割合(%)が1%を超えている場合、スペック見積もりに問題がある場合がある(お客様本番環境は、最小構成、スペックの負荷テスト環境以上のスペックがある想定なため)。
- 必要に応じて、負荷テストにおける限界スループット計測の方法を見直す。
-
最大秒間同時アクセス率(≒秒間最大リクエスト数 × Web/APサーバーの台数 ÷ 利用ユーザー数)がお客様本番環境で、実際どの程度なのか
- CPUの種類、コア数を見積もる際の根拠の1つに
- 負荷テストの際、限界スループットの値により、どの程度の利用ユーザー数までであれば問題にないかの指標になる
様々なお客様環境毎に、上記のようなパフォーマンス状況を確認して記録しておく事で、Webアプリケーションの特性が把握できるようになっていきます。
また、同じお客様のサーバーリプレースや製品のバージョンアップ後にも確認するようにしておく事で、更に細かく特性を把握する事ができます。
Apacheのアクセスログ以外に収集した各種ログ(OSのパフォーマンスログ、GCログ、Statspackレポートなど)は、調査した結果パフォーマンスが悪い機能や処理が見つかった際に、詳細調査をするためのものです。
サーバーサイジングには直接関わらない点なので、詳細は記載しませんが、問題がある処理が見つかった際には、詳細調査を行い、開発にフィードバックを行い、改善してもらうようにする事が大切です。
パフォーマンスの詳細調査の方法については、以下の記事も参考にしてください。
■各Web/APサーバーのメモリ見積もりの為の情報収集
最小構成で、メモリおよびヒープサイズを増やして負荷検証した際の限界スループット(ヒープサイズを2GB、4GB、8GB、12GBなどと増やした場合の限界スループットの推移)と、様々なお客様環境のメモリおよびヒープサイズでの秒間最大リクエスト数との間に大きな乖離が無いか確認します。
Web/APサーバーのOSパフォーマンスログで、ランキュー待ちが無いにも関わらず、秒間最大リクエスト数が負荷検証結果より低く、サーバー処理時間が3秒以上のリクエストの割合(%)が1%を超えている場合や、Full GCが頻発していたり、1回のFull GC時間が長かったり、OutOfMemoryErrorなどが発生しているような場合は、メモリおよびヒープサイズの割り当てに問題がある可能性があります(明確な根拠がある訳ではありませんが)。
また、Linux環境などで可能であれば、Apacheのプロセスでどの程度のメモリを使っているかをps auxなどで確認しておきます。
Webアプリケーションの特性により変動すると思われるので、過去の経験からの推測レベルの話ではありますが、秒間最大リクエスト数が多い環境では、メモリも多少余裕をもっておいた方がよいのではないかと考えます。
■必要なディスク容量見積もりの為の情報収集
各サーバーで必要となるディスク容量を見積もる際には、以下のような点を考慮して見積もります。
ドライブやパーティションの空き容量が、ドライブやパーティションサイズの10%以下になると、ファイルシステムへのアクセスが遅くなるため、多少余裕を持ったディスク容量にしておく事をお勧めします。
◆OSが必要とするディスク容量
最小サイズについては、OS提供元のサイトやマニュアルで確認できますが、WindowsであればCドライブに何かをインストールするミドルウェアがあったり、WindowsUpdateなどでディスク容量が多く必要となるケースがあったりするので、実際の環境のCドライブや/パーティションのサイズと空き容量を確認しておきます。
この情報を基に、OSの種類やバージョン毎のディスク容量を決定します。
※Windows Server 2016や2019であれば、Cドライブに100GB程度は確保しておくとよいと思います。
◆ミドルウェアをインストールするために必要なディスク容量
Apache、Tomcat、Oracleなどのミドルウェアをインストールするために必要なディスク容量も、基本的にはマニュアルに記載がされているので、その情報を基にします。
ただし、サイズは小さいものの、インストーラーなど、一時的に必要となる領域(Oracleの場合/tmpなど)および容量があるため、その点も考慮したものにしておきます。
◆各ミドルウェアのログを保管するために必要なディスク容量
本記事が前提とする構成では、Apache、Tomcat、Oracleのログが対象のログになります。
Tomcat(catalina.out、gcログなど)やOracleのログ(アラートログ、リスナーログ、トレースファイルなど)は、5年程度運用していても、数GBから多くても10GBちょっと程度で収まるものと思いますが、Apacheのアクセスログについては、アクセス数が多い環境では、無視できないサイズになります。
特に、監査要件で、アクセスログをサーバーのローカルディスクに長期間(1年、5年など)保管する必要がある場合は注意が必要になります。
ApacheのアクセスログやTomcatの標準出力ログ、GCログなどは、1日毎にログローテーションしている事が多いと思います。
これらのログについては、収集した各ログのうち、1日あたりのサイズが一番大きいものを探し、そのサイズを利用ユーザー数で割ったサイズ(1日での1ユーザーあたりのログサイズ)を確認しておきます。
様々なお客様本番環境のログを調査した中で、1日での1ユーザーあたりのログサイズが最も大きかった環境のログサイズを、Apache、Tomcatの各種ログサイズ見積もりの為の基準値にします。
Oracleのアラートログ、リスナーログ、トレースログについては、利用年数により、どの程度のサイズになるかをお客様環境やバージョン毎に確認し、見積もる際の参考にします。
◆Webアプリケーションのログを保管するために必要なディスク容量
ミドルウェア以外に、Webアプリケーションが独自に出力するログがある場合は、「ミドルウェアのログを保管するために必要なディスク容量」のセクションで説明したのと同じ方法で調査し、1日での1ユーザーあたりのログサイズが最も大きかった環境のログサイズをログサイズ見積もりの為の基準値にします。
◆Webアプリケーションのデータを保管するために必要なディスク容量
通常は、Webアプリケーションのデータが一番サイズが大きくなります。
本記事の前提では、Oracleにデータが格納されている前提ですが、ファイルシステム上にファイルデータを保管するようなシステムの場合は、ファイルデータも、ディスク容量見積もりの際の対象となります。
データ量の見積もりをする際には、情報収集した際のWebアプリケーションのデータサイズを、Webアプリケーションの利用期間(日数)と利用ユーザー数で割り、1日での1ユーザーあたりのデータ増加量を確認しておきます。
様々なお客様本番環境の中で、1日での1ユーザーあたりのデータ増加量が最も大きかった環境の増加量を、Webアプリケーションのデータサイズ見積もりの為の基準値にします。
◆アプリケーションの運用に必要なディスク容量
OS、ミドルウェア、Webアプリケーションのデータ、ログ以外にも、アプリケーション関連の運用(作業)で必要となるディスク容量を考慮します。
具体的には、ミドルウェア、Webアプリケーションのバージョンアップ用モジュールの置き場、データのexport/importに必要な領域などになります。
◆システム運用で必要となるディスク容量
運用監視やバックアップ・リストア、システム間のデータ連携など、Webアプリケーション以外で利用するツールなどで必要となるディスク容量についても確認します。
また、RPO、RTOの要件が厳しめの場合、Oracleはアーカイブログ運用とし、RMANなどで取得した一次バックアップは、ローカルディスクに出力する(その後、テープ装置や別ストレージにバックアップ)ような構成にする場合があります。
その場合は、アーカイブログファイルの出力先およびバックアップデータの保管先のディスク容量についても、世代管理数も考慮しつつ見積もる必要があります。
このために必要な領域を見積もるには、1日で出力される事が想定されるアーカイブログファイルのサイズがどの位か、Webアプリケーションのデータサイズが5年(減価償却期間)後、どの位のサイズになるかを見積もる必要があります。
Webアプリケーションのデータサイズについては、上述した「1日での1ユーザーあたりのデータ増加量が最も大きかった環境の増加量」を基に算出しますが、アーカイブログファイルが1日でどの位出力されるかについては、オンラインREDOログファイルのサイズとOracleのアラートログに出力されている、1日あたりのログスイッチの回数を掛け合わせて算出します。
様々なお客様本番環境の中で、1日でのログスイッチ回数×オンラインREDOログファイルのサイズの値が最も大きかったサイズを、アーカイブログファイル出力先のサイズ見積もりの為の基準値にします。
ただし、要件により、バックアップを取得し、不要となったアーカイブログファイルを毎日削除するのではなく、複数日分残すような運用にする場合は、その日数も考慮するようにします。
なお、サイズが大きなOracleのdumpファイルをimportしたりすると、日々の運用時に出力されるサイズよりも、はるかに沢山のアーカイブログファイルが出力される(100GBを超える事もある)ので、アーカイブログ運用をする場合は、少し大きめの領域を確保する事も検討してください。
■DBサーバーに必要なメモリ見積もりの為の情報収集
DBサーバーのメモリは、OLTPシステムの場合、OracleのSGAやPGAにより多くのメモリを割り当てた方が、パフォーマンスがよくなる可能性があります。
OracleのSGAやPGAにどの程度のメモリ割り当てが必要かを確認するには、StatspackレポートのSGA Target Advisory、PGA Memory Advisoryのセクションを確認します。
様々なお客様本番環境において、WebアプリケーションのデータサイズとSGA、PGAの割り当ておよびStatspackレポートのAdvisory統計の情報から、SGA、PGAのサイズの過不足を確認してまとめておき、見積もりの際の参考情報にします。
Statspackレポートの見方については、以下の記事も参考にしてください。
更に、Oracleのデータベースバッファキャッシュに、実データの何%程度がキャッシュされているかについても確認ができると、見積もり時に参考にする事ができます。
■DBサーバーに必要なCPUコア数を見積もるための情報収集
明確な根拠がある訳ではありませんが、DBサーバーのCPUコア数がどの程度必要かは、データベースのサイズ(Webアプリケーションのデータサイズ)とSGAのサイズ(データをバッファキャッシュにキャッシュしているサイズ)とに関係があると考えられます。
そのため、様々なお客様本番環境毎に、Webアプリケーションのデータサイズ、SGAのサイズ、DBサーバーのCPUの種類とコア数、CPU使用率について確認して参考にします。
負荷検証で、DBサーバーのメモリおよびSGAサイズを増やしていった際のCPU使用率と、同等のメモリ、SGA設定のお客様本番環境のCPU使用率とで、大きな乖離がないかも確認します(メモリ、SGA設定の他、Webアプリケーションのデータサイズも同等である前提で比較が必要)。
負荷検証時より、お客様本番環境のDBサーバーのCPU使用率が大幅に高い場合は、DBサーバーのCPUコア数の見積もり基準や負荷テストにおける負荷のかけ方について見直しが必要になります。
■必要なネットワーク帯域見積もりの為の情報収集
お客様拠点からWebアプリケーションまで、どの程度のネットワーク帯域が必要かを見積もるには、Web/APサーバーへのHTTPリクエストの平均転送量がどの位かを知る必要があります。
Apacheの場合、%Bなどで送信されたバイト数を確認する事ができるため、自社を含めた様々なお客様本番環境のApacheのアクセスログの転送量を確認し、1リクエストあたりの平均転送量を算出します。
調査した中で、1リクエストあたりの平均転送量が最も大きかった環境の転送量を、ネットワーク帯域見積もりの為の基準値にします。
各種見積もりの為に参考にする情報および基準値のまとめ
なお、以下は、新規の導入する際に参考にする情報および基準値です。
サーバーリプレースの際に参考にした方がよい情報が別にある場合は、備考欄にその旨を記載しています。
| 見積もり項目 | 見積もり時に参考にする情報、基準値 | 備考 |
|---|---|---|
| Web/APサーバーの台数、各サーバーのCPUコア数 | ・利用ユーザー数と想定される秒間同時リクエスト数 ・負荷検証における、限界秒間リクエスト数 |
可能であれば、今後5年(減価償却期間)の間の利用ユーザー数の増減予測も加味する サーバーリプレースの場合は、旧環境の最大秒間リクエスト数を参考にする |
| 各Web/APサーバーのヒープサイズ、Metaspaceサイズ | ・負荷検証でヒープサイズを変動させた際の、限界秒間リクエスト数 ・Webアプリケーションで必要となるMetaspaceサイズ |
サーバーリプレースの場合は、旧環境でのFull GCの間隔および1回のFull GCにかかっている時間が問題無いか、OutOfMemoryErrorが発生していないかについても確認する |
| 各Web/APサーバーのメモリ | ・OSの種類、バージョン ・Apacheで1ユーザー(プロセス/スレッド)あたりで必要とするメモリ ・Tomcatのヒープサイズ、Metaspaceサイズ ・Apache、Tomcat以外に導入される、運用監視、バックアップ、セキュリティソフトなどのミドルウェアやOSが何か |
Apache、Tomcatで必要とするメモリの見積もり結果と、それ以外に導入される、運用監視、バックアップ、セキュリティソフトなどのミドルウェアやOSで必要とするメモリを加味して決定する |
| 各Web/APサーバーのディスク容量 | ・OSで必要となるディスク容量 ・Apache、Tomcatをインストールするために必要なディスク容量 ・Apache、Tomcatで出力されるログ(特にアクセスログ)の保管に必要なディスク容量 ・Webアプリケーションの運用(バージョンアップ用モジュールの置き場、データ連携用の一時データなど)に必要なディスク容量 ・バックアップソフトなど、システム運用で必要なディスク容量 |
監査要件などにより変動する サーバーリプレースの場合は、旧環境の実際のディスク空き容量も確認する |
| DBサーバーのディスク容量 | ・OSで必要となるディスク容量 ・Oracleをインストールするために必要なディスク容量 ・Oracleが出力するログ(リスナーログ、アラートログなど)の保管に必要なディスク容量 ・Webアプリケーションの5年後の予測データサイズ(1日での1ユーザーあたりのデータ増加量の基準値を基に) ・(要件により)アーカイブログファイルの保管に必要なディスク容量、1次バックアップ保管に必要なディスク容量 ・バックアップソフトなど、システム運用で必要なディスク容量 |
サーバーリプレースの場合は、データ増加量を、見積もり時のWebアプリケーションの利用期間とデータサイズから算出し、現在のデータ量＋データ増加量/年×5年(減価償却期間)＋バッファで見積もる 旧環境の実際のディスク空き容量も確認する |
| OracleのSGA、PGAサイズ | ・5年(減価償却期間)後のWebアプリケーションのデータサイズ | サーバーリプレースの場合は、旧環境のStatspackレポートのAdvisory情報も参考にする |
| DBサーバーのメモリ | ・OSの種類、バージョン ・SGA、PGAサイズの見積もり結果 ・Oracle以外に導入される、運用監視、バックアップ、セキュリティソフトなどのミドルウェアやOSが何か |
OracleのSGA、PGAサイズの見積もり結果と、Oracle以外に導入される、運用監視、バックアップ、セキュリティソフトなどのミドルウェアやOSで必要とするメモリを加味して決定する |
| DBサーバーのCPUコア数 | ・Webアプリケーションのデータサイズ、SGAのサイズ、DBサーバーのCPUの種類とコア数、CPU使用率 | DBサーバーのメモリ見積もり結果により判断 サーバーリプレースの場合は、旧環境のCPUの種類、コア数、CPU使用率と新環境のCPUとの性能差を参考にする |
| 必要なネットワーク帯域 | ・1リクエストあたりの平均転送量が最も大きかった環境の転送量 | サーバーリプレースの場合は、旧環境の1リクエストあたりの平均転送量を参考にする |
サーバースペックの見積もり根拠
見積もりに入るまでの準備や情報収集についての説明が長くなってしまいましたが、ここでは、見積もりの為に収集した情報を活用し、どのような根拠でサーバースペックの見積もりを行えばよいかの参考として、過去に実際に行われたサーバーリプレース案件で、サーバースペックの見積もり根拠を求められた際に提示した資料を紹介したいと思います。
以下の例は、OSがLinux、Web/APサーバー、File/バッチサーバーが仮想基盤上、DBサーバーが物理サーバーにあり、ファイルデータはNASに、Web/AP、DBのOS、ミドルウェア領域およびDBデータは、SANのストレージに配置(OSもSANブート)されている構成の環境を、サーバーリプレースする際のスペック見積もりおよび根拠を記載した資料です(利用ユーザー数は14,000名、旧環境では、ロードバランサーで負荷分散し、Web/APサーバーは7台構成)。
前置き
※この文書は、物理環境での負荷試験結果などをベースにしていますが、仮想環境で負荷試験を行い、
Aシステムが高負荷状態になると、物理環境に比べ、最大30%程度パフォーマンスが悪化する
(特に、ディスクへの書き込みを伴うデータ更新処理)という結果が出ています。
よって、仮想環境でAシステムを動作させる際には、物理想定よりも多めに、CPU、メモリなどの
リソースを割り当てる事を推奨しています。
CPUの見積もり根拠
弊社にて実施した負荷テストの結果を基に見積もっています。
Aシステムの場合、同時アクセス数が増加するにつれ、Web/APサーバーのCPUがボトルネックとなり、
DBサーバーより先に限界が来る傾向があります(DBサーバーは、CPUではなく、ディスクI/O、
メモリ容量がボトルネックになります)。
よって、Web/APサーバーが処理を十分に捌けるCPU性能であれば、DBサーバーでも十分と考えられる為、
以下では、Web/APサーバーについての根拠を記載します。
弊社での負荷試験では、登録ユーザー数のうち、同じ時間帯に何らかの操作を行っているユーザー数は、
登録ユーザー数の5%である(実運用中のお客様のアクセス集中時間帯のアクセスログから設定)として
負荷試験を行っています。
なお、お客様環境における、2014年8月時点での同時操作ユーザー数は、ログインユーザー数の
2.84%でした。(登録ユーザー数ベースだと、1.83%)
また、負荷試験では、同時操作ユーザー数を増やしていき、応答時間が3秒以内に収まる上限を、
性能限界としています。
負荷テストに使用しているCPUは、「Intel Core2 Quad Q8200」です。(メモリは8GB)
この環境での負荷試験において、Web/APサーバー1台につき、同時操作ユーザー数が100までは、
応答時間が3秒以内に収まるという結果が出ています。
Intel XeonのCPU(E5シリーズ)は、弊社負荷試験で使用しているCPU(コア数4)に比べ、4倍以上の
処理性能を有しており、CPU性能に追従して、Aシステム(Web/AP)の処理性能も向上します。
また、CPUのコア数が倍になるとスループットが1.5倍になる事が弊社負荷試験結果から分かっています。
-------------------- 実環境の状況 --------------------
■2014/04/15
<AP1>
1日のリクエスト数：531943
サーバー処理時間が3秒以上のリクエスト数：4015(約0.755%)
サーバー処理時間が3秒以上のリクエストの平均処理時間：8秒
最大サーバー処理時間：280秒
サーバー処理時間が遅い時間帯：8:30からの10分間。(3061リクエスト)
1分間での最大リクエスト数：2049(ピークは、8:34。昼間は、800～1200リクエスト位)
<AP2>
1日のリクエスト数：494142
サーバー処理時間が3秒以上のリクエスト数：2463(約0.498%)
サーバー処理時間が3秒以上のリクエストの平均処理時間：7秒
最大サーバー処理時間：302秒
サーバー処理時間が遅い時間帯：8:30からの10分間。(1513リクエスト)
1分間での最大リクエスト数：1836(ピークは、8:34。昼間は、800～1200リクエスト位)
■2014/08/25
<AP1>
1日のリクエスト数：507541
サーバー処理時間が3秒以上のリクエスト数：731(約0.144%)
サーバー処理時間が3秒以上のリクエストの平均処理時間：13秒
最大サーバー処理時間：300秒
サーバー処理時間が遅い時間帯：10:00からの10分間。(86リクエスト)
1分間での最大リクエスト数：2117(ピークは、8:34。昼間は、800～1200リクエスト位)
最大リクエスト数があった1分間でのサーバー処理時間の平均：1秒未満
<AP2>
1日のリクエスト数：514471
サーバー処理時間が3秒以上のリクエスト数：576(約0.112%)
サーバー処理時間が3秒以上のリクエストの平均処理時間：10秒
最大サーバー処理時間：300秒
サーバー処理時間が遅い時間帯：8:40からの10分間。(35リクエスト)
1分間での最大リクエスト数：2110(ピークは、8:29。昼間は、800～1200リクエスト位)
最大リクエスト数があった1分間でのサーバー処理時間の平均：1秒未満
--------------------
なお、SSLの復号処理をAシステムのapacheで行うと、SSL処理をしない場合に比べ、
スループットは1/10に低下します。
よって、AシステムのapacheでSSL処理を行う事は避け、SSL処理はロードバランサーにて
行う事を推奨します。
旧環境で使用しているXeon5600番台と新環境で使用するE5シリーズでは、E5シリーズの方が
1.5倍程度の処理性能。
Core2 Quad Q8200とXeon5600番台とでは、5600番台の方が、少なくとも、3倍以上の
処理性能を有します。
よって、E5シリーズのCPUは、Core2 Quad Q8200に比べ、3×1.5=4.5倍以上の処理性能を
有しています。
Core2 Quad Q8200(4コア)で、同時操作ユーザー100程度までは処理を捌けるので、
E5シリーズでは、4コアで同時操作ユーザー450程度までまかなえます。
少なくとも、同時操作ユーザー数200であれば、十分に処理を捌けると言えます。
現状ピーク時間帯の1分間での最大リクエスト数は、約15400(2200×7)。
※旧環境のWeb/APサーバーは7台
また、ピーク時間帯のリクエストの平均サーバー処理時間は1秒未満なので、同時操作
ユーザー数は、1秒あたり15400/60≒256。
今後の利用ユーザー数の増加、利用機能の変化、突発的なアクセス集中を加味し、
同時操作ユーザー数を3倍の256×3=768と想定。
Web/APサーバー1台につき、Intel XeonのE5シリーズのCPUを4コア割り当てると、
同時操作ユーザー数200程度まではWeb/APサーバー1台で十分に処理を捌ける想定であり、
この場合、Web/APサーバーは4台必要となります。
DBサーバーについては、現環境で、Xeon5600番台の6coreのCPUを2台で、
12coreで運用しており、現状安定稼働しています。
Xeon5600番台とE5シリーズとでは、E5シリーズの方が1.5倍の処理性能を有します。
新環境では、Xeon E5シリーズのCPUを8core(12÷1.5)割り当てる事で、現状と同様の
安定したパフォーマンスが発揮できると考えます。
Fileサーバーについては、現状Xeon5600番台の4coreのCPUを使用していますが、
CPU使用率は高くても30%程度です。
今後、仮に処理量が倍になったとしても、現状リソースで十分な事が予想されるため、
Web/APサーバーと同様に、Xeon E5シリーズのCPUを4コア割当てる(現状より1.5倍の
性能向上)事で、十分な性能を発揮できると考えます。
メモリの見積もり根拠
弊社で、Aシステムのフル機能を実際に使用した実績値と、弊社で実施した負荷テスト
の結果を基に見積もっています。
Web/AP、DB各サーバーで、OSが1GBのメモリを必要とするものとしています。
また、監視ソフトやウィルス対策ソフトなど、OS、Aシステム以外のアプリケーションで、
1GB程度のメモリを使用する事を前提としています。
・APサーバー
Aシステム関連のミドルウェアには、以下があります。
- Apache
Aシステムでは、Apacheは、クライアント端末からのhttpリクエストを受け付け、
Tomcatにリクエストを引き渡す処理をメインで実行しているため、メモリ使用量は、
多くても1ユーザーあたり0.1MB程度です。
14000名の場合、最大で1400MB程度のメモリ使用量となる事を見込んでいます。
Web/APサーバー4台構成の場合、サーバー1台あたりでは、最大でも350MB程度の
メモリ使用量と見込んでいます。
- Tomcat
Javaアプリケーションでの、ビジネスロジックの実行および頻繁に参照されるデータの
キャッシュなどを行い、Web/APサーバーで一番メモリを使用するモジュールです。
Tomcat(JVM)に割り当てるメモリ領域には、以下の2つがあります。
<Heap領域>
ビジネスロジックの実行やAシステムのユーザー、グループ、ACLなど、頻繁に
参照するデータのキャッシュ領域として使う領域。
Aシステムの場合、最低でも800MB程度の領域が必要です。
また、この領域のサイズが大きい程データキャッシュできる領域が増えるため、
パフォーマンス向上に寄与します。
逆にサイズが小さすぎると、OutOfMemoryErrorの発生リスクが高まり、安定した
システム運用を阻害する要因となります。
<Permanent領域> ※当時。現状ではMetaspace領域
Javaのクラスオブジェクトをロードする領域。アプリケーションのソースコード量
などに依存します。Aシステムでは、ユーザー数に関わらず、384MBを割り当てます。
弊社負荷試験の結果では、Web/APサーバーの物理メモリ8GB、Heap領域に4GBの
割り当てをすると、同時操作ユーザー100までであれば、安定したレスポンスタイム、
スループットが出るという結果が出ています。
登録ユーザー数14000、同時操作ユーザー数が768の場合、Web/AP4台では、
サーバー1台あたりの同時操作ユーザー数は192。
4台の場合、Heapサイズは、100:4=192:X から、X=4×192÷100=7.68GB程度が
望ましいと考えます。
(同時操作ユーザー数に関しては、CPUについての記載を参照下さい)
以上から、登録ユーザー数14000の場合、各Web/APサーバーでHeap領域に8GB、
Permanent領域には384MBのメモリを割り当てる事を想定。
Heap、Permanent領域以外で、最大512MB程度メモリを使用するCヒープと合わせ、
Tomcatで9GB程度のメモリ割り当てが必要。
- memcached
Aシステムのアプリケーションの一覧情報のキャッシュをしています。512MBを
割り当てます。
- その他
Aシステムでは、1HTTPセッションあたり、2KB～10KB程度のメモリを使用します。
14000セッションでは、14000×10KB=140000KB≒137MB(Web/APサーバー1台あたり
約34MB)程度のメモリを必要とします。
以上から、APサーバーでは、以下のメモリ領域が必要と考えます。
1(OS)+1(Aシステム以外のアプリ)+0.35(Apache)+9(Tomcat)+0.5(memcached)=11.85(GB)
メモリは、各Web/APサーバーに、12GB以上必要と考えます。
・DBサーバー
DBサーバーでは、Oracleが稼働します。
- Oracle
データベースに関しては、データをSGA(システムグローバルエリア)にどれだけ
キャッシュできるかがパフォーマンスに大きく影響します。
よって、5年後のデータサイズがどの程度になっているかを考慮し、
メモリサイズを決める必要があります。
2015年3月末時点でのAシステム関連のOracleデータは、121GBであると
予想しています。
また、2015年4月から5年経過後の、Aシステム関連のOracleデータ量は、
319GBと予想しています
(詳細は、DB/Fileサーバーのディスク容量についての記述を参照)
※Aシステム verX.0より、これまでファイルシステム上に保管していた一部
ファイルデータがDB内に格納されるようになり、これにより、AシステムDBの
データサイズが最大で517GB程度になる見込みです。
ですが、これらのデータは、一覧の情報と一緒に読み込まれる事は無く、
詳細情報を参照する時のみに参照されるため、常にSGAにキャッシュする必要は
無いと考えています。
2014年8月時点で、SGAのバッファキャッシュにキャッシュされている
Aシステム関連データは、実データサイズの約20%で、この状態で良好な
パフォーマンスを発揮しています。
今後もSGAへのデータキャッシュ状況を監視し、良好なパフォーマンスが発揮
できている事を確認しつつではありますが、SGAにAシステム関連データの20%を
キャッシュするとした場合、5年後には319GB×0.2≒63.8GB程度が
必要と考えられます。
この他、PGA、共有プールなど、Oracleのデータキャッシュ以外に使うメモリに
2GBで、合わせて65.8GB以上のメモリをOracleに割り当てる必要があると考えます。
以上から、DBサーバーでは、以下のメモリ領域が必要と考えます。
1(OS)+1(Aシステム以外のアプリ)+65.8(Oracle)=67.8(GB)
以上から、メモリは、70GB以上の割り当てが必要。
なお、DBサーバーについては、メモリは多ければ多い程、高いパフォーマンス
を発揮します。
見積もりでは、70GBのメモリ割り当てが必要としていますが、データ増加率の
増大の可能性も考え、また、より最適なパフォーマンスを維持するため、
96GBのメモリを割り当てます。
・File兼バッチサーバー
Fileサーバーでは、RabbitMQ、memcached、Tomcatが稼働します。
現状、Fileサーバーで使用しているメモリ量は、最大でも4GB程度です。
4GBの内訳は、OS(Fileキャッシュなど)、RabbitMQとmemcachedが使用する
メモリと運用監視プロセスが使用するメモリです。
- Fileキャッシュ
お客様環境でのFileサーバーの運用監視レポートから、現状ではOS及び
監視プロセス含め、3GB程度のメモリを使用しています。
新環境で処理量が倍になったとした場合、6GBのメモリが必要。
- RabbitMQ
複数あるWeb/APサーバーで、キャッシュされている情報の同期を行います。
ユーザー規模に関わらず、最大でも256MB程度のメモリ消費となります。
- memcached
Aシステムのセッション情報などをキャッシュしています。
512MBを割り当てます。
新環境では、AシステムのFileサーバー兼バッチサーバーとして構成します。
Fileサーバー兼バッチサーバーではユーザーからのリクエストを処理する事は
ありませんが、バッチ処理を行うため、Web/APサーバーのTomcatと同程度の
メモリを使用します。
以上から、Fileサーバーでは、以下のメモリ領域が必要と考えます。
6(OS、Aシステム以外のアプリ、Fileキャッシュ)+9(Tomcat)+0.5(memcached)+0.25(RabbitMQ)=15.75(GB)
以上から、メモリは、16GB以上の割り当てが必要。
ディスク容量の見積もり根拠
弊社でAシステムのフル機能を利用した結果、1年でデータ量がどの位増加したかを基に見積もっています。
また、OSとAシステム関連ミドルウェア用に、各サーバー80GB(OSで50GB、M/Wで30GB)の容量が必要です。
・Web/APサーバー
Web/APサーバーに保管されるAシステムのデータは、apacheのアクセスログ、tomcatの標準出力ログ
などのログファイルです。
また、ログファイルのうちデータサイズのほとんどは、apacheのアクセスログ、
Aシステムのアクセスログ、レスポンスタイムログが占めます。
そのため、apacheのアクセスログ、Aシステムのアクセスログ、レスポンスタイムログのサイズを基に、
Web/APサーバーで必要なディスク容量の見積もりを行っています。
-------------------- 実環境の状況 --------------------
- 1日あたり
apacheアクセスログ：非圧縮で250MB。gz圧縮で15MB。
Aシステムアクセスログ：非圧縮で250MB。gz圧縮すれば、15MB程度。
Aシステムレスポンスタイムログ：非圧縮で250MB。gz圧縮すれば、15MB程度。
AP1台あたりのapacheのアクセスログは、1世代のみ非圧縮、それ以前はg
z圧縮する場合で、1年で15×365+250≒5.59GB。
Aシステムのアクセスログ、レスポンスタイムログは、非圧縮の場合、
1年で(250+250)×365≒178GB。
1世代のみ非圧縮、それ以前はgz圧縮する場合で、15×2×365+250×2≒11.18GB
------------------------------------------------------
新環境では、アクセスログは、gz圧縮する事とし、1年で、5.59+11.18=16.77GBのディスク容量が
必要。ただし、これはWeb/AP7台の時の1台あたりのアクセスログサイズであり、新環境でWeb/AP4台
構成にすると、1台あたりのアクセスログサイズは増大します。
Web/APサーバーを4台にした場合に必要な容量は、16.77GB×7÷4≒29.35GB。
今後のアクセス数の増加を考慮し、各Web/APサーバーで2倍の約60GBが必要であるとし、
アクセスログを各Web/APサーバーに5年保管するとした場合、300GBが必要。
この他OS、Aシステム関連ミドルウェア用に必要な80GBと合わせ80+300=380GBのディスク容量が必要。
Aシステム関連の作業領域なども含め、各Web/APサーバーには、400GB程度のディスク容量が必要。
・DBサーバー
DBサーバーに保管される、Aシステムのデータは、Oracleに格納するデータ、
Aシステムの文書に添付したファイル、全文検索Indexファイルです。
- Oracleデータ
お客様環境において、2014年8月7日時点でのデータベースのデータサイズは94.6GB。
2014年9月2日時点では、97.9GB。約1ヶ月で、3.3GBのデータが増加(1年で39.6GB)。
このペースでデータ増加が続くとした場合、2015年3月末時点では、Aシステム関連データは、
97.9+3.3*7=121GBになる事が見込まれます。
また、サイズの変動は小さいですが、Aシステム関連データ以外(SYSTEM表領域等)で、
最大30GB程度ディスクを使用しています。
よって、同じペースでデータが増加するとした場合、2015年4月から、1年、3年、5年経過後の
データサイズは、以下のようになる事が予想されます。
1年後(2016年3月末) 160.6GB(DB全体で、約190GB)
3年後(2018年3月末) 239.8GB(DB全体で、約270GB)
5年後(2020年3月末) 319.0GB(DB全体で、約350GB)
なお、AシステムverX.0より、これまでファイルシステム上に保管していたデータの一部を、
DBに保管するように変更されます。これによりデータベースサイズが増大する事が予想されます。
よって、データ増加率が2倍になるものとし、2015年4月から、1年、3年、5年経過後の
データサイズは、以下のようになると想定します。
1年後(2016年3月末) 200.2GB(DB全体で、約230GB)
3年後(2018年3月末) 358.6GB(DB全体で、約390GB)
5年後(2020年3月末) 517.0GB(DB全体で、約550GB)
この他、Oracle関連のログや、システム運用時に出力したdumpファイル用に、300GB程度
必要と見込んでいます。
また、アーカイブログ運用をする事を想定し、アーカイブログ用に200GB程度が必要。
更にOS、M/Wなどで80GBが必要。
※注)結果として、システム運用用のディスク容量は上記見積もりより多くすべきだった。
以上から、DB(Oracle)関連で必要となるディスク容量は、2015年3月末から1年後で610GB、
3年後で770GB、5年後で930GB以上必要。
・Fileサーバー
Fileサーバーに保管される、Aシステムのデータは、Aシステムの文書に添付したファイル、
全文検索Indexファイルです。
- 添付ファイルデータ
お客様環境において、2014年7月15日時点でのAシステムの添付ファイルのデータサイズは1.1TB。
2014年9月2日時点では、1.2TB。
約1ヶ月半で、83GBのデータが増加(1ヶ月で55.3GB、1年で663.6GB=0.65TB)。
このペースでデータ増加が続くとした場合、2015年3月末時点では、添付ファイルデータは、
1.2+0.387≒1.58TBになる事が見込まれます。
なお、利用ユーザーの増加、利用機能の拡大により、データ増加率も増える可能性が
ありますが、AシステムvX.0より、一部データがDB内に格納されるようになる事。
また、文書の複製時に添付ファイルは複製せず、ハードリンクを作成するようになる事で、
データ増加率は、現状と同じ程度になるのではないかと予想しています。
よって、同じペースでデータが増加するとした場合、2015年4月から1年、3年、5年経過後
の添付ファイルのデータサイズは、以下となる事が予想されます。
1年後(2016年3月末) 2.23TB
3年後(2018年3月末) 3.53TB
5年後(2020年3月末) 4.83TB
参考情報となりますが、添付ファイルのデータ増加率が2倍になると想定した場合の、
予測データサイズは以下となります。
1年後(2016年3月末) 2.88TB
3年後(2018年3月末) 5.48TB
5年後(2020年3月末) 8.08TB
今回は、データ増加率は現状と同じ想定とし、2015年4月から5年後の2020年3月末で、
添付ファイルデータ用に4.83TBのディスク容量が必要と考えます。
- 全文検索Indexファイル
お客様環境において、2014年7月15日時点でのAシステムの全文検索Indexファイルの
データサイズは116GB。2014年9月2日時点では、125GB。
約1ヶ月半で、9GBのデータが増加しています(1ヶ月で6GB、1年で72GB)。
このペースでデータ増加が続くとした場合、2015年3月末時点では、添付ファイルの
データは、125+42=167GBになる事が見込まれます。
なお、利用ユーザーの増加、利用機能の拡大により、データ増加率も増える可能性が
ありますが、AシステムvX.0より一部データがDB内に格納される事で、データ増加率は
現状と同程度と予想しています。
よって、同じペースでデータが増加するとした場合、2015年4月から、1年、3年、
5年経過後の全文検索Indexファイルのデータサイズは、以下となる事が予想されます。
1年後(2016年3月末) 239GB
3年後(2018年3月末) 383GB
5年後(2020年3月末) 527GB
また、全文検索Indexファイルのデータ増加率が2倍になると想定した場合の
予測データサイズは、以下となります。
1年後(2016年3月末) 311GB
3年後(2018年3月末) 599GB
5年後(2020年3月末) 887GB
今回は、データ増加率は現状と同じ想定とし、2015年4月から5年後の2020年3月末で、
全文検索Indexファイル用に527GBのディスク容量が必要と考えます。
以上から、Fileサーバーで必要となるディスク容量は、
<2015年3月末から3年後>
3.53TB+383GB≒3.9TB
OS、MW領域で80GBと合わせ、約4TB。
<2015年3月末から5年後>
4.83TB+527GB≒5.34TB
OS、MW領域で80GBと合わせ、約5.42TB
<ストレージ全体で必要なディスク容量>
■Web/AP、検証Web/AP
アクセスログ関連で、各Web/APサーバーでは1年で約60GBのディスク容量が必要。
5年保管の場合、300GBが必要。
その他、OS、Aシステム関連M/W用に必要な80GBと合わせ、各Web/APサーバーには
80+300=380GBが必要。
その他、Aシステム関連の作業領域を含め、Web/APサーバーでは400GBのディスク
容量が必要。
検証Web/APについては、アクセスが少なく、アクセスログなどのログサイズも
小さい事が予想されるため、150GB必要とする。
Web/AP：400GB×4(台)=1600GB
検証Web/AP：150GB
計：1750GB
■File
添付ファイルデータは、1年で0.65TBのデータ増加がある見込み。
4年保管の場合、0.65×4=2.6TBのディスク容量が必要。
全文検索Indexデータは、1年で72GBのデータ増加がある見込み。
4年保管の場合、72×4=288GB≒0.28TBのディスク容量が必要。
以上から、OS、MW領域で80GBと合わせ、0.08+2.6+0.28=2.96TB
Fileサーバー用に、3TBのディスク容量が必要。
■DB
データベースデータの、2015年4月から1年経過後のデータサイズは230GB。
5年経過後のデータサイズは550GBの見込み。
よって、4年データ保管の場合、550-230=320GBのディスク容量が必要。
※注)この環境では、過去データは定期的に削除する運用としていた。
この他、Oracle関連のログや、システム運用時に出力したdumpファイル用に
300GB程度必要と見込んでいます。
また、アーカイブログ運用をする事を想定し、アーカイブログ用に200GB程度が必要。
更にOS、M/Wなどで80GBが必要。
以上から、DBサーバーには、80+320+300+200=900GBのディスク容量が必要。
検証DBサーバーでは、アーカイブログ運用をしない想定であるため、200GBを減らし、
900-200=700GBのディスク容量が必要。
DB：900GB
検証DB：700GB
■ストレージ全体
Web/AP、検証Web/AP：1750GB
File：3072GB
DB：900GB
検証DB：700GB
計：6422GB≒6.27TB
<ストレージの性能要件>
最大2000～3000IOPS
今見返してみると、ツッコミたくなる記述もありますが、サーバースペックの見積もりや見積もり根拠を求められた際に、何かしら参考になれば幸いです。
ネットワーク帯域の見積もり
サーバースペックの他に、〇〇名いる拠点からどの位のネットワーク帯域があればよいのかと聞かれる事もあると思います。
ここでは、必要なネットワーク帯域の算出方法について紹介したいと思います。
ネットワーク帯域の見積もりの為に必要となるのは、Webアプリケーションで想定される「1リクエストあたりの平均転送量」になります(社内本番環境やお客様本番環境のApacheのアクセスログの情報から想定する)。
見積もりの前提例
同時アクセス率：1%
ネットワークの実効速度：帯域幅の50%
1リクエストあたりの平均転送量：20KB ※この値はWebアプリケーションにより変わります。
必要な帯域幅の計算
[必要帯域]=[ある拠点の利用ユーザー数]×[同時アクセス率]×[1リクエストあたりの平均転送量]
ある拠点の利用ユーザー数が1000名である場合、必要な帯域幅は以下のようになります。
必要帯域 = 1000 × 0.01 × 20(KB) = 0.2(MB) = 1.6(Mbit)
この拠点までの帯域幅が30Mbpsであった場合、実効速度が50%であるとすると、このネットワークで1.6Mbitのデータを転送するのに必要な時間は、以下のようになります。
1.6(Mbit) ÷ 30(Mbps) ÷ 0.5 ≒ 0.107(秒)
ここで算出された転送時間が、パフォーマンス的に問題ないかを確認し、必要な帯域幅の見積もりを行います。
転送時間に問題がありそうな場合は、想定する帯域幅を変動させ確認していきます。
例えば、上記例で帯域幅を100Mbpsと仮定した場合、転送時間は、1.6 ÷ 100 ÷ 0.5 ≒ 0.032(秒)となり、十分な帯域幅でありそうだと確認する事ができます。
Webアプリケーションの見積もり前提を決めておき、[ある拠点の利用ユーザー数]と[帯域幅]を変数とする事で、必要なネットワーク帯域幅を見積もりする事ができます。
ファイルのアップロード/ダウンロードの頻度が多かったり、登録、閲覧するファイルサイズが大きい事が想定される場合、平均転送量が大きくなる可能性があります。
同時アクセス率は、ピーク時間帯を想定します。同時アクセス率、平均転送量に安全率を掛け、帯域幅に問題が無いか確認を行います。
必要帯域を見積もった後、想定するネットワーク帯域での転送時間がどの程度かかるかを計算し、十分なパフォーマンス(転送時間)が得られるかを確認します。
おわりに
Webアプリケーションのサーバースペック見積もりにおいて、考慮すべき点、確認すべき点についてまとめてみました。
冒頭にも記載しましたが、サーバースペックを見積もるには、負荷検証を行ったり、お客様本番環境のパフォーマンス状況などの情報収集を行い、サーバー上で動作するWebアプリケーションのパフォーマンス特性を把握する事が大切です。
収集した情報を基に、各構成要素を見積もるための基準値(ディスク容量を見積もる際の基準値：1ユーザーあたりの1年でのデータ増加量の想定〇〇MBなど)や、実績ベースで確認できている点(秒間同時リクエスト数が〇〇までは、CPUコア数4、メモリ8GBのWeb/APサーバー1台で処理が捌けるなど)を整理しておく事で、様々な環境のスペックを見積もる事ができます。
また、見積もり根拠を求められた際にも、社内での負荷検証や実環境での実績ベースで説明する事で、お客様にも納得いただけるようになっていきます(特にサーバーリプレースの場合)。
見積もりが正当なものだったかどうか、後からお客様環境で負荷試験の実施を求められる事があるかもしれませんが、見積もり根拠を明確にして説明する事で、お客様環境で負荷試験を実施する必要がなくなる可能性も高いと思います(私の場合は、負荷試験の実施を求められる事がほぼ無くなりました)。
サーバーサイジング、スペック見積もりは難しいものではありますが、本記事の内容が少しでも参考になれば幸いです。