Smart Box
Rancher(k8s)를 도입하면서 느낀 점 본문
현재 다니고 있는 직장에서 많은 제휴사가 늘어감에 따라 서비스 배포 관리와 트래픽을 제어하기 위해 기존 서버 환경을 갈아 엎기로 하였다. 아무래도, 경력이 짧고, 짧은 시간 내에 조사하여 환경을 개선해야했기 때문에, 완벽하지는 않지만, 사내에 Rancher 및 Kubernetes를 도입하면서 느낀 점을 정리해보려고 한다.
기존 시스템 환경은?
- OS: Windows Server / CentOS
- CI/CD: Github Action
- Back-end: Kotlin / Spring Boot / MSA
위에가 전부다.
Load Balacner도 없고, Reverse Proxy Server도 없고, OS에 직접 서비스를 배포하고 있었으며, 백업도 진행하지 않고 있었다. 매우 문제가 많은 구조였다고 생각하지만, 초기에는 서비스 트래픽도 적고, 프로젝트가 매우 적어서, 적은 인원에서 모든 서비스를 직접 배포하며 관리하기 편했기 때문에 이 구조를 유지해왔던 것 같다.
하지만, 제휴사와 개발하는 프로젝트 또한 늘어가면서, 관리하기 점점 힘들어졌고, 사내 시스템을 변경을 반드시 해야만 했다.
Kubernetes(k8s)를 고른 이유는?
서비스 무중단 배포
모든 서비스가 그렇겠지만, 서비스가 일시적이라도 중단되면, 고객의 만족도가 낮아지기 때문에 서비스가 중단되지 않고 배포하는 것은 매우 중요하다. 특히, 우리 회사가 서비스하고 있는 것은 생활과 매우 밀접하기 때문에 한 번이라도 정상적으로 작동하지 않으면, 일상에 영향이 간다. 이 때문에 서비스가 중단되지 않고 배포되는 것은 매우 중요했다. (기존에는 2s 정도 중단 시간이 있었다.)
L7 Load Balancer
IDC 서버 랙에 자리가 거의 없어 L4 Switch를 도입하기 어려운 상황이였다. 또한 도입한 Switch를 학습하고 관리할 인력이 없었다. k8s는 Ingress를 통하여 L7에서 Load Balancing이 가능하며, 더 나아가 Reverse Proxy를 통하여 SSL 인증서를 관리하는 데에 매우 편리한 점이 있었다.
Auto Scaler
HPA(Horizontal Pod Autoscalers)를 통해 배포된 서비스의 과부화 정도에 따라 수평적으로 서비스를 자동으로 확장 및 축소를 할 수 있었다. 이로인해, 개발자가 직접 관리하지 않아도, 서버의 리소스를 최적으로 관리하며 서비스를 안정적으로 운영할 수 있었다.
Resource Management
기존에는 특정 서버에 CPU나 Memory 리소스가 부족하거나 하면, 해당 서비스를 다른 서버에 옮긴다거나와 같이 직접 모니터링을 하며 관리를 해야하는 수고가 들어간다. k8s는 특정 서비스에 사용할 수 있는 리소스를 제한할 수 있으며, 각 서버의 리소스를 모니터링 해 알맞는 서버에 서비스(pod)를 배치해주는 고마운 시스템이 있다.
High Availability
특정 서버가 무언가의 이유로 Down이 되면, 특정 시간 이후에 해당 서버에 배정된 서비스(pod)을 자동으로 다른 서버에 재배치도 해준다. 물론 Load Balancer를 통해 서비스는 중단되지 않고 지속되겠지만, 처리 성능이 떨어질 수 있는 기간을 줄여준다.
신뢰된 Open Soruce
Kubernetes는 이미 많은 회사들이 도입했기 때문에 C-Level들이 새로운 시스템을 받아들이는 데에 큰 문제가 없었다.
Rancher를 고른 이유는?
Kubernetes는 매우 큰 스케일을 위해 디자인된 시스템이므로, Learning Cruve가 매우, 극도로 높았다. YAML을 일일이 작성하여 Console을 통해 배포하는 것은 단기간 내에 불가능했고 판단했다.
Web에서 k8s를 관리할 수 없는지 찾아보다가 아래 글을 발견하였고, 바로 사내 테스트 서버에 도입하여 테스트했었다.
Rancher는 Web에서 k8s를 누구보다 쉽게 설정을 관리하고, 모니터링을 할 수 있게 도와준다. 게다가, 여러 직원이 동시에 관리할 수 있게, 직원들에게 권한을을 배정해줄 수 있었다. 무엇보다, YAML 파일을 작성하는 시간이 없어져, 생산성을 극대화하는 데에 큰 도움을 주었던 것 같다.
그렇다고 k8s가 다 좋은 것은 아니였다.
Learning Curve
앞서 말했지만, 매우 큰 Learning Curve를 요구한다. 나와 같이 일을 하는 사람들이 이에 대해 이해하고 있어야 한다. 또한, 나와 관계는 없지만 회사의 입장에서는 인수인계 받는 사람이 이를 배워야하거나 아는 사람을 뽑아야 하기 때문에 코스트가 큰 고민이 될 수 있다.
추가로 서비스 개발할 시간도 부족하고, 이에 대해 잘 알고 있지도 않은 상태에서 실 서비스에 도입하는 것은 매우 도박이다. 하지만, 우리 회사 같은 경우는 작은 규모에서 변경을 했고, k8s 환경에서 모든 서비스를 테스트 해본 후에 전환한거기에 가능했던 것 같다.
기본적으로 많은 서버 리소스가 필요
초기 설치하고 아무것도 하지 않은 채로 있는 서버인데, 기본적으로 Rancher가 많은 Resource를 요구한다. 따라서, 만약 서버의 성능이 그렇게 좋지 않거나, 서버가 적다면, k8s 보다 Docker Swarm이 더 나은 방향이 아닐지 생각해봐야한다.
On-promise일 경우 더 많은 것을 고민해야 한다
Cloud 환경을 전혀 이용하지 않을 경우, 즉 On-promise 환경에서 모든 것을 구축해야할 때, 더욱 많은 것들을 고민해야 한다. 기본적으로 Cloud에 의존하기 때문에 Load Balancer를 이용하려면 MetalLB와 같은 에드온을 추가적으로 구축해야 하고, 저장 공간이 필요하면, 추가로 NAS를 구축하여 연결해야 한다.이외에 제한 된 것을이 많다.
Logging 시스템 추가 구축
이건 단점이라고 하기 보다는, k8s를 구축하고 서비스 Log을 모니터링 하기 위해서는 추가적으로 Logging 시스템을 구축해야했다. 우리 회사 같은 경우, ELK Stack과 Logstash를 이용하여 모든 서비스의 로그를 수집하고, 중앙관리하고 있다. 직접 Pod의 Console Log를 실시간으로 볼 수 있지만, 추적하기 어려울 것이다.
그래서 현재의 환경은?
- VM OS: Proxmox
- Guest OS: Ubuntu
- Orchestration: Rancher/Kubernetes
- CI/CD: Github Action
지금은 Load Balancer를 통해 트래픽이 분산되고 있으며, 트래픽이 많아지면, 자동으로 확장하여 대비한다. 다음에는 Proxmox에 대해 적어보려고 한다.
'Programming' 카테고리의 다른 글
| Kotlin "when"은 언제나 exhaustive 해야 한다. (1) | 2022.04.11 |
|---|