클라우드에서 분산서버 구성하기

이제는 많은 개발자들에게 익숙해진 AWS, Azure, GCP, NBP 등의 클라우드 서비스는 많은 장점을 가지고 사용자에게 편의를 제공하지만 사용하기에 따라 운용하는 자원과 그 비용이 굉장히 유연할수도, 또는 엄청나게 비효율적일 수도 있습니다.

이런 클라우드에서 분산 서버를 구성하는 데 많이 사용하는 방법으로는, 수동으로 로드밸런서 및 다수의 서버를 구성하는 방법과 도커 기반의 컨테이너 오케스트레이션 프레임워크를 사용하는 방법이 있습니다.

클라우드는 일반적으로 on-premise 환경에 비해 하드웨어 관리, 보안 등 많은 부분에서 편의성을 제공하지만 컴퓨팅 자원을 부하에 비해 많이 사용할 경우 불필요한 비용이 발생할 수 있습니다.

여기서는 각 방법별로 어떤 장단점이 있고, 어떻게 클라우드에서 비용 효율적인 구성을 할 수 있는지 정리해보았습니다.

1. 다수의 서버 + 로드밸런서

개인적으로 가장 간단하게 구성할 수 있는 분산서버 형태라고 생각합니다.

웹서버를 예로 들면 똑같은 코드와 기술 스택(Apache+php등)이 설치된 서버가 여러개 있고, 로드밸런싱 기능을 하도록 세팅된(Nginx 등) 서버가 외부의 트래픽을 다수의 웹서버에 나누어주는 구조입니다. 이 경우 기존 웹 서버 구성에 사용하던 외부 스토리지, 캐시 서버, DB 등은 모든 서버가 공통으로 접근할 수 있도록 구성해야 합니다.(A서버에서 업데이트한 내용을 B서버에서 조회할 수 있도록)

On-premise에 다수의 같은 환경의 웹서버와 로드밸런서를 직접 구성하려면 많은 시간과 노력이 필요하겠지만, 클라우드 환경에서는 각 서비스 제공자가 제공하는 VM 복사, 로드밸런싱 서비스 등을 통해 비교적 간단하게 구성할 수 있습니다.

또한 On-premise와 비교했을 때 클라우드에서 이런 형태의 분산 서비스를 구성했을 경우 가장 큰 장점은 컴퓨팅 자원을 유연하게 관리할 수 있다는 점입니다. On-premise는 부하가 늘어날 경우 서버를 더 구매해서 세팅해야하고, 부하가 줄어들어도 늘어난 서버를 쉽게 줄이지 못하지만, 클라우드 환경에서는 시시각각 변하는 부하에 대응하는 작업이 비교적 간단합니다.

NBP의 Auto Scaling Group과 같은 기능이 대표적인데, 동일한 스펙의 클라우드 컴퓨팅 자원을 특정 이벤트(리소스 사용량, 시간대 등)에 따라 Scale in/out 함으로써 그때그때 부하에 따라 필요한 만큼만 탄력적으로 자원을 사용할 수 있습니다. 비용은 물론 사용한 자원에 따라서 클라우드 서비스 제공자에 따라 분단위, 초단위로 유연하게 청구됩니다.

이렇게 컨테이너 오케스트레이터를 사용하는 방법에 비해 명시적으로 로드밸런서를 사용할 경우 장점은 추가적인 학습이 필요 없이 기존의 웹서버 및 네트워크에 대한 지식을 통해 구성이 가능하다는 것입니다. 또, 버그가 발생했을 때 비교적 디버깅이 쉽다는 점 또한 큰 장점입니다.

다만 운영 시 서버 업데이트 배포, 장애 대응 등에 손이 많이 간다는 단점이 있습니다. 또한 Scaling 시 웹서버 1개 증가는 곧 클라우드 컴퓨팅 자원 한개 증가와 같기 때문에 Scaling에 걸리는 시간이 비교적 오래 걸립니다.

2. 컨테이너 오케스트레이터(쿠버네티스)

Docker 기반의 컨테이너 오케스트레이터를 사용하여 분산 서버를 구성하는 방법입니다.

최근 클라우드 서비스 제공자들이 활발하게 지원하고 있는 컨테이너 오케스트레이터로 Kubernetes가 있습니다. AWS의 EKS, GCP의 GKE, Azure의 AKS, NBP의 kubernetes service 등의 이름으로 상품을 제공합니다.

기존의 On-premise 환경에서의 Kubernetes는 여러대의 머신을 클러스터로 묶어 그 자원을 활용해서 웹서버 등의 서비스 다수를 배포하고, Scaling을 통해 부하를 분산할 수 있습니다. 클라우드 환경에서의 Kubernetes는 추가로 클라우드 컴퓨팅 리소스 제어와 결합하여 통해 서비스 뿐 아니라 클러스터를 구성하는 머신 자체도 Scaling이 가능합니다.

클라우드 서비스를 이용할 때 비용은 주로 사용하는 컴퓨팅 자원의 스펙과 개수에 따라 결정되는데, 웹서버 한 개당 설정해둔 CPU/Memory 점유 요구량과 전체 서버의 부하량에 따라 컴퓨팅 자원 자체가 조절된다면 서버에 부하가 많을 때만 비용이 많이 나가고, 적을 때는 최소한의 비용만 나가기 때문에 효율적으로 클러스터를 운영할 수 있습니다.

이전에 설명한 명시적으로 로드밸런서를 사용하는 방식에 비해 컨테이너 오케스트레이터를 사용하는 방식의 장점은 Docker 이미지 기반의 배포가 이루어지고 하나의 머신에 여러개의 서버가 동작할 수 있기 때문에 평균적인 scaling 시간이 빠르고, Kubernetes에서 Rolling update와 오류 발생 시 서버 재시작 등 운영 시 가용성, 신뢰성 확보를 위한 기능을 제공하기 때문에 운영 편의성이 크게 증가합니다.

컨테이너 오케스트레이터 방식의 단점으로는 분산 환경 구성을 위해서 기존 웹, 네트워크 지식 외에 추가적으로 Docker, Kubernetes와 같은 프레임워크를 익혀야 한다는 점과 하나의 웹 서비스가 기능에 따라 Kubernetes 내에서 다양한 요소의 상호작용으로 이루어지기 때문에 버그 발생 시 디버깅이 힘들다는 점이 있습니다.