01. PROJECT OVERVIEW — プロジェクト概要
既存のポートフォリオサイトは、Amazon EC2上でApacheを稼働させ、HTML・CSS・JavaScriptを使用した静的Webサイトとして公開していました。
しかし、作品の追加やデザイン変更を行う際には、SSH接続によるファイル編集やサーバーへのアップロードが必要となり、更新作業に手間がかかるという課題がありました。
そこで、WordPressを導入し、Webサイトのコンテンツ管理を効率化することを目的としてシステムを再構築しました。
単純にWordPressをインストールするだけではなく、AWSのネットワーク構成を見直し、Webサーバーとデータベースサーバーを分離した構成を採用しています。
02. AWS NETWORK DESIGN — ネットワーク設計
AWS上にVPCを構築し、用途の異なる2つのサブネットを配置しました。
VPC設計
- VPC CIDR：10.100.0.0/16
- Public Subnet：10.100.10.0/24
- Private Subnet：10.100.20.0/24
- Internet Gateway：VPCに接続
Public SubnetにはWebサーバー用EC2を配置し、Internet Gatewayを経由して外部からHTTPアクセスできる構成としました。
一方、Private Subnetにはデータベース用EC2を配置し、インターネットから直接アクセスできないネットワーク構成としています。
ルーティング設計
Public Subnetに関連付けたルートテーブルには、VPC内通信に加え、Internet Gatewayへのデフォルトルートを設定しています。
Private Subnetでは、Webサーバーとの通信に必要なVPC内のローカルルートを利用しています。
この構成により、Webサーバーは外部からのアクセスを受け付けながら、データベースサーバーは内部ネットワーク上で動作するように設計しました。
03. SERVER ARCHITECTURE — サーバー構築
Webサーバー
Public Subnet内のEC2にAmazon Linux 2023を導入し、Apache HTTP Serverを構築しました。
WordPressの動作環境としてPHPおよびPHP-FPMを導入し、Apacheと連携させています。
主な構成
- Amazon EC2
- Amazon Linux 2023
- Apache HTTP Server
- PHP / PHP-FPM
- WordPress
ApacheがHTTPリクエストを受け付け、PHP-FPMを介してPHPプログラムを実行することで、WordPressによる動的なページ生成を実現しています。
データベースサーバー
Private Subnet内のEC2にMariaDBを構築しました。
WordPressの投稿データ、ページ情報、各種設定などをデータベースで管理しています。
主な構成
- Amazon EC2
- Amazon Linux
- MariaDB
- MySQL互換プロトコル（TCP 3306）
WebサーバーとDBサーバーを別インスタンスに配置することで、役割を分離し、データベースを直接公開しない構成としました。
04. SECURITY DESIGN — セキュリティ設計
AWSのセキュリティグループを使用し、サーバー間の通信を制御しています。
Webサーバー側
HTTPによるWebサイトへのアクセスを許可しています。
- TCP 80：HTTPアクセス
- 送信元：0.0.0.0/0
DBサーバー側
MariaDBへの接続はWebサーバーからの通信に限定する方針とし、必要なデータベース通信のみを許可する構成としました。
- TCP 3306：MariaDB接続
- 送信元：Webサーバーのセキュリティグループ
送信元にセキュリティグループを指定することで、特定のIPアドレスに依存せず、Webサーバーからのアクセスを制御できます。
また、DBサーバーをPrivate Subnetに配置することで、外部からの直接接続を制限しています。
05. WORDPRESS IMPLEMENTATION — WordPress導入
静的HTMLで構築した既存サイトをWordPressに移行しました。
WordPressのファイルをWebサーバーに配置し、データベース接続設定を行うことで、Private Subnet内のMariaDBと連携させています。
WordPressの処理フロー
- ユーザーがブラウザからWebサイトへアクセス
- ApacheがHTTPリクエストを受信
- PHP-FPMがWordPressのPHPプログラムを実行
- WordPressが必要に応じてMariaDBからデータを取得
- 生成されたHTMLをApache経由でブラウザに返却
これにより、静的ファイルを直接配信する構成から、データベースと連携してページを動的に生成する構成へ移行しました。
06. CUSTOM THEME DEVELOPMENT — 独自テーマ開発
既存のポートフォリオデザインを維持するため、WordPressの独自テーマ「tata-portfolio」を制作しました。
テーマ構成
- front-page.php：トップページ
- index.php：基本テンプレート
- functions.php：テーマ機能の定義
- assets/style：CSS
- assets/script：JavaScript
- assets/images：画像ファイル
従来のHTMLをWordPressのPHPテンプレートへ移行し、WordPress環境で既存のデザインを再現しました。
また、WORKSやPhotographyなどの詳細ページについても、ページ遷移やナビゲーションが正常に動作するよう調整しています。
コンテンツ管理の改善
WordPressのブロックエディターを活用し、管理画面から文章や画像を編集できる仕組みを整備しています。
さらに、作品管理にはカスタム投稿タイプを活用し、作品の追加・編集・削除を管理画面から行える構成への拡張を進めています。
実際の操作画面
写真挿入・文章入力・公開まで一貫してワードプレス（ノーコード）で操作を行えます。
07. TROUBLESHOOTING — 課題と対応
WebサーバーとDBサーバー間の接続
WordPress導入時には、異なるサブネットに配置したEC2間でデータベース接続が必要となりました。
VPC内の通信経路、セキュリティグループ、MariaDBの接続設定を確認し、WebサーバーからDBサーバーへの接続を検証しました。
WordPress移行に伴う表示調整
既存の静的HTMLをWordPressの独自テーマへ移行した際、ページ構造や画像の参照先、ヘッダーの動作などを調整しました。
特に、WORKSやPhotographyなどの詳細ページでは、共通ナビゲーションの表示と動作を確認し、ページ間で一貫した操作ができるよう改善しました。
運用性の改善
静的HTMLでは、作品追加のたびにソースコードを変更する必要がありました。
そこで、WordPressの投稿管理機能とテンプレートを組み合わせ、コンテンツと表示デザインを分離することで、運用時の作業負担を減らすことを目指しています。
08. RESULTS & FUTURE — 成果と今後の展望
本プロジェクトでは、AWSのネットワーク設計からLinuxサーバー構築、Web・DBサーバーの連携、WordPress導入、独自テーマの制作まで一貫して実施しました。
特に、Webサーバーとデータベースサーバーを異なるサブネットに配置し、必要な通信を制御する構成を通じて、クラウドインフラにおけるネットワーク設計とセキュリティの理解を深めました。
今後は、以下の改善を予定しています。
- Route 53による独自ドメインの設定
- HTTPS（SSL/TLS）対応
- WordPress管理画面からの作品管理機能の拡充
- CloudWatchによる監視・アラートの導入
- バックアップおよび運用管理の改善
継続的な機能追加と改善を通じて、開発だけでなく運用・保守まで考慮したWebシステムの構築を目指します。