개요
나의 백엔드 서버는 현재 온프레미스로 배포되어 있는데, 하나의 서버에서 어플리케이션을 실행시키는 형태 로 배포되어 있다. 배포되어 있는 인프라의 구조에서 발생하는 단점과 불편한 점 등이 있어 아래의 그림과 같이 순차적으로 쿠버네틱스를 적용한 인프라 구조 형태로 바꾸려 한다. 대체 어떤 불편한 점이 있어서 인프라 구조를 바꾸려 하였는 지를 공유하려 한다.
왜 인프라 구조를 바꾸려 하나
데브옵스 관점 에서 내 서버를 보았을 때에 많이 부족한 모습이다. 그 중에 바로 생각나는 것은 가용성의 부족 , CI/CD 미적용 , 모니터링 시스템의 부재 이다.
🔸 가용성 향상
현재는 서버에 부하가 많이 쏠렸을 때에 서버가 부하를 감당하지 못해 요청을 정상적으로 처리하지 못하는 상황이 올 수 있다. 이러한 이슈를 쿠버네틱스를 활용하여 개선하려 한다. 쿠버네틱스는 단일 서버로 가던 부하를 여러 서버로 분산시켜줌으로써 서버의 부하를 줄여준다. (현재는 쿠버네틱스 적용을 위해 서버용 컴퓨터를 2대 구매한 상황이다. 잘 되었으면 좋겠다... )
🔸 CI / CD 진행
내 서버는 CI/CD 가 적용되어 있지 않다. 따라서 깃허브 에 올린 코드와 배포 중인 백엔드 서버의 코드 가 동기화되어 있지 않고 있다. 이를 해결하기 위해 GitHub Action 과 쿠버네틱스 를 적용할 예정이다. 원리는, 릴리즈 브랜치 에 변경점이 생기면 GitHub Action 가 변경점이 반영된 도커 이미지 를 생성하고 생성된 도커 이미지 를 쿠버네틱스 에 알려주어 쿠버네틱스 가 내부적으로 변경된 이미지를 배포 하는 방식이다.
🔸 모니터링 시스템 구성
현재 서버는 모니터링 시스템이 없다. 현재의 인프라 구조로도 모니터링 시스템을 만드는 것은 가능하지만 아직 진행을 하지 않은 상태이기도 하고 쿠버네틱스 로 변경할 시, 쿠버네틱스 와 연계된 모니터링 관련 오픈소스 를 사용할 수 있어 더 손쉽게 모니터링 시스템 을 구축할 수 있다. 따라서 쿠버네틱스 를 연계하여 모니터링 시스템을 구축할 예정이다. 메트릭 정보는 프로메테우스 를 통해 수집할 예정이고 메트릭 정보의 시각화는 그라파나 로 진행할 예정이다.
진행 사항
7월 2일부터 시작하여 아무리 길어도 2주안에는 끝내려 한다. 인프라 구조 변경을 위해 필요한 개념들과 실습은 어느정도 진행해본 지라 시도 자체는 가능할 것으로 보인다. 그러나 쿠버네틱스의 경우 아직 미니큐브로만 진행해본 상태고 각각의 컴퓨터에 워커노드로 설정해본 적은 없어서 살짝 걱정이 되긴 한다. 한번 시도해보자...!
고려해야되는 점
🔸 SSL 관리의 변화
SSL 을 현재 백엔드 서버에서 담당하고 있다. 변경 후에는 쿠버네틱스 내의 Nginx 가 담당하게 할 예정이다.
트러블슈팅
🔸 Node 버전 차이에 따른 함수 미동작
내 호스트머신 에서는 잘 되는데 도커 이미지 로 실행시키면 함수가 정상동작하지 않는 이슈가 있었다.
원인은 내 컴퓨터의 node 버전 과 도커 이미지 내 node 버전 이 서로 달라서 발생한 이슈였다.
그래서 도커 이미지의 node 버전 을 내 컴퓨터의 node 버전 으로 변경하여 해결하였다.
아래는 문제가 되었던 코드이다. 폴더가 없으면 폴더를 재귀적으로 생성해야되는데 노드 16 버전 에서는 정상 동작하지 않았다.
fs.mkdirSync(..., { recursive: true });내가 보려고 만든 Snippet
# 미니큐브 마운트
$ minikube mount /home/sori/db/entto:/db/entto
# 포트포워딩
$ kubectl port-forward --namespace=ingress-nginx service/ingress-nginx-controller 5501:80 4443:443 --address='0.0.0.0'
# nginx 공유파일 경로
$ /usr/share/nginx/html
# nginx config 파일 경로
$ /etc/nginx/conf.d참고문헌
관련 참고 블로그
쿠버네틱스 SSL 적용 관련 블로그
이것도.. - https://devopscube.com/configure-ingress-tls-kubernetes/
