오늘은 운영하면서 가장 중요하다고 뽑을수 있는 오토스케일링에 대해서 한번 알아보자.
기존에 사내 IDC가 있는 경우 많은 서버를 사놓고 각종 솔루션들을 설치한 후 어플리케이션을 올려서 운영을 한다.
보통 운영시 자원을 좀 더 넉넉하게 운영을 해야해서 언제 늘어나거나 줄어들지 모르는 서비스일지라도 어느정도 가용가능한 추가적인 서버들이 항상 있어야 한다.
하지만 이런 추가적인 구매와 운영 모두 비용이기 때문에 아쉬운 부분들이 있을 것이다
클라우드가 많이 도입되면서 위 상황들은 조금 해결이 된다. 온디맨드, 즉 사용한 만큼만 지불하면 된다.
하지만 이또한 잘못사용하면 과금폭탄이기에 장기간 모니터링을 통해 해당 서비스에 적정 스펙을 찾아내야 하고 이에 맞게 운영을 해야한다.
단순히 커머스와 같은 서비스는 이벤트가 굉장히 많다. 이런 스파이크성 트래픽을 받기 위해서 하루종일 최대 트래픽 상황에 맞게 인프라를 운영하는건 바보같은 행동이다. 적어도 이벤트 한시간전에 스케일링을 하는 방식등을 통해 운영한다.
또한 운영시 스파이크성이 아니라 점차 사용자가 늘어나는 경우, 예를들어 아침에 출근을 하며 쇼핑하는 사람들이 많아 자연스럽게 트래픽이 올라가는 경우, 이럴때에는 오토 스케일링등을 통해 유동적으로 대응해야 한다.
이를 위해 쿠버네티스에서는 HPA를 지원한다.
들어가기전에 간단히 용어를 살펴보면,
스케일업,다운 : 서버의 수는 같으며 서버의 CPU , memory같은 자원을 수직으로 증가시키고 줄이는 행위
스케일아웃, 인 : 같은 서버를 여러개로 증가시키고 줄이는 행위
기본적인 yaml을 살펴보자. 구글클라우드에서 보여주는 기본 yaml예제이다
minReplicas와 maxReplicas는 말그대로 최소,최대 replicas이다, pod는 저 숫자범위에서 움직인다.
또한 spec부분에서 해당 HPA가 발동되기 위한 조건을 명시할 수 있다. CPU, MEM을 몇퍼센트 사용했을시 스케일아웃 될 수 있느닞 설정한다.
사실 개념적인 부분은 이정도가 끝이라고 생각한다. 직접 테스트를 해보면 pod가 스케일 아웃,인 되는것을 쉽게 볼 수 있다.
이 HPA를 현업에 적용하려면 여러가지 생각을 해봐야한다.
단순히 HPA로 무한정 늘려주면 Bottle Neck 현상으로 100%장애가 발생한다고 말하고 싶다.
아래 그림과 같이 아무리 병의 몸통이 커도 결국 입구를 통해 나간다. HPA로 pod를 아무리 늘려도 뒷단에서 받지 못하면 장애가 난다. 특히 DB커넥션에서 많은 문제를 겪었었다.
그래서 성능테스트를 무조건 진행해보고 우리 서비스에 적절한 HPA가 몇인지 장기간 측정한 후 각 모듈에 맞게 적용해야 한다. 또한 HPA가 만능은 아니다, 아무리 서비스가 컨테이너로 기동이 되어도 흔히 커머스에서 사용하는 JVM환경은 기동되는데 최대 수분이 걸릴수 있다. 10~30초만에 수십배로 유입되는 트래픽은 HPA막기에는 한참 부족하다.
대규모 이벤트나 예상이 되는 대규모 트래픽에 대해서는 미리 한시간이든 두시간이든 pod및 DB를 pre warm up 해주고 aws를 사용하는 경우에는 ALB pre warm up도 진행하고 점검하는것이 좋다. 이렇게 늘려놓은 서버로 트래픽을 받을 시 추가적인 스케일아웃은 HPA로 유동적으로 대응가능하다.