인프라 구조 재고

This page was last edited on 19 May 2021, at 04:19.
< 페미위키:운영팀‎ | 개발팀‎ | 개발 블로그
.
낙엽1124

페미위키:운영팀/개발팀/개발 블로그/feed

페미위키의 컨테이너 오케스트레이션 툴을 Docker Swarm에서 Nomad로 전환하고 있는 중[1]에, 기록이 필요할 것 같아 글을 작성합니다.

우선 다음이 작업 중 알게 된 점입니다.

Nomad 운용에는 CPU와 메모리가 필요하다
저희가 Nomad의 기본 requirements를 충족하지 못 합니다. Nomad 데몬으로 CPU 사용량이 모든 시간에 균일하게 조금씩 상승하는 것은 burstable한 t계열 EC2 인스턴스[2]에 어울리지 않고, 메모리 부족은 블루/그린 디플로이를 불가하게 만듭니다. 노드가 하나인 건 아직은 심각한 문제는 없었습니다.
Consul Connect도 CPU 자원을 소모한다
Consul Connect가 없으면 Nomad로 실행한 서비스 간의 통신이 제한되고, 태스크의 스케일링이나 블루/그린 디플로이가 포트 충돌로 불가해집니다. Consul Connect는 모든 태스크 옆에 Envoy 컨테이너를 같이 띄우는데 이것의 CPU 사용량이 꽤 적지만 저희에게는 컸습니다.

다음과 같은 인프라 구조 변경들을 생각해 볼 수 있습니다.
(현재 상태: t3a.small 인스턴스 하나에 Docker Swarm을 운용 중)

  1. ❓ a계열 인스턴스로 변경: t3a.small에 비해 비용이 1.3배 정도[3] 오르지만 burstable하다고 안 써있으므로 CPU를 막 쓸 수 있지 않을까 합니다. 대신 CPU는 1개로 줄고 메모리는 동일합니다. ARM 도커 이미지 문제[4]를 해결해야 합니다. CPU 여유가 생기면 Consul Connect를 활성화할 수 있지만 블루/그린 디플로이 없이 Consul Connect만 있어서 특별히 장점이 뭔가 하는 건 문제입니다.
  2. 👍 t4g 계열 인스턴스로 변경: 변경한다고 특별히 획기적으로 나아지는 점은 없지만 ARM이기 때문에 옮긴 후에 a계열로 옮기기 수월해지는 것이 장점입니다. 그 외 소소한 비용 절감 효과를 기대할 수 있습니다(써있는[3] 대로면 88% 정도).
  3. 🚫 t3a.middle로 변경: 비용이 두 배가 되면서 메모리가 증가해 블루/그린 디플로이는 가능해지지만 CPU 베이스라인이 동일하게 20%이므로 CPU 문제를 해결해야 합니다.
  4. ❓ t3a.micro 둘로 쪼개기: 다이내믹하게 둘로 나누려면 Consul Connect가 필요할 텐데, t3a.micro의 CPU baseline이 10%이므로 Consul Connect만으로 이를 넘어설 위험이 있습니다. 단순히 태스크를 임의로 구분해서 둘로 쪼갤 수도 있겠는데, 과거에 페미위키가 Parsoid만 따로 nano로 띄우거나(왜 그랬지), stateful한 MySQL과 RESTBase만 다른 인스턴스로 나눈 적이 있었습니다[5](t3.micro와 t3.nano[6]). 그러나 CPU 사용량을 낮추는 게 목적이라면 php-fpm을 쪼개야 하고 그러면 Caddy를 로드 밸런서로 사용해야 합니다.
  5. 👍 Caddy cache를 만들고 Consul Connect 사용: CPU 사용량이 트래픽으로 인해 크게(6% → 15-25%)증가하며, php-fpm이 큰 원인인 것으로 보입니다. anonymous request를 캐싱[7]할 수 있으면 CPU 사용량을 크게 낮출 수 있을 것으로 예상되며, 그럼 아마 Consul Connect를 같이 띄워도 t3a.small의 베이스라인인 20%는 넘지 않을 것이라 기대해 볼 수 있습니다. 직접 해보고서 안 그럴 가능성도 있지만 캐시 개발 자체는 어차피 해야 하니 겸사겸사입니다.

메모:

블루/그린 디플로이에 필요한 것
Consul Connect, 메모리
Nomad에 필요한 것
CPU
Consul Connect에 필요한 것
CPU

출처