개인 서버의 무중단 서버 구축

안녕하세요. 현재 저의 서버로 구축하고 있는 환경에 관해 설명하고자합니다.
저는 온프레미스(On-premise) 환경에서 Docker Stack 배포하는 docker swarm , 그리고 kuberneter k8s 를 구축한 경험을 가지고 있습니다.

해당 블로그는 Docker Swarm 을 기반으로 온프레미스(On-premise) 환경에서의 죽지 않는 서버 즉, 무중단 서버로 구축을 하였습니다.

서바가 죽지 않는 이유는 Docker Swarm이 제공하는 내재적인 고가용성(High Availability) 및 복구 메커니즘 때문입니다.

---

아래와 같은 9가지를 적용하며, 구축을 진행했습니다.

1. 서비스 복제(Replication)
2. 오토 힐링(Auto-Healing)
3. 서비스 상태 관리(desired state reconciliation)
4. 리소스 분산 및 로드 밸런싱
5. 리더 선출 및 매니저 노드 복구
6. 노드 장애 복구
7. 재시작 정책(Restart Policy)
8. NFS와 같은 공유 스토리지의 활용
9. 스케일링 및 롤링 업데이트

---

1. 서비스 복제(Replication)

deploy:
  replicas: 3

복제(replication) 를 정의할 수 있습니다. 복제본이 항상 정해진 수로 유지되도록 관리하며, 특정 노드나 컨테이너가 장애가 나도 서비스가 지속됩니다.

우선적으로 매니저노드와 워커노드에 관련해서 알아봐야 합니다.
매니저 노드와 워커노드는 서버하나당 지칭을 합니다. 그 중에서 매니저 노드는 리더 선출(Leader Election) 알고리즘을 사용해서 고가용성을 보장합니다.
이 알고리즘은 Raft Consensus를 기반으로 하며, 다음과 같은 특징이 있습니다

• 클러스터에서 합의(consensus)를 이루기 위해 전체 매니저 노드 중 과반수의 동의가 필요합니다.
• 과반수는 n/2 + 1의 노드가 필요하므로, 다음과 같은 매니저 노드 구성이 가능합니다.
  - 1개 : 단독 운영이 가능하지만 고가용성 불가
  - 3개: 1개의 노드가 장애가 나도 과반수 유지 가능(고가용성)
  - 5개: 2개의 노드가 장애가 나도 과반수 유지가능(고갸용성 강화)
  - 짝수 매니저는 권장되지 않습니다. 과반수를 구성하기 어려운 구조이기 때문입니다.

그렇기 때문에 매니저 노드가 최소 3개여야합니다. 즉 장애 복구 및 리더 선출이 가능합니다. 워커노드는 몇개든지 유연하게 스케일 아웃(Scale-Out)을 할 수 있습니다.
결국 Docker Swarm 클러스터는 스케일 아웃(Scale-Out) 아키텍처로 설계된 오케스트레이션 도구입니다. 스케일 아웃은 수평확장을 통해 시스템의 성능과 가용성을 높이는 방식입니다.

스케일 아웃의 장점

1. 고가용성(HA): 매니저 노드와 워커 노드가 장애를 일으켜도 시스템이 지속적으로 동작.
2. 확장성: 시스템의 요구에 따라 노드를 추가하여 처리량을 유연하게 확장.
3. 비용 효율성: 스케일 업보다 저비용으로 처리량을 증가시킬 수 있음(저가 하드웨어 활용 가능).
4. 부하 분산: 여러 노드에 워크로드를 분산하여 성능을 최적화.

2. 오토 힐링(Auto-Healing)

Docker Swarm은 컨테이너를 지속적으로 모니터링하고, 문제가 발생한 컨테이너를 자동으로 재시작하거나 다른 노드에 재배치합니다.

오토 힐링의 작동 방식:

• 컨테이너가 중단되거나 비정상적으로 종료되면, Swarm은 즉시 상태를 감지합니다.
• Swarm은 장애 컨테이너를 종료하고, 정의된 상태(desired state)를 복구하기 위해 새로운 컨테이너를 배포합니다.

Swarm 오토 힐링 동작

결과적으로 서비스의 가용성을 유지.

deploy:
      replicas: 3
      restart_policy:
        condition: any  # 컨테이너가 어떤 이유로든 종료되면 재시작

또한 아래와 같이 서비스를 업데이트할 때 전략을 세부적으로 제어할수 있습니다.

update_config:
  delay: 15s       ##각 업데이트 작업 간의 대기 시간을 지정
  parallelism: 1  ##한번에 업데이트할 컨테이너(태스크) 수를 지정합니다
  monitor: 10s   ##헬스체크 및 안정성 모니터링 시간을 설정합니다.
  failure_action: rollback  ##업데이트 실패 시 수행할 동작 정의
  max_failure_ratio: 0.55 ##업데이트 실패 허용 비율을 설정합니다.

3. 서비스 상태 관리(desired state reconciliation)

Docker Swarm은 원하는 상태와 현재 상태를 비교해서 클러스터를 관리합니다.

예를 들어, 5개의 복제본이 필요한 서비스에서 1개의 컨테이너가 실패하면 Swarm은 현재 상태를 원하는 상태와 일치시키기 위해 즉시 새 컨테이너를 생성합니다.

4.. 리소스 분산 및 로드 밸런싱

Docker Swarm은 클러스터의 리소스를 최적화하면서 서비스를 실행합니다. 이를 통해 특정 노드가 과부하로 인해 실패하더라도 다른 노드가 이를 처리할 수 있습니다.

내장 로드 밸런서: Swarm은 서비스의 요청을 복제본 간에 분산합니다. 사용자는 단일 VIP(Virtual IP) 또는 DNS 이름을 통해 서비스를 호출하며, Swarm은 이를 적절히 라우팅합니다.

5. 리더 선출 및 매니저 노드 복구

Swarm 클러스터는 매니저 노드의 고가용성을 보장하기 위해 리더 선출(Leader Election) 알고리즘을 사용합니다.

• 매니저 노드가 여러 개일 경우, 한 노드가 장애가 나도 다른 매니저가 리더로 선출되어 클러스터를 계속 운영합니다.
• 장애가 난 매니저 노드를 복구하거나 새로운 노드를 추가하면 자동으로 클러스터에 다시 합류됩니다.

6. 노드 장애 복구

Docker Swarm은 노드의 상태를 지속적으로 모니터링합니다.

• 만약 워커 노드가 장애를 일으키면 Swarm은 해당 노드에서 실행되던 모든 서비스를 다른 가용 노드에 재배치합니다.

7. 재시작 정책(Restart Policy)

스택 배포 시, 각 서비스에 재시작 정책(restart policy)을 설정할 수 있습니다. 이는 컨테이너의 실패를 감지하고 자동으로 재시작하게 만듭니다.

deploy:
  restart_policy:
    condition: on-failure ##컨테이너가 오류로 종료되었을때만 재시작.

8. NFS와 같은 공유 스토리지의 활용

Docker Swarm에서 NFS와 같은 공유 스토리지를 사용하면, 서비스 데이터가 노드 간에 공유되므로 특정 노드 장애가 발생해도 데이터 손실 없이 다른 노드에서 서비스를 계속 실행할 수 있습니다.

해당 서버같은 경우는 NFS ( network file system) 서버를 구축한 후 마운팅을 진행하여 데이터 손실없이 다른 노드 서비스에서도 실행할 수 있게 구축을 진행했습니다.

9.스케일링 및 롤링 업데이트

Docker Swarm은 서비스를 동적으로 스케일링하거나 롤링 업데이트를 지원합니다. 이를 통해 서비스 중단 없이 애플리케이션을 업데이트하거나 확장할 수 있습니다.

결론: Docker Swarm으로 구축한 서버가 죽지 않는 이유

Docker Swarm은 클러스터의 서비스 상태를 지속적으로 모니터링하고, 컨테이너와 노드의 장애에 대해 자동으로 복구 작업을 수행합니다. 또한, 리소스 분산, 복제, 오토 힐링, 재시작 정책, 리더 선출 등 여러 고가용성 메커니즘을 통해 장애 상황에서도 서비스 중단을 최소화합니다.