식견 서버 기준 8기가 메모리의 홈서버에서 실행까지 요구되는 시간이 8초정도 걸렸는데 생각보다 유실되는 요청이 많았다. 그래서 그 해결 방법을 찾아보다가 쿠버네티스를 사용하면 쉽게 해결할 수 있다는 것도 알았다. 사이드 프로젝트에 쿠버네티스를 도입할 이유가 있을까? 막연하게 쿠버네티스는 엄청 큰 서버만 관리해야한다고 생각해왔다. 그러나 쿠버네티스도 종류가 엄청 다양하고, 프로젝트 규모에 따라서 선택지가 정말 많다는 것을 알게됐다.
이번 글에서는 지금 운영하고 있는 식견이라는 서비스에서 왜 쿠버네티스를 도입했는지 이야기 해보고자 한다. 이 글은 정보 전달이 주 목적이 아니므로, 프로그램을 설치하는 등의 과정을 기술하지 않는다.
왜 무중단 배포를 도입하나요?
학교 내라서 고정된 유저와, 크기 않은 트래픽이지만 무중단 배포를 도입하고자한다. 그 이유는 식견에서 커피챗 요청을 보내는 작업은 굉장히 사용자가 열심히 작업한 후에 보내는, 허들이 굉장히 높은 작업이다. 그런데 그러한 커피챗이 분실되는 상황이 종종 발생했다.
그 이유를 분석해보니, 학교 학생들이 커피챗 요청을 보내는 시간과 백엔드에서 서버를 배포하는 시간이 굉장히 겹치는 것이었다. 학교 학생들이 커피챗 요청을 보내는 시간과 우리 백엔드 팀이 개발하고 배포하는게 보통 자습시간에 발생했다. 식견은 많은 사용자를 타겟으로 하는 서비스가 아님으로 사용자 한명 한명이 너무 소중하기 때문에 모든 요청이 서버로 잘 날라와야한다. 그렇기 때문에 무중단 배포를 도입했다.
쿠버네티스의 종류로는 무엇이 있을까?
다음과 같은 kubernetes 옵션들이 있고, 자신의 상황에 맞게 잘 선택하면 된다.
나는 minikube를 사용했다. 그 이유는 minikube는 하나의 노드로도 실행이 가능하며, 매우 간단하다. 식견이라는 프로젝트는 현재 100명 명정도의 사용자를 가지고 있기에 추가로 노드를 위한 클라우드나 온프레미스 서버를 구축하는 것이 오버엔지니어링이라고 생각했다.
쿠버네티스로 SpringBoot Project 배포해보며
먼저 구성은 다음과 같이 되어있다.
다음의 상황에서 많이 고민한 것이 무중단 배포의 방식이다. 무중단 배포에 따라서 pod의 개수, 구성등이 바뀔 수 있기 때문이었다.
무중단 배포 종류 선택 과정
https://reference-m1.tistory.com/211
나는 무중단 배포 중 결국 롤링을 선택했다. 롤링을 한 이유는 쿠버네티스의 기본 배포 방식이어서 도입이 굉장히 간단한 것이 큰 영향을 미쳤다. 그리고 현재로써는 무엇을 선택하던 크게 차이가 없다.
쿠버네티스에서 롤링을 replicas를 하나도 두고 진행하게 된다면,
다음과 같은 다운타임이 발생하게 된다.
그래서 replicas를 2로 설정하고 진행을 하게 된다면,
중단이 발생하지 않는 것을 확인할 수 있다.
그러나 후에 블루 그린 배포를 사용하는 것이 우리 프로젝트에 가장 적합하게 될 것이라고 생각한다. 왜냐하면, 앞으로 더 많은 기능이 붙을 것이고 더 많은 QA 과정이 필요할 것인데 그런 상황에서는 테스트 서버를 그린, 실제 서버를 블루로 두고 운영을 한다면 서비스의 안정성을 증가시킬 수 있기 때문이다.
그러나 내가 제일 좋아하는 YAGNI 원칙에 의해서 조금 미뤄보고자 한다. 절대로 미루고 싶어서 그런게 아니다. ㅎ
배포를 낮시간에도 하고, 거기서 손실되는 사용자의 요청이 무중단 배포 구축보다 비싸다고 느껴진다면 다들 주저하지 말고 무중단 배포를 도입하는 것을 추천한다!
'기술고민' 카테고리의 다른 글
2024 6개월 이모저모 (2) | 2024.06.28 |
---|---|
모듈은 어떤 상황에서 분리되어야 할까? (0) | 2024.04.21 |
Fixture Monkey를 써야 할까? (0) | 2024.04.16 |
bootJar 와 jar 각자 어떤 책임이 있을까? (0) | 2024.04.14 |
스프링 시큐리티를 쓰지 맙시다. (feat. JWT) (4) | 2024.04.13 |