인프라 구조 재고

.

낙엽1124

2021년 4월 1일 오전 10:32

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

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

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

Nomad 운용에는 CPU와 메모리가 필요하다

저희가 Nomad의 기본 requirements를 충족하지 못 합니다. Nomad 데몬으로 CPU 사용량이 모든 시간에 균일하게 조금씩 상승하는 것은 burstable한 t계열 EC2 인스턴스에 어울리지 않고, 메모리 부족은 블루/그린 디플로이를 불가하게 만듭니다. 노드가 하나인 건 아직은 심각한 문제는 없었습니다.

Consul Connect도 CPU 자원을 소모한다

Consul Connect가 없으면 Nomad로 실행한 서비스 간의 통신이 제한되고, 태스크의 스케일링이나 블루/그린 디플로이가 포트 충돌로 불가해집니다. Consul Connect는 모든 태스크 옆에 Envoy 컨테이너를 같이 띄우는데 이것의 CPU 사용량이 꽤 적지만 저희에게는 컸습니다.

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

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

메모:

블루/그린 디플로이에 필요한 것

Consul Connect, 메모리

Nomad에 필요한 것

CPU

Consul Connect에 필요한 것

CPU