3주차 공통 멘토링

✔️ 멘토링 아젠다

논의 사항 및 질문

멘토의 조언이 필요한 부분을 질문으로 정리합니다.

현재 무중단 배포 방법이 적절할까요?

“Nginx와 도커 컨테이너 2개를 사용한 blue-green 배포”와 pm2를 모두 적용하고 있습니다.

조사해 보았을 때 이 둘을 함께 사용할 필요가 없다(중복 작업이 있고, 메모리 낭비일 수 있다)는 말도 있었습니다.

완전한 무중단 배포를 위해 Nginx로 트래픽을 전환하는 blue-green 배를, pm2로 서버의 안정성을 높인다고 주장하면, 현재 방법이 타당할까요?

클러스터 모드가 내려갔다 실행되는 프로세스를 참고해보자 pm2가 기능을 이미 잘 수행하고 있다면 Nginx는 필요 없지 않을까?

새로운 버전 설치하고 실행할 때 이전 버전 프로세스 graceful하게 종료가 된다면 pm만 써봐도 될 것 같다.
- pm2 프로세스 수를 cpu 코어 수보다 많이 하는 건 어떤 의미가 있나요?
기존의 CPU 코어 수 만큼 쓰지 못 했을 때 보다는 영향이 크지는 않다 요즘 CPU에는 하이퍼 쓰레드 기능이 있어서 효과가 있을 수 있다 마스터 노드가 하나 필요하기에
현업단계에서 라이브러리를 선정하는 기준이 궁금합니다!

저희 프로젝트 특징 상 차트를 많이 띄어야 해, 차트 라이브러리를 사용하려고 합니다.

많은 차트 라이브러리 중 어떤걸 써야할지 고민이 들었는데.. 어떤 기준으로 정해야할지 고민됐습니다.

성능, 파일크기는 고려안하고 UX만 고려해 라이브러리를 선정했는데 현업에선 어떤 과정을 거쳐서 라이브러리를 선택하게되는지 궁금합니다!
1. 유지보수가 중요 (망한, 망할거같은 라이브러리는 지양하자)
2. 유저수를 고려해야한다 (해당 라이브러리가 유지될 확률이 높아진다, 레퍼런스가 많아진다)
3. 사용하고자하는 목적에 부합한지? (사용하는것이 우리팀의 상황에 적절한지)
- 프론트엔드는 조금 다를지도?
  - 빠르게 상황이 바뀐다.
  - 변경이 쉽도록 일단 코드를 짜라 (부담없이 변경할 수 있도록)
성능 테스트 혹은 부하 테스트는 어떻게 하면 좋을까요?

데이터베이스의 성능 테스트, 프록시 서버의 요청 테스트에 대한 부하테스트를 진행해보고 싶은데 혹시 추천하는 부하 테스트 툴이 있을까요? (중요 “무료”)

서버에 높은 부하가 발생하게 되면 수평 확장이 필요할 수도 있을 것 같은데 현재 상황에서 오토 스케일링까지 고려하는게 좋을까요?

오토스케일링 환경을 만들어 보는게 좋을 것 같다 → 할 수 있으면 해보자 사용자들에게 보장할 수 있을만한 수치(?)가 필요하다 → 가용성, 복구 시간 (SLA 계약) 오토스케일링은 오히려 비용을 절감하기 위한 것이다. 급격하게 늘어나는 트래픽을 예측하고 미리 대응하는 방식으로 작업한다.

데이터베이스도 부하분산을 적용해보는게 좋을까요? << 사실, 현재 단계에서 여기까지 고려하는게 쉽지 않은 것 같습니다.
오늘 주요 고민사항

클라이언트를 저희 프로젝트 이용자이자 서비스 제공자, 유저를 클라이언트 서비스의 사용자라고 칭합니다. 저희는 3개의 서버로 구성된 프로젝트를 구현하였습니다. 콘솔 서버, 네임 서버, 프록시 서버입니다.
1. 클라이언트는 저희 콘솔 서버에서 본인의 서비스 정보(아이피, 도메인명)을 등록합니다. 이때, 저희의 네임 서버 주소를 넘겨주면 클라이언트는 cloudflare 등 사용하고 있는 DNS에 저희의 네임서버를 등록합니다.
2. 유저(클라이언트 서비스 사용자)의 요청이 발생시킨 UDP DNS 쿼리에 대해서, 저희 네임서버는 저희가 구현한 프록시 서버의 ip를 넘깁니다.
3. 프록시 서버는 요청과 응답을 클라이언트서버와 유저 사이에서 전달합니다. (원래 요청의 hostname을 토대로 영속화해 가지고 있는 아이피를 찾아 요청 전달)
이런 프로젝트 동작 흐름에서, 2가지 질문이 있습니다.
1. 이때, 클라이언트 서버가 https를 사용하고 있을 때, 저희 프록시서버도 https를 적용해야 하나요?
  
  ⇒ 필요함. 적용 완료
2. 만약 적용해야 한다면, 인증 절차를 어떻게 수행 하나요? 프록시 서버도 해당 클라이언트 서버 도메인에 대한 인증서를 그때그때 추가해줘야하나요? 안해도 동작하는 것 같…은데… 확실치않고…
가장 큰 문제는 호스트랑 IP가 매치가 안되다보니… 문제가 복잡해지더라구요…

진행상황 및 참고 자료

멘토가 일지를 보고 멘토링을 준비할 수 있도록, 팀의 진행상황과 참고 자료를 정리해서 넣어주세요.

https://github.com/boostcampwm-2024/web35-watchducks

[수 많은 차트라이브러리 그 중에 그대를 만나](https://www.notion.so/3d711900f01b4740b7d247a7c1679fe0?pvs=21)

[HTTPS(TLS) 도입](https://www.notion.so/HTTPS-TLS-a808307f0f3f42a180e8f7c78f8bd8f9?pvs=21)

[iptables 를 이용한 포트 포워딩](https://www.notion.so/iptables-a9e3765403b140828d6c9b65f3aa2f6b?pvs=21)

✔️ 멘토링 내용

… 앞에는 듣다가 정리 못했네요…ㅎ

기존 CPU 코어 수 늘어나는 것만큼의 장점이 있는 건 아니고 다른 장점이 있을 것
- 보통은 CPU -1 개만큼 생성
- 클러스터 모드 관리할 때 마스터 필요해서 하나는 마스터로 잡고 돌림.
- 보통은 클러스터라고 하면 3개이상이 의미있음.
- 현업에서는 도커라이징 된 컨테이너 자체를 관리 → 쿠버네티스
pm2가 클러스터모드일 때 graceful하게 shutdown 잘되고 있다면, 도커는 안쓰고 pm2만 써도 될 듯?
배포의 용이성 때문이라면 괜찮을 듯
실제 서비스 할 때 안 끊기고하려면 pm2가 그 역할을 함. → 도커라이징 유무와 관계 없음. (프로세스가 죽는 것이 컨테이너로 만드는 것과 관계 X)

라이브러리 선정 기준
- 유지 보수 → 안 망할 것 같은 것
  - 버려진지 오래된 것은 거르는 편(업그레이드 되는 환경에 따라가야…)
- 오픈소스가 잘 유지되려면 유저가 많아야 함. → 상관관계가 어느 정도 있어야 함.
  - 유저가 많으면 레퍼런스도 많음. → 문제 상황시 디버깅 용이
- 사용하고자 하는 목적에 부합하는지
  - 우리 상황에 적절한지
  - 어떤 것이 장점이고, 단점인지 비교
- 프론트엔드는 코드 수명이 짧아서, 오래동안 유지보수 안되도 됨.
- 코드를 빠르게 바꿀 수 있게 만들어야 함. → 라이브러리도 자주 바꾸기도
- 라이브러리를 직접 만들기도

오토스케일링을 고려해야 할지는 지금의 프로젝트라면 고려하면 좋겠다.
- 실제로 구현은 안해도, 오토스케일링에 대응하게 하면 좋을듯
- 고객에게 보장해 줄 수 있는 최소한의 수치가 필요함.
- b2b 계약 같은 경우 : 몇 %의 가용성, 서비스가 다운되었을 때 최대 몇 시간 안에 복구할 수 있다, 최대 몇시간의 데이터가 날아갈 수 있다
  - sla 계약
오토스케일링은 사용자가 없을 때 비용 절감하기 위한 기술에 가까움.
- 급격하게 몰리는 트래픽에 대한 경우는 예상해야 하는 경우
- 이전을 기준으로 유저를 예상하고, 클러스터를 만들어 놓는 …?
- 오토스케일링도 즉각즉각 개선은 안되기 때문에, b2b 기준 생각하는 것도 좋을듯
부하테스트의 경우, …