지난 2023년에는 저희를 포함해서 많은 스타트업에서 비용을 줄이려고 노력했던 것 같은데요.

이 비용을 줄이는 방법에는 여러 가지가 있지만, 이 서버의 자원을 최적화하는 게 가장 대표적인 방법 중에 하나인 거 같아요.

저희 토스에서는 쿠버네티스를 많이 사용을 하고 있고, 그래서 쿠버네티스 환경에서 CPU 최적화하기 위해서 노력했던 이야기들을 준비했습니다.

전 토스뱅크 데브옵스 김동석입니다.

반갑습니다. 오늘 내용은 쿠버네티스에 어느 정도 익숙하신 분들을 대상으로 준비했는데요.

그래도 잠깐 살펴보고 시작을 하도록 할게요.

이 쿠버네티스는 이제 여러 서버에서 컨테이너를 실행하고 상태를 관찰하고 제어할 수 있는 도구입니다.

그리고 CPU 할당량에 대한 설정도 할 수 있고요.

먼저 CPU 리퀘스트인데요. 리퀘스트는 컨테이너가 최소한 이만큼은 사용할 수 있어야 한다는 보장입니다.

만약에 서버 자원이 충분히 여유가 있다면은 이것보다 더 많이 사용할 수도 있고요.

다음으로 CPU 리미트 설정이 있는데요.

이건 CPU 최대 허용량이라고 생각하시면 됩니다.

그래서 이것보다 더 많이 사용하려고 하면 스로틀링이 발생할 수 있고요.

방금 말씀드린 CPU 스로틀링, CPU 할당받지 못해서 기다리는 현상을 말하는데요.

여기 보시는 것처럼 이제 하늘색만큼 CPU 사용을 했지만 노란색만 중간중간 스로틀링이 발생했기 때문에 전체 응답 속도가 더 느려진 것을 보실 수 있습니다.

그러면 이제 오늘의 주제인 이 자원 최적화의 개념에 대해서 살펴보도록 할 텐데요.

이 자원 최적화의 전제 조건은 서비스 안정성이라고 할 수가 있을 것 같아요.

우리가 비용을 줄이는 것도 중요하지만 안정성을 유지하면서 비용을 줄여야 의미가 있겠죠.

그리고 다음은 자원 할당량을 최소화하는 겁니다.

만약에 IDC 환경이라면 자원 할당량에 맞춰서 서버를 준비해야 될 것이고 클라우드 환경이라면 자원 할당량에 맞춰서 요금이 청구되니까요.

그리고 보통 여유를 두기 때문에 할당량을 사용량보다 더 크게 마련이고 그래서 자원 할당량을 최소화하면은 불필요하게 쓰고 있는 비용들을 좀 줄일 수가 있을 겁니다.

그리고 마지막으로는 자원 사용량을 최소화하고 분산하는 것도 필요한데, 그러면은 꼭 필요한 비용의 규모까지 줄일 수가 있겠죠.

이 과정을 쿠버네티스의 CPU 한번 대입해 보겠습니다.

먼저 CPU 스로틀링 방지해야 될 것이고요.

그러면서 CPU 할당량이 퀘스트와 리미트를 최소화해야 합니다. 그리고 마지막으로 CPU 사용량을 최소화하고 분산하는 거라고 할 수 있을 것 같아요.

그럼 이 중에서 CPU 스로틀링 방지하는 것에 대해서 먼저 자세하게 이야기해 볼게요.

이 내용은 자원 최적화 말고도 성능 관점에서도 참고하실 수 있을 것 같습니다.

CPU 지표를 관찰하다 보면은 CPU 사용량 추위가 리미트 보다 낮은데도 스로틀링이 발생하는 특이한 현상을 보실 수가 있어요.

보시는 것처럼 CPU 사용량이 5보다 낮은데 사실 리미트는 15거 그러면 사실 로드가 발생하지 않아야 될 것 같지만 실제로는 발생을 하는 겁니다.

그럼 이런 현상들을 우리가 이해하기 위해서는 CFS에 대해서 잠깐 살펴봐야 되는데요.

CFS 컨테이너가 워커 노드의 CPU 공유하기 위해서 사용하는 CPU 스케줄러입니다.

그래서 각각의 컨테이너는 자기가 실행되고 있는 워크로드의 모든 CPU 사용하면서 타임 슬라이스를 할당량 비율대로 나눠서 분배 봤죠.

그럼 이 CFS 동작에는 코타라는 것이 있는데요.

우리가 아까 앞에서 살펴봤던 리미츠 설정을 하게 되면은 이만큼 더 적게 쓰도록 해야 되기 때문에 CPU 사용량이 할당량 리미트를 넘는지 주기적으로 확인하게 됩니다.

그래서 이 주기적으로 확인하는 시간 단위가 100ms이고 할당량이 50% 컨테이너가 있다고 하면은 이제 만약에 50ms 사용했으면 이미 50% 다 채웠으니까 나머지 시간 동안은 기다려야 되고요.

그렇기 때문에 이제 전체적인 사용량의 추세는 할당량보다 낮더라도 한순간 많이 사용하게 되면은 이런 특성으로 인해서 스로틀링이 발생할 수 있는 겁니다.

그럼 이런 현상을 완화하기 위해서는 이 쿼터 피리어드 설정을 살펴보면 좋은데요.

아까 앞에서 살펴봤던 CFS CPU 사용량 확인을, 아, 사용량을 확인하는 간격에 대한 설정입니다.

그래서 만약에 이 간격을 1초로 줄이게 되면 이 최대 발생하는 스로틀링 시간도 1초로 줄어들게 되고요.

그리고 이 문제를 완전히 방지하려면 이 큐에서 쿼터 기능을 아예 비활성화할 수도 있습니다.

아니면은 특정 컨테이너 대에서 리미트 설정을 하지 않으면은 또 이런 쿼터가 동작하지 않게 해야 되고요.

뭐 이러면은 이제 확실하게 이 문제를 발제할 수는 있지만은 이제 아무래도 컨테이너 CPU 사용에 대한 제한이 없어지는 만큼 모니터링에 조금 더 신경을 써야 되겠죠.

다음으로 병렬성 설정에 대해서도 살펴보면 좋은데요.

컨테이너는 워커 노드의 OS 코어를 공유하기 때문에 CPU 코어를 이제 워커 노드 똑같이 인식합니다.

자기가 이 서버를 다 쓴다고 생각을 하는 거죠.

그렇기 때문에 만약에 병렬성 설정이 CPU 코어 개수에 연동되도록 돼 있다면은 이제 과도한 부하가 생길 수가 있습니다.

그래서 앞서 살펴봤던 CPU 스로틀링이 생기기도 쉽고요.

그래서 애플리케이션 종류와 버전에 따라서 이 병렬성 설정이 어떻게 되는지 확인해 보는 것도 중요합니다.

다음으로 CPU 할당량을 최적화하는 걸 살펴볼 텐데요. 이렇게 자원 할당량을 최적화하는 활동을 흔히 라이트사이징이라고 부릅니다.

만약에 할당량이 부족하면 서비스가 불안정할 수 있고 할당량이 과도하면 불필요한 비용이 발생하겠죠.

그래서 안정성과 효율성 사이에서 균형을 지킬 수 있는 정책을 사용해야 됩니다.

저희 토스뱅크에서는 이 워크로드 성격에 따라서 다른 정책을 사용하고 있어요.

그중에 대고객 서비스랑 직접 연관된 그런 워크로드가 있을 텐데요.

이 경우에는 안정성이 가장 중요하다고 할 수 있습니다.

잠시 얘기하기에 앞서서 저희 토스뱅크의 데이터 센터에 대해서 설명을 드릴게요.

저희는 데이터 센터 두 곳을 액티브 액티브 형태로 운영하고 있는데요.

만약에 한 곳에 문제가 생기면 나머지 한 곳으로만 서비스를 할 수 있어야 됩니다.

그리고 이때는 평소에 봤던 것보다 두 배 트래픽을 소화할 수 있어야 되고요.

그렇기 때문에 저희는 리퀘스트를 평상시 최대 사용량의 두 배가 되도록 기준을 설정하고 있습니다.

이 액티브 액티브에 대해서 더 궁금하신 분께서는 SLASH 2021 이항령 님의 발표를 참고해 주시고요.

그리고 이 대고객 서비스는 그 안정성이 중요하기 때문에 앞서 살펴봤던 그런 스로틀링 방지하기 위해서 CPU 리미트는 설정하지 않고 있습니다.

그리고 대고객 서비스가 아닌 나머지 인프라 성격의 워크도 있는데요, 이 경우에는 안정성이 상대적으로 덜 중요하다고 할 수 있겠죠.

그래서 CPU 리퀘스트는 하루 최대 사용량과 비슷하게, 그리고 리미트는 조금 더 여유 있게 설정하고 있습니다.

지금까지의 내용을 들으시면서 오토 스케일링을 떠올리신 분들이 많을 것 같은데요.

오토 스케일링은 데이터를 기준으로 해서 자원 할당량을 자동으로 조정하는 것을 말하죠.

근데 저희 토스뱅크는 IaaS 환경을 사용하고 있습니다.

이런 환경에서는 오토 스케일링이 오히려 위험할 수 있는데요.

이제 보통 오토 스케일링을 하게 되면은 부하가 많을 때 팟이 새로 할당되면 늘어나게 되잖아요.

근데 이때 서버를 즉시 늘릴 수가 없기 때문에 이미 있는 서버 자원에 대부분이 점유가 될 수 있습니다.

그럼 그때 만약에 꼭 필요한 배포가 있다면은 오히려 못 할 수도 있겠죠.

그래서 저희는 오토 스케일링은 사용하지 않고 있고요. 대신에 저희는 프로젝션 같은 방식으로 접근을 하고 있어요.

이거 이제 최대 부하를 추산하고 거기에 맞춰서 자원을 할당하는 방식이라고 할 수 있을 것 같은데요.

이 CPU 사용량이 항상 변하기 때문에 우리는 미리미리 그 변화에 맞춰서 조정할 수 있어야 됩니다.

그러기 위해서는 얼럿을 활용해 가지고 대응할 수 있어야 될 것이고요.

그래서 지금부터는 이제 저희 얼럿에 대해서 조금 더 자세하게 설명드리도록 하겠습니다.

저희는 매트릭 모니터링 도구로 그라파나, 프로메테우스, 타노스를 사용을 하고 있고요.

얼럿은 크게 두 가지가 있습니다.

CPU 할당량이 너무 낮아서 여유가 부족할 때, 그리고 할당량이 너무 높아서 자원이 낭비될 때 이렇게 두 상황을 알려주는 얼럿이 있고요.

얼럿을 잘 활용하기 위해서는 이제 또 기준 메트릭을 무엇으로 할지, 그리고 이제 노이즈를 어떻게 제거할지 또 고민해 봐야 합니다.

먼저 저희는 기준 메트릭으로 CPU 리퀘스트 대비 사용량 비율을 사용하고 있습니다.

처음에 살펴봤던 것처럼 리퀘스트를 넘는 사용량은 보장되지 않을 수 있기 때문에 안정적인 성능을 위해서 이거보다 낮게 유지하기 위함이고요.

노이즈는 이제 정확하지 않거나 중요하지 않은 알트를 말하는데요. 이런 것들이 많이 발생하게 되면은 주목도가 떨어지기 때문에 노이즈를 제거하는 것도 상당히 중요합니다.

저희 토스뱅크는 대부분 코틀린과 스프링으로 구성이 되어 있어요.

그렇기 때문에 웜업을 하는 동안 CPU 아주 많이 사용하는데요.

그럼 그때마다 노이즈가 발생하는 게 당연하겠죠.

그래서 초기 부하를 무시하기 위해서 저희는 프롬 큐 클램프를 사용해서 이 동안에 부하를 무시하고 있고요.

그리고 저희 토스뱅크는 대한민국에서만 서비스를 하고 있습니다.

그래서 새벽이랑 주말에는 트래픽이 아주 적어요.

근데 이제 저희 CPU 사용률이 너무 낮다는, 이제 다시 말해서 할당량이 높다는 알트가 이제 실시간 값을 기준으로 한다면은 새벽과 주말마다 노이즈가 발생하겠죠.

그런데 만약에 최근 일주일 동안의 최댓값을 기준으로 한다면은 실시간 값 대신에 그러면 아마 주기적으로 낮아지는 걸 무시할 수 있을 겁니다.

그래서 저희는 프롬 QL 맥스 오버타임을 사용해서 최근 1주 동안의 최댓값을 계산해서 활용하고 있고요.

그런데 방금처럼 1분 단위로 7일 동안에 맥스 오볼 타임을 계산하게 되면은 180개의 데이터가 쓰이게 됩니다.

연산이 아주 많겠죠. 그래서 프로메테우스 타노스에 과부화가 걸릴 수 있고, 그라파나에 타임아웃이 발생할 수도 있습니다.

그럼 이 문제를 해결하기 위해서 만약에 시간 해상도를 낮춘다. 그러면 사실 데이터 개수가 줄어드니까 간단하게 할 수 있지만은 그 최댓값을 계산하는 데이터 방식이 달라지겠죠.

그렇기 때문에 이 경우 적절한 방법이라고 할 수 없을 것 같고요.

그래서 저희는 맥스 오버타임을 중첩하는 방식으로 이런 문제를 해결하고 있습니다.

먼저 레코딩을 사용해서 1분 단위로 30분 동안의 최댓값을 계산해서 저장해 놓습니다.

그게 파란색이, 그다음에 이 결과를 가지고 15분 단위로 이제 7일 동안의 최댓값을 계산하는 겁니다.

그러면은 처음과 동일하게 1분 단위의 최댓값을 계산할 수 있지만 이 계산에 사용되는 그 최종 계산에 사용되는 데이터 양은 1로 줄어들기 때문에 이제 똑같은 결과를 얻으면서도 훨씬 부하를 줄일 수 있는 거죠.

토스ㅣSLASH 24 - Kubernetes CPU 알뜰하게 사용하기

금융의 모든 것, 토스에서 쉽고 간편하게
