Webサーバーの構築は、稼働環境とWebサーバーソフトウェアを決めたうえで、インストール、設定、ネットワークとセキュリティの調整、コンテンツの配置という順に進めれば完了します。
インターネットサービスを支える様々なサーバーのなかでも、Webサーバーは役割が明確で、基本構造も比較的シンプルです。そのため、初期構築自体はそれほど難しくはありません。
しかし、インターネット上に公開するサービスである以上、本番運用に向けたセキュリティや運用管理において注意すべき点は多岐にわたります。
本記事では、Webサーバーの基礎、シェア上位のApacheとnginxの構築手順、HTTPS化に必要な証明書の用意、そしてトラブルの起こりにくい堅牢なWebサーバー構築のためのセキュリティ対策を含む運用・保守のポイントを解説します。
この記事のポイント
- 稼働環境とWebサーバーソフトウェアの選び方
- オンプレミスのApacheで構築する手順
- AWS EC2のnginxで構築する手順
- HTTPS化に必要な証明書の用意のしかた
- 公開後の監視・バックアップ・セキュリティ対策
目次
Webサーバー構築前に知っておきたいサービス提供の基礎知識
Webサーバーとは、コンテンツ（文書、画像、動画など）をHTTP/HTTPSを通じてクライアント（Webブラウザ）に配信するシステムです。その実体は、コンピューター上やクラウド環境で動作するWebサーバーソフトウェアであり、代表的なものにApache、nginx、IISがあります。
Webサーバーを構築するとは、
- 環境を用意し
- Webサーバーソフトウェアをインストールして設定を行い
- ネットワークやセキュリティを含めた配信環境を整える
という一連の作業を指します。
Webサーバーの機能や役割など、詳しくは以下の記事を参照ください。
関連記事：Webサーバーとは？機能や構成、種類、運用上の注意点など徹底解説
Webサーバー構築前の情報整理と準備
構築作業に入る前に固めるのは、利用目的と要件、稼働環境、費用の見通し、Webサーバーソフトウェアの4点です。この順で決めると、後の手順で設定値に迷う場面が減ります。
| 決めること | 判断の軸 |
| 利用目的と要件 | 静的サイトか動的サイトか、社内共有かで必要な性能が変わる |
| 稼働環境 | 初期費用、運用負荷、拡張性、自社が負う責任範囲で比べる |
| 費用の構造 | 初期費用型・月額固定型・従量課金型で増え方が異なる |
| ソフトウェア | 配信するコンテンツの種類とOS環境との相性で決める |
利用目的と要件の確認
Webサーバーの利用目的により、必要な要件は異なります。構築の前にしっかりと確認しておくことが大切です。
静的サイト
企業サイトをインターネット上で公開するなど、コンテンツの変更が比較的少ないサイトの場合、安定稼働や高速なレスポンス、セキュリティ対策が重要となります。
動的サイト
ECサイトなど、アプリケーションサーバーやデータベースと連携するサイトの場合、静的サイトの要件に加え、アクセス増加に対応できるスケーラビリティ、データの整合性を保つ信頼性が求められます。
データ共有サイト
イントラネット上の情報共有サイトなどでは、大容量のストレージやアクセス制御が必要です。
サーバー稼働環境の選定
サーバーの稼働環境は、オンプレミス、ホスティング、クラウドに分けられ、それぞれに長所と短所があります。
- オンプレミス： 自由度が高い反面、多額の初期費用や運用コスト、専門知識が必要です。
- ホスティング： 運用負荷は軽減されますが、複数の利用者で環境を共有する共用型では、設定やカスタマイズに制限があります。
- クラウド： スケーラビリティが高く初期費用も抑えられますが、従量課金により利用状況次第で料金が変動します。
ユーザーとベンダーの責任範囲の違いも重要な選定基準となります。物理的な設備からOS、ミドルウェアまでのどこまでを自社が受け持つかは環境ごとに異なるため、自社でどこまで運用責任を持てるかを考慮しましょう。
稼働環境ごとに費用はどう変わるか
費用の総額よりも先に、費用の「発生のしかた」が環境ごとに違う点を押さえます。
オンプレミスは機器の購入費や設置費といった初期費用が先に立ち、その後も電源や保守、人件費が固定的にかかります。
ホスティングは月額固定が基本となるため、予算は立てやすい一方で、上位プランへの移行まで性能は頭打ちになります。
クラウドは初期費用を抑えられる代わりに、稼働時間やデータ転送量に応じて請求額が動きます。
クラウドで想定外の請求が起きる主な要因は、検証用に作ったまま停止し忘れたリソースと、転送量やバックアップ領域の増加です。予算のアラートを設定し、使っていないリソースを定期的に棚卸しすると、費用の振れ幅を抑えられます。
Webサーバーソフトウェアの選定
代表的なWebサーバーには以下の3つがあります。利用目的に合ったWebサーバーソフトウェアを選定することが重要です。
- Apache： 豊富なモジュールで拡張性が高く、柔軟な設定が可能です。動的コンテンツの処理に適しています。
- nginx： 少ないリソースで多数の同時接続を効率的に処理できるため、静的コンテンツの配信や大量アクセスに強みがあります。
- IIS： Windows環境での利用が前提となります。GUIによる直感的な操作が可能です。
選定で迷ったときは、配信するコンテンツの種類とOS環境の2点から絞り込みます。
静的なページや画像の配信が中心で、同時アクセスが多く見込まれるならnginx、モジュールを組み合わせて動的な処理を柔軟に構成したいならApacheが候補になります。Windows ServerでActive Directoryなどと連携する構成では、IISを選ぶ場面が多くなります。ApacheとnginxはどちらもLinux環境での情報が蓄積されており、設定例を探しやすい点も実務では効いてきます。
Webサーバーの構築手順 その①（オンプレミス Apache）
Apacheを用いてオンプレミス上のマシンにWebサーバーを構築する手順を解説します。OSはUbuntuの長期サポート版（LTS）を例とし、OSのインストールと初期設定は済んでいるものとします。
| 工程 | 作業の要点 |
| インストール | パッケージ管理システムでapache2を導入し、起動状態を確認する |
| 設定 | ホスト名とコンテンツの置き場所をディレクティブで指定する |
| ネットワークとセキュリティ | グローバルIPとDNSを設定し、不要なポートを閉じる |
| ドメインとDNS | レジストラでドメインを取得し、Aレコードを登録する |
| コンテンツの配置と確認 | 書き込み権限を整えてから外部ネットワークで表示を確認する |
Webサーバー（Apache）のインストール
Ubuntuのパッケージ管理システムを使用して、Apache HTTP Serverをインストールします。CUIの場合のコマンド例は以下です。
sudo apt install apache2
導入前に sudo apt update でパッケージ情報を更新しておくと、古いバージョンが入る事態を避けられます。インストール後は systemctl status apache2 で稼働状態を確かめ、ブラウザからサーバーのIPアドレスにアクセスして初期ページが表示されるかを見ます。ここで表示されれば、ソフトウェアの導入までは成功しています。
参考:「Ubuntu Server documentation」Server installation
Webサーバー（Apache）の設定
Apacheのメイン設定ファイルである apache2.conf や、仮想ホスト設定ファイルなどを編集して、必要なディレクティブを定義します。ディレクティブとは、Apache設定ファイル内でサーバーの動作や環境を指示する命令文のことです。
| 設定項目 | 設定内容 |
| ホスト名 | ServerName ディレクティブでWebサイトのホスト名を指定する。 |
| コンテンツディレクトリ | DocumentRoot ディレクティブでコンテンツのルートディレクトリを指定する。DocumentRootはURLパスの基点となり、サーバー上のディレクトリ構造はURLパスと基本的に対応する。 |
| 複数サイトの運用 | <VirtualHost> ディレクティブを使用する。 |
| SSL/TLS通信 | SSLEngine、SSLCertificateFile、SSLCertificateKeyFile などのディレクティブを設定する。 |
設定後に、Apacheの自動起動設定を行います。コマンド例は以下です。
sudo systemctl enable apache2
※参考：Apache HTTP Serverドキュメント – 設定ファイル
ネットワークとセキュリティの設定
インターネットにWebサーバーを公開する際、インターネット上で一意に識別されるグローバルIPアドレスをWebサーバーに割り当て、DNSを設定してホスト名と紐づけます。
また、サーバーのOSやルーターに付属するファイアウォールを設定し、必要なポート（HTTP：80番、HTTPS：443番など）以外は外部からのアクセスを遮断しておきましょう。
Ubuntuでufwを使う場合は、sudo ufw allow 80（HTTP）と sudo ufw allow 443（HTTPS）で公開するポートを開け、sudo ufw status で適用結果を確かめます。管理用のSSH（22番）は全世界に開放せず、管理拠点のIPアドレスからのみ許可する形にすると、不正アクセスの試行を大幅に減らせます。
参考：RFC 9110: HTTP Semantics
参考：Firewall – Ubuntu Server documentation
ドメイン取得とDNSレコードはどう設定するか
ドメインの取得とDNSの設定は、サーバー本体の構築とは別の作業です。IPアドレスだけで公開することもできるため、独自ドメインが必要な場合に進めます。
流れとしては、まずドメイン登録サービスで希望のドメインを取得し、そのドメインのDNSを管理する画面でAレコードにWebサーバーのグローバルIPアドレスを登録します。
設定が世界中のDNSに行き渡るまでには時間がかかるため、登録直後につながらなくても慌てる必要はありません。反映を確かめるときは、dig example.com や nslookup example.com を実行し、設定したIPアドレスが返ってくるかを見ます。
Webコンテンツの配置と動作確認
SCPやSFTPなどのファイル転送方法を用いてWebサーバーに接続し、コンテンツファイルをアップロードします。アップロード先はDocumentRootで指定したディレクトリであり、URLパスではない点に注意しましょう。
コンテンツ配置後、Webサーバーが置かれているオンプレミス環境とは異なるネットワーク（スマートフォンのモバイル環境など）からWebサーバーにアクセスして動作確認しましょう。
接続できない場合、下記を確認します。
- ファイアウォールの設定がHTTP/HTTPSを許可しているか？
- コンテンツの配置場所は正しいか？
- コンテンツファイルにWebサーバーが使用するユーザーの読み取り権限はあるか？
- Webサーバーのエラーログにエラーが記録されていないか？
Webサーバーの構築手順 その②（AWS EC2＋nginx）
nginxを用いてAWSのEC2上にWebサーバーを構築する手順を解説します。OSはAmazon Linux 2023を例とし、EC2インスタンスの起動と接続、OSの初期設定は済んでいるものとします。
| 工程 | 作業の要点 |
| AWSサービスの把握 | VPCやEC2など、Webサーバーを構成する要素の役割を押さえる |
| インストール | dnfでnginxを導入し、自動起動を設定する |
| 設定 | nginx.confでホスト名とコンテンツのルートを指定する |
| ネットワークとセキュリティ | セキュリティグループで必要なポートだけを開放する |
| コンテンツの配置と確認 | nginxの実行ユーザーの読み取り権限を確かめて表示を確認する |
AWSのどのサービスを使うのか
AWS上のWebサーバーは、単体のサーバーではなく複数のサービスの組み合わせで成り立ちます。役割を把握しておくと、設定画面のどこを触るのかで迷わずに済みます。
土台になるのがAmazon VPCで、AWSクラウド内に自社専用の仮想ネットワークを作り、IPアドレス範囲やサブネット、ルートテーブルを制御します。そのVPCにInternet Gatewayをアタッチすると、インターネットとの双方向通信ができるようになります。Webサーバーの本体となる仮想サーバーがAmazon EC2で、通信の許可はセキュリティグループで制御します。公開用のIPアドレスを固定したい場合はElastic IPアドレスを割り当て、独自ドメインと結びつけるときはDNSサービスであるRoute 53を使います。動的サイトでデータベースが必要ならAmazon RDS、画像や動画などの静的ファイルを大量に置くならAmazon S3が選択肢になります。
参考：AWSでの AL2023 の使用
参考：What is Amazon VPC?
参考：Enable internet access for a VPC using an internet gateway
Webサーバー（nginx）のインストール
Amazon Linux 2023のパッケージ管理システムを使用して、nginxをインストールします。CUIの場合のコマンド例は以下です。
sudo dnf install nginx
Webサーバー（nginx）の設定
nginxのメイン設定ファイルである nginx.conf を編集して設定を行います。Apacheとは記述の文法が異なるものの、指定する内容そのものは対応しています。
| 設定項目 | 設定内容 |
| ホスト名 | server_name ディレクティブでWebサイトのホスト名を指定する。 |
| コンテンツディレクトリ | root ディレクティブでコンテンツのルートディレクトリを指定する。 |
| 複数サイトの運用 | server ディレクティブを使用する。 |
| SSL/TLS通信 | listen ディレクティブの ssl パラメータ、ssl_certificate、ssl_certificate_key などを設定する。 |
設定後、nginxを起動し、自動起動の設定を行います。コマンド例は以下です。
sudo systemctl enable –now nginx
起動後は systemctl status nginx で稼働状態を確かめます。
参考：Configuring NGINX and NGINX Plus as a Web Server
参考：Module ngx_http_ssl_module（nginx）
ネットワークとセキュリティの設定
グローバルIPアドレスやDNSの設定はApacheの例と同様です。
ルーターのファイアウォール設定と近い存在に、AWSのセキュリティグループ設定があります。ここで必要なポートのみを開放する設定が可能です。
インバウンドルールの基本形は、HTTP（80番）とHTTPS（443番）をインターネット全体に許可し、SSH（22番）は管理元のIPアドレスに限定する構成です。インターネットから到達させるには、EC2インスタンスをパブリックサブネットに置き、Elastic IPアドレスなどの公開用アドレスを割り当てる必要もあります。
※参考：セキュリティグループを使用して AWS リソースへのトラフィックを制御する
Webコンテンツの配置と動作確認
コンテンツの配置と動作確認はApacheの例と同様です。
ただし、置き場所と実行ユーザーはApacheと異なります。nginxの初期のコンテンツディレクトリは /usr/share/nginx/html で、プロセスは nginx というユーザーで動くため、配置したファイルにこのユーザーの読み取り権限があるかを確かめます。
rootで作成したファイルの権限が絞られていると、ブラウザ側には403が返ります。原因の切り分けでは、/var/log/nginx/error.log を見ると権限エラーかパスの誤りかを判別できます。
参考：Module ngx_http_core_module（nginx）
参考：Amazon Linux 2023 nginxのビルド構成（amazonlinux/amazon-linux-2023）
HTTPS化に必要な証明書をどう用意するか
HTTPSで配信するには、設定ファイルにSSL/TLSのディレクティブを書くだけでなく、サーバー証明書そのものを取得する必要があります。入手先は、無料のLet’s Encrypt、AWSのAWS Certificate Manager、有償の証明書の3つに大別されます。
| 証明書の入手先 | 向くケース |
| Let’s Encrypt | 無料かつ自動更新で運用でき、ドメイン認証で足りるサイト |
| AWS Certificate Manager | ELBやCloudFrontを組み合わせるAWS中心の構成 |
| 有償の証明書 | 組織の実在性を示す認証が求められる場合 |
無料で使えるLet’s Encryptの使いどころ
Let’s Encryptは無料で証明書を発行でき、オンプレミスのApacheやEC2上のnginxにそのまま導入できます。発行と更新はCertbotなどのクライアントから実行し、サーバー側でドメインの所有確認が自動的に行われます。
証明書の有効期間は現在90日で、2027年2月からは64日、2028年には45日へ短縮される予定です。そのため、更新を自動化する前提で組み込みます。
Certbotは更新用のタイマーを登録する形で動くので、導入後に更新が走っているかを一度は確認しておくと安心です。発行できるのはドメインの所有を確認するタイプの証明書で、組織の実在性を示す証明書が必要な場合は有償の認証局を選びます。
参考:「Ubuntu Server documentation」Obtain TLS certificates
参考:「Certbot」Certbot
参考：FAQ – Let’s Encrypt
AWSならACMで証明書を発行する
AWS上で構築する場合は、AWS Certificate Manager（ACM）で証明書を無料で発行し、更新も任せる方法があります。DNSによる検証を選べば、Route 53でドメインを管理しているときの確認作業はほぼ自動で終わります。
ACMの証明書が無料になるのは、ELBやCloudFrontなどの統合サービスと組み合わせて使う場合です。
EC2インスタンスへ直接インストールしたい場合は、エクスポート可能なパブリック証明書として発行し、証明書と秘密鍵をエクスポートしてサーバーに配置します。この証明書は発行時と更新時にドメイン単位の料金が発生するため、費用を抑えたい場合はLet’s Encryptを導入する形も選択肢になります。
参考：AWS Certificate Manager exportable public certificates
参考：AWS Certificate Manager FAQs
参考：AWS Certificate Manager Pricing
有償の証明書を選ぶ場合
ドメインの所有確認に加えて、組織の実在性を示す認証が求められる場合は、有償の認証局が発行する証明書を選びます。Let’s EncryptやACMと異なり費用が発生するため、必要な認証の種類と対象ドメインの数を先に整理しておくと、見積もりとの差が出にくくなります。
Webサーバー構築後の運用と保守
構築したWebサーバーを安全に、そして安定して稼働させるためには、運用と保守が欠かせません。日々の作業は、ログ監視、バックアップ、セキュリティ対策、パフォーマンスチューニングの4つに整理できます。
| 運用項目 | 見るところ |
| ログ監視 | エラーログとアクセスログから障害の兆候と不正アクセスを拾う |
| バックアップ | コンテンツに加えて設定ファイルやデータベースも対象に含める |
| セキュリティ対策 | パッチ適用と設定の点検を継続し、情報の露出を減らす |
| パフォーマンスチューニング | 同時接続数、キャッシュ、Keep-Aliveを実測値に合わせて調整する |
ログ監視
ログ監視は、Webサーバーの状況をリアルタイムに把握できる手段であり、以下の目的に活用できます。
- 障害の早期発見： エラーログからサーバーダウンやレスポンス遅延の原因を特定する。
- セキュリティ脅威の検知： アクセスログから不正アクセスやサイバー攻撃の兆候を検知する。
- パフォーマンスの改善： アクセス状況を分析し、サーバーやコンテンツを最適化する。
ログの置き場所は、Ubuntuのapacheであれば /var/log/apache2、nginxであれば /var/log/nginx が初期値です。見るポイントを絞るなら、500番台のステータスコードの増加、特定のURLへの403や404の連続、そしてレスポンスタイムの悪化の3つから着手すると判断が早くなります。
AWS上であればCloudWatch Logsにログを集約し、しきい値を超えたときに通知が飛ぶ形にしておく方法もあります。
実際の事例紹介
スポーツのライブ配信サービスを運営する企業様では、試合のない日にもアクセスが急に集中する事象が繰り返し起きました。その際は、ハートビーツがログからアクセス元を特定、攻撃の種類や可能性を調査した上で、結果の報告から防御までの一連の対応を行いました。
▶︎事例をみる
【関連記事】【徹底解説】ログ管理とは？目的や重要性、ツールの選び方までわかりやすく紹介 | 株式会社ハートビーツ（HEARTBEATS Corporation）｜AWS・クラウド・サーバーなどのインフラ運用を24時間365日サポート
バックアップ
災害やサイバー攻撃、人的ミスなどの予期せぬ事態からWebサイトを守るため、バックアップは不可欠です。
バックアップすべきデータはWebコンテンツだけではなく、Webサーバーの設定ファイルやログファイル、動的サイトであればデータベースなど多岐にわたります。バックアップが必要なデータ範囲を明確にしておきましょう。
頻繁に更新されるサイトでは数時間おきやそれ以上の頻度でのバックアップが必要になるなど、サイトやデータの性質に応じてバックアップの頻度を計画することも重要です。
取得方法は環境で変わります。オンプレミスではrsyncによるファイル同期やデータベースのダンプを組み合わせ、AWSではEC2やRDSのスナップショットを定期取得する形が取りやすい方法です。また、保管先を本番と同じ場所だけにせず、復旧手順を一度試しておくと、いざというときに手が止まりません。
セキュリティ対策
構築したWebサーバーのセキュリティを維持するため、以下の対策を継続的に実施しましょう。
- OSとソフトウェアの最新化： 脆弱性対策のセキュリティパッチは迅速に適用する。
- 定期的な設定確認： ファイアウォールやアクセス制御設定が意図通りに機能しているか、定期的に確認する。
- セキュリティ診断の実施： 脆弱性診断ツールを用いて、設定ミスや脆弱性がないか客観的にチェックする。
Webサーバー側の設定では、情報の露出を減らす調整も効果があります。ディレクトリの一覧表示を無効化してファイル構成を隠し、レスポンスヘッダーに出るサーバーのバージョン情報を抑え、使っていないモジュールを無効化すると、攻撃者に渡る手がかりが減ります。
ApacheではOptionsディレクティブの Indexes 無効化と ServerTokens、nginxでは autoindex と server_tokens が該当する設定です。
参考：mod_autoindex – Apache HTTP Server Version 2.4
参考：core – Apache HTTP Server Version 2.4
参考：Module ngx_http_core_module（nginx）
パフォーマンスチューニング
ログ監視の結果、パフォーマンス改善が必要な場合は以下のチューニングを行います。いずれも推奨値が一律に決まるものではなく、実測したリソース使用状況に合わせて詰めていく性質の設定です。
同時接続数の調整
想定されるアクセス数に合わせて、サーバーが同時に処理できる接続数を調整します。設定項目には以下があります。サーバーのメモリ容量やCPUコア数による制限に注意しましょう。1プロセスあたりのメモリ使用量を実測し、空きメモリから逆算すると過剰な設定を避けられます。
- Apache： StartServers、MinSpareServers、MaxSpareServers、MaxRequestWorkersなど
- nginx： worker_processes、worker_connectionsなど
参考：mpm_common – Apache HTTP Server Version 2.4（ServerLimit Directive）
参考：Core functionality（nginx）
キャッシュ設定
HTMLや画像、CSSなどの静的コンテンツをキャッシュし、サーバーへのリクエスト数を減らして応答速度を向上させられます。設定項目には以下があります。キャッシュされている間はコンテンツの更新が反映されないため、キャッシュ対象や期間の設定に注意が必要です。更新頻度の高いファイルは短め、画像やCSSは長めというように対象ごとに期間を分けます。
- Apache： mod_expiresモジュール、ExpiresActive On、ExpiresByType
- nginx： expires
参考：mod_expires – Apache HTTP Server Version 2.4（ExpiresByType Directive）
Keep-Alive設定
接続確立のオーバーヘッドを削減し、レスポンスの向上が可能です。設定項目には以下があります。メモリ容量や同時接続数の制限に注意しましょう。待ち時間を長くするほど接続が占有されるため、短めの値から始めて調整します。
- Apache： KeepAliveTimeout、MaxKeepAliveRequests
- nginx： keepalive_timeout
参考：core – Apache HTTP Server Version 2.4（KeepAliveTimeout Directive）
参考：Module ngx_http_core_module（nginx）
自社構築と外注はどう使い分けるか
自社で構築するか外部に任せるかは、社内の技術レベルと、公開後に24時間365日の運用を担えるかで判断します。構築作業よりも、公開後の監視と障害対応を続けられるかが分かれ目になります。
| 進め方 | 向くケース |
| 自社で構築・運用する | 社内にサーバーの知見があり、運用も内製化したい場合 |
| 外部に依頼する | 専門人材がおらず、夜間休日の対応体制も組めない場合 |
| 構築と運用を分ける | 構築は自社で行い、日々の監視だけを委託したい場合 |
費用だけを見れば自社で構築・運用する方が安く収まりますが、突発的なトラブル対応の工数が読めない点は織り込んでおく必要があります。
設定を誤ると情報漏えいや不正中継の踏み台といった事態にもつながるため、セキュリティ設定に不安が残る段階で本番公開を急ぐのは避けたいところです。
検証や学習を目的とするなら自社構築が適し、短期間で堅牢な構成を求めるなら外部の知見を借りる形が現実的な選択になります。構築は自社、運用は委託という分担も取れるため、二択で考え込む必要はありません。
まとめ
Webサーバーの基礎知識から、Apacheとnginxを用いた構築手順、証明書の用意、運用・保守のポイントまでを解説しました。
Webサーバーの構築自体はそれほど難しくありませんが、セキュリティや運用管理には専門的な知識と継続的な対応が必要です。本記事が、トラブルの起こりにくい堅牢なWebサーバー構築に役立てば幸いです。
ハートビーツはインフラに関する深い知見をもとに、MSPサービスやセキュリティ導入・運用代行といった各種サービスを提供しています。Webサーバー構築の際には、ぜひお気軽にご相談ください。
▶︎お問い合わせはこちら
