티스토리 뷰

반응형

요즘은 서버를 분산시켜 관리하는 경우가 많습니다. 심지어 MSA로 전환되는 경우에는 각각 서버를 따로 운영하는건 너무 많은 비용을 야기하는데요 이럴 때 효과적인 방법으로 관리하기 위해 나온 클러스터라는 개념이 있습니다. 회사에서 부하 분산 서버를 클러스터로 전환하면서 배운 것들을 공유드리겠습니다.

 

사전에 이 글을 읽어보시는걸 추천드립니다.

https://golf-dev.tistory.com/56

 

[Docker 4주차] Docker Swarm

도커 스웜을 사용하는 이유 보통 현업에서는 지금까지 한 것 처럼 호스트 하나로만 이루어져 있지 않습니다. 이유는 간단합니다. CPU나 메모리, 디스크 용량같이 자원이 부족한 경우에 스케일 아

golf-dev.tistory.com

부하 분산서버

부하 분산 서버는 하나의 Load balancer가 있으면 라운드 로빈 같은 방식으로 요청을 분산시켜 각 서버에 전달되는 방식으로 아키텍처는 다음과 같습니다. 

flow를 설명드리면 도메인으로 443포트로 요청이 오면 Load Balancer가 요청을 무조건 앞에서 받습니다. 그리고 보통 보안을 위해 사설 IP로 각 서버에 요청을 보내는 식으로 구성이 되어있습니다. 

 

이 방식은 다음과 같은 문제점이 존재합니다.

  • 로그를 한 눈에 볼 수 없다. 
  • 서버가 장애 시 Load Balancer가 Health check로 감지는 해주지만 다시 서버 개수를 유지하기 위한 후처리는 지원해주지 않는다.
  • 서버가 replica 개수를 줄이는 데에도 너무 많은 비용이 든다.
    (먼저 LB가 요청을 더 이상 해당 서버로 보내지 않게 트래픽을 끊고 이 후 서버를 직접 shutdown해줘야한다.

클러스터 서버로의 전환 

클러스터는 병렬로 확장된 서버들을 매니저 개념의 하나의 서버가 관리합니다. 또한 여기서 하나의 서버는 노드로 불리며 그 중에 전체 클러스터를 관리하는 서버는 매니저 노드라고 불립니다. 

클러스터 서버를 docker swarm 아키텍처를 이용해 표현해보겠습니다. 

먼저 요청이 LB를 통해 분산되면 각각의 manager 노드가 적절히 분산하여 레플리카 서버에 요청을 분산시킵니다. 그리고 반드시 active 상태의 서버에만 보내기 때문에 트래픽이 엉뚱한 곳으로 가진 않습니다. 또한 metric이나 log를 manager에서 한 번에 관리가 가능합니다.

 

결론적으로 부하 분산에서의 문제점을 클러스터 서버는 모두 해결할 수 있습니다. 다만 장점만 있는 것은 아닙니다.

 

클러스터 서버도 장점만이 있는 것은 아닙니다. 우선 kubernetes나 docker swarm을 이용해야하기 때문에 추가 infra 구성이 필요하고 또한 kubenetes와 docker swarm은 매니징을 위한 추가 네트워크 발생 비용이 존재합니다. 또한 클러스터 서버는 manager에 장애가 생길 시 클러스터에 포함된 서버가 운영이 안될 수 있기 때문에 manager에 대한 fail over도 반드시 구성해야합니다. 

보통 3대 이상의 홀수개로 둬야하는데 이는 리더 선출 알고리즘의 특성 때문에 그렇습니다. 그리고 이렇게 추가 구성된 서버로 인해 규모가 작은 간단한 서비스에선 추가 비용이 나갈 수 있습니다. 

 

그럼 클러스터 서버를 운영하기엔 어떤 솔루션을 적용하기 좋을까요? 

  • Kubernetes
  • Kubernetes Manager
  • Docker swarm

위 3가지가 대표적인 솔루션인데요. 그 중에 저는 docker swarm을 사용했는데요 당시 제가 docker에 대한 지식이 있었던 점과 docker만 설치하면 swarm을 통해 간단하게 클러스터 서버를 구축해준다는 점을 미루어보았을 때 혼자서 구축하기 가장 좋아 도입하게 되었습니다. 

 

그렇다면 docker swarm은 어떻게 세팅할 수 있을까요? 

우선 서버는 3대가 있다고 가정하고 진행하겠습니다. 그리고 3대 모두 docker가 현재 설치 되었다는 가정하에 시작합니다.

그 중 한 개의 Leader가 될 노드를 선정하고 swarm을 시작합니다. 그 후 토큰을 발급해줍니다. 

# eth0 정보를 확인
server1 $ ifconfig

# docker swarm init
server1 $ docker swarm init --advertise-addr=eth0

# publish token
server1 $ docker swarm join-token manager

위 프로세스를 순서대로 진행하면 token이 발급되는것을 확인할 수 있을 겁니다.

To add a manager to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-05r99wehqwu4ic31783gk9o24sq9kfjut4ruoaybmpzs3dtor-304dquwuj5k46baa59einuv8 10.187.199.119:2377

 

이 후 나머지 두 노드에 발급된 토큰을 입력하여 클러스터에 join 시켜줄 수 있습니다. 

 

# 각 서버에 swarm에 참여 시키기

server2 $ docker swarm join --token SWMTKN-1-05r99wehqwu4ic31783gk9o24sq9kfjut4ruoaybmpzs3dtor-304dquwuj5k46baa59einuv8 10.187.199.119:2377

server3 $ docker swarm join --token SWMTKN-1-05r99wehqwu4ic31783gk9o24sq9kfjut4ruoaybmpzs3dtor-304dquwuj5k46baa59einuv8 10.187.199.119:2377

 

자, 이제 docker swarm을 쓰기위한 준비를 모두 마쳤습니다. 현재 3개의 클러스터 서버가 존재하고 각각 manager 노드가 존재할겁니다. 그리고 이 3개의 manager 중 하나가 장애가 발생하더라도 리더 선출 알고리즘을 통해 되살릴 수 있습니다. 

 

두 눈으로 확인하고 싶으시다면 다음 명령어로 확인해볼 수 있습니다. 

server1 $ docker node ls


다음 글에서는 docker swarm에 실제 서버를 배포하기 위해 Dockerfile과 docker-compose.yml 파일을 구성할 것이고 또 어떻게 구성해야 유연한 서버 운영이 가능한지 고민해볼 것입니다. 

마침.

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/12   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
글 보관함