이 포스트는 널널한 개발자님 강의를 참조하며 작성하였습니다.
L4 부하분산과 무정지 시스템
L4 스위치가 있는데 이 L4 스위치는 포트번호를 기반으로 스위칭된다. 그런데 이것을 주로 어디서 사용하냐면 부하분산 즉, LoadBalancer에 사용이 된다. 예를 들어서 인터넷에 각종 호스트들이 연결되어 있다고 해보자. 그런데 이 호스트들이 www.abc.com에 접속한다고 해보자. 그러면 당연히 DNS가 IP주소를 알려줄 것이다. 그런데 그 주소가 15.15.15.15:80이라고 가정하다. 그러면 이 호스트들이 해당 IP에 HTTP접속을 시도할 것이다. 그런데 위 그림의 라우터를 웹서버라고 했는데 이것은 호스트관점에서 웹서버인것이고 사실은 LoadBalancer로 작동한다. 그래서 15.15.15.15:80으로 접속하면 LoadBalancer는 마치 NAT처럼 포트포워딩을 한다. 즉, 어느 호스트가 접속하는 순간 LoadBalancer는 뒤에 있는 웹서버의 번호 순서대로 1번한테 전달할 것이다. 그리고 전달받은 서버는 응답을 보낸 호스트한테 전달할것이다. 그리고 또 다른 호스트가 접속을 했다고 하자. 그러면 이제 LoadBalancer가 2번 서버한테 전달을 줄 것이고 똑같이 응답을 해당 호스트에게 줄 것이다. 여기서 중요한 부분은 이렇게 서버가 여러대일지 몰라도 내용이라는 측면에서 동일한 서버이다. 그러니까 다 clone들이다. 딱 다른 부분은 사설IP주소 설정만 다르고 내용적으로 모두 동일한 clone들이다. 즉, 이 서버중에 어디로 접속하든 같은 내용을 받게 될 것이다.
LoadBalancing한다는 것은 별게 아니고 부하가 오면 뭔가 접속해서 처리해야 할 연산이 있다면 그걸 어떤 여러대 서버중에 적정한걸 1대 골라서 매핑해주는 것이다. 그리고 매핑할 때 부하가 모든 순서대로 1번 웹서버부터 순차적으로 매핑해주는 방식이 Round-Robine방식이다. 이런 방식으로는 서버를 운영할 수가 없다. 물론 운영은 할 수 있지만 이 방식이 매우 안 좋은 방식이고 부하분산을 제대로 할려면 Round-Robine방식 말고 health-check라는 기능이 들어가야 한다. health-check가 무엇이냐면 위의 그림처럼 n대의 서버가 있는것은 같지만 이 외에 이 n대의 서버와 연결된 Manager 서버가 등장한다. 또한 이 Manager서버는 LoadBalancer와도 연결이 되어있다. 그래서 여러 호스트들이 접속한다면 LoadBalancer가 어느 서버로 접속해줄지 결정을 하는데 이 결정 기반이 Manager서버가 실시한 health-check기반으로 한다. Manager서버는 n대의 서버의 부하량(CPU점유율, RAM메모리 사용량, 디스크 여유공간등)을 평상시에 매일 체크를 하다가 LoadBalancer에 트래픽이 딱 들어오는 시점에 Manager서버는 n대의 서버중에 가장 부하량이 적은 서버를 알려주고 LoadBalancer는 해당 서버로 트래픽을 보낸다. 그런데 만약에 어느 특정서버가 지속적으로 부하량이 80%이상이라고 하면 어떻게 될까? 당연히 장애가 날 위험이 있다고 판단하고 Manager 서버는 그 서버를 격리시킨다. 그리고 서버 관리자가 그 서버를 A/S를 보낸다. 그리고 다른 서버를 집어넣는 방식으로 운영이 된다. 여기서 핵심이 뭐냐면 장애가 날려는 서버는 빠졌지만 클라이언트 입장에서는 웹서버가 멈췄다는 생각은 안 들것이다. 그래서 이런 시스템을 무정지 시스템이라고 한다.
그래서 이런 무정지 시스템이 되려면 안전성이 극대화되어야 한다. 그래서 이런게 L4수준의 부하분산이고 평상시 장애상태라던가 health-check를 지속적으로 하고 그 외에 추가적으로 WAS를 모니터링하는 등 이런 개념들이 포함되면서 시스템들이 점점 커지게 되는 것이다. 여기서 만약 n대의 웹서버는 다 살아있지만 만약 LoadBalancer가 다운되면 어떻게 될까? 예상이 되지만 당연히 시스템 장애가 발생할 것이다. 이런것을 위해 LoadBalancer를 이중화구조를 취한다. 물론 Manager서버도 마찬가지다.
요즘 무정지 시스템의 최근 트렌드는 여러대 웹서버를 VMS로 두는 것이다. 즉 이렇게 되면 장애발생 웹서버를 A/S를 안보내고 재부팅 후에 스냅샷으로 복원시키면 되기 때문에 훨씬 비용적 측면에서 절약이 된다. 또한 이런 VMS들의 원본 VMS가 있는데 이 원본에 보안패치 후에 다른 n대 VMS를 재부팅하고 자동화하고 이런 효율적인 측면에서의 고민과 자동화 고민이 부상되면서 떠오르는 기술이 Docker이다. 그리고 관리적 이슈를 자동화하기 위해 kubernetes가 부상이 되었다.
요즘은 LoadBalancer부터 Manager서버까지 다 클라우드 환경에 존재하고 이런 도커나 쿠버네티스같은 기술을 잘 활용하기 위해 Devops 엔지니어도 부상이 되는것이다.
