
本番環境とテスト環境で、それぞれ別のURLを使い、Webサイトのデータを分けて管理していても、実際には同じサーバー上で稼働しているケースがあります。
たとえば、本番用とテスト用でURLやディレクトリを分けていても、CPUやメモリ、OS、ミドルウェアは共通していることがあります。見た目上は環境が分かれていても、サーバーとしては一部を共有している状態です。
この場合、テスト環境で負荷の高い処理を行ったり、PHPなどのミドルウェアを変更したりすると、本番環境にも影響を及ぼす可能性があります。
今回紹介する総合エンタテインメント企業では、Webサイトのリニューアルにあわせて、本番環境とテスト環境をそれぞれ別のサーバーに構築しました。
ただし、本番環境と同じ構成をテスト環境にもそのまま用意したわけではありません。本番環境は安定したサイト運用を重視し、テスト環境は変更内容の確認に必要な構成へ絞っています。
本記事では、本番環境とテスト環境を同じサーバーで運用する場合にどのような影響が考えられるのかを整理しながら、この企業がどのように2つの環境を分けたのかを紹介します。
Webサイトリニューアルにあわせ、本番環境とテスト環境を分離
本事例では、コーポレートサイトのリニューアルにあわせて、サーバー環境も見直しました。
今回のリニューアルでは、サイトデザインだけでなく、更新性や拡張性なども含めてWebサイト全体を見直しています。
クロジカでは、新しいサーバー環境の構築と、その後の運用保守を担当しました。
本番環境とテスト環境は、同じサーバー内でURLやディレクトリだけを分けるのではなく、それぞれ別のサーバーに構築しています。サーバーそのものを分けることで、テスト環境で使用するCPUやメモリ、OS、ミドルウェアなどを、本番環境とは別に管理できるようにしました。
一方で、2つの環境をまったく同じ構成にはしていません。
本番環境には公開中のWebサイトを安定して運用するために必要な構成を、テスト環境には変更内容を確認するために必要な構成を用意しています。本番環境とテスト環境では、目的に応じて異なる構成を採用しています。
本番環境とテスト環境が同じサーバーの場合、何を共有しているのか
本番環境とテスト環境を分けていても、URLやディレクトリだけを分け、同じサーバー上で運用しているケースがあります。
この場合、Webサイトとしては分かれていても、構成によっては以下のようなものを共有しています。
- CPU
- メモリ
- ディスク
- OS
- Webサーバー
- PHPなどのミドルウェア
つまり、「テスト環境が用意されていること」と、「本番環境とテスト環境がサーバー単位で分かれていること」は別ということです。
テスト環境の処理も、同じCPUやメモリを使う
本番環境とテスト環境を同じサーバーで運用していれば、テスト環境で行う処理も、本番環境と同じCPUやメモリ、ディスクを使います。
ページの表示確認や小規模な変更であれば、大きな影響が出ない場合もあります。一方、大量のデータを扱う処理や負荷の高いテストを行えば、本番環境と同じサーバーの処理能力を使うことになります。
実際にどの程度影響するかは、サーバーのスペックやアクセス状況、行う処理によって変わります。
重要なのは、同じサーバー上で稼働している限り、テスト環境で使うCPUやメモリなどが、本番環境から完全に独立しているわけではないという点です。
OSやPHPなどの変更も、本番環境と切り離せない場合がある
共有するのは、CPUやメモリだけではありません。
本番環境とテスト環境で同じOSやWebサーバー、PHPなどを利用している場合、それらの変更もテスト環境だけで完結できないことがあります。
たとえば、
- PHPのバージョンを変更する
- Webサーバーの設定を変更する
- サービスを再起動する
- OSやミドルウェアをアップデートする
といった作業です。
「新しいPHPのバージョンでもWebサイトが正常に動くか確認したい」と考えても、本番環境とテスト環境が同じPHPを利用していれば、テスト環境だけを変更して確認できるとは限りません。
そのため、テスト環境を考える際は、確認用のWebサイトが用意されているかだけでなく、テスト時の処理やサーバー設定の変更を、本番環境からどこまで切り離したいのかを見る必要があります。

本番環境は冗長構成、テスト環境は1台 目的に応じて構成を分ける
この企業では、本番環境とテスト環境を別のサーバーに構築していますが、両方を同じ構成にはしていません。
| 項目 | 本番環境 | テスト環境 |
| 役割 | 公開中のWebサイトを運用 | 変更内容を事前に確認 |
| Webサーバー | 複数台 | 1台 |
| DB | Webサーバーとは分けて冗長化 | Webと同じサーバー内に配置 |
| 構成の考え方 | 公開サイトの運用に必要な冗長性を確保 | 確認に必要な範囲へ構成を絞る |
本番環境は、複数のWebサーバーと冗長化したDBで構成
本番環境はAWS上に構築しています。Webサーバーを複数台とし、データベースも冗長化しています。
公開中のWebサイトを提供する本番環境では、一部のサーバーに問題が発生した場合も想定して、複数のWebサーバーと冗長化したDBを用意しています。
また、運用開始後も利用状況に応じてサーバーの性能を見直しており、一度構築した環境をそのまま固定しているわけではありません。
テスト環境は、WebとDBを1台のサーバーに集約
一方、テスト環境は、本番環境とは別のサーバー1台で構築しています。
Webサイトを動かすWebサーバーと、サイトで使用するデータを保存するDBを、1台のサーバーにまとめています。
本番環境とはサーバーそのものが分かれているため、テスト環境で使うCPUやメモリ、ディスクは、本番サーバーとは別です。
OSやPHP、Webサーバーなどについても、本番サーバーとは別に設定や変更を行えます。
そのため、テスト環境で処理負荷が高まった場合でも、その処理によって本番サーバーのCPUやメモリを直接使う構成ではありません。また、PHPなどのバージョンやサーバー設定を変更する場合も、本番サーバー自体を同時に変更する必要はありません。
一方で、本番環境にある複数のWebサーバーやDBの冗長構成まで、テスト環境で再現しているわけではありません。
テスト環境は「何を確認したいか」で必要な構成が変わる
テスト環境を本番環境から分ける場合でも、必ず本番環境と同じサーバー構成をもう一式用意する必要があるとは限りません。
必要な構成は、テスト環境で何を確認したいかによって変わります。
たとえば、Webサイトを修正した際の表示や、CMSでコンテンツを更新した際の動作を確認することが目的であれば、本番環境と同じように複数のWebサーバーや冗長化したDBまで用意しなくても、確認できる場合があります。
一方、PHPなどのバージョンを変更した際の動作を確認したいのであれば、本番環境とは別にPHPを変更できる環境が必要です。
さらに、本番環境で行っている負荷分散や、複数のWebサーバー、DBの冗長化まで含めた動作を確認したいのであれば、テスト環境にもそれに近い構成が必要になります。今回のようにWebとDBを1台にまとめたテスト環境では、そこまでは再現できません。
つまり、「本番環境と同じものを用意するか」ではなく、「本番環境へ変更を反映する前に何を確認したいのか」から、テスト環境に必要な構成を考えることがポイントです。
この企業では、本番環境には複数のWebサーバーと冗長化したDBを用意する一方、テスト環境ではWebとDBを1台のサーバーにまとめています。
本番環境とテスト環境をサーバー単位で分けることで、CPUやメモリなどの処理能力と、OSやPHP、Webサーバーなどの設定をそれぞれ別に管理しながら、テスト環境については本番環境と同じ冗長構成までは持たせていません。
なお、今回のサーバー環境では、CPU・メモリ・ディスクなどの監視や定期バックアップ、OS・ミドルウェアへのセキュリティパッチ適用、障害時の復旧対応なども運用保守の対象としています。
本番環境とテスト環境が同じサーバーなら、まず構成を確認する
本番環境とテスト環境を同じサーバーで運用しているからといって、必ず別のサーバーに変更する必要があるわけではありません。
Webサイトの規模や変更頻度、テスト環境で確認したい内容、予算などによって、適した構成は変わります。
そのため、まず確認したいのは「テスト環境があるか」ではなく、本番環境とテスト環境が実際にどのような構成になっているのかです。
そのうえで、
- テスト環境では、Webサイトの表示やコンテンツだけを確認するのか
- PHPやWebサーバーなどの変更も試したいのか
- テスト時の処理負荷を本番環境から分けたいのか
といった点を整理します。
Webサイトの表示確認など、限られた用途で現在の構成に問題がないのであれば、同じサーバーで運用する判断も考えられます。
一方、サーバー側の変更まで事前に確認したい場合や、テスト時の負荷を本番環境から切り離したい場合は、サーバーを分けることも選択肢になります。
「テスト環境があるから本番環境とは分かれている」と考えるのではなく、実際にどのサーバーを使い、何を共有しているのかを確認する。
そこから、自社に必要な分け方を考えることが重要です。
まとめ|本番環境とテスト環境は、目的に応じて分け方を考える
本事例では、Webサイトのリニューアルにあわせて、本番環境とテスト環境をそれぞれ別のサーバーに構築しました。
本番環境は、複数のWebサーバーと冗長化したDBで構成。一方、テスト環境はWebとDBを1台のサーバーにまとめています。
本番環境とテスト環境をサーバー単位で分けることで、CPUやメモリなどの処理能力だけでなく、OSやPHP、Webサーバーなども別に管理できます。
ただし、テスト環境に本番環境と同じ構成をそのまま用意する必要があるとは限りません。
何を事前に確認したいのか、本番環境から何を切り離したいのかによって、必要なテスト環境は変わります。
クロジカでは、現在のWebサイトやサーバーの構成、運用内容を確認したうえで、本番環境とテスト環境で何を共有しているのかを整理し、必要なサーバー環境の設計・構築から運用保守まで支援しています。
本番環境とテスト環境がどのような構成になっているか分からない場合や、現在の分け方で問題ないか確認したい場合は、まずは現在のサーバー構成からご相談ください。
コーポレートサイトをクラウドでセキュアに

クラウドサーバー管理
クロジカガイドブック
- コーポレートサイト構築・運用の課題を解決
- クロジカクラウドサーバー管理の主な機能
- 導入事例
- 導入までの流れ





