[Kubernetes] K3s로 운영·스테이징 환경을 단일 서버에서 분리하기 (1)

나는 현재 중간 지점 추천 서비스인 "모이삼"을 디벨롭하고 있으며 8월 중에 릴리즈 예정이다.

지금은 UI 개선과 API 로직 개선 등 다방면에서 개선하고 있다.

 

호다닥

 

모이삼은 릴리즈 전인 지금도 사용할 수 있고, 서울·경기·인천 지역에서 친구들과 어디서 만날지 확인할 수 있다.

https://moisam.kr/

모이삼

 

운영 서버 단일 구성의 한계: API와 UI 불일치로 인한 리스크 존재

출시 전인 지금도 사용할 수 있는 만큼, 기능 개발/수정 후 배포된다면 운영 서버에 바로 적용되어 프론트에서 사용하는 값과 백에서 제공하는 값이 틀어질 수 있다.

 

즉, 기존의 모이삼은 운영 서버 하나로만 관리되어 백엔드에서 배포하면 의도치 않은 에러가 발생하고, 항상 프론트와 싱크를 맞추는 과정에서 불필요한 공수가 들 수 있다.

기존 모이삼 아키텍처

 

곧 본격적인 개선이 이뤄져야 하는 시점이 다가왔고, 백로그에 담아놨던 운영·스테이징 환경 분리 작업을 진행하게 되었다.

---

고민 : 서버 1대 증설 (Scale Out) VS 단일 서버 내에서 분리

서버 1대 증설  - 장단점

운영·스테이징 환경을 분리하는데 가장 간단한 방법은 서버 1대를 더 구축하는 것이었다.

현재 사용하고 있는 서버를 운영 서버로 사용하고, 추가로 구축된 서버는 스테이징 서버로 사용하면 기존의 인프라 구축 로직이 크게 변경되지 않고 운용할 수 있다.

 

다만 가장 큰 단점이 존재한다.

비용 🥲

 

바로 비용이다. 💸💸💸

네이버 클라우드에서 크레딧을 제공해 줘서 6개월 정도는 서버 관련 비용은 문제가 없다. (서버 1대만 사용할 경우)

하지만 서버를 1대 늘리면 월 지출 비용이 2배가 됨으로써 유지 기간이 3개월로 줄어들게 된다.

 

그래서 크레딧을 아껴 쓰면서 운영·스테이징 환경을 분리해야 했고, 결국 서버 1대를 증설하는 고민은 고이 접어두었다.

 

단일 서버에서 분리 - 장단점

위의 NCP 서버 스펙을 보면 서버의 성능이 모이삼 웹 서비스 대비 고성능이다.

 

모니터링 그래프에서도 CPU 사용량이 종종 10%가 최고로 찍히고 대부분 0점대다. Memory 사용량도 20%를 하회한다.

즉, 운영 서버로 사용했는데도 불구하고 서버의 성능을 효과적으로 사용하지 못했다. 

 

낭비되고 있는 리소스를 사용해볼 순 없을까?

 

낭비되는 리소스를 스테이징 서버로 사용할 수 있으면 서버 리소스를 최대한 사용할 수 있을 거라 판단했고, 출시 후에 모니터링을 꾸준히 해서 트래픽이 몰릴 경우의 서버의 성능을 높이는 Scale-Up을 하거나 서버를 한 대 증설하는 Scale-Out을 할 수 있기에 확장할 수 있는 방법이 많다고 생각했다.

 

대신 기존의 모이삼 아키텍처는 전면 수정되어야 하고, 단일 서버 내 분리를 해본 적이 없었기 때문에 분리 가능성에 대해 불확실했다.

---

Docker -> Kubernetes 전환

위의 고민을 하기 전부터 나는 쿠버네티스에 관심이 많았다. 그래서 쿠버네티스 책을 읽으며 기본적인 지식을 쌓고 있었다.

쿠버네티스 문서를 살펴보다가 Namespace 기능을 활용해 하나의 클러스터 내에서 환경을 나눠 운영할 수 있다는 예제를 보게 되었고, 이는 내가 고민하고 있던 문제를 해결할 수 있는 방법이라고 판단했다.

네임스페이스를 사용해 클러스터 공유하기

 

또한 단일 서버 환경인 만큼 운영 서버의 안정성을 유지하면서 스테이징 환경의 리소스를 제한하는 것이 중요한데, 쿠버네티스에서는 리소스 제한(ResourceQuota)을 통해 이를 손쉽게 설정할 수 있다.

 

이외에도 쿠버네티스는 다음과 같은 기능들을 제공해 준다:

• Replica 수 조절
• Readiness Probe, Liveness Probe를 통한 안정성 확보
• HPA(Horizontal Pod Autoscaler)를 이용한 자동 확장
• YAML 기반으로 정의되는 선언적 인프라 관리

이러한 기능들은 추후 시스템 확장이나 장애 대응에도 유리하고, 또한 쿠버네티스를 실제 프로젝트에 적용해 보는 것은 나에게도 좋은 학습 기회가 될 것이라 생각하여 전환을 결정하게 되었다.

---

K8s 가 아닌 K3s 사용 이유

단일 서버에서 운영과 스테이징 환경을 동시에 구성하려다 보니, 클러스터 자체의 리소스 소모가 작아야 했다.

 

K8s의 경우, 최소 300MB 이상의 다수 바이너리 파일이지만 K3s는 40MB 정도의 단일 바이너리 파일로 모든 구성요소가 통합되어 리소스 측면에서 K3s가 훨씬 가벼웠다. 또한 K3s는 Edge, IoT와 같이 소규모의 서비스에서 사용하기를 권장하기 때문에 우리의 제한된 리소스 환경에서 충분히 적용 가능하다고 판단했다.

---

References

• https://k3s.io/
• https://kubernetes.io/ko/docs/tasks/administer-cluster/namespaces/#%EC%83%88-%EB%84%A4%EC%9E%84%EC%8A%A4%ED%8E%98%EC%9D%B4%EC%8A%A4-%EC%83%9D%EC%84%B1%ED%95%98%EA%B8%B0
• https://spacelift.io/blog/k3s-vs-k8s#benefits-of-using-k3s
• https://cloudchipr.com/blog/k3s-vs-k8s

원래 K3s 구축 과정을 적으려 했는데,,, 글이 길어졌네요 🤣

다음 글에서는 K3s를 기반으로 네임스페이스 분리, 리소스 매니페스트 작성 그리고 GitHub Actions를 통한 파이프라인 구축 과정을 적어보겠습니다!