프로젝트 목록으로

INFRASTRUCTURE PROJECT

WordPress 고가용성 인프라 구축

단일 서버 환경의 한계를 해결하기 위해 웹 서버 이중화, 로드밸런싱, 데이터베이스 복제를 적용한 고가용성 WordPress 인프라 구축 프로젝트

개인 프로젝트인프라 구축

Tech Skills

Environment

Rocky LinuxVagrantVirtualBox

Stack

HAProxyMySQLNFSiSCSIApacheWordPress

Project Summary

이 프로젝트의 문제 배경과 해결 방식, 핵심 아이디어를 간단히 정리했습니다.

Why I Built This

단일 서버 구조의 한계

기본적인 웹 서비스 구조에서는 하나의 서버가 웹 서비스와 데이터베이스를 모두 처리합니다. 이 경우 서버에 장애가 발생하면 서비스 전체가 중단될 수 있습니다.

고가용성 인프라 필요

웹 서비스는 장애 상황에서도 서비스가 지속될 수 있어야 합니다. 이를 위해 웹 서버 이중화, 로드밸런싱, 데이터베이스 복제와 같은 고가용성 아키텍처가 필요했습니다.

My Approach

01

웹 서버 이중화와 로드밸런싱

두 개의 WordPress 웹 서버를 구성하고 HAProxy를 통해 트래픽을 분산했습니다. 이를 통해 특정 서버에 장애가 발생해도 서비스가 지속될 수 있는 구조를 만들었습니다.

02

데이터 안정성과 스토리지 분리

MySQL Primary-Replica 복제를 구성해 데이터 안정성을 확보하고, NFS와 iSCSI를 활용해 웹 서버 간 파일 공유와 데이터 저장 구조를 분리했습니다.

System Architecture

서비스가 특정 서버 한 대에 의존하지 않도록, 요청 처리 계층과 애플리케이션 계층, 데이터 계층을 분리한 고가용성 구조로 설계했습니다.

WordPress high-availability architecture

Presentation Layer

HAProxy Load Balancer

HAProxy 로드밸런서가 클라이언트 요청을 받아 두 개의 웹 서버로 트래픽을 분산합니다. 이를 통해 특정 서버에 장애가 발생하더라도 다른 서버가 요청을 처리할 수 있도록 구성했습니다.

Application Layer

Apache + WordPress + NFS

두 개의 Apache 웹 서버에서 WordPress 애플리케이션을 실행하도록 구성했습니다. 또한 NFS를 통해 WordPress 소스 코드와 업로드 파일을 공유하여 웹 서버 간 서비스 일관성을 유지했습니다.

Data Layer

MySQL Primary-Replica + iSCSI

MySQL Primary–Replica 구조를 구성하여 데이터 안정성을 확보했습니다. 데이터 저장소는 iSCSI 기반 네트워크 스토리지를 사용해 웹 서버와 분리된 저장 구조로 운영했습니다.

Core Implementation

가상화 환경 구성부터 로드밸런싱, 데이터베이스 복제, 파일 공유, 스토리지 분리까지 고가용성 인프라를 구성한 핵심 구현 내용을 정리했습니다.

01

Vagrant 기반 가상 환경 구성

Vagrant와 VirtualBox로 역할별 VM을 분리해 인프라 기반을 구성했습니다.

로드밸런서, 웹 서버, DB 서버, 스토리지 서버를 각각 분리된 VM으로 만들고, 네트워크도 요청 처리, 애플리케이션, 데이터 계층으로 나누어 고가용성 인프라 구조를 구성했습니다.

3개 서브넷 기반 요청 처리·웹 서비스·데이터 계층 분리

로드밸런서·웹 서버·DB 서버·스토리지 서버 역할별 VM 정의

서버 역할별 CPU·메모리 차등 할당 기반 자원 분배

Vagrantfile 핵심 설정

rubyvm_subnet1 = "192.168.56."  # 외부 접속용
vm_subnet2 = "192.168.57."  # 웹/NFS
vm_subnet3 = "192.168.58."  # DB/스토리지

config.vm.define "lb01" do |node|
  node.vm.provider "virtualbox" do |vb|
    vb.cpus = 1; vb.memory = 1024
  end
  node.vm.network "private_network",
    ip: vm_subnet1 + "10", nic_type: "virtio"
end
02

HAProxy 로드밸런싱 설정

요청을 분산하고 헬스 체크를 적용해 웹 계층의 가용성을 높였습니다.

HAProxy를 로드밸런서로 두고 두 개의 WordPress 웹 서버에 요청을 분산했습니다. frontend와 backend를 나누고 Round Robin과 헬스 체크를 적용해, 특정 서버에 장애가 발생해도 서비스가 지속되도록 했습니다.

Round Robin 방식 기반 두 웹 서버 트래픽 균등 분산

헬스 체크 적용 기반 장애 서버 자동 제외 설정

haproxy.cfg 핵심 설정

frontend web_frontend
    bind *:80
    default_backend web_servers

backend web_servers
    balance roundrobin
    server web01 192.168.57.11:80 check
    server web02 192.168.57.12:80 check
03

MySQL Replication 구성

Primary–Secondary 복제를 통해 데이터 동기화와 안정성 구조를 만들었습니다.

MySQL Primary–Secondary 복제를 구성해 Primary 서버의 변경 사항이 Secondary 서버에 반영되도록 설정했습니다. 이를 통해 단일 DB 장애에 대비할 수 있는 데이터 복제 구조를 구현했습니다.

Primary 서버 binlog 기록 기반 데이터 변경 이력 복제

CHANGE MASTER TO 기반 Primary-Secondary 복제 연결 설정

MySQL 복제 설정 핵심

-- Primary (db01)
server-id     = 1
log-bin       = mysql-bin
binlog_format = ROW

-- Secondary (db02)
CHANGE MASTER TO
  MASTER_HOST='192.168.58.13',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=2192,
  GET_MASTER_PUBLIC_KEY=1;
START SLAVE;
04

NFS 파일 공유 구성

웹 서버가 같은 파일을 참조할 수 있도록 공유 파일 시스템을 구성했습니다.

NFS 서버를 두고 WordPress 소스 코드와 업로드 파일을 두 웹 서버가 함께 사용하도록 설정했습니다. 이를 통해 어느 서버로 요청이 들어오더라도 같은 파일을 서비스할 수 있게 했습니다.

두 웹 서버의 WordPress 소스 코드·업로드 파일 공통 참조 구성

NFS 권한 및 SELinux 정책 조정 기반 Apache 동작 연계

NFS 공유 설정 핵심

# NFS 공유 설정 (/etc/exports)
/srv/wordpress 192.168.57.11(rw,sync,no_root_squash)
/srv/wordpress 192.168.57.12(rw,sync,no_root_squash)

# 웹서버 fstab 마운트
192.168.57.20:/srv/wordpress \
  /var/www/html/wordpress nfs defaults 0 0
05

iSCSI 스토리지 구성

DB 저장소를 분리하고 인증 기반 접근으로 보안을 강화했습니다.

iSCSI를 이용해 DB 서버의 데이터 저장소를 네트워크 스토리지로 분리했습니다. CHAP 인증을 적용해 허가된 서버만 스토리지에 접근할 수 있게 했고, MySQL 데이터 디렉토리도 iSCSI 마운트 경로로 옮겼습니다.

서버별 IQN 정의 기반 데이터 저장소 연결 대상 구분

CHAP 인증 적용 기반 인가 서버만 스토리지 접근 허용

_netdev 옵션 적용 기반 부팅 시 네트워크 스토리지 마운트 순서 보장

iSCSI 설정 핵심

# CHAP 인증 설정 (/etc/iscsi/iscsid.conf)
node.session.auth.authmethod = CHAP
node.session.auth.username   = db01_user
node.session.auth.password = ********

# fstab 마운트
/dev/sdb1 /mnt/mysql_data01 ext4 defaults,_netdev 0 0

Results

구성한 인프라가 실제로 동작하는지 확인하기 위해 웹 접속, 데이터 복제, 요청 분산, 장애 대응 테스트를 진행했습니다.

결과 01 — 웹 서비스 및 DB 연결 확인

HAProxy와 각 웹 서버를 통해 WordPress가 정상적으로 열리는지 확인하고, 입력한 데이터가 DB에 저장되고 복제되는지도 함께 점검했습니다.

http://lb01.example.com (-> 192.168.56.10)

http://web01.example.com (-> 192.168.57.11)

http://web02.example.com (-> 192.168.57.12)

db01에 정보가 모두 저장됨

db02에도 복제됨

결과 02 — 로드밸런싱 동작 확인

두 웹 서버의 access log를 동시에 확인해 요청이 번갈아 처리되는지 테스트했고, Round Robin 방식의 분산이 정상적으로 동작함을 확인했습니다.

web01과 web02에서 sudo tail -f /var/log/httpd/access_log 동시 실행

결과 03 — 장애 대응 테스트

웹 서버 하나에서 Apache 서비스를 중지한 뒤에도 HAProxy를 통한 접속이 유지되는지 확인했고, 남은 서버가 요청을 계속 처리하는 것을 확인했습니다.

web01에서 Apache 서비스 중지 - sudo systemctl stop httpd

What I Learned

01

고가용성은 단순히 서버를 여러 대 두는 것으로 끝나지 않는다는 점

웹 서버 이중화뿐 아니라 로드밸런싱, 데이터베이스 복제, 파일 공유 구조까지 함께 설계되어야 서비스가 안정적으로 운영될 수 있다는 점을 직접 확인했습니다.

02

인프라는 설정만 하는 것이 아니라 실제로 동작하는지 검증하는 과정이 중요하다는 점

웹 접속, 데이터 동기화, 요청 분산, 장애 대응 테스트를 진행하면서 구성한 구조가 실제로 어떻게 동작하는지 직접 확인할 수 있었습니다.