2018.03.30

IDG 블로그 | 멜트다운 패치의 성능 영향, 생각만큼 나쁘지 않다

Andy Patrizio | Network World
업계 선도 업체들의 내부 테스트에서 리눅스나 윈도우 서버를 구동하는 서버에 적용한 멜트다운과 스펙터 패치가 처음 생각했던 것만큼 나쁜 영향을 미치지는 않는 것으로 나타났다. 또한 많은 사용례가 영향이 전혀 없었다.

지난 1월 공개된 멜트다운과 스펙터 취약점은 가상화 시스템의 악몽으로 여겨졌지만, 예상 피해 효과는 과장된 것이었다. 또 어떤 작업을 하고 어느 세대의 프로세서를 사용하는가에 따라 영향이 달라진다.

Project Zero

테스트는 2014년 출시된 하스웰 기반 제온과 2016년 출시된 브로드웰 기반 제온, 2017년 출시된 스카이레이크 기반 제온을 구동하는 서버에서 진행됐다. 하스웰과 브로드웰은 소소한 차이만 있는 동일한 마이크로아키텍처이다. 브로드웰의 가장 큰 차이는 다이 크기가 작아졌다는 것. 스카이레이크는 완전히 새로운 아키텍처인데, 이 때문에 결과는 차이를 보였다.

멜트다운과 스펙터는 가상화 환경에 가장 큰 악영향을 미친다. 전환이 많이 이루어지고 애플리케이션은 특권 모드에서 많은 시간을 사용하며, 잦은 시스템 호출과 개입 및 많은 사용자와 커널의 특권 변경이 일어나기 때문이다.

그리고 벤치마크 결과 모든 취약점을 완화하는 패치를 적용한 시스템은 일반 컴퓨팅부터, 정수 연산, 부동소수점 연산, 린팩(Linpack), 스트리밍, 서버 측 애플리케이션, 전력 효율 등 모든 면에서 무시해도 좋을 만큼의 영향을 받았다. 이는 커널 호출을 많이 하지 않고 대부분 작업을 사용자 공간에서 실행했기 때문이다.

또한 네트워크 패킷 최적화 기능인 DPDK를 사용하는 애플리케이션도 영향이 없었다. DPDK는 입출력이 높은 라이브러리이지만, 패킷이 CPU가 아니라 네트워크 카드로 바로 전달되기 때문에 커널을 우회해 전달된다. 익명을 요구한 전문가는 “입출력 활동이 많은 것은 어떤 것이라도 심각한 영향을 받을 것이라고 생각했지만, 현실은 그렇지 않았다. DPDK는 패킷을 전달하는 입출력 집약적인 워크로드이지만, 커널을 우회한다. DPDK의 성능이 높은 이유는 커널에서 보내는 시간을 최소화했다는 것이다”라고 설명했다.

하지만 웹 서버에서는 10%의 성능 하락이 일어났다. 웹 페이지 요청이 커널로 전달되고, 커널 전환이 과부하를 더하기 때문이다.

성능이 엉키는 것은 스토리지 관련 동작이다. 하지만 부분적이고 특정 환경에서만 성능 저하가 일어난다. 우선 스카이레이크는 마이크로아키텍처가 변경되면서 영향을 받지 않는다. 하스웰과 브로드웰 서버는 30%의 성능 하락이 발생하지만, IBRS란 패치를 사용했을 때만 일어난다. 이 패치는 인텔이 제공한 것으로, 리누스 토발즈로부터 혹평을 받은 바 있다. IBRS 대신 구글이 개발한 레트폴린(Retploline)을 사용하면, 성능 하락은 1~2%에 그친다.

구글은 멜트다운과 스펙터 취약점을 발견한 업체이고, 패치를 만들 시간이 있었다. 이 때문에 리눅스 세계의 많은 곳이 새로운 커널이 필요하고 애플리케이션을 재컴파일해야 함에도 불구하고 레트폴린으로 일치단결하고 있다.

경감 요소는 더 있다. 64kb 블록을 사용한 파일 입출력 스토리지 벤치마크에서 스카이레키는 10%, 브로드웰과 하스웰은 20%의 성능 저하를 기록했다. 블록 크기를 4kb로 줄이면 각각 32%와 60%의 성능 저하가 발생한다. 이유는 간단하다. 1GB 용량의 파일을 4kb 블록으로 읽어들이는 것은 읽고 옮겨야 하는 블록의 수가 증가하기 때문이다. 각각의 블록은 시스템 보호를 위한 개입을 의미하며, 시스템 성능으로 이어진다.

물론 데이터를 64kb 이상의 블록 크기로만 읽을 수는 없고, 데이터베이스 트랜잭션은 작은 블록을 이용한 읽기가 필요하다. 하지만 한편으로는 이런 벤치마크가 인위적인 환경에서 수행된 것으로 실제 프로덕션 환경에서는 일어나기 힘들다는 점도 고려해야 한다. CPU 활용도 100%는 현실 세계에서는 거의 일어나지 않는다.

또 하나 재미없는 발견은 하드디스크가 SATA SSD보다, 그리고 NVMe SSD보다 영향을 덜 받는다는 것이다. 하드디스크는 느리기 때문이라는 단순한 이유이며, 더 빠른 SSD일수록 더 많은 영향을 받는다.

현재 리눅스 업계는 구글의 레트폴린 패치에 정착한 것으로 보이며, 주요 리눅스 배포판은 모두 이를 지원하도록 업데이트했다. 마이크로소프트는 어떤 식으로든 지원 여부를 밝히지 않았다. 숙적 구글이 만든 것이라는 점에서 마이크로소프트에는 죽기보다 싫은 일일 수도 있다.

현재 패치는 매우 탄탄하기 때문에 더 이상의 새로운 최적화는 진행되지 않을 것으로 보인다. 인텔은 올해 하반기에 멜트다운과 스펙터 취약점을 해결한 신제품을 출시할 계획이지만, 자세한 정보는 아직 공개하지 않았다.  editor@itworld.co.kr


2018.03.30

IDG 블로그 | 멜트다운 패치의 성능 영향, 생각만큼 나쁘지 않다

Andy Patrizio | Network World
업계 선도 업체들의 내부 테스트에서 리눅스나 윈도우 서버를 구동하는 서버에 적용한 멜트다운과 스펙터 패치가 처음 생각했던 것만큼 나쁜 영향을 미치지는 않는 것으로 나타났다. 또한 많은 사용례가 영향이 전혀 없었다.

지난 1월 공개된 멜트다운과 스펙터 취약점은 가상화 시스템의 악몽으로 여겨졌지만, 예상 피해 효과는 과장된 것이었다. 또 어떤 작업을 하고 어느 세대의 프로세서를 사용하는가에 따라 영향이 달라진다.

Project Zero

테스트는 2014년 출시된 하스웰 기반 제온과 2016년 출시된 브로드웰 기반 제온, 2017년 출시된 스카이레이크 기반 제온을 구동하는 서버에서 진행됐다. 하스웰과 브로드웰은 소소한 차이만 있는 동일한 마이크로아키텍처이다. 브로드웰의 가장 큰 차이는 다이 크기가 작아졌다는 것. 스카이레이크는 완전히 새로운 아키텍처인데, 이 때문에 결과는 차이를 보였다.

멜트다운과 스펙터는 가상화 환경에 가장 큰 악영향을 미친다. 전환이 많이 이루어지고 애플리케이션은 특권 모드에서 많은 시간을 사용하며, 잦은 시스템 호출과 개입 및 많은 사용자와 커널의 특권 변경이 일어나기 때문이다.

그리고 벤치마크 결과 모든 취약점을 완화하는 패치를 적용한 시스템은 일반 컴퓨팅부터, 정수 연산, 부동소수점 연산, 린팩(Linpack), 스트리밍, 서버 측 애플리케이션, 전력 효율 등 모든 면에서 무시해도 좋을 만큼의 영향을 받았다. 이는 커널 호출을 많이 하지 않고 대부분 작업을 사용자 공간에서 실행했기 때문이다.

또한 네트워크 패킷 최적화 기능인 DPDK를 사용하는 애플리케이션도 영향이 없었다. DPDK는 입출력이 높은 라이브러리이지만, 패킷이 CPU가 아니라 네트워크 카드로 바로 전달되기 때문에 커널을 우회해 전달된다. 익명을 요구한 전문가는 “입출력 활동이 많은 것은 어떤 것이라도 심각한 영향을 받을 것이라고 생각했지만, 현실은 그렇지 않았다. DPDK는 패킷을 전달하는 입출력 집약적인 워크로드이지만, 커널을 우회한다. DPDK의 성능이 높은 이유는 커널에서 보내는 시간을 최소화했다는 것이다”라고 설명했다.

하지만 웹 서버에서는 10%의 성능 하락이 일어났다. 웹 페이지 요청이 커널로 전달되고, 커널 전환이 과부하를 더하기 때문이다.

성능이 엉키는 것은 스토리지 관련 동작이다. 하지만 부분적이고 특정 환경에서만 성능 저하가 일어난다. 우선 스카이레이크는 마이크로아키텍처가 변경되면서 영향을 받지 않는다. 하스웰과 브로드웰 서버는 30%의 성능 하락이 발생하지만, IBRS란 패치를 사용했을 때만 일어난다. 이 패치는 인텔이 제공한 것으로, 리누스 토발즈로부터 혹평을 받은 바 있다. IBRS 대신 구글이 개발한 레트폴린(Retploline)을 사용하면, 성능 하락은 1~2%에 그친다.

구글은 멜트다운과 스펙터 취약점을 발견한 업체이고, 패치를 만들 시간이 있었다. 이 때문에 리눅스 세계의 많은 곳이 새로운 커널이 필요하고 애플리케이션을 재컴파일해야 함에도 불구하고 레트폴린으로 일치단결하고 있다.

경감 요소는 더 있다. 64kb 블록을 사용한 파일 입출력 스토리지 벤치마크에서 스카이레키는 10%, 브로드웰과 하스웰은 20%의 성능 저하를 기록했다. 블록 크기를 4kb로 줄이면 각각 32%와 60%의 성능 저하가 발생한다. 이유는 간단하다. 1GB 용량의 파일을 4kb 블록으로 읽어들이는 것은 읽고 옮겨야 하는 블록의 수가 증가하기 때문이다. 각각의 블록은 시스템 보호를 위한 개입을 의미하며, 시스템 성능으로 이어진다.

물론 데이터를 64kb 이상의 블록 크기로만 읽을 수는 없고, 데이터베이스 트랜잭션은 작은 블록을 이용한 읽기가 필요하다. 하지만 한편으로는 이런 벤치마크가 인위적인 환경에서 수행된 것으로 실제 프로덕션 환경에서는 일어나기 힘들다는 점도 고려해야 한다. CPU 활용도 100%는 현실 세계에서는 거의 일어나지 않는다.

또 하나 재미없는 발견은 하드디스크가 SATA SSD보다, 그리고 NVMe SSD보다 영향을 덜 받는다는 것이다. 하드디스크는 느리기 때문이라는 단순한 이유이며, 더 빠른 SSD일수록 더 많은 영향을 받는다.

현재 리눅스 업계는 구글의 레트폴린 패치에 정착한 것으로 보이며, 주요 리눅스 배포판은 모두 이를 지원하도록 업데이트했다. 마이크로소프트는 어떤 식으로든 지원 여부를 밝히지 않았다. 숙적 구글이 만든 것이라는 점에서 마이크로소프트에는 죽기보다 싫은 일일 수도 있다.

현재 패치는 매우 탄탄하기 때문에 더 이상의 새로운 최적화는 진행되지 않을 것으로 보인다. 인텔은 올해 하반기에 멜트다운과 스펙터 취약점을 해결한 신제품을 출시할 계획이지만, 자세한 정보는 아직 공개하지 않았다.  editor@itworld.co.kr


X