다중화란?

이 포스팅은, 서버/인프라를 지탱하는 기술을 읽고 진행하는 스터디의 내용을 정리하였습니다.

다중화란? 

- 다중화란, 장애가 발생해도 예비 운용장비로 시스템의 기능을 계속할 수 있도록 하는 것을 말한다. 

다중화의 대상은 Server, Load balancer, Network Device 등이 있을 수 있다. 

단일장애점(SPOF)을 없애고 무중단/고가용성 서비스를 위해 다중화가 필요하다.

OnPremise환경에서의 다중화 관점

1) 장애를 상정한다.

2) 장애에 대비해서 예비 운용장비를 준비한다.

3) 장애가 발생했을 때 예비 운용장비로 교체할 수 있는 운용체제를 정비한다.

- 유휴장비 역시 비용이므로 ROI에 따라 다중화 수준을 정한다.

HealthCheck

ICMP/Port/HTTP 등을 요청하여 응답여부 체크

ping check의 경우 IP 정보만으로 요청이 가능한지를 확인하며,

port check의 경우 해당 서비스의 정상 구동 여부를 확인할 수 있다.

HTTP request의 경우 HTTP status code를 기반으로 보다 상세하게 이상유무를 판단할 수 있다.

기본 구성(Active/StandBy)

VIP를 할당하고 장애 발생시 예비 운용장비가 VIP를 인계한다.

구성 방식은 HSRP, VRRP 등의 프로토콜을 활용할 수 있으나, 내부적으로는 GARP를 사용하게 된다.

* GARP? 

장비가 ARP 패킷을 broadcast를 통해 같은 네트워크상에 있는 다른 장비에 자신의 존재를 알리는 목적으로 사용한다. 

이 경우 시스템은 아무런 정보도 얻지 못하지만 이 장비에 대한 엔트리를 가지고 있는 장비는 자신의 ARP cache를 갱신하여 이 장비의 엔트리가 만료되지 않도록 한다. 

또한 MAC 주소 변경시에 다른 호스트의 Cache를 갱신할 목적으로도 전송하며, 

이중화 게이트웨이 프로토콜(HSRP/VRRP)에서 Active Router가 변경되었을 경우 새로 활성화된 Router가 이를 발송한다.

* VRRP? 

보통은 Active/StandBy 형태로 구성하지는 않고(비효율적), LB를 앞단에 두어 부하분산을 한다. 

과거에 DNS RR 방식으로도 구성하였으나, 이는 

1) 서버의 수만큼 IP주소가 필요 

2) 균등하게 분산되지 않음(캐싱, 프록시 서버 경유 등) 

3) 서버가 다운되어도 감지하지 못하는 등의 문제로 자주 사용되진 않는다.

LB는 OSI 7 Layer 기준으로 L4/L7으로 나뉜다.

L4SW의 경우 IP주소나 포트번호에 따라 분산대상 서버를 지정할 수 있다.

L7SW의 경우 URL에 따라 분산대상 서버를 지정할 수 있다.

L4SW에서는 클라이언트가 통신하는 곳은 리얼서버지만, 

L7SW에서는 로드밸런서와 클라이언트가 TCP 세션을 전개한다.

LB 장비가 고가이므로, 오픈소스인 ipvs를 사용하여 구성하는 것도 고려할만 하다.

- ipvsadm : command tool

            가상서버를 정의하고 리얼서버를 할당

            설정내용/접속상황/전송률 등을 확인

- keepalived : 설정파일을 기준으로 IPVS의 가상서버를 구축

               다운된 서버를 부하분산에서 제외

               모두 다운되었을 경우 에러 메시지 전송

스케줄링 알고리즘

- rr : 모든 서버 균등

- wrr : 가중치 부여

- lc : ESTABLSHED/TIME_WAIT/FIN_WAIT인 접속수가 가장 적은 서버

- wlc : wrr + lc

- sed : ESTABLSHED인 접속수가 가장 적은 서버

- nq : sed (+ active가 0인 서버 최우선)

---

추가적으로..

DNS 다중화

주소 변환 라이브러리를 이용한 다중화와 문제점
/etc/resolv.conf에 여러 DNS 서버를 지정할 경우,
질의가 타임아웃되면 다음 네임서버에 질의하는데, 이 때 지연현상이 발생한다.(디폴트는 5초)
만약 네임서버가 장애라면 매번 질의할 때마다 지연현상이 발생하여 성능저하가 나타난다. 이 경우 '성능은 저하되지만 에러가 발생하지 않는' 상황이기에, 장애의 발견을 늦추는 요인이 된다.
따라서 DNS 서버를 다중화해야 한다. 이 때 방식은 VRRP/LoadBalancing 등의 방식이 있다.

Storage Server 다중화 (DRBD로 미러링 구성)

스토리지 서버의 장애 대책

하드디스크 고장에 의한 데이터 손실은 복구하기 어렵다,.
복구작업은 보통 백업한 데이터로 recovery하는 것이지만, 모든 파일을 복구하는데에는 많은 시간이 소요된다.
따라서 RAID 구성이 필요하나, 이 경우에도 만약 RAID 컨트롤러가 고장난 경우엔 데이터 손실이 발생할 여지도 있다. 결국 스토리지 서버도 다중화해야 한다.

스토리지 서버의 동기화 문제
두 대의 서버에 대해 파일 단위로 디스크를 동기화하거나 정합성을 체크하면 파일 개수가 많아질수록 디렉토리 검색이나 비교에 시간이 오래 걸린다.
또한 그런 경우 하드디스크에 과도한 부하가 걸리므로 서버 전체의 성능이 크게 저하된다.

• DRBD
  
  네트워크를 이용한 RAID1라고 생각하면 된다.
  DRBD는 실제 사용하는 블럭 디바이스의 I/O 명령을 대신 받아서 처리한다. 실제 블럭 디바이스에 데이터를 쓰고 해당 데이터를 네트워크를 통해 mirroring 되는 장치로 보낸다.

---

책의 범위는 아니지만 다중화와 관련된 주제들

Nginx를 활용한 부하분산

- LB vs Reverse Proxy: https://www.nginx.com/resources/glossary/reverse-proxy-vs-load-balancer/

LB: 부하분산, 서버상태체크, 세션관리

Reverse Proxy: 보안성향상, 확장성향상, 웹가속(압축/SSL처리로 백엔드 리소스 확보/캐싱)

PublicCloud 환경에서의 다중화(scale up -> scale out)

- multi az

- elb(alb) + auto scaling

  CPU, Memory 외에도 Tomcat의 Thread나 DB Idle count 등의 metric도 임계치로 설정 가능

Container 운용상에서의 다중화(표준화,코드화)

- ami 등 이미지의 단점: 세부 내용을 보거나 변경이 어려움(버전관리 x)

  Dockerfile을 통해 코드화 가능

- Container란, 리눅스 기술을 사용하여 선박의 컨테이너처럼 프로세스가 사용하는 자원을 격리

  Docker의 경우 이미 존재했지만 사용하기 어려웠던 리눅스 기술들

  (Namespaces, Cgroups, Storage, Networking, Security 등)을 잘 포장하여 제공

  기존 OS위에 GuestOS를 올려 Hypervisor를 통해 하드웨어 자원을 할당받아 사용하던 VM과 비교하여, 

  HostOS 위에서 동작하는 Docker가 훨씬 효율적

- Docker는 cold booting이 없으므로 scale out하기에 유연하며, 

   aufs 를 사용하여 layer로 구성되어 있기 때문에 fetch도 수월하게 진행된다.

Kubernetes

https://brainbackdoor.tistory.com/107

gRPC

https://grpc.io/blog/loadbalancing