|
|
|
|
1회 : 성능 문제에 대한 체계적 접근 |
| 분산 애플리케이션 성능관리 |
 |
2007년 06월 15일 00:00:00 |
데이터넷
|
 |
|
|
딜레이 위치·형태 판단 필수
시스템 구조 복잡하면 ‘탑-다운’ 방식으로 접근 … 병목 지점·형태 파악 필수
성능이라는 이슈는 애플리케이션이 태동하는 개발과정, 테스트과정, 프로덕션(Production)에서부터 이후 운영에 이르는 애플리케이션 라이프사이클 상의 전 과정에서 매우 중요하고 자주 발생하는 부분이다. 분산 환경이 보편화되고 과거에 비해 점점 더 복잡하고 규모가 커지는 애플리케이션으로 인해서 이러한 성능 문제에 대한 해결은 점점 더 어려워지고 있는 실정이다. 아예 서비스가 되지 않는 상태 즉, 가용성에 문제가 있는 경우에는 그 원인이 좀 더 명확하다. 서비스를 구성하고 있는 IT 자원들 중에 현재 치명적인 장애가 존재하는 요소를 찾아내면 된다. 2회에 걸쳐 분산 애플리케이션 성능관리에 대해 알아본다. <편집자>
연재순서
1회 : 성능 문제에 대한 체계적 접근 (이번호)
2회 : 성능 문제 해결 사례 연구
 김동균 //
한국컴퓨웨어 기술지원본부 차창
Dongkyun_kim@compuware.com
서비스가 되지 않는 경우는 서버, 네트워크 장비, 데이터베이스, 방화벽 등 여러 요소들의 현재 상태를 모니터링해 다운되거나 정상적인 상태를 보이지 않는 요소를 찾아내면 된다. 물론, 왜 다운이 됐는지, 왜 정상적인 상태가 아닌지를 분석하는 것은 좀 더 많은 분석과 지식을 동원해야 하는 부분이긴 하지만 직접적인 영향을 준 요소에 대해서 직관적으로 찾아낼 수 있다.
하지만, 성능 문제는 전혀 눈에 보이지 않을 수 있다. 물론, CPU 사용량이 많거나 메모리 부족과 같은 단순한 문제라면 성능 문제에 대한 원인을 찾는 것은 간단한 일일 것이다. 문제는 서비스를 구성하는 다양한 요소들(라우터, 스위치, 방화벽, 웹 서버, WAS, 데이터베이스, OS, H/W, 애플리케이션 자체, 각종 미들웨어 및 레거시 시스템 등)로부터 명확한 증상을 찾기 어려운 상황에서 발생하는 성능 장애의 경우에는 그 원인을 찾는데 매우 어려움을 겪게 된다. 일단 성능 딜레이의 원인이 어디에 있는지 모르는 상황에서는 이러한 다양한 요소 모두에 대해서 현재 상황을 파악하고 문제의 원인이 어디에 있을지를 유추해나가야 한다.
라우터, 스위치, 방화벽과 같은 요소는 네트워크 담당자가 상세하게 조사를 하고, OS, H/W, 웹 서버, WAS 등은 시스템 운영자, 데이터베이스는 DBA, 애플리케이션 자체는 개발팀, 각종 미들웨어 및 레거시 시스템에 대한 부분은 각 시스템 담당자들이 개별적으로 자신이 담당하고 있는 부분을 상세히 조사하면서 원인을 찾아갈 것이다.
문제는 여기서 발생하기 시작한다. 사용자가 발생시키는 트랜잭션의 응답시간은 어느 한 두 개의 요소에만 의존적인 것이 아니라 서비스를 구성하는 모든 요소에 의존적이다. 이러한 요소들 중에 단 하나라도 병목이 존재한다면 사용자는 좋지 못한 성능을 경험하게 된다. 담당자들이 자신에게 관련된 요소들만을 개별적으로 분석을 하기 때문에 각 요소들 간의 유기적인 관계에 대한 부분을 찾아내지 못하게 된다. 사용자 응답시간은 결국 이러한 요소들 간의 유기적인 요청과 응답을 통해 최종적으로 사용자에게 응답을 보이게 되는데 성능 문제를 접근하는데 있어서 가장 중요한 이 부분을 명확히 파악하지 못한 채 각 담당자가 각개전투식으로 자신이 담당하고 있는 부분만을 보게 되는 것이다.
가용성의 문제는 서비스를 구성하는 각각의 요소 자체에 대한 상태를 파악하는 것이 중요하나 성능 문제는 그러한 요소들 간의 유기적인 커뮤니케이션 상태를 파악하는 것이 매우 중요하다. 게다가 성능 장애가 발생했을 때 그 문제의 원인이 자신이 담당하고 있는 부분에서 발생하는 것이라면 자신을 비롯해 자신이 속해있는 팀, 팀원, 팀장 등에게 매우 좋지 않은 일이기 때문에 방어적으로 나오게 된다. 이러한 방어적인 자세로 인해 각 담당자간의 원활한 협조를 통해 문제를 해결해나가는 것이 어려워진다.
또한 각 담당자는 서로간의 알고 있는 지식 도메인이 다르기 때문에 서로간의 의사소통도 쉽지 않게 된다. 네트워크 담당자가 개발자하고 의사소통 하거나 DBA가 WAS 담당자하고 의사소통하는 것이 쉬울 거라고 생각하는 사람은 없을 것이다. 결국 서로 이해관계가 다른 여러 담당자들이 서로 다른 지식 도메인으로 인해 의사소통이 어려워진 상태에서 한 배를 타고 노를 저어 나아갈 수밖에 없게 되고 결국 산으로 가는 불행한 사태가 발생할 수도 있게 된다.
필자 또한 성능 문제 해결을 위해 업체에 가면 문제를 해결하지 못하고 우왕좌왕하는 모습을 많이 보게 된다. 그렇다고 해서 모든 담당자들에게 서로 최대한 협조를 유지하고 열린 마음으로 문제를 해결하기 위해 최선을 다하라고만 하기에는 앞에서도 언급했듯이 현실적으로 어려운 부분이 있다. 오늘날과 같이 다양한 시스템이 존재하고 그 시스템들은 분산되어 있으며 각 시스템별로 서로 다른 담당자간의 원활한 의사소통을 위해서는 체계적인 문제 접근이 절실할 때이다.
탑-다운 방식의 문제접근
앞에서 설명한 문제 접근 방식은 바텀-업(Bottom-up) 방식이다. 성능 딜레이가 발생하고 있는 서비스를 구성하는 하위의 다양한 요소들을 전부 분석하고 모니터링해 성능에 영향을 주는 원인이 무엇인지를 찾아가는 방식이다. 이러한 방식은 시스템 구조가 단순하다면 크게 문제가 되지 않을 것이다. 하지만 시스템이 복잡해질수록 이와 같은 방식은 매우 비효율적인 방식이 된다.
서비스를 구성하는 요소가 많아지면 많아질수록 복잡도는 더 커지게 된다. 오늘날과 같은 복잡한 분산환경에서는 이와 같은 바텀-업 방식으로 문제를 접근하는 것은 매우 비효율적이다. 오늘날과 같은 환경에서는 탑-다운(Top-down) 방식의 접근이 문제를 해결하는데 효과적인 방법이 된다.
탑-다운 방식은 말 그대로 위에서 아래로 접근해나가는 방식으로 바텀-업과는 정반대의 문제 접근 방식이라고 생각하면 된다. 즉, 서비스를 구성하는 다양한 요소들부터 접근하는 것이 아니라 그 서비스를 사용하는 사용자부터 가장 먼저 접근하는 방식이다. 사용자가 호출한 트랜잭션이 네트워크를 지나 서버로 들어가 애플리케이션 로직이 수행되고 데이터베이스로부터 결과를 얻고 그것이 다시 클라이언트로 오는 그 모든 복잡한 과정을 먼저 생각하는 것이 아니라 사용자가 어떠한 응답시간을 경험했는지, 사용자와 시스템 사이에 어떻게 데이터를 주고 받았는지를 파악해야 한다. 사용자는 어떠한 데이터를 언제 보냈으며 시스템은 그에 대해서 어떤 응답을 언제 보냈는지, 그리고 그러한 턴(클라이언트의 요청에 대한 시스템의 응답 또는 시스템의 요청에 대한 클라이언트의 응답)이 얼마나 많은지 등을 파악하는 것이 중요하다.
이러한 성능 문제의 접근 방식과 관련해 크게 두 가지를 파악해야 한다. 첫째는 병목 지점이다. 궁극적으로 구체적인 병목 지점을 찾아내는 것이 성능 문제의 원인을 찾는 출발점이다. 하지만 병목지점은 무수히 많은 곳에서 발생할 수 있다. 서비스를 구성하는 수많은 요소들, 그 각각의 요소별로 또 수많은 병목지점이 존재할 수 있다. 따라서 이러한 병목지점을 한번에 찾아내는 것은 매우 어렵고 비효율적인 방법이 된다. 따라서 병목지점을 크게 몇 가지로 분류할 필요가 있다.
가장 크게 분류를 한다면 클라이언트, 네트워크, 서버로 나눌 수 있다. 가장 먼저 파악해야 하는 것은 이 세 가지 부분 중에 가장 병목을 일으키는 구간이 어디인지를 파악하는 것이다. 이러한 접근은 주소를 가지고 위치를 찾아가는 것과 비슷한 방법이라고 할 수 있을 것이다. 이 지구상에 주소는 수억 개가 존재할 것이다.
하지만 체계적인 주소체계를 가지고 있기 때문에 아무리 많은 주소가 존재하더라도 정확히 그 위치를 찾을 수 있게 된다. 성능 문제에 대한 접근도 이와 같은 방식으로 진행돼야 한다. 탑-다운 방식이란 결국 주소를 찾아가는 것과 같이 하나씩 문제의 접근 범위를 좁혀가는 방법이다.
둘째는 병목 형태이다. 병목 형태는 크게 네 가지로 나눠 볼 수 있다. 프로세싱 딜레이(Processing Delay), 센딩 딜레이(Sending Delay), 레이턴시 딜레이(Latency Delay), 대역폭 딜레이(Bandwidth Delay) 등으로 크게 나눌 수 있다(그림 1 참조). 이 네 가지 병목 형태는 하나의 트랜잭션을 완료하는데 걸리는 총 시간을 네 가지 형태로 구분한 것이다. 따라서 어떠한 원인으로 해서 딜레이가 발생하더라도 이 네 가지 중에 반드시 하나의 형태를 가지게 된다. 이러한 병목 지점과 병목 형태를 정의하고 현재의 성능 딜레이가 어디에 속하는지를 찾아내는 것은 실제 어느 곳에서 병목이 발생하고 있는지를 파악하는데 매우 중요한 단서가 된다.
한 예로, 웹 애플리케이션이 서비스 장애를 겪고 있는데 병목 지점이 서버이고 서버의 처리 시간이 문제라면 WAS, WAS에서 운영되는 애플리케이션, 쿼리, 데이터베이스 등의 상태를 확인해봐야 할 것이고, 병목지점이 서버이고 병목 형태가 센딩 딜레이라면 WAS, 웹 서버, 네트워크의 상태를 확인해봐야 할 것이다.
이와 같이 병목 지점과 병목 형태를 바탕으로 서비스를 구성하는 다양한 요소들 중에 상세하게 진단하고 분석해야 할 대상을 좁혀나가게 되는 것이다. 이렇듯 최상위 단계에서부터 그 문제의 지점을 좁혀 나가는 방식으로 접근해나가야 한다.
프로세싱 딜레이
<그림 1>을 보면 프로세싱 타임은 한쪽에서 요청한 것에 대해서 응답이 발생할 때까지의 시간이다. 이 시간뿐만 아니라 응답이 온 후에 다시 한쪽에서 요청이 발생할 때까지의 시간 또한 프로세싱 타임이다. 이 프로세싱 타임은 크게 클라이언트 프로세싱 타임과 서버 프로세싱 타임으로 나눠 볼 수 있다.
서버 프로세싱 타임은 주로 클라이언트 요청에 대해서 서버에서 처리를 하고 그 결과를 클라이언트에게 응답을 보일 때까지의 시간이 되고 클라이언트 프로세싱 타임은 클라이언트가 서버로부터 응답을 받은 후에 그 다음 요청을 할 때까지의 시간 또는 반대로 서버에서 요청한 것에 대해서 클라이언트가 처리 후에 결과를 보내기 전까지의 시간이 된다. 전체 응답시간에서 프로세싱 타임이 가장 많은 부분을 차지한다면 프로세싱 딜레이가 주요 원인으로 볼 수 있다.
클라이언트 프로세싱 딜레이의 한 예로, 웹 애플리케이션처리에서, PC의 사양이 좋지 못해 클라이언트 PC에서 데이터를 표현하는데 시간이 딜레이 되거나, 어떤 다른 프로세스가 자원을 많이 소비하고 있거나, 자바 스크립트 또는 액티브X와 같은 컴포넌트들이 처리 딜레이를 발생시키는 경우를 들 수 있다.
서버 프로세싱 딜레이는 클라이언트의 요청에 대해서 서버에서 받아들인 후 애플리케이션의 비즈니스 로직이 수행되고, 데이터베이스로부터 입력/수정/삭제/조회 등등의 작업이 수행된 후에 그 결과를 생성해 클라이언트에게 전달하기 시작할 때까지의 시간이 된다. 특히 이러한 클라이언트 처리 딜레이는 앞에서 설명한 바텀-업 방식으로 접근하게 되면 그 딜레이 원인을 찾는데 무척 어려움을 겪게 될 것이다.
모 회사에서 서비스중인 웹 애플리케이션의 성능이 좋지 못해 자문이 들어와서 컨설팅을 해준 적이 있다. 그 회사는 느린 트랜잭션의 원인을 찾기 위해서 모든 담당자들이 이미 매우 많은 노력을 했지만 그 원인을 찾지 못하고 심각한 상태에 빠져있는 상황이었다. 그 결과 원인은 클라이언트에 설치된 액티브X 컨트롤이 접근하려고 하는 다른 시스템과의 연결이 원활이 되지 않아 계속 접속재시도를 하는데 있었다. 때문에 결과 화면이 나오는데 매우 오랜 시간이 걸리는 것이었다. 이 문제를 해결하기 위해서 그 회사의 모든 운영자들이 서버, 네트워크, 데이터베이스, WAS 등에서 원인을 찾기 위해 많은 노력을 했지만 결국 그 원인을 찾지 못한 것은 그 원인이 클라이언트에 있었기 때문이다.
이처럼 바텀-업 형태의 문제 접근은 문제의 원인이 어디에 있는지에 대한 단서도 없이 전체를 모두 조사해야 하는 비효율적인 방법이다.
<그림 2>는 프로세싱 딜레이로 인해 트랜잭션 처리 시간이 길어지는 내용을 보여준다. 클라이언트의 요청에 대해서 서버에서 처리 후에 응답을 하는데 걸린 시간이 많음을 알 수 있다. 이러한 병목 형태를 보이는 트랜잭션은 서버와 애플리케이션 내부를 프로파일링해 서버의 성능을 파악하고 애플리케이션 내부에서 해당 트랜잭션을 처리하는 로직에 대한 프로파일링을 통해 애플리케이션 어느 구간(함수, 메쏘드 등)에서 딜레이가 발생하는지를 파악하고 그 딜레이의 원인이 되는 것이 무엇인지를 파악해서 개선해야 한다.
센딩 딜레이
<그림 1>에서 센딩 타임은 프로세싱이 끝난 후에 그 결과 데이터를 보내는데 걸린 시간을 말한다. 이 센딩 타임은 여러 가지 원인에 의해서 영향을 받을 수 있다.
첫째는 서버 또는 클라이언트 자체가 데이터를 보내는데 문제가 있는 경우이다. 예로, 웹 애플리케이션이라면 WAS 또는 웹 서버 또는 WAS내에서 수행되는 애플리케이션이 데이터를 보내는데 문제가 있을 수 있게 된다. 두 번째는 네트워크로 인해서 문제가 발생할 수 있다. 뒤에서 설명할 대역폭 딜레이, 레이턴시 딜레이도 결국 센딩 타임이 늦어지도록 만드는 원인이다. 네트워크에서 발생할 수 있는 원인은 여러 가지가 존재한다.
<그림 3>은 그 중 두 가지에 대해서 설명한다. 좌측은 윈도 사이즈에 문제가 있어서 노드에서 데이터를 보낼 때 딜레이가 발생하고 있는 내용이다.
TCP 통신은 데이터를 주고받을 때 윈도 사이즈를 결정하게 된다. 이 윈도 사이즈는 보내는 쪽에서 보낼 데이터의 크기를 결정짓게 된다. 이 윈도 사이즈는 TCP 버퍼 크기를 말하여 수신 측에 현재 얼마나 버퍼 공간이 있는지를 전송 측에 알려주는 것이다. 따라서 전송 측에서는 이 윈도 사이즈를 보고 적절한 크기의 데이터를 보내게 된다.
만약, 수신 측이 윈도 사이즈 0을 보내게 되면 송신 측은 수신 측의 윈도 사이즈가 커질 때까지 데이터 전송을 보류한다. 이러한 윈도 사이즈 0이 발생하는 경우는 수신 측에서 송신 측이 보내오는 데이터를 미처 처리하기 전에 계속해서 송신 측의 데이터를 받아들이다 보니 버퍼가 모두 다 차버리는 상황이 발생하게 된다. 물론, 수신 측이 데이터 처리가 밀리는 경우도 여러 가지 원인이 존재할 것이다. 중요한 것은 윈도 사이즈가 0이 된다는 것을 알아내는 것이다.
<그림 3>의 오른쪽 부분은 리트랜스미션(retransmis sion)으로 인해 발생하는 딜레이를 보여주는 그림이다. 송신 측에서 보낸 패킷이 수신 측에 도착하기 전에 네트워크 장비의 문제나 케이블 문제 기타 여러 가지 문제로 인해 패킷이 손실되는 경우가 발생하게 된다. 이러한 리트랜스미션은 TCP 통신에서 종종 발생한다. 리트랜스미션이 발생했다고 해서 데이터 통신에 심각한 딜레이가 발생하는 것은 아니다. 문제는 그림에서와 같이 리트랜스미션 타이머에 의해서 일정 시간 동안 통신을 중단하게 되는 상황이 발생하는 것이 문제가 된다.
송신 측은 패킷이 손실됐는지 아닌지를 알 수가 없다. 수신 측이 보내오는 ACK 패킷을 통해 송신 측 패킷을 제대로 받았는지 아닌지를 판단하게 된다. 만약, 수신 측에서 이러한 ACK 패킷이 오지 않으면 송신 측은 일정시간 동안 기다리다가 다시 패킷을 전송하게 된다. 얼마나 기다릴 것인가를 결정하는 것이 리트랜스미션 타이머다. 리트랜스미션이 발생할 때마다 타이머의 시간이 길어지게 된다. 즉, 송신 측이 데이터를 보내지 않고 멈추어서 기다리는 시간이 계속 길어지게 된다. 이러한 리트랜스미션은 네트워크 장비와 장비간의 설정, 케이블 불량 등등 물리적인 원인 또는 설정의 문제로 인해 발생하는 경우가 많다. 만약, 딜레이의 원인이 이러한 리트랜스미션이 문제라면 네트워크와 관련된 설정이나 네트워크 장비들에 대한 진단을 상세하게 해서 그 원인을 찾아내야 한다.
대역폭 딜레이
<그림 1>에서 대역폭 타임은 송신 측에서 데이터를 모두 보내는 데 걸린 시간과 수신 측에서 데이터를 모두 받는데 걸린 시간의 차이이다. 대역폭이 충분치 못한 경우 송신 측에서 아무리 데이터를 빨리 보낸다 할지라도 대역폭이 좋지 못한 구간에서 패킷들은 자신의 패킷이 전달될 때까지 대기열(queue)에 쌓이게 된다. 따라서 <그림 1>에서 보는바와 같이 송신 측에서는 짧은 시간에 패킷들을 모두 전송했지만 받는 쪽은 그보다 더 오랜 시간에 걸쳐서 패킷을 받게 된다.
초고속 인터넷이 대중화되고 실시간으로 인터넷 상에서 영화를 보는 환경에서 살고 있지만 네트워크 자원이라는 것은 유한한 자원이며 오늘날 거의 대부분의 애플리케이션은 네트워크를 이용한 분산 환경에서 동작한다. 점점 더 네트워크의 의존성이 더 커가고 있으며 네트워크는 클라이언트, 서버, 애플리케이션에 의해서 공유되고 효율적으로 사용되어야 하는 자원이다. 이러한 대역폭의 문제는 랜 구간이 아니라 왠 구간에서 중요한 이슈가 된다. 왠 구간은 랜 구간과 같이 대량의 대역폭을 제공받을 수 없기 때문이다.
<그림 4>는 대역폭이 좋지 못한 상황에서 센딩 딜레이가 발생하는 것을 보여준다. 대역폭이 원인인 경우는 애플리케이션에서 데이터 전송 크기를 줄이거나, 해당 구간의 대역폭을 높이는 것 또는 QoS를 통해 해당 서비스에 대한 대역폭을 높여주는 방식으로 문제를 해결해나가야 한다.
레이턴시 딜레이
<그림 1>에서 보는 바와 같이 레이턴시 타임은 패킷이 송신 측에서 수신 측까지 도착하는데 걸리는 시간이다. 이 레이턴시가 길어지면 결국 패킷이 도착하는데 시간이 더 걸리게 되고 전체 트랜잭션 응답시간이 길어지게 된다. 이러한 레이턴시가 길어지는 원인은 송신 측에서 수신 측까지 패킷이 전달되는 동안 얼마나 많은 홉(Hop)을 거치는가 각 홉(Hop)에서 발생하는 딜레이가 얼마나 되는가 하는 부분이다. 거치는 홉의 수가 많고 각 홉에서 발생하는 딜레이가 많아진다면 결국 레이턴시는 길어질 수밖에 없다. 거치는 홉의 개수는 물리적으로 얼마나 멀리 떨어져 있느냐에 따라서 그 개수가 결정될 수 있을 것이다. 서울에서 부산을 가는 것이 서울에서 대전을 가는 것보다 많은 시간이 걸리는 것은 당연한 것이다. 이러한 레이턴시 타임을 원천적으로 없애는 것은 불가능하다.
로컬 랜 환경에서의 레이턴시는 1ms 이하의 거의 무시할 수 있는 수준이지만 왠 환경에서의 레이턴시는 100, 200ms를 넘는 것은 기본이다. 결국 로컬 랜 환경과 비교해 왠에서의 패킷 전송 속도는 100배 이상 늦는다고 볼 수 있다. 이러한 레이턴시를 줄이는 것은 결코 쉬운 일이 아니다. 네트워크에 대한 토폴로지를 재구성하지 않는 이상 줄이는 것은 어려우며 네트워크의 토폴로지를 재구성한다는 것 또한 현실적으로 불가능하다. 결국 애플리케이션이 레이턴시에 의한 영향을 가장 많이 받는다면 애플리케이션이 그러한 레이턴시 환경에서 효과적인 통신을 할 수 있도록 해주어야 한다.
<그림 5>의 좌측은 레이턴시에 의한 딜레이를 보여주는 예이다. 클라이언트는 서버에서 데이터를 요청하고 서버는 매 요청마다 1K크기의 데이터를 전송이 되었다. 클라이언트는 데이터를 하나 보내고 서버에서 받기를 기다리고 다시 보내고 기다리는 형태이다. 이러한 방식으로 통신하는 경우에 RTT(Round-Trip-Time)가 좋지 않은 왠 환경에서는 매우 응답속도가 떨어지는 상황이 발생하게 된다. RTT는 네트워크의 패킷이 전송 측에서 수신 측까지 도달한후에 그에 대한 응답이 수신 측에서 송신 측까지 도착하는데 걸리는 시간이다.
개발하는 과정에서는 이러한 왠구간의 RTT가 좋지 않은 상황에 대한 예측을 하고 실제 서비스가 될 왠 환경을 고려해 개발하고 테스트하는 경우는 많지 않다. 주로 애플리케이션 자체의 성능이 어떠한지, 서버가 얼마나 많은 부하를 견딜 수 있는지에 대한 여부만을 고려하는 경우가 대부분이다. 개발 시에는 모든 개발자 및 테스터들이 로컬의 매우 네트워크가 좋은 환경에서 테스트를 하고 검증을 하기 때문에 이 부분이 간과되기 십상이다.
개발 시에 아무런 성능에 문제가 없었던 시스템이 실제 사용자 오픈 후에 성능에 문제가 발생하는 경우 이러한 왠구간에 대한 고려 없이 개발된 후에 실제 사용자들이 왠 구간에서 접속했을 때 매우 느린 성능을 경험하게 되는 사례를 보게 된다.
예로, 서울에서 부산까지 100톤의 화물을 전달해야 하는데 1톤짜리 트럭으로 100번을 서울에서 부산까지 왕복 하는 것 보다는 10톤 짜리 트럭으로 10번만 왕복하는 것이 더 시간을 절약할 수 있다는 것은 누구나 다 아는 사실이다. 하지만 서울에서 부산까지 눈 깜짝할 사이에 전달할 수 있다면 10번을 왕복하건, 100번을 왕복하건 별 시간 차이를 느끼지 못할 것이다. 즉, 로컬 랜에서는 매우 빠른 전송속도를 가지기 때문에 100번의 왕복을 하건 10번의 왕복을 하건 별 차이를 느끼지 못하지만 왠구간이 되면 몇 번을 왕복하느냐가 전체 사용자 응답시간에 많은 영향을 미치게 된다.
<그림 5>는 애플리케이션이 레이턴시에 의한 딜레이가 발생하는 예이다. 레이턴시가 좋지 않은 상황에서 클라이언트와 서버 사이에 비효율적인 통신 방식으로 인해 응답속도가 좋지 않은 트랜잭션을 보여주는 것이다. 좌측에 트랜잭션은 총 애플리케이션 턴(Turn)수가 네 번이 발생했다. 턴수가 많은 트랜잭션을 ‘채티(Chatty)하다’고 말한다. ‘채티’는 수다스럽다는 뜻인데 말 그대로 클라이언트와 서버 사이에 데이터가 왔다갔다 하는 횟수가 많다는 것을 의미한다. 그림에서는 총 턴수가 네 번있는데 하나의 트랜잭션의 턴 수가 네번인 것은 ‘채티’한 것이 아니다. 단지 하나의 예를 설명하는 것이다. 그림에서 보는 바와 같이 패킷이 전달되는데 시간이 걸리기 때문에 이러한 레이턴시에 의한 딜레이를 줄이기 위해서는 애플리케이션 턴 수를 줄이는 것이 좋은 해결책이다.
오른쪽 상위에 있는 것이 한번에 1K씩 전달되던 데이터를 묶어서 2K씩 보내도록 했을 때 같은 레이턴시 타임 구간에서속도가 두 배가 빨라졌음을 보여주는 것이다. 또 다른 방법으로 한 번의 클라이언트 요청에 대해서 서버에서 모든 데이터를 리턴하는 구조로 턴 수를 줄일 수 있을 것이다. 이러한 방법 외에도 다양한 방법으로 턴 수를 줄여나갈 수 있을 것이다.
하지만 한 가지 어려운 부분은 이미 시스템이 오픈되어 사용하는 상황에서 레이턴시에 의한 영향을 줄이기 위해서 턴 수를 낮춘다는 것은 결국 애플리케이션을 수정해야 한다는 것을 의미한다. 시스템을 오픈한 후에 애플리케이션을 수정하는 것은 현실적으로 어려운 경우가 존재한다. 따라서 개발을 진행할 때 개발된 시스템이 어떤 환경에서 운영될 것인지를 파악하고 거기에 가장 효과적일 수 있도록 프로토콜을 설계하는 것은 중요한 부분이다.
대역폭과 레이턴시
네트워크를 이야기할 때 차들이 다니는 도로를 가지고 비유해 설명하면 이해가 쉽다. 도로는 네트워크망이고 도로를 달리는 차들은 패킷이 된다. 도로를 달리다 보면 교차로를 만나고 거기서 빨간불이라면 신호대기를 할 것이고 파란불이라면 곧장 지나갈 수 있을 것이다. 이러한 교차로는 네트워크의 스위치와도 같다. 이러한 비유를 하는 이유는 네트워크에 대한 한가지 잘못된 고정관념에 대해서 말하기 위함이다.
보통 네트워크가 좋지 못해서 애플리케이션의 응답속도가 저하되는 경우 대역폭을 높여주면 해결될 것이라고 보는 경우가 많다. 네트워크 딜레이는 곧 대역폭 문제라고 바라보는 고정관념이 있다. 하지만 이것은 매우 잘못된 생각이다. 대역폭을 도로에 비유하면 차선과도 같다. 해당 도로가 몇차선 도로인가 하는 것이다. 레이턴시는 해당 도로의 최대 속도라 보면 된다. 예로 10차선 도로이지만 규정 속도가 시속 50Km라면 그 이상은 달릴 수 없는 것이고 비록 1차선 도로이지만 제한속도가 200Km라면 빨리 달릴 수 있는 것이다. 평상시 1시간이면 가던 거리를 2시간이 지나도록 도착하지 못하고 차가 도로에 꽉 막혀 있는 경우 무엇이 문제인지 답답해하고 있는 차에 교통방송에서 차량 고장으로 인해 어느 지역이 막혀있다는 말을 듣게 된다. 이런 경우에는 고장 차량으로 인해서 평상시 다니던 차선보다 다닐 수 있는 차선이 좁아졌으며 이로 인해서 좁아진 구간에서 교통량을 처리하지 못해 발생한 것이기 때문에 이것은 대역폭에 의한 딜레이와 동일한 것이다.
또 다른 경우를 보자. 차가 막힌 이유가 도로공사에서 아스팔트를 새로 포장하기 위해서 기존 아스팔트를 모두 걷어내고 비포장도로를 만들어 놓은 곳이 있어서 막힌 것이라면 그것은 레이턴시에 의한 딜레이인 것이다. 첫번째 원인의 해결은 고장 차량을 제거하는 것이다. 즉, 좁혀진 도로 폭을 넓혀주어야 하는 것이고 두번째 원인의 해결책은 비포장도로를 포장도로로 만들어 주는 것이다. 즉, 레이턴시를 줄여주는 것이다. 두번째 문제에 대해서 도로폭을 넓혀 주는 것은 아무런 도움이 되지 않는다. 아무리 도로폭을 넓힌다 하더라도 비포장 도로 때문에 천천히 갈 수 밖에 없는 상황인데 도로폭을 넓히는 것은 아무런 도움이 되지 못한다.
이제까지 성능 문제를 체계적으로 접근하기 위해서 병목 지점과 병목 형태를 나누고 각각의 병목 지점과 형태에 따라서 어떠한 원인이 존재할 수 있는지에 대해서 설명하였다. 물론, 여기서 설명한 내용은 실제로 발생할 수 있는 수많은 구체적인 딜레이 원인 중에 아주 일부분일 것이다. 중요한 것은 딜레이의 위치와 형태를 판단하고 근본 원인을 찾기 위한 범위를 좁혀나가는 절차를 설명했다. 다음호에서는 다양한 성능 문제를 효과적으로 트러블 슈팅할 수 있는 몇가지 툴을 가지고 어떻게 딜레이원인을 찾을 수 있는지를 사례 중심으로 설명하도록 하겠다. |
|
|
|
|
|
|
|
|
|
| ⓒ 데이터넷(http://t564.ndsoftnews.com) 무단전재 및 재배포금지 | 저작권문의 |
|
|
|
|
|
|
| |
| 가장 많이 본 기사 |
|
|
 |
|
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
