[김한도]성능에서의 풍선효과

성능에서의 풍선효과

지금 된서리를 맞고 있는 참여정부 시절에 한 때 지면을 화려하게 장식했던 단어가 있다. 그것은 바로 ‘풍선 효과’ 이다. 이 풍선 효과라는 말은 집값을 잡으려고 한쪽에 규제를 몰아주니 그 곳의 집값의 오름세는 둔화되었지만 그 근처의 집값이 오르는 현상을 일컫는다. 풍선 한 쪽을 꾸욱 누르니 반대 편으로 공기가 밀려 부풀어 오르는 모양새를 빗댄 것이다.

이런 풍선 효과가 비단 부동산에만 있는 것은 아니다. 오라클의 성능에서도 이러한 풍선효과는 엄연히 존재하고 있다. 간단하게 말하자면 어느 한 곳의 경합이 해결되었을 때 성능이 마냥 좋아지는 것이 아니라 경합의 위치가 이동하는 현상을 말하는 것이다. 이러한 현상은 Oracle의 특정 영역이 아닌 모든 지점에서 관찰된다.
오라클의 경합을 설명할 때 즐겨 사용하는 것 중에 하나가 도로 교통의 예이다. 도로 교통의 흐름과 Oracle의 자료 처리의 흐름과 유사성이 있기 때문이다. 아래의 그림은 병목이 있는 도로에 사고가 발생한 경우와 평상시의 경우를 표현한 것이다. 4차선 도로에서 사고가 발생하여 두 개의 차선을 사용하기 못하게 된 것을 가정해 보자 그렇게 되면 이 사고 지점까지는 지체 현상이 두드러질 것이다. 그러나 사고 지점을 지나기만 하면 차들은 다시 속도를 올릴 수 있다는 것은 이 글을 읽으시는 분들도 경험을 해 보았을 것이라 생각한다.
이 경우 사고지점을 통과하는 차들의 양이 적기 때문에 병목이 있다 해도 큰 영향을 주지는 못한다. 하지만 흐름이 좋을 때를 생각해 보자. 병목 지점에서는 여지 없이 정체가 발생할 것이다. 물론 사고가 났을 때와 사고가 나지 않았을 때의 통과하는 차량의 대수는 비교가 되지 않을 것이지만 여기서는 병목이 발생하는 지점에만 초점을 맞추어 보도록 하자.

위의 경우가 일시적인 사고가 아니라 장기간의 공사로 인해 두 개의 차선을 사용하지 못하는 경우로 가정해 보자. 그렇게 되면 이 곳을 통과하는 운전자들은 애초부터 있던 병목지점은 크게 신경 쓰지 않을 것이다. 그리고 이 공사지점만 해결되면 만사가 형통할 것이라 생각할 것이다. 하지만 공사가 끝나면 숨어 있던 병목지점이 두드러 질 것이고 운전자들은 도로 설계에 대한 불평이 시작될 것이다. 이것은 바로 병목지점이 공사지점에서 차로가 좁아지는 곳으로 이동했기 때문이다. 즉 한 곳을 해결했더니 다른 한 쪽이 부각되는 풍선효과가 발생한 것으로 생각할 수 있다.

오라클에서도 마찬가지이다. 이미 엑셈 블로그의 넓은 시야에 대한 성찰이라는 글을 통해 이러한 풍선효과가 보고된 적이 있다. 무거운 Library Cache라는 Oracle의 장치를 가벼운 Mutex로 대체하였더니 숨어있던 과다 실행이라는 문제가 부각되었다는 것이 바로 이 글에서 다루고 있는 사례였다. 이는 과다한Function Call이라는 근본적이 문제(좁아지는 차로)가 library cache latch(사고 또는 공사)로 인해 보이지 않고 있었고 Library Cache대신 Mutex를 사용하자 과다 CPU의 점유라는 문제로 전이되어 버린 것이다. 오라클의 성능에서 풍선효과가 발생하고 있었던 것이다.
요전에 분석했던 IO의 테스트에서도 풍선효과가 관찰되었다. 이 테스트는 사실 풍선효과를 확인하기 위한 것은 아니었다. 엑셈의 고문으로 계시는 이상원 박사님께서 Flash Memory Hard, 즉 SSD(Solid State Disk)의 성능 실험을 한 데이터를 분석하는 과정에서 풍선효과가 목격되었다. 이에 대해 얘기를 해볼까 한다.
이 테스트는 동일 머신, 동일 Application을 SCSI하드와 SSD를 물려서 Storage 차이를 두어 그 차이를 보는 것이 목적이었다. 이 테스트는 각 Storage 마다. Buffer Cache의 크기를 100MB부터 1.5GB까지 100MB단위로 증가시켜 성능 추이를 보는 방식으로 진행되었다.
일단 수행속도와 처리량은 SSD가 월등함을 볼 수 있다. 이 성능의 개선 효과는 Elapse Time과 db file sequential read라고 하는 random io의 대기시간과 비교해 보면 Storage의 성능 개선이 밑받침이 된 것으로 판단할 수 있다.

 
그런데 여기서 1회 수행당 db file sequential read의 소요시간을 보면 눈에 띄는 것이 하나 있다. SCSI는 Buffer Cache의 크기에 관계없이 1회 SQL 수행당 16ms로 동일한데 반해 SSD의 경우 Buffer Cache의 크기가 증가함에 따라 소요시간이 증가 추세에 있다는 것이었다. 이러한 추이하면 5GB정도의 Buffer Cache를 사용하게 되면 SCSI나 SSD나 별반 차이가 없는 상황이 올 수도 있는 것이었다.

왜 Buffer Cache의 크기가 Storage의 성능 개선을 상쇄시키는 것일까? 가장 의심이 가는 것은 바로 풍선효과였다. IO의 제약이 사라짐에 따라 봇물같이 Block이 쏟아져 나왔을 것이므로 Buffer Cache의 경합이 발생했을 것이라는 생각이었다. 그러면 그 경합은 적재하는 과정이거나 탐색하는 과정에서 발생했을 것으로 가정해 볼 수 있다. 

 
우선 적재하는 과정에서 경합이 발생했는지를 판단하기 위해 read by other session라는 지표의 추이를 살펴보았다. 그러나 SSD에서 지속적으로 증가하는 추이는 찾아볼 수 없었다. 그리고 SCSI와 SSD모두 Buffer Cache가 증가함에 따라 Physical Reads의 양이 줄었기 때문에 적재에서 경합이 발생한다고는 생각할 수 없었다.

 
그래서 이미 Buffer Cache에 올라온 Buffer들을 탐색하는 데 경합을 확인하기 위해 latch: cache buffers lru chain과 latch: cache buffers chain의 발생 추이를 확인하였다. 이 그래프를 보면 역시 SSD가 Buffer Cache의 크기에 따라 지속적으로 증가하고 있음을 알 수 있다. 결국 예상했던 것과 같이 IO에서 성능 저해 요소가 사라지자 Buffer Cache의 latch로 성능 문제가 전이 되는 풍선효과가 있었음을 알 수 있었다.
이러한 현상을 풍선효과가 아니라 까도 까도 깔 것이 있는 양파 같다고 양파효과라 해도 상관 없다. 이러한 현상을 어떻게 부르느냐가 중요한 것이 아니라 성능에 있어서 발생하는 이러한 현상 자체가 중요하기 때문이다. 그래서 성능을 개선하기 위해서는 성능문제를 유발하는 근본 원인을 잘 판단하여 끝까지 추적하여 잡아내는 자세가 필요하다고 생각한다.

PS) 위 테스트 결과에서 성능을 더욱 개선하는 것은 상당히 어렵다고 생각한다. 그 이유는 지금까지 그 이유는 지금까지 Oracle은 기계적인 HDD를 감안하여 개선이 되어 왔다. Buffer Cache의 latch를 몇 개를 두느냐를 결정할 때도 이러한 경험적 지식이 바탕이 되었을 것이라 생각한다. 만약 latch 문제를 해결하기 위해 두 개의 latch를 증가하면 개선이 될까? 그건 장담할 수 없다. 하지만 머지 않아 SSD가 엔터프라이즈 시장의 강자가 될지도 모른다. 그렇게 되면 이에 대한 최적화 이슈가 상당히 늘어나게 된다는 것만은 확실할 것으로 생각한다.