CWIST의 응답 속도 문제: 빠른 녀석만 빠르면 안 되나?

CWIST의 가벼운 벤치마크에서는 96개의 제한된 풀이 일부만 빠르게 응답하게 만들어도 좋았습니다.

하지만 CWIST의 오랜 문제인 C1M의 경우, Axum도 Spring도 처리하지만 CWIST에서는 기아가 발생했습니다. 결국에는 CWIST가 요청 수에 맞게 스레드 풀 크기를 조정해서 공정성을 키워야 했습니다.

가장 큰 문제: 1 ms 내외의 지연이 wrk 등의 벤치에서 계속 생긴다

빠른 녀석만 빨리 응답하고 나머지는 나가 있으라는 꼼수가 사라지니, 1.x-2.x ms 수준의 지연이 계속 생깁니다. Axum이 같은 벤치에서 2.x-3.x ms 대이지만, 사실 끽해야 2배 빠른 것입니다.

하지만, 요청 수가 충분히 적을 경우 여전히 0.x ms대를 유지하긴 합니다.

이것이 의미하는 것

이것은 일상적인 상황에서는 CWIST가 충분히 빠르지만, 그렇지 않은 상황에서는 Axum 수준으로 밀릴 수 있다는 얘기입니다. 정말 이것을 극복할 수 있을까요?

Little's Law

정말 아쉽게도 이러한 지연은 Little's Law라는 법칙을 따라서, 0.x ms 대의 지연을 수십만 개의 연결에도 항상 유지하는 것은 불가능합니다. 큐잉이라는 방법 자체의 한계라고 볼 수 있는데요, 만약 서버의 코어가 아주 많다면(AMD 쓰레드리퍼 등 유명한 것들이 있습니다) 그래도 CWIST는 여전히 저지연의 가치를 제공할 수 있습니다. 하지만 가장 문제는 가상 환경 등에서는 아무리 시스템 콜을 줄여도 지연 시간은 1 ms 수준에서 머물 것이라는 이론적 한계입니다.

풀의 개수가 동적이면 응답이 늘수록 RSS가 증가한다

이것이 가장 치명적인 문제입니다. 동적으로 스레드 풀을 늘리면서 응답을 시도하면 메모리 점유율이 선형적으로 증가합니다.

이 문제를 개선하기 위해 응답의 큐잉을 Axum 스타일과 유사하게 도입해 보았습니다. 이것이 가져온 결과가 좋았든 싫었든간에, Axum보다 여전히 1.5배 이상 빠르지만 1-2 ms 정도의 지연이 생깁니다. 하지만 이 경우 꼬리 지연 등에서 스레드 풀을 늘리는 경우보다 큐잉이 악화되었고, 더 큰 문제는 이것이 예측 가능성을 저해한다는 것입니다.

일단은 모드를 나누자

일단은 적극적인 큐잉을 도입하는 CWIST_USE_C1M 플래그를 만들어서 동시 백만 개 요청을 처리할 수 있으나, 꼬리 지연이 약간 악화되는 문제를 감수하는 것과, 메모리 점유율을 늘리고 수백 만 개의 요청을 처리할 수 없는 스레드 풀 모드 두 가지를 두어, 사용자가 끄고 킬 수 있게 하였습니다. 이 블로그는 매우 저렴한 VPS 요금을 쓰고 있기 때문에 메모리가 부족합니다. 따라서 이 경우에는 C1M 모드를 씁니다. 하지만 메모리는 넉넉하고 꼬리 지연이 중요하다면 이것을 끌 수 있습니다.

우리가 이것을 보고 고민해야 할 것은 무엇인가

우리는 일단 이 작업에 대한 참신한 아이디어를 되도록 잘 고민해서 쓸 필요가 있습니다. 유명한 수학자들이나 공학자들이 '이것은 한계입니다'라고 그어 둔 선에서 줄넘기를 하려면 전통적인 CS 지식만으론 되지 않을 수 있고, 끝끝내 이 벽을 돌파하지 못할 가능성 역시 큽니다. 이것은 일반적인 방법론으로 도저히 해결할 수 있는 문제가 아닌 것 같습니다. 아마 방법을 찾기 위해 가능하면 고전적인 자료구조 밖에서 더 많은 것을 소개해야겠습니다.