지난 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 알뜰하게 사용하기

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


토스

2023년 스타트업의 비용 절감 노력과 토스의 쿠버네티스 CPU 최적화

많은 스타트업들이 비용 절감 노력을 했으며, 서버 자원 최적화가 대표적인 방법이다.

토스는 쿠버네티스를 사용하며 CPU 최적화에 노력했다.

발표는 쿠버네티스에 어느 정도 익숙한 사람들을 대상으로 한다.

쿠버네티스는 여러 서버에서 컨테이너를 실행하고 상태를 관찰 및 제어하는 도구이며, CPU 할당량 설정도 가능하다.

CPU 리퀘스트는 컨테이너가 최소한 사용해야 할 자원량을 보장하며, 리미트는 최대 허용량으로 초과 시 스로틀링 발생한다.

자원 최적화의 개념 및 전제 조건

자원 최적화의 전제 조건은 서비스 안정성 유지이다.

안정성을 유지하면서 비용을 줄여야 의미가 있다.

자원 할당량을 최소화해야 하며, IDC 환경에서는 서버 준비, 클라우드 환경에서는 요금 청구에 영향을 미친다.

자원 할당량을 최소화하면 불필요한 비용을 줄일 수 있다.

자원 사용량을 최소화하고 분산하는 것이 필요하다.

CPU 스로틀링 방지, CPU 할당량(리퀘스트 및 리미트) 최소화, CPU 사용량 최소화 및 분산이 주요 전략이다.

CPU 스로틀링 방지에 대한 자세한 설명과 청능 관점에서의 참고 사항 제시.

CPU 사용량이 낮음에도 스로틀링이 발생하는 현상 설명.

CFS(Completely Fair Scheduler)에 대한 설명: 컨테이너가 워커 노드의 CPU를 공유하기 위한 스케줄러.

병렬성 설정에 대한 설명: 컨테이너는 워커 노드의 OS 커널을 공유하며, 과도한 병렬성 설정은 부하를 야기할 수 있다.

CPU 할당량 최적화 (리사이징) 및 토스뱅크의 정책

리사이징을 통해 안정성과 효율성 사이의 균형을 유지해야 한다.

토스뱅크는 워크로드 성격에 따라 다른 정책을 사용한다.

대고객 서비스는 안정성이 중요하며, CPU 리미트를 설정하지 않는다.

토스뱅크는 데이터 센터 두 곳을 액티브-액티브 형태로 운영한다.

대고객 서비스가 아닌 인프라 워크로드는 안정성이 상대적으로 덜 중요하며, CPU 리퀘스트는 하루 최대 사용량과 비슷하게, 리미트는 여유 있게 설정한다.

오토 스케일링 대신 프로젝션 방식 활용 및 알람 활용

토스뱅크는 IDC 환경을 사용하며, 오토 스케일링은 위험할 수 있다.

오토 스케일링 대신 최대 부하를 추산하고 자원을 할당하는 프로젝션 방식을 사용한다.

변화에 맞춰 조정하기 위해 알람을 활용한다.

그라파나, 프로메테우스, 타노스를 사용하며, CPU 할당량이 너무 낮거나 높을 때 알람을 발생시킨다.

기준 메트릭으로 CPU 리퀘스트 대비 사용량 비율을 사용한다.

토스의 클라우드 환경 CPU 최적화 및 자원 분산 전략

클라우드 환경에서의 CPU 라이트 사이징, IDC 최적화, 자원 분산 노력에 대한 설명.

클라우드 환경에서 오버 프로비저닝은 즉시 비용 낭비로 이어진다.

신규 서비스의 성장에 따른 리소스 사이징의 어려움과 리소스 프래그멘테이션 문제 발생.

데몬셋의 고정 리소스 사용량 문제와 노드 스케일업을 통한 해결 방안.

2022년 대비 2023년 트래픽 증가율(20%) 대비 CPU 증가율(40%)의 비효율성 문제 제기.

CPU 최적화 작업 진행 및 효율화 영역

CPU 최적화 작업을 통해 서버 증설 없이 유저 증가 대응.

라이트 사이징은 할당과 사용률 간 갭 최적화, CPU 최적화는 불필요한 연산 제거를 통한 완전 최적 사이즈 구현이다.

최적화 영역은 클러스터 운영 컴포넌트(인프라)와 비즈니스 마이크로서비스로 나뉜다.

인프라 영역 효율화: Istio 믹서 대체, 토스 믹서 개발 및 도입으로 리소스 감소.

CPU 사용량 분산 전략 및 문제 해결

특정 노드에 CPU 사용량이 집중되는 문제 발생.

스케줄러 분배 문제점: 라벨 셀렉터와 우선순위 기반 스케줄링으로 인해 부하 분산 실패.

토폴로지 스프레드 컨스트레인트 기능 활용: 특정 서비스 그룹을 모든 노드에 동일하게 분배.

괴리율 40%에서 20%로 개선, 향후 부하 기반 스케줄러 도입 계획.

🚀 쿠버네티스 CPU 최적화 배경 및 목표

2023년, 많은 스타트업들이 비용 절감을 위해 노력했습니다. 토스 역시 예외는 아니었으며, **서버 자원 최적화가 핵심적인 방법 중 하나**였습니다. 토스에서는 쿠버네티스를 많이 사용하므로, 쿠버네티스 환경에서 CPU 최적화를 위한 노력에 집중했습니다.

자원 최적화의 전제 조건은 서비스 안정성 유지입니다. **비용을 줄이는 것도 중요하지만, 안정성을 유지하면서 비용을 절감해야 의미가 있습니다**. 또한 자원 할당량을 최소화하고, 사용량을 최소화 및 분산하는 것이 중요합니다.

CPU 사용량 추이가 리미트보다 낮은데도 스로틀링이 발생하는 경우가 있습니다. 이는 **CFS(Completely Fair Scheduler)의 쿼타(Quota) 때문**입니다. 컨테이너가 할당량 비율대로 타임슬롯을 나눠받기 때문에, 순간적으로 많은 CPU를 사용하면 스로틀링이 발생할 수 있습니다.

이러한 현상을 완화하기 위해 쿼타 피리어드 설정을 조정하거나, **CPU 쿼타 기능을 비활성화할 수 있습니다**. 병렬성 설정 역시 중요하며, 어플리케이션 종류와 버전에 따라 병렬 설정이 CPU 코어 개수에 연동되지 않도록 확인해야 합니다.

⚖️ CPU 할당량 최적화 (리사이징)

자원 할당량 최적화는 리사이징이라고도 불립니다. 할당량이 부족하면 서비스가 불안정해지고, 과도하면 불필요한 비용이 발생합니다. **안정성과 효율성 사이의 균형을 맞추는 것이 중요합니다**. 토스뱅크는 워크로드 성격에 따라 다른 정책을 사용합니다.

대고객 서비스의 경우 안정성이 가장 중요하므로, CPU 리퀘스트는 평상시 최대 사용량의 두 배로 설정하고, 스로틀링 방지를 위해 CPU 리미트는 설정하지 않습니다. 인프라 성격의 워크로드의 경우, CPU 리퀘스트는 하루 최대 사용량과 비슷하게, 리미트는 조금 더 여유 있게 설정합니다.

토스뱅크는 IDC 환경을 사용하고 있어 오토 스케일링은 사용하지 않고, 대신 최대 부하를 추산하여 자원을 할당하는 프로젝션 방식을 사용합니다. **CPU 사용량 변화에 맞춰 알람을 활용하여 대응하는 것이 중요합니다**.

CPU 할당량이 너무 낮아 여유가 부족할 때, 그리고 할당량이 너무 높아 자원이 낭비될 때 알림을 설정합니다. **기준 메트릭으로는 CPU 리퀘스트 대비 사용량 비율을 사용하며, 노이즈 제거가 중요합니다**.

웜업(Warm-up)으로 인한 초기 부하를 무시하기 위해 프롬QL 클램프를 사용하고, 새벽/주말 트래픽 감소로 인한 노이즈를 줄이기 위해 프롬QL 맥스 오버타임을 사용하여 최근 1주일 동안의 최댓값을 기준으로 알림을 설정합니다. 맥스 오버타임 중첩 방식을 통해 프로메테우스 타노스의 과부하를 방지합니다.

☁️ 클라우드 환경에서의 CPU 최적화

클라우드 환경에서는 오버 프로비저닝 시 즉시 비용 낭비가 발생하므로, IDC 환경처럼 민첩한 할당 최적화가 필요합니다. 서비스 성장 속도에 맞춰 EC2 사이즈를 늘려야 하는데, **리소스 프래그멘테이션(Resource Fragmentation) 이슈**가 발생할 수 있습니다.

클러스터 증가에 따라 EC2 스펙이 잘 올라가지 않아 리소스 사용률이 높아지는 경우가 있습니다. **노드를 스케일업하여 전체 리소스 사용률을 줄이고, EC2 비용을 절감할 수 있습니다**.

CPU 최적화는 할당과 사용률의 갭을 최적화하는 것을 넘어, **실제로 연산 중에 불필요한 연산이 없는지 제거하여 완전한 최적 사이즈를 만드는 것**입니다. 클러스터 운영을 위한 컴포넌트와 마이크로서비스 튜닝을 통해 CPU 최적화를 진행할 수 있습니다.

인프라 영역 효율화 중, 이스티오(Istio)의 리소스 사용량이 높았습니다. 기존 이스티오 텔레매트리의 비효율성을 개선하기 위해 토스 믹서(Toss Mixer)를 개발했습니다. Envoy Access Log Service를 통해 트래픽 정보를 수집하고, 메트릭을 어그리게이션(Aggregation)하여 프로메테우스의 메트릭 카디널리티 이슈를 해결했습니다. **결과적으로 이스티오 리소스가 3/4 감소하고, 프로메테우스 1/4 리소스 감소 효과를 얻었습니다**.

프로메테우스와 타노스 역시 리소스 사용률이 높은 컴포넌트입니다. 불필요한 메트릭을 제거하고, 오픈소스 업그레이드를 통해 TSDB 성능을 효율화하고, 고랭(Go)을 최적화하여 리소스 사용량을 줄일 수 있습니다. 특히, **잘못된 라벨 사용으로 인한 메트릭 카디널리티 증가를 방지해야 합니다**.

특정 타이밍에 피크 타임이 비슷한 서비스들이 특정 노드에 몰려 과부하가 발생하는 문제가 있었습니다. 이를 해결하기 위해 **쿠버네티스 토폴로지 스프레드 컨스트레인트(Topology Spread Constraints) 기능을 활용했습니다**. 피크 트래픽이 비슷한 서비스들을 묶어 모든 노드에 같은 개수로 분산시켜 과부하 문제를 해결했습니다.

토폴로지 스프레드 컨스트레인트 적용 결과, CPU 사용률 괴리율이 40% 포인트에서 20% 포인트로 개선되었습니다. 향후 부하 기반 스케줄러와 디스케줄러 도입을 통해 더욱 효율적인 CPU 사용량 분산을 목표하고 있습니다.

CPU 리퀘스트 라이트 사이징을 통해 오버 프로비저닝을 방지하고, 노드 스펙을 올려 데몬셋 개수를 줄여 리소스 프래그멘테이션을 방지하고, 불필요한 연산과 모니터링 아키텍처를 개선하여 CPU 사용률을 최소화하고, 토폴로지 웨어를 통해 CPU 사용률을 골고루 분산하는 것이 중요합니다. **이러한 노력들을 통해 토스는 수백억의 증설 없이 유저 증가에 대응할 수 있었습니다**.