세미프로젝트-웹 서비스 인프라 환경 구축(1/17~1/20)

최수환·2023년 1월 17일

Kubernetes

목록 보기

23/75

4일이라는 기간동안 아래의 인프라를 구축하는 세미 프로젝트를 진행 할 예정이다.

웹 서비스 구축 및 이중화

dns서비스 구축 및 이중화

웹 서버 로드밸런싱

SSL을 이용한 HTTPS적용

스토리지, FTP, NFS, DB 등의 인프라 구축

인프라 맵 설계

web서버는 nginx로 구성하고 이중화를 위해 두개 서버를 구축할 것이다.
이후 web서버 앞에 마스터/슬레이브 dns서버를 배치하여 dns쿼리에 대한 로드밸런싱을 구축할 것이다
HAPROXY를 이용하여 웹 서버에 트래픽에 대한 로드밸런싱을 구축할 것이다
HAPROXY에 SSL을 적용하여 HTTPS로 웹 서버에 접속할 것이다
이후 시간이 된다면 스토리지 및 파일공유 시스템을 구축할 것이다

웹 서비스 구축

웹 서버는 nginx를 이용하기로 하였다.

두개의 웹서버를 위한 가상머신 두대를 구동한다.
각각의 가상머신에 nginx를 이용해 웹 서버를 설치한다

<nginx 설치 및 실행>

vi /etc/yum.repos.d/nginx.repo 접속 후 아래 사진처럼 작성 후 저장
yum -y install nginx
firewall-cmd --permanent --zone=public --add-port=80/tcp
firewall-cmd --reload
systemctl start nginx
systemctl enable nginx
브라우저에서 http://localhost 로 접속 잘되면 완료
💡 nginx의 웹 표시 파일은 /usr/share/nginx/html/ 디렉터리에 존재한다 -> index.html 파일도 여기에 존재
💡 apache는 /var/www/html에 존재

<php 설치>

yum -y install epel-release yum-utils
yum -y install https://rpms.remirepo.net/enterprise/remi-release-7.rpm
yum-config-manager --enable remi-php73
yum install php php-common php-opcache php-mcrypt php-cli php-gd php-curl php-mysqlnd
php -v를 통해 버전이 7이상인지 확인

<php-fpm 설치>

yum install -y php-fpm
vi /etc/php-fpm.d/www.conf 접속 후 아래 사진처럼 수정
- ';' 주석이 있으면 제거
  -> 명령모드에서 :/ 원하는 단어 : 단어 검색
  📒 n으로 다음 단어 검색
systemctl start php-fpm
systemctl enable php-fpm
vi /etc/nginx/conf.d/default.conf 접속 후 아래 사진처럼 수정
- 📒 /etc/nginx/에 nginx 설정 파일들이 있다
systemctl restart nginx
/usr/share/nginx/html/에 phpinfo.php파일을 만들어 아래 사진처럼 저장

-> 웹에 http://192.168.56.101:8089/phpinfo.php 로 잘 접속되는지 확인

📒 nginx-php 연동 참고
📒 LAMP구축 참고

db 설치 및 wordpress연동

yum -y install mariadb mariadb-server
systemctl start mariadb
systemctl enable mariadb
yum -y install php-mysql
mysql_secure_installation
mysql -u root -p
create databse wordpress
create user wordpress@localhost identified by "1234"
GRANT ALL PRIVILEGES ON wordpress.* TO wordpress@localhost;
FLUSH PRIVILEGES; : 권한 재갱신

< 워드프레스 설치 >

cd /tmp
wget http://wordpress.org/latest.tar.gz
tar xvzf latest.tar.gz -C /usr/share/nginx/html
cd /usr/share/nginx/html 로 이동
chown -R nginx /usr/share/nginx/html/wordpress
systemctl restart nginx

<워드프레스 접속>

브라우저에서 http://localhost/wordpress
기타 설정 후 로그인하면 끝

DNS 서버 구축 및 이중화

dns서버 이중화라고 하면 간단하게 master, slave dns가 두개 있다고 생각하면 된다
master-slave는 동기화 과정을 통해 zone파일을 관리하는데 master의 zone파일에 SOA필드에 있는 serial값의 변화가 생기면 파일이 업데이트가 되었다고 판단되어 slave서버로 zone파일을 보내 동기화를 진행한다. 이런 동기화 과정이 바로 zone transfer이고 이때 사용되는 포트가 53/tcp이다
-> 따라서 master dns에서 장애 발생시 슬레이브 dns 서버에서 중단없이 서비스를 지속적으로 제공할 수 있다.

가상머신을 총 5개 세팅한다

웹 서버용 2개 : nginx로 이미 구축 되어있음
master dns용
slave dns용
client : test하기 위함

yum -y install bind*
/etc/named.conf 설정 파일 들어가서 아래 사진처럼 저장
/etc/named.rfc1912.zones에 들어가서 아래 사진처럼 저장

-> allow-update{ slave서버 IP; }
cp named.localhost project.com.zone : 서비스할 zone 파일 생성
만든 zone파일 project.com.zone에 접속 후 아래 사진처럼 저장

-> ns1은 master서버로, ns2는 slave서버로 설정 => 각각에 알맞은 IP입력
-> 접속할 웹 서버의 주소(10.0.2.7) 입력
방화벽 해제 : firewall-cmd --add-service=dns --permanent , reload
systemctl restart named
systemctl enable named

master dns와 똑같이 모듈 설치 후 named.conf파일 수정
/etc/named.rfc1912.zones 파일 접속 후 아래 사진처럼 수정 후 저장

-> 도메인은 똑같되, 타입은 slave, allow-update지우고
masters { master ip; } 입력
방화벽 해제, reload
systemctl restart named
systemctl enable named
실제로 /var/named/slaves 디렉터리에 아까 생성한 zone파일을 가져왔는지 ls -lh로 확인
master서버의 /var/log/messages에서도 확인 가능

client에 /etc/resolv.conf파일 접속 후 아래 사진처럼 master와 slave의 nameserver ip를 등록
nslookup에서 project.com을 입력

-> master가 존재할 때는 master가 project.com의 ip를 찾아내는 것을 볼 수 있다
-> master를 시스템 종료하고 다시 project.com을 입력했을 때 slave서버에서 project.com의 ip를 찾아내는 모습을 확인

<웹 서버 두개 구축 후 dns이중화 확인>

master의 /var/named/ 디렉터리에 zone파일에서 아래 사진처럼 새로 추가한 웹 서버의 ip추가

-> ip 추가후 serial값 +1변경 후 systemctl restart named
-> slave dns서버도 systemctl restart named
-> zone파일의 변경사항을 zone transfer로 master와 slave가 동기화 한다
위 사진처럼 nslookup으로 project.com을 찾으면 이번엔 마스터dns가 두개의 웹 서버의 ip를 반환하는 것을 확인
-> 마스터dns 종료 후 다시 project.com을 찾으면 slave dns가 두개의 웹 서버의 ip를 반환하는 것을 확인

💡 DNS 이중화 참고

웹 서버 이중화

고가용성을 위한 웹 서버를 두개 배치하였고 각 웹서버에 트래픽을 보내 헬스체크 및 가중치 부하분산 역할을 하는 로드밸런서를 구현 할 것이다.
로드밸런서는 HAPROXY를 이용하여 구축할 것이다.

가상머신을 총 6개 세팅한다

웹 서버용 2개 : nginx로 이미 구축 되어있음
master dns용 : 구축완료
slave dns용 : 구축완료
client : test하기 위함
HAPROXY 서버용

HAPROXY

L4 스위치

IP, Port, Session을 기반으로 로드밸런싱하며 왠만한 서비스는 이것만으로 부하분산이 충분히 가능하다
단점
- L4는 VIP(가상 IP주소) 단위로만 로드밸런싱하기 때문에 반드시 하나의 VIP에 연결된 서버의 수가 비슷해야 한다.
  만일 일부 서버에 문제가 생기면 동일한 VIP에 연결된 다른 서버 역시 연달아 부하가 발생하여 더 심각한 문제를 초래한다
- L4의 스펙상 최대 세션 수는 존재하나 시나리오에 따라 맺을 수 있는 최대 성능이 달라진다. 따라서 최대 세션에 도달하지 않았어도 추가로 세션을 연결할 수 없는 문제가 있다
  -> 예시로, 통신사 장애 등으로 세션이 비정상 종료된 시나리오에서 세션 서버는 클라이언트와 세션이 종료되고 정상적으로 다시 연결했지만 L4에서는 세션종료가 되지않아 두개의 세션을 동시에 유지하고 있어서 L4한계 용량을 초과할 수 있다.

L7 스위치

Application Layer에서 동작하는 스위치로 HTTP URI,
FTP 파일명, 쿠키정보 packet payload(관심있는 데이터)를 분석하여 좀 더 정교한 로드밸런싱이 가능하다
= 콘텐츠 기반 스위칭
L7은 L4보다 보안적으로 우수하다. 데이터 분석을 통해 DDos공격 방어 및 감염 패킷의 필터링이 가능하다

URL 스위칭 방식 : URL 주소를 확인하여 설정에 맞는 서버로 부하 분산
Cookie 스위칭 방식 : HTTP Header의 cookie값 설정에 따라 스위칭
Content 스위칭 : HTTP Header와 XML content를 기반으로 스위칭

세션 유지 방식

L4
- 스위치가 세션을 관리함(패킷을 확인하고 연결될 서버와 세션을 생성)
- sticky session : 사용자가 특정 서버와 세션을 생성한 경우, 일정 시간 동안 해당 서버에 추가적인 연결을 시켜주는 기능
L7
- 클라이언트와 서버 각각 세션을 맺고 두 세션을 연결시켜 관리한다.

HAPROXY

HAPROXY(High Availability Proxy)는 TCP와 HTTP 기반 어플리케이션을 위해 사용된다. 오픈소스 로드밸런싱의 표준 중 하나이며, 다양한 리눅스 버전에서 사용할 수 있다.
HAProxy는 기본적으로 리버스 프록시(Reverse Proxy) 형태로 동작한다.

최초 접근 시 서버에 요청 전달
응답 시 쿠키에 서버 정보 추가 후 반환
재요청시 PROXY에서 쿠키 정보 확인 및 최초 요청 서버로 전달
다시 접근 시 쿠키 추가 없이 전달(쿠키 재사용, 클라이언트에 쿠키 정보 계속 존재)

HAPROXY 구성

소프트웨어 기반 솔루션이기 때문에 HAProxy가 설치된 서버에 장애가 발생하면 하드웨어 L4보다 불안정할 수 있다. 때문에 master HAProxy에 문제가 생겨도 페일오버할 수 있도록 HA구성을 한다.

HAProxy는 기본적으로 VRRP(Virtual Router Redundancy Protocol)를 지원한다.

HAPROXY 구성

준비된 haproxy서버에 접속 후 /etc/hosts파일에 아래와 같이 웹 서버 두개를 등록해준다
각 웹서버의 /etc/hosts파일에 아래와 같이 haproxy서버를 등록한다
haproxy서버에서 yum -y update, yum -y install haproxy 실행
cd /etc/haproxy/ 접속 후
mv haproxy.cfg haproxy.cfg.orig로 원본 설정파일 백업해놓는다
vi haproxy.cfg파일 접속 후 HAPROXY 참고1의 내용을 붙여넣는다
-> 맨 마지막줄에 자신의 웹 서버 ip를 넣는다
-> 나중에 stats확인하기 위한 id/passwd도 변경한다
vi /etc/rsyslog.conf 접속 후 아래와 같이 주석 해제하고 추가한다
/etc/rsyslog.d에 접속해 vi haproxy.conf파일을 생성 후 아래와 같이 저장한다
systemctl restart rsyslog, systemctl restart haproxy
systemctl enable haproxy로 데몬을 실행시킨다
firewall-cmd --add-service=http --permanent
firewall-cmd --add-service=dns --permanent
firewall-cmd --zone=public --add-port=8080/tcp --permanent
firewall-cmd --reload
이전에 설치한 각 웹서버에 /usr/share/nginx/html에 존재하는 index.html에 test를 위해 텍스트를 저장한다
각 웹 서버에서 systemctl restart nginx 실행
이후 브라우저에 haproxy의 ip를 입력하면 웹서버1, 웹서버2가 차례대로 출력되는 것을 확인할 수 있다.
haproxy서버에서 curl haproxyip입력하면 ip가 계속 바뀌어 웹서버가 호출되는 것을 볼 수 있다
브라우저에 http://haproxyip:8080/stats입력하면
로드밸런싱이 되고 있는 상태창과 각 웹서버의 상태를 볼 수 있다

dns와 haproxy 연동

생각해보니 haproxy도 별도의 서버이고 dns도 별도의 서버이다. 따라서 client는 무조건 도메인을 입력할 것이고 dns가 이것을 제일 먼저 받아서 ip를 찾을 것이다. 이후 haproxy서버에 전달하면 haproxy는 이미 자신과 연결되어있는 웹 서버들중 로드밸런싱을 통해 특정 웹 서버에 연결할 것이다.
따라서 이전에 dns 이중화 작업에서 했던 zone파일을 수정할 것이다.
1. master dns의 zone파일에서 아래 사진처럼 이전의 웹 서버의 ip는 지우고 haproxy서버의 natip만 작성후 저장 + serial값 1증가

2. systemctl restart named후 slave dns에서 restart실행
3. slave에서 /var/named에 zone파일이 동기화 되어있는지 확인

웹 서버 / DNS 이중화 확인

클라이언트에서 curl -L 도메인 실행했을 때 웹이 번갈아가면서 호출되는 것을 볼 수 있다 = 로드밸런싱

nslookup으로 project.com의 ip를 찾았을때 마스터dns가 haproxy의 주소를 알려주는 것을 확인
master dns를 종료햇을때 slave가 haproxy의 주소를 알려주는 것을 확인

브라우저에 haproxyip:8080/stats입력했을 때 보이는 웹으로, 실제 curl로 해당 웹을 호출했을 때 total값이 증가하는 것을 확인

haproxyip를 브라우저에 입력했을때 번갈아가면서 index.html의 문구가 보이는 모습을 확인

📒 참고로 생각보다 방화벽이나 데몬을 재실행시키지 않아서 생기는 문제가 대다수였다.

HAPROXY 참고2
HAPROXY 참고3

haproxy에 ssl적용

cd /etc/haproxy
mkdir tls
tls디렉터리에 파일 생성

openssl genrsa -out private.key 2048 : 개인키 생성
openssl req -new -key private.key -out cert.csr : cert.csr 생성
서버의 정보를 입력한다
openssl x509 -req -signkey private.key -in cert.csr -out cert.crt : cert.crt 생성
openssl rsa - in private.key -text > key.pem : 공개키 생성
openssl x509 -inform PEM -in cert.crt > crt.pem : x509인증서 생성
openssl pkcs12 -export -in cert.crt -inkey private.key -out cert.p12 : pkcs12파일 생성
openssl pkcs12 -in cert.p12 -nodes -out cert.pem : pem파일 생성
ls로 생성된 파일 확인
vi /etc/haproxy/haproxy.cfg에 접속해 아래 사진처럼 수정 및 추가

- bind *:443 ssl crt /etc/haproxy/tls/cert.pem : pem키가 있는 절대 경로 입력
- http-request redirect scheme https unless { ssl_fc } : http로 접근할 경우 https로 redirect
- haproxy 서버에 ssl인증서 업로드 및 설정을 하였기 때문에 , haproxy서버에서 ssl암호화 처리 후 backend에 설정된 웹서버로 전송이 되므로 각 서버의 https가 아닌 http포트로 연결이 필요

haproxy -f /etc/haproxy/haproxy.cfg -c 로 파일 이상유무 체크
systemctl restart haproxy.service

haproxy에 ssl적용 확인

-> haproxy서버의 ip를 입력하면 '안전하지않다는 페이지'가 보인다. 고급에 '안전하지않은 페이지 계속'을 누르면 해당 ip가 ssl이 적용된 https로 나타나는 것을 확인할 수 있다
📒 CA(공식 인증기관)에서 인증받은 인증서로 만든 SSL이 아니기 때문에 '안전하지 않은 페이지'가 나타나는 것이다.