10년 된 제온 서버를 174번 재부팅해서 초당 4건을 더 얻어낸 이야기

10년 된 제온 서버를 174번 껐다 켜서 얻어낸 '초당 4건'

성능 튜닝 이야기 중에 가끔 이렇게 집요한 글이 있어요. 어떤 분이 10년 묵은 인텔 제온(Xeon) 서버 한 대를 무려 174번이나 재부팅하면서, 커널 옵션 12개를 하나씩 꺼본 끝에 처리량을 초당 4건(4 tps) 끌어올린 과정을 기록했거든요. "초당 4건이 뭐가 대수냐" 싶을 수 있는데, 한 건 한 건이 무거운 데이터베이스 트랜잭션이라면 이게 꽤 큰 비율이에요. 그리고 이 이야기가 흥미로운 건 숫자보다 '무엇을 껐는가'에 있어요.

그 12개의 플래그는 대체 뭘까

여기서 끈 옵션들은 거의 다 CPU 보안 취약점 완화(mitigation) 기능이에요. 혹시 2018년쯤 '스펙터(Spectre)'랑 '멜트다운(Meltdown)'이라는 단어 들어보셨어요? 이게 뭐냐면, 현대 CPU가 빠르게 동작하려고 '아마 이 명령을 다음에 실행하겠지?' 하고 미리 앞서 계산해두는 '투기적 실행(speculative execution)'이라는 기술이 있는데, 이 과정에서 흘러나오는 미세한 시간 차이를 이용하면 원래 못 봐야 할 다른 프로그램의 메모리를 훔쳐볼 수 있다는 게 밝혀졌거든요.

그래서 운영체제와 CPU 제조사들이 부랴부랴 방어막을 씌웠어요. 대표적으로 메모리 영역을 격리하는 KPTI, 분기 예측을 초기화하는 retpoline/IBRS, MDS·L1TF 같은 데이터 유출 방어들이 있죠. 문제는 이 방어막들이 전부 '공짜가 아니라는' 거예요. 매번 추가 검사를 하고, 캐시나 예측기를 비우고, 작업을 전환할 때마다 부가 작업을 하니까 그만큼 CPU가 느려져요. 특히 글 속 서버처럼 10년 전 하드웨어는 이런 방어가 칩 자체에 내장돼 있지 않아서, 전부 소프트웨어로 흉내 내야 하니 성능 손해가 더 크거든요.

왜 하나씩, 174번이나?

mitigations=off 한 줄이면 전부 꺼지는데 왜 굳이 12개를 따로따로 껐을까요? 바로 '어떤 방어가 내 작업 부하에서 진짜 비싼가'를 정확히 알고 싶었기 때문이에요. 부팅 옵션을 하나 바꾸고 → 재부팅하고 → 벤치마크 돌리고 → 결과 기록하고. 이걸 조합을 바꿔가며 반복하니 174번이라는 숫자가 나온 거죠. 이렇게 변수를 하나씩만 건드리며 측정하는 게(통제 실험) 성능 분석의 정석이에요. "대충 다 끄니까 빨라졌어"가 아니라 "이 방어가 우리 워크로드에서 X%를 먹더라"라고 말할 수 있게 되는 거니까요.

그런데 이거, 함부로 따라 하면 안 돼요

여기서 꼭 짚어야 할 게 있어요. 이 방어막들을 끄면 빨라지는 건 맞지만, 그만큼 CPU 취약점에 다시 노출되거든요. 그래서 이건 아무 데나 쓰면 안 되고, '믿을 수 있는 코드만 도는, 외부의 낯선 코드를 실행하지 않는 단일 사용자 서버'에서나 고려할 수 있는 선택이에요. 예를 들어 여러 고객의 코드를 한 칩에서 같이 돌리는 클라우드나, 브라우저처럼 남의 코드를 실행하는 환경에서 이걸 끄면 정말 위험해요. 반대로 우리 회사 전용으로 격리된 배치 처리 서버, 사내 데이터 전용 머신이라면 보안과 성능을 저울질해볼 만하죠.

한국 개발자에게 주는 시사점

요즘은 다들 클라우드만 쓰다 보니 '커널 부팅 파라미터' 같은 건 남의 일처럼 느껴질 수 있는데요. 그래도 온프레미스(자체 서버)나 베어메탈을 운영하는 곳이라면, 그리고 오래된 서버를 아직 굴리고 있다면 이 완화 패치 오버헤드가 생각보다 클 수 있어요. 한 번쯤 lscpu로 내 CPU가 어떤 취약점에 노출돼 있고 어떤 완화가 켜져 있는지 확인해보고, /sys/devices/system/cpu/vulnerabilities/ 디렉터리를 들여다보는 것만으로도 배울 게 많거든요. 무엇보다 이 글의 진짜 교훈은 '추측하지 말고 측정하라', 그리고 '성능과 보안은 늘 저울 위에 있다'는 거예요.

한 줄로 정리하면, 공짜 성능은 없고, 보안 방어를 끄는 것도 결국 트레이드오프라는 거죠. 여러분 회사에서는 서버 보안 완화 패치, 성능을 위해 일부라도 꺼본 적 있으세요? 어떤 기준으로 결정하셨는지 궁금하네요.