[지디넷코리아]성능 튜닝에 관한 글을 요청받고 어떤 글을 쓸까, 과연 글을 쓸 만한 기술이 있을까, 쓴다면 독자들에게 어떤 이야기를 들려줄 것인가를 생각하게 되었다. 엔지니어적 관점에서 성능이라는 주제는 고도의 기술과 논리적 사고를 요하는 흥미로운 분야이지만, 한편으로는 방대한 배경 지식을 요하는 분야이고 체계적인 방법으로 접근하고 논하기에도 힘든 분야이다.

물론 성능 튜닝 분야에서도 IT 엔지니어의 양적인 팽창과 인터넷의 혁명으로 특정 솔루션 튜닝 기법과 실무 사례들은 주위에서 쉽게 구할 수 있다. 그럼에도 불구하고 끊임없이 성능상의 문제가 발생하는 이유는 무엇인가? 기본적인 솔루션의 튜닝 지식에도 불구하고 실제 튜닝을 할 수 없는 이유는 무엇인가?

필자의 경험으로는 성능에 관한 이해 부족과 문제를 체계적으로 해결할 수 있는 방법론의 부재라고 생각한다.

필자는 또 한번 고민에 부딪혔다. 바로 방법론과 기본 지식 중 어떤 분야를 이 글에서 이야기할 것인가를 고민했고, 결과는 기본 지식을 이야기하기로 결정했다.

그 이유는 “테스팅은 방법론적 접근이 가능하지만 튜닝은 예술”이라는 격언과(섣부른 접근보다는 기회가 주어진다면 진지한 접근을 하고 싶다. 책 한권 분량은 되지 않을까?) 기본 지식에 관해 다시 한번 음미하는 기회를 가지는 것이 ‘왜 튜닝을 하는가?’란 이 글의 화두와도 어울린다고 생각했으며, 무엇보다 중요하다고 생각하기 때문이다.

필자가 튜닝에 관해 조금 안다고 자부하던 시절, 다음과 같은 충격적인 질문을 받았다. “시스템을 모니터링할 때 왜 CPU 사용량이 70~80%일 때 CPU 병목이라고 하나요? 50%도 아니고 60도 아니고 70~80%인 이유는 무엇인가요?” 이러한 질문에 필자는 그 당시 어물쩡 넘어갔지만, 한 동안 “내가 성능을 정말 이해하고 있는 게 맞는 것일까”하는 자괴감을 안겨 주었다.

필자가 즐겨보는 ‘CEO 익스체인지’라는 텔레비전 프로그램에서 헤드헌팅 회사의 CEO는 다음과 같은 질문을 헤드헌팅 대상자에게 주로 건넨다. “당신이 자기 자신에게 가장 큰 오해를 하고 있는 것은 무엇인가?” 이제 우리가 이러한 질문을 자신에게 물어봐야 할 시점이 된 것 같다. “당신이 성능에 관해 가장 큰 오해를 하고 있는 것은 무엇인가?”

에피소드 1. CPU 사용량 80%의 함정
왜 80인가에 관한 의문을 풀기 위해서는 다소 딱딱한 그렇지만 재미있을 수도 있는 큐잉 이론(Queueing theory)이라 불리는 수학적인 이야기를 하기로 하자.


<그림 1> 큐잉 이론
<그림 1>은 시스템의 상태(state)를 서비스 요청(request)의 개수로 그린 그림이다. 서비스 요청 개수의 예로는 CPU 자원인 경우 CPU 할당을 기다리고 있는 프로세스의 개수이며, 웹서버의 경우 사용자로부터 요청된 URL의 개수라고 할 수 있다. 원으로 표시된 상태는 서비스 요청이 K일 경우 시스템의 상태를 표시한다. λ는 새로이 발생되는 요청 개수이며, μ는 처리된 요청 개수로서 단위는 request/sec이다.

새로 발생되는 서비스 요청과 처리된 요청에 따라 시스템의 상태는 변화하게 된다. 바운더리로 표시된 영역은 새로이 발생된 요청의 개수와 처리된 요청의 개수가 균형을 이루는 경계들을 표현하고 있으며, 이러한 상태는 ‘operational equilibrium’이라 한다.

‘operational equilibrium’에 관심을 가지는 이유는 옆의 그림과 같이 설명될 수 있다. 만약 flow-in이 flow-out보다 지속적으로 많은 불안정한 관계가 지속될 경우 댐은 붕괴된다(컴퓨터 시스템의 경우 크래시 또는 다운될 것이다).

우리는 댐이 붕괴되는 시점을 모델링하고 싶은 것은 아니므로, 특정한 시점에서 flow-in과 flow-out이 균형을 이룬다고 가정할 경우 시스템의 상태는 다음과 같다(몇 가지 가정이 더 있지만 이 글에서는 생략한다. 더 자세히 알고 싶은 독자는 큐잉 이론을 참고하기 바란다).