NODE.js 앱 하나를 k8s에 올리면서 고민한 것들

Node.js 앱 하나를
k8s에 올리면서 고민한 것들
쇼핑검색개발
정형식

컨테이너와 k8s
• 단일 컨트롤 호스트 상에서 여러 개의 고립된 리눅스 시스템 (컨테이너)들을
실행하기 위한 운영 시스템 레벨 가상화 방법
https://ko.wikipedia.org/wiki/LXC

컨테이너와 k8s
• `컨테이너`
• 컨테이너에 화물을 넣으려는 입장: 컨테이너 안에 넣어야 함 (신선식품, 액체 등등)
• 화물을 옮기는 입장: 내용과 상관없이 동일한 방법으로 운송 가능

컨테이너와 k8s
• `컨테이너`
• 컨테이너에 화물을 넣으려는 입장: 컨테이너 안에 넣어야 함 (냉장, 액체 등등)
• 화물을 옮기는 입장: 내용과 상관없이 동일한 방법으로 운송 가능

컨테이너와 k8s
• 컨테이너가 수백개 있다면?
• 어느 머신에 어떤 컨테이너를 띄우지?
• 얘네들이 문제없이 잘 떠있나?
• 컨테이너들을 새 버전으로 바꿔야 겠다

컨테이너와 k8s
• 컨테이너가 수백개 있다면?
• 어느 머신에 어떤 컨테이너를 띄우지?
• 얘네들이 문제없이 잘 떠있나?
• 컨테이너들을 새 버전으로 바꿔야 겠다
• 쿠버네티스는 컨테이너 오케스트레이션의 사실상 표준

k8s object
• Pod: 도커 컨테이너(들)
• Deployment: Pod을 여러 개 띄워놓은 것
`node-api`
• Ingress: HTTP 요청을
서비스들한테 라우팅
https://medium.com/@ahmetb
• Service: Pod들을 네트워크로
접근할 수 있도록 묶어놓은 것

쇼핑검색개발과 k8s
• 사내 공용 클러스터가 오픈해서 기존 로직을 옮긴 신규 node.js
API 앱을 배포
• 자바 웹 (Spring MVC), node.js 웹(BFF + React SSR)도 옮기려고
계획 중
• 결국 (금전 / 비금전) 운영비용 효율화가 목적
(IaC와도 닿아있음)

쇼핑검색개발과 k8s
• 처음 올려보면서 고민했던, 그리고 지금도 고민하는 점을 공유
1. PM2를 쓸까 말까?
2. Liveness / readiness probe는 어떻게 설정할까?
3. Ingress 설정은 어떻게 안전하게 배포할까?

• PM2
• (Node.js) 프로세스를 관리해주는 도구
• 주요 기능
• 클러스터링 – node.js는 싱글 쓰레드고 장비에는 코어가 많으니까
• HA – 프로세스가 죽으면 다시 띄워줌
• 로깅 – 여러 프로세스에서 나온 로그를 모아서 볼 수 있게 + 로그 파일 rotation
• 모니터링 – 프로세스 별 CPU 사용량, 메모리 사용량 등
• 물리장비 / VM 위에서 node.js 앱을 운영할 때는 다들 씀
• k8s 위에서는?
• 쓰는 곳도 있고 안 쓰는 곳도 있다

• PM2의 역할을 k8s가 대체할 수 있을까?
• 클러스터링
• HA
• 로깅
• 모니터링

• PM2의 역할을 k8s가 대체할 수 있을까?
• 클러스터링 – Pod 개수를 늘리면 해결
• HA – Pod이 어떤 이유로 종료가 되면 restartPoliciy를 따라서 처리
https://kubernetes.io/ko/docs/concepts/workloads/pods/pod-
lifecycle/
• 로깅 & 모니터링 – 클러스터 별로 환경이 다르지만 보통 로그 확인 및
자원 모니터링 도구를 제공
• 일단은 PM2 없이, 별일 없이 운영하는 중

• 그러면 PM2는 쓸 필요가 하나도 없나?
• Pod 개수의 문제
• ex) 노드 프로세스 80개가 필요한 워크로드
• Pod 80개 vs Pod 10개 ? (PM2로 노드 프로세스 각각 8개)
• Pod마다 사이드카 컨테이너가(filbeat, nginx..) 있다면 Pod이 많은 것도 비용
• 앱이 다시 뜨는 속도
• Pm2: 프로세스가 죽음 -> 다시 띄움
• Pod: 프로세스가 죽고 -> 클러스터가 인지 -> LB에서 빼고 -> Pod 다시 띄우고 -> 다시 LB
에 넣고
• 만약 PM2를 쓴다면
• 무중단 배포 / 재시작을 위한 별도의 설정이 필요하다
• [라인 개발블로그 - 2 . ]
• (https://engineering.linecorp.com/ko/blog/pm2-nodejs/)

2. Liveness probe / Readiness probe는
어떻게 설정할까?
• K8s는 컨테이너 상태를 알기 위해 주기적으로 요청을 보냄
• 명령어, TCP 요청, HTTP 요청
• Liveness probe
• 컨테이너가 살아있는지
• Readiness probe
• 컨테이너가 요청을 처리할 준비가 되있는지

• Liveness probe
• 컨테이너가 살아있는지
• 실패: Pod이 재시작
• Readiness probe
• 컨테이너가 요청을 처리할 준비가 되있는지
• 실패: 다시 성공할 때 까지 LB에서 뺀다
• 언제 재시작되고 언제 잠깐 요청을 받지 말아야할까?

• 현재 설정
• Liveness: 항상 200 OK를 return 하는 HTTP endpoint
• Readiness: DB (Redis, MongoDB) 커넥션이 정상이어야 OK를 return
하는 endpoint

• 현재 설정
• Liveness: 항상 200 OK를 return 하는 HTTP endpoint
• Readiness: DB (Redis, MongoDB) 커넥션이 정상이어야 OK를 return
하는 endpoint
• 주의할 점
• 시작시간이 오래 걸린다면 livenessProbe의 initialDelaySeconds를 적절
히 조절
• 안그러면 계속 재시작..
• Ingress 컨트롤러 Pod에도 꼭 설정해 줄 것
• 안그러면 Pod 업데이트 할 때 순단 발생
https://cloud.google.com/blog/products/gcp/kubernetes-best-practices-setting-up-health-checks-with-readiness-and-liveness-probes
https://stackoverflow.com/a/48578390

• 좀 써보고 나니까…
• 원래는 무중단 배포를 위해 설정했는데
• 새 버전의 이미지, 차트를 배포할 때 최소한의 안전판 역할
• 사실 물리기반 서버 배포 스크립트에도 비슷한 내용이 있음

• 여전히 고민하는 지점
• Readiness probe의 내용
• Redis OK && MongoDB OK 로 설정을 해놓았는데
• 예를 들어 (혹시라도 만에 하나) 몽고DB에 장애가 나면 이 API 전체가 사용이 불
가해지는게 맞는가?
• 전체 체크는 Pod을 처음 시작할 때만 하는게 어떨까?

• 여전히 고민하는 지점
• Readiness probe의 내용
• Redis OK && MongoDB OK 로 설정을 해놓았는데
• 예를 들어 (혹시라도 만에 하나) 몽고DB에 장애가 나면 이 API 전체가 사용이 불
가해지는게 맞는가?
• 전체 체크는 Pod을 처음 시작할 때만 하는게 어떨까?
• 시스템의 상태는 스펙트럼으로 생각해야 한다고 한다.
https://medium.com/@copyconstruct/health-checks-in-distributed-systems-aa8a0e8c1672

3. Ingress 설정을 안전하게 업데이트 하
는 방법이 없을까?

• Ingress를 사용하려면
• Ingress 컨트롤러 Pod을 띄워야 하고 (eg., nginx, traefik)
• 이미지는 뭐 쓸지, 몇 대 띄울지 등등
• Ingress 설정을 넣어줘야 한다
• 어떤 주소 / 경로는 어떤 서비스로..

• Ingress를 사용하려면
• Ingress 컨트롤러 Pod을 띄워야 하고 (eg., nginx, traefik)
• 이미지는 뭐 쓸지, 몇 대 띄울지 등등
• Ingress 설정을 넣어줘야 한다
• 어떤 주소 / 경로는 어떤 서비스로..
• 잘못된 설정을 넣을 경우
• Ingress controller ?
• Pod은 아예 뜨지를 않으니 Liveness Probe / Readiness Probe 설정으로 검출 가
능
• Ingress 설정
• ???

• Ingress 설정을 잘못할 경우..
• 예시) Traefik Ingress에서 서비스 weight를 잘못 넣으면(=합이 100이
초과하도록 넣으면)
• 두 서비스 아무 곳으로도 요청을 보내지 않음
• 만약 서비스 전이라면
• 충분히 테스트해보고 요청을 받기 시작할 수 있음
• 운영중이라면
• 안 바꾸면 됨
• Ingress 파일을 분리해서 작성하는 식으로
실수 가능성을 줄일 수는 있다
https://docs.traefik.io/configuration/backends/kubernetes/#annotations

• 하고 있지는 못하는데 하면 좋겠다 싶은 방법들
• 스테이지 클러스터를 따로 하나 만들어서 거기서 검증
• Traefik Controller를 두 군으로 띄워서 한쪽에서 검증 후 나머지에 반영
• https://docs.traefik.io/user-guide/kubernetes/#between-multiple-traefik-
deployments
• Minikube를 이용해서 테스트..?

• 하고 있지는 못하는데 하면 좋겠다 싶은 방법들
• 스테이지 클러스터를 따로 하나 만들어서 거기서 검증
• Traefik Controller를 두 군으로 띄워서 한쪽에서 검증 후 나머지에 반영
• https://docs.traefik.io/user-guide/kubernetes/#between-multiple-traefik-
deployments
• Minikube를 이용해서 테스트..?
• 조심만 하고 있습니다

못다한 이야기들
• 배포 / 로깅
• 클러스터 환경마다 너무 달라서 스킵. 사내 플랫폼 사용중 (관리 포인트를 줄이기 위해서)
• 손으로 하는게 익숙해지면 점차 자동화하고 싶음
• 함께 익숙해지기
• 삽질이 왕도일까?
• 경험치를 효율적으로 전파하는 법?

NODE.js 앱 하나를 k8s에 올리면서 고민한 것들

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

NODE.js 앱 하나를 k8s에 올리면서 고민한 것들